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

Colin Perkins 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 
>> have
>> > some
>> > interesting effects.
>
>> Of course, but so what? One clearly needs software that understands 
>> the
>> format, and if you produce files without the magic number they're not
>> conforming.
>
> 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 
>> types.
>
>> 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.

Colin




More information about the Ietf-types mailing list