> Date: 2005-07-01 07:57
> From: Colin Perkins <csp@xxxxxxxxxxxxx>
> The idea of using the MIME media types registry to identify types
> that are carried predominantly by RTP was suggested at a meeting of
> the AVT working group, with participation from the applications area
> directors, in December 1997
[...]
> There has recently been concern expressed in some quarters about the
> use of media under the "text" top level media type within RTP.
While use of the MIME registry IETF tree may have seemed like a good idea
in '97, you are correct that there are concerns now. There are some
concerns in general, and some regarding text in particular, which is why...
> In
> particular, the update to RFC 2793 for Draft Standard RFC status was
> contentious, although it used the same text media type within RTP
> framing as the original RFC. Much of the concern seems to stem from
> the use of framed text media types, where the plain text media data
> is embedded within some binary wrapper for transport, since there is
> a belief that such data might "leak" into areas which don't
> understand the transport protocol in which the data is framed.
> I do not find this argument persuasive,
[...]
Leakage is an operational concern. There are also concerns about impact
on the registration procedures, the registries themselves, the review
process, and the impact on implementers (particularly on MIME
implementers, as RTP doesn't use MIME mechanisms and the brunt of the
impact of RTP registrations in the MIME registry is borne by MIME folk).
> Indeed,
> reliance on the property that unknown text formats can be treated as
> "text/plain" and displayed directly to the user would seem to be a
> security risk,[...] The use of framed media types
> does not change this property.
The property in question is part of the nature of MIME media types;
different top-level types have different distinguishing characteristics.
These characteristics provide benefit to implementers and users and
in turn restrict what can be registered under that top-level type
(top-level types can and have been added, and there are other media
type trees). There is not so much reliance on the properties as a
necessary symbiosis between the prescribed characteristics and types
registered under the text top-level type in the IETF tree. Those
characteristics include:
o "can be read without resorting to software that understands the
format. In particular, formats that employ embeddded [sic] binary
formatting information are not considered directly readable." [RFC2046]
o "to some extent readable even without the software that interprets
them. It is useful, then, to distinguish them, at the highest level,
from such unreadable data as images, audio, or text represented in an
unreadable form." [RFC2046]
o "In the absence of appropriate interpretation software, it is reasonable
to show subtypes of "text" to the user, while it is not reasonable to do
so with most nontextual data." [RFC2046]
o "The canonical form of any MIME "text" subtype MUST always represent a
line break as a CRLF sequence. Similarly, any occurrence of CRLF in
MIME "text" MUST represent a line break. Use of CR and LF outside of
line break sequences is also forbidden.
This rule applies regardless of format or character set or sets
involved." [RFC2046]
o a charset, defaulting to US-ASCII (paraphrased from RFC 2046 for brevity)
o "Unrecognized subtypes of "text" should be treated as subtype "plain"
as long as the MIME implementation knows how to handle the charset."
[RFC2046]
The symbiosis works both ways; MIME types must fit those characteristics
so that MIME implementations can take advantage of the fallback
mechanism and no need to invoke special processing -- conversely the
implementations can and have taken advantage of fallback and not having
to invoke special handling for text because the registration requirements
guarantee that those mechanisms are valid.
While the proposed RTP "text" types would present a small but non-zero
security risk, the essential properties of MIME text types of having the
characteristics above are not shared by the RTP types:
o clearly software which understands the format is required. The format
includes embedded binary formatting information
o not readable without software; indeed as pointed out, the RTP types
cannot even be save in a file format without conversion software
o it would be most unreasonable to try to present the RTP types without
appropriate interpretation software
o CRLF octets may appear in the RTP types (as binary data 0x0D0A) where
they do not represent a line ending. Note the BCP 14 "MUST" keyword
in the approved RFC 2046 text, indicating interoperability issues of
a serious nature (refer to BCP 14 section 6). [BCP14]
o the proposed RTP registrations provide no charset parameter, defaulting
to US-ASCII as far as MIME implementations are concerned
o fallback treatment as text plain is a problem for the RTP type because
of the incompatibilities above.
Now it's certainly true that the existence of an RTP type does not change
the properties expected of MIME IETF tree text media subtypes, but clearly
the RTP types do not share those properties. That would break the
guarantee of characteristics which are important to deployed MIME
implementations.
> With this in mind, I turn to the three possible registry futures
> presented in draft-iesg-media-type-00.txt. The second and third
> proposals in section 2 of the draft ("MIME handling is the model for
> other using protocols" and "Registry split") are both large and
> backwards incompatible changes. Either change would register the 71
> existing media types defined primarily for use with RTP framing
> obsolete. These changes would require significant amounts of new
> standards work, and would cause enormous confusion for users of RTP
> payload formats and SDP. It would also affect the extremely large
> deployed base of implementations.
It strikes me that many of the above statements are conjecture. In
principle, I see no backwards compatibility issues, a small amount of
standards work (registration procedures, primarily copy-and-paste),
and no need for confusion or effect on implementations. The simple
expedient of populating a separate RTP registry with "grandfathered"
copies of the relevant MIME registrations would obviate all of those
objections save the need for a registration procedure. The latter
could be achieved by copying Ned Freed's draft, making suitable
RTP-specific changes in one copy and removing RTP-specific items
from the other.
That would give the RTP vendors, implementers, and standards-writers
a clean sandbox to play in, prepared with exactly what is currently
of interest to RTP folk, unobscured by all that pesky MIME stuff with
its fallback rules and interoperability requirements.
Meanwhile, back in the MIME sandbox, there will remain some lumps of
RTP stuff -- there is no way to remove a media type, though they can
be marked as obsolete for MIME purposes. (RTPers can ignore the
markings in the MIME registry, and by migrating to the RTP registry
can ignore the MIME registry entirely) That's the bad news for MIME.
The good news is that further sullying of the MIME sandbox can be
avoided.
> The other option, "All media type protocols may specify handling", is
> the status quo. I believe this is the appropriate direction for the
> registry, although clarifications should be made to the registration
> rules, perhaps updating RFC 3555, to better explain how framed types
> are used.
That will have zero effect on the issues that keep coming up during
media type reviews. The concept is alien to MIME implementations.
> There are well defined and tested procedures for
> registering media types, an extremely large deployed base, and no
> history of problems with this approach.
If there were no problems, we wouldn't be here. Clearly there are
procedural and interoperability issues. There are also issues for
MIME implementers, though that appears to be of no concern to some
RTPers. Lack of concern on the part of some RTPers does not guarantee
a lack of problems for MIME implementers.
> The media types registry works well as currently specified. We have a
> large installed base, and well developed procedures. I do not believe
> it would be appropriate to make fundamental changes to these
> procedures or the registry at this late stage.
It is understandable that RTP folk might not appreciate the advantages
of a split; after all, they have not been affected by the problems
since they do not use MIME methods -- they simply use the form of the
namespace. The problems all fall on the heads of MIME implementers.
A split would require some RTP effort -- after all somebody is going
to have to make that copy of the registration draft, edit a few words,
and follow it through the IETF process.
There is one possible approach not detailed in the draft under discussion,
namely use of a separate tree in the registry, copying the RTP types to
that tree as described above for a separate registry. That would have the
advantage of not requiring a separate registry per se for what that's
worth, but would have the disadvantage of requiring RTP implementations
to adopt the corresponding different naming scheme (which would not be
necessary with a separate registry). I believe that that disadvantage to
the RTP folk, which would not affect MIME, would outweigh whatever
benefits there might be in a common registry per se. I doubt that it
would be of interest to RTPers, so I'll leave it to them to pursue if
they feel strongly that a shared registry is necessary -- that's the only
practical way that I can see that a shared registry can be maintained
without continuing the problems for MIME implementers and all reviewers
and registrants. Frankly, I think a separate registry would be best for
all concerned.
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types",
RFC 2046, November 1996.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf