💾 Archived View for radia.bortzmeyer.org › rfc-mirror › rfc1778.txt captured on 2024-05-10 at 19:50:37.
⬅️ Previous capture (2023-06-14)
-=-=-=-=-=-=-
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> ::= '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, 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: <caseignorelist> ::= <caseignorestring> | <caseignorestring> '