> Date: 2005-07-05 11:18
> From: Magnus Westerlund <magnus.westerlund@xxxxxxxxxxxx>
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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf