Implementation by the Internet Community or a subtype that is used to Registered to accomodate the different natural requirements for,Į.g., a subtype that will be recommended for wide support and
#2048 extension registration#
Registration process, different structures of subtype names may be In order to increase the efficiency and flexibility of the Procedures used for each of the different registration trees.Ģ.1. The following sections describe the requirements and The media type is then registered if the proposal isĪcceptable. Proposal is circulated and reviewed in a fashion appropriate to the Several different registration trees, which have different Registration of a new media type or types starts with theĬonstruction of a registration proposal. RFC 2048 MIME Registration Procedures November 1996 2. The original procedure was excessively restrictive and had to be Proliferation of media types is not a hindrance to interoperability, As media types are used in new environments, where the Interoperability when the capabilities of the remote mail system are Number of possible media types to increase the likelihood of In this mail environment there is a need to limit the Initially defined in the context of the asynchronous Internet mailĮnvironment. Historical Note: The registration process for media types was This document defines registration procedures which use the InternetĪssigned Numbers Authority (IANA) as a central registry for such The set of such values is developed in an orderly, well-specified, A registration process is needed, however, to ensure that Open-ended framework and can accommodate additional object types,Ĭharacter sets, and access methods without any changes to the basic Recent Internet protocols have been carefully designed to be easilyĮxtensible in certain areas. 19 4.4 Location of Registered Transfer Encodings List. 19 4.3 IANA Procedures for Transfer Encoding Registration.
18 4.2 Transfer Encoding Definition Procedure. 18 4.1.5 Data Integrity and Generality Requirements. 17 4.1.2 Algorithm Specification Requirements. 16 3.4 IANA Procedures for Registering Access Types. 16 3.3 Location of Registered Access Type List. 15 3.2.1 Present the Access Type to the Community. RFC 2048 MIME Registration Procedures November 1996 3.1.2 Mechanism Specification Requirements. 12 2.6 IANA Procedures for Registering Media Types. 12 2.5 Location of Registered Media Type List. 12 2.4 Comments on Media Type Registrations. 11Ģ.3.1 Present the Media Type to the Community for Review 11Ģ.3.2 IESG Approval. 8 2.2.7 Usage and Implementation Non-requirements.
7 2.2.4 Canonicalization and Format Requirements. 4 2.1 Registration Trees and Subtype Names. An appendix in RFC 2049ĭescribes differences and changes from previous versions.ġ. These documents are revisions of RFCs 15, which themselves Registration of character sets for use in MIME is covered elsewhereĪnd is no longer addressed by this document. Procedures for the following MIME facilities: This fourth document, RFC 2048, specifies various IANA registration RFC 2048 MIME Registration Procedures November 1996 Orthogonal to (rather than a revision of) RFC 822.įreed, et. So little about message bodies, these documents are largely These documents are based on earlier work documented in RFC 934, STDġ1, and RFC 1049, but extends and revises them. (4) textual header information in character sets other than (2) an extensible set of different formats for non-textual (1) textual message bodies in character sets other than
This set ofĭocuments, collectively called the Multipurpose Internet MailĮxtensions, or MIME, redefines the format of messages to allow for Message content, or message body, as flat US-ASCII text. STD 11, RFC 822, defines a message representation protocol specifyingĬonsiderable detail about US-ASCII message headers, and leaves the Internet Community, and requests discussion and suggestions for This document specifies an Internet Best Current Practices for the Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures Obsoleted by: 4288, 4289 BEST CURRENT PRACTICEĬategory: Best Current Practice J.
0 kommentar(er)
