< draft-ietf-appsawg-media-type-regs-13.txt   draft-ietf-appsawg-media-type-regs-14.txt >
Network Working Group N. Freed Network Working Group N. Freed
Internet-Draft Oracle Internet-Draft Oracle
Obsoletes: 4288 (if approved) J. Klensin Obsoletes: 4288 (if approved) J. Klensin
Intended status: BCP Intended status: BCP
Expires: December 14, 2012 T. Hansen Expires: December 22, 2012 T. Hansen
AT&T Laboratories AT&T Laboratories
June 12, 2012 June 20, 2012
Media Type Specifications and Registration Procedures Media Type Specifications and Registration Procedures
draft-ietf-appsawg-media-type-regs-13 draft-ietf-appsawg-media-type-regs-14
Abstract Abstract
This document defines procedures for the specification and This document defines procedures for the specification and
registration of media types for use in HTTP, MIME and other Internet registration of media types for use in HTTP, MIME and other Internet
protocols. protocols.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 14, 2012. This Internet-Draft will expire on December 22, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 44 skipping to change at page 4, line 44
registering media types for use in the context of the asynchronous registering media types for use in the context of the asynchronous
Internet mail environment. In this mail environment there is a need Internet mail environment. In this mail environment there is a need
to limit the number of possible media types, to increase the to limit the number of possible media types, to increase the
likelihood of interoperability when the capabilities of the remote likelihood of interoperability when the capabilities of the remote
mail system are not known. As media types are used in new mail system are not known. As media types are used in new
environments in which the proliferation of media types is not a environments in which the proliferation of media types is not a
hindrance to interoperability, the original procedure proved hindrance to interoperability, the original procedure proved
excessively restrictive and had to be generalized. This was excessively restrictive and had to be generalized. This was
initially done in [RFC2048], but the procedure defined there was initially done in [RFC2048], but the procedure defined there was
still part of the MIME document set. The media type specification still part of the MIME document set. The media type specification
and registration procedure has now been moved to this separate and registration procedure is now a separate document, to make it
document, to make it clear that it is independent of MIME. clear that it is independent of MIME.
It may be desirable to restrict the use of media types to specific It may be desirable to restrict the use of media types to specific
environments or to prohibit their use in other environments. This environments or to prohibit their use in other environments. This
revision incorporates such restrictions into media type registrations specification incorporates such restrictions into media type
in a systematic way. See Section 4.9 for additional discussion. registrations in a systematic way. See Section 4.9 for additional
discussion.
1.2. Conventions Used in This Document 1.2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] when they document are to be interpreted as described in [RFC2119] when they
appear in ALL CAPS. They may also appear in lower or mixed case as appear in ALL CAPS. They may also appear in lower or mixed case as
plain English words, without any normative meaning. plain English words, without any normative meaning.
This specification makes use of the Augmented Backus-Naur Form (ABNF) This specification makes use of the Augmented Backus-Naur Form (ABNF)
skipping to change at page 5, line 37 skipping to change at page 5, line 37
3. Registration Trees and Subtype Names 3. Registration Trees and Subtype Names
In order to increase the efficiency and flexibility of the In order to increase the efficiency and flexibility of the
registration process, different structures of subtype names can be registration process, different structures of subtype names can be
registered to accommodate the different natural requirements for, registered to accommodate the different natural requirements for,
e.g., a subtype that will be recommended for wide support and e.g., a subtype that will be recommended for wide support and
implementation by the Internet community, or a subtype that is used implementation by the Internet community, or a subtype that is used
to move files associated with proprietary software. The following to move files associated with proprietary software. The following
subsections define registration "trees" that are distinguished by the subsections define registration "trees" that are distinguished by the
use of faceted names, e.g., names of the form use of faceted names, e.g., subtype names that begin with a a "tree."
"tree.subtree...subtype". Note that some media types defined prior prefix. Note that some media types defined prior to this document do
to this document do not conform to the naming conventions described not conform to the naming conventions described below. See Appendix
below. See Appendix A for a discussion of them. A for a discussion of them.
3.1. Standards Tree 3.1. Standards Tree
The standards tree is intended for types of general interest to the The standards tree is intended for types of general interest to the
Internet community. Registrations in the standards tree MUST be Internet community. Registrations in the standards tree MUST be
either: either:
1. in the case of registrations in IETF specifications, approved 1. in the case of registrations in IETF specifications, approved
directly by the IESG, or directly by the IESG, or
skipping to change at page 6, line 39 skipping to change at page 6, line 39
Media types in the standards tree MUST NOT have faceted names, unless Media types in the standards tree MUST NOT have faceted names, unless
they are grandfathered in using the process described in Appendix A. they are grandfathered in using the process described in Appendix A.
The "owner" of a media type registered in the standards tree is The "owner" of a media type registered in the standards tree is
assumed to be the standards body itself. Modification or alteration assumed to be the standards body itself. Modification or alteration
of the specification uses the same level of processing (e.g., a of the specification uses the same level of processing (e.g., a
registration submitted on Standards Track can be revised in another registration submitted on Standards Track can be revised in another
Standards Track RFC, but cannot be revised in an Informational RFC) Standards Track RFC, but cannot be revised in an Informational RFC)
required for the initial registration. required for the initial registration.
Standards-tree registrations from recognized standards bodies may be Standards-tree registrations from recognized standards bodies are
submitted directly to the IANA, where they will undergo Expert Review submitted directly to the IANA, where they will undergo Expert Review
[RFC5226] prior to approval. In this case, the Expert Reviewer(s) [RFC5226] prior to approval. In this case, the Expert Reviewer(s)
will, among other things, ensure that the required specification will, among other things, ensure that the required specification
provides adequate documentation. provides adequate documentation.
3.2. Vendor Tree 3.2. Vendor Tree
The vendor tree is used for media types associated with publicly The vendor tree is used for media types associated with publicly
available products. "Vendor" and "producer" are construed very available products. "Vendor" and "producer" are construed very
broadly in this context and are considered equivalent. Note that broadly in this context and are considered equivalent. Note that
skipping to change at page 8, line 18 skipping to change at page 8, line 18
intended exclusively for use in private, local environments. Types intended exclusively for use in private, local environments. Types
in this tree cannot be registered and are intended for use only with in this tree cannot be registered and are intended for use only with
the active agreement of the parties exchanging them. the active agreement of the parties exchanging them.
However, with the simplified registration procedures described above However, with the simplified registration procedures described above
for vendor and personal trees, it should rarely, if ever, be for vendor and personal trees, it should rarely, if ever, be
necessary to use unregistered types. Therefore, use of types in the necessary to use unregistered types. Therefore, use of types in the
"x." tree is strongly discouraged. "x." tree is strongly discouraged.
Note that types with names beginning with "x-" are no longer Note that types with names beginning with "x-" are no longer
considered to members of this tree (see [I-D.ietf-appsawg-xdash]). considered to be members of this tree (see [I-D.ietf-appsawg-xdash]).
Also note that if a generally useful and widely deployed type Also note that if a generally useful and widely deployed type
incorrectly ends up with an "x-" name prefix, it MAY be registered incorrectly ends up with an "x-" name prefix, it MAY be registered
using its current name in an alternate tree by following the using its current name in an alternate tree by following the
procedure defined in Appendix A. procedure defined in Appendix A.
3.5. Additional Registration Trees 3.5. Additional Registration Trees
From time to time and as required by the community, new top-level From time to time and as required by the community, new top-level
registration trees may be created by IETF Standards Action. It is registration trees may be created by IETF Standards Action. It is
explicitly assumed that these trees may be created for external explicitly assumed that these trees may be created for external
skipping to change at page 10, line 40 skipping to change at page 10, line 40
If a "charset" parameter is specified, it SHOULD be a required If a "charset" parameter is specified, it SHOULD be a required
parameter, eliminating the options of specifying a default value. If parameter, eliminating the options of specifying a default value. If
there is a strong reason for the parameter to be optional despite there is a strong reason for the parameter to be optional despite
this advice, each subtype MAY specify its own default value, or this advice, each subtype MAY specify its own default value, or
alternately, it MAY specify that there is no default value. Finally, alternately, it MAY specify that there is no default value. Finally,
the "UTF-8" charset [RFC3629] SHOULD be selected as the default. See the "UTF-8" charset [RFC3629] SHOULD be selected as the default. See
[I-D.ietf-appsawg-mime-default-charset] for additional information on [I-D.ietf-appsawg-mime-default-charset] for additional information on
the use of "charset" parameters in conjunction with subtypes of text. the use of "charset" parameters in conjunction with subtypes of text.
Regardless of what approach is chosen, all text/* registrations MUST Regardless of what approach is chosen, all new text/* registrations
clearly specify how the charset is determined; relying on the US- MUST clearly specify how the charset is determined; relying on the
ASCII default defined in Section 4.1.2 of [RFC2046] is no longer US-ASCII default defined in Section 4.1.2 of [RFC2046] is no longer
permitted. If explanatory text is needed this SHOULD be placed in permitted. If explanatory text is needed this SHOULD be placed in
the additional information section of the registration. the additional information section of the registration.
Plain text does not provide for or allow formatting commands, font Plain text does not provide for or allow formatting commands, font
attribute specifications, processing instructions, interpretation attribute specifications, processing instructions, interpretation
directives, or content markup. Plain text is seen simply as a linear directives, or content markup. Plain text is seen simply as a linear
sequence of characters, possibly interrupted by line breaks or page sequence of characters, possibly interrupted by line breaks or page
breaks. Plain text MAY allow the stacking of several characters in breaks. Plain text MAY allow the stacking of several characters in
the same position in the text. Plain text in scripts like Arabic and the same position in the text. Plain text in scripts like Arabic and
Hebrew may also include facilities that allow the arbitrary mixing of Hebrew may also include facilities that allow the arbitrary mixing of
skipping to change at page 12, line 42 skipping to change at page 12, line 42
rules and other requirements specified in [RFC2046] and amended by rules and other requirements specified in [RFC2046] and amended by
Section 3.5 of [RFC6532]. Section 3.5 of [RFC6532].
4.2.7. Additional Top-level Types 4.2.7. Additional Top-level Types
In some cases a new media type may not "fit" under any currently In some cases a new media type may not "fit" under any currently
defined top-level type names. Such cases are expected to be quite defined top-level type names. Such cases are expected to be quite
rare. However, if such a case does arise a new type name can be rare. However, if such a case does arise a new type name can be
defined to accommodate it. Such a definition MUST be done via defined to accommodate it. Such a definition MUST be done via
standards-track RFC; no other mechanism can be used to define standards-track RFC; no other mechanism can be used to define
additional type name. additional type names.
4.2.8. Structured Syntax Name Suffixes 4.2.8. Structured Syntax Name Suffixes
XML in MIME [RFC3023] defined the first such augmentation to the XML in MIME [RFC3023] defined the first such augmentation to the
media type definition to additionally specify the underlying media type definition to additionally specify the underlying
structure of that media type. To quote: structure of that media type. To quote:
This document also standardizes a convention (using the suffix This document also standardizes a convention (using the suffix
'+xml') for naming media types ... when those media types '+xml') for naming media types ... when those media types
represent XML MIME (Multipurpose Internet Mail Extensions) represent XML MIME (Multipurpose Internet Mail Extensions)
skipping to change at page 15, line 35 skipping to change at page 15, line 35
specification of a media type is part of a standards-track protocol. specification of a media type is part of a standards-track protocol.
In addition, other standards bodies making use of the standards tree In addition, other standards bodies making use of the standards tree
may have their own rules regarding intellectual property that must be may have their own rules regarding intellectual property that must be
observed in their registrations. observed in their registrations.
IPR disclosures for registrations in the vendor and personal tree are IPR disclosures for registrations in the vendor and personal tree are
encouraged but not required. encouraged but not required.
4.5. Interchange Recommendations 4.5. Interchange Recommendations
Media types SHOULD interoperate across as many systems and Ideally media types will be defined so they interoperate across as
applications as possible. However, some media types will inevitably many systems and applications as possible. However, some media types
have problems interoperating across different platforms. Problems will inevitably have problems interoperating across different
with different versions, byte ordering, and specifics of gateway platforms. Problems with different versions, byte ordering, and
handling can and will arise. specifics of gateway handling can and will arise.
Universal interoperability of media types is not required, but known Universal interoperability of media types is not required, but known
interoperability issues SHOULD be identified whenever possible. interoperability issues SHOULD be identified whenever possible.
Publication of a media type does not require an exhaustive review of Publication of a media type does not require an exhaustive review of
interoperability, and the interoperability considerations section is interoperability, and the interoperability considerations section is
subject to continuing evaluation. subject to continuing evaluation.
These recommendations in this subsection apply regardless of the These recommendations in this subsection apply regardless of the
registration tree involved. registration tree involved.
4.6. Security Requirements 4.6. Security Requirements
An analysis of security issues MUST be done for all types registered An analysis of security issues MUST be done for all types registered
in the standards tree. A similar analysis for media types registered in the standards tree. A similar analysis for media types registered
in the vendor or personal trees is encouraged but not required. in the vendor or personal trees is encouraged but not required.
However, regardless of what security analysis has or has not been However, regardless of what security analysis has or has not been
done, all descriptions of security issues MUST be as accurate as done, all descriptions of security issues MUST be as accurate as
possible regardless of registration tree. In particular, a statement possible regardless of registration tree. In particular, the
that there are "no security issues associated with this type" MUST security considerations MUST NOT state that there are "no security
NOT be confused with "the security issues associates with this type issues associated with this type". Security considerations for types
have not been assessed". in the vendor or personal tree MAY say that "the security issues
associates with this type have not been assessed".
There is absolutely no requirement that media types registered in any There is absolutely no requirement that media types registered in any
tree be secure or completely free from risks. Nevertheless, all tree be secure or completely free from risks. Nevertheless, all
known security risks MUST be identified in the registration of a known security risks MUST be identified in the registration of a
media type, again regardless of registration tree. media type, again regardless of registration tree.
The security considerations section of all registrations is subject The security considerations section of all registrations is subject
to continuing evaluation and modification, and in particular MAY be to continuing evaluation and modification, and in particular MAY be
extended by use of the "comments on media types" mechanism described extended by use of the "comments on media types" mechanism described
in Section 5.4 below. in Section 5.4 below.
skipping to change at page 25, line 17 skipping to change at page 25, line 17
3. IANA requests Expert Review of the registration request against 3. IANA requests Expert Review of the registration request against
the corresponding guidelines. the corresponding guidelines.
4. The Designated Expert may request additional review or 4. The Designated Expert may request additional review or
discussion, as necessary. discussion, as necessary.
5. If Expert Review recommends registration, IANA adds the 5. If Expert Review recommends registration, IANA adds the
registration to the appropriate registry. registration to the appropriate registry.
The initial registry content specification
[I-D.appsawg-media-type-suffix-regs] provides examples of structured
syntax suffix registrations.
6.1. Change Procedures 6.1. Change Procedures
Registrations may be updated in each registry by the same mechanism Registrations may be updated in each registry by the same mechanism
as required for an initial registration. In cases where the original as required for an initial registration. In cases where the original
definition of the scheme is contained in an IESG-approved document, definition of the scheme is contained in an IESG-approved document,
update of the specification also requires IESG approval. update of the specification also requires IESG approval.
6.2. Structured Syntax Suffix Registration Template 6.2. Structured Syntax Suffix Registration Template
This template describes the fields that must be supplied in a This template describes the fields that must be supplied in a
 End of changes. 14 change blocks. 
27 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/