rfc2425.txt

RFC 的详细文档！

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









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


8.4.  Example 4

   The final example illustrates the use of the multipart/related
   Content-Type to include non-textual directory data via the "uri"
   encoding to refer to other body parts within the same message, or to
   external values.  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.

Content-Type: multipart/related;
        boundary=woof;
        type="text/directory";
        start="<[e-mail]>"
Content-ID: <[e-mail]>

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

source:ldap://cn=Bjorn%20Jensen,o=University%20of%20Michigan,c=US
cn:Bj=F8rn Jensen
sn:Jensen
email:[e-mail]
image;value=uri:cid:[e-mail]
image;value=uri;format=jpeg:ftp://some.host/some/path.jpg
sound;value=uri:cid:[e-mail]
phone:[phone]

--woof
Content-Type: image/jpeg
Content-ID: <[e-mail]>

<...image data...>

--woof
Content-Type: message/external-body;
        name="myvoice.au";
        site="myhost.com";
        access-type=ANON-FTP;
        directory="pub/myname";
        mode="image"

Content-Type: audio/basic
Content-ID: <[e-mail]>

--woof--



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


9.  Registration of new profiles

   This section defines procedures by which new profiles are registered
   with the IANA and made available to the Internet community. Note that
   non-IANA profiles can be used by bilateral agreement, provided the
   associated profile names follow the "X-" convention defined above.

   The procedures defined here are designed to allow public comment and
   review of new profiles, while posing only a small impediment to the
   definition of new profiles.

   Registration of a new profile is accomplished by the following steps.

9.1.  Define the profile

   A profile is defined by completing the following template.

      To: [e-mail]
      Subject: Registration of text/directory MIME profile XXX

      Profile name:

      Profile purpose:

      Profile types:

      Profile special notes (optional):

      Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)

   The explanation of what goes in each field in the template follows.

   Profile name: The name of the profile as it will appear in the
   text/directory MIME Content-Type "profile" header parameter, or the
   predefined "profile" type name.

   Profile purpose: The purpose of the profile (e.g., to represent
   information about people, printers, documents, etc.). Give a short
   but clear description.

   Profile types: The list of types associated with the profile.  This
   list of types is to be expected but not required in the profile,
   unless otherwise noted in the profile definition.  Other types not
   mentioned in the profile definition MAY also be present.  Note that
   any new types referenced by the profile MUST be defined separately as
   described in Section 10.





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


   Profile special notes: Any special notes about the profile, how it is
   to be used, etc. This section of the template can also be used to
   define an ordering on the types that appear in the Content-Type, if
   such an ordering is required.

9.2.  Post the profile definition

   The profile description must be posted to the new profile discussion
   list, [e-mail]

9.3.  Allow a comment period

   Discussion on the new profile must be allowed to take place on the
   list for a minimum of two weeks. Consensus must be reached on the
   profile before proceeding to step 4.

9.4.  Submit the profile for approval

   Once the two-week comment period has elapsed, and the proposer is
   convinced consensus has been reached on the profile, the registration
   application should be submitted to the Profile Reviewer for approval.
   The Profile Reviewer is appointed by the Application Area Directors
   and can either accept or reject the profile registration. An accepted
   registration is passed on by the Profile Reviewer to the IANA for
   inclusion in the official IANA profile registry. The registration may
   be rejected for any of the following reasons. 1) Insufficient comment
   period; 2) Consensus not reached; 3) Technical deficiencies raised on
   the list or elsewhere have not been addressed. The Profile Reviewer's
   decision to reject a profile can be appealed by the proposer to the
   IESG, or the objections raised can be addressed by the proposer and
   the profile resubmitted.

10.  Profile Change Control

   Existing profiles can be changed using the same process by which they
   were registered.

         Define the change

         Post the change

         Allow a comment period

         Submit the changed profile for approval







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


   Note that the original author or any other interested party can
   propose a change to an existing profile, but that such changes should
   only be proposed when there are serious omissions or errors in the
   published specification.  The Profile Reviewer can object to a change
   if it is not backwards compatible, but is not required to do so.

   Profile definitions can never be deleted from the IANA registry, but
   profiles which are no longer believed to be useful can be declared
   OBSOLETE by a change to their "intended use" field.

11.  Registration of new types

   This section defines procedures by which new types are registered
   with the IANA.  Note that non-IANA types can be used by bilateral
   agreement, provided the associated types names follow the "X-"
   convention defined above.

   The procedures defined here are designed to allow public comment and
   review of new types, while posing only a small impediment to the
   definition of new types.

   Registration of a new type is accomplished by the following steps.

11.1.  Define the type

   A type is defined by completing the following template.

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

      Type name:

      Type purpose:

      Type encoding:

      Type valuetype:

      Type special notes (optional):

      Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)

   The meaning of each field in the template is as follows.

   Type name: The name of the type, as it will appear in the body of an
   text/directory MIME Content-Type "type: value" line to the left of
   the colon ":".




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


   Type purpose: The purpose of the type (e.g., to represent a name,
   postal address, IP address, etc.). Give a short but clear
   description.

   Type encoding: The default encoding a value of the type must have in
   the body of a text/directory MIME Content-Type.

   Type valuetype: The format a value of the type must have in the body
   of a text/directory MIME Content-Type. This description must be
   precise and must not violate the general encoding rules defined in
   section 5 of this document.

   Type special notes: Any special notes about the type, how it is to be
   used, etc.

11.2.  Post the type definition

   The type description must be posted to the new type discussion list,
   [e-mail]

11.3.  Allow a comment period

   Discussion on the new type must be allowed to take place on the list
   for a minimum of two weeks. Consensus must be reached on the type
   before proceeding to step 4.

11.4.  Submit the type for approval

   Once the two-week comment period has elapsed, and the proposer is
   convinced consensus has been reached on the type, the registration
   application should be submitted to the Profile Reviewer for approval.
   The Profile Reviewer is appointed by the Application Area Directors
   and can either accept or reject the type registration. An accepted
   registration is passed on by the Profile Reviewer to the IANA for
   inclusion in the official IANA profile registry. The registration can
   be rejected for any of the following reasons. 1) Insufficient comment
   period; 2) Consensus not reached; 3) Technical deficiencies raised on
   the list or elsewhere have not been addressed.  The Profile
   Reviewer's decision to reject a type can be appealed by the proposer
   to the IESG, or the objections raised can be addressed by the
   proposer and the type resubmitted.










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


12.  Type Change Control

   Existing types can be changed using the same process by which they
   were registered.

         Define the change

         Post the change

         Allow a comment period

         Submit the type for approval

   Note that the original author or any other interested party can
   propose a change to an existing type, but that such changes should
   only be proposed when there are serious omissions or errors in the
   published specification.  The Profile Reviewer can object to a change
   if it is not backwards compatible, but is not required to do so.

   Type definitions can never be deleted from the IANA registry, but
   types which are nolonger believed to be useful can be declared
   OBSOLETE by a change to their "intended use" field.

13.  Registration of new parameters

   This section defines procedures by which new parameters are
   registered with the IANA and made available to the Internet
   community. Note that non-IANA parameters can be used by bilateral
   agreement, provided the associated parameters names follow the "X-"
   convention defined above.

   The procedures defined here are designed to allow public comment and
   review of new parameters, while posing only a small impediment to the
   definition of new parameters.

   Registration of a new parameter is accomplished by the following
   steps.

13.1.  Define the parameter

   A parameter is defined by completing the following template.

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

      Parameter name: