Subject: Re: RTP vs. MIME

From: Bruce Lilly <[email-masked]>
Date: Fri, 22 Jul 2005 11:25:39 -0400

>  Date: 2005-07-20 16:31
>  From: Colin Perkins <[email-masked]>

> On 20 Jul 2005, at 18:26, Bruce Lilly wrote:

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

I have made statements about the only publicly- and freely-visible format
specification which is referenced by MIME registration forms.  To the
extent that transport protocol overhead has been erroneously included in
what is purported to be a media format specification, that is a problem
with the registration and/or specification.  And I would add that that
causes problems for MIME reviewers and implementers, and said problems
would be alleviated by a separate registry with separate rules, where
RTP-specific registrations can conflate transport bits with format bits
or not without causing problems for MIME reviewers and implementers.

> You are confusing the applicability statement which   
> describes RTP-specific processing with the description of the media  
> type.

I see nothing in 3267 labeled "applicability statement"; I do see
multiple "format" descriptions.
 
> 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).

26.090, according to http://www.3gpp.org/ftp/Specs/html-info/26090.htm
is "AMR speech Codec; Transcoding Functions".  Transcoding functions and
media formats are separate types of specifications.  "Frame structure"
specifications *might* be applicable, *if* the media format is identical
to said "frame structure", but I see nothing in the registration form
that says so, and several parts of section 5 imply otherwise; sections
5, 5.1, and 5.2 make no reference to what precisely comprises "speech
frames" or "speech bits" or indeed why two different terms are used.
 
> > 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".
> 
> 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.

One might as well ask whether or not an elephant is eligible for a dog
license.  The question shouldn't even be asked.  And it wasn't a simple
matter of "took that advice", there was argument that even though the
media clearly was incompatible with text, that it should be registered
under text anyway, presumably merely because some RTPers would like it
that way with no regard for the registry's rules.  That the question
was asked is itself an indication of a problem (the rules are quite
clear and are not new; they have been in RFC 2046 which is now more
than eight years old).  That RTPers would like to do things incompatible
with MIME and the MIME registry is a clear indication that both RTP and
MIME communities would best be served by separate registries with
separate rules tailored to the needs of their respective communities.
Both seem quite clear from consideration of the facts... [in the interest
of keeping at least this IETF list discussion civil and professional,
I'll not comment re. your "is beyond me" statement other than to note
that the implications seem clear to me] 

[text/t140]
> > 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:
> 
> RFC 2793 is made obsolete by RFC 4103.

Same situation.  Moreover, the IANA MIME registry for text/t140 points to
[RFC-ietf-avt-rfc2793bis-09.txt] (I checked again now).  Why haven't the
AVT/RTP folks made sure that the IANA registry points to something
reasonable?

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

No, while the RTP content may be specified for RTP, I can find nothing in
2793 or 4103 that says what the MIME media format comprises.
 
> > So where precisely is the MIME media format specification, in a form
> > 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.

I see "RFC 4103", but as noted above, there does not appear to be anything
in 4103 that says what comprises the MIME media type format, if indeed the
media is at all suitable for MIME.

T.140 is not freely available; I have asked for specific confirmation that
it in fact clearly and explicitly defines a MIME media type format, but as
of yet I have seen no such confirmation.  Two simple yes/no questions for
somebody with access to T.140:
1. does T.140 contain the acronym/word "MIME"?
2. does T.140 contain the acronym "RTP"?

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

I see nothing in 4103 or the other RFCs discussed that resembles any
indication of an Applicability Statement.  Indeed "pplicab" does not
appear anywhere in any of those RFCs, as it would if there were an
Applicability Statement or statement of applicability or any such
thing.  Instead there are descriptions of formats, and as MIME media
types have formats, that is what has been discussed.

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

No, I have noted that the format specifications that are presented in
the RFCs referenced as the format specification show content which is
incompatible with MIME.  You have stated that those are in fact not
formats (though that is how they are labeled) but instead comprise
some sort of Applicability Statement (though neither that term nor
anything resembling it appears in the RFCs).
 
