On 20 Jul 2005, at 18:26, Bruce Lilly wrote:
Date: 2005-07-12 15:58
From: Colin Perkins <csp@xxxxxxxxxxxxx>
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 <csp@xxxxxxxxxxxxx>
[...]
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.
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.
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).
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.
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.
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.
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".
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.
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:
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.
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)?
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.
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?
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.
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.
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".
Date: 2005-07-12 21:33
From: Stephen Casner <casner@xxxxxxx>
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.
[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".
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?
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 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.
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 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.
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
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).
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.
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?
No, it is part of the RTP transport protocol.
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?
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.
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.
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
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf