rfc2425.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                         T. Howes
Request for Comments: 2425                                    M. Smith
Category: Standards Track                Netscape Communications Corp.
                                                             F. Dawson
                                         Lotus Development Corporation
                                                        September 1998


             A MIME Content-Type for Directory Information

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.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

1.  Abstract

   This document defines a MIME Content-Type for holding directory
   information.  The definition is independent of any particular
   directory service or protocol.  The text/directory Content-Type is
   defined for holding a variety of directory information, for example,
   name, or email address, or logo. The text/directory Content-Type can
   also be used as the root body part in a multipart/related Content-
   Type for handling more complicated situations, especially those in
   which non-textual information that already has a natural MIME
   representation, for example, a photograph or sound, is to be
   represented.

   The text/directory Content-Type defines a general framework and
   format for holding directory information in a simple "type:value"
   form. We refer to "type" in this context meaning a property or
   attribute with which the value is associated. Mechanisms are defined
   to specify alternate languages, encodings and other meta-information.
   This document also defines the procedure by which particular formats,
   called profiles, for carrying application-specific information within
   a text/directory Content-Type can be defined and registered, and the
   conventions such formats must follow. It is expected that other
   documents will be produced that define such formats for various
   applications (e.g., white pages).





Howes, et. al.              Standards Track                     [Page 1]

RFC 2425      MIME Content-Type for Directory Information September 1998


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
   document are to be interpreted as described in [RFC-2119].

2.  Table of Contents

   Status of the Memo................................................ 1
   Copyright Notice.................................................. 1
   1.  Abstract...................................................... 1
   2.  Table of Contents............................................. 2
   3.  Need for a MIME Directory Type................................ 3
   4.  Overview...................................................... 4
   5.  The text/directory Content-Type............................... 4
   5.1.  MIME media type name........................................ 4
   5.2.  MIME subtype name........................................... 5
   5.3.  Required parameters......................................... 5
   5.4.  Optional parameters......................................... 5
   5.5.  Encoding considerations..................................... 5
   5.6.  Security considerations..................................... 6
   5.7.  Interoperability considerations............................. 6
   5.8.  Published specification..................................... 6
   5.8.1.  Line delimiting and folding............................... 6
   5.8.2.  ABNF content-type definition.............................. 7
   5.8.3.  Pre-defined Parameters.................................... 9
   5.8.4.  Pre-defined Value Types...................................11
   5.9.  Applications which use this media type......................14
   5.10.  Additional information.....................................14
   5.11.  Person & email address to contact for further information..14
   5.12.  Intended usage.............................................14
   5.13.  Author/Change controller...................................15
   6.  Predefined Types..............................................15
   6.1.  SOURCE Type Definition......................................15
   6.2.  NAME Type Definition........................................16
   6.3.  PROFILE Type Definition.....................................16
   6.4.  BEGIN Type Definition.......................................17
   6.5.  END Type Definition.........................................17
   7.  Use of the multipart/related Content-Type.....................18
   8. Examples.......................................................18
   8.1.  Example 1...................................................19
   8.2.  Example 2...................................................19
   8.3.  Example 3...................................................20
   8.4.  Example 4...................................................21
   9.  Registration of new profiles..................................22
   9.1.  Define the profile..........................................22
   9.2.  Post the profile definition.................................23
   9.3.  Allow a comment period......................................23
   9.4.  Submit the profile for approval.............................23
   10.  Profile Change Control.......................................23



Howes, et. al.              Standards Track                     [Page 2]

