Re: [AVT] The storage format of EVRC/SMV vocoder (resent)

Keith,

Are there minutes of this meeting available? I'd like to understand the
rationale behind the choice (especially the choice of changing the MIME 
type, since "audio/qcp" seems appropriate).

Colin

--> keith.miller@nokia.com writes:
>All,
>
>This issue was discussed at the last 3GPP2 (April 14-18) meeting by the group developing the 3GPP2
>file format specification. It was decided that both formats should be published, but
>that Qualcomm would request a different MIME type for the EVRC storage in .QCP
>(maybe EVRC_QCP). Hari Garudadri is expected to submit an updated
>draft for ".QCP". Of course we need Qualcomm to verify this.
>
>regards,
>KEith Miller
>Chair 3GPP2 TSG-C 1.2 WG
>
>-----Original Message-----
>From: ext Colin Perkins [mailto:csp@csperkins.org]
>Sent: 22 April, 2003 12:27 PM
>To: Adam Li
>Cc: avt@ietf.org; 'Scott Bradner'; 'Allison Mankin'; Greer Craig
>(Nokia/Dallas); jlee@nextreaming.com; sakazawa@kddilabs.jp; Miller Keith
>(NRC/Dallas)
>Subject: Re: [AVT] The storage format of EVRC/SMV vocoder (resent) 
>
>
>Adam,
>
>The format specified in draft-garudadri-qcp-00.txt clearly needs to be
>published, and to have a MIME type registered, since it has been used by
>several applications for some years now. 
>
>What is unclear is whether draft-ieft-avt-evrc-smv-03.txt should refer to
>that format, or if it should continue to use the alternative format. The
>usual arguments apply: having two formats is clearly worse than one, but
>there may be technical or political reasons why the new format is to be
>preferred for some uses. 
>
>As the minutes from the recent AVT meeting note, the main users of the
>format in draft-ieft-avt-evrc-smv-03.txt seem to be 3GPP2. It is currently
>unclear if they have implementations of the file format, and if they chose
>it for technical reasons or because it it was the only format they knew. We
>are hoping to get input from them, to clarify their position.
>
>Colin
>
>
>
>
>--> "Adam Li" writes:
>>
>>The issue of the storage format of the EVRC and SMV vocoders in the MIME
>>registration has came up a while ago, and has caused the last minute
>>holding of the MIME registration for these two vocoders. The issue has
>>been discussed thoroughly here on the mailing list in the San Francisco
>>meeting. The reasons of each side of the argument have been well
>>presented. Now it may be time to make a decision?
>>
>>Like many other issues in our AVT WG, the decision here is ultimately
>>relying on the judgment of our chairs. During the two and half years
>>that this draft is being developed in the AVT, the course of the draft
>>has benefited greatly from your guidance. After the open and ego-free
>>discuss that our chairs called upon at the meeting session, it may be
>>another good time to hear the opinions from the chairs and get some help
>>on the decision from their experience and vision on which one will
>>reflect the consensus of the AVT and would be most beneficial to the
>>whole Internet and telecom industry who will use our specification.
>>
>>Below is the summary of the rationales for each of the choices:
>>
>>  draft-ieft-avt-evrc-smv-03.txt    |    draft-garudadri-qcp-00.txt
>>------------------------------------+--------------------------------
>>(1) Mature specification, been      | (1) Brand new ID
>>    developed for 2.5 years in AVT  |
>>------------------------------------+--------------------------------
>>(2) Covers both EVRC and SMV        | (2) Only cover EVRC
>>------------------------------------+--------------------------------
>>(3) Referred to by 3GPP2(*) FFMS    | (3) 
>>    specifications                  |
>>------------------------------------+--------------------------------
>>(4) Implemented and used by many 3G | (4) Supported in Eudora
>>    telecom operators (e.g., SKT,   |
>>    KTF, LGT). The interoperability |
>>    has been tested among them.     |
>>------------------------------------+--------------------------------
>>(5) Simple and efficient design,    | (5)
>>    quick to implement              |
>>------------------------------------+--------------------------------
>>(6) Registration already in IANA,   | (6)
>>------------------------------------+--------------------------------
>>(7) Supported and developed by 7    | (7) Supported and developed by
>>    companies and universities      |     Qualcomm
>>    (including Qualcomm)            |
>>------------------------------------+--------------------------------
>>(8) No IP related to this format    | (8) IP situation unclear
>>------------------------------------+--------------------------------
>>
>>(*) ERVC and SMV are both vocoders developed and defined in the
>>international consortium 3GPP2 (http://www.3gpp2.org) for the next
>>generation wireless network cdma2000.
>>
>>Thank you very much.
>>
>>Adam
>>
>>PS. This is a resent of the previous message, which did not seem to go
>>through maybe because of the long cc list. If you think anyone is missed
>>out, please let me know. Thanks.
>>
>>> -----Original Message-----
>>> From: Adam Li [mailto:adamli@icsl.ucla.edu]
>>> Sent: Saturday, March 15, 2003 9:20 PM
>>> To: 'Ietf-Avt'
>>> Cc: 'casner@acm.org'; 'Scott Bradner'; 'Colin Perkins'; 'Allison
>>> Mankin'; 'randy@qualcomm.com'; 'mccap@lucent.com';
>>> 'mdturner@lucent.com'; 'smathai@lucent.com'; 'lioy@qualcomm.com';
>>> 'zeng@packetvideo.com'; 'sherwood@packetvideo.com';
>>> 'villa@icsl.ucla.edu'; 'yllee@samsung.com'; 'jeonghoon@samsung.com';
>>> 'tom.hiller@lucent.com'; 'David.Leon@nokia.com';
>>> 'nleung@qualcomm.com'; 'dgal@lucent.com'; 'ajayrajkumar@lucent.com';
>>> 'Lars-Erik.Jonsson@epl.ericsson.se'; 'magnus.westerlund@era-
>>> t.ericsson.se'; 'vbharga@cisco.com'; 'craig.greer@nokia.com';
>>> 'magda@qualcomm.com'; 'casner@acm.org'; 'ned.freed@mrochek.com';
>>> 'mankin@psg.com'; 'hgarudad@qualcomm.com'; 'csp@isi.edu';
>>> 'jlee@nextreaming.com'; 'sakazawa@kddilabs.jp'; 'tsgc@3gpp2.org'
>>> Subject: Issues for the file format for EVRC/SMV vocoder
>>> 
>>> Hi folks,
>>> 
>>> The topic of the file format for EVRC/SMV vocoders hopefully will be
>>> discussed in this meeting at San Francisco. Below is a list of the
>>> issues that might be related to this topic. They are listed here as
>>> potential issues for you to consider before the discussion at the
>>> meeting.
>>> 
>>> (1) Technically differences. Is there much difference in efficiency
>>> and performance between the format in draft-ietf-avt-evrc-smv and
>>> draft-garudadri-qcp? Are the differences simply on the file syntax?
>>> 
>>> (2) Completeness. For EVRC codec data, formats defined in both
>>> document can handle it. For SMV codec data, the format defined in
>>> draft-ietf-avt-evrc-smv is currently the only file format that
>>> handles SMV data. draft-garudadri-qcp does not handle SMV at this
>>> time.
>>> 
>>> (3) Maturity of the format definition. draft-ietf-avt-evrc-smv has
>>> its first version submitted to AVT on November 2000. It has been
>>> actively worked on all these years, and is co-authored by people
>>> from seven companies and universities. It is currently on the RFC
>>> editor's queue. draft-garudadri-qcp is submitted in February 2003.
>>> Will there be concerns about the maturity of the drafts,
>>> particularly the handling of SMV codec hasn't been written in the
>>> later draft yet?
>>> 
>>> (4) The recognition. Since EVRC and SMV codec are designed in 3GPP2
>>> for their CDMA networks, formats recognized by them are likely to be
>>> the most widely used format for those codecs. Which of the formats,
>>> as defined in draft-ietf-avt-evrc-smv and draft-garudadri-qcp, has
>>> been considered by 3GPP2 for the format for storing EVRC and SMV
>>> data?
>>> 
>>> (5) Document organization. Even though this is a rather minor point,
>>> but would there be enough reasons to trade-off for the additional
>>> complexity for having the MIME registration of EVRC/SMV refering to
>>> a separate and yet to be complete draft?
>>> 
>>> Draft-ietf-avt-evrc-smv is currently on the RFC editor's queue. If
>>> we want to consider deleting the file format that is in the draft
>>> for almost two years in the last minute before it becomes an RFC and
>>> using another yet to be complete new draft instead, we should be
>>> providing ourselves with the clear justification for doing so.
>> 
>>> I will not be there for the discussion unfortunately since I have
>>> not made the plan to attend in advance. However, I hope the list of
>>> potential issues above might be useful for us to discuss and
>>> consider.
>>> 
>>> Wish we have a fruitful meeting in San Francisco.
>>> 
>>> Adam
>>
>>
>>_______________________________________________
>>Audio/Video Transport Working Group
>>avt@ietf.org
>>https://www1.ietf.org/mailman/listinfo/avt
>_______________________________________________
>Audio/Video Transport Working Group
>avt@ietf.org
>https://www1.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt