doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc4289.txt b/doc/rfc/rfc4289.txt
new file mode 100644
index 0000000..4ba25c0
--- /dev/null
+++ b/doc/rfc/rfc4289.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                           N. Freed
+Request for Comments: 4289                              Sun Microsystems
+BCP: 13                                                       J. Klensin
+Obsoletes: 2048                                            December 2005
+Category: Best Current Practice
+
+
+        Multipurpose Internet Mail Extensions (MIME) Part Four:
+                        Registration Procedures
+
+Status of This Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document specifies IANA registration procedures for MIME
+   external body access types and content-transfer-encodings.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed & Klensin          Best Current Practice                  [Page 1]
+
+RFC 4289                   MIME Registration               December 2005
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. External Body Access Types ......................................3
+      2.1. Registration Requirements ..................................3
+         2.1.1. Naming Requirements ...................................3
+         2.1.2. Mechanism Specification Requirements ..................3
+         2.1.3. Publication Requirements ..............................4
+         2.1.4. Security Requirements .................................4
+      2.2. Registration Procedure .....................................4
+         2.2.1. Present the Access Type to the Community ..............4
+         2.2.2. Access Type Reviewer ..................................4
+         2.2.3. IANA Registration .....................................5
+      2.3. Location of Registered Access Type List ....................5
+      2.4. IANA Procedures for Registering Access Types ...............5
+   3. Transfer Encodings ..............................................5
+      3.1. Transfer Encoding Requirements .............................6
+         3.1.1. Naming Requirements ...................................6
+         3.1.2. Algorithm Specification Requirements ..................6
+         3.1.3. Input Domain Requirements .............................6
+         3.1.4. Output Range Requirements .............................6
+         3.1.5. Data Integrity and Generality Requirements ............7
+         3.1.6. New Functionality Requirements ........................7
+         3.1.7. Security Requirements .................................7
+      3.2. Transfer Encoding Definition Procedure .....................7
+      3.3. IANA Procedures for Transfer Encoding Registration .........8
+      3.4. Location of Registered Transfer Encodings List .............8
+   4. Security Considerations .........................................8
+   5. IANA Considerations .............................................8
+   6. Acknowledgements ................................................8
+   7. References ......................................................9
+   A.  Changes Since RFC 2048 .........................................9
+
+1.  Introduction
+
+   Recent Internet protocols have been carefully designed to be easily
+   extensible in certain areas.  In particular, MIME [RFC2045] is an
+   open-ended framework and can accommodate additional object types,
+   charsets, and access methods without any changes to the basic
+   protocol.  A registration process is needed, however, to ensure that
+   the set of such values is developed in an orderly, well-specified,
+   and public manner.
+
+   This document defines registration procedures that use the Internet
+   Assigned Numbers Authority (IANA) as a central registry for these
+   values.
+
+
+
+
+
+Freed & Klensin          Best Current Practice                  [Page 2]
+
+RFC 4289                   MIME Registration               December 2005
+
+
+   Note:
+
+      Registration of media types and charsets for use in MIME are
+      specified in separate documents [RFC4288] [RFC2978] and are not
+      addressed here.
+
+1.1.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  External Body Access Types
+
+   [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
+   2046 defines an initial set of access types but allows for the
+   registration of additional access types to accommodate new retrieval
+   mechanisms.
+
+2.1.  Registration Requirements
+
+   New access type specifications MUST conform to the requirements
+   described below.
+
+2.1.1.  Naming Requirements
+
+   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.
+
+2.1.2.  Mechanism Specification Requirements
+
+   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.
+
+
+
+
+
+
+
+Freed & Klensin          Best Current Practice                  [Page 3]
+
+RFC 4289                   MIME Registration               December 2005
+
+
+2.1.3.  Publication Requirements
+
+   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.
+
+2.1.4.  Security Requirements
+
+   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.
+
+2.2.  Registration Procedure
+
+   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.
+
+2.2.2.  Access Type Reviewer
+
+   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].
+
+
+
+
+
+
+
+Freed & Klensin          Best Current Practice                  [Page 4]
+
+RFC 4289                   MIME Registration               December 2005
+
+
+2.2.3.  IANA Registration
+
+   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.
+
+2.3.  Location of Registered Access Type List
+
+   Access type registrations are listed by the IANA on the following web
+   page:
+
+     http://www.iana.org/assignments/access-types
+
+2.4.  IANA Procedures for Registering 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.
+
+3.  Transfer Encodings
+
+   Transfer encodings are transformations applied to MIME media types
+   after conversion to the media type's canonical form.  Transfer
+   encodings are used for several purposes:
+
+   o  Many transports, especially message transports, can only handle
+      data consisting of relatively short lines of text.  There can be
+      severe restrictions on what characters can be used in these lines
+      of text.  Some transports are restricted to a small subset of US-
+      ASCII, and others cannot handle certain character sequences.
+      Transfer encodings are used to transform binary data into a
+      textual form that can survive such transports.  Examples of this
+      sort of transfer encoding include the base64 and quoted-printable
+      transfer encodings defined in [RFC2045].
+
+   o  Image, audio, video, and even application entities are sometimes
+      quite large.  Compression algorithms are often effective in
+      reducing the size of large entities.  Transfer encodings can be
+      used to apply general-purpose non-lossy compression algorithms to
+      MIME entities.
+
+   o  Transport encodings can be defined as a means of representing
+      existing encoding formats in a MIME context.
+
+
+
+
+Freed & Klensin          Best Current Practice                  [Page 5]
+
+RFC 4289                   MIME Registration               December 2005
+
+
+   IMPORTANT:  The standardization of a large number of different
+   transfer encodings is seen as a significant barrier to widespread
+   interoperability and is expressly discouraged.  Nevertheless, the
+   following procedure has been defined in order to provide a means of
+   defining additional transfer encodings, should standardization
+   actually be justified.
+
+3.1.  Transfer Encoding Requirements
+
+   Transfer encoding specifications MUST conform to the requirements
+   described below.
+
+3.1.1.  Naming Requirements
+
+   Each transfer encoding MUST have a unique name.  This name appears in
+   the Content-Transfer-Encoding header field and MUST conform to the
+   syntax of that field.
+
+3.1.2.  Algorithm Specification Requirements
+
+   All of the algorithms used in a transfer encoding (e.g., conversion
+   to printable form, compression) MUST be described in their entirety
+   in the transfer encoding specification.  Use of secret and/or
+
+   proprietary algorithms in standardized transfer encodings is
+   expressly prohibited.  The restrictions imposed by [RFC2026] on the
+   standardization of patented algorithms MUST be respected as well.
+
+3.1.3.  Input Domain Requirements
+
+   All transfer encodings MUST be applicable to an arbitrary sequence of
+   octets of any length.  Dependence on particular input forms is not
+   allowed.
+
+   It should be noted that the 7bit and 8bit encodings do not conform to
+   this requirement.  Aside from the undesirability of having
+   specialized encodings, the intent here is to forbid the addition of
+   additional encodings similar to, or redundant with, 7bit and 8bit.
+
+3.1.4.  Output Range Requirements
+
+   There is no requirement that a particular transfer encoding produce a
+   particular form of encoded output.  However, the output format for
+   each transfer encoding MUST be fully and completely documented.  In
+   particular, each specification MUST clearly state whether the output
+   format always lies within the confines of 7bit or 8bit or is simply
+   pure binary data.
+
+
+
+
+Freed & Klensin          Best Current Practice                  [Page 6]
+
+RFC 4289                   MIME Registration               December 2005
+
+
+3.1.5.  Data Integrity and Generality Requirements
+
+   All transfer encodings MUST be fully invertible on any platform; it
+   MUST be possible for anyone to recover the original data by
+   performing the corresponding decoding operation.  Note that this
+   requirement effectively excludes all forms of lossy compression as
+   well as all forms of encryption from use as a transfer encoding.
+
+3.1.6.  New Functionality Requirements
+
+   All transfer encodings MUST provide some sort of new functionality.
+   Some degree of functionality overlap with previously defined transfer
+   encodings is acceptable, but any new transfer encoding MUST also
+   offer something no other transfer encoding provides.
+
+3.1.7.  Security Requirements
+
+   To the greatest extent possible, transfer encodings SHOULD NOT
+   contain known security issues.  Regardless, any known security issues
+   that arise from the use of the transfer encoding MUST be completely
+   and fully described.  If additional security issues come to light
+   after initial publication and registration, they SHOULD be addressed
+   by publishing revised versions of the transfer encoding
+   specification.
+
+3.2.  Transfer Encoding Definition Procedure
+
+   Definition of a new transfer encoding starts with the publication of
+   the specification as an Internet Draft.  The draft MUST define the
+   transfer encoding precisely and completely, and it MUST also provide
+   substantial justification for defining and standardizing a new
+   transfer encoding.  This specification MUST then be presented to the
+   IESG for consideration.  The IESG can:
+
+   o  reject the specification outright as being inappropriate for
+      standardization,
+
+   o  assign the specification to an existing IETF working group for
+      further work,
+
+   o  approve the formation of an IETF working group to work on the
+      specification in accordance with IETF procedures, or
+
+   o  accept the specification as-is for processing as an individual
+      standards-track submission.
+
+   Transfer encoding specifications on the standards track follow normal
+   IETF rules for standards-track documents.  A transfer encoding is
+
+
+
+Freed & Klensin          Best Current Practice                  [Page 7]
+
+RFC 4289                   MIME Registration               December 2005
+
+
+   considered to be defined and available for use once it is on the
+   standards track.
+
+3.3.  IANA Procedures for Transfer Encoding Registration
+
+   There is no need for a special procedure for registering Transfer
+   Encodings with the IANA.  All legitimate transfer encoding
+   registrations MUST appear as a standards-track RFC, so it is the
+   IESG's responsibility to notify the IANA when a new transfer encoding
+   has been approved.
+
+3.4.  Location of Registered Transfer Encodings List
+
+   The list of transfer encoding registrations can be found at:
+
+     http://www.iana.org/assignments/transfer-encodings
+
+4.  Security Considerations
+
+   Security requirements for access types are discussed in Section
+   2.1.4.  Security requirements for transfer encodings are discussed in
+   Section 3.1.7.
+
+5.  IANA Considerations
+
+   The sole purpose of this document is to define IANA registries for
+   access types and transfer encodings.  The IANA procedures for these
+   registries are specified in Section 2.4 and Section 3.3 respectively.
+
+6.  Acknowledgements
+
+   The current authors would like to acknowledge their debt to the late
+   Dr. Jon Postel, whose general model of IANA registration procedures
+   and specific contributions shaped the predecessors of this document
+   [RFC2048].  We hope that the current version is one with which he
+   would have agreed but, as it is impossible to verify that agreement,
+   we have regretfully removed his name as a co-author.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed & Klensin          Best Current Practice                  [Page 8]
+
+RFC 4289                   MIME Registration               December 2005
+
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+              Extensions (MIME) Part One: Format of Internet Message
+              Bodies", RFC 2045, November 1996.
+
+   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+              Extensions (MIME) Part Two: Media Types", RFC 2046,
+              November 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
+              Registration Procedures", BCP 13, RFC 4288, December 2005.
+
+7.2.  Informative References
+
+   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
+              3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2048]  Freed, N., Klensin, J., and J. Postel, "Multipurpose
+              Internet Mail Extensions (MIME) Part Four: Registration
+              Procedures", BCP 13, RFC 2048, November 1996.
+
+   [RFC2978]  Freed, N. and J. Postel, "IANA Charset Registration
+              Procedures", BCP 19, RFC 2978, October 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Freed & Klensin          Best Current Practice                  [Page 9]
+
+RFC 4289                   MIME Registration               December 2005
+
+
+Appendix A.  Changes Since RFC 2048
+
+   o  Media type registration procedures are now described in a separate
+      document [RFC4288].
+
+   o  The various URLs and addresses in this document have been changed
+      so they all refer to iana.org rather than isi.edu.  Additionally,
+      many of the URLs have been changed to use HTTP; formerly they used
+      FTP.
+
+   o  Much of the document has been clarified in the light of
+      operational experience with these procedures.
+
+   o  Several of the references in this document have been updated to
+      refer to current versions of the relevant specifications.
+
+   o  The option of assigning the task of working on a new transfer
+      encoding to an existing working group has been added to the list
+      of possible actions the IESG can take.
+
+   o  Security considerations and IANA considerations sections have been
+      added.
+
+   o  Registration of charsets for use in MIME is specified in [RFC2978]
+      and is no longer addressed by this document.
+
+Authors' Addresses
+
+   Ned Freed
+   Sun Microsystems
+   3401 Centrelake Drive, Suite 410
+   Ontario, CA  92761-1205
+   USA
+
+   Phone: +1 909 457 4293
+   EMail: ned.freed@mrochek.com
+
+
+   John C. Klensin
+   1770 Massachusetts Ave, #322
+   Cambridge, MA  02140
+
+   EMail: klensin+ietf@jck.com
+
+
+
+
+
+
+
+
+Freed & Klensin          Best Current Practice                 [Page 10]
+
+RFC 4289                   MIME Registration               December 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Freed & Klensin          Best Current Practice                 [Page 11]
+