On Tue May 31 2005 15:50, Internet-Drafts(_at_)ietf(_dot_)org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Internet Engineering Steering Group Working
Group of the IETF.
Title : A question on Media Type Registrations
Author(s) : T. Hardie
Filename : draft-iesg-media-type-00.txt
Pages : 9
Date : 2005-5-31
This document poses a question to the community on the future of the
IANA Media Type Registry. It presents three potential future courses
of development and asks that feedback on these be provided to the
IESG.
Comments below. Public copy sent to the IETF discussion list (so other
IETFers can see the comments).
Nit: idnits reports an illegal control character (HTAB) on line 6,
character 28 of the draft.
Substantive comments:
MIME is heavily used by messaging applications such as email
[R1.RFC2822], [R2.RFC3501], [R3.RFC3464], [R4.RFC3798], [R5.RFC3886],
voice messaging [R6.RFC3801], EDI [R7.RFC1767], [R8.RFC1865], fax
[R9.RFC2159], [R10.RFC3949], ODA [R11.RFC2161], and content negotiation
[R12.RFC3297]. Basic Internet Messaging and services such as VPIM built
on top of that substrate comprise a core Internet application protocol.
MIME is also heavily used by HTTP [R13.RFC2616] and by services which
use HTTP as a substrate [R14.BCP56].
While there have been some distracting interoperability-related issues
caused by the differences between MIME as specified in the core MIME
specifications as used by messaging applications and the modified
specifications as used by HTTP [R15.CRLF], fortunately the differences
are not so great as to have led to major problems. The similarities,
for example handling of unrecognized subtypes of the text type, tend to
preclude major problems.
Recently however, use has been made of the MIME registry for media types
by protocols which do not otherwise use the core MIME specification
(e.g. Content-Type fields), and which may interact very badly with core
application protocols, including security implications. RFC 2046
defines the text type such that it is reasonable to present any text
type without special application processing (albeit perhaps with reduced
functionality), and the specified behavior is in fact to treat
unrecognized text subtypes with recognized charset (default us-ascii) as
if they were text/plain. Recent specification of binary,
application-specific content as subtypes under text can interact badly
with the specified MIME fallback behavior, not only resulting in a
degraded user experience (gibberish presentation), but may have dire
security implications (some presentation devices may react to binary
content containing certain octet sequences by interpreting those
sequences as device control sequences (e.g. ECMA 48 control sequences),
and that may have undesirable consequences (emulating input device
sequences, etc.)).
The draft under discussion presents three possible media type registry
future directions:
2.1. All media type protocols may specify handling
2.2. MIME handling is the model for other using protocols
2.3. Registry split
The first direction interacts poorly with widely deployed core Internet
application protocols as discussed above.
The second direction does not have that problem by explicitly requiring
consonance with MIME, but might be construed as prohibiting registration
of categories of things separate from MIME media types by protocols
which may have a need for such categories.
The third direction explicitly provides for separate registries as may
be desirable, but does not not preclude possibly-harmful additional
incompatible registrations in the MIME registry.
It is this reviewer's opinion that a combination of the second and third
directions seems desirable, i.e.
o Protect the widely-deployed applications protocol implementations
from incompatible registrations which may interact poorly with MIME
fallback mechanisms
o Provide for separate registries as may be desirable for non-MIME
use of categories of content analogous in their respective protocol
domains to the MIME media types.
References:
[R1.RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[R2.RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
VERSION 4rev1", RFC 3501, March 2003.
[R3.RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message
Format for Delivery Status Notifications", RFC 3464,
January 2003.
[R4.RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition
Notification", RFC 3798, May 2004.
[R5.RFC3886] Allman, E., "An Extensible Message Format for Message
Tracking Responses", RFC 3886, September 2004.
[R6.RFC3801] Vaudreuil, G. and G. Parsons, "Voice Profile for
Internet Mail - version 2 (VPIMv2)", RFC 3801, June
2004.
[R7.RFC1767] Crocker, D., "MIME Encapsulation of EDI Objects",
RFC 1767, March 1995.
[R8.RFC1865] Houser, W., Griffin, J., and C. Hage, "EDI Meets the
Internet Frequently Asked Questions about Electronic
Data Interchange (EDI) on the Internet", RFC 1865,
January 1996.
[R9.RFC2159] Alvestrand, H., "A MIME Body Part for FAX", RFC 2159,
January 1998.
[R10.RFC3949] Buckley, R., Venable, D., McIntyre, L., Parsons, G.,
and J. Rafferty, "File Format for Internet Fax",
RFC 3949, February 2005.
[R11.RFC2161] Alvestrand, H., "A MIME Body Part for ODA", RFC 2161,
January 1998.
[R12.RFC3297] Klyne, G., Iwazaki, R., and D. Crocker, "Content
Negotiation for Messaging Services based on Email",
RFC 3297, July 2002.
[R13.RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[R14.BCP56] Moore, K., "On the use of HTTP as a Substrate", BCP 56,
RFC 3205, February 2002.
[R15.CRLF] http://www.imc.org/ietf-smtp/mail-archive/msg01646.html
et seq.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf