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

Harald Alvestrand <harald@alvestrand.no> Fri, 29 April 2016 15:17 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4722C12B062 for <rtcweb@ietfa.amsl.com>; Fri, 29 Apr 2016 08:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level:
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5T6zExuyZCWM for <rtcweb@ietfa.amsl.com>; Fri, 29 Apr 2016 08:17:11 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C6E412D0AA for <rtcweb@ietf.org>; Fri, 29 Apr 2016 08:17:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 5BF047C7F36; Fri, 29 Apr 2016 17:17:09 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PXDlVJzuwqx; Fri, 29 Apr 2016 17:17:07 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:1:9cb2:7a2a:8f4:70fa] (unknown [IPv6:2001:470:de0a:1:9cb2:7a2a:8f4:70fa]) by mork.alvestrand.no (Postfix) with ESMTPSA id C2BFC7C7F35; Fri, 29 Apr 2016 17:17:07 +0200 (CEST)
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
References: <F63DF3E8-51BF-4142-923A-663D053483C8@iii.ca> <CABcZeBOjYyQP10sSK91EvaCnW0c-ei+UJqk5KOkTG4CEjE=gzQ@mail.gmail.com> <CABkgnnXchQTa4VEawdPeKbwP0QStcxGifhL-vboxhPTKEEFfuQ@mail.gmail.com> <56B847E2.8060109@alvestrand.no> <06096FC8-AD0F-4C9F-9334-A95F981A7EB5@cisco.com>
From: Harald Alvestrand <harald@alvestrand.no>
Message-ID: <57237AF3.8050800@alvestrand.no>
Date: Fri, 29 Apr 2016 17:17:07 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <06096FC8-AD0F-4C9F-9334-A95F981A7EB5@cisco.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/kY1UUSy4XuT3u5cBvd79m4UZvpc>
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Clarification in draft-ietf-rtcweb-transports-11
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Apr 2016 15:17:14 -0000

Den 29. april 2016 16:57, skrev Cullen Jennings (fluffy):
> 
> Github says this was fixed in version -10 - See https://github.com/rtcweb-wg/rtcweb-transport/issues/12
> 
> But it does not seem to be in the -10 draft or latest draft so I'm wondering if it got lost along the way somewhere. 

You're right. I reopened the issue.

> 
> 
> 
>> On Feb 8, 2016, at 12:46 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
>>
>> This seems reasonable.
>>
>> Filed https://github.com/rtcweb-wg/rtcweb-transport/issues/12 so as to not forget.
>>
>>>
>>>
>>> On Wed, Feb 3, 2016 at 7:16 AM, Cullen Jennings <fluffy@iii.ca> 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
>>>
>>>    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.
>>>
>>> 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
>>>
>>> (with my individual contributor hat on)
>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>>
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>> -- 
>> Surveillance is pervasive. Go Dark.
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>