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

[ned.freed at mrochek.com]

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

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

And this will be my last message on this topic.

				Ned

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