Subject: Re: RTP vs. MIME

From: Bruce Lilly <[email-masked]>
Date: Wed, 20 Jul 2005 13:26:02 -0400

>  Date: 2005-07-12 15:58
>  From: Colin Perkins <[email-masked]>

> On 12 Jul 2005, at 13:43, Bruce Lilly wrote:
> >>   Re: Ietf Digest, Vol 15, Issue 19
> >>  Date: 2005-07-11 19:13
> >>  From: Colin Perkins <[email-masked]>
[...]

> 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.

I recall making no statements about RTP or the way it conveys data
save for the fact that that is as irrelevant to defining a media type
as are details of TCP or UDP etc.
 
> >> 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 processing is specified separately from the format, so I don't  
> understand this comment.

Audio/amr is defined in RFC 3267. The registration forms state:
               This type is defined for transfer via both RTP (RFC 1889)
               and stored-file methods as described in Sections 4 and 5,
               respectively, of RFC 3267.
RFC 3267 sections 4 and 5 indeed define separate formats; the section
headings both refer to "Format" (plural in the case of section 4).

The registration form data for "Public [sic; should be 'Published']
specification" says only
               Please refer to Section 11 of RFC 3267.

RFC 3267 section 11 provides no format specification at all; it is the
RFC section listing references.

> >> 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.
> 
> 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.

That is a very good reason for a separate registry.  There is no question
that the proposed media type did not meet the requirements for registration
in the text top-level MIME registry; it should never have been proposed to
register it there.  With a separate RTP registry, those interested in RTP
can establish whatever rules or lack of rules for things to be considered
as RTP "text".
 
> >> 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:
> 
> The 2793bis draft was published as RFC 4103.
> 
> >    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.
> 
> 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.

The issue is that there has to be a specification of the format.  The
registration form points to RFC 2793.  The format specified in 2793 is
what is shown above.  If the authors of 2793 meant that something else
was in fact the media format, then that something else should have been
specified, as I said earlier:

> > 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).
> 
> 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.

ITU T.140 appears to be a for-purchase document.  Whether or not it
specifically defines a MIME format cannot be determined without looking
at the document, and I'm not about to spend money on a wild goose chase.
As its title is "Protocol for multimedia application text conversation"
and not Format for..., I'm going to assume that it in fact says nothing
about MIME or MIME formats.  Can you quote (under fair-use provisions)
any part of T.140 that specifically mentions MIME (or confirm that it
does not in fact mention MIME)?
 
> The media format does not contain binary data: the binary header is  
> part of the RTP transport protocol, not part of the media format.

So where precisely is the MIME media format specification, in a form
which clearly states that it is a MIME media format specification?
 
> > Claiming that untagged binary data is compatible with MIME text types
> > demonstrates either a gross misunderstanding of MIME or deliberate
> > misrepresentation of facts.
> 
> Or a gross misunderstanding of RTP, on your part.

We're discussing MIME registrations using MIME registration forms and
MIME registration procedures.  RTP is irrelevant to MIME, and as
discussed earlier could and should be handled via an Applicability
Statement as defined in BCP 9 (RFC 2026) section 3.2.  Details of
how a media type is transported via a specific protocol are issues
for an Applicability Statement, not for a MIME media registration.

>  Date: 2005-07-12 21:33
>  From: Stephen Casner <[email-masked]>

> 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

Then the sections of the RFC should not have both been labeled as
defining formats.
 
> 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.

Where precisely is that format specified -- I can find nothing in
RFC 2793 (or 3267) that does so other than format specifications that
contain binary data incompatible with the MIME text top-level type,
nor do I see in 2793 any format specification that shows a "magic number"
field of some sort?  I do see a description of a "magic number" in
RFC 3267 text, and partially shown in conjunction with a "chan-desc
field", the latter apparently containing a 28 bit sequence of zero
bits, i.e. 3 0x00 octets, which is incompatible with MIME text types.
The four low-order bits apparently comprise a channel number which
is described as a 4 bit unsigned integer; channel numbers of zero,
ten, or thirteen would be incompatible with MIME as those are the
taboo 0x00, 0x0A, and 0x0D octets.  The text makes reference to
section 4.1 or RFC 1890, which is RTP-specific whereas the section
making that reference is the Multi-channel Header subsection of
the "Storage Format" section.  The Storage Format section ends with a
subsection "Speech Frames" which defines a binary one-octet header
which refers to a non-existent section 4.1.2 and to 4.3.3 (RTP-specific)
and specifically mentions zero-padding octets which could result in
illegal content (0x0A ends in a zero bit).

> As Colin explained, the first twelve octets here are the RTP header,
> which is present in every RTP packet.

Is it in the defined media format?  If yes, it's incompatible with
MIME text.  If not, then where is the precise specification of what
is the defined media format, and why isn't the RTP protocol-specific
stuff in a separate document as an Applicability Statement?
 
> 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.

MIME media type registrations do not include TCP packet header data
in the media format specifications.  They specify exactly and
exclusively the media format to be registered.  MIME media type
registrations should not include RTP packet header data.  They should
specify exactly and exclusively the media format to be registered.
Look for example at RFC 3023, which defines several media types in the
text and application trees.  It contains no TCP header packet data or
HTTP start lines or header fields, etc. -- only the specifications for
the media types defined.

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 20 Jul 2005 21:31:55 +0100

> as are details of TCP or UDP etc.

You have made, and continue to make, numerous statements about RTP  
payload formats and their associated media type registrations which  
are factually incorrect. The most obvious of these is your insistence  
on treating the RTP transport protocol headers as part of the media  
data, as you repeatedly do in the message to which I am replying.

>>> have been specified separately from the format.
>>

