idnits 2.17.1 draft-ietf-asid-ldapv3-dn-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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 page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 1) being 61 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 42 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** 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 124: '... form SHOULD be used if the Attribut...' RFC 2119 keyword, line 140: '... Implementations MAY escape other char...' RFC 2119 keyword, line 155: '... client MUST also accept (and ignore...' RFC 2119 keyword, line 193: '... LDAPv2 client MUST accept the synta...' RFC 2119 keyword, line 194: '... MUST NOT, however, generate any of ...' (5 more instances...) == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC1779, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 27 has weird spacing: '...listing conta...' -- 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.) -- The document date (March 24, 1997) is 9866 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-09) exists of draft-ietf-asid-ldapv3-protocol-04 == Outdated reference: A later version (-07) exists of draft-ietf-asid-ldapv3-attributes-04 ** Obsolete normative reference: RFC 822 (ref. '5') (Obsoleted by RFC 2822) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Wahl 2 INTERNET-DRAFT Critical Angle Inc. 3 Obsoletes: RFC 1779 S. Kille 4 Isode Ltd. 5 T. Howes 6 Netscape Communications Corp. 7 Expires in six months from March 24, 1997 8 Intended Category: Standards Track 10 Lightweight Directory Access Protocol (v3): 11 UTF-8 String Representation of Distinguished Names 12 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, and 18 its working groups. Note that other groups may also distribute working 19 documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference material 24 or to cite them other than as "work in progress." 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 29 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 31 Abstract 33 The X.500 Directory uses distinguished names as the primary keys to 34 entries in the directory. Distinguished Names are encoded in ASN.1 35 in the X.500 Directory protocols. In the Lightweight Directory 36 Access Protocol, a string representation of distinguished names is 37 transferred. This specification defines the string format for representing 38 names, which is designed to give a clean representation of commonly used 39 distinguished names, while being able to represent any distinguished name. 41 1. Background 43 This specification assumes familiarity with X.500 [1], and the concept of 44 Distinguished Name. It is important to have a common format to be 45 able to unambiguously represent a distinguished name. The primary goal 46 of this specification is ease of encoding and decoding. A secondary 47 goal is to have names that are human readable. It is not expected that 48 LDAP clients with a human user interface would display these strings 49 directly to the user, but would most likely be performing translations 50 (such as expressing attribute type names in the local national language). 52 2. Converting DistinguishedName from ASN.1 to a String 54 In X.501 [2] the ASN.1 structure of distinguished name is defined as: 56 DistinguishedName ::= RDNSequence 58 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 60 RelativeDistinguishedName ::= SET SIZE (1..MAX) OF 61 AttributeTypeAndValue 63 AttributeTypeAndValue ::= SEQUENCE { 64 type AttributeType, 65 value AttributeValue } 67 The following sections defines the algorithm for converting from an 68 ASN.1 structured representation to a UTF-8 string representation. 70 2.1. Converting the RDNSequence 72 If the RDNSequence is an empty sequence, the result is the empty 73 or zero length string. 75 Otherwise, the output consists of the string encodings of each 76 RelativeDistinguishedName in the RDNSequence (according to 2.2), 77 starting with the last element of the sequence and moving backwards 78 toward the first. 80 The encodings of adjoining RelativeDistinguishedNames are separated by 81 a comma character (',' ASCII 44). 83 2.2. Converting RelativeDistinguishedName 85 When converting from an ASN.1 RelativeDistinguishedName to a 86 string, the output consists of the string encodings of each 87 AttributeTypeAndValue (according to 2.3), in any order. 89 Where there is a multi-valued RDN, the outputs from adjoining 90 AttributeTypeAndValues are separated by a plus ('+' ASCII 43) character. 92 2.3. Converting AttributeTypeAndValue 94 The AttributeTypeAndValue is encoded as the string representation 95 of the AttributeType, followed by an equals character ('=' ASCII 61), 96 followed by the string representation of the AttributeValue. The 97 encoding of the AttributeValue is given in section 2.4. 99 If the AttributeType is in a published table of attribute types 100 associated with LDAP [4], then the type name string from that table is 101 used, otherwise it is encoded as the dotted-decimal encoding of the 102 AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation is 103 described in [3]. As an example, strings for a few of the attribute 104 types frequently seen in RDNs include: 106 String X.500 AttributeType 107 ------------------------------ 108 CN commonName 109 L localityName 110 ST stateOrProvinceName 111 O organizationName 112 OU organizationalUnitName 113 C countryName 114 STREET streetAddress 115 DC domainComponent 116 UID userid 118 2.4. Converting an AttributeValue from ASN.1 to a String 120 If the AttributeValue is of a type which does not have a string 121 representation defined for it, then it is simply encoded as an octothorpe 122 character ('#' ASCII 35) followed by the hexadecimal representation of the 123 each of the bytes of the BER encoding of the X.500 AttributeValue. This 124 form SHOULD be used if the AttributeType is of the dotted-decimal form. 126 Otherwise, if the AttributeValue is of a type which has a string 127 representation, the value is converted first to a UTF-8 string according to 128 its syntax specification. 130 If the UTF-8 string does not have any of the following characters which need 131 escaping, then that string can be used as the string representation of the 132 value. 134 o a space or "#" character occurring at the beginning of the string 136 o a space character occurring at the end of the string 138 o one of the characters ",", "+", """, "\", "<", ">" or ";" 140 Implementations MAY escape other characters. 142 If a character to be escaped is a one of the list shown above, then it is 143 prefixed by a backslash ('\' ASCII 92). 145 Otherwise the character to be escaped is replaced by a backslash and two 146 hex digits, which form a single byte in the code of the character. 148 Examples of the escaping mechanism are shown in section 5. 150 3. Parsing a String back to a Distinguished Name 152 The structure of the string is specified in a BNF grammar, based on the 153 grammar defined in RFC 822, with the terminals enclosed in <> [5]. 154 Server implementations parsing a DN string generated by an LDAPv2 155 client MUST also accept (and ignore) the variants given in section 4 of 156 this document. 158 ::= | "" -- empty string 160 ::= | "," 162 ::= 163 | "+" 165 ::= 166 "=" 168 ::= 1*( ) | 169 ::= letters, digits and '-' 171 ::= 1* ( ) 172 ::= digits and '.' 174 ::= 176 ::= *( | ) 177 | "#" 178 | '"' *( | | ) '"' -- only from v2 180 ::= "," | "=" | "+" | "<" | ">" | "#" | ";" 182 ::= "\" ( | "\" | '"' | ) 183 ::= any character except or "\" or '"' 185 1* ( ) 186 ::= 187 ::= 0-9, a-f, A-F 189 4. Relationship with RFC 1779 and LDAPv2 191 The syntax given in this document is more restrictive than the 192 syntax in RFC 1779. Implementations parsing a string generated by an 193 LDAPv2 client MUST accept the syntax of RFC 1779. Implementations 194 MUST NOT, however, generate any of the RFC 1779 encodings which are not 195 described above in section 2. 197 Implementations MUST allow a semicolon character to be used instead of a 198 comma to separate RDNs in a distinguished name, and MUST also allow 199 whitespace characters to be present on either side of the comma or 200 semicolon. The whitespace characters are ignored, and the semicolon 201 replaced with a comma. 203 Implementations MUST allow an oid in the attribute type to be prefixed by 204 the characters "oid." or "OID.". 206 Implementations MUST allow for space (' ' ASCII 32) characters to be 207 present between and ',', between 208 and '+', between and '=', and between '=' and 209 . These space characters are ignored when parsing. 211 Implementations MUST allow a value to be surrounded by quote ('"' ASCII 212 34) characters, which are not part of the value. Inside the quoted value, 213 the following characters can occur without any escaping: 215 ",", "=", "+", "<", ">", "#" and ";" 217 5. Examples 219 This notation is designed to be convenient for common forms of name. 220 This section gives a few examples of distinguished names written 221 using this notation. First is a name containing three relative 222 distinguished names (RDNs): 224 CN=Steve Kille,O=Isode Limited,C=GB 226 Here is an example name containing three RDNs, in which the first RDN is 227 multi-valued: 229 OU=Sales+CN=J. Smith,O=Widget Inc.,C=US 231 This example shows the method of quoting of a comma in an organization name: 233 CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB 235 An example name in which a value contains a carriage return character: 237 CN=Before\0DAfter,O=Test,C=GB 239 An example name in which an RDN was of an unrecognized type. The value 240 is the BER encoding of an OCTET STRING containing two bytes 0x48 and 241 0x69. 243 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB 245 Finally, an example of an RDN surname value consisting of five letters: 247 Unicode Letter Description 10646 code UTF-8 Quoted 248 =============================== ========== ====== ======= 249 LATIN CAPITAL LETTER L U0000004C 0x4C L 250 LATIN SMALL LETTER U U00000075 0x75 u 251 LATIN SMALL LETTER C WITH CARON U0000010D 0xC48D \C4\8D 252 LATIN SMALL LETTER I U00000069 0x69 i 253 LATIN SMALL LETTER C WITH ACUTE U00000107 0xC487 \C4\87 255 Could be written in printable ASCII (useful for debugging purposes): 257 SN=Lu\C4\8Di\C4\C7 259 6. References 261 [1] The Directory -- overview of concepts, models and services. 262 ITU-T Rec. X.500(1993). 264 [2] The Directory -- Models. ITU-T Rec. X.501(1993). 266 [3] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol 267 (v3)", INTERNET DRAFT, draft-ietf-asid-ldapv3-protocol-04.txt. 268 March 1997. 270 [4] M. Wahl, S. Kille, T. Howes, A. Coulbeck, "Lightweight Directory Access 271 Protocol (v3): Standard and Pilot Attribute Definitions", INTERNET 272 DRAFT, draft-ietf-asid-ldapv3-attributes-04.txt. 273 March 1997. 275 [5] D. Crocker, "Standard of the Format of ARPA-Internet Text 276 Messages", STD 11, RFC 822, August 1982. 278 6. Security Considerations 280 Security issues are not discussed in this memo. 282 7. Author's Address 284 Mark Wahl 285 Critical Angle Inc. 286 4815 W. Braker Lane #502-385 287 Austin, TX 78759 288 USA 290 EMail: M.Wahl@critical-angle.com 292 Steve Kille 293 Isode Ltd. 294 The Dome 295 The Square 296 Richmond, Surrey 297 TW9 1DT 298 England 300 Phone: +44-181-332-9091 301 EMail: S.Kille@ISODE.COM 303 Tim Howes 304 Netscape Communications Corp. 305 501 E. Middlefield Rd 306 Mountain View, CA 94043 307 USA 309 Phone: +1 415 254-1900 310 EMail: howes@netscape.com