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: ietf-mime-direct@imc.org
Subject: Registration of text/directory MIME type parameter XXX
Parameter name:
Parameter purpose:
Parameter values:
Parameter special notes (optional):
Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
The explanation of what goes in each field in the template follows.
Parameter name: The name of the parameter as it will appear in the
text/directory MIME Content-Type.
Parameter purpose: The purpose of the parameter (e.g., to represent
the format of an image, type of a phone number, etc.). Give a short
but clear description. If defining a general paramemter like "format"
or "type" keep in mind that other applications might wish to extend
its use.
Parameter values: The list or description of values associated with
the parameter.
Parameter special notes: Any special notes about the parameter, how
it is to be used, etc.
13.2. Post the parameter definition
The parameter description must be posted to the new parameter
discussion list, ietf-mime-direct@imc.org
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
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: ietf-mime-direct@imc.org
Subject: Registration of text/directory MIME value type XXX
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, ietf-mime-direct@imc.org
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
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", RFC1777, March 1995.
[RFC-1778] Howes, T., Kille, S., Yeong, W., and C. Robbins, "The
String Representation of Standard Attribute Syntaxes",
RFC1778, March 1995.
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC822, August 1982.
[RFC-2045] Borenstein, N., and N. Freed, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC2045, November 1996.
[RFC-2046] Moore, K., "Multipurpose Internet Mail Extensions (MIME)
Part Two: Media Types", RFC2046, November 1996.
[RFC-2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", RFC2048, November 1996.
[RFC-1766] Alvestrand, H., "Tags for the Identification of
Languages", RFC1766, March 1995.
[RFC-2112] Levinson, E., "The MIME Multipart/Related Content-type",
RFC2112, 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", RFC1835, August
1995.
[RFC-1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC1738, December 1994.
[MIME-VCARD] Dawson, F., and T. Howes, "VCard MIME Directory
Profile", RFC2426, 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, RFC2119, March 1997.
[RFC-2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC2234, November 1997.
19. Authors' Addresses
Tim Howes
Netscape Communications Corp.
501 East Middlefield Rd.
Mountain View, CA 94041
USA
Phone: +1.415.937.3419
EMail: howes@netscape.com
Mark Smith
Netscape Communications Corp.
501 East Middlefield Rd.
Mountain View, CA 94041
USA
Phone: +1.415.937.3477
EMail: mcs@netscape.com
Frank Dawson
Lotus Development Corporation
6544 Battleford Drive
Raleigh, NC 27613
USA
Phone: +1-919-676-9515
EMail: frank_dawson@lotus.com
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.