Document tunnel command's environment variables
[claws.git] / doc / src / rfc2048.txt
1
2
3
4
5
6
7 Network Working Group                                           N. Freed
8 Request for Comments: 2048                                      Innosoft
9 BCP: 13                                                       J. Klensin
10 Obsoletes: 1521, 1522, 1590                                          MCI
11 Category: Best Current Practice                                J. Postel
12                                                                      ISI
13                                                            November 1996
14
15
16                  Multipurpose Internet Mail Extensions
17                            (MIME) Part Four:
18                         Registration Procedures
19
20 Status of this Memo
21
22    This document specifies an Internet Best Current Practices for the
23    Internet Community, and requests discussion and suggestions for
24    improvements.  Distribution of this memo is unlimited.
25
26 Abstract
27
28    STD 11, RFC 822, defines a message representation protocol specifying
29    considerable detail about US-ASCII message headers, and leaves the
30    message content, or message body, as flat US-ASCII text.  This set of
31    documents, collectively called the Multipurpose Internet Mail
32    Extensions, or MIME, redefines the format of messages to allow for
33
34     (1)   textual message bodies in character sets other than
35           US-ASCII,
36
37     (2)   an extensible set of different formats for non-textual
38           message bodies,
39
40     (3)   multi-part message bodies, and
41
42     (4)   textual header information in character sets other than
43           US-ASCII.
44
45    These documents are based on earlier work documented in RFC 934, STD
46    11, and RFC 1049, but extends and revises them.  Because RFC 822 said
47    so little about message bodies, these documents are largely
48    orthogonal to (rather than a revision of) RFC 822.
49
50
51
52
53
54
55
56
57
58 Freed, et. al.           Best Current Practice                  [Page 1]
59 \f
60 RFC 2048              MIME Registration Procedures         November 1996
61
62
63    This fourth document, RFC 2048, specifies various IANA registration
64    procedures for the following MIME facilities:
65
66     (1)   media types,
67
68     (2)   external body access types,
69
70     (3)   content-transfer-encodings.
71
72    Registration of character sets for use in MIME is covered elsewhere
73    and is no longer addressed by this document.
74
75    These documents are revisions of RFCs 1521 and 1522, which themselves
76    were revisions of RFCs 1341 and 1342.  An appendix in RFC 2049
77    describes differences and changes from previous versions.
78
79 Table of Contents
80
81    1. Introduction .........................................    3
82    2. Media Type Registration ..............................    4
83    2.1 Registration Trees and Subtype Names ................    4
84    2.1.1 IETF Tree .........................................    4
85    2.1.2 Vendor Tree .......................................    4
86    2.1.3 Personal or Vanity Tree ...........................    5
87    2.1.4 Special `x.' Tree .................................    5
88    2.1.5 Additional Registration Trees .....................    6
89    2.2 Registration Requirements ...........................    6
90    2.2.1 Functionality Requirement .........................    6
91    2.2.2 Naming Requirements ...............................    6
92    2.2.3 Parameter Requirements ............................    7
93    2.2.4 Canonicalization and Format Requirements ..........    7
94    2.2.5 Interchange Recommendations .......................    8
95    2.2.6 Security Requirements .............................    8
96    2.2.7 Usage and Implementation Non-requirements .........    9
97    2.2.8 Publication Requirements ..........................   10
98    2.2.9 Additional Information ............................   10
99    2.3 Registration Procedure ..............................   11
100    2.3.1 Present the Media Type to the Community for  Review   11
101    2.3.2 IESG Approval .....................................   12
102    2.3.3 IANA Registration .................................   12
103    2.4 Comments on Media Type Registrations ................   12
104    2.5 Location of Registered Media Type List ..............   12
105    2.6 IANA Procedures for Registering Media Types .........   12
106    2.7 Change Control ......................................   13
107    2.8 Registration Template ...............................   14
108    3. External Body Access Types ...........................   14
109    3.1 Registration Requirements ...........................   15
110    3.1.1 Naming Requirements ...............................   15
111
112
113
114 Freed, et. al.           Best Current Practice                  [Page 2]
115 \f
116 RFC 2048              MIME Registration Procedures         November 1996
117
118
119    3.1.2 Mechanism Specification Requirements ..............   15
120    3.1.3 Publication Requirements ..........................   15
121    3.1.4 Security Requirements .............................   15
122    3.2 Registration Procedure ..............................   15
123    3.2.1 Present the Access Type to the Community ..........   16
124    3.2.2 Access Type Reviewer ..............................   16
125    3.2.3 IANA Registration .................................   16
126    3.3 Location of Registered Access Type List .............   16
127    3.4 IANA Procedures for Registering Access Types ........   16
128    4. Transfer Encodings ...................................   17
129    4.1 Transfer Encoding Requirements ......................   17
130    4.1.1 Naming Requirements ...............................   17
131    4.1.2 Algorithm Specification Requirements ..............   18
132    4.1.3 Input Domain Requirements .........................   18
133    4.1.4 Output Range Requirements .........................   18
134    4.1.5 Data Integrity and Generality Requirements ........   18
135    4.1.6 New Functionality Requirements ....................   18
136    4.2 Transfer Encoding Definition Procedure ..............   19
137    4.3 IANA Procedures for Transfer Encoding Registration...   19
138    4.4 Location of Registered Transfer Encodings List ......   19
139    5. Authors' Addresses ...................................   20
140    A. Grandfathered Media Types ............................   21
141
142 1.  Introduction
143
144    Recent Internet protocols have been carefully designed to be easily
145    extensible in certain areas.  In particular, MIME [RFC 2045] is an
146    open-ended framework and can accommodate additional object types,
147    character sets, and access methods without any changes to the basic
148    protocol.  A registration process is needed, however, to ensure that
149    the set of such values is developed in an orderly, well-specified,
150    and public manner.
151
152    This document defines registration procedures which use the Internet
153    Assigned Numbers Authority (IANA) as a central registry for such
154    values.
155
156    Historical Note: The registration process for media types was
157    initially defined in the context of the asynchronous Internet mail
158    environment.  In this mail environment there is a need to limit the
159    number of possible media types to increase the likelihood of
160    interoperability when the capabilities of the remote mail system are
161    not known.  As media types are used in new environments, where the
162    proliferation of media types is not a hindrance to interoperability,
163    the original procedure was excessively restrictive and had to be
164    generalized.
165
166
167
168
169
170 Freed, et. al.           Best Current Practice                  [Page 3]
171 \f
172 RFC 2048              MIME Registration Procedures         November 1996
173
174
175 2.  Media Type Registration
176
177    Registration of a new media type or types starts with the
178    construction of a registration proposal.  Registration may occur in
179    several different registration trees, which have different
180    requirements as discussed below.  In general, the new registration
181    proposal is circulated and reviewed in a fashion appropriate to the
182    tree involved.  The media type is then registered if the proposal is
183    acceptable.  The following sections describe the requirements and
184    procedures used for each of the different registration trees.
185
186 2.1.  Registration Trees and Subtype Names
187
188    In order to increase the efficiency and flexibility of the
189    registration process, different structures of subtype names may be
190    registered to accomodate the different natural requirements for,
191    e.g., a subtype that will be recommended for wide support and
192    implementation by the Internet Community or a subtype that is used to
193    move files associated with proprietary software.  The following
194    subsections define registration "trees", distinguished by the use of
195    faceted names (e.g., names of the form "tree.subtree...type").  Note
196    that some media types defined prior to this document do not conform
197    to the naming conventions described below.  See Appendix A for a
198    discussion of them.
199
200 2.1.1.  IETF Tree
201
202    The IETF tree is intended for types of general interest to the
203    Internet Community. Registration in the IETF tree requires approval
204    by the IESG and publication of the media type registration as some
205    form of RFC.
206
207    Media types in the IETF tree are normally denoted by names that are
208    not explicitly faceted, i.e., do not contain period (".", full stop)
209    characters.
210
211    The "owner" of a media type registration in the IETF tree is assumed
212    to be the IETF itself.  Modification or alteration of the
213    specification requires the same level of processing (e.g.  standards
214    track) required for the initial registration.
215
216 2.1.2.  Vendor Tree
217
218    The vendor tree is used for media types associated with commercially
219    available products.  "Vendor" or "producer" are construed as
220    equivalent and very broadly in this context.
221
222
223
224
225
226 Freed, et. al.           Best Current Practice                  [Page 4]
227 \f
228 RFC 2048              MIME Registration Procedures         November 1996
229
230
231    A registration may be placed in the vendor tree by anyone who has
232    need to interchange files associated with the particular product.
233    However, the registration formally belongs to the vendor or
234    organization producing the software or file format.  Changes to the
235    specification will be made at their request, as discussed in
236    subsequent sections.
237
238    Registrations in the vendor tree will be distinguished by the leading
239    facet "vnd.".  That may be followed, at the discretion of the
240    registration, by either a media type name from a well-known producer
241    (e.g., "vnd.mudpie") or by an IANA-approved designation of the
242    producer's name which is then followed by a media type or product
243    designation (e.g., vnd.bigcompany.funnypictures).
244
245    While public exposure and review of media types to be registered in
246    the vendor tree is not required, using the ietf-types list for review
247    is strongly encouraged to improve the quality of those
248    specifications. Registrations in the vendor tree may be submitted
249    directly to the IANA.
250
251 2.1.3.  Personal or Vanity Tree
252
253    Registrations for media types created experimentally or as part of
254    products that are not distributed commercially may be registered in
255    the personal or vanity tree.  The registrations are distinguished by
256    the leading facet "prs.".
257
258    The owner of "personal" registrations and associated specifications
259    is the person or entity making the registration, or one to whom
260    responsibility has been transferred as described below.
261
262    While public exposure and review of media types to be registered in
263    the personal tree is not required, using the ietf-types list for
264    review is strongly encouraged to improve the quality of those
265    specifications.  Registrations in the personl tree may be submitted
266    directly to the IANA.
267
268 2.1.4.  Special `x.' Tree
269
270    For convenience and symmetry with this registration scheme, media
271    type names with "x." as the first facet may be used for the same
272    purposes for which names starting in "x-" are normally used.  These
273    types are unregistered, experimental, and should be used only with
274    the active agreement of the parties exchanging them.
275
276
277
278
279
280
281
282 Freed, et. al.           Best Current Practice                  [Page 5]
283 \f
284 RFC 2048              MIME Registration Procedures         November 1996
285
286
287    However, with the simplified registration procedures described above
288    for vendor and personal trees, it should rarely, if ever, be
289    necessary to use unregistered experimental types, and as such use of
290    both "x-" and "x." forms is discouraged.
291
292 2.1.5.  Additional Registration Trees
293
294    From time to time and as required by the community, the IANA may,
295    with the advice and consent of the IESG, create new top-level
296    registration trees.  It is explicitly assumed that these trees may be
297    created for external registration and management by well-known
298    permanent bodies, such as scientific societies for media types
299    specific to the sciences they cover.  In general, the quality of
300    review of specifications for one of these additional registration
301    trees is expected to be equivalent to that which IETF would give to
302    registrations in its own tree. Establishment of these new trees will
303    be announced through RFC publication approved by the IESG.
304
305 2.2.  Registration Requirements
306
307    Media type registration proposals are all expected to conform to
308    various requirements laid out in the following sections.  Note that
309    requirement specifics sometimes vary depending on the registration
310    tree, again as detailed in the following sections.
311
312 2.2.1.  Functionality Requirement
313
314    Media types must function as an actual media format: Registration of
315    things that are better thought of as a transfer encoding, as a
316    character set, or as a collection of separate entities of another
317    type, is not allowed.  For example, although applications exist to
318    decode the base64 transfer encoding [RFC 2045], base64 cannot be
319    registered as a media type.
320
321    This requirement applies regardless of the registration tree
322    involved.
323
324 2.2.2.  Naming Requirements
325
326    All registered media types must be assigned MIME type and subtype
327    names. The combination of these names then serves to uniquely
328    identify the media type and the format of the subtype name identifies
329    the registration tree.
330
331    The choice of top-level type name must take the nature of media type
332    involved into account. For example, media normally used for
333    representing still images should be a subtype of the image content
334    type, whereas media capable of representing audio information belongs
335
336
337
338 Freed, et. al.           Best Current Practice                  [Page 6]
339 \f
340 RFC 2048              MIME Registration Procedures         November 1996
341
342
343    under the audio content type. See RFC 2046 for additional information
344    on the basic set of top-level types and their characteristics.
345
346    New subtypes of top-level types must conform to the restrictions of
347    the top-level type, if any. For example, all subtypes of the
348    multipart content type must use the same encapsulation syntax.
349
350    In some cases a new media type may not "fit" under any currently
351    defined top-level content type. Such cases are expected to be quite
352    rare. However, if such a case arises a new top-level type can be
353    defined to accommodate it. Such a definition must be done via
354    standards-track RFC; no other mechanism can be used to define
355    additional top-level content types.
356
357    These requirements apply regardless of the registration tree
358    involved.
359
360 2.2.3.  Parameter Requirements
361
362    Media types may elect to use one or more MIME content type
363    parameters, or some parameters may be automatically made available to
364    the media type by virtue of being a subtype of a content type that
365    defines a set of parameters applicable to any of its subtypes.  In
366    either case, the names, values, and meanings of any parameters must
367    be fully specified when a media type is registered in the IETF tree,
368    and should be specified as completely as possible when media types
369    are registered in the vendor or personal trees.
370
371    New parameters must not be defined as a way to introduce new
372    functionality in types registered in the IETF tree, although new
373    parameters may be added to convey additional information that does
374    not otherwise change existing functionality.  An example of this
375    would be a "revision" parameter to indicate a revision level of an
376    external specification such as JPEG.  Similar behavior is encouraged
377    for media types registered in the vendor or personal trees but is not
378    required.
379
380 2.2.4.  Canonicalization and Format Requirements
381
382    All registered media types must employ a single, canonical data
383    format, regardless of registration tree.
384
385    A precise and openly available specification of the format of each
386    media type is required for all types registered in the IETF tree and
387    must at a minimum be referenced by, if it isn't actually included in,
388    the media type registration proposal itself.
389
390
391
392
393
394 Freed, et. al.           Best Current Practice                  [Page 7]
395 \f
396 RFC 2048              MIME Registration Procedures         November 1996
397
398
399    The specifications of format and processing particulars may or may
400    not be publically available for media types registered in the vendor
401    tree, and such registration proposals are explicitly permitted to
402    include only a specification of which software and version produce or
403    process such media types.  References to or inclusion of format
404    specifications in registration proposals is encouraged but not
405    required.
406
407    Format specifications are still required for registration in the
408    personal tree, but may be either published as RFCs or otherwise
409    deposited with IANA. The deposited specifications will meet the same
410    criteria as those required to register a well-known TCP port and, in
411    particular, need not be made public.
412
413    Some media types involve the use of patented technology.  The
414    registration of media types involving patented technology is
415    specifically permitted.  However, the restrictions set forth in RFC
416    1602 on the use of patented technology in standards-track protocols
417    must be respected when the specification of a media type is part of a
418    standards-track protocol.
419
420 2.2.5.  Interchange Recommendations
421
422    Media types should, whenever possible, interoperate across as many
423    systems and applications as possible. However, some media types will
424    inevitably have problems interoperating across different platforms.
425    Problems with different versions, byte ordering, and specifics of
426    gateway handling can and will arise.
427
428    Universal interoperability of media types is not required, but known
429    interoperability issues should be identified whenever possible.
430    Publication of a media type does not require an exhaustive review of
431    interoperability, and the interoperability considerations section is
432    subject to continuing evaluation.
433
434    These recommendations apply regardless of the registration tree
435    involved.
436
437 2.2.6.  Security Requirements
438
439    An analysis of security issues is required for for all types
440    registered in the IETF Tree.  (This is in accordance with the basic
441    requirements for all IETF protocols.) A similar analysis for media
442    types registered in the vendor or personal trees is encouraged but
443    not required.  However, regardless of what security analysis has or
444    has not been done, all descriptions of security issues must be as
445    accurate as possible regardless of registration tree.  In particular,
446    a statement that there are "no security issues associated with this
447
448
449
450 Freed, et. al.           Best Current Practice                  [Page 8]
451 \f
452 RFC 2048              MIME Registration Procedures         November 1996
453
454
455    type" must not be confused with "the security issues associates with
456    this type have not been assessed".
457
458    There is absolutely no requirement that media types registered in any
459    tree be secure or completely free from risks.  Nevertheless, all
460    known security risks must be identified in the registration of a
461    media type, again regardless of registration tree.
462
463    The security considerations section of all registrations is subject
464    to continuing evaluation and modification, and in particular may be
465    extended by use of the "comments on media types" mechanism described
466    in subsequent sections.
467
468    Some of the issues that should be looked at in a security analysis of
469    a media type are:
470
471     (1)   Complex media types may include provisions for
472           directives that institute actions on a recipient's
473           files or other resources.  In many cases provision is
474           made for originators to specify arbitrary actions in an
475           unrestricted fashion which may then have devastating
476           effects.  See the registration of the
477           application/postscript media type in RFC 2046 for
478           an example of such directives and how to handle them.
479
480     (2)   Complex media types may include provisions for
481           directives that institute actions which, while not
482           directly harmful to the recipient, may result in
483           disclosure of information that either facilitates a
484           subsequent attack or else violates a recipient's
485           privacy in some way.  Again, the registration of the
486           application/postscript media type illustrates how such
487           directives can be handled.
488
489     (3)   A media type might be targeted for applications that
490           require some sort of security assurance but not provide
491           the necessary security mechanisms themselves. For
492           example, a media type could be defined for storage of
493           confidential medical information which in turn requires
494           an external confidentiality service.
495
496 2.2.7.  Usage and Implementation Non-requirements
497
498    In the asynchronous mail environment, where information on the
499    capabilities of the remote mail agent is frequently not available to
500    the sender, maximum interoperability is attained by restricting the
501    number of media types used to those "common" formats expected to be
502    widely implemented.  This was asserted in the past as a reason to
503
504
505
506 Freed, et. al.           Best Current Practice                  [Page 9]
507 \f
508 RFC 2048              MIME Registration Procedures         November 1996
509
510
511    limit the number of possible media types and resulted in a
512    registration process with a significant hurdle and delay for those
513    registering media types.
514
515    However, the need for "common" media types does not require limiting
516    the registration of new media types. If a limited set of media types
517    is recommended for a particular application, that should be asserted
518    by a separate applicability statement specific for the application
519    and/or environment.
520
521    As such, universal support and implementation of a media type is NOT
522    a requirement for registration.  If, however, a media type is
523    explicitly intended for limited use, this should be noted in its
524    registration.
525
526 2.2.8.  Publication Requirements
527
528    Proposals for media types registered in the IETF tree must be
529    published as RFCs. RFC publication of vendor and personal media type
530    proposals is encouraged but not required. In all cases IANA will
531    retain copies of all media type proposals and "publish" them as part
532    of the media types registration tree itself.
533
534    Other than in the IETF tree, the registration of a data type does not
535    imply endorsement, approval, or recommendation by IANA or IETF or
536    even certification that the specification is adequate.  To become
537    Internet Standards, protocol, data objects, or whatever must go
538    through the IETF standards process.  This is too difficult and too
539    lengthy a process for the convenient registration of media types.
540
541    The IETF tree exists for media types that do require require a
542    substantive review and approval process with the vendor and personal
543    trees exist for those that do not. It is expected that applicability
544    statements for particular applications will be published from time to
545    time that recommend implementation of, and support for, media types
546    that have proven particularly useful in those contexts.
547
548    As discussed above, registration of a top-level type requires
549    standards-track processing and, hence, RFC publication.
550
551 2.2.9.  Additional Information
552
553    Various sorts of optional information may be included in the
554    specification of a media type if it is available:
555
556     (1)   Magic number(s) (length, octet values). Magic numbers
557           are byte sequences that are always present and thus can
558           be used to identify entities as being of a given media
559
560
561
562 Freed, et. al.           Best Current Practice                 [Page 10]
563 \f
564 RFC 2048              MIME Registration Procedures         November 1996
565
566
567           type.
568
569     (2)   File extension(s) commonly used on one or more
570           platforms to indicate that some file containing a given
571           type of media.
572
573     (3)   Macintosh File Type code(s) (4 octets) used to label
574           files containing a given type of media.
575
576    Such information is often quite useful to implementors and if
577    available should be provided.
578
579 2.3.  Registration Procedure
580
581    The following procedure has been implemented by the IANA for review
582    and approval of new media types.  This is not a formal standards
583    process, but rather an administrative procedure intended to allow
584    community comment and sanity checking without excessive time delay.
585    For registration in the IETF tree, the normal IETF processes should
586    be followed, treating posting of an internet-draft and announcement
587    on the ietf-types list (as described in the next subsection) as a
588    first step.  For registrations in the vendor or personal tree, the
589    initial review step described below may be omitted and the type
590    registered directly by submitting the template and an explanation
591    directly to IANA (at iana@iana.org).  However, authors of vendor or
592    personal media type specifications are encouraged to seek community
593    review and comment whenever that is feasible.
594
595 2.3.1.  Present the Media Type to the Community for Review
596
597    Send a proposed media type registration to the "ietf-types@iana.org"
598    mailing list for a two week review period.  This mailing list has
599    been established for the purpose of reviewing proposed media and
600    access types. Proposed media types are not formally registered and
601    must not be used; the "x-" prefix specified in RFC 2045 can be used
602    until registration is complete.
603
604    The intent of the public posting is to solicit comments and feedback
605    on the choice of type/subtype name, the unambiguity of the references
606    with respect to versions and external profiling information, and a
607    review of any interoperability or security considerations. The
608    submitter may submit a revised registration, or withdraw the
609    registration completely, at any time.
610
611
612
613
614
615
616
617
618 Freed, et. al.           Best Current Practice                 [Page 11]
619 \f
620 RFC 2048              MIME Registration Procedures         November 1996
621
622
623 2.3.2.  IESG Approval
624
625    Media types registered in the IETF tree must be submitted to the IESG
626    for approval.
627
628 2.3.3.  IANA Registration
629
630    Provided that the media type meets the requirements for media types
631    and has obtained approval that is necessary, the author may submit
632    the registration request to the IANA, which will register the media
633    type and make the media type registration available to the community.
634
635 2.4.  Comments on Media Type Registrations
636
637    Comments on registered media types may be submitted by members of the
638    community to IANA.  These comments will be passed on to the "owner"
639    of the media type if possible.  Submitters of comments may request
640    that their comment be attached to the media type registration itself,
641    and if IANA approves of this the comment will be made accessible in
642    conjunction with the type registration itself.
643
644 2.5.  Location of Registered Media Type List
645
646    Media type registrations will be posted in the anonymous FTP
647    directory "ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/"
648    and all registered media types will be listed in the periodically
649    issued "Assigned Numbers" RFC [currently STD 2, RFC 1700].  The media
650    type description and other supporting material may also be published
651    as an Informational RFC by sending it to "rfc-editor@isi.edu" (please
652    follow the instructions to RFC authors [RFC-1543]).
653
654 2.6.  IANA Procedures for Registering Media Types
655
656    The IANA will only register media types in the IETF tree in response
657    to a communication from the IESG stating that a given registration
658    has been approved. Vendor and personal types will be registered by
659    the IANA automatically and without any formal review as long as the
660    following minimal conditions are met:
661
662     (1)   Media types must function as an actual media format.
663           In particular, character sets and transfer encodings
664           may not be registered as media types.
665
666     (2)   All media types must have properly formed type and
667           subtype names. All type names must be defined by a
668           standards-track RFC. All subtype names must be unique,
669           must conform to the MIME grammar for such names, and
670           must contain the proper tree prefix.
671
672
673
674 Freed, et. al.           Best Current Practice                 [Page 12]
675 \f
676 RFC 2048              MIME Registration Procedures         November 1996
677
678
679     (3)   Types registered in the personal tree must either
680           provide a format specification or a pointer to one.
681
682     (4)   Any security considerations given must not be obviously
683           bogus. (It is neither possible nor necessary for the
684           IANA to conduct a comprehensive security review of
685           media type registrations.  Nevertheless, IANA has the
686           authority to identify obviously incompetent material
687           and exclude it.)
688
689 2.7.  Change Control
690
691    Once a media type has been published by IANA, the author may request
692    a change to its definition. The descriptions of the different
693    registration trees above designate the "owners" of each type of
694    registration. The change request follows the same procedure as the
695    registration request:
696
697     (1)   Publish the revised template on the ietf-types list.
698
699     (2)   Leave at least two weeks for comments.
700
701     (3)   Publish using IANA after formal review if required.
702
703    Changes should be requested only when there are serious omission or
704    errors in the published specification. When review is required, a
705    change request may be denied if it renders entities that were valid
706    under the previous definition invalid under the new definition.
707
708    The owner of a content type may pass responsibility for the content
709    type to another person or agency by informing IANA and the ietf-types
710    list; this can be done without discussion or review.
711
712    The IESG may reassign responsibility for a media type. The most
713    common case of this will be to enable changes to be made to types
714    where the author of the registration has died, moved out of contact
715    or is otherwise unable to make changes that are important to the
716    community.
717
718    Media type registrations may not be deleted; media types which are no
719    longer believed appropriate for use can be declared OBSOLETE by a
720    change to their "intended use" field; such media types will be
721    clearly marked in the lists published by IANA.
722
723
724
725
726
727
728
729
730 Freed, et. al.           Best Current Practice                 [Page 13]
731 \f
732 RFC 2048              MIME Registration Procedures         November 1996
733
734
735 2.8.  Registration Template
736
737      To: ietf-types@iana.org
738      Subject: Registration of MIME media type XXX/YYY
739
740      MIME media type name:
741
742      MIME subtype name:
743
744      Required parameters:
745
746      Optional parameters:
747
748      Encoding considerations:
749
750      Security considerations:
751
752      Interoperability considerations:
753
754      Published specification:
755
756      Applications which use this media type:
757
758      Additional information:
759
760        Magic number(s):
761        File extension(s):
762        Macintosh File Type Code(s):
763
764      Person & email address to contact for further information:
765
766      Intended usage:
767
768      (One of COMMON, LIMITED USE or OBSOLETE)
769
770      Author/Change controller:
771
772      (Any other information that the author deems interesting may be
773      added below this line.)
774
775 3.  External Body Access Types
776
777    RFC 2046 defines the message/external-body media type, whereby a MIME
778    entity can act as pointer to the actual body data in lieu of
779    including the data directly in the entity body. Each
780    message/external-body reference specifies an access type, which
781    determines the mechanism used to retrieve the actual body data. RFC
782    2046 defines an initial set of access types, but allows for the
783
784
785
786 Freed, et. al.           Best Current Practice                 [Page 14]
787 \f
788 RFC 2048              MIME Registration Procedures         November 1996
789
790
791    registration of additional access types to accommodate new retrieval
792    mechanisms.
793
794 3.1.  Registration Requirements
795
796    New access type specifications must conform to a number of
797    requirements as described below.
798
799 3.1.1.  Naming Requirements
800
801    Each access type must have a unique name.  This name appears in the
802    access-type parameter in the message/external-body content-type
803    header field, and must conform to MIME content type parameter syntax.
804
805 3.1.2.  Mechanism Specification Requirements
806
807    All of the protocols, transports, and procedures used by a given
808    access type must be described, either in the specification of the
809    access type itself or in some other publicly available specification,
810    in sufficient detail for the access type to be implemented by any
811    competent implementor.  Use of secret and/or proprietary methods in
812    access types are expressly prohibited. The restrictions imposed by
813    RFC 1602 on the standardization of patented algorithms must be
814    respected as well.
815
816 3.1.3.  Publication Requirements
817
818    All access types must be described by an RFC. The RFC may be
819    informational rather than standards-track, although standard-track
820    review and approval are encouraged for all access types.
821
822 3.1.4.  Security Requirements
823
824    Any known security issues that arise from the use of the access type
825    must be completely and fully described. It is not required that the
826    access type be secure or that it be free from risks, but that the
827    known risks be identified.  Publication of a new access type does not
828    require an exhaustive security review, and the security
829    considerations section is subject to continuing evaluation.
830    Additional security considerations should be addressed by publishing
831    revised versions of the access type specification.
832
833 3.2.  Registration Procedure
834
835    Registration of a new access type starts with the construction of a
836    draft of an RFC.
837
838
839
840
841
842 Freed, et. al.           Best Current Practice                 [Page 15]
843 \f
844 RFC 2048              MIME Registration Procedures         November 1996
845
846
847 3.2.1.  Present the Access Type to the Community
848
849    Send a proposed access type specification to the "ietf-
850    types@iana.org" mailing list for a two week review period.  This
851    mailing list has been established for the purpose of reviewing
852    proposed access and media types.  Proposed access types are not
853    formally registered and must not be used.
854
855    The intent of the public posting is to solicit comments and feedback
856    on the access type specification and a review of any security
857    considerations.
858
859 3.2.2.  Access Type Reviewer
860
861    When the two week period has passed, the access type reviewer, who is
862    appointed by the IETF Applications Area Director, either forwards the
863    request to iana@isi.edu, or rejects it because of significant
864    objections raised on the list.
865
866    Decisions made by the reviewer must be posted to the ietf-types
867    mailing list within 14 days. Decisions made by the reviewer may be
868    appealed to the IESG.
869
870 3.2.3.  IANA Registration
871
872    Provided that the access type has either passed review or has been
873    successfully appealed to the IESG, the IANA will register the access
874    type and make the registration available to the community. The
875    specification of the access type must also be published as an RFC.
876    Informational RFCs are published by sending them to "rfc-
877    editor@isi.edu" (please follow the instructions to RFC authors [RFC-
878    1543]).
879
880 3.3.  Location of Registered Access Type List
881
882    Access type registrations will be posted in the anonymous FTP
883    directory "ftp://ftp.isi.edu/in-notes/iana/assignments/access-types/"
884    and all registered access types will be listed in the periodically
885    issued "Assigned Numbers" RFC [currently RFC-1700].
886
887 3.4.  IANA Procedures for Registering Access Types
888
889    The identity of the access type reviewer is communicated to the IANA
890    by the IESG.  The IANA then only acts in response to access type
891    definitions that either are approved by the access type reviewer and
892    forwarded by the reviewer to the IANA for registration, or in
893    response to a communication from the IESG that an access type
894    definition appeal has overturned the access type reviewer's ruling.
895
896
897
898 Freed, et. al.           Best Current Practice                 [Page 16]
899 \f
900 RFC 2048              MIME Registration Procedures         November 1996
901
902
903 4.  Transfer Encodings
904
905    Transfer encodings are tranformations applied to MIME media types
906    after conversion to the media type's canonical form.  Transfer
907    encodings are used for several purposes:
908
909     (1)   Many transports, especially message transports, can
910           only handle data consisting of relatively short lines
911           of text. There can also be severe restrictions on what
912           characters can be used in these lines of text -- some
913           transports are restricted to a small subset of US-ASCII
914           and others cannot handle certain character sequences.
915           Transfer encodings are used to transform binary data
916           into textual form that can survive such transports.
917           Examples of this sort of transfer encoding include the
918           base64 and quoted-printable transfer encodings defined
919           in RFC 2045.
920
921     (2)   Image, audio, video, and even application entities are
922           sometimes quite large. Compression algorithms are often
923           quite effective in reducing the size of large entities.
924           Transfer encodings can be used to apply general-purpose
925           non-lossy compression algorithms to MIME entities.
926
927     (3)   Transport encodings can be defined as a means of
928           representing existing encoding formats in a MIME
929           context.
930
931    IMPORTANT:  The standardization of a large numbers of different
932    transfer encodings is seen as a significant barrier to widespread
933    interoperability and is expressely discouraged.  Nevertheless, the
934    following procedure has been defined to provide a means of defining
935    additional transfer encodings, should standardization actually be
936    justified.
937
938 4.1.  Transfer Encoding Requirements
939
940    Transfer encoding specifications must conform to a number of
941    requirements as described below.
942
943 4.1.1.  Naming Requirements
944
945    Each transfer encoding must have a unique name.  This name appears in
946    the Content-Transfer-Encoding header field and must conform to the
947    syntax of that field.
948
949
950
951
952
953
954 Freed, et. al.           Best Current Practice                 [Page 17]
955 \f
956 RFC 2048              MIME Registration Procedures         November 1996
957
958
959 4.1.2.  Algorithm Specification Requirements
960
961    All of the algorithms used in a transfer encoding (e.g.  conversion
962    to printable form, compression) must be described in their entirety
963    in the transfer encoding specification.  Use of secret and/or
964    proprietary algorithms in standardized transfer encodings are
965    expressly prohibited. The restrictions imposed by RFC 1602 on the
966    standardization of patented algorithms must be respected as well.
967
968 4.1.3.  Input Domain Requirements
969
970    All transfer encodings must be applicable to an arbitrary sequence of
971    octets of any length.  Dependence on particular input forms is not
972    allowed.
973
974    It should be noted that the 7bit and 8bit encodings do not conform to
975    this requirement. Aside from the undesireability of having
976    specialized encodings, the intent here is to forbid the addition of
977    additional encodings along the lines of 7bit and 8bit.
978
979 4.1.4.  Output Range Requirements
980
981    There is no requirement that a particular tranfer encoding produce a
982    particular form of encoded output.  However, the output format for
983    each transfer encoding must be fully and completely documented.  In
984    particular, each specification must clearly state whether the output
985    format always lies within the confines of 7bit data, 8bit data, or is
986    simply pure binary data.
987
988 4.1.5.  Data Integrity and Generality Requirements
989
990    All transfer encodings must be fully invertible on any platform; it
991    must be possible for anyone to recover the original data by
992    performing the corresponding decoding operation.  Note that this
993    requirement effectively excludes all forms of lossy compression as
994    well as all forms of encryption from use as a transfer encoding.
995
996 4.1.6.  New Functionality Requirements
997
998    All transfer encodings must provide some sort of new functionality.
999    Some degree of functionality overlap with previously defined transfer
1000    encodings is acceptable, but any new transfer encoding must also
1001    offer something no other transfer encoding provides.
1002
1003
1004
1005
1006
1007
1008
1009
1010 Freed, et. al.           Best Current Practice                 [Page 18]
1011 \f
1012 RFC 2048              MIME Registration Procedures         November 1996
1013
1014
1015 4.2.  Transfer Encoding Definition Procedure
1016
1017    Definition of a new transfer encoding starts with the construction of
1018    a draft of a standards-track RFC.  The RFC must define the transfer
1019    encoding precisely and completely, and must also provide substantial
1020    justification for defining and standardizing a new transfer encoding.
1021    This specification must then be presented to the IESG for
1022    consideration.  The IESG can
1023
1024     (1)   reject the specification outright as being
1025           inappropriate for standardization,
1026
1027     (2)   approve the formation of an IETF working group to work
1028           on the specification in accordance with IETF
1029           procedures, or,
1030
1031     (3)   accept the specification as-is and put it directly on
1032           the standards track.
1033
1034    Transfer encoding specifications on the standards track follow normal
1035    IETF rules for standards track documents.  A transfer encoding is
1036    considered to be defined and available for use once it is on the
1037    standards track.
1038
1039 4.3.  IANA Procedures for Transfer Encoding Registration
1040
1041    There is no need for a special procedure for registering Transfer
1042    Encodings with the IANA. All legitimate transfer encoding
1043    registrations must appear as a standards-track RFC, so it is the
1044    IESG's responsibility to notify the IANA when a new transfer encoding
1045    has been approved.
1046
1047 4.4.  Location of Registered Transfer Encodings List
1048
1049    Transfer encoding registrations will be posted in the anonymous FTP
1050    directory "ftp://ftp.isi.edu/in-notes/iana/assignments/transfer-
1051    encodings/" and all registered transfer encodings will be listed in
1052    the periodically issued "Assigned Numbers" RFC [currently RFC-1700].
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066 Freed, et. al.           Best Current Practice                 [Page 19]
1067 \f
1068 RFC 2048              MIME Registration Procedures         November 1996
1069
1070
1071 5.  Authors' Addresses
1072
1073    For more information, the authors of this document are best
1074    contacted via Internet mail:
1075
1076    Ned Freed
1077    Innosoft International, Inc.
1078    1050 East Garvey Avenue South
1079    West Covina, CA 91790
1080    USA
1081
1082    Phone: +1 818 919 3600
1083    Fax:   +1 818 919 3614
1084    EMail: ned@innosoft.com
1085
1086
1087    John Klensin
1088    MCI
1089    2100 Reston Parkway
1090    Reston, VA 22091
1091
1092    Phone: +1 703 715-7361
1093    Fax:   +1 703 715-7436
1094    EMail: klensin@mci.net
1095
1096
1097    Jon Postel
1098    USC/Information Sciences Institute
1099    4676 Admiralty Way
1100    Marina del Rey, CA  90292
1101    USA
1102
1103
1104    Phone: +1 310 822 1511
1105    Fax:   +1 310 823 6714
1106    EMail: Postel@ISI.EDU
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122 Freed, et. al.           Best Current Practice                 [Page 20]
1123 \f
1124 RFC 2048              MIME Registration Procedures         November 1996
1125
1126
1127 Appendix A -- Grandfathered Media Types
1128
1129    A number of media types, registered prior to 1996, would, if
1130    registered under the guidelines in this document, be placed into
1131    either the vendor or personal trees.  Reregistration of those types
1132    to reflect the appropriate trees is encouraged, but not required.
1133    Ownership and change control principles outlined in this document
1134    apply to those types as if they had been registered in the trees
1135    described above.
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179 Freed, et. al.           Best Current Practice                 [Page 21]
1180 \f