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

[ned.freed at mrochek.com]

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

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.

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

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.

				Ned

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt