From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1778.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc1778.txt (limited to 'doc/rfc/rfc1778.txt') diff --git a/doc/rfc/rfc1778.txt b/doc/rfc/rfc1778.txt new file mode 100644 index 0000000..7d99b02 --- /dev/null +++ b/doc/rfc/rfc1778.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group T. Howes +Request for Comments: 1778 University of Michigan +Obsoletes: 1488 S. Kille +Category: Standards Track ISODE Consortium + W. Yeong + Performance Systems International + C. Robbins + NeXor Ltd. + March 1995 + + + The String Representation of Standard Attribute Syntaxes + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + The Lightweight Directory Access Protocol (LDAP) [9] requires that + the contents of AttributeValue fields in protocol elements be octet + strings. This document defines the requirements that must be + satisfied by encoding rules used to render X.500 Directory attribute + syntaxes into a form suitable for use in the LDAP, then goes on to + define the encoding rules for the standard set of attribute syntaxes + defined in [1,2] and [3]. + +1. Attribute Syntax Encoding Requirements. + + This section defines general requirements for lightweight directory + protocol attribute syntax encodings. All documents defining attribute + syntax encodings for use by the lightweight directory protocols are + expected to conform to these requirements. + + The encoding rules defined for a given attribute syntax must produce + octet strings. To the greatest extent possible, encoded octet + strings should be usable in their native encoded form for display + purposes. In particular, encoding rules for attribute syntaxes + defining non-binary values should produce strings that can be + displayed with little or no translation by clients implementing the + lightweight directory protocols. + + + + + + +Howes, Kille, Yeong & Robbins [Page 1] + +RFC 1778 Syntax Encoding March 1995 + + +2. Standard Attribute Syntax Encodings + + For the purposes of defining the encoding rules for the standard + attribute syntaxes, the following auxiliary BNF definitions will be + used: + + ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' | + 'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' | + 's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' | + 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' | + 'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' | + 'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z' + + ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' + + ::= | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | + 'A' | 'B' | 'C' | 'D' | 'E' | 'F' + + ::= | | '-' + +

