|
Re: RTP vs. MIME (Was Re: Ietf Digest, Vol 15, Issue 35)
2005-07-12 12:59:18
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>
To: iesg(_at_)ietf(_dot_)org
CC: ietf(_at_)ietf(_dot_)org, Stephen Casner <casner(_at_)acm(_dot_)org>
Now the initial internet-draft deadline has passed I want to respond
to the main points of this message. I don't believe that a point-by-
point rebuttal is useful, due to the length of the message and
repetition of arguments.
Indeed repetition is not helpful, particularly when it is a repetition
of a misstatement of position or of facts. I'll limit my remarks to
those cases.
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.
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.
The thrust of most of the rest of this message seems to be that the
use of MIME type to identify RTP audio and video formats is
uncontroversial,
Not completely uncontroversial, just less damaging than incompatible
text registrations.
but you have a serious concern over use of text
formats with RTP, since you believe these will disrupt MIME
operations due to "leakage". This concern difficult to justify for
several reasons:
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.
1) These types have been in widespread use for several years now;
there have been no reports of actual operational problems, opposed to
the theoretical arguments being made here.
No, the proposed text/3gpp-tt hasn't been in use as a MIME type. Of
course there are no operational problems; they have been nipped in the
bud. To the extent that text/t140 hasn't caused operational problems,
that is because it has been largely ignored (not without cost) because
it is in fact not a valid MIME type.
There is no such thing as text/3gpp-tt; that format is being
registered under the video top level type, as a result of comments
during MIME review. More on this, and on text/t140, below.
The arguments are not "theoretical"; mixing disparate types of
registrations in the single MIME registry, some of which do not use
MIME mechanisms at all, makes extra work for implementers -- work
which yields no benefits, only wastes effort and creates confusion.
If our specifications and procedures do not benefit implementers --
indeed when they cause confusion and busy-work -- there is a problem
which needs to be addressed. In this case, separate registries for
MIME and non-MIME content is an appropriate solution.
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.
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.
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.
The claimed "massive backwards compatibility- and interoperability-
breaking" changes you suggest would occur have not been needed in the
five years since this format was registered;
Then why are they specified in the format? If the format doesn't
need binary data, why is it in fact specified as containing binary
data (as opposed to say tagged ASCII-digit based representations of
sequence numbers, timestamps, identifiers, etc.)?
The media format does not contain binary data: the binary header is
part of the RTP transport protocol, not part of the media format.
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.
The use of MIME types to identify RTP payload formats does conform to
the MIME rules including the additional rules for text formats.
Where in the specification is the restriction against 0x00, 0x0A, and
0x0D octets (except for CRLF pairs as line endings)?
ITU recommendation T.140. Rules for the use of RTP to convey this
format can be found in RFC 4103 sections 3.2 and 3.3, which state
that each RTP packet should contain a single block of T.140 text data
with no additional headers.
How precisely
do you expect a human to find the text without use of software when
there is no tagging or other delimiter between binary data embedded
in the format and text?
There is no binary data embedded in the format, so this is not a
problem. The media type is transported within RTP: you clearly need
an implementation of RTP to receive this format when sent via RTP,
but that is no different to needing a HTTP implementation when
receiving a text format distributed via the web. In both cases, the
media content is plain text with no embedded binary data, all that
differs is the transport protocol.
Colin
[1] Post to ietf-types(_at_)ietf(_dot_)org on 9 August 2004. Message ID
<E859DAAD-EA16-11D8-9045-000A957FC5F2(_at_)csperkins(_dot_)org>
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
|
|