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

From: Colin Perkins <[email-masked]>
Date: Sun, 3 Oct 2004 22:58:02 +0100

On 3 Oct 2004, at 18:22, [email-masked] wrote:
>> On 26 Sep 2004, at 06:13, [email-masked] wrote:
>> >> On 24 Sep 2004, at 16:29, [email-masked] wrote:
>> ...
>> >> > 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.
>
>> You seem to be arguing that the media types namespace cannot be shared
>> between different domains of applicability unless those domains have
>> the exact same framing and parameters.
>
> Nope. I'm arguing that a media type name needs to uniquely identify a 
> specific cononical format. Various encoding details, including some 
> aspects of framing, can of course be domain-specific. It is also 
> possible for an entire media type to have a single domain of 
> applicability, but in such cases it is still wrong to use the same 
> name for something different in another domain.

yes, of course.

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

> Additionally, I see zero support being offered for this notion from 
> anyone else. I therefore regard the matter as closed.
>
> 				Ned
>
>
-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: [email-masked]
Date: Sun, 03 Oct 2004 15:40:58 -0700 (PDT)

> 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

File header/magic number != framing in my book.

And this will be my last message on this topic.

				Ned

---

From: Colin Perkins <[email-masked]>
Date: Mon, 4 Oct 2004 00:53:31 +0100

On 3 Oct 2004, at 23:40, [email-masked] wrote:
> 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.
>
> (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.

And as I have repeatedly argued, this prevents use of the media type
registry for different domains of applicability, since those domains
will have different headers due to the framing.

> File header/magic number != framing in my book.

So, what do you mean by framing? In the examples I'm quoting, the media
data format is bitwise identical in both cases.  The difference is that
it's framed in a file (and hence has a file header) rather than a series
of RTP packets (and hence has an RTP header); once you strip the framing
there is no difference in format.

> And this will be my last message on this topic.

Which doesn't resolve the conflict between draft-freed-media-types-reg
-01.txt and existing practice. Much as you may dislike it, there are two
proposed standards (RFC 3267 and 3558) which register formats in the way
I describe. The change you propose is problematic for a significant user
community, which has previously registered these types in good faith, 
according to IETF procedures.

Colin

---

From: Colin Perkins <[email-masked]>
Date: Sun, 3 Oct 2004 16:41:59 +0100

...
>> >> > Now, nothing says you cannot use a naming convention of some sort
>> >> to link the
>> But that link is the media type name, with the domain of applicability
> doesn't mean much. There are hundreds of media types and who knows how 

the exact same framing and parameters. I don't see this as realistic, 

Colin

---

From: [email-masked]
Date: Sun, 03 Oct 2004 10:22:19 -0700 (PDT)

> the exact same framing and parameters.

Nope. I'm arguing that a media type name needs to uniquely identify a specific
cononical format. Various encoding details, including some aspects of framing,
can of course be domain-specific. It is also possible for an entire media type
to have a single domain of applicability, but in such cases it is still wrong
to use the same name for something different in another domain.

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. Additionally, I see zero support being
offered for this notion from anyone else. I therefore regard the matter
as closed.

				Ned

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 22 Oct 2004 18:30:08 +0200

Hi Ned,

We need to resolve this. And I do not consider it resolved as long as it 
  is not sufficient motivated and way of handling the already approved 
specifications is indicated.

I can understand the need for caution if registering different 
parameters for different applicability. How does one clarify what is 
acceptable, and what is not? Thus please answer Colin's questions below 
in attempt to define some borders.

Is your point that if you need a different piece of software to 
correctly handle the data, then it is another type. Like the fact that 
you need to have a handler of RTP timestamp that sorts frame correctly 
for AMR RTP payload format, while the file format only needs to be able 
to read the frames in sequence to get the order?

Secondly how does we handle the already registered types? They are 
almost impossible to change due to the deployed base of at least some of 
the types. The file format for AMR is deployed in a couple of millions 
mobile phones that support MMS. Do we only leave them in as anomalies in 
the system?

Cheers

Magnus

-- 

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]