On Tue, 5 Jul 2005, Bruce Lilly wrote:
Date: 2005-07-05 11:18
From: Magnus Westerlund <magnus(_dot_)westerlund(_at_)ericsson(_dot_)com>
Magnus,
Comments in-line:
[...] registered a large amount of names (>70) makes it very hard to see
that moving into separated registries will resolve any confusion. In
addition it will require a huge work effort to move to the new registry.
I have suggested grandfathering existing RTP-related registrations in
a separate RTP registry. That would prevent further confusion and
would give the RTP registry a separate sandbox with clean sand and new
toys. Some small amount of copying work would be required, and of course
registration procedures for both registries would require some minor
tweaking.
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.
As Colin mentioned, in December 1997, then-ADs Harald Alvestrand and
Keith Moore strongly encouraged the AVT working group to convert from
using its own name space for media payload formats to using the MIME
media type registry. 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 help populate the MIME audio and video spaces which were very
sparse.
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.
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.
To me the best way forward is that we clean up the registration
procedures of the current media types registry.
Because of widely-deployed mission-critical MIME applications, any such
"clean up" cannot change the fundamental rules for text media types, as
detailed earlier. We're not talking about mere entertainment applications,
we're talking about email and things like Internet fax, voice messaging,
and EDI.
There is no proposal to change the way email, html, and fax use MIME
types. 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.
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. Someone wanting to know more
about text/plain would look up that media type. 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.
What I intended to stress was that
having cross review between registries is a hard way of avoiding
having two different formats register the same name but in different
registries. As the name structure looks the same, it is very hard to
determine to which registry such a name would belong. Thus one needs to
look up both if checking.
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".
Leakage occurs precisely then implementors and users don't reference
documentation. If we have different names for the same media format
when carried in RTP and in email, this increases the likelihood that
the name from one domain will be used incorrectly in the other. Sure,
one could register the same name in both registries at the same time
if both modes of use were being defined at once, but that is not
always the case. 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. That is, negative
information is better than no information. Not foolproof, but better.
If there is a single registry:
o each MIME and each RTP implementer will have to examine each entry
and determine:
* is this media type applicable to my work?
- yes
- no
- unclear
This is clearly more work for implementers if there is a combined
registry. To the extent that implementers ask questions ("what's
this 'framed' stuff?"), it may be more work for registered contacts
also.
From my perspective a implementor normally know what it needs to
support on a fundamental level. I need to support the AMR codec.
MIME types are explicitly not supposed to be encoding schemes; there is a
separate MIME mechanism for encodings. If RTP permits mixing encodings
with true media types, that's another reason to have a separate RTP
registry; it doesn't fit the MIME model.
I don't understand this point. Are you saying that all audio should
be only one subtype, 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.
From
that perspective looking up audio/amr in either of the registries will
be simple.
Let's discuss lookups. In MIME, a receiver has a clear indication of
a media type (Content-Type field), encoding (Content-Transfer-Encoding),
identifier (Content-ID), checksums (Content-MD5), language
(Content-Language), etc. Where does an RTP receiver get the "audio/amr"
from; does RTP send a Content-Type field?
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. There
are several different signaling protocols in use. I don't think any
of the ones currently in use has a field labeled "Content-Type", but
it would be perfectly reasonable to have a signaling protocol that did
so.
Are the only applications of "text/plain" ones that put that string
after "Content-Type: " ?
In the MIME case, the MIME type from the Content-Type field can be
looked up in the MIME registry. If a particular RTP type can never be
sent via MIME, putting it in the MIME registry may have a performance
impact on MIME lookups, either directly (e.g. a table search) or
indirectly (e.g. paging/swapping due to large hash tables).
Likewise for the RTP case; if, as you say, there is no way for text/plain,
text/html, text/enriched, text/troff, text/rtf, text/sgml, text/csv, etc.
to be sent via RTP, surely their presence complicates RTP applications
finding types that *can* be used with RTP.
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.
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. One hopes
that the subtype name choices allow a more narrow search than linear.
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.
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. Further, many applications or
application suites will use both means of transport.
In fact this is one of the media types that are both RTP and
file format. This would need to be doubly registered and thus needs
links to the other registry to have people avoid taking the wrong
version if they are lacking the necessary knowledge.
As IANA maintains registration information via a web site, two links
to the same registration form would be trivial.
If the registry page would include columns that indicated usage of the
media type this can easily be resolved.
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.
o the registration procedures, forms, review forum, etc. will have
to accommodate items which are the union of items which are
individually applicable to different uses
* MIME registrants will continually ask "what is this 'framed'
encoding stuff?"
* RTP registrants will continually be told "your 'text' type
is incompatible with the requirements for 'no software required',
'fallback to text/plain', etc."
These reasons you list are due to the unclarity regarding the procedure.
No, "framed" has no meaning in a MIME context. That isn't sue to a
procedure; it's due to something irrelevant to MIME being shoehorned
into the registration form. The restrictions on the nature of media
registered under the text top-level MIME type aren't a mere procedural
formality; they are essential to the interoperable functioning of MIME.
Nothing about framing needs to be included in the main MIME documents
nor the registration form. All that's needed is a recognition that
media types may be used differently in different domains, and to make
a provision for separate documents (like RFC 3555) to specify the
additional details that are required for the specific domain.
> 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.
o if there is some media type that is usable by MIME and by RTP, it
need only be registered once (unless of course there are differences
in parameters, security issues, etc, in the registration form that
would indicate separate registration)
* the key question is, are there any such types?
- clearly you have said that, unlike MIME media types, the RTP
types cannot be stored in a file, etc. So it's clear that
the RTP types cannot be used by MIME
- can the MIME types be used by RTP? For example, can RTP make
use of the MIME media type application/vnd.ms-excel?
This would be a point in favor of a combined registry -- if and only
if there is a reasonable number of media types usable by both MIME
and RTP.
I think this is one of the points of contentions in the earlier
discussions we have had regarding this topic. This in the light of
registrations like audio/amr (RFC 3267) that are for both file format
and RTP.
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.
[skipping some in the interest of brevity -- there are various
tradeoffs between combined and separate registries, but not strong
reasons for changing from the status quo -- neither choice can prevent
stupidity]
There are a lot of pro and con and I don't see a lot of decisive
arguments. Therefore I would like to point out the issue of workload. I
think we should select the way forward that results in least work why
still improves the situation. To me that is to keep a single registry
and improve the registration process and information.
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.
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. 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.
The registration process has changed a little since RFC 1341, and
isn't a problem. Getting necessary information from the registry
involves carefully reviewing the registration forms and full
specifications, and would be facilitated by separate registries so
that irrelevant specifications can be more easily ignored.
I doubt that anyone reads through all the full specifications in the
registry to decide which type to use. Finding a type is not hard.
Learning the details of how to implement that type correctly requires
looking at the full specification for that type, not not others.
-- Steve
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf