[AVT] Re: Comments on draft-freed-media-types-reg-01.txt

[ned.freed at mrochek.com]

> Hi Ned,

> See below.

> ned.freed at mrochek.com wrote:

> >> Hi Ned and John,
> >
> >
> >> I have now reviewed your document and have some comments and questions.
> >
> >
> >> MW1: Section 3.4: Based on all arguments I have heard about any
> > But this is what the section already says:
> >
> >   However, with the simplified registration procedures described above
> >   for vendor and personal trees, it should rarely, if ever, be
> >   necessary to use unregistered experimental types, and as such use of
> >   both "x-" and "x." forms is discouraged.
> >
> > I think this is pretty clear already.

> I think one could use a stronger language in discouraging people.

Then by all means suggest some.

> >
> >> ME3: Section 4.3: Parameters only applicable to a specific domain of
> >> usage? Certain types will be (are) registered for several domain of
> >> usage, however the different domain may require that different
> >> parameters are used. I can give you an example in RFC 3267 that has
> >> quite many parameters for RTP usage, but none for the file format. How
> >> is it supposed to be indicated that this is the case?
> >
> >
> > IMO if the parameter space is different the types are different. I don't
> > think it is appropriate to have domain-specific parameters, only
> > type-specific ones.

> Okay, so registering the RTP payload format and a dedicated file format
> for the same codec needs to use two different media types, due to that
> that they partially needs to have different parameters?

They most certainly do.

> I have an example in the draft-ietf-avt-rtp-vmr-wb-03.txt where we have
> RTP payload format that carries the different audio frames. There is
> also a specification of a file format, that also contains the same
> frames. The wrapping structure is somewhat different due to that they
> are file format and RTP payload format.

In other words, the bits are different as well. That means two media types are
required regardless of whether or not the parameters are the same.

While it is nice to be able to cater to some extent to protocol-specific needs
in our procedures, we cannot afford to compromise the core functionality media
types provide. One of those core functions is that each type labels a single,
canonical object format. Types don't label codecs, and it has long been the
case that a single codec can give rise to multiple media types. (It is also
possible for multiple codecs to be combined in a single type.)

> I understand. I might have not meant application really correctly. What
> I mean is that if we update the RTP registration rules for media types,
> we can define a string that should be written into Restriction on usage
> if only RTP is supported. That way we are not really being explicit
> about application, but can ensure that we have a good definition on what
> restriction we applies.

That may be the right thing to do for RTP, but we need to think more
generally here. Of course nothing prevents RTP from specifying its
own additional registrations requirements for media types it uses.
The MIME specification is certainly going to do something along these
lines once it is revised.

> >> MW6: I think further clarification on the coupling between the "intended
> >> usage" and the "Restriction on usage" is needed. For example, is one
> >> allowed to use "Common" when the restriction of usage says: Only for use
> >> in RTP? And is the classification of what is common, limited usage, or
> >> obsolete depending on the domain?
> >
> >
> > I guess I don't see the problem. The commonality of use of something
> > has almost nothing to do with how usage is restricted. I could have
> > a media type that's commonly used but only RTP. Or I could have
> > an obsolete type that can be used anywhere. Any combination is possible.
> >
> > Perhaps moving the restrictions on usage field below the intended usage
> > field in the registration form and adding some text as to what goes
> > in the restrictions on usage will help.
> >

> What could happen is that we have a media type that is for a codec and
> with two defined usages, file format and RTP payload format. The RTP
> payload format is after standardization used, but later found unsuitable
> for usage. Therefore a new RTP payload format is defined. However as
> there is a deployed basis one can't simple use the same media type for
> the new RTP payload format and defines a new one. The previous name is
> still valid for the file format part, while OBSOLETE for the RTP payload
> part.

In other words, having a media type that labels more than one sort of 
object can give rise to situations where the intended usage varies
depending on where the type is employed. This is hardly surprising given
that the initial premise violates the entire media type philosophy.

This is still more reason why having a single label for two very differnet
things is TOTALLY unacceptable.

				Ned