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

> > > 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@ietf.org
https://www1.ietf.org/mailman/listinfo/avt