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

From: [email-masked]
Date: Tue, 22 Apr 2003 12:38:56 -0500

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:[email-masked]]
Sent: 22 April, 2003 12:27 PM
To: Adam Li
Cc: [email-masked]; 'Scott Bradner'; 'Allison Mankin'; Greer Craig
(Nokia/Dallas); [email-masked]; [email-masked]; 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:[email-masked]]
>> Sent: Saturday, March 15, 2003 9:20 PM
>> To: 'Ietf-Avt'
>> Cc: [email-masked]'; 'Scott Bradner'; 'Colin Perkins'; 'Allison
>> Mankin'; [email-masked]'; [email-masked]';
>> [email-masked]'; [email-masked]'; [email-masked]';
>> [email-masked]'; [email-masked]';
>> [email-masked]'; [email-masked]'; [email-masked]';
>> [email-masked]'; [email-masked]';
>> [email-masked]'; [email-masked]'; [email-masked]';
>> [email-masked]'; 'magnus.westerlund@era-
>> t.ericsson.se'; [email-masked]'; [email-masked]';
>> [email-masked]'; [email-masked]'; [email-masked]';
>> [email-masked]'; [email-masked]'; [email-masked]';
>> [email-masked]'; [email-masked]'; [email-masked]'
>> 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
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Tue, 22 Apr 2003 14:04:57 -0400

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

---

From: Randall Gellens <[email-masked]>
Date: Wed, 23 Apr 2003 15:33:15 -0700

>  type, since "audio/qcp" seems appropriate).

Regarding the MIME type, "audio/qcp" was the initial suggested MIME 
type, but there was pushback based on the principle that MIME types 
should describe the content, not the format.  In general, neglect of 
this principle reduces interoperability, since it then means that an 
implementation that supports a certain MIME type may not be able to 
handle content received in that MIME type.  So, in accordance with 
the principle, it makes sense to use "audio/qcelp" for QCELP 13K data 
in this format, "audio/evrc-qcp" for EVRC data stored in the QCP 
format, and "audio/smv-qcp" for SMV data in the QCP format.

I suppose "audio/qcelp" plus "audio/qcp" with a mandatory parameter 
for the codec included, which could only be SMV or EVRC, not QCELP, 
could also work.  I've added Ned Freed to the distribution list to 
get his views, as the IANA-designated MIME expert.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Randall Gellens <[email-masked]>
Date: Wed, 23 Apr 2003 18:50:01 -0700

>  draft for ".QCP". Of course we need Qualcomm to verify this.

Yes, this was the agreed resolution; an updated qcp draft will be 
published.  See my earlier message to the list for the MIME type 
discussion.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
I make a fortune from criticizing the policy of the government, and
then hand it over to the government in taxes to keep it going.
                                              --George Bernard Shaw
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: [email-masked]
Date: Thu, 24 Apr 2003 23:21:09 -0700 (PDT)

> handle content received in that MIME type.

Yes, although there's sometimes a fine line between content differences and the
use of different content options. The standard example is PostScript, which has
numerous optional facilities, so many that describing them all in  either
parameters or in subtype names is clearly impractical.

> So, in accordance with

> get his views, as the IANA-designated MIME expert.

(FYI, I'm on the AVT list already...)

I tend to lean towards separate types myself, but either way will work.

				Ned