Re: Last Call: 'Media Type Specifications and Registration Procedures' to BCP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>     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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]