Subject: [rtcweb] Clarification in draft-ietf-rtcweb-transports-11

From: Cullen Jennings <[email-masked]>
Date: Wed, 3 Feb 2016 11:16:29 -0400

I think we need to make the ALPN a bit more explicit. We agreed to include the ALPN header so that a proxy knows it might receive video packet rates tunnelled across it. However the text on this is not 100% clear. Right now it says

   If it does so, it MUST support the "ALPN" header as
   specified in [RFC7639],

But some people have posted out including this header is optional in 7639 so there might be some ubiquity here about what is meant. I think we should change the word “support” to “include” to make it clear this needs to be sent to the proxy so that it would read

    If it does so, it MUST include the "ALPN" header as
   specified in [RFC7639],

I believe that correctly reflects what we intended on this. There is no requirement for the proxy to understand or do anything with this header. Old proxies will just ignore it and cary on as if it was not there. 

Cullen

(with my individual contributor hat on)

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 Feb 2016 07:58:38 -0800

On Wed, Feb 3, 2016 at 7:16 AM, Cullen Jennings <[email-masked]> wrote:

> I think we need to make the ALPN a bit more explicit. We agreed to include
> the ALPN header so that a proxy knows it might receive video packet rates
> tunnelled across it. However the text on this is not 100% clear. Right now
> it says
>
> But some people have posted out including this header is optional in 7639
> so there might be some ubiquity here about what is meant. I think we should
> change the word “support” to “include” to make it clear this needs to be
> sent to the proxy so that it would read
>
> I believe that correctly reflects what we intended on this. There is no
> requirement for the proxy to understand or do anything with this header.
> Old proxies will just ignore it and cary on as if it was not there.
>

I wouldn't have a problem with this if it were restricted to browsers.
However,
we don't want to careful about retroactively branding endpoints which aren't
browsers but can talk to WebRTC clients as noncompliant. Maybe this
is like codecs where they are "WebRTC Compatible"?

-Ekr

Cullen
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 5 Feb 2016 17:28:10 +1100

I think that Cullen's request is reasonable.

I really don't understand the obsession with labeling.  Branding something
as less than 100% "compliant" if they don't use the header field seems OK
to me.  There are plenty of other places where implementations will be
non-compliant. Also, I think that everyone involved understands that the
target is still moving.
On Feb 5, 2016 2:59 AM, "Eric Rescorla" <[email-masked]> wrote:

>> I think we need to make the ALPN a bit more explicit. We agreed to
>> include the ALPN header so that a proxy knows it might receive video packet
>> rates tunnelled across it. However the text on this is not 100% clear.
>> Right now it says
>>

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 8 Feb 2016 08:46:42 +0100

This seems reasonable.

Filed https://github.com/rtcweb-wg/rtcweb-transport/issues/12 so as to
not forget.

On 02/05/2016 07:28 AM, Martin Thomson wrote:
> I really don't understand the obsession with labeling.  Branding
> something as less than 100% "compliant" if they don't use the header
> field seems OK to me.  There are plenty of other places where
> implementations will be non-compliant. Also, I think that everyone
> involved understands that the target is still moving.
>
> On Feb 5, 2016 2:59 AM, "Eric Rescorla" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>     On Wed, Feb 3, 2016 at 7:16 AM, Cullen Jennings <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         I think we need to make the ALPN a bit more explicit. We
>         agreed to include the ALPN header so that a proxy knows it
>         might receive video packet rates tunnelled across it. However
>         the text on this is not 100% clear. Right now it says
>
>         But some people have posted out including this header is
>         optional in 7639 so there might be some ubiquity here about
>         what is meant. I think we should change the word “support” to
>         “include” to make it clear this needs to be sent to the proxy
>         so that it would read
>
>         I believe that correctly reflects what we intended on this.
>         There is no requirement for the proxy to understand or do
>         anything with this header. Old proxies will just ignore it and
>         cary on as if it was not there.
>
>
>     I wouldn't have a problem with this if it were restricted to
>     browsers. However,
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
Surveillance is pervasive. Go Dark.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 8 Feb 2016 11:07:48 +0000

Cullen's suggestion also seems reasonable to me and reflects what we intended to say anyway.

Andy

From: rtcweb [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 08 February 2016 07:47
To: [email-masked]
Subject: Re: [rtcweb] Clarification in draft-ietf-rtcweb-transports-11

This seems reasonable.

Filed https://github.com/rtcweb-wg/rtcweb-transport/issues/12 so as to not forget.

I really don't understand the obsession with labeling.  Branding something as less than 100% "compliant" if they don't use the header field seems OK to me.  There are plenty of other places where implementations will be non-compliant. Also, I think that everyone involved understands that the target is still moving.
On Feb 5, 2016 2:59 AM, "Eric Rescorla" <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Feb 3, 2016 at 7:16 AM, Cullen Jennings <[email-masked]<mailto:[email-masked]>> wrote:
I think we need to make the ALPN a bit more explicit. We agreed to include the ALPN header so that a proxy knows it might receive video packet rates tunnelled across it. However the text on this is not 100% clear. Right now it says

But some people have posted out including this header is optional in 7639 so there might be some ubiquity here about what is meant. I think we should change the word "support" to "include" to make it clear this needs to be sent to the proxy so that it would read

I wouldn't have a problem with this if it were restricted to browsers. However,
we don't want to careful about retroactively branding endpoints which aren't
browsers but can talk to WebRTC clients as noncompliant. Maybe this
is like codecs where they are "WebRTC Compatible"?

-Ekr

Cullen

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

rtcweb mailing list

[email-masked]<mailto:[email-masked]>

--