IETF Logo Mail Archive

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

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Fri, 29 April 2016 14:57 UTC

Return-Path: <fluffy@cisco.com>
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 D0FCA12D0B8 for <rtcweb@ietfa.amsl.com>; Fri, 29 Apr 2016 07:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -115.517
X-Spam-Level:
X-Spam-Status: No, score=-115.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 vhsxfC_HuSDL for <rtcweb@ietfa.amsl.com>; Fri, 29 Apr 2016 07:57:27 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1391812D16A for <rtcweb@ietf.org>; Fri, 29 Apr 2016 07:57:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2596; q=dns/txt; s=iport; t=1461941846; x=1463151446; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3+yblBe1leyCPD8JZW6qDZ6sbZBCEG60XWqZasFEjK0=; b=MEKnB1qD6d+4kXshu+qBcBd1RkHfbT+RyrnOubdRWpP+rFhrq4HQQA6/ EgnLPGFx6+pKQBAJZFurHGljEomwiAMo/ukG1tNLkrCLqgTuKRd9ba8Xj O5SFWrwG2xKQprPkmWjZ05CSM4Vsv8aoBLXy6I93/Zbwk0K/0A1ntxdxv Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D/AQATdiNX/5BdJa1dgzhTfQa5awENgXYXC4UkSgKBKjgUAQEBAQEBAWUnhEEBAQEDAQEBAWsLBQsCAQgYLicLJQIEDgWIIggOxC0BAQEBAQEBAQEBAQEBAQEBAQEBAQERBIgXCIJOhD2DK4IrBZgTAYV7iBuBZ4d2hTSPLwEeAQFCg2tsiAJ/AQEB
X-IronPort-AV: E=Sophos;i="5.24,552,1454976000"; d="scan'208";a="265896777"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Apr 2016 14:57:10 +0000
Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u3TEvAmG015646 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Apr 2016 14:57:10 GMT
Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 29 Apr 2016 10:57:10 -0400
Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1104.009; Fri, 29 Apr 2016 10:57:10 -0400
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Harald Tveit Alvestrand <harald@alvestrand.no>
Thread-Topic: [rtcweb] Clarification in draft-ietf-rtcweb-transports-11
Thread-Index: AQHRoidnJpCOBA6OL0yIUrnna1wLIQ==
Date: Fri, 29 Apr 2016 14:57:10 +0000
Message-ID: <06096FC8-AD0F-4C9F-9334-A95F981A7EB5@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>
In-Reply-To: <56B847E2.8060109@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.249.165]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <CDB258465F55474F8D14B926115259FA@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/1V4GYs5RQj4p5Hg283fA69ovGC4>
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 14:57:33 -0000

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. 



> 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

v2.23.0 | Report a Bug | By Email