doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

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> ::= '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> '$' <caseignorelist>
+
+<caseignorestring> ::= 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:
+
+<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]
+
+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:
+
+     <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*('$' <ttx-parm>)
+
+     <ttx-param> ::= <ttx-key> ':' <ttx-value>
+
+     <ttx-key> ::= 'graphic' | 'control' | 'misc' | 'page' | 'private'
+
+     <ttx-value> ::= <octetstring>
+
+   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.
+
+
+
+
+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:
+
+<fax-number> ::= <printablestring> [ '$' <faxparameters> ]
+
+<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"
+
+
+
+
+
+
+
+
+
+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:
+
+     <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.
+
+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> ::= <version> '#' <serial> '#' <signature-algorithm-id>
+                     '#' <issuer> '#' <validity> '#' <subject>
+                     '#' <public-key-info> '#' <encrypted-sign-value>
+
+     <version> ::= <integervalue>
+
+     <serial> ::= <integervalue>
+
+     <signature-algorithm-id> ::= <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-sign-value>
+
+     <encrypted-sign-value> ::= <hex-string> | <hex-string> '-' <d>
+
+     <algorithm-id> ::= <oid> '#' <algorithm-parameters>
+
+
+
+Howes, Kille, Yeong & Robbins                                   [Page 7]
+
+RFC 1778                    Syntax Encoding                   March 1995
+
+
+     <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:
+
+<certificate-list> ::= <signature-algorithm-id> '#' <issuer> '#' <utc-time>
+                        [ '#' <revoked-certificates> ]
+                        '#' <signature-algorithm-id>
+                        '#' <encrypted-sign-value>
+
+<revoked-certificates> ::= 1*( '#' <revoked-certificate> )
+                        <signature-algorithm-id> '#' <encrypted-sign-value>
+
+<revoked-certificate> ::= <signature-algorithm-id> '#' <issuer> '#'
+                        <serial> '#' <utc-time>
+
+   The syntactic components <signature-algorithm-id>, <issuer>,
+   <encrypted-sign-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> ::= <forward> '#' <reverse>
+                             | <forward>
+                             | <reverse>
+
+     <forward> ::= 'forward:' <certificate>
+
+     <reverse> ::= 'reverse:' <certificate>
+
+
+
+
+Howes, Kille, Yeong & Robbins                                   [Page 8]
+
+RFC 1778                    Syntax Encoding                   March 1995
+
+
+   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
+
+   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].
+
+
+
+
+
+
+
+
+
+
+
+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:
+
+     <dlsubmit-perm> ::= <dlgroup_label> ':' <dlgroup-value>
+                             | <dl-label> ':' <dl-value>
+
+     <dlgroup-label> ::= 'group_member'
+
+     <dlgroup-value> ::= <name>
+
+     <name> ::= an encoded Distinguished Name
+
+     <dl-label> ::= 'individual' | 'dl_member' | 'pattern'
+
+     <dl-value> ::= <orname>
+
+     <orname> ::= <address> '#' <dn>
+            |  <address>
+
+     <address> ::= <add-label> ':' <oraddress>
+
+     <dn> ::= <dn-label> ':' <name>
+
+     <add-label> = 'X400'
+
+     <dn-label> = 'X500'
+
+   where <oraddress> 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]
+