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.
I could find no other references to audio/basic or PCMU in your message.
- To help populate the MIME audio and video spaces which were very
sparse.
Filling up the MIME registry with names of things that cannot be used
in MIME doesn't seem like a sound reason.
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.
In my opinion, we should set a fairly high bar for the decision to
change from the status quo and induce the overhead of obsoleting a
large number of RFCs.
Red herring. The MIME types remain; no RFCs are obsoleted, and there is
ample opportunity to adjust those specifications as necessary and with
minimal effort in the course of the normal Standards Track progression.
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.
Perhaps "clean up" is not the most appropriate term. I would
say what's needed is to be more specific about the domains in which
media types are used, without changing at all how they have been or
will be used for email, etc.
Perhaps we can agree that only "domains" which respect the long-standing
requirements for registration under the text media type are permitted
to use text subtypes.
The issue I see is that with two separate registries one will not
seriously consider the names in the other registry.
Why should a MIME implementer need to "consider" RTP names or vice versa;
e.g. text/plain or text/html vs. RTP?
This question does not make any sense.
It is a simple question, and it would help understanding if there were
an answer rather than a brush-off. Why would an RTP implementer care
about text/html if RTP cannot carry text/html?
Someone wanting to know more
about text/plain would look up that media type.
Yes. Now why would an RTP implementer care about text/plain?
However, it would be
good if someone who was thinking about sending snippets of audio
captured from a GSM phone considering the registration of audio/GSM
that is defined currently only for the transport via RTP.
If sending via RTP, sure. If the type cannot be used in the MIME
"domain", then there's no point for sending it via MIME as that type.
Now perhaps some GSM phone software implementer might wish to convert
that type to something amenable to storage in a file and transport via
MIME; such an implementer will need to consult the specifications
applicable to both sides of the conversion software regardless of
whether there is one registry or two -- a clear division in two
registries helps such an implementer by focusing his attention
on appropriate types for each side, and helps other implementers
as well.
Why? An particular implementation is either handling RTP streams or MIME
data, and would only need to be concerned with the appropriate registry.
It seems to me that the main concern in this discussion is "leakage".
It's an operational concern which may adversely affect security and
interoperability. The main concern is about appropriate use of the MIME
registry so that interoperability and security are not adversely
affected in widely-deployed, mission-critical applications which
have always conformed to the MIME rules.
Leakage occurs precisely then implementors and users don't reference
documentation.
If the documentation says that a particular media type is registered
in the "Multipurpose Internet Mail Extensions (MIME)" registry as a
MIME type and that media type isn't suitable for MIME use, then the
documentation is at fault and may lead implementers astray.
If we have different names for the same media format
when carried in RTP and in email,
I'm still waiting to hear of such a case which is truly "the same
media format".
this increases the likelihood that
the name from one domain will be used incorrectly in the other.
I still haven't heard an explanation of where the *name* (as distinct
from some protocol-specific code) is actually used in RTP.
Having separate registries for separate things does not imply such
problems. One could in theory register a language tag "foo", a charset
"foo", a text media subtype "foo", an SMTP protocol type "foo", an
diagnostic type "foo", an MTA name type "foo", etc. There is no
doom-and-gloom usage problem because each namespace has a specific
application; a charset name won't end up as a media subtype or
vice versa, a language tag won't end up in a Received field "with"
component, etc.
I believe it is better to have an entry in one
unified registry that says for subtype foo that "this type is defined
only for transport in RTP" than to have separate registries with
nothing for the name foo in the MIME registry.
I understand that that is the belief of many RTP folk, but I see no
rationale supporting that in the wide community interest.
That is, negative
information is better than no information.
Negative information is e.g. the fact that text/foo isn't registered
as a MIME type. Registering text/foo in the MIME registry with some
note saying "don't use this MIME type for MIME" buried in gobbledygook
in a hundred-page specification isn't negative information; it's
contradictory information, obfuscated.
I don't understand this point. Are you saying that all audio should
be only one subtype,
No.
and that a compression scheme such as AMR should
be expressed as a content-transfer-encoding or the equivalent? That
would be a pretty extreme view.
It's not necessarily my position, but that is more-or-less the way
MIME works. See some discussion on the ietf-822 mailing list, e.g.
http://www.imc.org/ietf-822/mail-archive/msg05807.html
Depending of course on pertinent details such as whether compression
is in some way specific to audio (e.g. mu-law as used in telephony)
or just some way to compress non-specific data tacked onto a basic
media type.
RTP does not communicate the "audio/amr" selection at all. RTP
carries a small integer Payload Type that is dynamically bound to a
payload format such as audio/amr by some signaling protocol.
So what's the problem? Use the same integer, bind it to some name
in an RTP registry (use audio/amr or something else; that's up to
RTP to specify) and carry on as before.
Are the only applications of "text/plain" ones that put that string
after "Content-Type: " ?
As text/plain is the default, e.g. in the absence of a Content-Type
field, that's a loaded question. "text/rtf" in a MIME context is
always identified as such by a Content-Type field.
I doubt that this is a significant problem on either the MIME or RTP
side. In both cases, the application supports some set of types which
it keeps in its one little list. The application does not go to IANA
to look up the name in a registry.
Many applications have lists of MIME media types; while it's true
that applications don't consult the IANA MIME registry in real time,
the lists come from somewhere -- putting the burden on thousands of
application developers to wade through irrelevant registrations
doesn't solve the problem, it shifts the burden (RFC 1925 "(6)").
In any event, merely looking up something in a registry simply confirms
whether or not there is a registered type. At least in the case of
MIME, it may be necessary for an implementer to determine what parameters
are required, which optional parameters are valid, what effect any
parameters might have on processing, etc. As the registry is currently
organized, that means wading through each registration form in detail
and consulting the detailed specification. Why should MIME
implementation programmers have to wade through RTP registration forms --
what purpose would that serve?
The implementer of a system wanting to use a media type will look for
a registration of a type that corresponds to that medium.
The mind boggles. If one has a media type, that media type has a name,
and that is the registered (or private-use) name. One doesn't pick
some name because it looks nice; the point is to communicate information
from sender to receiver about what the media actually *is*. Exceptions
being miscreants such as those who propagate worms etc. by mislabeling
content and relying on non-conforming implementations to do nasty
things with such content.
One hopes
that the subtype name choices allow a more narrow search than linear.
One hopes that choices in a MIME context allow for all MIME types and
can be readily expanded as new MIME types are added.
An implementor wanting to specify a MIME media type for a new format
would do well to reference the registration for RTP transport of that
format (if it existed) because it is likely that at least some of the
parameters required to identify the type for RTP will also be needed
to identify the type for MIME usages.
Assuming that you mean a specification writer rather than implementer,
that makes no sense as RTP transport is incompatible with MIME (at
least as Magnus has described the issues w.r.t. media formats).
Unless I'm reading RFC 3267 incorrectly, there are in fact *two*
separate formats, one for RTP use (sect. 4) and one for MIME (sect. 5).
One of which will never be seen in MIME, and one of which will never
be seen in RTP. So why force two sets of programmers to wade through
twice as many format specifications than either will need?
The frames of audio are the same in both cases, so defining both uses
together makes a lot of sense.
Well, audio is fundamentally an analog signal, which can be digitized
and formatted in many ways. SUre, a given audio signal can be
represented in different formats, and it makes some sense to define
some common operations.
Further, many applications or
application suites will use both means of transport.
With conversion between the different formats, one of which actually
uses some sort of code for identification, and the other uses a name.
With separate registries, the need to redesign the pages would be
avoided, which is of course easier than such a redesign.
These are trivialities that do not cross the high bar.
It's real work for IANA and for implementers who have to consult the
IANA registry (adapting to changes in format, etc.).
Nothing about framing needs to be included in the main MIME documents
nor the registration form.
It *is* currently in the draft registration procedure.
All that's needed is a recognition that
media types may be used differently in different domains,
In the MIME registry, "text" means what (primarily) RFC 2046 says it
means, and that is human-readable w/o software, no binary content,
CRLF line endings, no lone CR or LF, etc. If you want different
rules, you need a different registry.
> These have been observed issues with use of the MIME registry for RTP
What are you referring to.
The "what is framed" question and the comments about incompatibility
of proposals for registration under the MIME top-level text media type.
There is a certain amount of angst in the current discussions, but I
believe it is the result of misperceptions. I believe Colin's
messages expressed the issues well. A number of strong theoretical
concerns have been described, but they don't map to reality.
Careful, that path leads to solipsism. The reality for MIME is documented
in the MIME RFCs and is a universal reality. You can of course pretend
that there is some different "reality"...
3267 gives very different format specifications and different security
considerations; precisely my point.
The sequence of audio frames is just the same in both modes of use.
That's nice; the sequence of words, paragraphs etc. represented by
text/html and text/rtf may be the same, but the formats are quite
different; while a human may ignore the (non-binary) markup and
understand the content, the formats remain distinct and should be
labeled distinctly. Feeding one format into an interpreter designed
for the other is unlikely to be useful.
Re workload:
o for whom?
For the AVT working group in particular, which has operated in good
faith building in the MIME registry for years.
I see. Workload for MIME implementers doesn't count. Workload for
IANA doesn't count. Workload for the MIME media types reviewer
doesn't count. But 30 seconds in the course of a required update
is a big deal, because some AVT WG editor will have to do it. As
for "good faith building in the MIME registry", playing by the
MIME registry rules for text media subtypes is necessary to qualify
as "good faith".
o short-term or long-term?
A single registry means more work for MIME implementers and reviewers,
both short-term and long-term, and doesn't improve the situation.
I don't think that is true. As I said, specification of additional,
domain-specific details for registration procedures falls to those
working in the domain.
Let's see, there are >600 types and ~70 of those are for RTP, so
specification of the "additional ... details" means an order of
magnitude more work for MIME folk than AVT/RTP folk (not to mention
IANA's work). Yes, I see why that looks favorable from the AVT
point of view.
We have been registering RTP payload formats
for some time with little impact on MIME reviewers until the recent
discussion ensued. And I can't see how the impact of an audio/amr
registration on MIME implementors interested only text/plain can be
any more than trivial.
Apples vs. Oranges. Audio details are largely uninteresting as
far as MIME implementations are concerned. About the only item
of interest is whether or not some required parameter is specified
(as with "rate" for audio/L16). And the extent of that is that if
a MIME implementation encounters such a type which is specified as
having a required parameter, but the parameter is in fact not present,
there is a MIME error. For video, as far as I know there are no
required parameters for subtypes that would affect parsing of a MIME
message. Text/directory has specific processing requirements and a
required charset parameter, text/plain has specific characteristics,
and most text types can specify a charset parameter, which may affect
the fallback mechanisms. As for "MIME implementors interested only
text/plain", that might well be the empty set, as explained below.
I doubt that anyone reads through all the full specifications in the
registry to decide which type to use.
So do I; but that's not what was claimed. An implementer who needs
to handle MIME messages needs to understand the implications of each
MIME media type, including parameters and interaction with the
specified fallback mechanisms (RFCs 2046, 2049).
Finding a type is not hard.
I doubt that anybody wakes up in the morning and stops to think "what
media type name shall I look for today". Somebody with a media type
to send presumably knows what type it is, and need not look for a
name -- he already knows what type he has (and MIME types specifically
provide for things such as magic numbers to facilitate association of
the name in some non-MIME environments). Somebody receiving a named
media type via MIME is informed what the media type is; that type is
either supported or not by the recipient's application -- if not, some
implementer needs to set to work, and that brings us back to the main
issue, namely non-MIME clutter in the MIME registry makes extra work for
MIME implementers with negative benefit to the community.
Learning the details of how to implement that type correctly requires
looking at the full specification for that type, not not others.
No. The fallback mechanisms specifically require handling of unrecognized
types as if they were a specific registered type (sometimes conditionally,
as in the case of text, where there is a condition related to the specified
charset (default US-ASCII)), and obviously (at least to MIME implementers)
those specific types need to be supported in accordance with the MIME
specifications -- RFC 2049 goes into some detail about this. MIME
applications deal with the gamut of MIME types; one does not use one mail
user agent (MUA) for text/plain and a different one for text/html and yet
another for a message with a combination of text/html, image/jpeg, and
audio/32kadpcm -- a hypothetical MUA which could handle only a single
media type would be at best a niche product; it would certainly not be
used by recipients of a rich variety of MIME messages, at least not without
some add-on support for real MIME media type handling. A conforming MIME
implementation, upon receiving a hypothetical unrecognized type
"text/foo" MUST operate in a specific manner:
0. in the absence of a charset parameter, the charset defaults to US-ASCII,
which must be recognized
1. if the specified charset (default US-ASCII) is unrecognized, the media
must be treated as application/octet-stream. Application./octet-stream
has certain handling requirements, and obviously a conforming
implementation needs to handle application/octet-stream appropriately.
2. if the charset (default US-ASCII) is recognized, the media type must be
treated as text/plain, which has its own requirements.
There are similar considerations for the other top-level media types, so
the absolute minimum that a conforming MIME implementation must handle
includes text/plain, application/octet-stream, multipart/mixed,
multipart/alternative, multipart/digest, and message/rfc822;
also encodings quoted-printable, base64, 7bit, 8bit, and binary; and
charsets US-ASCII and the ISO-8859 family. The idea that a MIME
implementation can be based on "the full specification for [a single]
type, and not others" represents at best a serious lack of understanding
of MIME.
In the case of the specific hypothetical "text/foo", with no charset
parameter and no specified transfer encoding, a conforming MIME
implementation will treat that type as 7bit, text/plain, US-ASCII. In
turn, that means that the media represented by that type:
a) may not contain any octets with the high-order bit set (no binary data)
b) may not contain any octet with value 0x00 (i.e. ASCII NUL, therefore no
binary data)
c) must contain a CRLF (0x0D0A) pair with at most 998 other octets between
such pairs, and those pairs must represent line endings
d) there may be no lone x0D or 0x0A octets (no binary data)
e) obviously, the charset of text must be US-ASCII
Now there are many ways in which a text media type containing ancillary
timing information could be made to fit within the MIME framework. As an
arbitrary example:
i) a charset parameter could be specified, default US-ASCII, only MIME
text/plain-compatible charsets allowed (RFC 2046). That permits use
of e.g. utf-8 if a charset parameter is specified, however the default
must be US-ASCII.
ii) CRLF line endings
iii) timing information in ASCII alphanumeric format, with some suitable
markup mechanism (e.g. XML). Binary data cannot work unless there is
some mechanism to prevent 0x00, 0x0A, and 0x0D octets.
None of which is rocket science, and the last consideration could be
addressed in a variety of MIME-compatible ways. But RTF folk have instead,
despite "careful attention to detail", proposed a format which does not use
US-ASCII as a default charset, which has no provision for a charset
parameter, no requirement for use of charsets compatible with MIME (indeed,
an explicit use of UTF-16, which is not MIME-compatible for text/plain),
which does specify CRLF line endings, and which includes binary data with
no provision to exclude 0x00, 0x0A, or 0x0D octets. In short, it is
incompatible with the MIME text top-level type.
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf