Comments on draft-freed-media-types-reg-01.txt

[Colin Perkins]

I'd also like to see a resolution of this, since we have new RTP 
payload formats under development that need MIME types to be assigned, 
and it's clear there are different understandings of the rules.

We have two proposed standard RFCs (RFCs 3267 and 3558) which register 
the same media type for the RTP Payload Format and for the File Format. 
At the time those RFCs were written, the AVT working group considered 
them to be the same format (as the data is identical between the file 
format and the RTP payload format, with only the framing differing). I 
can only assume the that the IESG agreed, since each format was 
registered using the same media type name for the two different framing 
methods.

It's now clear that Ned (and others) don't regard it appropriate for a 
file format and an RTP payload format to use the same media type.

This is a conflict which needs to be resolved, both to clarify the 
status of the existing registrations and to make sure that we do the 
right thing with the many new RTP payload formats under development. I 
don't care which way it's resolved* but the fact that we have this 
discussion (and existing practice which conflicts with some 
interpretations of the rules) implies that the registration rules need 
clarification, and is the reason for my questions.

Colin




* to be clear: I'm not an author on RFC 3267 or 3558, nor do I sell 
product based on either, nor am I trying to register a new media type. 
I am however the person stuck with having to resolve the conflict 
between those two RFCs and the interpretation of the rules I'm hearing 
on this list.




On 22 Oct 2004, at 17:30, Magnus Westerlund wrote:
> 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
>
>
> Colin Perkins wrote:
>>>
>>> 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
>
>
> -- 
>
> 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: magnus.westerlund at ericsson.com