Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Wed, 4 Sep 2013 20:03:06 +0000

I support the proposed text addition. But rather than adding at the end of section 3, replace the beginning of section 3 as below.

OLD:
   To ensure a baseline level of interoperability between WebRTC
   clients, a minimum set of required codecs are specified below.
   While this section specifies the codecs that will be mandated for all
   WebRTC client implementations, it leaves the question of supporting
   additional codecs to the will of the implementer.

NEW:
   To ensure a baseline level of interoperability between WebRTC
   clients, a minimum set of required codecs are specified below.
   If other suitable audio codecs are available to the browser to use, 
   it is RECOMMENDED that they are also included in the offer in order 
   to maximize the possibility to establish the session without the need 
   for audio transcoding.

Mo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bo Burman
Sent: Tuesday, August 27, 2013 10:53 AM
To: [email-masked]
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt

Based on the previous discussion thread http://www.ietf.org/mail-archive/web/rtcweb/current/msg08501.html, I believe there is support to add some text into this document.

I thus propose to add the following text at the end of section 3:

If other suitable audio codecs are available to the browser to use, 
it is RECOMMENDED that they are also included in the offer in order 
to maximize the possibility to establish the session without the need 
for audio transcoding

Cheers,
Bo

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: den 2 augusti 2013 18:30
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action: draft-ietf-rtcweb-audio-02.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF.
> 
> 	Title           : WebRTC Audio Codec and Processing Requirements
> 	Author(s)       : Jean-Marc Valin
>                           Cary Bran
> 	Filename        : draft-ietf-rtcweb-audio-02.txt
> 	Pages           : 6
> 	Date            : 2013-08-02
> 
> Abstract:
>    This document outlines the audio codec and processing requirements
>    for WebRTC client application and endpoint devices.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-audio
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-rtcweb-audio-02
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-audio-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are
> available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 5 Sep 2013 10:14:00 +0000

I support this proposal.

Kind regards,
Uwe 

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext Mo Zanaty (mzanaty)
> Sent: Wednesday, September 04, 2013 10:03 PM
> To: Bo Burman; [email-masked]
> I support the proposed text addition. But rather than adding at the end
> of section 3, replace the beginning of section 3 as below.
> 
> OLD:
> Based on the previous discussion thread http://www.ietf.org/mail-
> archive/web/rtcweb/current/msg08501.html, I believe there is support to
> add some text into this document.
> 
> > From: [email-masked] [mailto:i-d-announce-
> [email-masked]] On Behalf Of [email-masked]
> > Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are
> > Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Bo Burman <[email-masked]>
Date: Thu, 5 Sep 2013 13:05:46 +0000

I also support it.
/Bo

> From: Rauschenbach, Uwe (NSN - DE/Munich) [mailto:[email-masked]]
> Sent: den 5 september 2013 12:14
> To: ext Mo Zanaty (mzanaty); Bo Burman; [email-masked]
> Subject: RE: I-D Action: draft-ietf-rtcweb-audio-02.txt
> 
> I support this proposal.
> 
> Kind regards,
> Uwe
> 
> 
> > I support the proposed text addition. But rather than adding at the
> > end of section 3, replace the beginning of section 3 as below.
> >
> > OLD:
> > Behalf Of Bo Burman
> > archive/web/rtcweb/current/msg08501.html, I believe there is support
> > to add some text into this document.
> >
> > If other suitable audio codecs are available to the browser to use, it
> > is RECOMMENDED that they are also included in the offer in order to
> > maximize the possibility to establish the session without the need for
> > audio transcoding
> >
> > Cheers,
> > Bo
> >

---

From: Leon Geyser <[email-masked]>
Date: Thu, 5 Sep 2013 16:06:04 +0200

It would be nice if a word like mandated/mandatory is present in the new
text like it was in the old text. Maybe REQUIRED in uppercase?

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 05 Sep 2013 16:17:45 +0200

On 09/05/2013 04:06 PM, Leon Geyser wrote:
> It would be nice if a word like mandated/mandatory is present in the 
> new text like it was in the old text. Maybe REQUIRED in uppercase?

REQUIRED is an RFC 2119 reserved word, and means the same thing as MUST.
I would strenously object to REQUIRED.