RFC 2425      MIME Content-Type for Directory Information September 1998


   11.  Registration of new types....................................24
   11.1.  Define the type............................................24
   11.2.  Post the type definition...................................25
   11.3.  Allow a comment period.....................................25
   11.4.  Submit the type for approval...............................25
   12.  Type Change Control..........................................25
   13.  Registration of new parameters...............................26
   13.1.  Define the parameter.......................................26
   13.2.  Post the parameter definition..............................27
   13.3.  Allow a comment period.....................................27
   13.4.  Submit the parameter for approval..........................27
   14.  Parameter Change Control.....................................28
   15.  Registration of new value types..............................28
   15.1.  Define the value type......................................28
   15.2.  Post the value type definition.............................29
   15.3.  Allow a comment period.....................................29
   15.4.  Submit the value type for approval.........................29
   16.  Security Considerations......................................30
   17. Acknowledgements..............................................30
   18. References....................................................30
   19.  Authors' Addresses...........................................32
   20. Full Copyright Statement......................................33

3.  Need for a MIME Directory Type

   For purposes of this document, a directory is a special-purpose
   database that contains typed information. A directory usually
   supports both read and search of the information it contains, and can
   support creation and modification of the information as well.
   Directory information is usually accessed far more often than it is
   updated.  Directories can be local or global in scope. They can be
   distributed or centralized. The information they contain can be
   replicated, with weak or strong consistency requirements.

   There are several situations in which users of Internet mail might
   wish to exchange directory information: the email analogy of a
   "business card" exchange; the conveyance of directory information to
   a user having only email access to the Internet; the provision of
   machine-parseable address information when purchasing goods or
   services over the Internet; etc.  As MIME [RFC-2045, RFC-2046] is
   used increasingly by other protocols, most notably HTTP, it can also
   be useful for these protocols to carry directory information in MIME
   format. Such a format, for example, could be used to represent URC
   (uniform resource characteristics) information about resources on the
   World Wide Web, or to provide a rudimentary directory service over
   HTTP.





Howes, et. al.              Standards Track                     [Page 3]

RFC 2425      MIME Content-Type for Directory Information September 1998


4.  Overview

   The scheme defined here for representing directory information in a
   MIME Content-Type has two parts. First, the text/directory Content-
   Type is defined for use in holding directory information within a
   single body part, for example name, title, or email address. In its
   simplest form, the format uses a "type:value" approach, which should
   be easily parseable by existing MIME implementations and
   understandable by users. More complicated situations can be
   represented also.  This document defines the general form the
   information in the Content-Type should have, and the procedure by
   which specific types and values (properties) for particular
   applications can be defined. The framework is general enough to
   handle information from any number of end directory services,
   including LDAP [RFC-1777, RFC-1778], WHOIS++ [RFC-1835], and X.500
   [X500].

   Directory entries can include far more than just textual information.
   Some such information (e.g., an image or sound) overlaps with
   predefined MIME Content-Types. In these cases it can be desirable to
   include the information in its well-known MIME format. This situation
   is handled by using a multipart/related Content-Type as defined in
   [RFC-2112].  The root component of this type is a text/directory body
   part specifying any in-line information, and for information
   contained in other Content-Types, the Content-IDs (in URI form) of
   those parts.

   In some applications, it can be useful to include a pointer (e.g, a
   URI) to some directory information rather than the information
   itself.  This document defines a general mechanism for accomplishing
   this.

5.  The text/directory Content-Type

   The text/directory Content-Type is used to hold basic directory
   information and URIs referencing other information, including other
   MIME body parts holding supplementary or non-textual directory
   information, such as an image or sound. It is defined as follows,
   using the MIME media type registration template from [RFC-2048].

   To: [e-mail]
   Subject: Registration of MIME media type text/directory

5.1.  MIME media type name

   MIME media type name: text





Howes, et. al.              Standards Track                     [Page 4]

RFC 2425      MIME Content-Type for Directory Information September 1998


5.2.  MIME subtype name

   MIME subtype name: directory

5.3.  Required parameters

   Required parameters: charset

   The "charset" parameter is as defined in [RFC-2046] for other body
   parts.  It is used to identify the default character set used within
   the body part.

