[RFC2046] defines the message/external-body media type, whereby a
MIME entity can act as pointer to the actual body data in lieu of
including the data directly in the entity body. Each
message/external-body reference specifies an access type, which
determines the mechanism used to retrieve the actual body data. RFC
2046draft defines an initial set of access types but allows for the
registration of additional access types to accommodate new retrieval
mechanisms.
New access type specifications MUST conform to the requirements
described below.
Each access type MUST have a unique name. This name appears in the
access-type parameter in the message/external-body content-type
header field and MUST conform to MIME content type parameter syntax.
All of the protocols, transports, and procedures used by a given
access type MUST be described, either in the specification of the
access type itself or in some other publicly available specification,
in sufficient detail for the access type to be implemented by any
competent implementor. Use of secret and/or proprietary methods in
access types is expressly prohibited. The restrictions imposed by
[RFC2026] on the standardization of patented algorithms must be
respected as well.
All access types MUST be described by an RFC. The RFC may be
informational rather than standards-track, although standards-track
review and approval are encouraged for all access types.
Any known security issues that arise from the use of the access type
MUST be completely and fully described. It is not required that the
access type be secure or that it be free from risks, but it is
required that the known risks be identified. Publication of a new
access type does not require an exhaustive security review, and the
security considerations section is subject to continuing evaluation.
Additional security considerations SHOULD be addressed by publishing
revised versions of the access type specification.
Registration of a new access type starts with the publication of the
specification as an Internet Draft.
2.2.1. Present the Access Type to the Community
A proposed access type specification is sent to the
"ietf-types@iana.org" mailing list for a two-week review period.
This mailing list has been established for the purpose of reviewing
proposed access and media types. Proposed access types are not
formally registered and must not be used.
The intent of the public posting is to solicit comments and feedback
on the access type specification and a review of any security
considerations.
When the two-week period has passed, the access type reviewer, who is
appointed by the IETF Applications Area Director(s), either forwards
the request to iana@iana.org or rejects it because of significant
objections raised on the list.
Decisions made by the reviewer must be posted to the ietf-types
mailing list within 14 days. Decisions made by the reviewer may be
appealed to the IESG as specified in [RFC2026].
Provided that the access type either has passed review or has been
successfully appealed to the IESG, the IANA will register the access
type and make the registration available to the community. The
specification of the access type must also be published as an RFC.
Access type registrations are listed by the IANA on the following web
page:
http://www.iana.org/assignments/access-types
The identity of the access type reviewer is communicated to the IANA
by the IESG. The IANA then only acts either in response to access
type definitions that are approved by the access type reviewer and
forwarded to the IANA for registration, or in response to a
communication from the IESG that an access type definition appeal has
overturned the access type reviewer's ruling.