> [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".

True, and unless I misunderstood earlier statements to the effect that
RTP does not use MIME mechanisms (e.g. Content-Type field), section 4
seems irrelevant (except that parts of section 5, which would seem to
be relevant to MIME, refer back to section 4 "formats").  Section 5
might be relevant to MIME; at best though it is poorly specified as it
does not stand alone (in part because of cross-references to the RTP-
specific section 4).
 
> 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.

True, my error.  It's not clear precisely why we're discussing audio;
IIRC somebody said the amr subtypes were defined for combined MIME/RTP
use, but recent discussion seem to indicate that the format specified
isn't in fact for MIME, but is an RTP-specific transport data
specification.  Which seems contrary to the claim of combined use.

[RFC 3267] 
> > 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)
[...]
> 
> RFC 3267 is an audio format

Yes, OK, but where are the missing 4.1.2, and why are sections supposedly
dealing with a MIME type referring to RTP-specific transport protocol
data specifications (as seems to be the claim)?

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

The incompatibilities with text media types and RTP remain.  It has been
claimed as justification for a combined registry that some few audio types
(but not text, video, model, multipart, image, message, application types)
are registered for combined use.  On examination, the specifications
containing the registrations do not clearly specify how those media are
formatted in a MIME context.  Rather than being a rather weak argument in
favor of a combined registry, it appears that the media types are in fact
not used with MIME and that argues in favor of a separate registry. 

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

---

From: Colin Perkins <[email-masked]>
Date: Fri, 22 Jul 2005 23:55:03 +0100

On 22 Jul 2005, at 16:25, Bruce Lilly wrote:
...
> To the extent that transport protocol overhead has been erroneously  
> included in what is purported to be a media format specification,  
> that is a problem with the registration and/or specification.

There is nothing in the MIME rules which requires an RFC to include  
only a MIME registration template. Despite your attempts to claim  
otherwise, it is entirely legitimate and appropriate for an RFC to  
include both a media type registration and some other specification.

> And I would add that that causes problems for MIME reviewers and  
> implementers, and said problems would be alleviated by a separate  
> registry with separate rules, where RTP-specific registrations can  
> conflate transport bits with format bits or not without causing  
> problems for MIME reviewers and implementers.

The documents clearly separate "transport bits" from "format bits",  
so this is not an issue.  This separation has been repeatedly  
explained to you, and is documented in these particular  
specifications, and the RTP specification (RFC 3550 -- STD 64).

> multiple "format" descriptions.

There is no requirement in RFC 2026 for the explicit label  
"applicability statement" to appear anywhere, so this cannot be your  
complaint. You will find several format descriptions in the RFC: two  
RTP payload formats, and two media types. The two RTP payload format  
definitions (section 4 of RFC 3267) describe how the two media types  
are conveyed within RTP, but don't define the media types. The two  
media types are described in section 5 of RFC 3267, with reference to  
the 3GPP specifications which define the bit patterns and semantics  
of the speech frames. The media type registrations are in section 8  
of RFC 3267. You are, as I previously stated, confusing the RTP  
specific processing (an "RTP Payload Format") with the description of  
the media type.

> frames" or "speech bits" or indeed why two different terms are used.

The 3GPP documents are, without any doubt, both applicable and  
appropriate specifications for these formats.  There are several  
dozen independent and interoperable implementations based on the  
specifications, using the media formats both with RTP and in more  
traditional MIME contexts such as file downloads. These  
implementations are in daily use by tens of millions of users. By any  
measure, this meets the necessary standards of specification clarity  
for the community which is implementing the standard.

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

That is your interpretation of our motives, with which I completely  
and utterly disagree. Your reasoning leads to anyone from asking for  
advice related to MIME registration procedures being labelled as  
doing "things incompatible with MIME", which is patently absurd. We  
asked for advice, that advice was given and taken, and the format is  
now registered under video. The registration procedures worked as  
defined.

>>> been specified, as I said earlier:
>>

RFC-ietf-avt-rfc2793bis-09.txt is the document which became RFC 4103.  
You should ask the IANA why they haven't updated their web page: the  
failings in internal IANA and RFC Editor procedures are not the fault  
of AVT.