RECOMMENDED is also an RFC 2119 reserved word, and means the same thing 
as SHOULD.
I have misgivings about giving such a strongly worded recommendation, 
but I can live with it.

>
>
> On 5 September 2013 15:05, Bo Burman <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I also support it.
>     /Bo
>
>     > From: Rauschenbach, Uwe (NSN - DE/Munich)
>     [mailto:[email-masked] <mailto:[email-masked]>]
>     <mailto:[email-masked]>
>     > > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     > > To: Bo Burman; [email-masked] <mailto:[email-masked]>
>     > >    While this section specifies the codecs that will be
>     mandated for
>     > > all
>     > >    to maximize the possibility to establish the session
>     without the
>     > > need
>     > >    for audio transcoding.
>     > >
>     > > Mo
>     > >
>     > > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     > > Behalf Of Bo Burman
>     > > To: [email-masked] <mailto:[email-masked]>
>     > > > From: [email-masked]
>     <mailto:[email-masked]> [mailto:i-d-announce-
>     <mailto:i-d-announce->
>     > > [email-masked] <mailto:[email-masked]>] On Behalf Of
>     [email-masked] <mailto:[email-masked]>
>     > > > To: [email-masked] <mailto:[email-masked]>
>     > > > Cc: [email-masked] <mailto:[email-masked]>
>     > > > A New Internet-Draft is available from the on-line
>     Internet-Drafts
>     > > directories.
>     > > >  This draft is a work item of the Real-Time Communication in
>     WEB-
>     > > browsers Working Group of the IETF.
>     > > >
>     > > > available at tools.ietf.org <http://tools.ietf.org>.
>     > > >
>     > > > [email-masked] <mailto:[email-masked]>
>     > > [email-masked] <mailto:[email-masked]>
>     > > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 5 Sep 2013 14:41:47 +0000

If you mean for the required codecs, that is already in the next sentence. Full context:

OLD:

WebRTC clients are REQUIRED to implement the following audio codecs.

NEW:

WebRTC clients are REQUIRED to implement the following audio codecs.

From: Leon Geyser [mailto:[email-masked]]
Sent: Thursday, September 05, 2013 10:06 AM
To: Bo Burman
Cc: Rauschenbach, Uwe (NSN - DE/Munich); Mo Zanaty (mzanaty); [email-masked]
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt

It would be nice if a word like mandated/mandatory is present in the new text like it was in the old text. Maybe REQUIRED in uppercase?

On 5 September 2013 15:05, Bo Burman <[email-masked]<mailto:[email-masked]>> wrote:
I also support it.
/Bo

> From: Rauschenbach, Uwe (NSN - DE/Munich) [mailto:[email-masked]<mailto:[email-masked]>]
> To: ext Mo Zanaty (mzanaty); Bo Burman; [email-masked]<mailto:[email-masked]>
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> > To: Bo Burman; [email-masked]<mailto:[email-masked]>
> > From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> > Behalf Of Bo Burman
> > To: [email-masked]<mailto:[email-masked]>
> > > From: [email-masked]<mailto:[email-masked]> [mailto:i-d-announce-<mailto:i-d-announce->
> > [email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
> > > To: [email-masked]<mailto:[email-masked]>
> > > Cc: [email-masked]<mailto:[email-masked]>
> > > available at tools.ietf.org<http://tools.ietf.org>.
> > >
> > > [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Lijing (Jessie, Huawei)" <[email-masked]>
Date: Fri, 6 Sep 2013 04:05:52 +0000

+1

I also support this proposal.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mo Zanaty (mzanaty)
Sent: Thursday, September 05, 2013 4:03 AM
To: Bo Burman; [email-masked]
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt

OLD:

NEW:

Mo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bo Burman
Sent: Tuesday, August 27, 2013 10:53 AM
To: [email-masked]
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt

Cheers,
Bo

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 6 Sep 2013 16:59:08 +0000

There was a discussion on this back in January and I then I thought we had converged on the following text which made a lower case type recommendation:

"If other suitable audio codecs are available to the browser to use it is recommended that they are also included in the offer in order to maximize the possibility to establish the session without the need for audio transcoding"

See http://www.ietf.org/mail-archive/web/rtcweb/current/msg06121.html

Andy

> Behalf Of Lijing (Jessie, Huawei)
> Sent: 06 September 2013 05:06
> To: Mo Zanaty (mzanaty); Bo Burman; [email-masked]
> Behalf Of Mo Zanaty (mzanaty)

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 06 Sep 2013 14:49:37 -0400

There was a consensus call made a while ago and as far as I remember,
there was no WG consensus for any SHOULD/RECOMMENDED codecs.

Cheers,

	Jean-Marc

On 08/27/2013 10:53 AM, Bo Burman wrote:
> Based on the previous discussion thread 
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg08501.html,
> I believe there is support to add some text into this document.
> 
>  it is RECOMMENDED that they are also included in the offer in
> order to maximize the possibility to establish the session without
> the need for audio transcoding
> 
> Cheers, Bo
> 
>> -----Original Message----- From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of 
>> [email-masked] Sent: den 2 augusti 2013 18:30 To: 
>> [email-masked] Cc: [email-masked] Subject: I-D Action: 
>> draft-ietf-rtcweb-audio-02.txt
>> 
>> 
>> Internet-Drafts directories. This draft is a work item of the
>> Real-Time Communication in WEB-browsers Working Group of the
>> IETF.
>> 
>>  Author(s)       : Jean-Marc Valin Cary Bran Filename        : 
>> draft-ietf-rtcweb-audio-02.txt Pages           : 6 Date :
>> 2013-08-02
>> 
>> Abstract: This document outlines the audio codec and processing 
>> requirements for WebRTC client application and endpoint devices.
>> 
>> 
>> Please note that it may take a couple of minutes from the time
>> of submission until the htmlized version and diff are available
>> at tools.ietf.org.
>> 
>> _______________________________________________ I-D-Announce 
>> mailing list [email-masked] 
> _______________________________________________ rtcweb mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 6 Sep 2013 20:28:36 +0000

Clearly no consensus for any more specific codecs. But the proposed text just says if you have more codecs available (not specific ones), you should offer them all, rather than suppress them and only offer the required codecs. So if the "will of the implementer" (current text) is neutral, this may sway them to offer more than required. If the will is hostile to other codecs, this text won't matter.

Mo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jean-Marc Valin
Sent: Friday, September 06, 2013 2:50 PM
To: Bo Burman
Cc: [email-masked]
Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt

Cheers,

	Jean-Marc

---

From: Martin Thomson <[email-masked]>
Date: Fri, 6 Sep 2013 13:38:04 -0700

On 6 September 2013 13:28, Mo Zanaty (mzanaty) <[email-masked]> wrote:
> If the will is hostile to other codecs, this text won't matter.

The natural disposition of the implementer is hostility toward more
work, so I don't see the text making much difference either way.

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 6 Sep 2013 21:42:06 +0000

True. The same can be said about every SHOULD, but we still bother to specify it.
Maybe we should update RFC 2119 to state:

Obey: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT"
Ignore: "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"

---

From: Martin Thomson <[email-masked]>
Date: Fri, 6 Sep 2013 15:22:34 -0700

> True. The same can be said about every SHOULD, but we still bother to specify it.

Most SHOULDs I've written are more like "MUST unless you have some
some good reasons that we haven't bothered to enumerate".  These serve
as an escape valve for people who want to break the rules in a
controlled environment.

That's interoperability requirements though, not implementation.  I
haven't ever done anything equivalent to MUST implement/SHOULD
implement, which is what we are talking about here.

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 07 Sep 2013 00:27:11 +0200

> Ignore: "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"

At the time 2119 was written (I remember discussing this with Scott 
Bradner several times), the intent of the text for "SHOULD" was "you'd 
better do this if you don't have a real good reason why it's not a 
reasonable thing to do in your particular case".

Quoth:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.

Of course, people who don't want to cover all the SHOULDs have pushed 
towards interpreting it as "weak recommendation that we can ignore if we 
feel like it", but that wasn't the original intent of 2119, and some of 
us still want to have that word available for use in the stronger meaning.

At one time there was push towards saying that "if you write SHOULD in 
an RFC, you need to spell out the circumstances where it'll be 
reasonable to ignore it - otherwise, write MUST or MAY". That push has 
petered out at this time, but I felt sympathetic to the idea.

That's why I'm so reluctant to use the word in cases where I think a 
large part of the implementors are going to ignore it, and where (in my 
opinion) no great harm comes to interoperability when they do.

But this instance not something I storm barricades over; if the 
consensus of the WG is to use "RECOMMENDED" rather than "recommended", 
I'll note that I'm the rough part of the consensus, and live with it.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 6 Sep 2013 15:39:35 -0700

On 6 September 2013 15:27, Harald Alvestrand <[email-masked]> wrote:
> That's why I'm so reluctant to use the word in cases where I think a large
> part of the implementors are going to ignore it, and where (in my opinion)
> no great harm comes to interoperability when they do.

I tend to agree, though we have to be careful not to end up with the
RFC 6919, Section 1 problem at the same time.

I still try to do the "MUST, unless ..." form rather than SHOULD.
SHOULD is a bit wishy-washy.

In this case, I don't see the point of saying anything at all.  I'm
sure that browser implementers will add what they believe will be best
for their users.  And avoiding transcoding is good, which should be
sufficient.  Ultimately, we're all grown-ups, and having the IETF
tells us to eat our vegetables is insulting.

---

From: <[email-masked]>
Date: Mon, 9 Sep 2013 06:47:31 +0000

Let's avoid reopening the whole discussion about this normative wording! 

I would like to recall again that the proposal from Bo comes from a compromise statement that was almost reached in e-mail discussions last January (from an initial proposal from Andrew Allen) and almost reached now again
http://www.ietf.org/mail-archive/web/rtcweb/current/msg08501.html

So it confirms clearly that the consensus of the group is on the proposed text and especially because it does not include any formal normative language. 
So I would strongly suggest to not reinvent anything new and close now this long discussion on the last proposal from Bo on which several supports have been expressed and no objections, possibly with the slight modification suggested by Mo Zanaty on the place where the text can be added (beginning of section 3) which is a good idea that I support as well
http://www.ietf.org/mail-archive/web/rtcweb/current/msg08750.html

Stéphane

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Martin Thomson
Envoyé : samedi 7 septembre 2013 00:40
À : Harald Alvestrand
Cc : [email-masked]
Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt

On 6 September 2013 15:27, Harald Alvestrand <[email-masked]> wrote:
> large part of the implementors are going to ignore it, and where (in 
> my opinion) no great harm comes to interoperability when they do.

I tend to agree, though we have to be careful not to end up with the RFC 6919, Section 1 problem at the same time.

In this case, I don't see the point of saying anything at all.  I'm sure that browser implementers will add what they believe will be best for their users.  And avoiding transcoding is good, which should be sufficient.  Ultimately, we're all grown-ups, and having the IETF tells us to eat our vegetables is insulting.
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 09 Sep 2013 10:47:14 +0200

This last round was triggered by Leon Geyser suggesting that we put 
REQUIRED in there.

I'm happy with the proposal made in January (lowercase "recommended"), 
weakly opposed to SHOULD / RECOMMENDED and strongly opposed to MUST / 
REQUIRED. I'm perfectly willing to go along with a chairs' declaration 
that the WG has consensus for SHOULD / RECOMMENDED, but it's up to the 
chairs to make the call.

I'll try to remain silent on the issue until the chairs have spoken.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 9 Sep 2013 06:04:33 -0700

On Mon, Sep 9, 2013 at 1:47 AM, Harald Alvestrand <[email-masked]>wrote:

> REQUIRED. I'm perfectly willing to go along with a chairs' declaration that
> the WG has consensus for SHOULD / RECOMMENDED, but it's up to the chairs to
> make the call.
>

I would like to hear from the chairs as well. It was not my impression that
we had consensus on any kind of recommendation here but rather that
those against a recommendation had merely grown tired of arguing.

I would suggest that we schedule a small amount of discussion time
at the next IETF to resolve this (20 min should be sufficient) and verify
consensus. However, I will defer to the chairs' judgement.

-Ekr

>> I would like to recall again that the proposal from Bo comes from a
>> compromise statement that was almost reached in e-mail discussions last
>> January (from an initial proposal from Andrew Allen) and almost reached now
>> again
>> http://www.ietf.org/mail-**archive/web/rtcweb/current/**msg08501.html<http://www.ietf.org/mail-archive/web/rtcweb/current/msg08501.html>
>>
>> So it confirms clearly that the consensus of the group is on the proposed
>> text and especially because it does not include any formal normative
>> language.
>> So I would strongly suggest to not reinvent anything new and close now
>> this long discussion on the last proposal from Bo on which several supports
>> have been expressed and no objections, possibly with the slight
>> modification suggested by Mo Zanaty on the place where the text can be
>> added (beginning of section 3) which is a good idea that I support as well
>> http://www.ietf.org/mail-**archive/web/rtcweb/current/**msg08750.html<http://www.ietf.org/mail-archive/web/rtcweb/current/msg08750.html>
>>
>> Stéphane
>>
>>
>>
>>
>>
>>
>> De : [email-masked] [mailto:rtcweb-bounces@ietf.**org<[email-masked]>]
>> De la part de Martin Thomson
>> I tend to agree, though we have to be careful not to end up with the RFC
>> 6919, Section 1 problem at the same time.
>>
>> In this case, I don't see the point of saying anything at all.  I'm sure
>> that browser implementers will add what they believe will be best for their
>> users.  And avoiding transcoding is good, which should be sufficient.
>>  Ultimately, we're all grown-ups, and having the IETF tells us to eat our
>> vegetables is insulting.
>> ______________________________**_________________
>> rtcweb mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>>
>> ______________________________**______________________________**
>> ______________________________**______________________________**_
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>> recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>> electroniques etant susceptibles d'alteration,
>> This message and its attachments may contain confidential or privileged
>> information that may be protected by law;
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Matt Fredrickson <[email-masked]>
Date: Tue, 10 Sep 2013 09:58:42 -0500

Coming from an implementor's perspective (typically), and having read quite
a few RFCs, I strongly concur with your statement, about using SHOULD in an
RFC requiring spelling out the circumstances where it's reasonable to
ignore.

As Martin said, and I agree, usually implementors take liberties to ignore
the "SHOULDs, RECOMMENDEDs, MAYs, and OPTIONALs" until they get bit by
something (usually in interop).  Then they curse the spec for using non
mandatory language for whatever bit them :-)

Matthew Fredrickson

On Fri, Sep 6, 2013 at 5:27 PM, Harald Alvestrand <[email-masked]>wrote:

> feel like it", but that wasn't the original intent of 2119, and some of us
> still want to have that word available for use in the stronger meaning.
>
> At one time there was push towards saying that "if you write SHOULD in an
> RFC, you need to spell out the circumstances where it'll be reasonable to
> ignore it - otherwise, write MUST or MAY". That push has petered out at
> this time, but I felt sympathetic to the idea.
>
> But this instance not something I storm barricades over; if the consensus
> of the WG is to use "RECOMMENDED" rather than "recommended", I'll note that
> I'm the rough part of the consensus, and live with it.
>
>
>
>
>> From: Martin Thomson [mailto:martin.thomson@gmail.**com<[email-masked]>
>> ]

---

From: Matt Fredrickson <[email-masked]>
Date: Tue, 10 Sep 2013 10:01:47 -0500

I support it as well.

Matthew Fredrickson

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 10 Sep 2013 12:26:30 -0400

> to maximize the possibility to establish the session without the need

Let's look at the practical effect here, assuming people were to
actually follow such a recommendation. The only audio codecs that are
implemented in browsers but not available for WebRTC are the ones used
for HTML5. According to http://html5test.com/ these codecs are Vorbis,
MP3, AAC, and uncompressed PCM. These are the codecs that would be
recommended under such text. None of them is really ideal for
interactive audio, none of them is implemented in old phones AFAIK, but
all of them would require time and effort to add to a browser's RTP
stack. I really don't see the point here.

	Jean-Marc

---

From: Roman Shpount <[email-masked]>
Date: Tue, 10 Sep 2013 12:54:42 -0400

> stack. I really don't see the point here.
My biggest problem with the recommendation text is "other suitable audio
codecs are available to the browser to use". Jean-Marc's comment underlines
the problem. His interpretation is that this refers to codecs already
implemented in the browser. Another interpretation is that this refers to
codecs already implemented in the underlying OS or platform, such as AMR-WB
or H.264. Yet another interpretation implies codecs with no associated
patents, such as G.722 or G.726. Yet another interpretation is that implies
codecs with patent licenses which allows free implementation such as iLBC
or iSAC. What is the intent here? With so many interpretations this
language is completely useless.

I think original intent was to encourage browser implementers to add
support for G.722, AMR and AMR-WB if available in underlying platform, and
H.264, if available in underlying platform or browser. In this regards this
language fails completely. Don't you think it would be better to state
exactly what the intent is and provide the language when implementation of
each of those codecs is not required (meaning if additional license fees
will need to be paid or due to incompatible licensing policy).
_____________
Roman Shpount

---

From: <[email-masked]>
Date: Wed, 11 Sep 2013 09:19:41 +0000

>These are the codecs that would be recommended under such text. None of them is really ideal for interactive audio

That is the reason why the proposed text only applies to "suitable" audio codecs
" If other suitable audio codecs..."

That's also why it cannot be interpreted as a strictly normative text and why I also suggested (as it was previously suggested by the Chairs) to have some additional informative (and separate) text about what are those suitable codecs to be considered and what is the rationale behind this (http://www.ietf.org/mail-archive/web/rtcweb/current/msg08501.html)

Stéphane

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Jean-Marc Valin
Envoyé : mardi 10 septembre 2013 18:27
À : Mo Zanaty (mzanaty)
Cc : [email-masked]
Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-audio-02.txt

> To ensure a baseline level of interoperability between WebRTC clients, 
> a minimum set of required codecs are specified below.
> audio transcoding.

Let's look at the practical effect here, assuming people were to actually follow such a recommendation. The only audio codecs that are implemented in browsers but not available for WebRTC are the ones used for HTML5. According to http://html5test.com/ these codecs are Vorbis, MP3, AAC, and uncompressed PCM. These are the codecs that would be recommended under such text. None of them is really ideal for interactive audio, none of them is implemented in old phones AFAIK, but all of them would require time and effort to add to a browser's RTP stack. I really don't see the point here.

	Jean-Marc

---

From: Tim Panton <[email-masked]>
Date: Thu, 12 Sep 2013 10:54:09 +0100

As I said last time this came up, we need to include language that ensures that these non-mandatory codecs don't 
get used unless the mandatory ones are unavailable, or the web developer explicitly selected them.

I don't want to find that I'm getting amr-nb between a pair of phone based browsers and getting narrow band because
both the phones happen to have that codec available.

How about: 

To ensure a baseline level of interoperability between WebRTC clients, 
a minimum set of required codecs are specified below.
If other suitable audio codecs are available to the browser to use, it 
is advised that they are also included in the offer at a lower priority than the required codecs in order to 
maximize the possibility to establish the session without the need for 
audio transcoding when the required codecs are unavailable to one party.

- Of course this whole discussion highlights the need for a set of constraints (or an API) that let the web developer 
express her preferences wrt codec selection.

Tim.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 12 Sep 2013 12:43:08 -0700

> express her preferences wrt codec selection.

[BA] This - and the need to specify the default ordering of codecs within the API, so that by default the MTI codecs will be offered at a higher priority. 

> audio transcoding when the required codecs are unavailable to one party.
 
[BA] On reading this I'm unsure whether by "offer" you mean the SDP used in the API, of if you're talking about an offer sent over the wire.   The text makes more sense to me if you're talking about the API. 
 
If the developer decides they want to offer amr-nb as the preferred codec in an Offer sent over the wire, that's their choice, as long as they don't delete the MTI codecs from the offer, which could potentially cause an interoperability failure.   However, if the developer is just trusting the API to do something sensible, then by default I'd say that one of the MTI codecs should be negotiated by default.  In particular, in the browser-browser case I'd advocate that Opus by negotiated by default, for audio.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 12 Sep 2013 15:49:42 -0400

On Thu, Sep 12, 2013 at 3:43 PM, Bernard Aboba <[email-masked]>wrote:

>
> [BA] This - and the need to specify the default ordering of codecs within
> the API, so that by default the MTI codecs will be offered at a higher
> priority.
>

I am not sure that MTI codecs should always be highest priority. If
optional codec would be developed of higher quality then Opus or the yet to
be defined MTI video codec (for instance if someone created Opus-NG or in
case of VP9 or H.265), then there is no reason for this codec not to be
offered at higher priority then MTI.
_____________
Roman Shpount