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

[Colin Perkins]

Ned,

On 11 Sep 2004, at 19:21, ned.freed at mrochek.com wrote:
>> On 8 Sep 2004, at 14:59, ned.freed at mrochek.com wrote:
>> >> >> 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'm a little concerned about the strength of this rule. I agree when
>> the parameter space is separate, but I can certainly envisage cases
>> when the parameter space and data format for two different domains 
>> have
>> a very high degree of overlap, and where it makes sense for them to 
>> use
>> the same media type.
>
> Data formats are either the same or they aren't. If they are the same 
> only one
> media type is required. If they aren't then different types are 
> required
> regardless of the disjointness of domains of applicability, the use of 
> the same
> underlying set of codecs, and so on.
>
> Leakage between domains is just too common to relax this rule.

Data formats can be the same, although they have different framing. 
There are several existing examples where we have the same data, using 
the same MIME type, but with different framing for RTP and for the file 
format. I would argue that this is entirely legitimate, and indeed 
required if we're to allow registrations for different domains of 
applicability.

> OTOH, parameters can be optional. I don't much care for it, but I 
> suppose
> there's nothing to prevent you from having a parameter that's optional 
> in some
> contexts and mandatory in others. (This could simply be spelled out in 
> the
> parameter specification language.) However, I would not want to  see 
> language
> prohibiting a particular parameter in some context; IMO this goes too 
> far.
> Having a single parameter with different domain-specific meanings is 
> also
> unacceptable.

Sure.

>> For example, there are several audio codecs where the RTP payload
>> format can be summarised as "put frames into RTP packets in order" and
>> the file format is "put frames into the file in order, following an
>> initial magic number". In both cases there are common parameters:
>> sampling rate, frame duration, and number of channels. However the RTP
>> payload format needs an additional parameter: maximum frame duration
>> (RTP packets have a size limit due to the path MTU, but the file 
>> format
>> supports any frame size). I'm not sure it makes sense to require these
>> to use different media types, since they're clearly the same format
>> applied to different domains, yet the above rule would seem to require
>> it.
>
> And interop problems are likely if files are produced without the 
> magic number
> and software that checks the magic numbers is used. Similarly, 
> treating the
> magic number as audio data could, depending on the codec involved have 
> some
> interesting effects.

Of course, but so what? One clearly needs software that understands the 
format, and if you produce files without the magic number they're not 
conforming.

> Now, nothing says you cannot use a naming convention of some sort to 
> link the
> two types in some way. But IMO they really need to be two different 
> types.

In which case we have two different and separate namespaces, trying to 
share the same registry. This, IMHO, doesn't make sense.

Colin