Re: [AVT] Re: <draft-ietf-avt-rtp-vmr-wb-03.txt>: Storage format

Hi,

On 13 Sep 2004, at 10:06, Magnus Westerlund wrote:
> First, the reason to have the information (mode-set and channels) in 
> the MIME type, and not only in the file header is so that a receiver 
> prior to downloading the complete content can determine its formats. 
> If you only have them in the magic numbers, then you will need get the 
> first bytes of content. A strong argument in this reasoning is email 
> systems. Many do allow you to fetch everything except attachments 
> which then later can be fetched if desired. In such a system as I 
> understand it, you will get the MIME type of the attachment together 
> with the main body. That way one can refuse to download an attachment 
> one can't handle.
>
> As VMR-WB is going to be extended and there will be a new mode-set 
> later. I would think it is very appropriate that one can actually 
> perform the above operation before download content, as there is a 
> clear risk that the content of the file may not be playable on the 
> device that downloads it.

Agreed with this.

> sassan.ahmadi@nokia.com wrote:
>> Now, if there is no MIME parameter associated with the storage format,
>> is there any change regarding the media types registration in the 
>> draft?
>
> See above arguments why I think it is appropriate to have parameters 
> also in file format case.
>
> However independently of the above issue, you will need to assign 
> different MIME names to the RTP payload format and the file format: 
> For example you could name them:
>
> audio/vmr-wb-pt  (RTP payload type)
> audio/vmr-wb-ff  (File format)

I'm not sure about this - these would seem to be the same format, so 
they should use the same media type.

>> By the way, the media types registration rules that you referred to is
>> still an individual draft and still under review and discussion, we
>> cannot really follow any of the guidelines in this draft until they 
>> are
>> finalized. Can we?
>
> Although this is an ongoing discussion, I think we should align where 
> this is reasonable and we do agree. On the issue of defining two MIME 
> types, one for the file format and one for the RTP payload format, I 
> do clearly see the motivation for that statement.
>
> I would also like to point out that the MIME types are going to expert 
> MIME review and need to pass this. So not aligning it with clearly 
> expressed views is going to make it harder. I am not saying to through 
> your own reasoning overboard, however you better start a discussion 
> with them if your view do not align on how things should be.

I have done so.

Collin

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt