From: Kurt Zeilenga Date: Mon, 22 Nov 1999 01:39:33 +0000 (+0000) Subject: Obsoleted by RFC 1778 X-Git-Tag: UCDATA_2_4~182 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=788fa66435d060ff380b99a26668942cd079c1c6;p=openldap Obsoleted by RFC 1778 --- diff --git a/doc/rfc/rfc1488.txt b/doc/rfc/rfc1488.txt deleted file mode 100644 index ecafe75bfd..0000000000 --- a/doc/rfc/rfc1488.txt +++ /dev/null @@ -1,619 +0,0 @@ - - - - - - -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] - -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' | '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. - -2.2. Case Ignore String - - A string of type caseIgnoreStringSyntax is encoded as the string - value itself. - - - - - -Howes, Kille, Yeong & Robbins [Page 2] - -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: - - ::= | - '$' - - ::= a string encoded according to the rules - for Case Ignore String as above. - - - - - - -Howes, Kille, Yeong & Robbins [Page 3] - -RFC 1488 X.500 Syntax Encoding July 1993 - - -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 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: - - ::= '$' '$' - - ::= - - ::= - - ::= - - 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*( '$' ) - - 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. - -2.19. Facsimile Telephone Number - - Values of type FacsimileTelephoneNumber are encoded according to the - following BNF: - - ::= [ '$' ] - - - -Howes, Kille, Yeong & Robbins [Page 5] - -RFC 1488 X.500 Syntax Encoding July 1993 - - - ::= | '$' - - ::= '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" - -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. - - - - - - - -Howes, Kille, Yeong & Robbins [Page 6] - -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: - - ::= '#' '#' '#' - '#' - - ::= - - ::= an encoded Distinguished Name - - ::= '#' - - ::= - - ::= - - ::= | | - '{ASN}' - - ::= an encoded Distinguished Name - - ::= '#' - - ::= | '-' - - ::= '#' - - ::= 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: - - - - -Howes, Kille, Yeong & Robbins [Page 7] - -RFC 1488 X.500 Syntax Encoding July 1993 - - - ::= '#' '#' - [ '#' ] - - ::= '#' - [ '#' 0*() '#'] - - ::= '#' '#' - '#' - - 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: - - ::= '|' - - 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 - - - -Howes, Kille, Yeong & Robbins [Page 8] - -RFC 1488 X.500 Syntax Encoding July 1993 - - - 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]. - -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] - -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] - -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] - \ No newline at end of file