Date: 2005-07-01 11:38
From: Magnus Westerlund <magnus(_dot_)westerlund(_at_)ericsson(_dot_)com>
Magnus,
you wrote:
I think there are good reasons for keeping the registry as one.
Let's look at your reasons:
Both in
RTP and MIME usage the types are after all media formats with specified
represenations.
That's a good reason to have registries which share certain
characteristics, but it does not require sharing the same
registry and namespace.
Having one registry with all representation instead of
separating does not simplify the process of maintaining good usage of
that registry and avoid duplicating entires when there actually are two
different representations.
I'm not sure that I completely understand what you mean. Anyway:
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.
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 have been observed issues with use of the MIME registry for RTP
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.
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.
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.
o registration procedures, forms, review forums, etc. can be customized
for the particular needs, simplifying matters for registrants, reviewers
(including the IESG), and IANA (e.g. if one registry needs a way to
an "obsolete" status and others do not, there is no conflict in
information presentation)
* reduces the number of questions/potential for confusion among
- registrants
- reviewers (including IETF Last Calls if issued, IESG)
- implementers
Point in favor of separate registries
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
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.
Issues which might be unclear:
o Expert reviewer/review forum workload
* clearly there is a flow of MIME registrations; it also appears that
there is a flow of RTP registrations
- Is the combined total too much for one reviewer/one review forum?
- Is there enough flow of both types to support two reviewers (reviews
happen frequently enough that the reviewer hasn't retired or moved
on between reviews)?
- if the answers are:
yes/no -- inconsistent
yes/yes -- indicates in favor of separate registries
no/no -- use one reviewer (doesn't matter if registries are combined
or separate)
no/yes -- indicates in favor of separate registries
Either inconclusive or favors separate review forums (and registries, to
avoid clashes).
o Expert reviewer/review forum expertise:
* I believe that past discussion on the media types review list and here
indicates that while reviewers are familiar with MIME issues, RTP
issues have not always been well-understood. While we can learn/adapt,
separate review forums, possibly also separate reviewers might be
more productive for all parties
Seems to favor separate review forums, probably separate registries (to
avoid clashes)
As I see it, most of the issues seem to favor separate registries, the
exception hinging on whether or not there are any media types which are
usable by both MIME and RTP. If I understand the bulk of your message
correctly (which is similar to explanations made on the media types
review list some weeks ago), there aren't any.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf