I'll address just a few points:
On Tue, 12 Jul 2005, Bruce Lilly wrote:
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.
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.
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.
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.
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.
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf