idnits 2.17.1 draft-ietf-osids-syntaxes-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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) 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 6 months document validity. ** 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. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 an Authors' Addresses Section. ** There are 8 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([3], [4], [1,2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 415 looks like a reference -- Missing reference section? '2' on line 418 looks like a reference -- Missing reference section? '3' on line 421 looks like a reference -- Missing reference section? '4' on line 424 looks like a reference -- Missing reference section? '5' on line 427 looks like a reference -- Missing reference section? '6' on line 430 looks like a reference Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Tim Howes 2 INTERNET-DRAFT University of Michigan 3 Steve Hardcastle-Kille 4 University College London 5 Wengyik Yeong 6 Performance Systems International 7 Colin Robbins 8 X-Tel Services Ltd. 10 The String Representation of Standard Attribute Syntaxes 12 1. Status of this Memo 14 This draft document will be submitted to the RFC Editor as a standards 15 document. Distribution of this memo is unlimited. Please send comments 16 to the authors, or the discussion group . 18 This document is an Internet Draft. Internet Drafts are working docu- 19 ments of the Internet Engineering Task Force (IETF), its Areas, and its 20 Working Groups. Note that other groups may also distribute working docu- 21 ments as Internet Drafts). 23 Internet Drafts are draft documents valid for a maximum of six months. 24 Internet Drafts may be updated, replaced, or obsoleted by other docu- 25 ments at any time. It is not appropriate to use Internet Drafts as 26 reference material or to cite them other than as a "working draft" or 27 "work in progress." 29 Please check the I-D abstract listing contained in each Internet Draft 30 directory to learn the current status of this or any other Internet 31 Draft. 33 2. Abstract 35 The lightweight directory protocols require that the contents of Attri- 36 buteValue fields in protocol elements be octet strings. This document 37 defines the requirements that must be satisfied by encoding rules used 38 to render Directory attribute syntaxes into a form suitable for use in 39 the lightweight directory protocols, then goes on to define the encoding 40 rules for the standard set of attribute syntaxes defined in [1,2] and 41 [3]. 43 The attribute syntax encodings defined in this document are adapted from 44 those used in the QUIPU X.500 implementation. The contributions of the 45 authors of the QUIPU implementation in the specification of the QUIPU 46 syntaxes [4] are gratefully acknowledged. 48 3. Attribute Syntax Encoding Requirements. 50 This section defines general requirements for lightweight directory pro- 51 tocol attribute syntax encodings. All documents defining attribute syn- 52 tax encodings for use by the lightweight directory protocols are 53 expected to conform to these requirements. 55 The encoding rules defined for a given attribute syntax must produce 56 octet strings. To the greatest extent possible, encoded octet strings 57 should be usable in their native encoded form for display purposes. In 58 particular, encoding rules for attribute syntaxes defining non-binary 59 values should produce strings that can be displayed with little or no 60 translation by clients implementing the lightweight directory protocols. 62 4. Standard Attribute Syntax Encodings 64 For the purposes of defining the encoding rules for the standard attri- 65 bute syntaxes, the following auxiliary BNF definitions will be used: 67 ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' | 68 'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' | 69 's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' | 70 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' | 71 'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' | 72 'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z' 74 ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' 76 ::= | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 77 'A' | 'B' | 'C' | 'D' | 'E' | 'F' 79 ::= | '-' 81

::= | | ''' | '(' | ')' | '+' | ',' | '-' | '.' | 82 '/' | ':' | '?' | ' ' 84 ::= The ASCII newline character with hexadecimal value 0x0A 86 ::= | 88 ::= | 90 ::= | 92 ::=

|

93 ::= ' ' | ' ' 95 4.1. Undefined 97 Values of type Undefined are encoded as if they were values of type 98 Octet String. 100 4.2. Case Ignore String 102 A string of type caseIgnoreStringSyntax is encoded as the string value 103 itself. 105 4.3. Case Exact String 107 The encoding of a string of type caseExactStringSyntax is the string 108 value itself. 110 4.4. Printable String 112 The encoding of a string of type printableStringSyntax is the string 113 value itself. 115 4.5. Numeric String 117 The encoding of a string of type numericStringSyntax is the string value 118 itself. 120 4.6. Octet String 122 The encoding of a string of type octetStringSyntax is the string value 123 itself. 125 4.7. Case Ignore IA5 String 127 The encoding of a string of type caseIgnoreIA5String is the string value 128 itself. 130 4.8. IA5 String 132 The encoding of a string of type iA5StringSyntax is the string value 133 itself. 135 4.9. T61 String 137 The encoding of a string of type t61StringSyntax is the string value 138 itself. 140 4.10. Case Ignore List 142 Values of type caseIgnoreListSyntax are encoded according to the follow- 143 ing BNF: 145 ::= | 146 '$' 148 ::= a string encoded according to the rules for Case 149 Ignore String as above. 151 4.11. Case Exact List 153 Values of type caseExactListSyntax are encoded according to the follow- 154 ing BNF: 156 ::= | 157 '$' 159 ::= a string encoded according to the rules for Case 160 Exact String as above. 162 4.12. Distinguished Name 164 Values of type distinguishedNameSyntax are encoded to have the represen- 165 tation defined in [5]. 167 4.13. Boolean 169 Values of type booleanSyntax are encoded according to the following BNF: 171 ::= "TRUE" | "FALSE" 173 Boolean values have an encoding of "TRUE" if they are logically true, 174 and have an encoding of "FALSE" otherwise. 176 4.14. Integer 178 Values of type integerSyntax are encoded as the decimal representation 179 of their values, with each decimal digit represented by the its charac- 180 ter equivalent. So the digit 1 is represented by the character '1', the 181 digit 2 is represented by the character '2' and so on. 183 4.15. Object Identifier 185 Values of type objectIdentifierSyntax are encoded according to the 186 following BNF: 188 ::= | '.' | 190 ::= 192 ::= | '.' 194 In the above BNF, is the syntactic representation of an object 195 descriptor. When encoding values of type objectIdentifierSyntax, the 196 first encoding option should be used in preference to the second, which 197 should be used in preference to the third wherever possible. That is, in 198 encoding object identifiers, object descriptors (where assigned and 199 known by the implementation) should be used in preference to numeric 200 oids to the greatest extent possible. For example, in encoding the 201 object identifier representing an organizationName, the descriptor 202 ``organizationName'' is preferable to ``ds.4.10'', which is in turn 203 preferable to the string ``2.5.4.10''. 205 4.16. Telephone Number 207 Values of type telephoneNumberSyntax are encoded as if they were Print- 208 able String types. 210 4.17. Telex Number 212 Values of type telexNumberSyntax are encoded according to the following 213 BNF: 215 ::= '$' '$' 217 ::= 219 ::= 221 ::= 223 In the above, is the syntactic representation of the number 224 portion of the TELEX number being encoded, is the TELEX 225 country code, and is the answerback code of a TELEX terminal. 227 4.18. Teletex Terminal Identifier 229 Values of type teletexTerminalIdentifier are encoded according to the 230 following BNF: 232 ::= 0*( '$' ) 234 In the above, the first is the encoding of the first 235 portion of the teletex terminal identifier to be encoded, and the subse- 236 quent 0 or more are subsequent portions of the 237 teletex terminal identifier. 239 4.19. Facsimile Telephone Number 241 Values of type FacsimileTelephoneNumber are encoded according to the 242 following BNF: 244 ::= [ '$' ] 246 ::= | '$' 248 ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' | 249 'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed' 251 In the above, the first is the actual fax number, and 252 the tokens represent fax parameters. 254 4.20. Presentation Address 256 Values of type PresentationAddress are encoded to have the representa- 257 tion described in [6]. 259 4.21. UTC Time 261 Values of type uTCTimeSyntax are encoded as if they were Printable 262 Strings with the strings containing a UTCTime value. 264 4.22. Guide (search guide) 266 Values of type Guide, such as values of the searchGuide attribute, are 267 encoded according to the following BNF: 269 ::= [ '#' ] 271 ::= an encoded value of type objectIdentifierSyntax 273 ::= | | '!' 275 ::= [ '(' ] '&' [ ')' ] | 276 [ '(' ] '|' [ ')' ] 278 ::= [ '(' ] '$' [ ')' ] 280 ::= "EQ" | "SUBSTR" | "GE" | "LE" | "APPROX" 282 4.23. Postal Address 284 Values of type PostalAddress are encoded according to the following BNF: 286 ::= | '$' 288 In the above, each component of a postal address value is 289 encoded as a value of type t61StringSyntax. 291 4.24. User Password 293 Values of type userPasswordSyntax are encoded as if they were of type 294 octetStringSyntax. 296 4.25. User Certificate 298 Values of type userCertificate are encoded according to the following 299 BNF: 301 ::= '#' '#' '#' 302 '#' 304 ::= 306 ::= an encoded Distinguished Name 308 ::= '#' 310 ::= 312 ::= 314 ::= | | 315 '{ASN}' 317 ::= an encoded Distinguished Name 319 ::= '#' 321 ::= | '-' 323 ::= '#' 325 ::= an encoded UTCTime value 327 ::= | 329 4.26. CA Certificate 331 Values of type cACertificate are encoded as if the values were of type 332 userCertificate. 334 4.27. Authority Revocation List 336 Values of type authorityRevocationList are encoded according to the fol- 337 lowing BNF: 339 ::= '#' '#' 340 [ '#' ] 342 ::= '#' 343 [ '#' 0*() '#'] 345 ::= '#' '#' 346 '#' 348 The syntactic components , , , 349 , and have the same definitions as in the 350 BNF for the userCertificate attribute syntax. 352 4.28. Certificate Revocation List 354 Values of type certificateRevocationList are encoded as if the values 355 were of type authorityRevocationList. 357 4.29. Cross Certificate Pair 359 Values of type crossCertificatePair are encoded according to the follow- 360 ing BNF: 362 ::= '|' 364 The syntactic component has the same definition as in the 365 BNF for the userCertificate attribute syntax. 367 4.30. Delivery Method 369 Values of type deliveryMethod are encoded according to the following 370 BNF: 372 ::= | '$' 374 ::= 'any' | 'mhs' | 'physical' | 'telex' | 'teletex' | 375 'g3fax' | 'g4fax' | 'ia5' | 'videotex' | 'telephone' 377 4.31. Other Mailbox 379 Values of the type otherMailboxSyntax are encoded according to the fol- 380 lowing BNF: 382 ::= '$' 384 ::= an encoded Printable String 386 ::= an encoded IA5 String 388 In the above, represents the type of mail system in which 389 the mailbox resides, for example "Internet" or "MCIMail"; and 390 is the actual mailbox in the mail system defined by . 392 4.32. Mail Preference 394 Values of type mailPreferenceOption are encoded according to the follow- 395 ing BNF: 397 ::= "NO-LISTS" | "ANY-LIST" | "PROFESSIONAL-LISTS" 399 4.33. Photo 401 Values of type Photo are encoded as if they were octet strings contain- 402 ing JPEG images in the JPEG File Interchange Format (JFIF). 404 4.34. Fax 406 Values of type Fax are encoded as if they were octet strings containing 407 Group 3 Fax images. 409 5. Security Considerations 411 Security considerations are not discussed in this document. 413 6. Bibliography 415 [1] The Directory: Selected Attribute Syntaxes 416 CCITT; Recommendation X.520 418 [2] Information Processing Systems -- Open Systems Interconnection -- 419 The Directory: Selected Attribute Syntaxes 421 [3] The COSINE and Internet X.500 Schema 422 Paul Barker, Steve Hardcastle-Kille; Request for Comment (RFC) 1274 424 [4] The ISO Development Environment: User's Manual -- Volume 5: QUIPU 425 Colin Robbins, Stephen E. Hardcastle-Kille 427 [5] A String Representation of Distinguished Names 428 Steve Hardcastle-Kille; OSI-DS document 23 430 [6] A String Representation for Presentation Addresses 431 Steve Hardcastle-Kille; Request for Comment (RFC) 1278