[AVT] Re: Comments on draft-freed-media-types-reg-01.txt
csp at csperkins.org
Sat Sep 25 19:52:16 CEST 2004
On 24 Sep 2004, at 16:29, ned.freed at mrochek.com wrote:
>> > And interop problems are likely if files are produced without the
>> > magic number
>> > and software that checks the magic numbers is used. Similarly,
>> > treating the
>> > magic number as audio data could, depending on the codec involved
>> > some
>> > interesting effects.
>> Of course, but so what? One clearly needs software that understands
>> format, and if you produce files without the magic number they're not
> Sure they are. Your entire entire goal here is to use the same label
> for two different formats, one with the magic number and one without.
No, not within the same domain. I'm intending that the format that's
limited to use when transported in an unreliable sequence of RTP
datagrams has a different header than the format for use when
transported by a reliable byte stream, but that's a different domain of
applicability. It's certainly should not be legal to use the headers
for the byte stream format in RTP, or vice-versa.
> This admits the possibility of two conformant pieces of software
> failing to interoperate, and that's not good.
>> > Now, nothing says you cannot use a naming convention of some sort
>> to link the
>> > two types in some way. But IMO they really need to be two different
>> In which case we have two different and separate namespaces, trying to
>> share the same registry. This, IMHO, doesn't make sense.
> No, what we have is a single registry for specific formats and a way to
> link formats that are in some way related.
But that link is the media type name, with the domain of applicability
to prevent interoperability problems. This is done in RFCs 3267 and
3558, for example, and doesn't appear to have caused problems.
More information about the Ietf-types