idnits 2.17.1 draft-sermersheim-nds-ldap-schema-02.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. 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 146: '...f true, this object class SHALL NOT be...' RFC 2119 keyword, line 159: '...th a list of all MUST and MAY attribut...' RFC 2119 keyword, line 304: '... NDS servers MUST, and Clients that ...' RFC 2119 keyword, line 305: '... SHOULD recognize all the syntaxes d...' RFC 2119 keyword, line 365: '...e transmitted in text form and MUST be...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 348 has weird spacing: '... number uint3...' == Line 394 has weird spacing: '... number uint3...' == Line 420 has weird spacing: '... number uint3...' == Line 648 has weird spacing: '...Seconds uin...' == Line 705 has weird spacing: '... number uint3...' -- 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 786 looks like a reference -- Missing reference section? 'RFC2252' on line 796 looks like a reference -- Missing reference section? 'RFC2256' on line 54 looks like a reference -- Missing reference section? 'RFC2119' on line 809 looks like a reference -- Missing reference section? 'Self' on line 564 looks like a reference -- Missing reference section? 'Creator' on line 567 looks like a reference -- Missing reference section? 'Public' on line 569 looks like a reference -- Missing reference section? 'Root' on line 572 looks like a reference -- Missing reference section? 'RFC1778' on line 791 looks like a reference -- Missing reference section? 'RFC2253' on line 803 looks like a reference -- Missing reference section? 'BYTEORDER' on line 813 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 13 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-02.txt July, 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 imperatives from [RFC2119] 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 Jan 2002 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 Description option is used (see 63 4.1.5.1 of [LDAPV3]). Applications may use the ";binary" Attribute 64 Description option when transmitting and requesting attributes, in 65 which case the BER 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 that 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 Jan 2002 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 may be nothing other than a 143 leaf node). 145 Valid values for the qdstrings following X-NDS_NONREMOVABLE are '0' 146 (false) and '1' (true). If true, this object class SHALL NOT be 147 removed from the schema. 149 The qdstrings following X-NDS_CONTAINMENT contains a list of all 150 object class names that may contain this object class. In other 151 words, only entries that are of an object class listed here may be a 152 direct superior in the DIT to entries of this object class. If this 153 term is not included when defining an object class, it will be 154 automatically filled with ( 'c' 'o' 'ou' 'l' 'domain' ). 156 The qdstrings following X-NDS_NAMING holds a list of all attribute 157 type names that may be used to name this object class. If this term 158 is not supplied when defining an object class, it will automatically 159 be filled with a list of all MUST and MAY attributes defined for 161 Sermersheim Informational - Expires Jan 2002 3 162 this object class that use any of the following syntaxes: Country 163 String, Directory String, IA5 String, and Printable String. 165 X-NDS_NAME is followed by a qdstrings that contains the legacy NDS 166 name for this object class. An example is ('Organizational Person'). 167 Because NDS was created before LDAP was defined, it sometimes 168 doesn't adhere to the exact same rules as LDAP. One such LDAP rule 169 is that the names of schema elements cannot contain anything other 170 than ASCII letters, the hyphen character and semicolon. NDS allows 171 spaces, colons, and others. For this reason, some schema elements 172 will have LDAP names that differ from the NDS names that they were 173 first known as. 175 4.4. Attribute Description 177 The NDSAttributeTypeDescription defined here, adds to the 178 AttributeTypeDescription, which is defined in section 4.2 of 179 [RFC2252]. The added terms, which begin with the characters 180 "X-NDS ", exist to describe NDS specific attribute constraints which 181 have not yet been adopted by LDAP attributes. 183 Lines have been folded for readability, transmissions of the 184 NDSAttributeTypeDescription do not contain newlines. The description 185 of whsp, qdescrs, qdstring, woid, numericstring, and noidlen are 186 given in section 4.3.2 of [RFC2252]. 188 NDSAttributeTypeDescription = "(" whsp 189 numericoid whsp ; AttributeType identifier 190 [ "NAME" qdescrs ] ; name used in AttributeType 191 [ "DESC" qdstring ] ; description 192 [ "OBSOLETE" whsp ] 193 [ "SUP" woid ] ; derived from this other 194 ; AttributeType 195 [ "EQUALITY" woid ] ; Matching Rule name 196 [ "ORDERING" woid ] ; Matching Rule name 197 [ "SUBSTR" woid ] ; Matching Rule name 198 [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3 of[RFC2252] 199 [ "SINGLE-VALUE" whsp ] ; default multi-valued 200 [ "COLLECTIVE" whsp ] ; default not collective 201 [ "NO-USER-MODIFICATION" whsp ] ; default user modifiable 202 [ "USAGE" whsp AttributeUsage ] ; default userApplications 203 [ "X-NDS_PUBLIC_READ" qdstrings ] 204 ; default not public read ('0') 205 [ "X-NDS_SERVER_READ" qdstrings ] 206 ; default not server read ('0') 207 [ "X-NDS_NEVER_SYNC" qdstrings ] 208 ; default not never sync ('0') 209 [ "X-NDS_NOT_SCHED_SYNC_IMMEDIATE" qdstrings ] 210 ; default sched sync 211 ; immediate ('0') 212 [ "X-NDS_SCHED_SYNC_NEVER" qdstrings ] 213 ; default schedule sync ('0') 215 Sermersheim Informational - Expires Jan 2002 4 217 [ "X-NDS_LOWER_BOUND" qdstrings ] 218 ; default no lower bound 219 ; ('0')(upper is specified in 220 ; SYNTAX) 221 [ "X-NDS_NAME_VALUE_ACCESS" qdstrings ] 222 ; default not name value 223 ; access ('0') 224 [ "X-NDS_NAME" qdstrings ] ; legacy NDS name 226 whsp ")" 228 AttributeUsage = 229 "userApplications" / 230 "directoryOperation" / 231 "distributedOperation" / ; DSA-shared 232 "dSAOperation" ; DSA-specific, value depends 233 ; on server 235 Valid values for the qdstrings following X-NDS_PUBLIC_READ are '0' 236 (false) and '1' (true). Setting this value to true indicates that 237 anyone can read the attribute without read privileges being 238 assigned. The use of ACL's to restrict the access to this attribute 239 will be ineffective. 241 Valid values for the qdstrings following X-NDS_SERVER_READ are '0' 242 (false) and '1' (true). When this is true, server class objects can 243 read the attribute even though the privilege to read has not been 244 granted. Clients cannot set or modify this value. 246 Valid values for the qdstrings following X-NDS_NEVER_SYNC are '0' 247 (false) and '1' (true). True here, indicates that this attribute is 248 never synchronized on other replicas. Clients may not set or modify 249 this value. 251 Valid values for the qdstrings following 252 X-NDS_NOT_SCHED_SYNC_IMMEDIATE are '0' (false) and '1' (true). By 253 default, any update to an attribute value will cause a replica 254 synchronization session to occur within 10 seconds. If this flag is 255 set to true, updates to this attribute won't immediately initiate a 256 synchronization session, instead, a synchronization session will be 257 initiated within 30 minutes. At that time the updates will be 258 replicated to other servers. 260 Valid values for the qdstrings following X-NDS_SCHED_SYNC_NEVER are 261 '0' (false) and '1' (true). If this flag is set to true, updates to 262 this attribute will not cause a synchronization session to be 263 scheduled. Note that this flag does not prevent the attribute from 264 being synchronized like the X-NDS_NEVER_SYNC does. Once a 265 synchronization session is initiated by another process, the updates 266 to this attribute will be replicated. After the creation of an 267 AttributeType, this field cannot be updated. 269 Sermersheim Informational - Expires Jan 2002 5 270 Valid values for the qdstrings following X-NDS_LOWER_BOUND is a 271 quoted uint32string. This represents the lowest value that may be 272 used in this attribute. LDAP only allows for an upper bound (see the 273 definition of noidlen in RFC 2252) 275 Valid values for the qdstrings following X-NDS_NAME_VALUE_ACCESS are 276 '0' (false) and '1' (true). This is specified only when the 277 attribute uses a Distinguished Name syntax. It specifies (when true) 278 that the subject (user) must have management rights (write 279 permissions on the acl attribute) to the entry which the DN names, 280 that is being added or removed from this attribute. In other words, 281 if this is set on my 'friends' attribute, I can't add your DN to my 282 list of friends unless I have write permissions to your acl 283 attribute. For those who are familiar with legacy NDS access APIs, 284 this is the "Write Managed" flag and is renamed here for clarity. 286 5. Syntaxes 288 The NDSSyntaxDescription defined here, adds to the 289 SyntaxDescription, which is defined in section 4.3.3 of [RFC2252]. 290 The added terms, which begin with the characters 291 "X-NDS ", exist to describe NDS specific information. 293 Lines have been folded for readability, transmissions of the 294 NDSSyntaxDescription do not contain newlines. The description of 295 whsp, qdstring, and numericoid are given in section 4.1 of 296 [RFC2252]. 298 NDSSyntaxDescription = "(" whsp 299 numericoid whsp ; Syntax identifier 300 [ "DESC" qdstring ] ; description 301 [ "X-NDS_SYNTAX" qdstrings ] ; legacy NDS syntax identifier 302 whsp ")" 304 NDS servers MUST, and Clients that wish to operate with NDS servers 305 SHOULD recognize all the syntaxes described in this section. 307 5.1 Case Ignore List 309 ( 2.16.840.1.113719.1.1.5.1.6 DESC 'Case Ignore List' ) 311 This syntax is the same as Postal Address (6.27 of [RFC2252]) except 312 there is no limitation of characters per line, nor number of lines. 313 NDS limits Postal Address to six strings. 315 Values in this syntax are encoded according to the following BNF: 317 caseIgnorelist = dstring *( "$" dstring) 319 Backslashes and dollar characters are escaped as described in 6.27 320 of [RFC2252]. 322 Sermersheim Informational - Expires Jan 2002 6 323 The following ASN.1 data type is used to represent this syntax when 324 transferred in BER form (see 4.1): 326 caseIgnorelist ::= SEQUENCE OF LDAPString 328 Attributes of this syntax match for equality using 329 caseIgnoreListMatch (2.5.13.11) 331 5.2 Tagged Data 333 ( 2.16.840.1.113719.1.1.5.1.12 DESC 'Tagged Data' ) 335 This is the Net Address syntax in NDS. 337 Values in this syntax are encoded according to the following BNF: 339 taggedData = uint32string "#" octetstring 341 Note that the data portion of the value is represented as an octet 342 string, which may contain non printable characters. 344 The following ASN.1 data type is used to represent this syntax when 345 transferred in BER form (see 4.1): 347 taggedData ::= SEQUENCE { 348 number uint32, 349 data OCTET STRING 350 } 352 Attributes of this syntax match for equality if the number (using 353 integerMatch (2.5.13.14)) and the data matches exactly. 355 5.3 Octet List 357 ( 2.16.840.1.113719.1.1.5.1.13 DESC 'Octet List' ) 359 Used for attributes that are ordered sequences of octet strings. 361 Those familiar with this syntax as it is represented in NDS will 362 note that the length field has been omitted. 364 Because of problems finding a suitable separator character, Values 365 in this syntax are not be transmitted in text form and MUST be 366 transmitted in BER form. This is the default encoding for this 367 syntax and thus it is not necessary to specify the ;binary option. 369 The following ASN.1 data type is used to represent this syntax: 371 octetList ::= SEQUENCE OF OCTET STRING 373 Attributes of this syntax match for equality if the number of octet 374 strings is the same and each octet string matches. 376 Sermersheim Informational - Expires Jan 2002 7 377 Attributes of this syntax match approximately if at least one octet 378 string matches. 380 5.4 Tagged String 382 ( 2.16.840.1.113719.1.1.5.1.14 DESC 'Tagged String' ) 384 This is the Email Address syntax in NDS 386 Values in this syntax are encoded according to the following BNF: 388 taggedString = uint32string "#" dstring 390 The following ASN.1 data type is used to represent this syntax when 391 transferred in BER form (see 4.1): 393 taggedString ::= SEQUENCE { 394 number uint32, 395 string LDAPString 396 } 398 Attributes of this syntax match for equality if the number (using 399 integerMatch (2.5.13.14)) and the string (using caseIgnoreMatch 400 (1.3.6.1.4.1.1466.115.121.1.15)) matches. 402 5.5 Tagged Name And String 404 ( 2.16.840.1.113719.1.1.5.1.15 DESC 'Tagged Name And String' ) 406 This is the Path syntax in NDS 408 Values in this syntax are encoded according to the following BNF: 410 taggedNameAndString = distinguishedname "#" uint32string "#" dstring 412 Any occurance of the # character in the distinguishedname part MUST 413 be escaped using the rules in Section 4.3 of [RFC2252]. 415 The following ASN.1 data type is used to represent this syntax when 416 transferred in BER form (see 4.1): 418 taggedNameAndString ::= SEQUENCE { 419 name LDAPDN, 420 number uint32, 421 string LDAPString 422 } 424 The string represented by the string field is compared for equality 425 using the same rules that CaseExactIA5Match 426 (1.3.6.1.4.1.1466.109.114.1) uses, with the following exception: 428 Sermersheim Informational - Expires Jan 2002 8 429 In comparing two string values, the following white space (spaces, 430 tabs, etc.) is not significant: 431 Leading spaces (those preceding the first printable character) 432 Trailing spaces (those following the last printable character) 433 Multiple consecutive internal spaces (these are taken as equivalent 434 to a single space character) 436 In searches and comparisons, the string field can specify a presence 437 match by setting the string to "*". 439 5.6 NDS Replica Pointer 441 ( 2.16.840.1.113719.1.1.5.1.16 DESC 'NDS Replica Pointer') 443 Used for attributes whose values represent partition replicas. A 444 value of this syntax is composed of five parts: 446 1. The distinguished name of the server that stores the replica. 447 2. A value describing the capabilities of this copy of the 448 partition: master, secondary, read-only or subordinate reference. 449 3. A value indicating the current state of the replica (new, dying, 450 locked, changing state, splitting, joining, moving). 451 4. A number representing the replica (all replicas of a partition 452 have different numbers that are assigned when the replicas are 453 created). 454 5. A referral containing one or more network addresses that hint at 455 the node at which the server probably resides. Since servers are 456 accessible over different protocols, the server may have an address 457 for each supported protocol. 459 Values in this syntax may not be transmitted in string format. They 460 MUST be transmitted as BER representations of the following ASN.1: 462 ndsReplicaPointer ::= SEQUENCE { 463 serverName LDAPDN, 464 replicaType uint16, 465 replicaState uint16, 466 replicaNumber uint32, 467 replicaAddressHint SEQUENCE OF NetAddress 468 } 470 NetAddress ::= SEQUENCE { 471 transportType uint32, 472 addressValue OCTET STRING 473 } 475 Values for replicaType are: 476 0 Master, 477 1 Secondary, 478 2 Read Only, 479 3 Subordinate Reference, 480 4 Sparse Write, 482 Sermersheim Informational - Expires Jan 2002 9 483 5 Sparse Read. 485 Values for replicaState are: 486 0 On, 487 1 New Replica, 488 2 Dying Replica, 489 3 Locked, 490 4 Change Replica Type State 0, 491 5 ChangeReplica Type State 1, 492 6 Transition On, 493 48 Split State 0, 494 49 Split State 1, 495 64 Join State 0, 496 65 Join State 1, 497 66 Join State 2, 498 80 Move State 0, 499 81 Move State 1, 500 82 Move State 2. 502 Values for transportType are: 503 0 ipx, 504 1 ip, 505 2 sdlc, 506 3 tokenringEthernet, 507 4 osi nsap, 508 5 appleTalk, 509 6 netbeui, 510 7 sockAddr, 511 8 udp, 512 9 tcp, 513 10 udp6, 514 11 tcp6, 515 12 internal, 516 13 url. 518 Attributes of this syntax match for equality if the servername 519 matches using distinguishedNameMatch (2.5.13.1) 521 5.7 NDS ACL 523 ( 2.16.840.1.113719.1.1.5.1.17 DESC 'NDS ACL') 525 Used for attributes whose values represent ACL entries. An ACL value 526 can protect either an object or an attribute. The protected object 527 is always the one that contains the ACL attribute. 529 Values in this syntax are encoded according to the following BNF: 531 ndsAcl = privileges "#" scope "#" subjectname "#" protectedattrname 533 privileges = uint32string 535 Sermersheim Informational - Expires Jan 2002 10 536 scope = "entry" / "subtree" 538 subjectname = distinguishedname / "[Self]" / "[Creator]" / 539 "[Public]" / "[Inheritance Mask]" / "[Root]" 541 protectedattrname = caseignorestring / "[Entry Rights]" / 542 "[All Attributes Rights]" 544 The privileges field is number that represents the kind of access 545 being granted. Performing a bitwise OR on the numbers that represent 546 the desired access arrives at this number. Below a table is shown 547 which specifies the values: 549 Value Attributes [Entry Rights] 550 ----------------------------------------------------------- 551 1 Compare Attributes Browse Entry 552 2 Read Attributes Add Entry 553 4 Write, Add, Delete Attrs Delete Entry 554 8 Add/Delete Self Rename Entry 555 16 (none) Supervisory 556 32 Supervisory (none) 558 The scope field specifies whether or not the privileges are applied 559 to the target entry (the entry containing the ACL) or the target and 560 its subtree. 562 The subjectname either contains the distinguished name of the entry 563 being granted the privileges, or one of the special values: 564 [Self] Indicates the user authenticated in the current 565 connection. This can only be used in the Add 566 Entry operation. 567 [Creator] The user who created the object. This can only 568 be used in the Add Entry operation. 569 [Public] Includes all objects in the tree. 570 [Inheritance Mask] Filters or masks the privileges granted to an 571 object. 572 [Root] Denotes the directory tree root object 574 Any occurance of the # character in the subjectname MUST be escaped 575 using the rules in Section 4.3 of [RFC2252]. 577 The protectedattrname either names a specific attribute that the 578 privileges are applied to, or it contains one of the following 579 special values: 581 [Entry Rights] Privileges apply to the entire object, 582 rather than an attribute. 583 [All Attributes Rights] Privileges apply to all attributes of 584 the object. 586 If the protectedattrname neither specifies a valid attribute as 587 defined in the schema, nor one of the special values, an 589 Sermersheim Informational - Expires Jan 2002 11 590 invalidSyntax error will be returned 592 The following ASN.1 data type is used to represent this syntax when 593 transferred in binary form (see 4.1): 595 ndsAcl ::= SEQUENCE { 596 privileges uint32, 597 scope uint32, 598 subjectName LDAPDN, 599 protectedAttrName LDAPString 600 } 602 The special string values for protectedAttrName and subjectName are 603 the same as given in the BNF above. The privileges field is an 604 integer which represents the bit mask as described above. The scope 605 field is set to either 0 for "entry" or 1 for "subtree". 607 Attributes of this syntax match for equality if all fields match for 608 equality and match approximate if the attribute name and the subject 609 name match, and any privilege bits set in the filter are also set in 610 the target value. 612 5.8 NDS Timestamp 614 ( 2.16.840.1.113719.1.1.5.1.19 DESC 'NDS Timestamp') 616 Used for attributes whose values mark the time when a particular 617 event occurred or will occur. A time stamp value has three 618 components: 620 1. The wholeseconds value consists of the whole number of seconds, 621 where zero equals 12:00 midnight, January 1, 1970, UTC. 622 2. The replicanum value identifies the server that minted the 623 timestamp. A replica number is assigned whenever a replica is 624 created on a server. 625 3. The event field is an integer that orders events occurring within 626 the same whole-second interval. The event number restarts at one for 627 each new second. 629 The initial value of a time stamp has seconds = 1 and event = 0. 630 Values can be skipped, but MUST NOT be reused. An unknown event is 631 coded as 0xFFFF. 633 Values in this syntax are encoded according to the following BNF: 635 ndsTimestamp = wholeseconds "#" replicanum "#" event 637 wholeseconds = uint32string ; 0 = 12:00 midnight Jan 01 1970, UTC 639 replicanum = uint16string 641 event = uint16string 643 Sermersheim Informational - Expires Jan 2002 12 644 The following ASN.1 data type is used to represent this syntax when 645 transferred in binary form (see 4.1): 647 ndsTimestamp ::= SEQUENCE { 648 wholeSeconds uint32, 649 replicaNum uint16, 650 event uint16 651 } 653 Attributes of this syntax match for equality if the wholeSeconds 654 matches and the event matches. 656 Attributes of this syntax match for ordering using first the 657 wholeSeconds and then the event. 659 5.9 Counter 661 ( 2.16.840.1.113719.1.1.5.1.22 DESC 'Counter') 663 This syntax is the same as Integer (1.3.6.1.4.1.1466.115.121.1.27) 664 except that it has the following special properties: 666 - Attributes using this syntax are implicitly single-valued. 668 - The LDAP modify-add operation will add the passed number to the 669 value of the counter 671 - The LDAP modify-delete operation will subtract the passed number to 672 the value of the counter. 674 Values in this syntax are encoded in the same manner as the INTEGER 675 syntax. See [RFC2252] section 6.16. For example the value 11667 is 676 represented as the character string "11667" 678 The following ASN.1 data type is used to represent this syntax when 679 transferred in BER form (see 4.1): 681 counter ::= uint32 683 Integer matching rules apply to attributes of this syntax. 685 5.10 Tagged Name 687 ( 2.16.840.1.113719.1.1.5.1.23 DESC 'Tagged Name' ) 689 Holds a distinguished name and a 32 bit unsigned integer. 691 This is the Back Link syntax in NDS. 693 Values in this syntax are encoded according to the following BNF: 695 Sermersheim Informational - Expires Jan 2002 13 696 taggedName = uint32string "#" distinguishedname 698 Any occurance of the # character in the distinguishedname part MUST 699 be escaped using the rules in Section 4.3 of [RFC2252]. 701 The following ASN.1 data type is used to represent this syntax when 702 transferred in BER form (see 4.1): 704 taggedName ::= SEQUENCE { 705 number uint32, 706 name LDAPDN 707 } 709 Attributes of this syntax match for equality when the name matches 710 using distinguishedNameMatch (2.5.13.1) and the number matches. 712 5.11 Typed Name 714 ( 2.16.840.1.113719.1.1.5.1.25 DESC 'Typed Name') 716 Used for attributes whose values represent a level and an interval 717 associated with an object. This syntax names a directory entry and 718 attaches two numeric values to it: 720 1. The level of the attribute indicates the priority. 721 2. The interval indicates the frequency of reference. 723 The objectname value identifies the directory entry referred to by 724 the Typed Name. The values of level and interval are user-assigned 725 and relative. 727 To be effective, the user must implement them. The user can use them 728 to implement iterative intervals or to enforce priorities. 730 Values in this syntax are encoded according to the following BNF: 732 typedname = objectname "#" level "#" interval 734 objectname = distinguishedname. Any occurance of the # character in 735 the objectname part MUST be escaped using the rules in Section 4.3 736 of [RFC2252]. 738 level = uint32string 740 interval = uint32string 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, 748 Sermersheim Informational - Expires Jan 2002 14 749 level uint32, 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 764 While this document discusses the use of security related LDAP 765 attributes and syntaxes, it does not expose or create any security 766 problems which haven't been addressed in other documents. 768 10. Acknowledgements 770 The author would like to thank the input and review by individuals 771 at Novell including but not limited to Ed Reed, Renea Campbell, 772 Brian Jarvis, Mark Hinckley, Gary Anderson, Steve McLain, and Judy 773 Wilson. 775 11. Author's Address 777 Jim Sermersheim 778 Novell, Inc. 779 1800 South Novell Place 780 Provo, UT 84606 781 USA 782 +1 801 861 3088 784 12. Bibliography 786 [LDAPV3] 787 M. Wahl, S. Kille and T. Howes, "Lightweight Directory Access 788 Protocol (v3)", Internet Standard, December, 1997. Available as 789 RFC2251. 791 [RFC1778] 792 T. Howes, S. Kille, W Yeong, C. Robbins, "The String 793 Representation of Standard Attribute Syntaxes", Internet 794 Standard, March, 1995. Available as RFC1778. 796 [RFC2252] 797 M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight 798 Directory Access Protocol (v3): Attribute Syntax Definitions", 799 Internet Standard, December, 1997. Available as RFC2252. 801 Sermersheim Informational - Expires Jan 2002 15 803 [RFC2253] 804 M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access 805 Protocol (v3): UTF-8 String Representation of Distinguished 806 Names", Internet Standard, December, 1997. Available as 807 RFC2253. 809 [RFC2119] 810 S. Bradner, "Key Words for use in RFCs to Indicate Requirement 811 Levels", Internet Standard, March, 1997. Available as RFC2119. 813 [BYTEORDER] 814 C. Newman, "Network Byte Order" Internet Draft, February, 1999. 815 Available as draft-newman-network-byte-order-01.txt 817 Full Copyright Statement 819 "Copyright (C) The Internet Society 2001. All Rights Reserved. This 820 document and translations of it may be copied and furnished to 821 others, and derivative works that comment on or otherwise explain it 822 or assist in its implementation may be prepared, copied, published 823 and distributed, in whole or in part, without restriction of any 824 kind, provided that the above copyright notice and this paragraph 825 are included on all such copies and derivative works. However, this 826 document itself may not be modified in any way, such as by removing 827 the copyright notice or references to the Internet Society or other 828 Internet organizations, except as needed for the purpose of 829 developing Internet standards in which case the procedures for 830 copyrights defined in the Internet Standards process must be 831 followed, or as required to translate it into. 833 Sermersheim Informational - Expires Jan 2002 16