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

[Colin Perkins]

On 3 Oct 2004, at 23:40, ned.freed at mrochek.com wrote:
>> > > I don't see this as realistic,
>> > > since the entire reasoning behind specifying domains of 
>> applicability
>> > > for media types is to allow for different framing and parameters.
>
>> > I do not regard fundamental differences in what goes in the content
>> > as a framing detail. Again, the metric needs to be based on
>> > interoperability.
>
>> > Look, this discussion has become pointless. I find your proposal to
>> > use the same media type name to identify different formats in
>> > different domains to be completely unacceptable, so much so that I
>> > will not be party to any draft that incorporates this concept.
>
>> THAT IS NOT MY PROPOSAL!
>
> On the contrary, that's exactly your proposal. Quoting your own 
> original
> message on this thread:
>
>  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  it.
>
> I have stated repeatedly that I regard data with and without some sort 
> of header as constituting different formats that require different 
> media types.

And as I have repeatedly argued, this prevents use of the media type
registry for different domains of applicability, since those domains
will have different headers due to the framing.

>> What I have been arguing for is to allow the
>> framing and framing specific parameters to vary for different domains
>> of applicability, yet have received nothing but push back on this. Go
>> read RFC 3267; only the framing differs.
>
> File header/magic number != framing in my book.

So, what do you mean by framing? In the examples I'm quoting, the media
data format is bitwise identical in both cases.  The difference is that
it's framed in a file (and hence has a file header) rather than a series
of RTP packets (and hence has an RTP header); once you strip the framing
there is no difference in format.

> And this will be my last message on this topic.

Which doesn't resolve the conflict between draft-freed-media-types-reg
-01.txt and existing practice. Much as you may dislike it, there are two
proposed standards (RFC 3267 and 3558) which register formats in the way
I describe. The change you propose is problematic for a significant user
community, which has previously registered these types in good faith, 
according to IETF procedures.

Colin