> 2793 or 4103 that says what the MIME media format comprises.

In section 10.1 of RFC 4103 it states, using a standard MIME  
registration template, that the media format is defined in ITU-T  
recommendation T.140. If you read that ITU recommendation, you will  
find it clearly defines the format.

> media is at all suitable for MIME.

RFC 4103 references ITU recommendation T.140. The ITU recommendation  
states what comprises the media format content.

> 1. does T.140 contain the acronym/word "MIME"?

No, it does not. The media type registration template is in RFC 4103,  
with the media format being defined in T.140. This is entirely  
appropriate, and is consistent with other MIME registrations (e.g.  
"application/postscript" and "image/tiff" are exactly the same, with  
the MIME template being in an RFC separate to the media format  
specification).

> 2. does T.140 contain the acronym "RTP"?

No, it does not. The media type is independent of RTP.

> types have formats, that is what has been discussed.

Nothing in RFC 2026 requires the words "applicability statement" to  
be in the RFC. The RFCs clearly state that they define "RTP payload  
formats", a term defined in RFC 3550 (STD 64), which define "how a  
particular kind of payload data, such as H.261 encoded video, should  
be carried in RTP" (see section 13 of RFC 3550). This is clearly an  
applicability statement for a media format, defining how that media  
format can be transported within RTP.

In addition, these documents also register media formats, with  
reference to external specifications of those formats.

> incompatible with MIME.

No, they do not. The specifications of the media formats conform to  
all MIME rules applicable to the top-level media types under which  
they are registered. The specifications of the RTP payload formats do  
not conform to MIME rules, but do not need to since they are not part  
of MIME.

> You have stated that those are in fact not formats (though that is  
> how they are labeled) but instead comprise some sort of  
> Applicability Statement (though neither that term nor anything  
> resembling it appears in the RFCs).

Again, you are confusing an "RTP Payload Format", defining the RTP  
specific processing of a media format, with the media format itself.

> be relevant to MIME, refer back to section 4 "formats").

Section 4 of RFC 3267 is indeed irrelevant to MIME, as it defines an  
RTP payload format. As Steve and I have repeatedly explained, the  
equivalent sections of RFC 4103 are also irrelevant to MIME, since  
they also define an RTP payload format. For this reason, your  
complaints about the alleged non-conformance of RFC 4103 with MIME  
rules make no sense, since they relate to the RTP payload format,  
which we agree is irrelevant to MIME.

> Section 5 might be relevant to MIME; at best though it is poorly  
> specified as it does not stand alone (in part because of cross- 
> references to the RTP-specific section 4).

Section 5 defines a MIME format, yes.

> specification.  Which seems contrary to the claim of combined use.

The formats are widely used with RTP, and for more traditional MIME  
file transfer purposes.

> Yes, OK, but where are the missing 4.1.2,

The reference to section 4.1.2 would appear to be an incorrect  
reference to section 4.3.2. We'll add this to the errata list for the  
RFC.

> and why are sections supposedly dealing with a MIME type referring  
> to RTP-specific transport protocol data specifications (as seems to  
> be the claim)?

Because the format of the data is the same in both cases, and it  
seemed easier to reference the specification rather than copy-and- 
paste the text.

>>>> some of the octets of the TCP header carrying email may be 0x00,  
>>>> 0x0A or  0x0D.
>>>
> The incompatibilities with text media types and RTP remain.

No, they do not: this assertion is factually incorrect. The RTP use  
of text media formats is in full compliance with all the MIME rules  
for text media. Your complaints relate to the RTP headers, which are  
not part of the media format data, and so do not need to conform to  
MIME rules.

> It has been claimed as justification for a combined registry that  
> some few audio types (but not text, video, model, multipart, image,  
> message, application types) are registered for combined use.  On  
> examination, the specifications containing the registrations do not  
> clearly specify how those media are formatted in a MIME context.   
> Rather than being a rather weak argument in favor of a combined  
> registry, it appears that the media types are in fact not used with  
> MIME and that argues in favor of a separate registry.

On the contrary, the media types in question are in daily use by tens  
of millions of users, both with RTP in more traditional MIME uses.

Colin