5.4.  Optional parameters

   Optional parameters: profile

   The "profile" parameter is used to convey the type(s) of entity(ies)
   to which the directory information pertains and the likely set of
   information associated with the entity(ies). It is intended only as a
   guide to applications interpreting the information contained within
   the body part. It SHOULD NOT be used to exclude or require particular
   pieces of information unless a profile definition specifically calls
   for this behavior. Unless specifically forbidden by a particular
   profile definition, a text/directory content type can contain
   arbitrary attribute/value pairs.

   The value of the "profile" parameter is defined as follows.  Profile
   names are case insensitive (i.e., the profile name "vCard" is the
   same as "VCARD" and "vcard" and "vcArD").

         profile = x-name / iana-token

         x-name = "x-" 1*(ALPHA / DIGIT / "-")
             ; Names beginning with "x-" or "X-" are
             ; reserved for experimental use not intended for released
             ; products, or for use in bilateral agreements.

         iana-token = <a publicly-defined extension token, registered
                        with IANA, as specified in Section 9 of this
                        document>

5.5.  Encoding considerations

   The default encoding is 8bit. Otherwise, as specified by the
   Content-Transfer-Encoding header field.






Howes, et. al.              Standards Track                     [Page 5]

RFC 2425      MIME Content-Type for Directory Information September 1998


5.6.  Security considerations

   Directory information can be public or it can be protected from
   unauthorized access by the directory service in which it resides.
   Once the information leaves its native service, there can be no
   guarantee that the same care will be taken by all services handling
   the information.  Furthermore, this specification defines no access
   control mechanism by which information can be protected, or by which
   access control information can be conveyed.  Note that the integrity
   and privacy of a text/directory body part can be protected by
   enclosing it within an appropriate MIME-based security mechanism.

5.7.  Interoperability considerations

   In order to make sense of directory information, applications must
   share a common understanding of the types of information contained
   within the Content-Type (the directory schema).  This schema
   information is not defined in this document, but rather in companion
   documents (e.g., [MIME-VCARD]) that follow the requirements specified
   in this document, or in bilateral agreements between communicating
   parties.

5.8.  Published specification

   The text/directory Content-Type contains directory information,
   typically pertaining to a single directory entity or group of
   entities.  The content consists of one or more lines in the format
   given below.

5.8.1.  Line delimiting and folding

   Individual lines within the MIME text/directory Content Type body are
   delimited by the [RFC-822] line break, which is a CRLF sequence
   (ASCII decimal 13, followed by ASCII decimal 10). Long logical lines
   of text can be split into a multiple-physical-line representation
   using the following folding technique.

   A logical line MAY be continued on the next physical line anywhere
   between two characters by inserting a CRLF immediately followed by a
   single white space character (space, ASCII decimal 32, or horizontal
   tab, ASCII decimal 9).  At least one character must be present on the
   folded line. Any sequence of CRLF followed immediately by a single
   white space character is ignored (removed) when processing the
   content type.  For example the line:

   DESCRIPTION:This is a long description that exists on a long line.

   Can be represented as:



Howes, et. al.              Standards Track                     [Page 6]

RFC 2425      MIME Content-Type for Directory Information September 1998


   DESCRIPTION:This is a long description
     that exists on a long line.

   It could also be represented as:

   DESCRIPTION:This is a long descrip
    tion that exists o
    n a long line.

   The process of moving from this folded multiple-line representation
   of a type definition to its single line representation is called
   unfolding.  Unfolding is accomplished by regarding CRLF immediately
   followed by a white space character (namely HTAB ASCII decimal 9 or
   SPACE ASCII decimal 32) as equivalent to no characters at all (i.e.,
   the CRLF and single white space character are removed).

5.8.2.  ABNF content-type definition

   The following ABNF uses the notation of RFC 2234, which also defines
   CRLF, WSP, DQUOTE, VCHAR, ALPHA, and DIGIT.  After the unfolding of
   any folded lines as described above, the syntax for a line of this
   content type is as follows:

   contentline  = [group "."] name *(";" param) ":" value CRLF
      ; When parsing a content line, folded lines MUST first
      ; be unfolded according to the unfolding procedure
      ; described above.
      ; When generating a content line, lines longer than 75
      ; characters SHOULD be folded according to the folding