Re: Ietf Digest, Vol 15, Issue 19

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxx>

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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]