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

[John C Klensin]

Hi.

For whatever the additional calibration is worth, my reactions
are in complete agreement with Ned's on all issues.  In
particular, the notion of registration by application, rather
than file (body part) content has been absolutely miserable and
a plague on interoperability.  Part of the reason is that, in
many situations, we can have application X that can handle file
formats A, B, and C, and application Y that can handle file
formats D, E, and B.  If the content types reflect the formats,
there is no problem -- both simply use B.  If they reflect the
applications, then there is an serious interoperability problem.

   john


--On Wednesday, 08 September, 2004 06:59 -0700
ned.freed at mrochek.com wrote:

>> 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