rfc2425.txt

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

13.2.  Post the parameter definition

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

13.3.  Allow a comment period

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

13.4.  Submit the parameter for approval

   Once the two-week comment period has elapsed, and the proposer is
   convinced consensus has been reached on the parameter, 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 parameter
   registration.  An accepted registration is passed on by the Profile
   Reviewer to the IANA for inclusion in the official IANA parameter
   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 profile can be
   appealed by the proposer to the IESG, or the objections raised can be



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


   addressed by the proposer and the parameter registration resubmitted.

14.  Parameter Change Control

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

         Define the change

         Post the change

         Allow a comment period

         Submit the parameter for approval

   Note that the original author or any other interested party can
   propose a change to an existing parameter, 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.

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

15.  Registration of new value types

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

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

   Registration of a new value types is accomplished by the following
   steps.

15.1.  Define the value type

   A value type is defined by completing the following template.

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




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


      value type name:

      value type purpose:

      value type format:

      value type special notes (optional):

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

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

   value type name: The name of the value type as it will appear in the
   text/directory MIME Content-Type.

   value type purpose: The purpose of the value type.  Give a short but
   clear description.

   value type format: The definition of the format for the value,
   usually using ABNF grammar.

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

15.2.  Post the value type definition

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

15.3.  Allow a comment period

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

15.4.  Submit the value type for approval

   Once the two-week comment period has elapsed, and the proposer is
   convinced consensus has been reached on the value 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 value type
   registration.  An accepted registration should be passed on by the
   Profile Reviewer to the IANA for inclusion in the official IANA value
   type 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



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


   profile can be appealed by the proposer to the IESG, or the
   objections raised can be addressed by the proposer and the value type
   registration resubmitted.

16.  Security Considerations

   Internet mail is subject to many well known security attacks,
   including monitoring, replay, and forgery. Care should be taken by
   any directory service in allowing information to leave the scope of
   the service itself, where any access controls can no longer be
   guaranteed.  Applications should also take care to display directory
   data in a "safe" environment (e.g., PostScript-valued types).

17.  Acknowledgements

   The registration procedures defined here were shamelessly lifted from
   the MIME registration RFC.

   The many valuable comments contributed by members of the IETF ASID
   working group are gratefully acknowledged, as are the contributions
   of the Versit Consortium. Chris Newman was especially helpful in
   navigating the intricacies of ABNF lore.

18.  References

   [RFC-1777]   Yeong, W., Howes, T., and S. Kille, "Lightweight
                Directory Access Protocol", RFC 1777, March 1995.

   [RFC-1778]   Howes, T., Kille, S., Yeong, W., and C. Robbins, "The
                String Representation of Standard Attribute Syntaxes",
                RFC 1778, March 1995.

   [RFC-822]    Crocker, D., "Standard for the Format of ARPA Internet
                Text Messages", STD 11, RFC 822, August 1982.

   [RFC-2045]   Borenstein, N., and N. Freed, "Multipurpose Internet
                Mail Extensions (MIME) Part One: Format of Internet
                Message Bodies", RFC 2045, November 1996.

   [RFC-2046]   Moore, K., "Multipurpose Internet Mail Extensions (MIME)
                Part Two:  Media Types", RFC 2046, November 1996.

   [RFC-2048]   Freed, N., Klensin, J., and J. Postel, "Multipurpose
                Internet Mail Extensions (MIME) Part Four: Registration
                Procedures", RFC 2048, November 1996.

   [RFC-1766]   Alvestrand, H., "Tags for the Identification of
                Languages", RFC 1766, March 1995.



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


   [RFC-2112]   Levinson, E., "The MIME Multipart/Related Content-type",
                RFC 2112, March 1997.

   [X500]       "Information Processing Systems - Open Systems
                Interconnection - The Directory: Overview of Concepts,
                Models and Services", ISO/IEC JTC 1/SC21, International
                Standard 9594-1, 1988.

   [RFC-1835]   Deutsch, P., Schoultz, R., Faltstrom, P., and C. Weider,
                "Architecture of the WHOIS++ service", RFC 1835, August
                1995.

   [RFC-1738]   Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
                Resource Locators (URL)", RFC 1738, December 1994.

   [MIME-VCARD] Dawson, F., and T. Howes, "VCard MIME Directory
                Profile", RFC 2426, September 1998.

   [VCARD]      Internet Mail Consortium, "vCard - The Electronic
                Business Card", Version 2.1,
                http://www.imc.com/pdi/vcard-21.txt, September, 1996.

   [RFC-2119]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement  Levels", BCP 14, RFC 2119, March 1997.

   [RFC-2234]   Crocker, D., and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", RFC 2234, November 1997.
























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


19.  Authors' Addresses

   Tim Howes
   Netscape Communications Corp.
   501 East Middlefield Rd.
   Mountain View, CA 94041
   USA

   Phone: [phone]
   EMail: [e-mail]


   Mark Smith
   Netscape Communications Corp.
   501 East Middlefield Rd.
   Mountain View, CA 94041
   USA

   Phone: [phone]
   EMail: [e-mail]


   Frank Dawson
   Lotus Development Corporation
   6544 Battleford Drive
   Raleigh, NC 27613
   USA

   Phone: [phone]
   EMail: [e-mail]





















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


20.  Full Copyright Statement

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Howes, et. al.              Standards Track                    [Page 33]