Date: 2005-07-12 15:58
From: Colin Perkins <csp(_at_)csperkins(_dot_)org>
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(_at_)csperkins(_dot_)org>
[...]
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 <casner(_at_)acm(_dot_)org>
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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf