|
Re: Ietf Digest, Vol 15, Issue 19
2005-07-11 16:14:04
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.
Comments follow inline.
On 6 Jul 2005, at 18:01, Bruce Lilly wrote:
Date: 2005-07-06 04:06
From: Stephen Casner <casner(_at_)acm(_dot_)org>
Stephen, you wrote:
That's not it. Of course all the existing registrations would be
copied. However, all of the many RTP-related RFCs that refer to MIME
registrations would become obsolete and need to be revised. A fair
number of those RFCs are referenced by other SDO's documents.
Are any of those RFCs on the Standards Track? Are they all at full
Standard? Those which are Standards Track but not yet full Standard
need to be followed up on to advance on the Standards Track, and that
would be a good time to do a global replace of MIME with RTP and add
an IANA considerations section directing IANA to mark the type in the
MIME registry as obsolete. Should take about 30 seconds to do that.
The MIME registrations will never go away (unfortunately for MIME),
so if a particular implementer goes ferreting through the MIME
registrations because he has an old copy of a document that says
MIME, he'll still find the type.
Some of the motivations for moving the RTP namespace into the MIME
namespace were:
- To avoid different names for the same media format, such as
MIME's
audio/basic and RTP's PCMU. More on this below.
To date, I know of no "same media format" for MIME and RTP; Magnus
specifically mentioned audio/amr, which has different formats, and
alluded to a tiny number of others but was not specific.
The simplest is audio/L16. For historical reasons, audio/basic and
audio/pcmu are identical but have different names: eliminating
duplicate names for such formats was one of the initial reasons for
using the MIME namespace for RTP.
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.
...
The AVT working group did a lot of work between then and now to
specify the mechanism for the registrations and to create
registrations with what I believe was careful attention to detail.
This process has imposed very little load on the "MIME folks"; in
fact, it has received little notice until the recent consideration of
two subtypes under the text major type.
That is because of the way MIME works and has always worked; the text
type is for media containing human-readable (w/o software) text. The
fallback is to text/plain, which is what the Internet Message Format
carries in the absence of MIME. There are relatively few
interoperability
considerations for audio and video media subtypes, so the attitude is
largely "ho hum, another subtype; who cares". Not for text. More
below.
...
There is no proposal to change the way email, html, and fax use MIME
types.
On the contrary, any registration of a format which requires software
for interpretation, contains binary content, etc. under the MIME text
type would require massive backwards compatibiliy- and
interoperability-
breaking changes. Given the mission-critical use of the affected
applications (e.g. IETF business such as this and other mailing lists)
that is simply unacceptable.
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, 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:
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.
2) As has been mentioned previously, the text/t140 format, which
started this discussion, 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.
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; or as a result of the 8
years worth of deployment of other RTP formats signalled using a
range of MIME media types within SDP.
...
The simple rule -- necessary to ensure interoperability -- is "MIME
registry,
MIME rules". If the RTP specification writers were to conform to
the MIME
rules -- which are in plain view in RFCs 2046 & 2049 -- there
wouldn't be an
issue; mind you, the types might be of little interest outside or
RTP, and
would still cause busy-work for MIME implementers. As conformance
is not
the path chosen by the RTP folk, the only ways forward that do not
sacrifice
interoperability have already been proposed, viz:
1. a separate registry
2. a separate top-level type for RTP "text" (using some other type
name)
with fallbacks and defaults different from the MIME top-level
text type
3. conformance to MIME criteria
The use of MIME types to identify RTP payload formats does conform to
the MIME rules including the additional rules for text formats.
Accordingly, the status quo, using a single registry as done for the
past several yeas, should remain.
Colin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
|
|