Since RFC 3267 registers both audio/amr and audio/amr-wb and defines  
their use with RTP and as file formats, section 4 correctly refers to  
"Formats" in the plural. For each of the two media types, section 4  
of RFC 3267 describes the RTP-specific process by which that format  
is transported in RTP, and section 5 describes the file format (a  
sequence of concatenated frames of the media format preceded by a  
magic number). You are confusing the applicability statement which  
describes RTP-specific processing with the description of the media  
type.

> RFC section listing references.

The formats are specified in the following:

    [1]   3GPP TS 26.090, "Adaptive Multi-Rate (AMR) speech  
transcoding",
          version 4.0.0 (2001-03), 3rd Generation Partnership Project
          (3GPP).

    [2]   3GPP TS 26.101, "AMR Speech Codec Frame Structure", version
          4.1.0 (2001-06), 3rd Generation Partnership Project (3GPP).

    [3]   3GPP TS 26.190 "AMR Wideband speech codec; Transcoding
          functions", version 5.0.0 (2001-03), 3rd Generation  
Partnership
          Project (3GPP).

    [4]   3GPP TS 26.201 "AMR Wideband speech codec; Frame Structure",
          version 5.0.0 (2001-03), 3rd Generation Partnership Project
          (3GPP).

There are references 1-4 from section 11 of RFC 3267. This is made  
clear in sections 3.1 and 3.2 of RFC 3267, but you are correct in  
noting that the registration template doesn't clearly reference the  
formats. We'll add this to the errata list for the RFC.

> can establish whatever rules or lack of rules for things to be  

You seem to be complaining because we asked the advice of the MIME  
community on whether the 3GPP timed text format should be registered  
under text or video, and then took that advice. Quite how this can be  
construed as a failure of the process, or as a statement that RTP is  
not appropriate for use with MIME types is beyond me.

> specified, as I said earlier:

RFC 2793 is made obsolete by RFC 4103.

As stated previously, the first 12 octets are part of the RTP header,  
and the media data occupies the part of the packet labelled "T.140  
encoded data". This is clearly stated in section 3.5 of RFC 4103 and  
several times later in that document, and has been explained several  
times on this mailing list. The format of the "T.140 encoded data" is  
defined in ITU T.140, as indicated in sections 3.2 and 10.1 of RFC  
4103. The issues you raise are explicitly addressed in the RFC.

> does not in fact mention MIME)?

As I stated in the message which you quoted, the media type is  
defined in ITU T.140, and is registered in RFC 4103. Accordingly, you  
will find the MIME registration in RFC 4103, along with the RTP  
specific mappings needed to convey that type in RTP. The definition  
of a media type being separate from the MIME registration for that  
type is common: there are many non-RTP examples of this in the MIME  
tree.

> which clearly states that it is a MIME media format specification?

As I stated previously, the format is defined in ITU T.140 and  
registered in RFC 4103. In section 10.1 of RFC 4103 ("Registration of  
MIME Media Type text/t140") it clearly states:

    Published specification: ITU-T T.140 Recommendation.  RFC 4103.

as part of a standard MIME registration template. It is difficult to  
be clearer that this.

> for an Applicability Statement, not for a MIME media registration.

Indeed this is true. That is why RFC 4103 contains both a MIME media  
type registration and a statement of applicability which describes  
how that media type is transported using RTP. Despite this, you have  
repeatedly complained that the RTP specific parts of the RFC do not  
conform to the MIME rules, when they clearly do not need to conform  
to those rules since - as you point out - "RTP is irrelevant to MIME".

> Then the sections of the RFC should not have both been labeled as

[This is referring to sections 4 and 5 of RFC 3267]

The term "RTP Payload Format" is clearly defined in RFC 3550 (STD  
64). Since section 4 of RFC 3267 describes an RTP payload format, it  
seems an appropriate term to use. Section 5, as you might expect from  
its title, describes a file format. Both formats use the media types  
registered in sections 8.1 and 8.2 of RFC 3267. There is nothing  
inappropriate in this terminology - MIME does not disallow other uses  
of the term "Format".

> field of some sort?

The comment to which you are responding was about RFC 3267. That RFC  
specifies a media file format consisting of a concatenated sequence  
of audio frames with a magic number header for identification in  
section 5. Since this is an audio format, there is no need for the  
data to be compatible with the MIME text top-level type.

You will not find any reference to a magic number in RFC 2793, and  
indeed no-one has stated that there should be one (Steve's comment  
above related to RFC 3267).

> I do see a description of a "magic number" in

RFC 3267 is an audio format, registered under the audio top-level  
type, and so does not need to be compatible with MIME text types.

> taboo 0x00, 0x0A, and 0x0D octets.

RFC 3267 is an audio format, registered under the audio top-level  
type, and so does not need to be compatible with MIME text types.

> The text makes reference to

RFC 3267 is an audio format, registered under the audio top-level  
type, and so does not need to be compatible with MIME text types.

> Is it in the defined media format?

No, it is part of the RTP transport protocol.

> If yes, it's incompatible with

The precise specification of the text/t140 media type is in ITU T. 
140, with the media type registration form being in RFC 4103 section  
10.1. The statement explaining how that media type is applicable to  
RTP transport, and providing the precise rules by which that format  
is used with RTP, is also in RFC 4103 (sections 3-9). RFC 2026  
explicitly allows these to be part of the same document.

> HTTP start lines or header fields, etc. -- only the specifications for

Your complaint now seems to be that we have used a single document  
both to register a media type, and to explain how that media type is  
transported within RTP. RFC 2048 does not prohibit this, and RFC 2026  
explicitly allows the applicability statement for a technical  
specification to be part of the same document as that specification.

Colin