--- /dev/null
+
+
+
+
+
+
+Network Working Group T. Howes
+Request for Comments: 1488 University of Michigan
+ S. Kille
+ ISODE Consortium
+ W. Yeong
+ Performance Systems International
+ C. Robbins
+ NeXor Ltd.
+ July 1993
+
+
+ The X.500 String Representation of Standard Attribute Syntaxes
+
+Status of this Memo
+
+ This RFC specifies an IAB standards track protocol for the Internet
+ community, and requests discussion and suggestions for improvements.
+ Please refer to the current edition of the "IAB Official Protocol
+ Standards" 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 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]
+\f
+RFC 1488 X.500 Syntax Encoding July 1993
+
+
+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> ::= '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'
+
+ <d> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
+
+ <hex-digit> ::= <d> | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' |
+ 'A' | 'B' | 'C' | 'D' | 'E' | 'F'
+
+ <k> ::= <a> | <d> | '-'
+
+ <p> ::= <a> | <d> | ''' | '(' | ')' | '+' | ',' | '-' | '.' |
+ '/' | ':' | '?' | ' '
+
+ <CRLF> ::= The ASCII newline character with hexadecimal value 0x0A
+
+ <letterstring> ::= <a> | <a> <letterstring>
+
+ <numericstring> ::= <d> | <d> <numericstring>
+
+ <keystring> ::= <a> | <a> <anhstring>
+
+ <anhstring> ::= <k> | <k> <anhstring>
+
+ <printablestring> ::= <p> | <p> <printablestring>
+
+ <space> ::= ' ' | ' ' <space>
+
+2.1. Undefined
+
+ Values of type Undefined are encoded as if they were values of type
+ Octet String.
+
+2.2. Case Ignore String
+
+ A string of type caseIgnoreStringSyntax is encoded as the string
+ value itself.
+
+
+
+
+
+Howes, Kille, Yeong & Robbins [Page 2]
+\f
+RFC 1488 X.500 Syntax Encoding July 1993
+
+
+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:
+
+ <caseignorelist> ::= <caseignorestring> |
+ <caseignorestring> '$' <caseignorelist>
+
+ <caseignorestring> ::= a string encoded according to the rules
+ for Case Ignore String as above.
+
+
+
+
+
+
+Howes, Kille, Yeong & Robbins [Page 3]
+\f
+RFC 1488 X.500 Syntax Encoding July 1993
+
+
+2.11. Case Exact List
+
+ Values of type caseExactListSyntax are encoded according to the
+ following BNF:
+
+ <caseexactlist> ::= <caseexactstring> |
+ <caseexactstring> '$' <caseexactlist>
+
+ <caseexactstring> ::= 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:
+
+ <boolean> ::= "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:
+
+ <oid> ::= <descr> | <descr> '.' <numericoid> | <numericoid>
+
+ <descr> ::= <keystring>
+
+ <numericoid> ::= <numericstring> | <numericstring> '.' <numericoid>
+
+ In the above BNF, <descr> 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]
+\f
+RFC 1488 X.500 Syntax Encoding July 1993
+
+
+ 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:
+
+ <telex-number> ::= <actual-number> '$' <country> '$' <answerback>
+
+ <actual-number> ::= <printablestring>
+
+ <country> ::= <printablestring>
+
+ <answerback> ::= <printablestring>
+
+ In the above, <actual-number> is the syntactic representation of the
+ number portion of the TELEX number being encoded, <country> is the
+ TELEX country code, and <answerback> is the answerback code of a
+ TELEX terminal.
+
+2.18. Teletex Terminal Identifier
+
+ Values of type teletexTerminalIdentifier are encoded according to the
+ following BNF:
+
+ <teletex-id> ::= <printablestring> 0*( '$' <printablestring>)
+
+ In the above, the first <printablestring> is the encoding of the
+ first portion of the teletex terminal identifier to be encoded, and
+ the subsequent 0 or more <printablestrings> are subsequent portions
+ of the teletex terminal identifier.
+
+2.19. Facsimile Telephone Number
+
+ Values of type FacsimileTelephoneNumber are encoded according to the
+ following BNF:
+
+ <fax-number> ::= <printablestring> [ '$' <faxparameters> ]
+
+
+
+Howes, Kille, Yeong & Robbins [Page 5]
+\f
+RFC 1488 X.500 Syntax Encoding July 1993
+
+
+ <faxparameters> ::= <faxparm> | <faxparm> '$' <faxparameters>
+
+ <faxparm> ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' |
+ 'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed'
+
+ In the above, the first <printablestring> is the actual fax number,
+ and the <faxparm> 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:
+
+ <guide-value> ::= [ <object-class> '#' ] <criteria>
+
+ <object-class> ::= an encoded value of type objectIdentifierSyntax
+
+ <criteria> ::= <criteria-item> | <criteria-set> | '!' <criteria>
+
+ <criteria-set> ::= [ '(' ] <criteria> '&' <criteria-set> [ ')' ] |
+ [ '(' ] <criteria> '|' <criteria-set> [ ')' ]
+
+ <criteria-item> ::= [ '(' ] <attributetype> '$' <match-type> [ ')' ]
+
+ <match-type> ::= "EQ" | "SUBSTR" | "GE" | "LE" | "APPROX"
+
+2.23. Postal Address
+
+Values of type PostalAddress are encoded according to the following BNF:
+
+ <postal-address> ::= <t61string> | <t61string> '$' <postal-address>
+
+ In the above, each <t61string> component of a postal address value is
+ encoded as a value of type t61StringSyntax.
+
+
+
+
+
+
+
+Howes, Kille, Yeong & Robbins [Page 6]
+\f
+RFC 1488 X.500 Syntax Encoding July 1993
+
+
+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:
+
+ <certificate> ::= <signature> '#' <issuer> '#' <validity> '#' <subject>
+ '#' <public-key-info>
+
+ <signature> ::= <algorithm-id>
+
+ <issuer> ::= an encoded Distinguished Name
+
+ <validity> ::= <not-before-time> '#' <not-after-time>
+
+ <not-before-time> ::= <utc-time>
+
+ <not-after-time> ::= <utc-time>
+
+ <algorithm-parameters> ::= <null> | <integervalue> |
+ '{ASN}' <hex-string>
+
+ <subject> ::= an encoded Distinguished Name
+
+ <public-key-info> ::= <algorithm-id> '#' <encrypted-value>
+
+ <encrypted-value> ::= <hex-string> | <hex-string> '-' <d>
+
+ <algorithm-id> ::= <oid> '#' <algorithm-parameters>
+
+ <utc-time> ::= an encoded UTCTime value
+
+ <hex-string> ::= <hex-digit> | <hex-digit> <hex-string>
+
+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:
+
+
+
+
+Howes, Kille, Yeong & Robbins [Page 7]
+\f
+RFC 1488 X.500 Syntax Encoding July 1993
+
+
+ <certificate-list> ::= <signature> '#' <issuer> '#'
+ <utc-time> [ '#' <revoked-certificates> ]
+
+ <revoked-certificates> ::= <algorithm> '#' <encrypted-value>
+ [ '#' 0*(<revoked-certificate>) '#']
+
+ <revoked-certificates> ::= <subject> '#' <algorithm> '#'
+ <serial> '#' <utc-time>
+
+ The syntactic components <algorithm>, <issuer>, <encrypted-value>,
+ <utc-time>, <subject> and <serial> 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:
+
+ <certificate-pair> ::= <certificate> '|' <certificate>
+
+ The syntactic component <certificate> 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:
+
+ <delivery-value> ::= <pdm> | <pdm> '$' <delivery-value>
+
+ <pdm> ::= '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:
+
+ <otherMailbox> ::= <mailbox-type> '$' <mailbox>
+
+ <mailbox-type> ::= an encoded Printable String
+
+ <mailbox> ::= an encoded IA5 String
+
+
+
+Howes, Kille, Yeong & Robbins [Page 8]
+\f
+RFC 1488 X.500 Syntax Encoding July 1993
+
+
+ In the above, <mailbox-type> represents the type of mail system in
+ which the mailbox resides, for example "Internet" or "MCIMail"; and
+ <mailbox> is the actual mailbox in the mail system defined by
+ <mailbox-type>.
+
+2.32. Mail Preference
+
+ Values of type mailPreferenceOption are encoded according to the
+ following BNF:
+
+ <mail-preference> ::= "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].
+
+2.34. 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.35. Fax
+
+ Values of type Fax are encoded as if they were octet strings
+ containing Group 3 Fax images as defined in [7].
+
+3. Acknowledgements
+
+ Many of the attribute syntax encodings defined in this document are
+ adapted from those used in the QUIPU X.500 implementation. The
+ contribu- tions of the authors of the QUIPU implementation in the
+ specification of the QUIPU syntaxes [4] are gratefully acknowledged.
+
+4. 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.
+
+
+
+Howes, Kille, Yeong & Robbins [Page 9]
+\f
+RFC 1488 X.500 Syntax Encoding July 1993
+
+
+ [5] Kille, S., "A String Representation of Distinguished Names", RFC
+ 1485, July 1993.
+
+ [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 1487, Performance Systems International,
+ University of Michigan, ISODE Consortium, July 1993.
+
+ [10] Kille, S., "Mapping between X.400(1988)/ISO 10021 and RFC 822",
+ RFC 1327, University College London, May 1992.
+
+5. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Howes, Kille, Yeong & Robbins [Page 10]
+\f
+RFC 1488 X.500 Syntax Encoding July 1993
+
+
+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 11]
+\f
\ No newline at end of file
projects / openldap / commitdiff