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

[ned.freed at mrochek.com]

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

You're assuming that material can be constrained to a single domain. We have
ample experience that (a) such assumptions are routinely voilated and (2) we
have absolutely no competence at predicting when violations will occur.

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

Two examples where problems haven't yet arisen in a specific domain doesn't
mean much. There are hundreds of media types and who knows how many domains of
applicability, and the rules have to work for all of them.

				Ned