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.
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.
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?
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.
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.
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?
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.
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?
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?
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.
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.
> 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.
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.
o if there are two types with incompatible definitions which wish
to use the same name, there will be a clash
* the namespace is big enough so that names aren't scarce
* however, there may be some user-land confusion, as sometimes
users infer more from a name that just it being a tag for something
This is a relatively minor point in favor of separate registries.
I agree that it is not a problem if we are capable of detecting and
keeping the review to actually look in both registries and ensure that
the other work is not trying to use the same name.
Separate registries, same name isn't a technical problem; it's more of
a potential user confusion issue -- but if that hasn't happened with
audio/amr is probably not worth worrying about.
If there are separate registries:
o RTP implementers can look through an RTP registry, without having to
wade through MIME types and vice versa. Likewise for any other
registries that might be desirable
* MIME implementers can safely ignore the RTP registry and vice versa
- any implementer who needs to be concerned with both can of course
look at both
Point in favor of separate registries.
I can agree with that if one comes looking at names from that direction.
However I think the most common is that one either comes from the
defining RFC
The RFC should indicate (or it should be clear from context) whether it
addresses MIME or RTP or something else.
or have the type name and want to look it up.
In the case of MIME, the type name comes from a MIME Content-Type field,
so the only appropriate place to look would be the MIME registry. It's
unclear where an RTP receiver would get a media type name to look up, but
as it is an *RTP* receiver, the logical place to do so would be in an RTP
registry.
In these
cases separate registries do not provide any benefit.
The benefit (primarily for RTP, but going forward preventing the MIME
registry from becoming more cluttered) is in not having to cut through
the brush of irrelevant registrations.
However the will actually be an increase in questions as you will also
need to ask: Are this name registered in the other registry?
Why would anybody care -- where do MIME and RTP intersect?
o if there is some media type which is usable by both MIME and RTP,
registration would have to be duplicated (modulo differences in forms
and so on)
* as above, are there any?
* copy and paste...
* maybe some incremental work for IESG and IANA -- *IF* there are any
such types
Point in favor of a combined registry, if and only if there is a
reasonable number of such combined-use media types
There are 5 or so that are combined registered.
1. in the case of audio/amr and audio/amr-wb there are (each) two different
formats registered under the same name. If I understand the 3267 sections
4 and 5, the separate formats never mix; the section 4 RTP format never
appears in MIME and the section 5 format never appears in RTP (whether or
not it has ever actually appeared in MIME is another matter).
2. There are currently a total of 615 registered media types (41 text, 71 audio
36 image, 36 video, 12 model, 394 application, 13 multipart, 12 message).
5 out of 615 is less than one percent, and doesn't seem to warrant a
combined registry, especially as that small amount of overlap (if it
really is overlap -- see the item above re. audio/amr and audio/amr-wb)
can be handled by links or copies.
o no clashes in the case of incompatible definitions, even if similar or
the same name is used, provided that MIME and RTP do not interact in
such a way as might cause confusion about whether media is a MIME
type or an RTP type
* as I understand it, there is no opportunity for confusion; any
relationship would require some sort of conversion, and a software
or protocol entity accepts/generates either one type or the other
* names in each realm can be convenient for users, though there may
be some potential for user confusion about whether a type is a MIME
type or an RTP type
Point in favor of separate registries.
The confusion on this level do exist more in the head of implementors
and users. Looking at the name audio/amr can you determine what registry
it belongs in? And the answer is no, you need to have the application
context to determine that.
How under RTP would one *not* know the application context? The root
of the audio/amr problem seems to be that two incompatible formats are
given the same name (and to introduce an informal notation, MIME:audio/amr
and RTP:audio/amr would be distinct names, so separate registries would
help).
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?
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. 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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf