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

Colin Perkins csp at csperkins.org
Sat Sep 11 12:35:29 CEST 2004

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.

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 


More information about the Ietf-types mailing list