Subject: Re: I-D ACTION:draft-iesg-media-type-00.txt

From: Bruce Lilly <[email-masked]>
Date: Fri, 1 Jul 2005 17:49:50 -0400

>  Date: 2005-07-01 07:57
>  From: Colin Perkins <[email-masked]>

> 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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Colin Perkins <[email-masked]>
Date: Sat, 2 Jul 2005 01:58:54 +0100

Considering the text/t140 media type (RFC 4103) which caused this  
controversy:

On 1 Jul 2005, at 22:49, Bruce Lilly wrote:
...
>   includes embedded binary formatting information

No, it does not. The format contains only plain UTF-8 text. You may  
be confused because the RFC describing the media type also explains  
how that type is to be transported within RTP, since several features  
of RTP are configured according to the media type parameters, and  
repeats the definition of the RTP headers.

>   cannot even be save in a file format without conversion software

The contents of the RTP packets are plain UTF-8 text. It can  
trivially be saved as a text/plain file, but doing so will lose the  
timing information provided by the RTP headers (it is the presence of  
the additional timing parameters that require this to be a separate  
media type to text/plain for use with RTP). There are other media  
types, under audio/* and video/* where this is a more complex  
process, but that does not affect this case.

>   appropriate interpretation software

One clearly needs an implementation of a transport protocol to  
receive data sent in that protocol. Once the data has been received  
from the transport protocol, the contents are plain UTF-8 text with  
implicit timing information.

>   a serious nature (refer to BCP 14 section 6). [BCP14]

The text/t140 format contains UTF-8 text. The CRLF octets are only  
used to represent a line ending, not in any other case, in  
conformance with these rules.

>   to US-ASCII as far as MIME implementations are concerned

The charset is always UTF-8 for text/t140. When signalled in SDP,  
there is also provision for a language tag.

>   of the incompatibilities above.

The content is plain UTF-8 text.

Colin