Subject: RE: [AVT] File format for EVRC/SMV vocoder

From: Randall Gellens <[email-masked]>
Date: Sun, 16 Mar 2003 10:54:48 -0800

At 1:52 PM +0100 3/11/03, Lars-Erik Jonsson (EAB) wrote:

>  OK, but why has not this issue been brought up earlier?

Because of an unfortunate oversight.  Neither myself nor the other 
authors of the evrc/smv draft were aware of the qcp format.  I very 
much regret this.  At the time we were working on the evrc/smv draft, 
we specified a file format to make the draft complete.  Had we been 
aware of an existing format that was currently being used to 
interoperably exchange vocoder frames, I'm sure it would have been 
considered instead of inventing something new.

>   The EVRC/SMV
>  format work in AVT has been going on for a long time, and therefore one
>  can question whether it is correct (from a procedural point of view) to
>  suddenly not use what has been developed in this WG, but use something
>  defined elsewhere. IETF standardization is usually an engineering
>  process, not rubber-stamping of already deployed technical solutions.

When I learned of the qcp format, my suggestion for how to proceed 
was to register a new mime type (audio/qcp) so as to not risk 
delaying the evrc draft.  (As one of the authors of that draft, I 
have no desire to delay it at all.)  This is what the current qcp 
draft says.  However, I was told to do the technically correct thing 
instead.

>  Note that I am not aware of all the details in this matter, but what
>  has been communicated on the list does not provide enough material for
>  motivating what has been proposed. "We have already deployed this
>  alternative format while you were trying to agree on a standard, and
>  now we think you should use our format instead since it is more
>  widely deployed" is a rather strange way of arguing in standards
>  development, I think.

The QCP format was in deployment when we started working on the 
evrc/smv draft, but neither I not the other authors were aware of 
this.  It's not the case that the qcp format was deployed afterwards 
or in parallel, in an attempt to circumvent process.

The question now is how best to proceed.  As I said, my initial 
suggestion was to take the easy path of not deleting the file format 
from the evrc/smv draft, and instead to use a kludge of registering a 
new mime type for the qcp file format.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Laughter is the closest distance between two people.
                                     --Victor Borge
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Pete McCann <[email-masked]>
Date: Sun, 16 Mar 2003 15:52:03 -0600

Hi, Randy,

Are there any intellectual property issues with the qcp format?

Also, were the interoperable implementations of the qcp format really
done independently?  My understanding is that Eudora is a Qualcomm
product and that Apple acted merely as an integrator and distributer
of the PureVoice technology from Qualcomm.  If these implementations
are not independent it may be misleading for you to talk about
interoperability.

-Pete

---

From: Stephen Casner <[email-masked]>
Date: Sun, 16 Mar 2003 21:11:11 -0800 (PST)

> draft says.  However, I was told to do the technically correct thing

My guidance to you on this was in two parts:

1.  I don't think it makes sense he have audio/qcp as a type that does
    not say what encoding is inside the qcp format file.  That led to
    my suggestion to use the existing audio/qcelp and audio/evrc
    types.  When I wrote that, I was forgetting that there already was
    a file format associated with audio/evrc.

2.  It sounded to me as if there was substantial following for qcp
    file format as the container for EVRC, and that the format in the
    evrc-smv draft was created only because the authors were unaware
    of the qcp format.

If the second point accurately reflected the situation, then it would
not be technically correct to proceed with publishing the file format
in the evrc-smv draft, and it would be fortunate that we discovered
this before publication.

However, we are now hearing significant objection to the idea of
deleting the file format in the evrc-smv draft on a variety of
points.  There can be two formats, but all of you, on both sides of
the question, are going to suffer pain in the future if there are two
formats rather than one.  You know its true.

So, the process here is to honestly assess the demand for the two
formats, without ego as to who wrote what.  If there are IPR claims
for one or the other, then that factors into the decision.  If it is a
question of market penetration, and competitors have chosen sides,
then we may be forced into the position of specifying both (or
neither).

My first point above can be satisfied while still defining both
formats by associating the file format with audio/qcelp (where, as I
understand it, there is no conflict) and audio/evrc-qcp.

                                                        -- Steve