idnits 2.17.1 draft-sermersheim-nds-ldap-schema-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 13) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC2256], [LDAPV3], [RFC2252]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 145: '... If true, this object class MAY NOT be...' RFC 2119 keyword, line 158: '...th a list of all MUST and MAY attribut...' RFC 2119 keyword, line 302: '... NDS servers MUST, and Clients that ...' RFC 2119 keyword, line 303: '... SHOULD recognize all the syntaxes d...' RFC 2119 keyword, line 363: '...e transmitted in text form and MUST be...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 346 has weird spacing: '... number uint3...' == Line 393 has weird spacing: '... number uint3...' == Line 419 has weird spacing: '... number uint3...' == Line 650 has weird spacing: '...Seconds uin...' == Line 704 has weird spacing: '... number uint3...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Valid values for the qdstrings following X-NDS_NONREMOVABLE are '0' (false) and '1' (true). If true, this object class MAY NOT be removed from the schema. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'LDAPV3' on line 783 looks like a reference -- Missing reference section? 'RFC2252' on line 793 looks like a reference -- Missing reference section? 'RFC2256' on line 54 looks like a reference -- Missing reference section? 'RFC2119' on line 806 looks like a reference -- Missing reference section? 'Self' on line 565 looks like a reference -- Missing reference section? 'Creator' on line 568 looks like a reference -- Missing reference section? 'Public' on line 570 looks like a reference -- Missing reference section? 'Root' on line 573 looks like a reference -- Missing reference section? 'RFC1778' on line 788 looks like a reference -- Missing reference section? 'RFC2253' on line 798 looks like a reference -- Missing reference section? 'BYTEORDER' on line 810 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission J. Sermersheim 3 Internet Draft Novell, Inc. 4 Document: draft-sermersheim-nds-ldap-schema-01.txt January, 2001 5 Category: Informational 7 LDAP Schema for NDS 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- Drafts 20 as reference material or to cite them other than as "work in 21 progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 2. Abstract 29 This document defines the [LDAPV3] schema descriptions and non- 30 standard syntaxes used by Novell Directory Services (referred to 31 here as NDS). The ObjectClassDescription, AttributeTypeDescription, 32 SyntaxDescriptionm and syntaxes defined in this document are unique 33 to NDS and are meant to compliment those defined in [RFC2252], 34 [RFC2256] and other RFCs and Internet Drafts. 36 3. Overview 38 The purpose of this document is to advertise certain LDAP schema 39 descriptors, and syntax elements used by an NDS server which haven't 40 previously been defined in another RFC or Internet Draft. The schema 41 elements defined here represent those in use by NDS version 8 and 42 later. 44 4. Conventions used in this document 46 The key words from [RFC2119] are used in this document are to be 47 interpreted as described there. 49 4.1. Encodings 51 This document describes encodings used in an Internet protocol. 53 Sermersheim Informational - Expires July 2000 1 54 This document builds upon [RFC2252], [RFC2256] and their 55 predecessors. Implementers are strongly encouraged to become 56 familiar with those documents before reading this. 58 The attribute syntax definitions in this document are represented as 59 strings in BNF and in some cases, ASN.1. The intention is that the 60 string representations are used in normal transmissions of 61 attributes using these syntaxes. The ASN.1 is included for cases 62 where the "binary" Attribute Type Option is used (see 4.1.5.1 of 63 [LDAPV3]). Applications may use the "binary" Attribute Type option 64 when transmitting and requesting attributes, in which case the BER 65 encoding of the ASN.1 data type will be returned. 67 4.1.1. BNF 69 The BNF descriptions used here are described in section 4.1 of 70 [RFC2252]. The following definitions are also added: 72 distinguishedname = 73 uint16string = numericstring ; values transmitted as 74 ; uint16string have an 75 ; upper bound of "65535" 76 uint32string = numericstring ; values transmitted as 77 ; uint32string have an 78 ; upper bound of "4294967295" 80 There is no historical set convention for the use of value 81 delimiting characters. In this document, the following convention is 82 used: 83 "#" is used to delimit disparate elements 84 "$" is used to delimit like elements (such as those in a list) 85 "," is used to delimit disparate values which make up a single list 86 element or to separate disparate elements of a complex element which 87 itself is being separated by the "#" character. 89 4.1.2. ASN.1 91 The ASN.1 definitions include ASN.1 definitions from [LDAPV3] as 92 well as the following: 94 uint16 ::= INTEGER(0..maxUint16) 95 maxUint16 ::= 65535 -- (2^^16 - 1) 97 uint32 ::= INTEGER(0..maxUint32) 98 maxUint32 ::= 4294967295 -- (2^^32 - 1) 100 4.2. Distinguished Names 102 One must be aware that, when storing values in attributes of any 103 syntax listed here which contain a distinguished name, the value of 104 the distinguished name will be validated by the DSA. If a client 105 sends a distinguished name, which does not exist in the DIT, the 107 Sermersheim Informational - Expires July 2000 2 108 LDAP error invalidDNSyntax (34) will be returned in the LDAPResult. 110 4.3. Object Class Description 112 The NDSObjectClassDescription defined here, adds to the 113 ObjectClassDescription, which is defined in section 4.4 of 114 [RFC2252]. The additional terms, which begin with the characters 115 "X-NDS ", exist to describe NDS specific object class flags and 116 states that have not yet been adopted by LDAP object classes. 118 Lines have been folded for readability, transmissions of the 119 NDSObjectClassDescription do not contain newlines. The description 120 of whsp, qdescrs, qdstring, woid, numericstring, and noidlen are 121 given in section 4.1 of [RFC2252]. 123 NDSObjectClassDescription = "(" whsp 124 numericoid whsp ; ObjectClass identifier 125 [ "NAME" qdescrs ] 126 [ "DESC" qdstring ] 127 [ "OBSOLETE" whsp ] 128 [ "SUP" oids ] ; Superior ObjectClasses 129 [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ] 130 ; default structural 131 [ "MUST" oids ] ; AttributeTypes 132 [ "MAY" oids ] ; AttributeTypes 133 [ "X-NDS_NOT_CONTAINER" qdstrings ] ; default container ('0') 134 [ "X-NDS_NONREMOVABLE" qdstrings ] ; default removable ('0') 135 [ "X-NDS_CONTAINMENT" qdstrings ] 136 [ "X-NDS_NAMING" qdstrings ] 137 [ "X-NDS_NAME" qdstrings ] ; legacy NDS name 138 whsp ")" 140 Valid values for the qdstrings following X-NDS_NOT_CONTAINER are '0' 141 (false) and '1' (true). If true, instances of this object class may 142 not contain other object entries (it is a leaf node). 144 Valid values for the qdstrings following X-NDS_NONREMOVABLE are '0' 145 (false) and '1' (true). If true, this object class MAY NOT be 146 removed from the schema. 148 The qdstrings following X-NDS_CONTAINMENT contains a list of all 149 object class names that may contain this object class. In other 150 words, only entries that are of an object class listed here may be a 151 direct superior in the DIT to entries of this object class. If this 152 term is not included when defining an object class, it will be 153 automatically filled with ( 'c' 'o' 'ou' 'l' 'domain' ). 155 The qdstrings following X-NDS_NAMING holds a list of all attribute 156 type names that may be used to name this object class. If this term 157 is not supplied when defining an object class, it will automatically 158 be filled with a list of all MUST and MAY attributes that use any of 159 the following syntaxes: Country String, Directory String, IA5 161 Sermersheim Informational - Expires July 2000 3 162 String, and Printable String. 164 X-NDS_NAME is followed by a qdstrings that contains the legacy NDS 165 name for this object class. An example is ('Organizational Person'). 166 Because NDS was created before LDAP was defined, it sometimes 167 doesn't adhere to the exact same rules as LDAP. One such LDAP rule 168 is that the names of schema elements cannot contain anything other 169 than ASCII letters, the hyphen character and semicolon. NDS allows 170 spaces, colons, and others. For this reason, some schema elements 171 will have LDAP names that are different from the NDS names that they 172 were first known as. 174 4.4. Attribute Description 176 The NDSAttributeTypeDescription defined here, adds to the 177 AttributeTypeDescription, which is defined in section 4.2 of 178 [RFC2252]. The added terms, which begin with the characters 179 "X-NDS ", exist to describe NDS specific attribute constraints which 180 have not yet been adopted by LDAP attributes. 182 Lines have been folded for readability, transmissions of the 183 NDSAttributeTypeDescription do not contain newlines. The description 184 of whsp, qdescrs, qdstring, woid, numericstring, and noidlen are 185 given in section 4.3.2 of [RFC2252]. 187 NDSAttributeTypeDescription = "(" whsp 188 numericoid whsp ; AttributeType identifier 189 [ "NAME" qdescrs ] ; name used in AttributeType 190 [ "DESC" qdstring ] ; description 191 [ "OBSOLETE" whsp ] 192 [ "SUP" woid ] ; derived from this other 193 ; AttributeType 194 [ "EQUALITY" woid ] ; Matching Rule name 195 [ "ORDERING" woid ] ; Matching Rule name 196 [ "SUBSTR" woid ] ; Matching Rule name 197 [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3 of[RFC2252] 198 [ "SINGLE-VALUE" whsp ] ; default multi-valued 199 [ "COLLECTIVE" whsp ] ; default not collective 200 [ "NO-USER-MODIFICATION" whsp ] ; default user modifiable 201 [ "USAGE" whsp AttributeUsage ] ; default userApplications 202 [ "X-NDS_PUBLIC_READ" qdstrings ] 203 ; default not public read ('0') 204 [ "X-NDS_SERVER_READ" qdstrings ] 205 ; default not server read ('0') 206 [ "X-NDS_NEVER_SYNC" qdstrings ] 207 ; default not never sync ('0') 208 [ "X-NDS_NOT_SCHED_SYNC_IMMEDIATE" qdstrings ] 209 ; default sched sync 210 ; immediate ('0') 211 [ "X-NDS_SCHED_SYNC_NEVER" qdstrings ] 212 ; default schedule sync ('0') 213 [ "X-NDS_LOWER_BOUND" qdstrings ] 215 Sermersheim Informational - Expires July 2000 4 216 ; default no lower bound 217 ; ('0')(upper is specified in 218 ; SYNTAX) 219 [ "X-NDS_NAME_VALUE_ACCESS" qdstrings ] 220 ; default not name value 221 ; access ('0') 222 [ "X-NDS_NAME" qdstrings ] ; legacy NDS name 224 whsp ")" 226 AttributeUsage = 227 "userApplications" / 228 "directoryOperation" / 229 "distributedOperation" / ; DSA-shared 230 "dSAOperation" ; DSA-specific, value depends 231 ; on server 233 Valid values for the qdstrings following X-NDS_PUBLIC_READ are '0' 234 (false) and '1' (true). Setting this value to true indicates that 235 anyone can read the attribute without read privileges being 236 assigned. The use of ACL's to restrict the access to this attribute 237 will be ineffective. 239 Valid values for the qdstrings following X-NDS_SERVER_READ are '0' 240 (false) and '1' (true). When this is true, server class objects can 241 read the attribute even though the privilege to read has not been 242 granted. Clients cannot set or modify this value. 244 Valid values for the qdstrings following X-NDS_NEVER_SYNC are '0' 245 (false) and '1' (true). True here, indicates that this attribute is 246 never synchronized on other replicas. Clients may not set or modify 247 this value. 249 Valid values for the qdstrings following 250 X-NDS_NOT_SCHED_SYNC_IMMEDIATE are '0' (false) and '1' (true). By 251 default, any update to an attribute value will cause a replica 252 synchronization session to occur within 10 seconds. If this flag is 253 set to true, updates to this attribute won't immediately initiate a 254 synchronization session, instead, a synchronization session will be 255 initiated within 30 minutes at that time the updates will be 256 replicated to other servers. 258 Valid values for the qdstrings following X-NDS_SCHED_SYNC_NEVER are 259 '0' (false) and '1' (true). If this flag is set to true, updates to 260 this attribute will not cause a synchronization session to be 261 scheduled. Note that this flag does not prevent the attribute from 262 being synchronized like the X-NDS_NEVER_SYNC does. Once a 263 synchronization session is initiated by another process, the updates 264 to this attribute will be replicated. 266 Valid values for the qdstrings following X-NDS_LOWER_BOUND is a 267 quoted uint32string. This represents the lowest value that may be 269 Sermersheim Informational - Expires July 2000 5 270 used in this attribute. LDAP only allows for an upper bound (see the 271 definition of noidlen in RFC 2252) 273 Valid values for the qdstrings following X-NDS_NAME_VALUE_ACCESS are 274 '0' (false) and '1' (true). This is specified only when the 275 attribute uses a Distinguished Name syntax. It specifies (when true) 276 that the subject (user) must have management rights (write 277 permissions on the acl attribute) to the entry which the DN names, 278 that is being added or removed from this attribute. In other words, 279 if this is set on my 'friends' attribute, I can't add your DN to my 280 list of friends unless I have write permissions to your acl 281 attribute. For those who are familiar with legacy NDS access APIs, 282 this is the "Write Managed" flag and is renamed here for clarity. 284 5. Syntaxes 286 The NDSSyntaxDescription defined here, adds to the 287 SyntaxDescription, which is defined in section 4.3.3 of [RFC2252]. 288 The added terms, which begin with the characters 289 "X-NDS ", exist to describe NDS specific information. 291 Lines have been folded for readability, transmissions of the 292 NDSSyntaxDescription do not contain newlines. The description of 293 whsp, qdescrs, qdstring, woid, numericstring, and noidlen are given 294 in section 4.1 of [RFC2252]. 296 NDSSyntaxDescription = "(" whsp 297 numericoid whsp ; Syntax identifier 298 [ "DESC" qdstring ] ; description 299 [ "X-NDS_SYNTAX" qdstrings ] ; legacy NDS syntax identifier 300 whsp ")" 302 NDS servers MUST, and Clients that wish to operate with NDS servers 303 SHOULD recognize all the syntaxes described in this section. 305 5.1 Case Ignore List 307 ( 2.16.840.1.113719.1.1.5.1.6 DESC 'Case Ignore List' ) 309 This syntax is the same as Postal Address (6.27 of [RFC2252]) except 310 there is no limitation of characters per line, nor number of lines. 311 NDS limits Postal Address to six strings. 313 Values in this syntax are encoded according to the following BNF: 315 caseIgnorelist = dstring *( "$" dstring) 317 Backslashes and dollar characters are escaped as described in 6.27 318 of [RFC2252]. 320 The following ASN.1 data type is used to represent this syntax when 321 transferred in binary form (see 4.1): 323 Sermersheim Informational - Expires July 2000 6 324 caseIgnorelist ::= SEQUENCE OF LDAPString 326 Attributes of this syntax match for equality using 327 caseIgnoreListMatch (2.5.13.11) 329 5.2 Tagged Data 331 ( 2.16.840.1.113719.1.1.5.1.12 DESC 'Tagged Data' ) 333 This is the Net Address syntax in NDS. 335 Values in this syntax are encoded according to the following BNF: 337 taggedData = uint32string "#" octetstring 339 Note that the data portion of the value is represented as an octet 340 string, which may contain non printable characters. 342 The following ASN.1 data type is used to represent this syntax when 343 transferred in binary form (see 4.1): 345 taggedData ::= SEQUENCE { 346 number uint32, 347 data OCTET STRING 348 } 350 Attributes of this syntax match for equality if the number (using 351 integerMatch (2.5.13.14)) and the data matches exactly. 353 5.3 Octet List 355 ( 2.16.840.1.113719.1.1.5.1.13 DESC 'Octet List' ) 357 Used for attributes that are ordered sequences of octet strings. 359 Those familiar with this syntax as it is represented in NDS will 360 note that the length field has been omitted. 362 Because of problems finding a suitable separator character, Values 363 in this syntax may not be transmitted in text form and MUST be 364 transmitted in binary form. 366 The following ASN.1 data type is used to represent this syntax when 367 transferred in binary form (see 4.1): 369 octetList ::= SEQUENCE OF OCTET STRING 371 Attributes of this syntax match for equality if the number of octet 372 strings is the same and each octet string matches. 374 Attributes of this syntax match approximately if at least one octet 376 Sermersheim Informational - Expires July 2000 7 377 string matches. 379 5.4 Tagged String 381 ( 2.16.840.1.113719.1.1.5.1.14 DESC 'Tagged String' ) 383 This is the Email Address syntax in NDS 385 Values in this syntax are encoded according to the following BNF: 387 taggedString = uint32string "#" dstring 389 The following ASN.1 data type is used to represent this syntax when 390 transferred in binary form (see 4.1): 392 taggedString ::= SEQUENCE { 393 number uint32, 394 string LDAPString 395 } 397 Attributes of this syntax match for equality if the number (using 398 integerMatch (2.5.13.14)) and the string (using caseIgnoreMatch 399 (1.3.6.1.4.1.1466.115.121.1.15)) matches. 401 5.5 Tagged Name And String 403 ( 2.16.840.1.113719.1.1.5.1.15 DESC 'Tagged Name And String' ) 405 This is the Path syntax in NDS 407 Values in this syntax are encoded according to the following BNF: 409 taggedNameAndString = distinguishedname "#" uint32string "#" dstring 411 Although the '#' character may occur in a string representation of a 412 distinguished name, no additional special quoting is done. 414 The following ASN.1 data type is used to represent this syntax when 415 transferred in binary form (see 4.1): 417 taggedNameAndString ::= SEQUENCE { 418 name LDAPDN, 419 number uint32, 420 string LDAPString 421 } 423 The string represented by the string field is compared for equality 424 using the same rules that CaseExactIA5Match 425 (1.3.6.1.4.1.1466.109.114.1) uses. That is, two Paths match for 426 equality when their lengths and corresponding characters, including 427 case, are identical. 429 Sermersheim Informational - Expires July 2000 8 430 In comparing two values, the following white space (spaces, tabs, 431 etc.) is not significant: 432 Leading spaces (those preceding the first printable character) 433 Trailing spaces (those following the last printable character) 434 Multiple consecutive internal spaces (these are taken as equivalent 435 to a single space character) 437 In searches and comparisons, the string field can specify a presence 438 match by setting the string to "*". 440 5.6 NDS Replica Pointer 442 ( 2.16.840.1.113719.1.1.5.1.16 DESC 'NDS Replica Pointer') 444 Used for attributes whose values represent partition replicas. A 445 value of this syntax is composed of five parts: 447 1. The distinguished name of the server that stores the replica. 448 2. A value describing the capabilities of this copy of the 449 partition: master, secondary, read-only or subordinate reference. 450 3. A value indicating the current state of the replica (new, dying, 451 locked, changing state, splitting, joining, moving). 452 4. A number representing the replica (all replicas of a partition 453 have different numbers that are assigned when the replicas are 454 created). 455 5. A referral containing one or more network addresses that hint at 456 the node at which the server probably resides. Since servers are 457 accessible over different protocols, the server may have an address 458 for each supported protocol. 460 Values in this syntax may not be transmitted in string format. They 461 MUST be transmitted as BER representations of the following ASN.1: 463 ndsReplicaPointer ::= SEQUENCE { 464 serverName LDAPDN, 465 replicaType uint16, 466 replicaState uint16, 467 replicaNumber uint32, 468 replicaAddressHint SEQUENCE OF NetAddress 469 } 471 NetAddress ::= SEQUENCE { 472 transportType uint32, 473 addressValue OCTET STRING 474 } 476 Values for replicaType are: 477 0 Master, 478 1 Secondary, 479 2 Read Only, 480 3 Subordinate Reference, 481 4 Sparse Write, 483 Sermersheim Informational - Expires July 2000 9 484 5 Sparse Read. 486 Values for replicaState are: 487 0 On, 488 1 New Replica, 489 2 Dying Replica, 490 3 Locked, 491 4 Change Replica Type State 0, 492 5 ChangeReplica Type State 1, 493 6 Transition On, 494 48 Split State 0, 495 49 Split State 1, 496 64 Join State 0, 497 65 Join State 1, 498 66 Join State 2, 499 80 Move State 0, 500 81 Move State 1, 501 82 Move State 2. 503 Values for transportType are: 504 0 ipx, 505 1 ip, 506 2 sdlc, 507 3 tokenringEthernet, 508 4 osi nsap, 509 5 appleTalk, 510 6 netbeui, 511 7 sockAddr, 512 8 udp, 513 9 tcp, 514 10 udp6, 515 11 tcp6, 516 12 internal, 517 13 url. 519 Attributes of this syntax match for equality if the servername 520 matches using distinguishedNameMatch (2.5.13.1) 522 5.7 NDS ACL 524 ( 2.16.840.1.113719.1.1.5.1.17 DESC 'NDS ACL') 526 Used for attributes whose values represent ACL entries. An ACL value 527 can protect either an object or an attribute. The protected object 528 is always the one that contains the ACL attribute. 530 Values in this syntax are encoded according to the following BNF: 532 ndsAcl = privileges "#" scope "#" subjectname "#" protectedattrname 534 privileges = uint32string 536 Sermersheim Informational - Expires July 2000 10 537 scope = "entry" / "subtree" 539 subjectname = distinguishedname / "[Self]" / "[Creator]" / 540 "[Public]" / "[Inheritance Mask]" / "[Root]" 542 protectedattrname = caseignorestring / "[Entry Rights]" / 543 "[All Attributes Rights]" 545 The privileges field is number that represents the kind of access 546 being granted. Performing a bitwise OR on the numbers that represent 547 the desired access arrives at this number. Below a table is shown 548 which specifies the values: 550 Value Attributes [Entry Rights] 551 ----------------------------------------------------------- 552 1 Compare Attributes Browse Entry 553 2 Read Attributes Add Entry 554 4 Write, Add, Delete Attrs Delete Entry 555 8 Add/Delete Self Rename Entry 556 16 (none) Supervisory 557 32 Supervisory (none) 559 The scope field specifies whether or not the privileges are applied 560 to the target entry (the entry containing the ACL) or the target and 561 its subtree. 563 The subjectname either contains the distinguished name of the entry 564 being granted the privileges, or one of the special values: 565 [Self] Indicates the user authenticated in the current 566 connection. This can only be used in the Add 567 Entry operation. 568 [Creator] The user who created the object. This can only 569 be used in the Add Entry operation. 570 [Public] Includes all objects in the tree. 571 [Inheritance Mask] Filters or masks the privileges granted to an 572 object. 573 [Root] Denotes the directory tree root object 575 Although the '#' character may occur in a string representation of a 576 distinguished name used in the subjectname, no additional special 577 quoting is done. 579 The protectedattrname either names a specific attribute that the 580 privileges are applied to, or it contains one of the following 581 special values: 583 [Entry Rights] Privileges apply to the entire object, 584 rather than an attribute. 585 [All Attributes Rights] Privileges apply to all attributes of 586 the object. 588 If the protectedattrname neither specifies a valid attribute as 590 Sermersheim Informational - Expires July 2000 11 591 defined in the schema, nor one of the special values, an 592 invalidSyntax error will be returned 594 The following ASN.1 data type is used to represent this syntax when 595 transferred in binary form (see 4.1): 597 ndsAcl ::= SEQUENCE { 598 privileges uint32, 599 scope uint32, 600 subjectName LDAPDN, 601 protectedAttrName LDAPString 602 } 604 The special string values for protectedAttrName and subjectName are 605 the same as given in the BNF above. The privileges field is an 606 integer which represents the bit mask as described above. The scope 607 field is set to either 0 for "entry" or 1 for "subtree". 609 Attributes of this syntax match for equality if all fields match for 610 equality and match approximate if the attribute name and the subject 611 name match, and any privilege bits set in the filter are also set in 612 the target value. 614 5.8 NDS Timestamp 616 ( 2.16.840.1.113719.1.1.5.1.19 DESC 'NDS Timestamp') 618 Used for attributes whose values mark the time when a particular 619 event occurred or will occur. A time stamp value has three 620 components: 622 1. The wholeseconds value consists of the whole number of seconds, 623 where zero equals 12:00 midnight, January 1, 1970, UTC. 624 2. The replicanum value identifies the server that minted the 625 timestamp. A replica number is assigned whenever a replica is 626 created on a server. 627 3. The event field is an integer that orders events occurring within 628 the same whole-second interval. The event number restarts at one for 629 each new second. 631 The initial value of a time stamp has seconds = 1 and event = 0. 632 Values can be skipped, but MUST NOT be reused. An unknown event is 633 coded as 0xFFFF. 635 Values in this syntax are encoded according to the following BNF: 637 ndsTimestamp = wholeseconds "#" replicanum "#" event 639 wholeseconds = uint32string ; 0 = 12:00 midnight Jan 01 1970, UTC 641 replicanum = uint16string 643 Sermersheim Informational - Expires July 2000 12 644 event = uint16string 646 The following ASN.1 data type is used to represent this syntax when 647 transferred in binary form (see 4.1): 649 ndsTimestamp ::= SEQUENCE { 650 wholeSeconds uint32, 651 replicaNum uint16, 652 eventID uint16 653 } 655 Attributes of this syntax match for equality if the wholeSeconds 656 matches and the eventID matches. 658 Attributes of this syntax match for ordering using first the 659 wholeSeconds and then the eventID. 661 5.9 Counter 663 ( 2.16.840.1.113719.1.1.5.1.22 DESC 'Counter') 665 This syntax is the same as Integer (1.3.6.1.4.1.1466.115.121.1.27) 666 except that it has the following special properties: 668 - Attributes using this syntax are implicitly single-valued. 670 -The LDAP modify-add operation will add the passed number to the 671 value of the counter 673 -The LDAP modify-delete operation will subtract the passed number to 674 the value of the counter. 676 Values in this syntax are encoded in the same manner as the INTEGER 677 syntax. See [RFC2252] section 6.16. For example the value 11667 is 678 represented as the character string "11667" 680 The following ASN.1 data type is used to represent this syntax when 681 transferred in binary form (see 4.1): 683 counter ::= uint32 685 Integer matching rules apply to attributes of this syntax. 687 5.10 Tagged Name 689 ( 2.16.840.1.113719.1.1.5.1.23 DESC 'Tagged Name' ) 691 Holds a distinguished name and a 32 bit unsigned integer. 693 This is the Back Link syntax in NDS. 695 Sermersheim Informational - Expires July 2000 13 696 Values in this syntax are encoded according to the following BNF: 698 taggedName = uint32string "#" distinguishedname 700 The following ASN.1 data type is used to represent this syntax when 701 transferred in binary form (see 4.1): 703 taggedName ::= SEQUENCE { 704 number uint32, 705 name LDAPDN 706 } 708 Attributes of this syntax match for equality when the name matches 709 using distinguishedNameMatch (2.5.13.1) and the number matches. 711 5.11 Typed Name 713 ( 2.16.840.1.113719.1.1.5.1.25 DESC 'Typed Name') 715 Used for attributes whose values represent a level and an interval 716 associated with an object. This syntax names a directory entry and 717 attaches two numeric values to it: 719 1. The level of the attribute indicates the priority. 720 2. The interval indicates the frequency of reference. 722 The objectname value identifies the directory entry referred to by 723 the Typed Name. The values of level and interval are user-assigned 724 and relative. 726 To be effective, the user must implement them. The user can use them 727 to implement iterative intervals or to enforce priorities. 729 Values in this syntax are encoded according to the following BNF: 731 typedname = objectname "#" level "#" interval 733 objectname = distinguishedname 735 level = uint32string 737 interval = uint32string 739 Although the '#' character may occur in a string representation of a 740 distinguished name, no additional special quoting is done. 742 The following ASN.1 data type is used to represent this syntax when 743 transferred in binary form (see 4.1): 745 typedName ::= SEQUENCE { 746 objectName LDAPDN, 747 level uint32, 749 Sermersheim Informational - Expires July 2000 14 750 interval uint32 751 } 753 Attributes of this syntax match for equality if the name matches 754 using distinguishedNameMatch (2.5.13.1) and both values match. 756 8. Matching Rules 758 As of this printing, NDS tightly binds matching rules to syntaxes. 759 See the syntax definitions in section 5 for matching rule 760 explanations. 762 9. Security Considerations 763 While this document discusses the use of security related LDAP 764 attributes and syntaxes, it does not expose or create any security 765 problems which haven't been addressed in other documents. 767 10. Acknowledgements 768 The author would like to thank the input and review by individuals 769 at Novell including but not limited to Ed Reed, Renea Campbell, 770 Brian Jarvis, Mark Hinckley, Gary Anderson, Steve McLain, and Judy 771 Wilson. 773 11. Author's Address 774 Jim Sermersheim 775 Novell, Inc. 776 1800 South Novell Place 777 Provo, UT 84606 778 USA 779 +1 801 861 3088 781 12. Bibliography 783 [LDAPV3] 784 M. Wahl, S. Kille and T. Howes, "Lightweight Directory Access 785 Protocol (v3)", Internet Standard, December, 1997. Available as 786 RFC2251. 788 [RFC1778] 789 T. Howes, S. Kille, W Yeong, C. Robbins, "The String 790 Representation of Standard Attribute Syntaxes", Internet 791 Standard, March, 1995. Available as RFC1778. 793 [RFC2252] 794 M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight 795 Directory Access Protocol (v3): Attribute Syntax Definitions", 796 Internet Standard, December, 1997. Available as RFC2252. 798 [RFC2253] 799 M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access 800 Protocol (v3): UTF-8 String Representation of Distinguished 801 Names", Internet Standard, December, 1997. Available as 803 Sermersheim Informational - Expires July 2000 15 804 RFC2253. 806 [RFC2119] 807 S. Bradner, "Key Words for use in RFCs to Indicate Requirement 808 Levels", Internet Standard, March, 1997. Available as RFC2119. 810 [BYTEORDER] 811 C. Newman, "Network Byte Order" Internet Draft, February, 1999. 812 Available as draft-newman-network-byte-order-01.txt 814 Full Copyright Statement 816 "Copyright (C) The Internet Society 2001. All Rights Reserved. This 817 document and translations of it may be copied and furnished to 818 others, and derivative works that comment on or otherwise explain it 819 or assist in its implementation may be prepared, copied, published 820 and distributed, in whole or in part, without restriction of any 821 kind, provided that the above copyright notice and this paragraph 822 are included on all such copies and derivative works. However, this 823 document itself may not be modified in any way, such as by removing 824 the copyright notice or references to the Internet Society or other 825 Internet organizations, except as needed for the purpose of 826 developing Internet standards in which case the procedures for 827 copyrights defined in the Internet Standards process must be 828 followed, or as required to translate it into. 830 Sermersheim Informational - Expires July 2000 16