idnits 2.17.1 draft-ietf-asid-ldapv3-dn-00.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-04-25) 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 4 longer pages, the longest (page 1) being 63 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 38 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == 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 26 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 (July 31, 1996) is 10130 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-01 == Outdated reference: A later version (-07) exists of draft-ietf-asid-ldapv3-attributes-01 ** Obsolete normative reference: RFC 822 (ref. '5') (Obsoleted by RFC 2822) Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Wahl 3 INTERNET-DRAFT Critical Angle Inc. 4 Obsoletes: RFC 1779 S. Kille 5 ISODE Consortium 6 Expires in six months from July 31, 1996 7 Intended Category: Standards Track 9 Lightweight Directory Access Protocol (v3): 10 UTF-8 String Representation of Distinguished Names 11 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, and 17 its working groups. Note that other groups may also distribute working 18 documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 28 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 30 Abstract 32 The X.500 Directory uses distinguished names as the primary keys to 33 entries in the directory. Distinguished Names are encoded in ASN.1 34 in the X.500 Directory protocols. In the Lightweight Directory 35 Access Protocol, a string representation of distinguished names is 36 transferred. This specification defines the string format for representing 37 names, which is designed to give a clean representation of commonly used 38 distinguished names, while being able to represent any distinguished name. 40 1. Background 42 This specification assumes familiarity with X.500 [1], and the concept of 43 Distinguished Name. It is important to have a common format to be 44 able to unambiguously represent a distinguished name. The primary goal 45 of this specification is ease of encoding and decoding. A secondary 46 goal is to have names that are human readable. It is not expected that 47 LDAP clients with a human user interface would display these strings 48 directly to the user, but would most likely be performing translations 49 (such as expressing attribute type names in the local national language). 51 2. A Notation for Distinguished Name 53 In X.501 [2] the ASN.1 structure of Distinguished Name is defined as: 55 DistinguishedName ::= RDNSequence 57 RDNSequence ::= SEQUENCE OF RelativeDistinguishedName 59 RelativeDistinguishedName ::= SET SIZE (1..MAX) OF AttributeTypeAndValue 60 AttributeTypeAndValue ::= SEQUENCE { 61 type AttributeType, 62 value AttributeValue } 64 The following sections 2.1 and 2.2 define the algorithm for converting 65 between an ASN.1 structured representation and a UTF-8 string 66 representation. 68 2.1 Converting DistinguishedName from ASN.1 to a String 70 If the RDNSequence is an empty sequence, the result is the empty 71 or zero length string. 73 Otherwise, the output consists of the string encodings of each 74 RelativeDistinguishedName in the RDNSequence (according to 2.2), 75 starting with the last element of the sequence and moving backwards 76 toward the first. 78 The encodings of adjoining RelativeDistinguishedNames are separated by 79 either a comma or a semicolon character. There may be space 80 characters present on either side of the comma or semicolon. 82 Either the comma or the semicolon character is to be used to separate 83 all the RelativeDistinguishedNames in a particular string. 85 2.1.2. Converting RelativeDistinguishedName from ASN.1 to a String 87 When converting from an ASN.1 RelativeDistinguishedName to a 88 string, the output consists of the string encodings of each 89 AttributeTypeAndValue (according to 2.3), in any order. 91 Where there is a multi-valued RDN, the outputs from adjoining 92 AttributeTypeAndValues are separated by a plus character. 94 2.1.3. Converting AttributeTypeAndValue from ASN.1 to a String 96 The AttributeTypeAndValue is encoded as the string representation 97 of the AttributeType, followed by an equals character, followed by the 98 string representation of the AttributeValue. 100 If the AttributeType is one defined in Table 1 or in the IANA- 101 maintained register of valid attribute types, then the string from that 102 table is used, otherwise it is encoded as the string "OID." or "oid." 103 immediately followed by the dotted-decimal encoding of the AttributeType's 104 OBJECT IDENTIFIER. The dotted-decimal notation is described in [3]. 106 Table 1: Standardized Attribute Types used in RDNs 108 String AttributeType 109 ------------------------------ 110 CN commonName 111 L localityName 112 ST stateOrProvinceName 113 O organizationName 114 OU organizationalUnitName 115 C countryName 116 STREET streetAddress 117 DC domainComponent 119 2.1.4. Converting AttributeValue from ASN.1 to a String 121 If the AttributeValue is of a type which does not have a string 122 representation defined in [4], then it is simply encoded as an octothorpe 123 character ("#") followed by the hexidecimal representation of the bytes of 124 the BER encoding of AttributeValue. 126 Otherwise, if the AttributeValue is of a type which has a string 127 representation, it is converted first to a UTF-8 string according to that 128 specification. 130 If that 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 character occurring at the beginning of the string 136 o a space character occurring at the end of the string 138 o a space character adjoining another space character 140 o non-printing characters other than the single space 142 o one of the characters ",", "+", "=", """, "\", "<", ">", "#" or ";" 144 There are two possible escaping mechanisms. If the string does not contain 145 the double quote character, then the entire string can be surrounded by 146 double quote characters, and that used as the encoding. The alternative 147 is to prefix each of the characters which need escaping by a backslash 148 character. Examples of these mechanisms are shown in section 3. 150 2.2. 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]. 155 ::= | "" -- empty string 157 ::= ( ) 158 | 160 ::= 161 162 164 ::= "," | ";" 166 ::= *( " " ) 168 ::= 169 | "+" 170 172 ::= 173 "=" 175 ::= 1*( ) | "OID." | "oid." 176 ::= letters, numbers, and space 177 ::= | "." 178 ::= 1* 179 ::= digits 0-9 181 ::= 183 ::= *( | ) 184 | '"' *( | | ) '"' 185 | "#" 187 ::= "," | "=" | | "+" | "<" | ">" | "#" | ";" 189 ::= "\" ( | "\" | '"') 190 ::= any character except or "\" or '"' 192 ::= 2* 193 ::= 0-9, a-f, A-F 195 3. Differences from RFC 1779 197 The following changes have been made in this version of the specification: 199 o The use of angle brackets to surround the strings is not described, as 200 this is not used in LDAP. Also the grammar for UFNs has been removed. 201 However it is suggested that angle brackets may be used in preference to 202 quotes or other characters as delimiters when including distinguished 203 names in paragraphs. 205 o Only space characters, not newlines, are shown between RDNs. 207 o The AttributeType name "DC" has been added. 209 4. Examples 211 This notation is designed to be convenient for common forms of name. 212 This section gives a few examples of distinguished names written 213 using this notation: 215 CN=Steve Kille, O=ISODE Consortium, C=GB 216 CN=Christian Huitema, O=INRIA, C=FR 218 Here is an example of a multi-valued Relative Distinguished Name, 219 where the namespace is flat within an organization, and department is 220 used to disambiguate certain names: 222 OU=Sales + CN=J. Smith, O=Widget Inc., C=US 224 The final examples show both methods quoting of a comma in an 225 Organization name: 227 CN=L. Eagle, O="Sue, Grabbit and Runn", C=GB 228 CN=L. Eagle, O=Sue\, Grabbit and Runn, C=GB 230 5. References 232 [1] The Directory -- overview of concepts, models and services. 233 ITU-T Rec. X.500(1993). 235 [2] The Directory -- Models. ITU-T Rec. X.501(1993). 237 [3] M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol 238 (v3)", INTERNET DRAFT, draft-ietf-asid-ldapv3-protocol-01.txt. 239 June 1996. 241 [4] M. Wahl, S. Kille, T. Howes, A. Coulbeck, "Lightweight Directory Access 242 Protocol (v3): Standard and Pilot Attribute Definitions", INTERNET 243 DRAFT, draft-ietf-asid-ldapv3-attributes-01.txt. 244 June 1996. 246 [5] D. Crocker, "Standard of the Format of ARPA-Internet Text 247 Messages", STD 11, RFC 822, August 1982. 249 6. Security Considerations 251 Security issues are not discussed in this memo. 253 7. Author's Address 255 Mark Wahl 256 Critical Angle Inc. 257 4815 W. Braker Lane #502-385 258 Austin, TX 78759 259 USA 261 EMail: M.Wahl@critical-angle.com 263 Steve Kille 264 ISODE Consortium 265 The Dome 266 The Square 267 Richmond, Surrey 268 TW9 1DT 269 England 271 Phone: +44-181-332-9091 272 EMail: S.Kille@ISODE.COM