rfc2425.txt

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

   "float": The "float" value type is used to express real numbers.  If
   sign is not specified, the value is assumed positive "+". Multiple
   "float" values can be specified using the comma-separated notation,
   unless restricted by a profile.

       Examples: 20.30
                 1000000.0000001
                 1.333,3.14

5.9.  Applications which use this media type

   Applications which use this media type: Various

5.10.  Additional information

   Additional information: None

5.11.  Person & email address to contact for further information

   Tim Howes
   Netscape Communications Corp.
   501 East Middlefield Rd.
   Mountain View, CA 94041
   USA
   [e-mail]
   [phone]

5.12.  Intended usage

   Intended usage: COMMON












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


5.13.  Author/Change controller

   Tim Howes
   Netscape Communications Corp.
   501 East Middlefield Rd.
   Mountain View, CA 94041
   USA
   [e-mail]
   [phone]

   Mark Smith
   Netscape Communications Corp.
   501 East Middlefield Rd.
   Mountain View, CA 94041
   USA
   [e-mail]
   [phone]

   Frank Dawson
   Lotus Development Corporation
   6544 Battleford Drive
   Raleigh, NC 27613-3502
   USA
   [e-mail]
   [phone]

6.  Predefined Types

   The following types are generally useful regardless of the profile
   being carried and are defined below using the text/directory MIME
   type registration template defined in Section 11.1 of this document.
   These types MAY be included in any profile, unless explicitly
   forbidden in the profile definition.

6.1.  SOURCE Type Definition

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

   Type name: SOURCE

   Type purpose: To identify the source of directory information
   contained in the content type.

   Type encoding: 8bit

   Type valuetype: uri




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


   Type special notes: The SOURCE type is used to provide the means by
   which applications knowledgable in the given directory service
   protocol can obtain additional or more up-to-date information from
   the directory service. It contains a URI as defined in [RFC-1738]
   and/or other information referencing the directory entity or entities
   to which the information pertains. When directory information is
   available from more than one source, the sending entity can pick what
   it considers to be the best source, or multiple SOURCE types can be
   included. The interpretation of the value for a SOURCE type can
   depend on the setting of the CONTEXT type parameter. The value of the
   CONTEXT type parameter MUST be compatible with the value of the uri
   prefix.

   Type example:
           SOURCE;CONTEXT=LDAP:ldap://ldap.host/cn=Babs%20Jensen,
            %20o=Babsco,%20c=US

6.2.  NAME Type Definition

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

   Type name: NAME

   Type purpose: To identify the displayable name of the directory
   entity to which information in the content type pertains.

   Type encoding: 8bit

   Type valuetype: text

   Type special notes: The NAME type is used to convey the display name
   of the entity to which the directory information pertains.

   Type example:
           NAME:Babs Jensen's Contact Information

6.3.  PROFILE Type Definition

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

   Type name: PROFILE

   Type purpose: To identify the type of directory entity to which
   information in the content type pertains.

   Type encoding: 8bit



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


   Type valuetype: A profile name, registered as described in Section 9
   of this document or bilaterally agreed upon as described in Section
   5.

   Type special notes: The PROFILE type is used to convey the type of
   the entity to which the directory information in the rest of the body
   part pertains. It should be the same as the "profile" header
   parameter, if present.

   Type example:
           PROFILE:vCard

6.4.  BEGIN Type Definition

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

   Type name: BEGIN

   Type purpose: To denote the beginning of a syntactic entity within a
   text/directory content-type.

   Type encoding: 8bit

   Type valuetype: text, containing a profile name, registered as
   described in Section 9 of this document or bilaterally-agreed upon as
   described in Section 5.

   Type special notes: The BEGIN type is used in conjunction with the
   END type to delimit a profile containing a related set of properties
   within an text/directory content-type. This construct can be used
   instead of or in addition to wrapping separate sets of information
   inside additional MIME headers. It is provided for applications that
   wish to define content that can contain multiple entities within the
   same text/directory content-type or to define content that can be
   identifiable outside of a MIME environment.

   Type example:
           BEGIN:VCARD

6.5.  END Type Definition

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

   Type name: END





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


   Type purpose: To denote the end of a syntactic entity within a
   text/directory content-type.

   Type encoding: 8bit

   Type valuetype: text, containing a profile name, registered as
   described in Section 9 of this document or bilaterally-agreed upon as
   described in Section 5.

   Type special notes: The END type is used in conjunction with the
   BEGIN type to delimit a profile containing a related set of
   properties within an text/directory content-type.  This construct can
   be used instead of or in addition to wrapping separate sets of
   information inside additional MIME headers. It is provided for
   applications that wish to define content that can contain multiple
   entities within the same text/directory content-type or to define
   content that can be identifiable outside of a MIME environment.

   Type example:
           END: VCARD

7.  Use of the multipart/related Content-Type

   The multipart/related Content-Type can be used to hold directory
   information comprised of both text and non-text information or
   directory information that already has a natural MIME representation.
   The root body part within the multipart/related body part is
   specified as defined in [RFC-2112] by a "start" parameter, or it is
   the first body part in the absence of such a parameter.  The root
   body part must have a Content-Type of "text/directory".  This part
   holds inline information and makes reference to subsequent body parts
   holding additional text or non-text directory information via their
   Content-ID URIs as explained in Section 5.

   The body parts referred to do not have to be in any particular order,
   except as noted above for the root body part.

8.  Examples

   The following examples are for illustrative purposes only and are not
   part of the definition.










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


8.1.  Example 1

   The first example illustrates simple use of the text/directory
   Content-Type.  Note that no "profile" parameter is given, so an
   application may not know what kind of directory entity the
   information applies to.  Note also the use of both hypothetical
   official and bilaterally agreed upon types.

      From: [e-mail]
      To: [e-mail]
      Subject: whatever
      MIME-Version: 1.0
      Message-ID: <[e-mail]>
      Content-Type: text/directory
      Content-ID: <[e-mail]>

      cn:Babs Jensen
      cn:Barbara J Jensen
      sn:Jensen
      email:[e-mail]
      phone:[phone]
      x-id:1234567890

8.2.  Example 2

   The next example illustrates the use of the Quoted-Printable transfer
   encoding defined in [RFC 2045] to include non-ASCII character in some
   of the information returned, and the use of the optional "name" and
   "source" types. It also illustrates the use of an "encoding" type
   parameter to encode a certificate value in "b".  A "vCard" profile
   [MIME- VCARD] is used for the example.

Content-Type: text/directory;
        charset="iso-8859-1";
        profile="vCard"
Content-ID: <[e-mail]>
Content-Transfer-Encoding: Quoted-Printable

begin:VCARD
source:ldap://cn=bjorn%20Jensen, o=university%20of%20Michigan, c=US
name:Bjorn Jensen
fn:Bj=F8rn Jensen
n:Jensen;Bj=F8rn
email;type=internet:[e-mail]
tel;type=work,voice,msg:[phone]
key;type=x509;encoding=B:dGhpcyBjb3VsZCBiZSAKbXkgY2VydGlmaWNhdGUK
end:VCARD




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


8.3.  Example 3

   The next example illustrates the use of multi-valued type parameters,
   the "language" type parameter, the "value" type parameter, folding of
   long lines, the \n encoding for formatted lines, attribute grouping,
   and the inline "b" encoding.  A "vCard" profile [MIME-VCARD] is used
   for the example.

Content-Type: text/directory; profile="vcard"; charset=iso-8859-1
Content-ID: <[e-mail]>
Content-Transfer-Encoding: Quoted-Printable

begin:vcard
source:ldap://cn=Meister%20Berger,o=Universitaet%20Goerlitz,c=DE
name:Meister Berger
fn:Meister Berger
n:Berger;Meister
bday;value=date:1963-09-21
o:Universit=E6t G=F6rlitz
title:Mayor
title;language=de;value=text:Burgermeister
note:The Mayor of the great city of
  Goerlitz in the great country of Germany.
email;internet:[e-mail]
home.tel;type=fax,voice,msg:[phone]
home.label:Hufenshlagel 1234\n
 02828 Goerlitz\n
 Deutschland
key;type=X509;encoding=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQ
 AwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zI
 ENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQD
 ExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNjE5NDc1OVoXDTk3MTIwMzE5NDc
 1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYDVQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW
 9ucyBDb3JwLjEYMBYGA1UEAxMPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBF
 hJob3dlc0BuZXRzY2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqG
 SIb3DQEBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2dXc
 oX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MBEGCWCGSAGG+E
 IBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9
 w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIPmx93HGp0Kgyx1jIVMyNgsemeAwBM+M
 SlhMfcpbTrONwNjZYW8vJDSoi//yrZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8V
 UMk1U7jt8LYpo4YULU7UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ==
end:vcard