::= | | ''' | '(' | ')' | '+' | ',' | '-' | '.' | + '/' | ':' | '?' | ' ' + + ::= The ASCII newline character with hexadecimal value 0x0A + + ::= | + + ::= | + + ::= | + + ::= | + + ::=

|

+ + ::= ' ' | ' ' + +2.1. Undefined + + Values of type Undefined are encoded as if they were values of type + Octet String, with the string value being the BER-encoded version of + the value. + +2.2. Case Ignore String + + A string of type caseIgnoreStringSyntax is encoded as the string + value itself. + + + + +Howes, Kille, Yeong & Robbins [Page 2] + +RFC 1778 Syntax Encoding March 1995 + + +2.3. Case Exact String + + The encoding of a string of type caseExactStringSyntax is the string + value itself. + +2.4. Printable String + + The encoding of a string of type printableStringSyntax is the string + value itself. + +2.5. Numeric String + + The encoding of a string of type numericStringSyntax is the string + value itself. + +2.6. Octet String + + The encoding of a string of type octetStringSyntax is the string + value itself. + +2.7. Case Ignore IA5 String + + The encoding of a string of type caseIgnoreIA5String is the string + value itself. + +2.8. IA5 String + + The encoding of a string of type iA5StringSyntax is the string value + itself. + +2.9. T61 String + + The encoding of a string of type t61StringSyntax is the string value + itself. + +2.10. Case Ignore List + + Values of type caseIgnoreListSyntax are encoded according to the + following BNF: + + ::= | + '$' + + ::= a string encoded according to the rules for Case + Ignore String as above. + + + + + + +Howes, Kille, Yeong & Robbins [Page 3] + +RFC 1778 Syntax Encoding March 1995 + + +2.11. Case Exact List + + Values of type caseExactListSyntax are encoded according to the + following BNF: + + ::= | + '$' + + ::= a string encoded according to the rules for Case + Exact String as above. + +2.12. Distinguished Name + + Values of type distinguishedNameSyntax are encoded to have the + representation defined in [5]. + +2.13. Boolean + + Values of type booleanSyntax are encoded according to the following + BNF: + + ::= "TRUE" | "FALSE" + + Boolean values have an encoding of "TRUE" if they are logically true, + and have an encoding of "FALSE" otherwise. + +2.14. Integer + + Values of type integerSyntax are encoded as the decimal + representation of their values, with each decimal digit represented + by the its character equivalent. So the digit 1 is represented by the + character + +2.15. Object Identifier + + Values of type objectIdentifierSyntax are encoded according to the + following BNF: + + ::= | '.' | + + ::= + + ::= | '.' + + In the above BNF, is the syntactic representation of an + object descriptor. When encoding values of type + objectIdentifierSyntax, the first encoding option should be used in + preference to the second, which should be used in preference to the + + + +Howes, Kille, Yeong & Robbins [Page 4] + +RFC 1778 Syntax Encoding March 1995 + + + third wherever possible. That is, in encoding object identifiers, + object descriptors (where assigned and known by the implementation) + should be used in preference to numeric oids to the greatest extent + possible. For example, in encoding the object identifier representing + an organizationName, the descriptor "organizationName" is preferable + to "ds.4.10", which is in turn preferable to the string "2.5.4.10". + +2.16. Telephone Number + + Values of type telephoneNumberSyntax are encoded as if they were + Printable String types. + +2.17. Telex Number + + Values of type telexNumberSyntax are encoded according to the + following BNF: + + ::= '$' '$' + + ::= + + ::= + + ::= + + In the above, is the syntactic representation of the + number portion of the TELEX number being encoded, is the + TELEX country code, and is the answerback code of a + TELEX terminal. + +2.18. Teletex Terminal Identifier + + Values of type teletexTerminalIdentifier are encoded according to the + following BNF: + + ::= 0*('$' ) + + ::= ':' + + ::= 'graphic' | 'control' | 'misc' | 'page' | 'private' + + ::= + + In the above, the first is the encoding of the + first portion of the teletex terminal identifier to be encoded, and + the subsequent 0 or more are subsequent portions + of the teletex terminal identifier. + + + + +Howes, Kille, Yeong & Robbins [Page 5] + +RFC 1778 Syntax Encoding March 1995 + + +2.19. Facsimile Telephone Number + + Values of type FacsimileTelephoneNumber are encoded according to the + following BNF: + + ::= [ '$' ] + + ::= | '$' + + ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' | + 'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed' + + In the above, the first is the actual fax number, + and the tokens represent fax parameters. + +2.20. Presentation Address + + Values of type PresentationAddress are encoded to have the + representation described in [6]. + +2.21. UTC Time + + Values of type uTCTimeSyntax are encoded as if they were Printable + Strings with the strings containing a UTCTime value. + +2.22. Guide (search guide) + + Values of type Guide, such as values of the searchGuide attribute, + are encoded according to the following BNF: + + ::= [ '#' ] + + ::= an encoded value of type objectIdentifierSyntax + + ::= | | '!' + + ::= [ '(' ] '&' [ ')' ] | + [ '(' ] '|' [ ')' ] + + ::= [ '(' ] '$' [ ')' ] + + ::= "EQ" | "SUBSTR" | "GE" | "LE" | "APPROX" + + + + + + + + + +Howes, Kille, Yeong & Robbins [Page 6] + +RFC 1778 Syntax Encoding March 1995 + + +2.23. Postal Address + + Values of type PostalAddress are encoded according to the following + BNF: + + ::= | '$' + + In the above, each component of a postal address value is + encoded as a value of type t61StringSyntax. + +2.24. User Password + + Values of type userPasswordSyntax are encoded as if they were of type + octetStringSyntax. + +2.25. User Certificate + + Values of type userCertificate are encoded according to the following + BNF: + + ::= '#' '#' + '#' '#' '#' + '#' '#' + + ::= + + ::= + + ::= + + ::= an encoded Distinguished Name + + ::= '#' + + ::= + + ::= + + ::= | | + '{ASN}' + + ::= an encoded Distinguished Name + + ::= '#' + + ::= | '-' + + ::= '#' + + + +Howes, Kille, Yeong & Robbins [Page 7] + +RFC 1778 Syntax Encoding March 1995 + + + ::= an encoded UTCTime value + + ::= | + +2.26. CA Certificate + + Values of type cACertificate are encoded as if the values were of + type userCertificate. + +2.27. Authority Revocation List + + Values of type authorityRevocationList are encoded according to the + following BNF: + + ::= '#' '#' + [ '#' ] + '#' + '#' + + ::= 1*( '#' ) + '#' + + ::= '#' '#' + '#' + + The syntactic components , , + , , and have the + same definitions as in the BNF for the userCertificate attribute + syntax. + +2.28. Certificate Revocation List + + Values of type certificateRevocationList are encoded as if the values + were of type authorityRevocationList. + +2.29. Cross Certificate Pair + + Values of type crossCertificatePair are encoded according to the + following BNF: + + ::= '#' + | + | + + ::= 'forward:' + + ::= 'reverse:' + + + + +Howes, Kille, Yeong & Robbins [Page 8] + +RFC 1778 Syntax Encoding March 1995 + + + The syntactic component has the same definition as in + the BNF for the userCertificate attribute syntax. + +2.30. Delivery Method + + Values of type deliveryMethod are encoded according to the following + BNF: + + ::= | '$' + + ::= 'any' | 'mhs' | 'physical' | 'telex' | 'teletex' | + 'g3fax' | 'g4fax' | 'ia5' | 'videotex' | 'telephone' + +2.31. Other Mailbox + + Values of the type otherMailboxSyntax are encoded according to the + following BNF: + + ::= '$' + + ::= an encoded Printable String + + ::= an encoded IA5 String + + In the above, represents the type of mail system in + which the mailbox resides, for example "Internet" or "MCIMail"; and + is the actual mailbox in the mail system defined by + . + +2.32. Mail Preference + + Values of type mailPreferenceOption are encoded according to the + following BNF: + + ::= "NO-LISTS" | "ANY-LIST" | "PROFESSIONAL-LISTS" + +2.33. MHS OR Address + + Values of type MHS OR Address are encoded as strings, according to + the format defined in [10]. + + + + + + + + + + + +Howes, Kille, Yeong & Robbins [Page 9] + +RFC 1778 Syntax Encoding March 1995 + + +2.34. Distribution List Submit Permission + + Values of type DLSubmitPermission are encoded as strings, according + to the following BNF: + + ::= ':' + | ':' + + ::= 'group_member' + + ::= + + ::= an encoded Distinguished Name + + ::= 'individual' | 'dl_member' | 'pattern' + + ::= + + ::=

'#' + |
+ +
::= ':' + + ::= ':' + + = 'X400' + + = 'X500' + + where is as defined in RFC 1327. + +2.35. Photo + + Values of type Photo are encoded as if they were octet strings + containing JPEG images in the JPEG File Interchange Format (JFIF), as + described in [8]. + +2.36. Fax + + Values of type Fax are encoded as if they were octet strings + containing Group 3 Fax images as defined in [7]. + + + + + + + + + + +Howes, Kille, Yeong & Robbins [Page 10] + +RFC 1778 Syntax Encoding March 1995 + + +3. Security Considerations + + Security issues are not discussed in this memo. + +4. Acknowledgements + + Many of the attribute syntax encodings defined in this document are + adapted from those used in the QUIPU X.500 implementation. The + contributions of the authors of the QUIPU implementation in the + specification of the QUIPU syntaxes [4] are gratefully acknowledged. + +5. Bibliography + + [1] The Directory: Selected Attribute Syntaxes. CCITT, + Recommendation X.520. + + [2] Information Processing Systems -- Open Systems Interconnection -- + The Directory: Selected Attribute Syntaxes. + + [3] Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema", + RFC 1274, University College London, November 1991. + + [4] The ISO Development Environment: User's Manual -- Volume 5: + QUIPU. Colin Robbins, Stephen E. Kille. + + [5] Kille, S., "A String Representation of Distinguished Names", RFC + 1779, ISODE Consortium, March 1995. + + [6] Kille, S., "A String Representation for Presentation Addresses", + RFC 1278, University College London, November 1991. + + [7] Terminal Equipment and Protocols for Telematic Services - + Standardization of Group 3 facsimile apparatus for document + transmission. CCITT, Recommendation T.4. + + [8] JPEG File Interchange Format (Version 1.02). Eric Hamilton, C- + Cube Microsystems, Milpitas, CA, September 1, 1992. + + [9] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access + Protocol", RFC 1777, Performance Systems International, + University of Michigan, ISODE Consortium, March 1995. + + [10] Alvestrand, H., Kille, S., Miles, R., Rose, M., and S. Thompson, + "Mapping between X.400 and RFC-822 Message Bodies", RFC 1495, + SINTEF DELAB, ISODE Consortium, Soft*Switch, Inc., Dover Beach + Consulting, Inc., Soft*Switch, Inc., August 1993. + + + + + +Howes, Kille, Yeong & Robbins [Page 11] + +RFC 1778 Syntax Encoding March 1995 + + +6. Authors' Addresses + + Tim Howes + University of Michigan + ITD Research Systems + 535 W William St. + Ann Arbor, MI 48103-4943 + USA + + Phone: +1 313 747-4454 + EMail: tim@umich.edu + + + Steve Kille + ISODE Consortium + PO Box 505 + London + SW11 1DX + UK + + Phone: +44-71-223-4062 + EMail: S.Kille@isode.com + + + Wengyik Yeong + PSI Inc. + 510 Huntmar Park Drive + Herndon, VA 22070 + USA + + Phone: +1 703-450-8001 + EMail: yeongw@psilink.com + + + Colin Robbins + NeXor Ltd + University Park + Nottingham + NG7 2RD + UK + + + + + + + + + + + +Howes, Kille, Yeong & Robbins [Page 12] + -- cgit v1.2.3