[AVT] Re: Comments on draft-freed-media-types-reg-01.txt
ned.freed at mrochek.com
ned.freed at mrochek.com
Mon Oct 4 00:40:58 CEST 2004
> > > 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
More information about the Ietf-types
mailing list