Subject: RTP vs. MIME (Was Re: Ietf Digest, Vol 15, Issue 35)

From: Bruce Lilly <[email-masked]>
Date: Tue, 12 Jul 2005 08:43:35 -0400

>   Re: Ietf Digest, Vol 15, Issue 19
>  Date: 2005-07-11 19:13
>  From: Colin Perkins <[email-masked]>
>  To: [email-masked]
>  CC: [email-masked], Stephen Casner <[email-masked]>
>  
> Now the initial internet-draft deadline has passed I want to respond  
> to the main points of this message. I don't believe that a point-by- 
> point rebuttal is useful, due to the length of the message and  
> repetition of arguments.

Indeed repetition is not helpful, particularly when it is a repetition
of a misstatement of position or of facts.  I'll limit my remarks to
those cases.

> The audio/amr format contains identical media data, but the RTP  
> transport is defined to strip the initial magic number, which is  
> redundant with fields in the RTP protocol headers. The wide band  
> version of AMR, and the related EVRC formats are similar.

Audio/amr explicitly specifies two separate media formats; if it
were merely a matter of some RTP processing, such processing could have
been specified separately from the format.

> The thrust of most of the rest of this message seems to be that the  
> use of MIME type to identify RTP audio and video formats is  
> uncontroversial,

Not completely uncontroversial, just less damaging than incompatible
text registrations.

> but you have a serious concern over use of text   
> formats with RTP, since you believe these will disrupt MIME  
> operations due to "leakage". This concern difficult to justify for  
> several reasons:

It's not about "leakage", it hasn't been about "leakage"; that is a
minor issue that has been turned into a strawman in order to
demonstrate how easily it can be knocked down. 

> 1) These types have been in widespread use for several years now;  
> there have been no reports of actual operational problems, opposed to  
> the theoretical arguments being made here.

No, the proposed text/3gpp-tt hasn't been in use as a MIME type.  Of
course there are no operational problems; they have been nipped in the
bud.  To the extent that text/t140 hasn't caused operational problems,
that is because it has been largely ignored (not without cost) because
it is in fact not a valid MIME type.

The arguments are not "theoretical"; mixing disparate types of
registrations in the single MIME registry, some of which do not use
MIME mechanisms at all, makes extra work for implementers -- work
which yields no benefits, only wastes effort and creates confusion.

If our specifications and procedures do not benefit implementers --
indeed when they cause confusion and busy-work -- there is a problem
which needs to be addressed.  In this case, separate registries for
MIME and non-MIME content is an appropriate solution.

> 2) As has been mentioned previously, the text/t140 format, which  
> started this discussion,

No, the discussion started with an IESG I-D requesting discussion, and
that followed a failed attempt to register "text/3gpp-tt" in the MIME
registry despite many incompatibilities of the proposed format with
the requirements for registration under the "text" top-level type.

> does comply with the MIME registration rules   
> for the text media type. The format is plain UTF-8 text with implicit  
> timing data, there are no embedded control characters, the CRLF  
> sequence is only used to identify line breaks, and a language tag is  
> available.

RFC 2793 (the AVT 2793bis draft is unavailable) specifies:

   This is an example of a T140 RTP packet without redundancy.
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X| CC=0  |M|   T140 PT   |       sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      timestamp (1000Hz)                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   +                      T.140 encoded data                       +
   |                                                               |
   +                                               +---------------+
   |                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[...]
   Published specification: ITU-T T.140 Recommendation.
                            RFC 2793.

First, the content excluding "T.140 encoded data" is not delimited
as not part of the text content (vs. e.g. text/html, text/sgml,
text/enriched, etc.).  Second, unless it is absolutely guaranteed
that neither octet of the sequence number, none of the 4 octets of
the timestamp, and none of the 4 octets of the SSRC identifier can
ever have values 0x00, 0x0A, or 0x0D, the format fails to comply
with the text media type requirements, which prohibit those values.

If the format specified in RFC 2793 is not intended as the media
type specification, then the MIME registration form should not have
specified RFC 2793 or 2793 should have specified the exact format,
with any special protocol use considerations specified in a separate
RFC worded as an Applicability Statement (per BCP 9).

> The claimed "massive backwards compatibility- and interoperability- 
> breaking" changes you suggest would occur have not been needed in the  
> five years since this format was registered;

Then why are they specified in the format?  If the format doesn't
need binary data, why is it in fact specified as containing binary
data (as opposed to say tagged ASCII-digit based representations of
sequence numbers, timestamps, identifiers, etc.)?

Claiming that untagged binary data is compatible with MIME text types
demonstrates either a gross misunderstanding of MIME or deliberate
misrepresentation of facts.

> The use of MIME types to identify RTP payload formats does conform to  
> the MIME rules including the additional rules for text formats.

Where in the specification is the restriction against 0x00, 0x0A, and
0x0D octets (except for CRLF pairs as line endings)?  How precisely
do you expect a human to find the text without use of software when
there is no tagging or other delimiter between binary data embedded
in the format and text?

> Accordingly, the status quo, using a single registry as done for the  
> past several yeas, should remain.

False premises.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Colin Perkins <[email-masked]>
Date: Tue, 12 Jul 2005 20:58:49 +0100

> of a misstatement of position or of facts.  I'll limit my remarks to

As will I, since your message includes many misstatements of facts  
relating to the RTP transport protocol and the way in which it  
conveys media data.

> been specified separately from the format.

The processing is specified separately from the format, so I don't  
understand this comment.

> it is in fact not a valid MIME type.

There is no such thing as text/3gpp-tt; that format is being  
registered under the video top level type, as a result of comments  
during MIME review. More on this, and on text/t140, below.

> the requirements for registration under the "text" top-level type.

As mentioned previously, that format is now being registered under  
video. I believe this is an example of the MIME review working well:  
in the initial request for MIME review for the 3GPP-TT format, I  
said: "I'm not sure we have the experience to decide this in the AVT  
working group. The question is about draft-ietf-avt-rtp-3gpp-timed- 
text-04.txt: is it appropriate to register the format under the video  
or text top-level type?" [1]. There was considerable discussion, and  
as a result of that discussion, the format was registered under the  
video top-level type.

> RFC 2793 (the AVT 2793bis draft is unavailable) specifies:

The 2793bis draft was published as RFC 4103.

>    This is an example of a T140 RTP packet without redundancy.

As explained previously, those values are part of the RTP protocol  
header and are not part of the media data.  The media data begins  
following the 12 octet standard RTP header, and is labelled "T.140  
encoded data" in the figure. You can find an explanation of RTP in  
RFC 3550, if this is not clear.

> RFC worded as an Applicability Statement (per BCP 9).

RFCs 2793 and 4103 contain both a media type registration, and a  
description of how the RTP transport protocol is adapted to convey  
that media type. You appear to be confusing the RTP specific  
adaptation layer, described in RFC 2793/4103, with the media type  
defined in ITU T.140 and registered in RFC 2793/4103.

> sequence numbers, timestamps, identifiers, etc.)?

The media format does not contain binary data: the binary header is  
part of the RTP transport protocol, not part of the media format.

> misrepresentation of facts.

Or a gross misunderstanding of RTP, on your part.

> 0x0D octets (except for CRLF pairs as line endings)?

ITU recommendation T.140. Rules for the use of RTP to convey this  
format can be found in RFC 4103 sections 3.2 and 3.3, which state  
that each RTP packet should contain a single block of T.140 text data  
with no additional headers.

> How precisely

There is no binary data embedded in the format, so this is not a  
problem. The media type is transported within RTP: you clearly need  
an implementation of RTP to receive this format when sent via RTP,  
but that is no different to needing a HTTP implementation when  
receiving a text format distributed via the web. In both cases, the  
media content is plain text with no embedded binary data, all that  
differs is the transport protocol.

Colin

[1] Post to [email-masked] on 9 August 2004. Message ID  
<[email-masked]>

---

From: Stephen Casner <[email-masked]>
Date: Tue, 12 Jul 2005 18:33:51 -0700 (PDT)

I'll address just a few points:

> been specified separately from the format.

As Colin explained, the two things specified are not separate media
formats, they are:

  - a media format consisting of a sequence of frames
  - a means of processing those frames for transport in RTP

They are specified separately in the RFC, but it makes sense to handle
them together in one RFC, especially since many readers will be
interested in both.

The right way to think about this from the MIME perspective is that
the document defines a media file format consisting of a concatenated
sequence of frames with a magic number for identification as a
header.  Because the MIME type is applicable to multiple domains of
use, it also indicates the selection of an RTP payload format using
the same sequence of frames and loading them into packets.

> demonstrate how easily it can be knocked down.

In earlier discussions with Ned Freed and John Klensin, "leakage" of
types from RTP applications to others was one of the primary concerns
they expressed.

>    This is an example of a T140 RTP packet without redundancy.

As Colin explained, the first twelve octets here are the RTP header,
which is present in every RTP packet.  It is comparable to a TCP
header or a UDP header.  RTP usually runs within UDP, and the
concatenation of the UDP header and the RTP header provides a set of
services that is similar to the set of services provided by the TCP
header (not the same, of course, because the purpose is different).

I don't think you are concerned, from a MIME perspective, that some of
the octets of the TCP header carrying email may be 0x00, 0x0A or 0x0D.

                                                        -- Steve