> Date: Tue, 12 Apr 2005 21:20:28 +0100
> From: Colin Perkins <csp@xxxxxxxxxxxxx>
> Message-ID: <c8c3d491c54371c30af777f7ceb38dfb@xxxxxxxxxxxxx>
> | RFC 3555 allows media types to be defined for transport only via RTP.
> | The majority of these registrations are under the audio and video
> | top-level types, with a small number being under text. Is your
> | objection to any media type being defined only for transport via RTP,
> | or to text media types being defined only for transport via RTP?
> Not to either of those being attempted, but to the expectation that the
> "only via RTP" will, or can, ever be enforced.
Exactly so. This is why I've been pushing back on this. Stuff slops from one
application/transport to another all the time.
> That is, to your earlier statement ...
> Sure, but if the display agent is unaware of the restrictions, it won't
> ever be able to receive the media data.
> You'd need to be able to show me how that can possibly be true, when I
> can trivially easily send e-mail with text/t140 in the Content-Type header.
Two points:
(1) IMO text/t140 content actually conforms pretty well to the restrictions on
the text top-level type. In particular, text/t140 material basically
consists of unadorned UTF-8 text. There are a couple of control characters
used for special purposes, but we're not talking about HTML here or
anything similar.
(2) The place where text/t140 parts ways with other media type usage is in
how it is encoded. text/t140 cannot be encoded as a simple series
of octets. Rather, it depends critically on RTP packet framing both
to tie the content to other media and to eliminate duplicate material.
We added the "framed" encoding type to the media type registration
to take care of this and similar cases. A media type that uses
the "framed" encoding really is confined to a particular transport
realm.
So, in the case of text/t140, I reallly don't see any conflict we need to
resolve. But this doesn't mean there aren't potential conflicts - media types
have been defined that work in both the packet and stream worlds. And such
types could very easily leak - in fact I'd be surprised if they didn't.
Ned
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf