From nobody Tue Mar 1 00:04:42 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567031B2A5D for ; Tue, 1 Mar 2016 00:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 PwYPrNoxFLWl for ; Tue, 1 Mar 2016 00:04:35 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0091.outbound.protection.outlook.com [65.55.169.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80F51B2A5B for ; Tue, 1 Mar 2016 00:04:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OadMUS+LmdoRrrvKcdOBnHf+Ed6kg3lNM99RsIc0nsI=; b=bKOrDUgjUel7x+/51CexE5CtuaKL4NTKYw8wQUOmphqa8le0MKT7PM9Ylch5OV+XBKFCijfcrtp9EJFchTr4HQAmStXlOPbvbUBWnmefuBypbK2iPAwkluIntuG1p+bvn1B8GzLBZ261LJ+TA0INkahpw0idiCltP4UmdMx93rQ= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 1 Mar 2016 08:04:31 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Tue, 1 Mar 2016 08:04:31 +0000 From: "Asveren, Tolga" To: Ted Hardie Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p89KcurgAAU0gCAALLLgIAAOucggAC01ICAANVAYIAAKmkAgAA3mfCAAzMegIAAEaGAgAAC3oCAAAAVkIAAD2GAgAAJS/qAAA2lgIAAuVMQ Date: Tue, 1 Mar 2016 08:04:31 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> <56D000EF.9010004@alvestrand.no> <56D1A080.7050901@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 51a5a752-93bd-4a3b-52f2-08d341a81e8c x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:ZsT+MnjFYdXDtY5nhHl1EzGEt27TCzCo+ul0HjGl52OBZrdSLPfSLJAP3ZU+cJTEWGba7L97YiNXgV0wYx1lHed3DQdSq6Fb3Up5bdiXf5eZjVCxCnUCLh8xvaLxNf7qkfGVValan09yDNUg9A3ycQ==; 24:kg0oggat4tXsypUXvpxQYfWq95j9Jv/eQhjf9fKvj0gRBQ0Usz5eZVke05EJ0eOFUIRykbyUy+7+EwwekVhntqWfl2Nf6+pRw07pWTjBarU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 086831DFB4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(24454002)(53754006)(164054003)(2473001)(377454003)(106116001)(3846002)(87936001)(11100500001)(50986999)(19300405004)(5002640100001)(76176999)(2906002)(81156008)(110136002)(102836003)(93886004)(230783001)(5003600100002)(76576001)(1096002)(3660700001)(19625215002)(16236675004)(5004730100002)(122556002)(10400500002)(3280700002)(92566002)(790700001)(74316001)(3900700001)(40100003)(6116002)(19609705001)(2900100001)(5001960100003)(33656002)(4326007)(586003)(19580405001)(1220700001)(2950100001)(5008740100001)(189998001)(54356999)(99286002)(66066001)(77096005)(86362001)(19580395003)(15975445007)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB15518F98FD31A3BAE6505079B2BB0SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2016 08:04:31.0320 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 08:04:40 -0000 --_000_SN1PR0301MB15518F98FD31A3BAE6505079B2BB0SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aS0gSSB0aG91Z2h0IEkgYW5zd2VyZWQgdGhhdCBhc3BlY3QgYnV0IGhlcmUgaXQgZ29lcyBhZ2Fp biB3aXRoIGFuIGV4YW1wbGU6DQoNCkFwcCBEZXZlbG9wZXIsIHdobyBrbm93cyB3aGF0IGhlIGlz IGRvaW5nOg0KQVBJIGNhbGw6DQpTZW5kX0RUTUZfRGlnaXQo4oCcNeKAnSwgZHVyYXRpb249MjAw MG1zLCBpbnRlcnZhbD02MG1zKQ0KQnJvd3NlciB1c2VzIHRoZSB2YWx1ZXMgc3VwcGxpZWQgaW4g dGhlIEFQSSBjYWxsLiBJdCBkb2VzIG5vdCBlbmZvcmNlIGFueSBjaGVja3MuDQpBcHAuIERldmVs b3BlciBtYXkgdXNlIGRpZmZlcmVudCB2YWx1ZXMgYmFzZWQgb24gdGhlIG5lZ290aWF0ZWQgY29k ZWMuDQoNCkFwcCBEZXZlbG9wZXIsIHdobyBpcyBub3Qgc2F2dnkgYWJvdXQgRFRNRiBkaWdpdHM6 DQpBUEkgY2FsbDoNClNlbmRfRFRNRl9EaWdpdCjigJw14oCdKQ0KQnJvd3NlciB1c2VzIGl0cyBk ZWZhdWx0IHZhbHVlcyBmb3IgZHVyYXRpb24gYW5kIGludGVydmFsLg0KQnJvd3NlciBkZWZhdWx0 IHZhbHVlcyBtYXkgYmUgZGlmZmVyZW50IGJhc2VkIG9uIHRoZSBuZWdvdGlhdGVkIGNvZGVjLg0K RGlmZmVyZW50IGJyb3dzZXJzIG1heSB1c2UgZGlmZmVyZW50IGRlZmF1bHQgdmFsdWVzIGJ1dCB0 aGlzIGRvZXMgbm90IGNhdXNlIGFueSBwcm9ibGVtIGZyb20gQXBwLiBEZXYuIHBlcnNwZWN0aXZl Lg0KDQpPdmVyYWxsLCBicm93c2VyIG5ldmVyIGVuZm9yY2VzIGEgcmFuZ2UuIElUIGVpdGhlciB1 c2VzIHdoYXQgaGFzIGJlZW4gc3VwcGxpZWQgYnkgdGhlIEFQSSBjYWxsIGRpcmVjdGx5IG9yIGl0 cyBkZWZhdWx0IHZhbHVlcy4NCg0KaWktIEkgdGhpbmsgYW55IGVuZm9yY2VkIHJhbmdlIGlzIGFs d2F5cyBndWVzc3dvcmsgYW5kIHdlIG1heSBiZSBsaW1pdGluZyBzb21lIHVzZSBjYXNlcyAocGVv cGxlIGNhbiBiZSBpbWFnaW5hdGl2ZSA7LSkgKS4gRXNwZWNpYWxseSBhIG1pbiBvZiA0MG1zIGlz IHRvbyBoaWdoIElNSE8uIEJ1dCBhcyBzYWlkLCBJIGRvbuKAmXQgc2VlIGEgcmVhc29uIGZvciB0 aGUgYnJvd3NlciBlbmZvcmNpbmcgYSByYW5nZSBhbnlob3cuDQoNClRoYW5rcywNClRvbGdhDQoN CkZyb206IFRlZCBIYXJkaWUgW21haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb21dDQpTZW50OiBNb25k YXksIEZlYnJ1YXJ5IDI5LCAyMDE2IDM6NTMgUE0NClRvOiBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVy ZW5Ac29udXNuZXQuY29tPg0KQ2M6IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPjsg SGFyYWxkIEFsdmVzdHJhbmQgPGhhcmFsZEBhbHZlc3RyYW5kLm5vPjsgcnRjd2ViQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gRndkOiBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLXJ0Y3dl Yi1hdWRpby0xMC50eHQ+IChXZWJSVEMgQXVkaW8gQ29kZWMgYW5kIFByb2Nlc3NpbmcgUmVxdWly ZW1lbnRzKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KDQpIb3dkeSwNCk9uIE1vbiwgRmViIDI5LCAy MDE2IGF0IDEyOjEwIFBNLCBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPG1h aWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20+PiB3cm90ZToNCi0gQXBwIGRldmVsb3BlciBrbm93 cyB3aGF0IGhlIGlzIGRvaW5nDQoNCllvdSBzdGlsbCBoYXZlIG5vdCBhbnN3ZXJlZCB0aGUgcXVl c3Rpb24gb2YgaG93IHRoZSBhcHBsaWNhdGlvbiBkaXNjZXJucyB3aGF0IHRoZSBib3VuZHMgYXJl IGZvciBhIGJyb3dzZXIsIGlmIHRoZXkgYXJlIG5vdCBzcGVjaWZpZWQuDQpBbHNvLCBhc3N1bWlu ZyBlaXRoZXIgNDAvNjAwMCAob3IgZXZlbiA0MC84MDAwLCB0byBmb2xsb3cgUm9tYW4ncyByZWNl bnQgc3VnZ2VzdGlvbikgYXJlIHVzZWQgaW4gY29uZm9ybWFuY2Ugd2l0aCBQU1ROIHJlcXVpcmVt ZW50cywgd2hhdCBpcyB0aGUgbGlrZWxpaG9vZCB0aGF0IHRoZSBkZXZlbG9wZXIgd2hvIGtub3dz IHdoYXQgc2hlJ3MgZG9pbmcgaXMgZ29pbmcgdG8gc2VsZWN0IHNvbWV0aGluZyBvdXRzaWRlIHRo YXQgcmFuZ2U/DQpyZWdhcmRzLA0KVGVkDQoNCg0KVGhhbmtzLA0KDQpUb2xnYQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVs dXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXguY29tPj4NClNlbnQ6IE1vbmRheSwgRmVicnVh cnkgMjksIDIwMTYgMjozMCBQTQ0KVG86IEFzdmVyZW4sIFRvbGdhDQpDYzogVGVkIEhhcmRpZTsg SGFyYWxkIEFsdmVzdHJhbmQ7IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIEZ3ZDogTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1ydGN3 ZWItYXVkaW8tMTAudHh0PiAoV2ViUlRDIEF1ZGlvIENvZGVjIGFuZCBQcm9jZXNzaW5nIFJlcXVp cmVtZW50cykgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCg0KT24gTW9uLCBGZWIgMjksIDIwMTYgYXQg MTo0MiBQTSwgQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFz dmVyZW5Ac29udXNuZXQuY29tPj4gd3JvdGU6DQpJIGFtIG5vdCBzdXJlIHdoZXRoZXIgNDBtcyBz aG91bGQgYmUgYWJzb2x1dGUgbWluaW11bSBmb3IgYWxsIGNvZGVjcy4gRXZlbiBmb3IgNjAwMG1z LCB3aG8gYW0gSSB0byBhcmd1ZSB0aGF0IHNvbWVib2R5IGNhbuKAmXQgY29tZSB1cCB3aXRoIGEg dXNlIGNhc2UvYXBwbGljYXRpb24sIHdoaWNoIHJlcXVpcmVzIHNvbWV0aGluZyBsb25nZXIuIFNv LCBvdmVyYWxsLCBlbmZvcmNpbmcgZG9lcyBub3Qgc2VlbSB0byBiZSB0aGUgcmlnaHQgdGhpbmcg SU1HTyAoZGVmYXVsdCB2YWx1ZSBpcyBmaW5lIGFzIGFscmVhZHkgaW5kaWNhdGVkKSAoYW5kIEkg ZG9u4oCZdCBmdWxseSBhZ3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50IHRoYXQg4oCcdGhlIHBvaW50 IG9mIG1pbi9tYXggaXMgcHJvbW90aW5nIHNhbmUgdmFsdWVz4oCdIGFzIHRoZSBtb2RlbCB5b3Ug YXJlIGRlc2NyaWJpbmcgaXMgIOKAnGVuZm9yY2luZ+KAnSBhIHJhbmdlIHJhdGhlciB0aGFuIGEg ZGVmYXVsdCB2YWx1ZSBpbiBicm93c2VyL3JlY29tbWVuZGF0aW9uIGluIHRoZSBzcGVjaWZpY2F0 aW9uKS4NCg0KDQpIaSBBbGwsDQoNCkp1c3QgdG8gYmUgYWJzb2x1dGVseSBjbGVhciwgdGhlcmUg YXJlIG5vIGludGVyY29ubmVjdGVkIFBTVE4gc3lzdGVtcyB3aGljaCBhY2NlcHQgRFRNRiB0b25l cyBzaG9ydGVyIHRoZW4gNDAgbXMgd2l0aCBsZXNzIHRoZW4gMzAgbXMgZ2Fwcy4gUkZDIDQ3MzMg ZG9lcyBub3QgaW1wb3NlIHRoZSBtaW5pbXVtIERUTUYgdG9uZSBkdXJhdGlvbiBsaW1pdCwgc28g Vm9JUCBvbmx5IHN5c3RlbXMgd2lsbCB0YWtlIHNob3J0ZXIgdG9uZXMuIFdlIHJvdXRpbmVseSB0 ZXN0IFNCQ3MgYW5kIHByb3ZpZGVyIGdhdGV3YXlzIG9uIGhvdyB0aGV5IGhhbmRsZSBleHRyZW1l bHkgc2hvcnQgRFRNRiB0b25lcy4gUXVpdGUgYSBmZXcgb2YgdGhlbSBicmVhaywgc2luY2UgdG9u ZXMgYW5kIGdhcHMgbmVlZCB0byBiZSBleHRlbmRlZCB0byBnZW5lcmF0ZSB2YWxpZCBQQ01VL1BD TUEgYXVkaW8uDQoNClJGQyAyODMzIGhhZCBhIG1heGltdW0gRFRNRiB0b25lIGR1cmF0aW9uIG9m IDgxOTEgbXMgYWZ0ZXIgd2hpY2ggdGhlIHRvbmUgZHVyYXRpb24gY291bnRlciBvdmVyZmxvd2Vk ICh1bnNpZ25lZCBzaG9ydCBpbnQgdXNlZCB0byBtZWFzdXJlIGR1cmF0aW9uIGluIFJUUCB1bml0 cyB3aXRoIDggS0h6IGNsb2NrKS4gSSBhbSBub3QgYXdhcmUgb2YgYW55b25lIHdobyBydW4gaW50 byB0aGlzIGxpbWl0IGZvciBhbnkgcHJhY3RpY2FsIGFwcGxpY2F0aW9uLg0KDQpTbywgYXMgZmFy IGFzIEkgY2FuIHNlZSB3ZSBoYXZlIHR3byBvcHRpb25zIGZvciBtaW4gZHVyYXRpb246DQoNCmEu IFNldCB0aGUgbWluIHRvbmUgZHVyYXRpb24gbGltaXQgdG8gNDAgbXMgYW5kIG1pbiBnYXAgbGlt aXQgdG8gMzAgbXMuIFRoZXNlIGFyZSBtaW5pbXVtIHZhbHVlcyBhY2NlcHRlZCBieSBuYXRpb25h bCBwaG9uZSBuZXR3b3JrcyBhY2NvcmRpbmcgdG8gSVRVDQpiLiBTZXQgdGhlIG1pbiB0b25lIGR1 cmF0aW9uIGFuZCBtaW4gZ2FwIHRvIDAuIFRoZXNlIGFyZSB0aGUgbWluaW11bSB2YWx1ZXMgcG9z c2libGUgd2l0aCBSRkMgNDczMw0KDQpJIHdvdWxkIHByZWZlciBvcHRpb24gYiBoZXJlLCBidXQg dGhpcyBpcyBtb3N0bHkgZm9yIHRlc3RpbmcuIEkgd291bGQgdW5kZXJzdGFuZCBpZiBubyBvbmUg ZWxzZSB3b3VsZCB3YW50IHRoaXMgYW5kIGdvIHdpdGggUFNUTiBiYXNlZCBsaW1pdHMgKG9wdGlv biBhKS4NCg0KQW5kIHdlIGhhdmUgdHdvIG9wdGlvbnMgZm9yIG1heCBkdXJhdGlvbjoNCg0KYS4g U2V0IG1heCB0b25lIGR1cmF0aW9uIHRvIDgwMDAgbXMgKEkgd291bGQgaW5jcmVhc2UgaXQgZnJv bSA2MDAwbXMgdG8gYXQgbGVhc3QgaGF2ZSBzb21lIHJlYXNvbiBmb3IgaXQpLg0KYi4gTWFrZSBt YXggdG9uZSBkdXJhdGlvbiB1bmxpbWl0ZWQuDQoNCkkgd291bGQgZ28gd2l0aCBvcHRpb24gYS4g Tm8gb25lIG5lZWRzIHRvbmVzIGxvbmdlciB0aGVuIDggcyBldmVuIGZvciB0ZXN0aW5nLg0KDQpJ IGFzc3VtZSBubyBvbmUgaXMgYWdhaW5zdCB0aGUgZGVmYXVsdCB2YWx1ZXMgb2YgMTAwIG1zIHRv bmUgYW5kIDcwIG1zIGdhcC4gSSBiZWxpZXZlIHRoZXNlIHZhbHVlcyB0byBiZSBzYWZlIGFuZCBy ZWFzb25hYmxlLg0KRnJvbSBpbnRlcm9wIGV4cGVyaWVuY2UgSSB3b3VsZCBhbHNvIGVuZm9yY2Ug c3RhcnRpbmcgYW5kIGVuZGluZyB0aGUgdG9uZSBvbiB0aGUgbm9uIHRvbmUgcGFja2V0IGJvdW5k YXJ5LCBidXQgdGhpcyBjYW4gYmUgYW4gaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuDQoNClRoaXMg d2FzIGFsbCBkaXNjdXNzZWQgdG8gZGVhdGggaW4gdGhlIHdlYnJ0YyBncm91cC4gVW5mb3J0dW5h dGVseSBpdCB3YXMgdGhlIHdyb25nIGdyb3VwIHRvIGRpc2N1c3MgdGhpcyB0b3BpYy4NCg0KUmVn YXJkcywNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg0KDQo= --_000_SN1PR0301MB15518F98FD31A3BAE6505079B2BB0SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPmktIEkgdGhvdWdodCBJIGFuc3dlcmVkIHRoYXQgYXNwZWN0IGJ1dCBoZXJlIGl0IGdvZXMg YWdhaW4gd2l0aCBhbiBleGFtcGxlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+QXBwIERldmVsb3Blciwgd2hvIGtub3dzIHdoYXQgaGUgaXMgZG9pbmc6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkFQSSBjYWxsOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNlbmRfRFRNRl9EaWdp dCjigJw14oCdLCBkdXJhdGlvbj0yMDAwbXMsIGludGVydmFsPTYwbXMpPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkJyb3dzZXIgdXNlcyB0aGUgdmFsdWVzIHN1cHBsaWVkIGluIHRoZSBBUEkgY2FsbC4gSXQg ZG9lcyBub3QgZW5mb3JjZSBhbnkgY2hlY2tzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BcHAuIERldmVs b3BlciBtYXkgdXNlIGRpZmZlcmVudCB2YWx1ZXMgYmFzZWQgb24gdGhlIG5lZ290aWF0ZWQgY29k ZWMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BcHAgRGV2ZWxv cGVyLCB3aG8gaXMgbm90IHNhdnZ5IGFib3V0IERUTUYgZGlnaXRzOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5BUEkgY2FsbDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2VuZF9EVE1GX0RpZ2l0KOKAnDXigJ0pPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkJyb3dzZXIgdXNlcyBpdHMgZGVmYXVsdCB2YWx1ZXMgZm9yIGR1cmF0 aW9uIGFuZCBpbnRlcnZhbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QnJvd3NlciBkZWZhdWx0IHZhbHVl cyBtYXkgYmUgZGlmZmVyZW50IGJhc2VkIG9uIHRoZSBuZWdvdGlhdGVkIGNvZGVjLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5EaWZmZXJlbnQgYnJvd3NlcnMgbWF5IHVzZSBkaWZmZXJlbnQgZGVmYXVsdCB2 YWx1ZXMgYnV0IHRoaXMgZG9lcyBub3QgY2F1c2UgYW55IHByb2JsZW0gZnJvbSBBcHAuIERldi4g cGVyc3BlY3RpdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5P dmVyYWxsLCBicm93c2VyIG5ldmVyIGVuZm9yY2VzIGEgcmFuZ2UuIElUIGVpdGhlciB1c2VzIHdo YXQgaGFzIGJlZW4gc3VwcGxpZWQgYnkgdGhlIEFQSSBjYWxsIGRpcmVjdGx5IG9yIGl0cyBkZWZh dWx0IHZhbHVlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmlp LSBJIHRoaW5rIGFueSBlbmZvcmNlZCByYW5nZSBpcyBhbHdheXMgZ3Vlc3N3b3JrIGFuZCB3ZSBt YXkgYmUgbGltaXRpbmcgc29tZSB1c2UgY2FzZXMgKHBlb3BsZSBjYW4gYmUgaW1hZ2luYXRpdmUg Oy0pICkuIEVzcGVjaWFsbHkgYSBtaW4gb2YgNDBtcyBpcyB0b28gaGlnaA0KIElNSE8uIEJ1dCBh cyBzYWlkLCBJIGRvbuKAmXQgc2VlIGEgcmVhc29uIGZvciB0aGUgYnJvd3NlciBlbmZvcmNpbmcg YSByYW5nZSBhbnlob3cuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VG9sZ2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBUZWQgSGFyZGll IFttYWlsdG86dGVkLmlldGZAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwg RmVicnVhcnkgMjksIDIwMTYgMzo1MyBQTTxicj4NCjxiPlRvOjwvYj4gQXN2ZXJlbiwgVG9sZ2Eg Jmx0O3Rhc3ZlcmVuQHNvbnVzbmV0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFJvbWFuIFNocG91 bnQgJmx0O3JvbWFuQHRlbHVyaXguY29tJmd0OzsgSGFyYWxkIEFsdmVzdHJhbmQgJmx0O2hhcmFs ZEBhbHZlc3RyYW5kLm5vJmd0OzsgcnRjd2ViQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbcnRjd2ViXSBGd2Q6IExhc3QgQ2FsbDogJmx0O2RyYWZ0LWlldGYtcnRjd2ViLWF1ZGlv LTEwLnR4dCZndDsgKFdlYlJUQyBBdWRpbyBDb2RlYyBhbmQgUHJvY2Vzc2luZyBSZXF1aXJlbWVu dHMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2R5LDxicj4NCk9uIE1vbiwgRmViIDI5LCAyMDE2IGF0 IDEyOjEwIFBNLCBBc3ZlcmVuLCBUb2xnYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNv bnVzbmV0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRhc3ZlcmVuQHNvbnVzbmV0LmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4tIEFwcCBkZXZlbG9wZXIga25vd3Mgd2hhdCBoZSBp cyBkb2luZzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5Zb3Ugc3RpbGwgaGF2ZSBub3QgYW5zd2VyZWQgdGhl IHF1ZXN0aW9uIG9mIGhvdyB0aGUgYXBwbGljYXRpb24gZGlzY2VybnMgd2hhdCB0aGUgYm91bmRz IGFyZSBmb3IgYSBicm93c2VyLCBpZiB0aGV5IGFyZSBub3Qgc3BlY2lmaWVkLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij5BbHNvLCBhc3N1bWluZyBlaXRoZXIgNDAvNjAwMCAob3IgZXZlbiA0MC84 MDAwLCB0byBmb2xsb3cgUm9tYW4ncyByZWNlbnQgc3VnZ2VzdGlvbikgYXJlIHVzZWQgaW4gY29u Zm9ybWFuY2Ugd2l0aCBQU1ROIHJlcXVpcmVtZW50cywgd2hhdCBpcyB0aGUgbGlrZWxpaG9vZCB0 aGF0IHRoZSBkZXZlbG9wZXIgd2hvIGtub3dzIHdoYXQgc2hlJ3MgZG9pbmcgaXMgZ29pbmcNCiB0 byBzZWxlY3Qgc29tZXRoaW5nIG91dHNpZGUgdGhhdCByYW5nZT88bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+cmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGFua3Ms PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPlRvbGdhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndo aXRlIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPg0KPGhyIHNpemU9IjIiIHdpZHRoPSI5OCUiIGFsaWduPSJjZW50 ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiBSb21hbiBTaHBvdW50ICZsdDs8 YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5jb20iIHRhcmdldD0iX2JsYW5rIj5yb21hbkB0 ZWx1cml4LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVhcnkgMjks IDIwMTYgMjozMCBQTTxicj4NCjxiPlRvOjwvYj4gQXN2ZXJlbiwgVG9sZ2E8YnI+DQo8Yj5DYzo8 L2I+IFRlZCBIYXJkaWU7IEhhcmFsZCBBbHZlc3RyYW5kOyA8YSBocmVmPSJtYWlsdG86cnRjd2Vi QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpydGN3ZWJAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBGd2Q6IExhc3QgQ2FsbDogJmx0O2RyYWZ0LWlldGYt cnRjd2ViLWF1ZGlvLTEwLnR4dCZndDsgKFdlYlJUQyBBdWRpbyBDb2RlYyBhbmQgUHJvY2Vzc2lu ZyBSZXF1aXJlbWVudHMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5PbiBNb24sIEZlYiAyOSwgMjAxNiBhdCAxOjQyIFBNLCBBc3ZlcmVuLCBU b2xnYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnRhc3ZlcmVuQHNvbnVzbmV0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkkgYW0gbm90IHN1cmUgd2hldGhlciA0MG1zIHNob3VsZCBiZSBh YnNvbHV0ZSBtaW5pbXVtIGZvciBhbGwgY29kZWNzLiBFdmVuIGZvciA2MDAwbXMsIHdobyBhbSBJ IHRvIGFyZ3VlIHRoYXQgc29tZWJvZHkgY2Fu4oCZdCBjb21lIHVwIHdpdGggYSB1c2UgY2FzZS9h cHBsaWNhdGlvbiwgd2hpY2ggcmVxdWlyZXMgc29tZXRoaW5nDQogbG9uZ2VyLiBTbywgb3ZlcmFs bCwgZW5mb3JjaW5nIGRvZXMgbm90IHNlZW0gdG8gYmUgdGhlIHJpZ2h0IHRoaW5nIElNR08gKGRl ZmF1bHQgdmFsdWUgaXMgZmluZSBhcyBhbHJlYWR5IGluZGljYXRlZCkgKGFuZCBJIGRvbuKAmXQg ZnVsbHkgYWdyZWUgd2l0aCB5b3VyIHN0YXRlbWVudCB0aGF0IOKAnHRoZSBwb2ludCBvZiBtaW4v bWF4IGlzIHByb21vdGluZyBzYW5lIHZhbHVlc+KAnSBhcyB0aGUgbW9kZWwgeW91IGFyZSBkZXNj cmliaW5nIGlzICZuYnNwO+KAnGVuZm9yY2luZ+KAnQ0KIGEgcmFuZ2UgcmF0aGVyIHRoYW4gYSBk ZWZhdWx0IHZhbHVlIGluIGJyb3dzZXIvcmVjb21tZW5kYXRpb24gaW4gdGhlIHNwZWNpZmljYXRp b24pLiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPkhpIEFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si Pkp1c3QgdG8gYmUgYWJzb2x1dGVseSBjbGVhciwgdGhlcmUgYXJlIG5vIGludGVyY29ubmVjdGVk IFBTVE4gc3lzdGVtcyB3aGljaCBhY2NlcHQgRFRNRiB0b25lcyBzaG9ydGVyIHRoZW4gNDAgbXMg d2l0aCBsZXNzIHRoZW4gMzAgbXMgZ2Fwcy4gUkZDIDQ3MzMgZG9lcw0KIG5vdCBpbXBvc2UgdGhl IG1pbmltdW0gRFRNRiB0b25lIGR1cmF0aW9uIGxpbWl0LCBzbyBWb0lQIG9ubHkgc3lzdGVtcyB3 aWxsIHRha2Ugc2hvcnRlciB0b25lcy4gV2Ugcm91dGluZWx5IHRlc3QgU0JDcyBhbmQgcHJvdmlk ZXIgZ2F0ZXdheXMgb24gaG93IHRoZXkgaGFuZGxlIGV4dHJlbWVseSBzaG9ydCBEVE1GIHRvbmVz LiBRdWl0ZSBhIGZldyBvZiB0aGVtIGJyZWFrLCBzaW5jZSB0b25lcyBhbmQgZ2FwcyBuZWVkIHRv IGJlIGV4dGVuZGVkIHRvDQogZ2VuZXJhdGUgdmFsaWQgUENNVS9QQ01BIGF1ZGlvLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+UkZDIDI4MzMgaGFkIGEgbWF4aW11bSBEVE1GIHRvbmUgZHVy YXRpb24gb2YgODE5MSBtcyBhZnRlciB3aGljaCB0aGUgdG9uZSBkdXJhdGlvbiBjb3VudGVyIG92 ZXJmbG93ZWQgKHVuc2lnbmVkIHNob3J0IGludCB1c2VkIHRvIG1lYXN1cmUgZHVyYXRpb24gaW4g UlRQDQogdW5pdHMgd2l0aCA4IEtIeiBjbG9jaykuIEkgYW0gbm90IGF3YXJlIG9mIGFueW9uZSB3 aG8gcnVuIGludG8gdGhpcyBsaW1pdCBmb3IgYW55IHByYWN0aWNhbCBhcHBsaWNhdGlvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlNvLCBhcyBmYXIgYXMgSSBjYW4gc2VlIHdlIGhhdmUg dHdvIG9wdGlvbnMgZm9yIG1pbiBkdXJhdGlvbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PmEuIFNldCB0aGUgbWluIHRvbmUgZHVyYXRpb24gbGltaXQgdG8gNDAgbXMgYW5kIG1pbiBnYXAg bGltaXQgdG8gMzAgbXMuIFRoZXNlIGFyZSBtaW5pbXVtIHZhbHVlcyBhY2NlcHRlZCBieSBuYXRp b25hbCBwaG9uZSBuZXR3b3JrcyBhY2NvcmRpbmcgdG8gSVRVPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPmIuIFNldCB0aGUgbWluIHRvbmUgZHVyYXRpb24gYW5kIG1pbiBn YXAgdG8gMC4gVGhlc2UgYXJlIHRoZSBtaW5pbXVtIHZhbHVlcyBwb3NzaWJsZSB3aXRoIFJGQyA0 NzMzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JIHdvdWxkIHByZWZlciBvcHRpb24gYiBo ZXJlLCBidXQgdGhpcyBpcyBtb3N0bHkgZm9yIHRlc3RpbmcuIEkgd291bGQgdW5kZXJzdGFuZCBp ZiBubyBvbmUgZWxzZSB3b3VsZCB3YW50IHRoaXMgYW5kIGdvIHdpdGggUFNUTiBiYXNlZCBsaW1p dHMgKG9wdGlvbiBhKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkFuZCB3ZSBoYXZlIHR3 byBvcHRpb25zIGZvciBtYXggZHVyYXRpb246PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5h LiBTZXQgbWF4IHRvbmUgZHVyYXRpb24gdG8gODAwMCBtcyAoSSB3b3VsZCBpbmNyZWFzZSBpdCBm cm9tIDYwMDBtcyB0byBhdCBsZWFzdCBoYXZlIHNvbWUgcmVhc29uIGZvciBpdCkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmIuIE1ha2UgbWF4IHRvbmUgZHVyYXRpb24g dW5saW1pdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSB3b3VsZCBnbyB3aXRoIG9w dGlvbiBhLiBObyBvbmUgbmVlZHMgdG9uZXMgbG9uZ2VyIHRoZW4gOCBzIGV2ZW4gZm9yIHRlc3Rp bmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JIGFzc3VtZSBubyBvbmUgaXMgYWdhaW5z dCB0aGUgZGVmYXVsdCB2YWx1ZXMgb2YgMTAwIG1zIHRvbmUgYW5kIDcwIG1zIGdhcC4gSSBiZWxp ZXZlIHRoZXNlIHZhbHVlcyB0byBiZSBzYWZlIGFuZCByZWFzb25hYmxlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Gcm9tIGludGVyb3AgZXhwZXJpZW5jZSBJIHdvdWxk IGFsc28gZW5mb3JjZSBzdGFydGluZyBhbmQgZW5kaW5nIHRoZSB0b25lIG9uIHRoZSBub24gdG9u ZSBwYWNrZXQgYm91bmRhcnksIGJ1dCB0aGlzIGNhbiBiZSBhbiBpbXBsZW1lbnRhdGlvbiBzcGVj aWZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoaXMgd2FzIGFsbCBkaXNjdXNzZWQg dG8gZGVhdGggaW4gdGhlIHdlYnJ0YyBncm91cC4gVW5mb3J0dW5hdGVseSBpdCB3YXMgdGhlIHdy b25nIGdyb3VwIHRvIGRpc2N1c3MgdGhpcyB0b3BpYy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5fX19fX19fX19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN1PR0301MB15518F98FD31A3BAE6505079B2BB0SN1PR0301MB1551_-- From nobody Tue Mar 1 01:25:05 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0511B3696 for ; Tue, 1 Mar 2016 01:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 7_f49nCZOeRP for ; Tue, 1 Mar 2016 01:25:01 -0800 (PST) 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 BBC341B36A1 for ; Tue, 1 Mar 2016 01:25:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id DA25E7C7883; Tue, 1 Mar 2016 10:24:59 +0100 (CET) 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 miY2iYqTx83y; Tue, 1 Mar 2016 10:24:59 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:4811:707a:323e:7958] (unknown [IPv6:2001:470:de0a:1:4811:707a:323e:7958]) by mork.alvestrand.no (Postfix) with ESMTPSA id D1D9F7C7882; Tue, 1 Mar 2016 10:24:58 +0100 (CET) To: "Asveren, Tolga" , Ted Hardie References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D1A080.7050901@alvestrand.no> From: Harald Alvestrand Message-ID: <56D55FE9.60408@alvestrand.no> Date: Tue, 1 Mar 2016 10:24:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 09:25:04 -0000 Den 01. mars 2016 09:04, skrev Asveren, Tolga: > i- I thought I answered that aspect but here it goes again with an example: > > > > App Developer, who knows what he is doing: > > API call: > > Send_DTMF_Digit(“5”, duration=2000ms, interval=60ms) > > Browser uses the values supplied in the API call. It does not enforce > any checks. > > App. Developer may use different values based on the negotiated codec. > > > > App Developer, who is not savvy about DTMF digits: > > API call: > > Send_DTMF_Digit(“5”) > > Browser uses its default values for duration and interval. > > Browser default values may be different based on the negotiated codec. > > Different browsers may use different default values but this does not > cause any problem from App. Dev. perspective. > The other way to look at it: App developer who doesn't know what he's doing: Send_Dtmf_Digit("5", duration=10) Runs on Chrome. It works on his test system. Deploys to a thousand users. Someone runs it on Firefox. "Illegal value". Files a bug against Firefox. Wastes a lot of people's time. In the meantime, the Chrome users discover that the DTMF-sending app only works part of the time, and files bugs against Chrome for not sending reliable DTMF. Lots of time wasted for all. People's distrust of DTMF ever working reliably goes up. What's the benefit of NOT having a hard limit? From nobody Tue Mar 1 02:17:58 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312941B3E80 for ; Tue, 1 Mar 2016 02:17:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 PHEUPQ_7A0YP for ; Tue, 1 Mar 2016 02:17:54 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0065.outbound.protection.outlook.com [65.55.169.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DB291B3EAF for ; Tue, 1 Mar 2016 02:17:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ectUl96KpI0p2ev+2aTKdOYfW7nhSpx5eT2MxekQwu4=; b=bogRnasFZGBTnwsvZVnaJDGu+2dSzAuOUNvuIhrrBeMvsLj60diiOPMe+eRd62FC72pRI+hBFnN5tB9QF0GLIiwlp6OzzMV5R81hHBhqWJQpMGY0NMV1mJ3+M2ALUZb8VJQo92oFXJeAzIpLgSjyW6sYqJ9n5NE1JMneuMvP4h4= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1550.namprd03.prod.outlook.com (10.162.129.156) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 1 Mar 2016 10:17:43 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Tue, 1 Mar 2016 10:17:43 +0000 From: "Asveren, Tolga" To: Harald Alvestrand , Ted Hardie Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p89KcurgAAU0gCAALLLgIAAOucggAC01ICAANVAYIAAKmkAgAA3mfCAAzMegIAAEaGAgAAC3oCAAAAVkIAAD2GAgAAJS/qAAA2lgIAAuVMQgAAYxoCAAA0u0A== Date: Tue, 1 Mar 2016 10:17:43 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D1A080.7050901@alvestrand.no> <56D55FE9.60408@alvestrand.no> In-Reply-To: <56D55FE9.60408@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alvestrand.no; dkim=none (message not signed) header.d=none; alvestrand.no; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: cc9d4365-14e5-4ae0-80df-08d341baba56 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1550; 5:KRxuxcHDIYn9oQ5O4y6BOd6EWNIeSsybykpm8GEfPgD4LTLItq10QeuYoKlKL6NaYDYNE9Gp2TOCf7wMwqMbfCMwm8HO1ODHcA82CwA2recItCU+cNqbi5M47CXWaO5VlOcjGN+Pu8i0XLfTayj96w==; 24:lOi34aFeiRVSVB9GAoXsp6DpoH2JZ4FvdvexKt5AcCB2zScqUSvSDbzQ6hxqCjn2Wqfsj2ZW1BwUtr4GoFHXNxUE+RuIky+i8/CMZfgaBII= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1550; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:SN1PR0301MB1550; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1550; x-forefront-prvs: 086831DFB4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(164054003)(55674003)(13464003)(2473001)(377454003)(87936001)(102836003)(3846002)(1096002)(76176999)(11100500001)(54356999)(189998001)(50986999)(106116001)(66066001)(76576001)(5002640100001)(93886004)(5001960100003)(2950100001)(2906002)(5004730100002)(1220700001)(99286002)(81156008)(74316001)(3660700001)(6116002)(3280700002)(2900100001)(5001770100001)(77096005)(92566002)(122556002)(10400500002)(5003600100002)(586003)(33656002)(4326007)(86362001)(230783001)(5008740100001)(19580405001)(19580395003)(40100003); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1550; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2016 10:17:43.3450 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1550 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 10:17:56 -0000 V2VsbCwgaW4geW91ciBjYXNlLCBpdCBpcyBvYnZpb3VzbHkgYXBwLiBkZXZlbG9wZXJzIGZhdWx0 IHRvIHN1cHBseSBkdXJhdGlvbi9pbnRlcnZhbCB3aXRob3V0IGtub3dpbmcgd2hhdCB0aGV5IG1l YW4vd2hhdCBoZSBpcyBkb2luZyAoYXNzdW1pbmcgdGhvc2UgdmFsdWVzIGFyZSBicmVha2luZyBz b21ldGhpbmcgZm9yIHdoYXRldmVyIHJlYXNvbiBmb3IgdGhhdCBwYXJ0aWN1bGFyIGRlcGxveW1l bnQpLiBUaGlzIHdvdWxkIGJlIGEgYnVnIG9uIHRoZSBhcHBsaWNhdGlvbi91bmludGVsbGlnZW50 IGJlaGF2aW9yIGJ5IHRoZSBhcHAuIGRldmVsb3Blci4gSSBhbSBmb3IgY29udmVuaWVuY2UgYW5k IGFjY29tbW9kYXRpbmcgcGVvcGxlIHdobyBhcmUgbm90IHNhdnZ5IGFib3V0IERNVEYgYXNwZWN0 cyBidXQgZW5mb3JjaW5nIGxpbWl0cyB0byBndWFyZCBhZ2FpbnN0IHN0dXBpZGl0eSB3b3VsZCBz YWNyaWZpY2UgZmxleGliaWxpdHksIHdoaWNoIElNSE8gaXMgYW5vdGhlciBpbXBvcnRhbnQgYXNw ZWN0LiBBbmQgZW5mb3JjaW5nIG1pbi9tYXggd291bGQgZG8gZXhhY3RseSB0aGF0LCBsaW1pdGlu ZyBmbGV4aWJpbGl0eS4NCg0KVGhhbmtzLA0KVG9sZ2EgDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogSGFyYWxkIEFsdmVzdHJhbmQgW21haWx0bzpoYXJhbGRAYWx2ZXN0 cmFuZC5ub10NCj4gU2VudDogVHVlc2RheSwgTWFyY2ggMDEsIDIwMTYgNDoyNSBBTQ0KPiBUbzog QXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbT47IFRlZCBIYXJkaWUNCj4gPHRl ZC5pZXRmQGdtYWlsLmNvbT4NCj4gQ2M6IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29t PjsgcnRjd2ViQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBGd2Q6IExhc3QgQ2Fs bDogPGRyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvLTEwLnR4dD4NCj4gKFdlYlJUQyBBdWRpbyBDb2Rl YyBhbmQgUHJvY2Vzc2luZyBSZXF1aXJlbWVudHMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+IA0K PiBEZW4gMDEuIG1hcnMgMjAxNiAwOTowNCwgc2tyZXYgQXN2ZXJlbiwgVG9sZ2E6DQo+ID4gaS0g SSB0aG91Z2h0IEkgYW5zd2VyZWQgdGhhdCBhc3BlY3QgYnV0IGhlcmUgaXQgZ29lcyBhZ2FpbiB3 aXRoIGFuIGV4YW1wbGU6DQo+ID4NCj4gPg0KPiA+DQo+ID4gQXBwIERldmVsb3Blciwgd2hvIGtu b3dzIHdoYXQgaGUgaXMgZG9pbmc6DQo+ID4NCj4gPiBBUEkgY2FsbDoNCj4gPg0KPiA+IFNlbmRf RFRNRl9EaWdpdCjigJw14oCdLCBkdXJhdGlvbj0yMDAwbXMsIGludGVydmFsPTYwbXMpDQo+ID4N Cj4gPiBCcm93c2VyIHVzZXMgdGhlIHZhbHVlcyBzdXBwbGllZCBpbiB0aGUgQVBJIGNhbGwuIEl0 IGRvZXMgbm90IGVuZm9yY2UNCj4gPiBhbnkgY2hlY2tzLg0KPiA+DQo+ID4gQXBwLiBEZXZlbG9w ZXIgbWF5IHVzZSBkaWZmZXJlbnQgdmFsdWVzIGJhc2VkIG9uIHRoZSBuZWdvdGlhdGVkIGNvZGVj Lg0KPiA+DQo+ID4NCj4gPg0KPiA+IEFwcCBEZXZlbG9wZXIsIHdobyBpcyBub3Qgc2F2dnkgYWJv dXQgRFRNRiBkaWdpdHM6DQo+ID4NCj4gPiBBUEkgY2FsbDoNCj4gPg0KPiA+IFNlbmRfRFRNRl9E aWdpdCjigJw14oCdKQ0KPiA+DQo+ID4gQnJvd3NlciB1c2VzIGl0cyBkZWZhdWx0IHZhbHVlcyBm b3IgZHVyYXRpb24gYW5kIGludGVydmFsLg0KPiA+DQo+ID4gQnJvd3NlciBkZWZhdWx0IHZhbHVl cyBtYXkgYmUgZGlmZmVyZW50IGJhc2VkIG9uIHRoZSBuZWdvdGlhdGVkIGNvZGVjLg0KPiA+DQo+ ID4gRGlmZmVyZW50IGJyb3dzZXJzIG1heSB1c2UgZGlmZmVyZW50IGRlZmF1bHQgdmFsdWVzIGJ1 dCB0aGlzIGRvZXMgbm90DQo+ID4gY2F1c2UgYW55IHByb2JsZW0gZnJvbSBBcHAuIERldi4gcGVy c3BlY3RpdmUuDQo+ID4NCj4gDQo+IFRoZSBvdGhlciB3YXkgdG8gbG9vayBhdCBpdDoNCj4gDQo+ IEFwcCBkZXZlbG9wZXIgd2hvIGRvZXNuJ3Qga25vdyB3aGF0IGhlJ3MgZG9pbmc6DQo+IA0KPiBT ZW5kX0R0bWZfRGlnaXQoIjUiLCBkdXJhdGlvbj0xMCkNCj4gDQo+IFJ1bnMgb24gQ2hyb21lLiBJ dCB3b3JrcyBvbiBoaXMgdGVzdCBzeXN0ZW0uIERlcGxveXMgdG8gYSB0aG91c2FuZCB1c2Vycy4N Cj4gDQo+IFNvbWVvbmUgcnVucyBpdCBvbiBGaXJlZm94Lg0KPiANCj4gIklsbGVnYWwgdmFsdWUi Lg0KPiANCj4gRmlsZXMgYSBidWcgYWdhaW5zdCBGaXJlZm94LiBXYXN0ZXMgYSBsb3Qgb2YgcGVv cGxlJ3MgdGltZS4NCj4gSW4gdGhlIG1lYW50aW1lLCB0aGUgQ2hyb21lIHVzZXJzIGRpc2NvdmVy IHRoYXQgdGhlIERUTUYtc2VuZGluZyBhcHANCj4gb25seSB3b3JrcyBwYXJ0IG9mIHRoZSB0aW1l LCBhbmQgZmlsZXMgYnVncyBhZ2FpbnN0IENocm9tZSBmb3Igbm90IHNlbmRpbmcNCj4gcmVsaWFi bGUgRFRNRi4NCj4gDQo+IExvdHMgb2YgdGltZSB3YXN0ZWQgZm9yIGFsbC4gUGVvcGxlJ3MgZGlz dHJ1c3Qgb2YgRFRNRiBldmVyIHdvcmtpbmcgcmVsaWFibHkNCj4gZ29lcyB1cC4NCj4gDQo+IFdo YXQncyB0aGUgYmVuZWZpdCBvZiBOT1QgaGF2aW5nIGEgaGFyZCBsaW1pdD8NCg== From nobody Tue Mar 1 03:17:38 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BFD1A037E for ; Tue, 1 Mar 2016 03:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 yXePITOqEbtH for ; Tue, 1 Mar 2016 03:17:35 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC5B51A039C for ; Tue, 1 Mar 2016 03:17:34 -0800 (PST) X-AuditID: c1b4fb2d-f79836d000006396-76-56d57a4cf0bc Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 70.0B.25494.C4A75D65; Tue, 1 Mar 2016 12:17:33 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0248.002; Tue, 1 Mar 2016 12:17:32 +0100 From: =?Windows-1252?Q?Stefan_H=E5kansson_LK?= To: "Asveren, Tolga" , Harald Alvestrand , Ted Hardie Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/efeEnpNaWjrEeaxVOONL18hQ== Date: Tue, 1 Mar 2016 11:17:32 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D1A080.7050901@alvestrand.no> <56D55FE9.60408@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2J7uK5v1dUwg7V32S2O9XWxWaz9185u MbvzPZNF41w7BxaPKxOusHrsnHWX3WPJkp9MHpc+/2cPYInisklJzcksSy3St0vgylh96Dpb wVGpip8tT9gbGLvFuhg5OSQETCSWLLnGAmGLSVy4t54NxBYSOMwocXmVexcjF5C9iFHi7pyT rF2MHBxsAsESTX/dQGpEBCol3v6fwwxiMwuoS9xZfI4dpF5YoI9RYsLvq6wgjohAP6PEgjNN zBAdehItt2cygdgsAioSX1f3g8V5BXwl1u2+zAqx7TiHxNt9r8CKGIFO+n5qDRPECnGJW0/m M0GcKiCxZM95ZghbVOLl43+sELaixM6z7VAnGUi8PzcfytaWWLbwNdQyQYmTM5+wTGAUnYVk 7CwkLbOQtMxC0rKAkWUVo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmBEHdzyW3cH4+rXjocY BTgYlXh4C85eCRNiTSwrrsw9xCjBwawkwnu89GqYEG9KYmVValF+fFFpTmrxIUZpDhYlcV62 T5fDhATSE0tSs1NTC1KLYLJMHJxSDYyL5V38zIoWXSh5e/2M0NwEWSMVhY1PInzWnWvYds7Q 981Rr/PPtzMtNODvey164nqkV8mh0mlWsq+jL8fMWdVkyt/7cdEkvnyF62tCehwtrA6aiDx7 NpPH3msP/745ijodZ06fkzc4KDUx9/HZi8IzJyuyKb/7qVTsevDFHZfGf8k9T5b1CD5TYinO SDTUYi4qTgQA0v8YfaQCAAA= Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 11:17:37 -0000 On 01/03/16 11:18, Asveren, Tolga wrote:=0A= > Well, in your case, it is obviously app. developers fault to supply=0A= > duration/interval without knowing what they mean/what he is doing=0A= > (assuming those values are breaking something for whatever reason for=0A= > that particular deployment). This would be a bug on the=0A= > application/unintelligent behavior by the app. developer. I am for=0A= > convenience and accommodating people who are not savvy about DMTF=0A= > aspects but enforcing limits to guard against stupidity would=0A= > sacrifice flexibility, which IMHO is another important aspect. And=0A= > enforcing min/max would do exactly that, limiting flexibility.=0A= =0A= I don't think increasing flexibility is a good reason per se. If that =0A= was the guiding principle all browser APIs would be on a very low level.=0A= =0A= Is there a use case that can't be supported with the current spec?=0A= =0A= Stefan=0A= =0A= >=0A= > Thanks, Tolga=0A= >=0A= >> -----Original Message----- From: Harald Alvestrand=0A= >> [mailto:harald@alvestrand.no] Sent: Tuesday, March 01, 2016 4:25=0A= >> AM To: Asveren, Tolga ; Ted Hardie=0A= >> Cc: Roman Shpount ;=0A= >> rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: Last Call:=0A= >> (WebRTC Audio Codec and Processing=0A= >> Requirements) to Proposed Standard=0A= >>=0A= >> Den 01. mars 2016 09:04, skrev Asveren, Tolga:=0A= >>> i- I thought I answered that aspect but here it goes again with=0A= >>> an example:=0A= >>>=0A= >>>=0A= >>>=0A= >>> App Developer, who knows what he is doing:=0A= >>>=0A= >>> API call:=0A= >>>=0A= >>> Send_DTMF_Digit(=935=94, duration=3D2000ms, interval=3D60ms)=0A= >>>=0A= >>> Browser uses the values supplied in the API call. It does not=0A= >>> enforce any checks.=0A= >>>=0A= >>> App. Developer may use different values based on the negotiated=0A= >>> codec.=0A= >>>=0A= >>>=0A= >>>=0A= >>> App Developer, who is not savvy about DTMF digits:=0A= >>>=0A= >>> API call:=0A= >>>=0A= >>> Send_DTMF_Digit(=935=94)=0A= >>>=0A= >>> Browser uses its default values for duration and interval.=0A= >>>=0A= >>> Browser default values may be different based on the negotiated=0A= >>> codec.=0A= >>>=0A= >>> Different browsers may use different default values but this does=0A= >>> not cause any problem from App. Dev. perspective.=0A= >>>=0A= >>=0A= >> The other way to look at it:=0A= >>=0A= >> App developer who doesn't know what he's doing:=0A= >>=0A= >> Send_Dtmf_Digit("5", duration=3D10)=0A= >>=0A= >> Runs on Chrome. It works on his test system. Deploys to a thousand=0A= >> users.=0A= >>=0A= >> Someone runs it on Firefox.=0A= >>=0A= >> "Illegal value".=0A= >>=0A= >> Files a bug against Firefox. Wastes a lot of people's time. In the=0A= >> meantime, the Chrome users discover that the DTMF-sending app only=0A= >> works part of the time, and files bugs against Chrome for not=0A= >> sending reliable DTMF.=0A= >>=0A= >> Lots of time wasted for all. People's distrust of DTMF ever working=0A= >> reliably goes up.=0A= >>=0A= >> What's the benefit of NOT having a hard limit?=0A= > _______________________________________________ rtcweb mailing list=0A= > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb=0A= >=0A= =0A= From nobody Tue Mar 1 03:28:15 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57761A1A52 for ; Tue, 1 Mar 2016 03:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001] autolearn=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 meagnRJi6RIl for ; Tue, 1 Mar 2016 03:28:13 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0695.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:695]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF211A1A4C for ; Tue, 1 Mar 2016 03:28:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=r+JfEqBIq9l4vpm9zBmFnHB8iFsXVSlF5nL2/KVuJnM=; b=UWIxz0d07f45m51h1Q0qz12WyZ1R95XxWc7OtEoZOBQRn1aARcg0rgdffYRWtm1qnbyx+s9IBXWZ/9XzSRXrzSjgiskIwa+GNx81CgmGo/UPbcYWJWUjD1Vss/85tTY7hUT4iFtJFe5wl/C1B9eNMBSXzxyDs9Oqn+oWsPXiF/4= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1552.namprd03.prod.outlook.com (10.162.129.158) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 1 Mar 2016 11:27:50 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Tue, 1 Mar 2016 11:27:50 +0000 From: "Asveren, Tolga" To: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= , Harald Alvestrand , Ted Hardie Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p9EeOUQ Date: Tue, 1 Mar 2016 11:27:50 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D1A080.7050901@alvestrand.no> <56D55FE9.60408@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> In-Reply-To: <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: c1d3deb8-c0f1-4426-76b0-08d341c485c7 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1552; 5:33tvg1pPMLxpOLKrnB0J/WkjUFsPRFX6Fs3cORcvfYQ40hI/OIjSfNCvfOTJjmI1cBQepkqcWW4biRzlkpbAgYVLtVxHkSMPPUIy7zxMMHWougJkB1BFiGkYI/wXMikViV6CItXIzwqZLYBvmKo7/Q==; 24:81zzSd9/ZHBF6jBxRYc+Dc7NZJECfp4do3D8LZkyaTLoiiJMI3j6xH+i9kmixipiyLYoh0E6rJVXQE/bohMfWyngk+pNxy3SEPqfdSvtnnc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1552; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR0301MB1552; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1552; x-forefront-prvs: 086831DFB4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(2473001)(377454003)(13464003)(24454002)(164054003)(479174004)(76176999)(92566002)(6116002)(15975445007)(3280700002)(19580395003)(19580405001)(5001960100003)(5001770100001)(1096002)(77096005)(4326007)(1220700001)(74316001)(33656002)(54356999)(11100500001)(2906002)(5004730100002)(3846002)(99286002)(106116001)(50986999)(102836003)(5002640100001)(10400500002)(5003600100002)(189998001)(2950100001)(40100003)(122556002)(3660700001)(5008740100001)(76576001)(93886004)(66066001)(2900100001)(586003)(86362001)(87936001)(230783001)(81156008); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1552; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2016 11:27:50.1021 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1552 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 11:28:14 -0000 There are obviously different levels of flexibility. I am not arguing for c= hanging the "level of abstraction" for the API. I just argue that enforcing= limits *in the browser* is not a good idea. When it comes to use cases setting limits based our imagination/agenda does= not seem right to me. I think the high level principle should be the oppos= ite: Do not add restrictions until absolutely necessary. One could have an = application where pushing a digit for 10seconds triggers some special servi= ce/treatment. And 40ms is definitely too low of a value, I am aware of VoIP= systems where lower values are used (but I definitely think that no enforc= ed limit is the right thing to do rather than merely decreasing min). Thanks, Tolga > -----Original Message----- > From: Stefan H=E5kansson LK [mailto:stefan.lk.hakansson@ericsson.com] > Sent: Tuesday, March 01, 2016 6:18 AM > To: Asveren, Tolga ; Harald Alvestrand > ; Ted Hardie > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Fwd: Last Call: > (WebRTC Audio Codec and Processing Requirements) to Proposed Standard >=20 > On 01/03/16 11:18, Asveren, Tolga wrote: > > Well, in your case, it is obviously app. developers fault to supply > > duration/interval without knowing what they mean/what he is doing > > (assuming those values are breaking something for whatever reason for > > that particular deployment). This would be a bug on the > > application/unintelligent behavior by the app. developer. I am for > > convenience and accommodating people who are not savvy about DMTF > > aspects but enforcing limits to guard against stupidity would > > sacrifice flexibility, which IMHO is another important aspect. And > > enforcing min/max would do exactly that, limiting flexibility. >=20 > I don't think increasing flexibility is a good reason per se. If that was= the > guiding principle all browser APIs would be on a very low level. >=20 > Is there a use case that can't be supported with the current spec? >=20 > Stefan >=20 > > > > Thanks, Tolga > > > >> -----Original Message----- From: Harald Alvestrand > >> [mailto:harald@alvestrand.no] Sent: Tuesday, March 01, 2016 4:25 AM > >> To: Asveren, Tolga ; Ted Hardie > >> Cc: Roman Shpount ; > >> rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: Last Call: > >> (WebRTC Audio Codec and Processing > >> Requirements) to Proposed Standard > >> > >> Den 01. mars 2016 09:04, skrev Asveren, Tolga: > >>> i- I thought I answered that aspect but here it goes again with an > >>> example: > >>> > >>> > >>> > >>> App Developer, who knows what he is doing: > >>> > >>> API call: > >>> > >>> Send_DTMF_Digit("5", duration=3D2000ms, interval=3D60ms) > >>> > >>> Browser uses the values supplied in the API call. It does not > >>> enforce any checks. > >>> > >>> App. Developer may use different values based on the negotiated > >>> codec. > >>> > >>> > >>> > >>> App Developer, who is not savvy about DTMF digits: > >>> > >>> API call: > >>> > >>> Send_DTMF_Digit("5") > >>> > >>> Browser uses its default values for duration and interval. > >>> > >>> Browser default values may be different based on the negotiated > >>> codec. > >>> > >>> Different browsers may use different default values but this does > >>> not cause any problem from App. Dev. perspective. > >>> > >> > >> The other way to look at it: > >> > >> App developer who doesn't know what he's doing: > >> > >> Send_Dtmf_Digit("5", duration=3D10) > >> > >> Runs on Chrome. It works on his test system. Deploys to a thousand > >> users. > >> > >> Someone runs it on Firefox. > >> > >> "Illegal value". > >> > >> Files a bug against Firefox. Wastes a lot of people's time. In the > >> meantime, the Chrome users discover that the DTMF-sending app only > >> works part of the time, and files bugs against Chrome for not sending > >> reliable DTMF. > >> > >> Lots of time wasted for all. People's distrust of DTMF ever working > >> reliably goes up. > >> > >> What's the benefit of NOT having a hard limit? > > _______________________________________________ rtcweb > mailing list > > rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > > From nobody Tue Mar 1 03:36:05 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF481A1B24 for ; Tue, 1 Mar 2016 03:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 CTrmpqNDSOzA for ; Tue, 1 Mar 2016 03:36:02 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A0A41A1A52 for ; Tue, 1 Mar 2016 03:36:02 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-80-56d57e9f3b3e Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6A.0C.15637.F9E75D65; Tue, 1 Mar 2016 12:35:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.73]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Tue, 1 Mar 2016 12:35:58 +0100 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: "Asveren, Tolga" , Harald Alvestrand , Ted Hardie Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/efeEnpNaWjrEeaxVOONL18hQ== Date: Tue, 1 Mar 2016 11:35:57 +0000 Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B374B95F3@ESESSMB209.ericsson.se> References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D1A080.7050901@alvestrand.no> <56D55FE9.60408@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7ge78uqthBl+Wylgc6+tis1j7r53d YnbneyaLxrl2DiweVyZcYfXYOesuu8eSJT+ZPC59/s8ewBLFZZOSmpNZllqkb5fAlbH69z+W gk8aFc33Z7M1MC5S6mLk5JAQMJFY/mYuO4QtJnHh3nq2LkYuDiGBw4wSvx80MEE4ixglWlYd YQOpYhMIlNi6bwGYLSJQKfH2/xxmEJtZQF3izuJz7CANwgJ9jBITfl9lBXFEBPoZJRacaWKG 6NCTaLk9kwnEZhFQkXh69hwjiM0r4Cvx4O1fVoh1jzglTkydAZZgBDrq+6k1TBArxCVuPZnP BHGsgMSSPeeZIWxRiZeP/7FC2EoSPzZcYoGo15O4MXUKG4StLbFs4WtmiGWCEidnPmGZwCg6 C8nYWUhaZiFpmYWkZQEjyypG0eLU4qTcdCNjvdSizOTi4vw8vbzUkk2MwKg6uOW36g7Gy28c DzEKcDAq8fAWnL0SJsSaWFZcmXuIUYKDWUmE17f2apgQb0piZVVqUX58UWlOavEhRmkOFiVx XtZPl8OEBNITS1KzU1MLUotgskwcnFINjEwVun6e8+1Tv5zs+Z5zeMEuH9HbT5LyFmxz8NEL YDfRauJImXNmc/KHpg3G86xkI+X87wSK/Ddxq0zyPf6hdcMyjtNPmmUjpmsy2URqHLn94fwZ ztM+5Q9evW+WP6XOIloYbGj3Km//fAPh2vtiHbwndrY7n0yvknT8lG29OJrv+IqNN61fKrEU ZyQaajEXFScCABuDiU6mAgAA Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 11:36:04 -0000 On 01/03/16 12:27, Asveren, Tolga wrote:=0A= > There are obviously different levels of flexibility. I am not arguing=0A= > for changing the "level of abstraction" for the API. I just argue=0A= > that enforcing limits *in the browser* is not a good idea.=0A= =0A= I think differently. Having limits (based on real world =0A= experience/implementations and that allow agreed use cases to be =0A= supported) makes life easier for the app developer, the browser =0A= implementer and everyone involved in testing.=0A= =0A= >=0A= > When it comes to use cases setting limits based our=0A= > imagination/agenda does not seem right to me. I think the high level=0A= > principle should be the opposite: Do not add restrictions until=0A= > absolutely necessary. One could have an application where pushing a=0A= > digit for 10seconds triggers some special service/treatment. And 40ms=0A= > is definitely too low of a value, I am aware of VoIP systems where=0A= > lower values are used (but I definitely think that no enforced limit=0A= > is the right thing to do rather than merely decreasing min).=0A= >=0A= > Thanks, Tolga=0A= >=0A= >> -----Original Message----- From: Stefan H=E5kansson LK=0A= >> [mailto:stefan.lk.hakansson@ericsson.com] Sent: Tuesday, March 01,=0A= >> 2016 6:18 AM To: Asveren, Tolga ; Harald=0A= >> Alvestrand ; Ted Hardie =0A= >> Cc: rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: Last Call:=0A= >> (WebRTC Audio Codec and Processing=0A= >> Requirements) to Proposed Standard=0A= >>=0A= >> On 01/03/16 11:18, Asveren, Tolga wrote:=0A= >>> Well, in your case, it is obviously app. developers fault to=0A= >>> supply duration/interval without knowing what they mean/what he=0A= >>> is doing (assuming those values are breaking something for=0A= >>> whatever reason for that particular deployment). This would be a=0A= >>> bug on the application/unintelligent behavior by the app.=0A= >>> developer. I am for convenience and accommodating people who are=0A= >>> not savvy about DMTF aspects but enforcing limits to guard=0A= >>> against stupidity would sacrifice flexibility, which IMHO is=0A= >>> another important aspect. And enforcing min/max would do exactly=0A= >>> that, limiting flexibility.=0A= >>=0A= >> I don't think increasing flexibility is a good reason per se. If=0A= >> that was the guiding principle all browser APIs would be on a very=0A= >> low level.=0A= >>=0A= >> Is there a use case that can't be supported with the current spec?=0A= >>=0A= >> Stefan=0A= >>=0A= >>>=0A= >>> Thanks, Tolga=0A= >>>=0A= >>>> -----Original Message----- From: Harald Alvestrand=0A= >>>> [mailto:harald@alvestrand.no] Sent: Tuesday, March 01, 2016=0A= >>>> 4:25 AM To: Asveren, Tolga ; Ted Hardie=0A= >>>> Cc: Roman Shpount ;=0A= >>>> rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: Last Call:=0A= >>>> (WebRTC Audio Codec and=0A= >>>> Processing Requirements) to Proposed Standard=0A= >>>>=0A= >>>> Den 01. mars 2016 09:04, skrev Asveren, Tolga:=0A= >>>>> i- I thought I answered that aspect but here it goes again=0A= >>>>> with an example:=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> App Developer, who knows what he is doing:=0A= >>>>>=0A= >>>>> API call:=0A= >>>>>=0A= >>>>> Send_DTMF_Digit("5", duration=3D2000ms, interval=3D60ms)=0A= >>>>>=0A= >>>>> Browser uses the values supplied in the API call. It does=0A= >>>>> not enforce any checks.=0A= >>>>>=0A= >>>>> App. Developer may use different values based on the=0A= >>>>> negotiated codec.=0A= >>>>>=0A= >>>>>=0A= >>>>>=0A= >>>>> App Developer, who is not savvy about DTMF digits:=0A= >>>>>=0A= >>>>> API call:=0A= >>>>>=0A= >>>>> Send_DTMF_Digit("5")=0A= >>>>>=0A= >>>>> Browser uses its default values for duration and interval.=0A= >>>>>=0A= >>>>> Browser default values may be different based on the=0A= >>>>> negotiated codec.=0A= >>>>>=0A= >>>>> Different browsers may use different default values but this=0A= >>>>> does not cause any problem from App. Dev. perspective.=0A= >>>>>=0A= >>>>=0A= >>>> The other way to look at it:=0A= >>>>=0A= >>>> App developer who doesn't know what he's doing:=0A= >>>>=0A= >>>> Send_Dtmf_Digit("5", duration=3D10)=0A= >>>>=0A= >>>> Runs on Chrome. It works on his test system. Deploys to a=0A= >>>> thousand users.=0A= >>>>=0A= >>>> Someone runs it on Firefox.=0A= >>>>=0A= >>>> "Illegal value".=0A= >>>>=0A= >>>> Files a bug against Firefox. Wastes a lot of people's time. In=0A= >>>> the meantime, the Chrome users discover that the DTMF-sending=0A= >>>> app only works part of the time, and files bugs against Chrome=0A= >>>> for not sending reliable DTMF.=0A= >>>>=0A= >>>> Lots of time wasted for all. People's distrust of DTMF ever=0A= >>>> working reliably goes up.=0A= >>>>=0A= >>>> What's the benefit of NOT having a hard limit?=0A= >>> _______________________________________________ rtcweb=0A= >> mailing list=0A= >>> rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb=0A= >>>=0A= >=0A= >=0A= =0A= From nobody Tue Mar 1 03:46:34 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B221A1BED for ; Tue, 1 Mar 2016 03:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 9rMSC-6xNcWi for ; Tue, 1 Mar 2016 03:46:30 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98FF71A1BEE for ; Tue, 1 Mar 2016 03:46:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 179617C7888; Tue, 1 Mar 2016 12:46:29 +0100 (CET) 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 YXqRB81md7uH; Tue, 1 Mar 2016 12:46:28 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:4811:707a:323e:7958] (unknown [IPv6:2001:470:de0a:1:4811:707a:323e:7958]) by mork.alvestrand.no (Postfix) with ESMTPSA id 295D17C7886; Tue, 1 Mar 2016 12:46:28 +0100 (CET) To: "Asveren, Tolga" , Ted Hardie References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D1A080.7050901@alvestrand.no> <56D55FE9.60408@alvestrand.no> From: Harald Alvestrand Message-ID: <56D58113.2070704@alvestrand.no> Date: Tue, 1 Mar 2016 12:46:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 11:46:32 -0000 Den 01. mars 2016 11:17, skrev Asveren, Tolga: > Well, in your case, it is obviously app. developers fault to supply duration/interval without knowing what they mean/what he is doing (assuming those values are breaking something for whatever reason for that particular deployment). This would be a bug on the application/unintelligent behavior by the app. developer. That's the part that I don't get. I pointed out how the choice *not* to have hard limits imposes cost on a lot of people - most of which are *not* the people doing the unintelligent behavior. And there's *no* mechanism for asking the app developer to pay for their wasted time. > I am for convenience and accommodating people who are not savvy about DMTF aspects but enforcing limits to guard against stupidity would sacrifice flexibility, which IMHO is another important aspect. And enforcing min/max would do exactly that, limiting flexibility. Again - is there any *realistic* use case that is impossible when a consistent min/max is enforced, and impossible when some other limits are enforced? Remember that *all* browsers *will* impose *some* limit. From nobody Tue Mar 1 09:01:22 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35681B2FB1 for ; Tue, 1 Mar 2016 09:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 Do0oZeIaU3Qg for ; Tue, 1 Mar 2016 09:01:18 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0087.outbound.protection.outlook.com [207.46.100.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9191B2F87 for ; Tue, 1 Mar 2016 09:00:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cb0jchahXRFdxiWFt6qV9RgU2eCQFhN/eyMFIzqVwi0=; b=oeJXy+UM9xjwaximQ/aEtE7eiQdSZXjTFQHKfMC9Rwjk0XyaA6EnH5eT1U83u4L2TFwjgvmrUBfyNRHIoFkGvrS3Z3oqlUf6999DEkd0bwrmFFO8TjkzekT8fd97nRS9szLf7qVXjgcim08O/WrFN4YFTxWD90YDqEhY9DeKPmA= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 1 Mar 2016 17:00:15 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Tue, 1 Mar 2016 17:00:15 +0000 From: "Asveren, Tolga" To: Harald Alvestrand , Ted Hardie Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p89KcurgAAU0gCAALLLgIAAOucggAC01ICAANVAYIAAKmkAgAA3mfCAAzMegIAAEaGAgAAC3oCAAAAVkIAAD2GAgAAJS/qAAA2lgIAAuVMQgAAYxoCAAA0u0IAAGluAgABWJSA= Date: Tue, 1 Mar 2016 17:00:14 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D1A080.7050901@alvestrand.no> <56D55FE9.60408@alvestrand.no> <56D58113.2070704@alvestrand.no> In-Reply-To: <56D58113.2070704@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alvestrand.no; dkim=none (message not signed) header.d=none; alvestrand.no; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 21717b2b-cab3-48c8-c614-08d341f2f609 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:rwJlJpZ5tWQPvdDguSbxl6PW3GUNjG5v+2QTgBLK6piGUOsHPjJ2tO9p88n77LwTBL3KjWswO8jRh6nVR/+ehjT4eLFgX6Hs6G7vbcscP1jtOBAwivoMlMlaP2SsJQTJWmHBV1PUQgM+KcSk6BlRGQ==; 24:SqEtFk2SExKuqSDQnlo2PUeUeQgCXmeURpJHsS5hzBqeVEk75Mu5Erj8p/2/p4c94SIpX5iPdN3XBMHYZ7+cnYDUf7MGDF1mVCYBFUqePno= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 086831DFB4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(164054003)(2473001)(13464003)(377454003)(106116001)(50986999)(2906002)(11100500001)(5002640100001)(5003600100002)(3846002)(87936001)(76176999)(102836003)(230783001)(5001960100004)(81156009)(76576001)(1096002)(93886004)(3660700001)(122556002)(10400500002)(92566002)(3280700002)(40100003)(6116002)(2900100001)(33656002)(4326007)(586003)(19580405001)(1220700001)(5001770100001)(5008740100001)(189998001)(54356999)(2950100001)(74316001)(19580395003)(77096005)(86362001)(99286002)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2016 17:00:15.2911 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 17:01:20 -0000 U28sIHlvdSB0aGluayB0aGF0IHdlIHNob3VsZG7igJl0IGV4cGVjdCB0aGF0IGFuIEFwcC4gRGV2 Liwgd2hvIGRvZXNu4oCZdCBrbm93IG11Y2ggYWJvdXQgRFRNRiwgY2Fu4oCZdCBjYWxsIHRoZSBy aWdodCBBUEksIHdoaWNoIHdvdWxkIHVzZSB0aGUgYnJvd3NlciBkZWZhdWx0cyhkZXNwaXRlIGV4 cGxhbmF0aW9ucyBpbiByZWxldmFudCBzcGVjaWZpY2F0aW9ucyk/IEkgcmVzcGVjdGZ1bGx5IGRp c2FncmVlLiBXaGF0IGFib3V0IHNvbWUgb3RoZXIgQXBwLiBEZXYuLCB3aG8gY2FsbHMgQVBJcyBp biBhIG5pbGx5LXdpbGx5IHdheSwgaW4gdGhlIHdyb25nIG9yZGVyLCB3aXRoIHdyb25nIHZhbHVl cy4uLiBNYXliZSB3ZSBzaG91bGQgaGF2ZSBhIHNpbmdsZSBBUEk6IE1ha2VfQ2FsbChwaG9uZSBu dW1iZXIpPyE/DQoNClRoYW5rcywNClRvbGdhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogSGFyYWxkIEFsdmVzdHJhbmQgW21haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5u b10NCj4gU2VudDogVHVlc2RheSwgTWFyY2ggMDEsIDIwMTYgNjo0NiBBTQ0KPiBUbzogQXN2ZXJl biwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbT47IFRlZCBIYXJkaWUNCj4gPHRlZC5pZXRm QGdtYWlsLmNvbT4NCj4gQ2M6IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPjsgcnRj d2ViQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBGd2Q6IExhc3QgQ2FsbDogPGRy YWZ0LWlldGYtcnRjd2ViLWF1ZGlvLTEwLnR4dD4NCj4gKFdlYlJUQyBBdWRpbyBDb2RlYyBhbmQg UHJvY2Vzc2luZyBSZXF1aXJlbWVudHMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQo+IA0KPiBEZW4g MDEuIG1hcnMgMjAxNiAxMToxNywgc2tyZXYgQXN2ZXJlbiwgVG9sZ2E6DQo+ID4gV2VsbCwgaW4g eW91ciBjYXNlLCBpdCBpcyBvYnZpb3VzbHkgYXBwLiBkZXZlbG9wZXJzIGZhdWx0IHRvIHN1cHBs eQ0KPiBkdXJhdGlvbi9pbnRlcnZhbCB3aXRob3V0IGtub3dpbmcgd2hhdCB0aGV5IG1lYW4vd2hh dCBoZSBpcyBkb2luZw0KPiAoYXNzdW1pbmcgdGhvc2UgdmFsdWVzIGFyZSBicmVha2luZyBzb21l dGhpbmcgZm9yIHdoYXRldmVyIHJlYXNvbiBmb3IgdGhhdA0KPiBwYXJ0aWN1bGFyIGRlcGxveW1l bnQpLiBUaGlzIHdvdWxkIGJlIGEgYnVnIG9uIHRoZSBhcHBsaWNhdGlvbi91bmludGVsbGlnZW50 DQo+IGJlaGF2aW9yIGJ5IHRoZSBhcHAuIGRldmVsb3Blci4NCj4gDQo+IFRoYXQncyB0aGUgcGFy dCB0aGF0IEkgZG9uJ3QgZ2V0Lg0KPiBJIHBvaW50ZWQgb3V0IGhvdyB0aGUgY2hvaWNlICpub3Qq IHRvIGhhdmUgaGFyZCBsaW1pdHMgaW1wb3NlcyBjb3N0IG9uIGEgbG90DQo+IG9mIHBlb3BsZSAt IG1vc3Qgb2Ygd2hpY2ggYXJlICpub3QqIHRoZSBwZW9wbGUgZG9pbmcgdGhlIHVuaW50ZWxsaWdl bnQNCj4gYmVoYXZpb3IuDQo+IA0KPiBBbmQgdGhlcmUncyAqbm8qIG1lY2hhbmlzbSBmb3IgYXNr aW5nIHRoZSBhcHAgZGV2ZWxvcGVyIHRvIHBheSBmb3IgdGhlaXINCj4gd2FzdGVkIHRpbWUuDQo+ IA0KPiANCj4gPiBJIGFtIGZvciBjb252ZW5pZW5jZSBhbmQgYWNjb21tb2RhdGluZyBwZW9wbGUg d2hvIGFyZSBub3Qgc2F2dnkgYWJvdXQNCj4gRE1URiBhc3BlY3RzIGJ1dCBlbmZvcmNpbmcgbGlt aXRzIHRvIGd1YXJkIGFnYWluc3Qgc3R1cGlkaXR5IHdvdWxkIHNhY3JpZmljZQ0KPiBmbGV4aWJp bGl0eSwgd2hpY2ggSU1ITyBpcyBhbm90aGVyIGltcG9ydGFudCBhc3BlY3QuIEFuZCBlbmZvcmNp bmcgbWluL21heA0KPiB3b3VsZCBkbyBleGFjdGx5IHRoYXQsIGxpbWl0aW5nIGZsZXhpYmlsaXR5 Lg0KPiANCj4gQWdhaW4gLSBpcyB0aGVyZSBhbnkgKnJlYWxpc3RpYyogdXNlIGNhc2UgdGhhdCBp cyBpbXBvc3NpYmxlIHdoZW4gYSBjb25zaXN0ZW50DQo+IG1pbi9tYXggaXMgZW5mb3JjZWQsIGFu ZCBpbXBvc3NpYmxlIHdoZW4gc29tZSBvdGhlciBsaW1pdHMgYXJlIGVuZm9yY2VkPw0KPiANCj4g UmVtZW1iZXIgdGhhdCAqYWxsKiBicm93c2VycyAqd2lsbCogaW1wb3NlICpzb21lKiBsaW1pdC4N Cg== From nobody Tue Mar 1 10:27:00 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDB21B38BE for ; Tue, 1 Mar 2016 10:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 CfrCnv-1Drdt for ; Tue, 1 Mar 2016 10:26:51 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA79D1B38BD for ; Tue, 1 Mar 2016 10:26:50 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id n190so29141388iof.0 for ; Tue, 01 Mar 2016 10:26:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=5w+KClcgjnA/GjBPIc+uQIgxT5vOK9Yt1B1lkwQyxXc=; b=r3hUnF9yswg9YfAG6Gj0JGYbrT8cm4O8SX74SGqnM57N0jxVJHHkYH5gqdtdUwJm/S ZylQ6wH/LUTmge4mPTZ3BHSrvW+IDw45u+g1QPvHb9r/7tLzp97R97LytazU34M8k12E C/GNBFMQ9j0JEhP3UbfY10WOfrl/bz8qsYKxR48BIpyK8ITzXx41MPZ2Yu0/Yxt6POoj UfPrNFWJq7KzWLs2DQzZUfyqLLRquB23FL3v9KoWERbkNAp1F//49pO80TLMG8yV5yxg ANMDjaaSz+8YuF3C1Nne+vpkZjqXsEhetJSv85l+8rKHEBWt9FKkEsH6I+RVzExkmEaM Llqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=5w+KClcgjnA/GjBPIc+uQIgxT5vOK9Yt1B1lkwQyxXc=; b=dXh0pMWc5Jmb+t/YZgcjgCAXBX+YLFTSUGcDuhB2DIfADtJD53bdLs+rWbTtrOsq6A 5Mwwr6N/log1qpogXMD1ycv66WE6Lo9vFoaAhqzK9ve1iyrudwBW6gxb22hSVM24OBX2 uLco9+GK0DwvoA7aR8NCkbDaqYoNLaPjlIzCj1WPbHqN/FhXBLWXuPlFnei9iTKryBdV wrXYMoL1xaE1BcLeHXI9WoNlCKqgJHbhLu05ZAwSl2LdyE/qHvEEbHwlciZO1zh5AGW1 TOoSTrttX0j3R51YG+D7g5t5kWbqz7iarNOqaJxImrZMcSWMZ+vuts7gPpSTEnPISV7R BtkQ== X-Gm-Message-State: AG10YORGdR6Vo6T2K2CmU2K535s0+btBQHAZoknwCypbdL2yKAY6bUhlSCgJMPMtahIW3A== X-Received: by 10.107.39.139 with SMTP id n133mr26754824ion.57.1456856810152; Tue, 01 Mar 2016 10:26:50 -0800 (PST) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com. [209.85.213.177]) by smtp.gmail.com with ESMTPSA id ei2sm160545igc.11.2016.03.01.10.26.48 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Mar 2016 10:26:48 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id z8so24685030ige.0 for ; Tue, 01 Mar 2016 10:26:48 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.61.166 with SMTP id q6mr457397igr.96.1456856808195; Tue, 01 Mar 2016 10:26:48 -0800 (PST) Received: by 10.36.105.77 with HTTP; Tue, 1 Mar 2016 10:26:48 -0800 (PST) In-Reply-To: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> <56D000EF.9010004@alvestrand.no> <56D1A080.7050901@alvestrand.no> Date: Tue, 1 Mar 2016 13:26:48 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=047d7bdca2f88aa0b3052d00e8a0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 18:26:51 -0000 --047d7bdca2f88aa0b3052d00e8a0 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 1, 2016 at 3:04 AM, Asveren, Tolga wrote: > App. Developer may use different values based on the negotiated codec. > > > Can you please explain how negotiated codec will affect DTMF tone generation? WebRTC end points will only send DTMF tones using RFC 4733 telephone events, so codec negotiation will not affect DTMF tone duration. _____________ Roman Shpount --047d7bdca2f88aa0b3052d00e8a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 1, 2016 at 3:04 AM, Asveren, Tolga <<= a href=3D"mailto:tasveren@sonusnet.com" target=3D"_blank">tasveren@sonusnet= .com> wrote:

App. Developer may use different values base= d on the negotiated codec.



Can you please explain how negotiated codec will affect DTMF tone generati= on? WebRTC end points will only send DTMF tones using RFC 4733 telephone ev= ents, so codec negotiation will not affect DTMF tone duration.
_____________
Roman Shpount
=C2=A0
--047d7bdca2f88aa0b3052d00e8a0-- From nobody Tue Mar 1 10:31:39 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659F61B32B6 for ; Tue, 1 Mar 2016 10:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 JvEDU8L604Dm for ; Tue, 1 Mar 2016 10:31:37 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613D61B30F7 for ; Tue, 1 Mar 2016 10:31:37 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id l127so232431369iof.3 for ; Tue, 01 Mar 2016 10:31:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/LKcmiSq7uFftC7aAwNoGRk5Y0cJeGGfN/6bvOX6yds=; b=RZ7thzpFxqpIrZar7H6crFleccofsrBN11C3Cv58bOUPPuJCxF4V/yzSpzZcTnFl3M KGFNZQRkFgc4q7T19wcbq9zRZ0a/S23gHIfRsrmy2+bdRUCh9OfYulvA3FSMD4XFRQo/ GN/yEblh4XhGx9qGlGiiROQcssxEnPPU2oAumWaGduzlNU5iIwOOITKiJDlD8IgICGwq OVQh1s6Xjk3et0UHyhRAYl5StTPNlgBqGhOO2KW5SUua7qDTuiDTmaXLfXJlZzwL6XNn ANDg02Azc0LdwFlLaIxF0LHNDAsfJnlCsqB4Ryv0CAY7HIjziv1C6WvH/BBmx4OBbfix MA5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/LKcmiSq7uFftC7aAwNoGRk5Y0cJeGGfN/6bvOX6yds=; b=Q9p1B/wEyH0RQOAYt9g4KMSVLH6CU+js92Fzv5k2GufUiZ4WnOj4HvvRfzLDDodro0 CqkHgAcz0D9Jcbqmses2xGZFGvAR8d7V638hcFVz4JI7829bYqZ20+GS+K5UxJNrcIdv MvXxrzqAwBvjnDyAyHZ0fUwUOPC5WmxXdll41vdYy4bAkP0VhMqEKYgEHQARvLAr03lN 4velbrjM2Zpa+n3DgsYbsoum7OFI3ab38pK1rBSchHEEmBibgxoTrz76x1sT1wI1KBlu mNgnofj+M7/DIwYJjBid5iDQIDIL7WzbJMsf2oIeDYNZNRcqQeXLPiJI1T2Xf9n1/j8L tOrA== X-Gm-Message-State: AG10YOSk6qECnZV1K22rXg1htuncvfaiLFzt3DdjkhmADvEiKqRZ8aLZk2q7RIxEYUNuZA== X-Received: by 10.107.136.194 with SMTP id s63mr28874311ioi.88.1456857096785; Tue, 01 Mar 2016 10:31:36 -0800 (PST) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com. [209.85.223.176]) by smtp.gmail.com with ESMTPSA id z18sm158136igp.20.2016.03.01.10.31.34 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Mar 2016 10:31:35 -0800 (PST) Received: by mail-io0-f176.google.com with SMTP id g203so232481263iof.2 for ; Tue, 01 Mar 2016 10:31:34 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr23889483ioe.38.1456857094400; Tue, 01 Mar 2016 10:31:34 -0800 (PST) Received: by 10.36.105.77 with HTTP; Tue, 1 Mar 2016 10:31:34 -0800 (PST) In-Reply-To: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D1A080.7050901@alvestrand.no> <56D55FE9.60408@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> Date: Tue, 1 Mar 2016 13:31:34 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a1140b47299be6f052d00f99f Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 18:31:38 -0000 --001a1140b47299be6f052d00f99f Content-Type: text/plain; charset=UTF-8 On Tue, Mar 1, 2016 at 6:27 AM, Asveren, Tolga wrote: > And 40ms is definitely too low of a value, I am aware of VoIP systems > where lower values are used (but I definitely think that no enforced limit > is the right thing to do rather than merely decreasing min). > I assume you meant 40 ms is too high of the value. If you have an example of an application (except testing apps) which is using a lower value, please provide it to the list. _____________ Roman Shpount --001a1140b47299be6f052d00f99f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 1, 2016 at 6:27 AM, Asveren, Tolga <<= a href=3D"mailto:tasveren@sonusnet.com" target=3D"_blank">tasveren@sonusnet= .com> wrote:
=C2=A0And 40ms is definitely too low of a value, I am aware of V= oIP systems where lower values are used (but I definitely think that no enf= orced limit is the right thing to do rather than merely decreasing min).

I assume you meant 40 ms is too high of t= he value. If you have an example of an application (except testing apps) wh= ich is using a lower value, please provide it to the list.
_____________
Roman Shpount
=C2= =A0
--001a1140b47299be6f052d00f99f-- From nobody Tue Mar 1 10:40:23 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC491B3FA8 for ; Tue, 1 Mar 2016 10:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 riUiL33lhNWc for ; Tue, 1 Mar 2016 10:40:10 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0057.outbound.protection.outlook.com [65.55.169.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0594D1B38D3 for ; Tue, 1 Mar 2016 10:40:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=p6YWu4/rcJmCqpkWt0LPHSaSpSQCCMeAbMfj4Y0bXuA=; b=odgprQ6Ul3QKl8LhAwwscTWwxnH7MFH12YPDMyDMwLoJ5qB6g9uHXb23iib3kdkKAKvp7vgf4B4THO+OnoLiAGDUCv49D1KsvqhwKjS6ZBvrUx4TNBDfAxp/td0cEvArEwmPqkVHSlDTYEJ+0gMaM3AjExEK9XsQntm6h2a6Gas= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 1 Mar 2016 18:40:08 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Tue, 1 Mar 2016 18:40:08 +0000 From: "Asveren, Tolga" To: Roman Shpount Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p89KcurgAAU0gCAALLLgIAAOucggAC01ICAANVAYIAAKmkAgAA3mfCAAzMegIAAEaGAgAAC3oCAAAAVkIAAD2GAgAAJS/qAAA2lgIAAuVMQgACwKgCAAAH60A== Date: Tue, 1 Mar 2016 18:40:08 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56CE2CF4.70001@jmvalin.ca> <56D000EF.9010004@alvestrand.no> <56D1A080.7050901@alvestrand.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: telurix.com; dkim=none (message not signed) header.d=none;telurix.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: ce8cf50e-2dec-47a8-a0e4-08d34200ea03 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:NTdjFC9e3qjj1T/rYABXK00r7F3VeLZRsWP+HsGWqSjKA7OlY1vQjGrfVwU9pHTFPzj/iLqNihFnAcM4CeCR+vXZCdYFQ4CeCNXr5QQTGuPqk9olZfCv8zZj5CrGk6odxGgrH/iMMD43si4ErDWhVQ==; 24:HZBMdvDFJzqLV99KmyR3dNrgg2iTrETMzbS43470A7HVZOZvlE93sz9DMYaRxcD6+mWSGPXFXLHwDnuPGzd/ehpiL43OZGEI/wu9iAMr/0k= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 086831DFB4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(164054003)(2473001)(377454003)(50986999)(106116001)(2906002)(11100500001)(19300405004)(5002640100001)(76176999)(5003600100002)(87936001)(110136002)(102836003)(230783001)(93886004)(5001960100004)(81156009)(1096002)(76576001)(19625215002)(16236675004)(3660700001)(122556002)(10400500002)(790700001)(92566002)(3280700002)(15975445007)(6116002)(40100003)(19609705001)(2900100001)(3846002)(33656002)(99286002)(4326007)(19580405001)(1220700001)(189998001)(5008740100001)(54356999)(2950100001)(586003)(74316001)(77096005)(19580395003)(86362001)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB15510DF849E2E5A972044818B2BB0SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2016 18:40:08.1661 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 18:40:19 -0000 --_000_SN1PR0301MB15510DF849E2E5A972044818B2BB0SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TmVnb3RpYXRlZCBjb2RlYyBtYXkgcmV2ZWFsIGluZm9ybWF0aW9uIGFib3V0IHdoZXRoZXIgdHJh bnNjb2Rpbmcgd2lsbCBoYXBwZW4gKGFuZCBpdCBtYXkgYmUga25vd24gYSBwcmlvcmkgdGhhdCBh bGwgdHJhbnNjb2RlZCBzY2VuYXJpb3MgdXNlIGEgY2VydGFpbiBjb2RlYyBvbiB0aGUg4oCcbGVn YWN54oCdIHNpZGXigJ0gZXRj4oCmKSBvciBub3QgZGVwZW5kaW5nIG9uIGFwcGxpY2F0aW9uL2Rl cGxveW1lbnQgbW9kZWwsIGUuZy4gQU1SIG5lZ290aWF0ZWQgPT4gbm8gdHJhbnNjb2RpbmcuIEl0 IHJlYWxseSBkZXBlbmRzIG9uIHRoZSB1c2UgY2FzZS9kZXBsb3ltZW50IG1vZGVsLiBJIGFtIG5v dCBhcmd1aW5nIHRoaXMgd291bGQgYmUgYSBnZW5lcmljL3VuaXZlcnNhbCBjYXBhYmlsaXR5IGJ1 dCBtYXkgcGxheSBhIHJvbGUuIEFuZCBpZiBub3QsIGFnYWluIG5vdGhpbmcgaXMgcmVhbGx5IGNo YW5naW5nIGluIG15IG1haW4gYXJndW1lbnQ6IEFwcC4gRGV2ZWxvcGVyIGNhbiBlaXRoZXIgc3Vw cGx5IHRoZSB2YWx1ZXMgb3IgdXNlIHRoZSBicm93c2VyIGRlZmF1bHRzLg0KDQpUaGFua3MsDQpU b2xnYQ0KDQpGcm9tOiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5jb21dDQpT ZW50OiBUdWVzZGF5LCBNYXJjaCAwMSwgMjAxNiAxOjI3IFBNDQpUbzogQXN2ZXJlbiwgVG9sZ2Eg PHRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4NCkNjOiBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5j b20+OyBIYXJhbGQgQWx2ZXN0cmFuZCA8aGFyYWxkQGFsdmVzdHJhbmQubm8+OyBydGN3ZWJAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBGd2Q6IExhc3QgQ2FsbDogPGRyYWZ0LWlldGYt cnRjd2ViLWF1ZGlvLTEwLnR4dD4gKFdlYlJUQyBBdWRpbyBDb2RlYyBhbmQgUHJvY2Vzc2luZyBS ZXF1aXJlbWVudHMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQoNCk9uIFR1ZSwgTWFyIDEsIDIwMTYg YXQgMzowNCBBTSwgQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86 dGFzdmVyZW5Ac29udXNuZXQuY29tPj4gd3JvdGU6DQpBcHAuIERldmVsb3BlciBtYXkgdXNlIGRp ZmZlcmVudCB2YWx1ZXMgYmFzZWQgb24gdGhlIG5lZ290aWF0ZWQgY29kZWMuDQoNCg0KQ2FuIHlv dSBwbGVhc2UgZXhwbGFpbiBob3cgbmVnb3RpYXRlZCBjb2RlYyB3aWxsIGFmZmVjdCBEVE1GIHRv bmUgZ2VuZXJhdGlvbj8gV2ViUlRDIGVuZCBwb2ludHMgd2lsbCBvbmx5IHNlbmQgRFRNRiB0b25l cyB1c2luZyBSRkMgNDczMyB0ZWxlcGhvbmUgZXZlbnRzLCBzbyBjb2RlYyBuZWdvdGlhdGlvbiB3 aWxsIG5vdCBhZmZlY3QgRFRNRiB0b25lIGR1cmF0aW9uLg0KX19fX19fX19fX19fXw0KUm9tYW4g U2hwb3VudA0KDQo= --_000_SN1PR0301MB15510DF849E2E5A972044818B2BB0SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk5lZ290aWF0ZWQgY29kZWMgbWF5IHJldmVh bCBpbmZvcm1hdGlvbiBhYm91dCB3aGV0aGVyIHRyYW5zY29kaW5nIHdpbGwgaGFwcGVuIChhbmQg aXQgbWF5IGJlIGtub3duIGEgcHJpb3JpIHRoYXQgYWxsIHRyYW5zY29kZWQgc2NlbmFyaW9zIHVz ZSBhIGNlcnRhaW4gY29kZWMNCiBvbiB0aGUg4oCcbGVnYWN54oCdIHNpZGXigJ0gZXRj4oCmKSBv ciBub3QgZGVwZW5kaW5nIG9uIGFwcGxpY2F0aW9uL2RlcGxveW1lbnQgbW9kZWwsIGUuZy4gQU1S IG5lZ290aWF0ZWQgPSZndDsgbm8gdHJhbnNjb2RpbmcuIEl0IHJlYWxseSBkZXBlbmRzIG9uIHRo ZSB1c2UgY2FzZS9kZXBsb3ltZW50IG1vZGVsLiBJIGFtIG5vdCBhcmd1aW5nIHRoaXMgd291bGQg YmUgYSBnZW5lcmljL3VuaXZlcnNhbCBjYXBhYmlsaXR5IGJ1dCBtYXkgcGxheSBhIHJvbGUuIEFu ZA0KIGlmIG5vdCwgYWdhaW4gbm90aGluZyBpcyByZWFsbHkgY2hhbmdpbmcgaW4gbXkgbWFpbiBh cmd1bWVudDogQXBwLiBEZXZlbG9wZXIgY2FuIGVpdGhlciBzdXBwbHkgdGhlIHZhbHVlcyBvciB1 c2UgdGhlIGJyb3dzZXIgZGVmYXVsdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRvbGdhPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUm9t YW4gU2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFR1ZXNkYXksIE1hcmNoIDAxLCAyMDE2IDE6MjcgUE08YnI+DQo8Yj5Ubzo8L2I+IEFzdmVyZW4s IFRvbGdhICZsdDt0YXN2ZXJlbkBzb251c25ldC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBUZWQg SGFyZGllICZsdDt0ZWQuaWV0ZkBnbWFpbC5jb20mZ3Q7OyBIYXJhbGQgQWx2ZXN0cmFuZCAmbHQ7 aGFyYWxkQGFsdmVzdHJhbmQubm8mZ3Q7OyBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtydGN3ZWJdIEZ3ZDogTGFzdCBDYWxsOiAmbHQ7ZHJhZnQtaWV0Zi1ydGN3ZWIt YXVkaW8tMTAudHh0Jmd0OyAoV2ViUlRDIEF1ZGlvIENvZGVjIGFuZCBQcm9jZXNzaW5nIFJlcXVp cmVtZW50cykgdG8gUHJvcG9zZWQgU3RhbmRhcmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBN YXIgMSwgMjAxNiBhdCAzOjA0IEFNLCBBc3ZlcmVuLCBUb2xnYSAmbHQ7PGEgaHJlZj0ibWFpbHRv OnRhc3ZlcmVuQHNvbnVzbmV0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRhc3ZlcmVuQHNvbnVzbmV0 LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BcHAuIERldmVsb3BlciBtYXkgdXNlIGRpZmZlcmVu dCB2YWx1ZXMgYmFzZWQgb24gdGhlIG5lZ290aWF0ZWQgY29kZWMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5D YW4geW91IHBsZWFzZSBleHBsYWluIGhvdyBuZWdvdGlhdGVkIGNvZGVjIHdpbGwgYWZmZWN0IERU TUYgdG9uZSBnZW5lcmF0aW9uPyBXZWJSVEMgZW5kIHBvaW50cyB3aWxsIG9ubHkgc2VuZCBEVE1G IHRvbmVzIHVzaW5nIFJGQyA0NzMzIHRlbGVwaG9uZSBldmVudHMsIHNvIGNvZGVjIG5lZ290aWF0 aW9uIHdpbGwgbm90IGFmZmVjdCBEVE1GIHRvbmUgZHVyYXRpb24uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fXzxi cj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SN1PR0301MB15510DF849E2E5A972044818B2BB0SN1PR0301MB1551_-- From nobody Tue Mar 1 10:47:13 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3961B3FB3 for ; Tue, 1 Mar 2016 10:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 b3hMlJfXmhyI for ; Tue, 1 Mar 2016 10:47:10 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0090.outbound.protection.outlook.com [65.55.169.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74C6C1B3F9A for ; Tue, 1 Mar 2016 10:47:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/+NfNzsbrUGbh9YEtwDKdpsrPyR8gH2UxWH9lppYz9g=; b=XBRsGJjnpiG+OqOuS9bcYgbE50h2a5AqCijtR7OlhNayAh2bu51nJ6CTz/1RmG+1crVK6LErBnSB/5saa2VzXIOUXvggZzR+Jkl8ekt1sJJTlyd6Il5jHTs/zTFzMUmdFpmBnuhd3kZ9wPR94xUph6doRdNfkklruUNjcON7tOI= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 1 Mar 2016 18:47:03 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Tue, 1 Mar 2016 18:47:03 +0000 From: "Asveren, Tolga" To: Roman Shpount Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p9EeOUQgAB4VQCAAAJvQA== Date: Tue, 1 Mar 2016 18:47:02 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D1A080.7050901@alvestrand.no> <56D55FE9.60408@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: telurix.com; dkim=none (message not signed) header.d=none;telurix.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 3964cddd-1e78-4283-3aa5-08d34201e14e x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:K2VbITey0OrdVnqUMteTQIduWJ8XdCpw257ZtOyN1z8pKKwtW3dWAWA6HEJTVxqfNmFIA0+chu/LrmVdYGxOyVfphrYW8JWQ/N8jnV3LYOmph0GDBiiTNC3CFdaqWlhnoUhE/nrBCuyf7Mu2kArBng==; 24:Lc80QkyrsqNx+ubQEQ/+UIPjjBXHPyefP6+qPF8uMkfOELxZtXSuAoqeZU2i+jAizVtyMvJr6gd6P/bbufXr6Tuvl831olJeIGEtxGS3m20= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 086831DFB4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(2473001)(377454003)(24454002)(164054003)(3846002)(33656002)(99286002)(790700001)(92566002)(15975445007)(3280700002)(19609705001)(2900100001)(6116002)(40100003)(77096005)(19580395003)(86362001)(74316001)(66066001)(5001960100004)(81156009)(19580405001)(4326007)(1220700001)(2950100001)(54356999)(586003)(5008740100001)(189998001)(5003600100002)(87936001)(76176999)(19300405004)(5002640100001)(102836003)(110136002)(106116001)(50986999)(11100500001)(2906002)(3660700001)(16236675004)(19625215002)(122556002)(10400500002)(93886004)(230783001)(76576001)(1096002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551006A8D73179743E85322B2BB0SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2016 18:47:03.0210 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 18:47:12 -0000 --_000_SN1PR0301MB1551006A8D73179743E85322B2BB0SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWggeWVzLCBJIG1lYW50IHRvbyBoaWdo4oCmDQoNCmktIEFzIGEgZ2VuZXJhbCBwcmluY2lwbGUg 4oCcQWJzZW5jZSBvZiBwcm9vZiBkb2VzIG5vdCBtZWFuIHByb29mIG9mIGFic2VuY2XigJ0uIFRo YXQgeW91L0kveCBoYXMgbm90IHNlZW4gYW4gYXBwbGljYXRpb24gaW4gdGhlaXIgbGlmZXRpbWUg dXNpbmcgYSB2YWx1ZSBsb3dlciB0aGFuIDQwbXMgZG9lcyBub3QgbWVhbiBhIHVzZSBjYXNlIGRv ZXMgbm90IGV4aXN0L2NhbuKAmXQgZXhpc3QgaW4gdGhlIGZ1dHVyZS4NCg0KaWktIEFzIGFub3Ro ZXIgZ2VuZXJhbCBwcmluY2lwbGUsIGludHJvZHVjaW5nIGEgcmVzdHJpY3Rpb24gd2l0aG91dCBh IGdvb2QgcmVhc29uIGlzIGEgYmFkIGlkZWEgSU1ITy4gU28gZmFyLCBJIHlldCBoYXZlIHRvIHNl ZSBhIGdvb2QgYXJndW1lbnQgaW4gZmF2b3Igb2YgYW4gZW5mb3JjZWQgcmFuZ2UgKG90aGVyIHRo YW4gdGhhdCB3ZSBzaG91bGQgYXNzdW1lIHRoYXQgaW50ZWxsaWdlbmNlIGxldmVsIG9mIGFwcC4g ZGV2ZWxvcGVy4oCZcyBpcyBlcXVhbCB0byBhIGNoaW1wYW56ZWUpDQoNCmlpaS0gSSBzYXcgbG9n cyB1c2luZyB2YWx1ZXMgbGVzcyB0aGFuIDQwbXMgKGFuZCBhbSBhd2FyZSBvZiBTQkNzIHN1cHBv cnRpbmcgbG93ZXIgdGhhbiA0MG1zIHZhbHVlcykgYnV0IEkgYW0gbm90IHN1cmUgcmlnaHQgbm93 IHdoYXQgd2FzIHRoZSBlbWl0dGluZyBub2RlIChidXQgYWdhaW4sIHRoaXMgcmVhbGx5IHNob3Vs ZG7igJl0IGJlIHRoZSBkZXRlcm1pbmluZyBmYWN0b3IgaW4gdGhpcyBkZWJhdGU7IGlpLSBpcyB0 aGUgbWFpbiBwb2ludCBJTUhPIGZvciBhIGNsZWFuIHNvbHV0aW9uKS4NCg0KVGhhbmtzLA0KVG9s Z2ENCg0KRnJvbTogUm9tYW4gU2hwb3VudCBbbWFpbHRvOnJvbWFuQHRlbHVyaXguY29tXQ0KU2Vu dDogVHVlc2RheSwgTWFyY2ggMDEsIDIwMTYgMTozMiBQTQ0KVG86IEFzdmVyZW4sIFRvbGdhIDx0 YXN2ZXJlbkBzb251c25ldC5jb20+DQpDYzogU3RlZmFuIEjDpWthbnNzb24gTEsgPHN0ZWZhbi5s ay5oYWthbnNzb25AZXJpY3Nzb24uY29tPjsgSGFyYWxkIEFsdmVzdHJhbmQgPGhhcmFsZEBhbHZl c3RyYW5kLm5vPjsgVGVkIEhhcmRpZSA8dGVkLmlldGZAZ21haWwuY29tPjsgcnRjd2ViQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gRndkOiBMYXN0IENhbGw6IDxkcmFmdC1pZXRmLXJ0 Y3dlYi1hdWRpby0xMC50eHQ+IChXZWJSVEMgQXVkaW8gQ29kZWMgYW5kIFByb2Nlc3NpbmcgUmVx dWlyZW1lbnRzKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KDQpPbiBUdWUsIE1hciAxLCAyMDE2IGF0 IDY6MjcgQU0sIEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb208bWFpbHRvOnRh c3ZlcmVuQHNvbnVzbmV0LmNvbT4+IHdyb3RlOg0KIEFuZCA0MG1zIGlzIGRlZmluaXRlbHkgdG9v IGxvdyBvZiBhIHZhbHVlLCBJIGFtIGF3YXJlIG9mIFZvSVAgc3lzdGVtcyB3aGVyZSBsb3dlciB2 YWx1ZXMgYXJlIHVzZWQgKGJ1dCBJIGRlZmluaXRlbHkgdGhpbmsgdGhhdCBubyBlbmZvcmNlZCBs aW1pdCBpcyB0aGUgcmlnaHQgdGhpbmcgdG8gZG8gcmF0aGVyIHRoYW4gbWVyZWx5IGRlY3JlYXNp bmcgbWluKS4NCg0KSSBhc3N1bWUgeW91IG1lYW50IDQwIG1zIGlzIHRvbyBoaWdoIG9mIHRoZSB2 YWx1ZS4gSWYgeW91IGhhdmUgYW4gZXhhbXBsZSBvZiBhbiBhcHBsaWNhdGlvbiAoZXhjZXB0IHRl c3RpbmcgYXBwcykgd2hpY2ggaXMgdXNpbmcgYSBsb3dlciB2YWx1ZSwgcGxlYXNlIHByb3ZpZGUg aXQgdG8gdGhlIGxpc3QuDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCg== --_000_SN1PR0301MB1551006A8D73179743E85322B2BB0SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFoIHllcywgSSBtZWFudCB0b28gaGlnaOKA pjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aS0gQXMgYSBnZW5l cmFsIHByaW5jaXBsZSDigJxBYnNlbmNlIG9mIHByb29mIGRvZXMgbm90IG1lYW4gcHJvb2Ygb2Yg YWJzZW5jZeKAnS4gVGhhdCB5b3UvSS94IGhhcyBub3Qgc2VlbiBhbiBhcHBsaWNhdGlvbiBpbiB0 aGVpciBsaWZldGltZSB1c2luZyBhIHZhbHVlIGxvd2VyIHRoYW4NCiA0MG1zIGRvZXMgbm90IG1l YW4gYSB1c2UgY2FzZSBkb2VzIG5vdCBleGlzdC9jYW7igJl0IGV4aXN0IGluIHRoZSBmdXR1cmUu IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aWktIEFzIGFub3Ro ZXIgZ2VuZXJhbCBwcmluY2lwbGUsIGludHJvZHVjaW5nIGEgcmVzdHJpY3Rpb24gd2l0aG91dCBh IGdvb2QgcmVhc29uIGlzIGEgYmFkIGlkZWEgSU1ITy4gU28gZmFyLCBJIHlldCBoYXZlIHRvIHNl ZSBhIGdvb2QgYXJndW1lbnQgaW4gZmF2b3Igb2YgYW4NCiBlbmZvcmNlZCByYW5nZSAob3RoZXIg dGhhbiB0aGF0IHdlIHNob3VsZCBhc3N1bWUgdGhhdCBpbnRlbGxpZ2VuY2UgbGV2ZWwgb2YgYXBw LiBkZXZlbG9wZXLigJlzIGlzIGVxdWFsIHRvIGEgY2hpbXBhbnplZSk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmlpaS0gSSBzYXcgbG9ncyB1c2luZyB2YWx1ZXMg bGVzcyB0aGFuIDQwbXMgKGFuZCBhbSBhd2FyZSBvZiBTQkNzIHN1cHBvcnRpbmcgbG93ZXIgdGhh biA0MG1zIHZhbHVlcykgYnV0IEkgYW0gbm90IHN1cmUgcmlnaHQgbm93IHdoYXQgd2FzIHRoZSBl bWl0dGluZyBub2RlIChidXQNCiBhZ2FpbiwgdGhpcyByZWFsbHkgc2hvdWxkbuKAmXQgYmUgdGhl IGRldGVybWluaW5nIGZhY3RvciBpbiB0aGlzIGRlYmF0ZTsgaWktIGlzIHRoZSBtYWluIHBvaW50 IElNSE8gZm9yIGEgY2xlYW4gc29sdXRpb24pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ub2xnYTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBNYXJjaCAwMSwgMjAxNiAxOjMyIFBNPGJyPg0KPGI+VG86PC9iPiBBc3Zl cmVuLCBUb2xnYSAmbHQ7dGFzdmVyZW5Ac29udXNuZXQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4g U3RlZmFuIEjDpWthbnNzb24gTEsgJmx0O3N0ZWZhbi5say5oYWthbnNzb25AZXJpY3Nzb24uY29t Jmd0OzsgSGFyYWxkIEFsdmVzdHJhbmQgJmx0O2hhcmFsZEBhbHZlc3RyYW5kLm5vJmd0OzsgVGVk IEhhcmRpZSAmbHQ7dGVkLmlldGZAZ21haWwuY29tJmd0OzsgcnRjd2ViQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBGd2Q6IExhc3QgQ2FsbDogJmx0O2RyYWZ0LWll dGYtcnRjd2ViLWF1ZGlvLTEwLnR4dCZndDsgKFdlYlJUQyBBdWRpbyBDb2RlYyBhbmQgUHJvY2Vz c2luZyBSZXF1aXJlbWVudHMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIFR1ZSwgTWFyIDEsIDIwMTYgYXQgNjoyNyBBTSwgQXN2ZXJlbiwgVG9sZ2EgJmx0OzxhIGhy ZWY9Im1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20iIHRhcmdldD0iX2JsYW5rIj50YXN2ZXJl bkBzb251c25ldC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO0FuZCA0 MG1zIGlzIGRlZmluaXRlbHkgdG9vIGxvdyBvZiBhIHZhbHVlLCBJIGFtIGF3YXJlIG9mIFZvSVAg c3lzdGVtcyB3aGVyZSBsb3dlciB2YWx1ZXMgYXJlIHVzZWQgKGJ1dCBJIGRlZmluaXRlbHkgdGhp bmsgdGhhdCBubyBlbmZvcmNlZCBsaW1pdCBpcyB0aGUgcmlnaHQgdGhpbmcgdG8gZG8gcmF0aGVy IHRoYW4gbWVyZWx5IGRlY3JlYXNpbmcgbWluKS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYXNzdW1lIHlvdSBtZWFudCA0MCBt cyBpcyB0b28gaGlnaCBvZiB0aGUgdmFsdWUuIElmIHlvdSBoYXZlIGFuIGV4YW1wbGUgb2YgYW4g YXBwbGljYXRpb24gKGV4Y2VwdCB0ZXN0aW5nIGFwcHMpIHdoaWNoIGlzIHVzaW5nIGEgbG93ZXIg dmFsdWUsIHBsZWFzZSBwcm92aWRlIGl0IHRvIHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+ DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN1PR0301MB1551006A8D73179743E85322B2BB0SN1PR0301MB1551_-- From nobody Tue Mar 1 10:58:43 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6920B1B3FB6 for ; Tue, 1 Mar 2016 10:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 7bcDNuYoUb_S for ; Tue, 1 Mar 2016 10:58:41 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA25C1B3FCA for ; Tue, 1 Mar 2016 10:58:40 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id s5so73083398qkd.0 for ; Tue, 01 Mar 2016 10:58:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vo84afoRKT5IrGQlN4nRPkj0Tb6HZhhlYc+hBc2jL/8=; b=xfVSQi0Kx8zdc+eMnUvBunMXZaOJiHGWsMeMks0AmDt+cpARv/cTdDXNwsYsVbXXI+ z9cMA9RaKyGfWbBShFdtBrZjNwHYqyuzBUZFtRo0tN+GLZBwoOgERaFkZDhvBh5UkalF MXUYlfEGFmudvuh7G4pXCbkSX+qjvnnZEFwVqOh8PN0An3oslG+JpStjedOs/EdHnh5h ZwPi4w5Gfgao33/43pv3wOgfK0WpUf5ZZ90IIVkmZhN8wNHAfC00W/LUvsP8q+Vqv5vs idhgYModsvzNWyWDqok3NmgV9IJt8QUmEXCvlBlQuLDSyVy1RC5yMaMS2EY+hOsYM7VS h7ZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vo84afoRKT5IrGQlN4nRPkj0Tb6HZhhlYc+hBc2jL/8=; b=AczNckdZ5WNMs4s74BBfJPDflkqIELJP8zkh/TlARCdmSetKoApSkwVWpQjFGIC+4R OmRzKN37Dcp3/ncsgiA3R+GS4E0fdm6JY1+/6f49DrdFI/bYXhSzqBNucnav3zO1UsfZ 8sLdLNfNH3kRFvPaw/lLY7l+QKbKOZTgwDM7Fd3DALndoUgFmmz/AWT1YJvJ16cOIFsb ToDF+PybEorMrR3V4TAD9qnkFmfkOh4J6KgbJfGKoEb0+9BgeF6t06mguI/YoA/z7/Zq coL/bk7le3hrZW+SLEDIBWBVICz5irqQ0/kTDog9G8lhQcFvfPx3rBYx+fYj48Tj8i1B Qr8A== X-Gm-Message-State: AD7BkJLntqGB2NsFGgMBWgIWrxPROmGK4UWbxKlNiQk/c1iJgjgtu4bhgFdwb8uOsFeGNK+Yta7fLJeXLh3jSQ== X-Received: by 10.55.49.11 with SMTP id x11mr28145894qkx.86.1456858719803; Tue, 01 Mar 2016 10:58:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.6.13 with HTTP; Tue, 1 Mar 2016 10:58:20 -0800 (PST) In-Reply-To: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D1A080.7050901@alvestrand.no> <56D55FE9.60408@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> From: Ted Hardie Date: Tue, 1 Mar 2016 10:58:20 -0800 Message-ID: To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a114780787b694d052d015adc Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 18:58:42 -0000 --001a114780787b694d052d015adc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tolga, On Tue, Mar 1, 2016 at 10:47 AM, Asveren, Tolga wrote: > > > ii- As another general principle, introducing a restriction without a goo= d > reason is a bad idea IMHO. So far, I yet have to see a good argument in > favor of an enforced range (other than that we should assume that > intelligence level of app. developer=E2=80=99s is equal to a chimpanzee) > > > This is not a fair characterization of the point that has been made, and I'd appreciate your being careful with your wording. The point that has been made is that there will be a range imposed by browsers and that standardizing that range avoids the complexity of discovery and/or random failure modes. If you are arguing that there will be no enforced range at all, then the browser makers' assertion to the contrary seems to be problematic for accepting your argument. regards, Ted --001a114780787b694d052d015adc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tolga,

On Tue, Mar 1, 2016 at 10:47 AM, Asveren, Tolga <tas= veren@sonusnet.com> wrote:

=C2=A0

ii- As another general principle, int= roducing a restriction without a good reason is a bad idea IMHO. So far, I = yet have to see a good argument in favor of an enforced range (other than that we should assume that intelligence level o= f app. developer=E2=80=99s is equal to a chimpanzee)


This is not a fair characterization of the point that has been mad= e, and I'd appreciate your being careful with your wording.=C2=A0 The p= oint that has been made is that there will be a range imposed by browsers a= nd that standardizing that range avoids the complexity of discovery and/or = random failure modes.=C2=A0 If you are arguing that there will be no enforc= ed range at all, then the browser makers' assertion to the contrary see= ms to be problematic for accepting your argument.

regards,

Ted

--001a114780787b694d052d015adc-- From nobody Tue Mar 1 11:02:48 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697731B3FCE for ; Tue, 1 Mar 2016 11:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham 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 JOYY2MvnpkMF for ; Tue, 1 Mar 2016 11:02:44 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0613.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::613]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27D01B3948 for ; Tue, 1 Mar 2016 11:02:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nDpmFrfq94spG3h9WPnq0+UzGDLcZC+JXyF2Kk5Y0jU=; b=FtrB3WnrHKdsdBMcmEcyxILIZL89KWJkQ/MDNxexy2Xz5KPtbv192bmzp+imWro4lm3QHYX/tBXb8YlA8Jg4SPbI2eIKBhbumhQosDx6fKHqZI7VG/BhTgzdkR7MSwh5tzClF+qi2zf8lDMS0at64hH/GhBWcOobQGYqGh3xYHk= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 1 Mar 2016 19:02:24 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Tue, 1 Mar 2016 19:02:24 +0000 From: "Asveren, Tolga" To: Ted Hardie Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p9EeOUQgAB4VQCAAAJvQIAABQwAgAAAciA= Date: Tue, 1 Mar 2016 19:02:24 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D1A080.7050901@alvestrand.no> <56D55FE9.60408@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: a34b50b0-3587-49ca-76f1-08d3420406b3 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1551; 5:FH0x/ymLeoWClZD8D4mD4cvp7m+gokbdTq76tq4Ifqh1ebd0NqHdOVN38nuvFtnp+oyfRh0Trkz7gb6+4OuxsqrTGbCnQQowxNrXroF60uihtnsJ5bR18PQW/lv09MIYB2Abl7EH3mYv2F3us6T00Q==; 24:75XzvaU/UyqF/zRRIn2X4iOSRa9m714B2rPLTZfBC3LyQeXTBVpsDjtjdPFQwO7HYVJs6gbrMkhjaKinOL6BqSzeIYqhHLU4nNFiYxbyfuY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1551; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR0301MB1551; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1551; x-forefront-prvs: 086831DFB4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(24454002)(164054003)(2473001)(3846002)(6116002)(790700001)(3660700001)(2906002)(5003600100002)(102836003)(586003)(5008740100001)(86362001)(5001960100004)(81156009)(230783001)(76576001)(93886004)(99286002)(54356999)(122556002)(19609705001)(3280700002)(66066001)(40100003)(19625215002)(10400500002)(19300405004)(110136002)(1220700001)(189998001)(77096005)(2900100001)(4326007)(15975445007)(2950100001)(19580395003)(74316001)(11100500001)(5002640100001)(33656002)(1096002)(50986999)(16236675004)(87936001)(106116001)(92566002)(76176999)(19580405001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1551; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551CDEEA6EA1C7A696972B7B2BB0SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2016 19:02:24.6755 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1551 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 19:02:47 -0000 --_000_SN1PR0301MB1551CDEEA6EA1C7A696972B7B2BB0SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCcdGhhdCB0aGVyZSB3aWxsIGJlIGEgcmFuZ2UgaW1wb3NlZCBieSBicm93c2Vyc+KAnQ0KV2h5 IGFyZSB3ZSBhc3N1bWluZyB0aGlzPyBUaGVyZSBzaG91bGQgYmUgc29tZSBqdXN0aWZpY2F0aW9u IGZvciB0aGlzIHN0YXRlbWVudCAoYW5kIHRoaXMgaXMgd2hhdCBJIGZhaWwgdG8gc2VlL3VuZGVy c3RhbmQgYnV0IGFtIHJlYWxseSBvcGVuIHRvIGdvb2QgZXhwbGFuYXRpb24gZm9yIHRoZSBuZWVk IGZvciB0aGlzKS4gVGhlIG1vZGVsIEkgcHJlc2VudGVkIGhhcyBhIOKAnGRlZmF1bHQgdmFsdWXi gJ0gZm9yIGJyb3dzZXJzIG5vdCBhbiDigJxlbmZvcmNlZCByYW5nZeKAnS4gVGhvc2UgdHdvIGFy ZSBkaWZmZXJlbnQgdGhpbmdzLg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpGcm9tOiBUZWQgSGFyZGll IFttYWlsdG86dGVkLmlldGZAZ21haWwuY29tXQ0KU2VudDogVHVlc2RheSwgTWFyY2ggMDEsIDIw MTYgMTo1OCBQTQ0KVG86IEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb20+DQpD YzogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb20+OyBTdGVmYW4gSMOla2Fuc3NvbiBM SyA8c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nvbi5jb20+OyBIYXJhbGQgQWx2ZXN0cmFuZCA8 aGFyYWxkQGFsdmVzdHJhbmQubm8+OyBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRj d2ViXSBGd2Q6IExhc3QgQ2FsbDogPGRyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvLTEwLnR4dD4gKFdl YlJUQyBBdWRpbyBDb2RlYyBhbmQgUHJvY2Vzc2luZyBSZXF1aXJlbWVudHMpIHRvIFByb3Bvc2Vk IFN0YW5kYXJkDQoNCkhpIFRvbGdhLA0KDQpPbiBUdWUsIE1hciAxLCAyMDE2IGF0IDEwOjQ3IEFN LCBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPG1haWx0bzp0YXN2ZXJlbkBz b251c25ldC5jb20+PiB3cm90ZToNCg0KaWktIEFzIGFub3RoZXIgZ2VuZXJhbCBwcmluY2lwbGUs IGludHJvZHVjaW5nIGEgcmVzdHJpY3Rpb24gd2l0aG91dCBhIGdvb2QgcmVhc29uIGlzIGEgYmFk IGlkZWEgSU1ITy4gU28gZmFyLCBJIHlldCBoYXZlIHRvIHNlZSBhIGdvb2QgYXJndW1lbnQgaW4g ZmF2b3Igb2YgYW4gZW5mb3JjZWQgcmFuZ2UgKG90aGVyIHRoYW4gdGhhdCB3ZSBzaG91bGQgYXNz dW1lIHRoYXQgaW50ZWxsaWdlbmNlIGxldmVsIG9mIGFwcC4gZGV2ZWxvcGVy4oCZcyBpcyBlcXVh bCB0byBhIGNoaW1wYW56ZWUpDQoNClRoaXMgaXMgbm90IGEgZmFpciBjaGFyYWN0ZXJpemF0aW9u IG9mIHRoZSBwb2ludCB0aGF0IGhhcyBiZWVuIG1hZGUsIGFuZCBJJ2QgYXBwcmVjaWF0ZSB5b3Vy IGJlaW5nIGNhcmVmdWwgd2l0aCB5b3VyIHdvcmRpbmcuICBUaGUgcG9pbnQgdGhhdCBoYXMgYmVl biBtYWRlIGlzIHRoYXQgdGhlcmUgd2lsbCBiZSBhIHJhbmdlIGltcG9zZWQgYnkgYnJvd3NlcnMg YW5kIHRoYXQgc3RhbmRhcmRpemluZyB0aGF0IHJhbmdlIGF2b2lkcyB0aGUgY29tcGxleGl0eSBv ZiBkaXNjb3ZlcnkgYW5kL29yIHJhbmRvbSBmYWlsdXJlIG1vZGVzLiAgSWYgeW91IGFyZSBhcmd1 aW5nIHRoYXQgdGhlcmUgd2lsbCBiZSBubyBlbmZvcmNlZCByYW5nZSBhdCBhbGwsIHRoZW4gdGhl IGJyb3dzZXIgbWFrZXJzJyBhc3NlcnRpb24gdG8gdGhlIGNvbnRyYXJ5IHNlZW1zIHRvIGJlIHBy b2JsZW1hdGljIGZvciBhY2NlcHRpbmcgeW91ciBhcmd1bWVudC4NCnJlZ2FyZHMsDQpUZWQNCg0K --_000_SN1PR0301MB1551CDEEA6EA1C7A696972B7B2BB0SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ 4oCcdGhhdCB0aGVyZSB3aWxsIGJlIGEgcmFuZ2UgaW1wb3NlZCBieSBicm93c2Vyc+KAnTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0 NDU0NkEiPldoeSBhcmUgd2UgYXNzdW1pbmcgdGhpcz8gVGhlcmUgc2hvdWxkIGJlIHNvbWUganVz dGlmaWNhdGlvbiBmb3IgdGhpcyBzdGF0ZW1lbnQgKGFuZCB0aGlzIGlzIHdoYXQgSSBmYWlsIHRv IHNlZS91bmRlcnN0YW5kIGJ1dCBhbSByZWFsbHkgb3BlbiB0byBnb29kIGV4cGxhbmF0aW9uDQog Zm9yIHRoZSBuZWVkIGZvciB0aGlzKS4gVGhlIG1vZGVsIEkgcHJlc2VudGVkIGhhcyBhIOKAnGRl ZmF1bHQgdmFsdWXigJ0gZm9yIGJyb3dzZXJzIG5vdCBhbiDigJxlbmZvcmNlZCByYW5nZeKAnS4g VGhvc2UgdHdvIGFyZSBkaWZmZXJlbnQgdGhpbmdzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZBIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzQ0NTQ2QSI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZBIj5Ub2xnYTwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzQ0NTQ2QSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVGVkIEhhcmRpZSBbbWFp bHRvOnRlZC5pZXRmQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXJj aCAwMSwgMjAxNiAxOjU4IFBNPGJyPg0KPGI+VG86PC9iPiBBc3ZlcmVuLCBUb2xnYSAmbHQ7dGFz dmVyZW5Ac29udXNuZXQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gUm9tYW4gU2hwb3VudCAmbHQ7 cm9tYW5AdGVsdXJpeC5jb20mZ3Q7OyBTdGVmYW4gSMOla2Fuc3NvbiBMSyAmbHQ7c3RlZmFuLmxr Lmhha2Fuc3NvbkBlcmljc3Nvbi5jb20mZ3Q7OyBIYXJhbGQgQWx2ZXN0cmFuZCAmbHQ7aGFyYWxk QGFsdmVzdHJhbmQubm8mZ3Q7OyBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtydGN3ZWJdIEZ3ZDogTGFzdCBDYWxsOiAmbHQ7ZHJhZnQtaWV0Zi1ydGN3ZWItYXVkaW8t MTAudHh0Jmd0OyAoV2ViUlRDIEF1ZGlvIENvZGVjIGFuZCBQcm9jZXNzaW5nIFJlcXVpcmVtZW50 cykgdG8gUHJvcG9zZWQgU3RhbmRhcmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgVG9sZ2EsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgTWFyIDEsIDIwMTYgYXQgMTA6NDcgQU0sIEFzdmVy ZW4sIFRvbGdhICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tIiB0YXJn ZXQ9Il9ibGFuayI+dGFzdmVyZW5Ac29udXNuZXQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5paS0gQXMgYW5vdGhlciBnZW5lcmFsIHByaW5jaXBsZSwgaW50cm9kdWNpbmcgYSByZXN0cmlj dGlvbiB3aXRob3V0IGEgZ29vZCByZWFzb24gaXMgYSBiYWQgaWRlYSBJTUhPLg0KIFNvIGZhciwg SSB5ZXQgaGF2ZSB0byBzZWUgYSBnb29kIGFyZ3VtZW50IGluIGZhdm9yIG9mIGFuIGVuZm9yY2Vk IHJhbmdlIChvdGhlciB0aGFuIHRoYXQgd2Ugc2hvdWxkIGFzc3VtZSB0aGF0IGludGVsbGlnZW5j ZSBsZXZlbCBvZiBhcHAuIGRldmVsb3BlcuKAmXMgaXMgZXF1YWwgdG8gYSBjaGltcGFuemVlKTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoaXMgaXMgbm90IGEg ZmFpciBjaGFyYWN0ZXJpemF0aW9uIG9mIHRoZSBwb2ludCB0aGF0IGhhcyBiZWVuIG1hZGUsIGFu ZCBJJ2QgYXBwcmVjaWF0ZSB5b3VyIGJlaW5nIGNhcmVmdWwgd2l0aCB5b3VyIHdvcmRpbmcuJm5i c3A7IFRoZSBwb2ludCB0aGF0IGhhcyBiZWVuIG1hZGUgaXMgdGhhdCB0aGVyZSB3aWxsIGJlIGEg cmFuZ2UgaW1wb3NlZCBieSBicm93c2VycyBhbmQNCiB0aGF0IHN0YW5kYXJkaXppbmcgdGhhdCBy YW5nZSBhdm9pZHMgdGhlIGNvbXBsZXhpdHkgb2YgZGlzY292ZXJ5IGFuZC9vciByYW5kb20gZmFp bHVyZSBtb2Rlcy4mbmJzcDsgSWYgeW91IGFyZSBhcmd1aW5nIHRoYXQgdGhlcmUgd2lsbCBiZSBu byBlbmZvcmNlZCByYW5nZSBhdCBhbGwsIHRoZW4gdGhlIGJyb3dzZXIgbWFrZXJzJyBhc3NlcnRp b24gdG8gdGhlIGNvbnRyYXJ5IHNlZW1zIHRvIGJlIHByb2JsZW1hdGljIGZvciBhY2NlcHRpbmcg eW91ciBhcmd1bWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+cmVnYXJkcyw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRlZDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_SN1PR0301MB1551CDEEA6EA1C7A696972B7B2BB0SN1PR0301MB1551_-- From nobody Wed Mar 2 15:10:21 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2343E1B340C for ; Wed, 2 Mar 2016 15:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 65m_N7iTHeho for ; Wed, 2 Mar 2016 15:10:18 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8986D1B341D for ; Wed, 2 Mar 2016 15:10:04 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id x1so1947394qkc.1 for ; Wed, 02 Mar 2016 15:10:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XZZvZqd2/XvPbZ+Yf9SpoSGRZyB8tNIve0skANFh1U0=; b=acJjpo0wo6EGx9JsJ9It8MYSXKBKRk+fj7xF9zicr7U+qVjofzNcMQmMCG256eFS8m g2Ejy4ywgtZIrn8laVEHLVyq1YkJfd+zJKUyfctNcK5QUD34An6/VUd3pAHXnJJMzOKp 1prHfzuSovxbBbL08olrX9WoAdqvrqKx+zBsJvNcFB5bpWSs8IX59B4M/VFGvU/XzhSV 1dE0U2c5/GNB/l8quYpIBZfVR2adZBfRl65lsCaNRq56sTypZWSEK6jeQVqpSpRYOl3J pNtVgGFIRn66bs1FpEkqzEx14PHzyTrJj5L0rhBwS/5XWt26Y3PESxgebKD9N60WoCuY 8HZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XZZvZqd2/XvPbZ+Yf9SpoSGRZyB8tNIve0skANFh1U0=; b=gkjKvEraInoANX7if6UTPT/8n/E3GLKwO1WSCvgAK8r3iAbOSNkvGsVF/fCUH1Z0lV UV+jumHJHgdnQmBOwTlRaxfmLzcBlDjtZYwlGGJXbGpBndcqM1Xqn74TgHBUDqU4N+HE nkpxC3cjAoJ3yBvokRc4IFWZMc7la3OFv3CrXbH7REdBRd1gnZK8x3dEUmCt+r0QcRC4 wMKi8C8BAYMJNdeQXT0Ev9InBNi7genwIQ0fzcriIgrMHqSOY2i7Cbt1qa+B5ExW0vDz JHPg79/8mo9P1hIs2FUhCbxyI2Fr9qQ70yUcFEDGYxvtIWw2/53bOHX9WNnGmufwKeo8 RC9A== X-Gm-Message-State: AD7BkJLuUXYqdRNCFWJotWAVNfs7nJRb9CXIgiTWWuf+tvMSWjn+zaN09JRZf4kCDwF1jaTi1s6WoPItk1O+JA== X-Received: by 10.55.195.16 with SMTP id a16mr36584369qkj.36.1456960203667; Wed, 02 Mar 2016 15:10:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.6.13 with HTTP; Wed, 2 Mar 2016 15:09:44 -0800 (PST) In-Reply-To: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D1A080.7050901@alvestrand.no> <56D55FE9.60408@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> From: Ted Hardie Date: Wed, 2 Mar 2016 15:09:44 -0800 Message-ID: To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a11479d86643fa1052d18fbd3 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 23:10:20 -0000 --001a11479d86643fa1052d18fbd3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 1, 2016 at 11:02 AM, Asveren, Tolga wrote: > =E2=80=9Cthat there will be a range imposed by browsers=E2=80=9D > > Why are we assuming this? There should be some justification for this > statement (and this is what I fail to see/understand but am really open t= o > good explanation for the need for this). The model I presented has a > =E2=80=9Cdefault value=E2=80=9D for browsers not an =E2=80=9Cenforced ran= ge=E2=80=9D. Those two are > different things. > > > We are assuming it because some of the browser vendors participating have said so. Other data would be, of course, welcome. Ted Thanks, > > Tolga > > > > *From:* Ted Hardie [mailto:ted.ietf@gmail.com] > *Sent:* Tuesday, March 01, 2016 1:58 PM > *To:* Asveren, Tolga > *Cc:* Roman Shpount ; Stefan H=C3=A5kansson LK < > stefan.lk.hakansson@ericsson.com>; Harald Alvestrand ; > rtcweb@ietf.org > *Subject:* Re: [rtcweb] Fwd: Last Call: > (WebRTC Audio Codec and Processing Requirements) to Proposed Standard > > > > Hi Tolga, > > > > On Tue, Mar 1, 2016 at 10:47 AM, Asveren, Tolga > wrote: > > > > ii- As another general principle, introducing a restriction without a goo= d > reason is a bad idea IMHO. So far, I yet have to see a good argument in > favor of an enforced range (other than that we should assume that > intelligence level of app. developer=E2=80=99s is equal to a chimpanzee) > > > > This is not a fair characterization of the point that has been made, and > I'd appreciate your being careful with your wording. The point that has > been made is that there will be a range imposed by browsers and that > standardizing that range avoids the complexity of discovery and/or random > failure modes. If you are arguing that there will be no enforced range a= t > all, then the browser makers' assertion to the contrary seems to be > problematic for accepting your argument. > > regards, > > Ted > > > --001a11479d86643fa1052d18fbd3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 1, 2016 at 11:02 AM, Asveren, Tolga <tas= veren@sonusnet.com> wrote:

=E2=80=9Cthat there will be a range imposed by brows= ers=E2=80=9D

Why are we assuming this? There shoul= d be some justification for this statement (and this is what I fail to see/= understand but am really open to good explanation for the need for this). The model I presented has a =E2=80=9Cdefault value= =E2=80=9D for browsers not an =E2=80=9Cenforced range=E2=80=9D. Those two a= re different things.

=C2=A0

<= /blockquote>
We are assuming it because some of the browser vendors par= ticipating have said so. Other data would be, of course, welcome.

Ted



Thanks,

Tolga=

=C2=A0

From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: Tuesday, March 01, 2016 1:58 PM
To: Asveren, Tolga <tasveren@sonusnet.com>
Cc: Roman Shpount <roman@telurix.com>; Stefan H=C3=A5kansson LK <stefan.lk.hakan= sson@ericsson.com>; Harald Alvestrand <harald@alvestrand.no>; rtcweb@ietf.org
Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10= .txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Stand= ard

=C2=A0

Hi Tolga,

=C2=A0

On Tue, Mar 1, 2016 at 10:47 AM, Asveren, Tolga <= tasveren@sonusne= t.com> wrote:

=C2=A0

ii- As another general principle, int= roducing a restriction without a good reason is a bad idea IMHO. So far, I yet have to see a good argument in favor of an enforced range (o= ther than that we should assume that intelligence level of app. developer= =E2=80=99s is equal to a chimpanzee)

=C2=A0

This is not a fair ch= aracterization of the point that has been made, and I'd appreciate your= being careful with your wording.=C2=A0 The point that has been made is tha= t there will be a range imposed by browsers and that standardizing that range avoids the complexity of discovery and/or ra= ndom failure modes.=C2=A0 If you are arguing that there will be no enforced= range at all, then the browser makers' assertion to the contrary seems= to be problematic for accepting your argument.

regards,

Ted

=C2=A0


--001a11479d86643fa1052d18fbd3-- From nobody Thu Mar 3 02:47:57 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476011A8991 for ; Thu, 3 Mar 2016 02:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001] autolearn=ham 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 GxNfBtPacRAW for ; Thu, 3 Mar 2016 02:47:51 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0633.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:633]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC7E1A8990 for ; Thu, 3 Mar 2016 02:47:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Tbw6sKhLM5mqmD/RGRbxQIdP/p5cSBmTQlO8uwzg+bM=; b=QaTsI0eSbgKpG6kUKxuRWpWunPD3sGTp0sHtFTXHxpZPsvI9t5HnB6q1MKH6GIdUa+J+qZgtGYSrscUM5jcj0CpFJmHh46DkF+QToCDHF9W+mHhpF/KRsHuq+tKBhN47j3mdbOXFjBldnZ5NWZE62HB4HMCvJbxPrZMY/Gsy4AI= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.409.15; Thu, 3 Mar 2016 10:47:33 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Thu, 3 Mar 2016 10:47:33 +0000 From: "Asveren, Tolga" To: Ted Hardie Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p9EeOUQgAB4VQCAAAJvQIAABQwAgAAAciCAAdggAIAAwScA Date: Thu, 3 Mar 2016 10:47:33 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D1A080.7050901@alvestrand.no> <56D55FE9.60408@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 718cd4f5-2efd-47ed-ea29-08d3435139fe x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:5DnegvW2lXdJvjZphYPbQs75XdJhBrdO33gMN9KvIM3OCciVnugajsWPr9DVhT3RbOhKDG0/vcfoeMkvVVqNOdCnS0xByjeCilfPPcqP5yDZ7z1qbWzACBPd2uBm67d7rwDnGhEcy04hzA5dxrHbuw==; 24:V5Zv6SC+MXzdtqiSGriaNyjdYQ0ZJpNozVJq8TvdxlxMmFQ2VSoHxuekyRS4rS4IvHgIeyMLesBc0fJA9S+zBhgtT0kZCjMbkqkBPUcl4PM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 0870212862 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(2473001)(377454003)(164054003)(33656002)(3846002)(3280700002)(6116002)(40100003)(19609705001)(790700001)(15975445007)(5004730100002)(19580395003)(66066001)(86362001)(1220700001)(2900100001)(74316001)(5008740100001)(5001960100004)(54356999)(2950100001)(4326007)(19580405001)(189998001)(586003)(11100500001)(5002640100001)(19300405004)(77096005)(50986999)(87936001)(106116001)(92566002)(2906002)(10400500002)(3660700001)(110136002)(19625215002)(5003600100002)(16236675004)(122556002)(93886004)(102836003)(230783001)(76176999)(76576001)(1096002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB15514DE72ED6C92766D32E80B2BD0SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2016 10:47:33.1447 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 10:47:55 -0000 --_000_SN1PR0301MB15514DE72ED6C92766D32E80B2BD0SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aS0gQnV0IGlzIOKAnFggdG9sZCBzb+KAnSByZWFsbHkgYSB0ZWNobmljYWwgYXJndW1lbnQgYW5k IHNob3VsZG7igJl0IHdlIGJhc2Ugb3VyIGRlY2lzaW9ucyBvbiB0ZWNobmljYWwgYXNwZWN0cz8g V2hhdCBJIGFtIHN1Z2dlc3RpbmcgKGJyb3dzZXJzIHN1cHBvcnRpbmcg4oCcZGVmYXVsdOKAnSB2 YWx1ZXMgaW5zdGVhZCBvZiDigJxlbmZvcmNlZCByYW5nZXPigJ0pIGhhcyB0aGUgdGVjaG5pY2Fs IG1lcml0cyB0aGF0IGl0IGJvdGggcHJvdmlkZXMgZmxleGliaWxpdHkgZm9yIGFwcGxpY2F0aW9u LCB3aGljaCBrbm93IHdoYXQgdGhleSBhcmUgZG9pbmcgYW5kIG5lZWQgdGhlIGZsZXhpYmlsaXR5 LCBhbmQgYXQgdGhlIHNhbWUgdGltZSBjb3ZlcnMgdGhlIGNhc2Ugb2Ygbm9uLXNhdnZ5IHVzZXJz Lg0KDQppaS0gUlRDV2ViIGlzIG5vdCBvbmx5IGFib3V0IGJyb3dzZXJzLiBUaGVyZSBhcmUgZ2F0 ZXdheXMgYW5kIG5hdGl2ZSBhcHBsaWNhdGlvbnMgYXMgd2VsbC4gUlRDV2ViIHNwZWNpZmljYXRp b25zIHNob3VsZCBjb3ZlciB1c2UgYnkgYWxsIHRoZXNlIHR5cGVzIG9mIGVudGl0aWVzIElNSE8u DQoNCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogVGVkIEhhcmRpZSBbbWFpbHRvOnRlZC5pZXRm QGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMDIsIDIwMTYgNjoxMCBQTQ0KVG86 IEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb20+DQpDYzogUm9tYW4gU2hwb3Vu dCA8cm9tYW5AdGVsdXJpeC5jb20+OyBTdGVmYW4gSMOla2Fuc3NvbiBMSyA8c3RlZmFuLmxrLmhh a2Fuc3NvbkBlcmljc3Nvbi5jb20+OyBIYXJhbGQgQWx2ZXN0cmFuZCA8aGFyYWxkQGFsdmVzdHJh bmQubm8+OyBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBGd2Q6IExhc3Qg Q2FsbDogPGRyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvLTEwLnR4dD4gKFdlYlJUQyBBdWRpbyBDb2Rl YyBhbmQgUHJvY2Vzc2luZyBSZXF1aXJlbWVudHMpIHRvIFByb3Bvc2VkIFN0YW5kYXJkDQoNCk9u IFR1ZSwgTWFyIDEsIDIwMTYgYXQgMTE6MDIgQU0sIEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBz b251c25ldC5jb208bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4+IHdyb3RlOg0K4oCcdGhh dCB0aGVyZSB3aWxsIGJlIGEgcmFuZ2UgaW1wb3NlZCBieSBicm93c2Vyc+KAnQ0KV2h5IGFyZSB3 ZSBhc3N1bWluZyB0aGlzPyBUaGVyZSBzaG91bGQgYmUgc29tZSBqdXN0aWZpY2F0aW9uIGZvciB0 aGlzIHN0YXRlbWVudCAoYW5kIHRoaXMgaXMgd2hhdCBJIGZhaWwgdG8gc2VlL3VuZGVyc3RhbmQg YnV0IGFtIHJlYWxseSBvcGVuIHRvIGdvb2QgZXhwbGFuYXRpb24gZm9yIHRoZSBuZWVkIGZvciB0 aGlzKS4gVGhlIG1vZGVsIEkgcHJlc2VudGVkIGhhcyBhIOKAnGRlZmF1bHQgdmFsdWXigJ0gZm9y IGJyb3dzZXJzIG5vdCBhbiDigJxlbmZvcmNlZCByYW5nZeKAnS4gVGhvc2UgdHdvIGFyZSBkaWZm ZXJlbnQgdGhpbmdzLg0KDQpXZSBhcmUgYXNzdW1pbmcgaXQgYmVjYXVzZSBzb21lIG9mIHRoZSBi cm93c2VyIHZlbmRvcnMgcGFydGljaXBhdGluZyBoYXZlIHNhaWQgc28uIE90aGVyIGRhdGEgd291 bGQgYmUsIG9mIGNvdXJzZSwgd2VsY29tZS4NClRlZA0KDQoNClRoYW5rcywNClRvbGdhDQoNCkZy b206IFRlZCBIYXJkaWUgW21haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnRlZC5pZXRm QGdtYWlsLmNvbT5dDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAwMSwgMjAxNiAxOjU4IFBNDQpUbzog QXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbTxtYWlsdG86dGFzdmVyZW5Ac29u dXNuZXQuY29tPj4NCkNjOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbTxtYWlsdG86 cm9tYW5AdGVsdXJpeC5jb20+PjsgU3RlZmFuIEjDpWthbnNzb24gTEsgPHN0ZWZhbi5say5oYWth bnNzb25AZXJpY3Nzb24uY29tPG1haWx0bzpzdGVmYW4ubGsuaGFrYW5zc29uQGVyaWNzc29uLmNv bT4+OyBIYXJhbGQgQWx2ZXN0cmFuZCA8aGFyYWxkQGFsdmVzdHJhbmQubm88bWFpbHRvOmhhcmFs ZEBhbHZlc3RyYW5kLm5vPj47IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIEZ3ZDogTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1ydGN3 ZWItYXVkaW8tMTAudHh0PiAoV2ViUlRDIEF1ZGlvIENvZGVjIGFuZCBQcm9jZXNzaW5nIFJlcXVp cmVtZW50cykgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCg0KSGkgVG9sZ2EsDQoNCk9uIFR1ZSwgTWFy IDEsIDIwMTYgYXQgMTA6NDcgQU0sIEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5j b208bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4+IHdyb3RlOg0KDQppaS0gQXMgYW5vdGhl ciBnZW5lcmFsIHByaW5jaXBsZSwgaW50cm9kdWNpbmcgYSByZXN0cmljdGlvbiB3aXRob3V0IGEg Z29vZCByZWFzb24gaXMgYSBiYWQgaWRlYSBJTUhPLiBTbyBmYXIsIEkgeWV0IGhhdmUgdG8gc2Vl IGEgZ29vZCBhcmd1bWVudCBpbiBmYXZvciBvZiBhbiBlbmZvcmNlZCByYW5nZSAob3RoZXIgdGhh biB0aGF0IHdlIHNob3VsZCBhc3N1bWUgdGhhdCBpbnRlbGxpZ2VuY2UgbGV2ZWwgb2YgYXBwLiBk ZXZlbG9wZXLigJlzIGlzIGVxdWFsIHRvIGEgY2hpbXBhbnplZSkNCg0KVGhpcyBpcyBub3QgYSBm YWlyIGNoYXJhY3Rlcml6YXRpb24gb2YgdGhlIHBvaW50IHRoYXQgaGFzIGJlZW4gbWFkZSwgYW5k IEknZCBhcHByZWNpYXRlIHlvdXIgYmVpbmcgY2FyZWZ1bCB3aXRoIHlvdXIgd29yZGluZy4gIFRo ZSBwb2ludCB0aGF0IGhhcyBiZWVuIG1hZGUgaXMgdGhhdCB0aGVyZSB3aWxsIGJlIGEgcmFuZ2Ug aW1wb3NlZCBieSBicm93c2VycyBhbmQgdGhhdCBzdGFuZGFyZGl6aW5nIHRoYXQgcmFuZ2UgYXZv aWRzIHRoZSBjb21wbGV4aXR5IG9mIGRpc2NvdmVyeSBhbmQvb3IgcmFuZG9tIGZhaWx1cmUgbW9k ZXMuICBJZiB5b3UgYXJlIGFyZ3VpbmcgdGhhdCB0aGVyZSB3aWxsIGJlIG5vIGVuZm9yY2VkIHJh bmdlIGF0IGFsbCwgdGhlbiB0aGUgYnJvd3NlciBtYWtlcnMnIGFzc2VydGlvbiB0byB0aGUgY29u dHJhcnkgc2VlbXMgdG8gYmUgcHJvYmxlbWF0aWMgZm9yIGFjY2VwdGluZyB5b3VyIGFyZ3VtZW50 Lg0KcmVnYXJkcywNClRlZA0KDQoNCg== --_000_SN1PR0301MB15514DE72ED6C92766D32E80B2BD0SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmktIEJ1dCBpcyDigJxYIHRvbGQgc2/igJ0g cmVhbGx5IGEgdGVjaG5pY2FsIGFyZ3VtZW50IGFuZCBzaG91bGRu4oCZdCB3ZSBiYXNlIG91ciBk ZWNpc2lvbnMgb24gdGVjaG5pY2FsIGFzcGVjdHM/IFdoYXQgSSBhbSBzdWdnZXN0aW5nIChicm93 c2VycyBzdXBwb3J0aW5nIOKAnGRlZmF1bHTigJ0NCiB2YWx1ZXMgaW5zdGVhZCBvZiDigJxlbmZv cmNlZCByYW5nZXPigJ0pIGhhcyB0aGUgdGVjaG5pY2FsIG1lcml0cyB0aGF0IGl0IGJvdGggcHJv dmlkZXMgZmxleGliaWxpdHkgZm9yIGFwcGxpY2F0aW9uLCB3aGljaCBrbm93IHdoYXQgdGhleSBh cmUgZG9pbmcgYW5kIG5lZWQgdGhlIGZsZXhpYmlsaXR5LCBhbmQgYXQgdGhlIHNhbWUgdGltZSBj b3ZlcnMgdGhlIGNhc2Ugb2Ygbm9uLXNhdnZ5IHVzZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+aWktIFJUQ1dlYiBpcyBub3Qgb25seSBhYm91dCBicm93c2Vy cy4gVGhlcmUgYXJlIGdhdGV3YXlzIGFuZCBuYXRpdmUgYXBwbGljYXRpb25zIGFzIHdlbGwuIFJU Q1dlYiBzcGVjaWZpY2F0aW9ucyBzaG91bGQgY292ZXIgdXNlIGJ5IGFsbCB0aGVzZSB0eXBlcyBv ZiBlbnRpdGllcw0KIElNSE8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5U b2xnYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IFRlZCBIYXJkaWUgW21haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb21dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXJjaCAwMiwgMjAxNiA2OjEwIFBNPGJyPg0K PGI+VG86PC9iPiBBc3ZlcmVuLCBUb2xnYSAmbHQ7dGFzdmVyZW5Ac29udXNuZXQuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gUm9tYW4gU2hwb3VudCAmbHQ7cm9tYW5AdGVsdXJpeC5jb20mZ3Q7OyBT dGVmYW4gSMOla2Fuc3NvbiBMSyAmbHQ7c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nvbi5jb20m Z3Q7OyBIYXJhbGQgQWx2ZXN0cmFuZCAmbHQ7aGFyYWxkQGFsdmVzdHJhbmQubm8mZ3Q7OyBydGN3 ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIEZ3ZDogTGFzdCBD YWxsOiAmbHQ7ZHJhZnQtaWV0Zi1ydGN3ZWItYXVkaW8tMTAudHh0Jmd0OyAoV2ViUlRDIEF1ZGlv IENvZGVjIGFuZCBQcm9jZXNzaW5nIFJlcXVpcmVtZW50cykgdG8gUHJvcG9zZWQgU3RhbmRhcmQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g VHVlLCBNYXIgMSwgMjAxNiBhdCAxMTowMiBBTSwgQXN2ZXJlbiwgVG9sZ2EgJmx0OzxhIGhyZWY9 Im1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20iIHRhcmdldD0iX2JsYW5rIj50YXN2ZXJlbkBz b251c25ldC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj7igJx0aGF0 IHRoZXJlIHdpbGwgYmUgYSByYW5nZSBpbXBvc2VkIGJ5IGJyb3dzZXJz4oCdPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZB Ij5XaHkgYXJlIHdlIGFzc3VtaW5nIHRoaXM/IFRoZXJlIHNob3VsZCBiZSBzb21lIGp1c3RpZmlj YXRpb24gZm9yIHRoaXMgc3RhdGVtZW50IChhbmQgdGhpcyBpcyB3aGF0IEkNCiBmYWlsIHRvIHNl ZS91bmRlcnN0YW5kIGJ1dCBhbSByZWFsbHkgb3BlbiB0byBnb29kIGV4cGxhbmF0aW9uIGZvciB0 aGUgbmVlZCBmb3IgdGhpcykuIFRoZSBtb2RlbCBJIHByZXNlbnRlZCBoYXMgYSDigJxkZWZhdWx0 IHZhbHVl4oCdIGZvciBicm93c2VycyBub3QgYW4g4oCcZW5mb3JjZWQgcmFuZ2XigJ0uIFRob3Nl IHR3byBhcmUgZGlmZmVyZW50IHRoaW5ncy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZBIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+V2UgYXJl IGFzc3VtaW5nIGl0IGJlY2F1c2Ugc29tZSBvZiB0aGUgYnJvd3NlciB2ZW5kb3JzIHBhcnRpY2lw YXRpbmcgaGF2ZSBzYWlkIHNvLiBPdGhlciBkYXRhIHdvdWxkIGJlLCBvZiBjb3Vyc2UsIHdlbGNv bWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U ZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0NDU0NkEiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZB Ij5Ub2xnYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBUZWQgSGFyZGllIFttYWlsdG86PGEgaHJlZj0ibWFpbHRv OnRlZC5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRlZC5pZXRmQGdtYWlsLmNvbTwv YT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWFyY2ggMDEsIDIwMTYgMTo1OCBQTTxi cj4NCjxiPlRvOjwvYj4gQXN2ZXJlbiwgVG9sZ2EgJmx0OzxhIGhyZWY9Im1haWx0bzp0YXN2ZXJl bkBzb251c25ldC5jb20iIHRhcmdldD0iX2JsYW5rIj50YXN2ZXJlbkBzb251c25ldC5jb208L2E+ Jmd0Ozxicj4NCjxiPkNjOjwvYj4gUm9tYW4gU2hwb3VudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJv bWFuQHRlbHVyaXguY29tIiB0YXJnZXQ9Il9ibGFuayI+cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0 OzsgU3RlZmFuIEjDpWthbnNzb24gTEsgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVmYW4ubGsuaGFr YW5zc29uQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZWZhbi5say5oYWthbnNzb25A ZXJpY3Nzb24uY29tPC9hPiZndDs7IEhhcmFsZCBBbHZlc3RyYW5kICZsdDs8YSBocmVmPSJtYWls dG86aGFyYWxkQGFsdmVzdHJhbmQubm8iIHRhcmdldD0iX2JsYW5rIj5oYXJhbGRAYWx2ZXN0cmFu ZC5ubzwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3 ZWJdIEZ3ZDogTGFzdCBDYWxsOiAmbHQ7ZHJhZnQtaWV0Zi1ydGN3ZWItYXVkaW8tMTAudHh0Jmd0 OyAoV2ViUlRDIEF1ZGlvIENvZGVjIGFuZCBQcm9jZXNzaW5nIFJlcXVpcmVtZW50cykgdG8gUHJv cG9zZWQgU3RhbmRhcmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkhpIFRvbGdhLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIE1hciAxLCAyMDE2IGF0IDEw OjQ3IEFNLCBBc3ZlcmVuLCBUb2xnYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVz bmV0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRhc3ZlcmVuQHNvbnVzbmV0LmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmlpLSBB cyBhbm90aGVyIGdlbmVyYWwgcHJpbmNpcGxlLCBpbnRyb2R1Y2luZyBhIHJlc3RyaWN0aW9uIHdp dGhvdXQgYSBnb29kIHJlYXNvbiBpcyBhIGJhZCBpZGVhIElNSE8uDQogU28gZmFyLCBJIHlldCBo YXZlIHRvIHNlZSBhIGdvb2QgYXJndW1lbnQgaW4gZmF2b3Igb2YgYW4gZW5mb3JjZWQgcmFuZ2Ug KG90aGVyIHRoYW4gdGhhdCB3ZSBzaG91bGQgYXNzdW1lIHRoYXQgaW50ZWxsaWdlbmNlIGxldmVs IG9mIGFwcC4gZGV2ZWxvcGVy4oCZcyBpcyBlcXVhbCB0byBhIGNoaW1wYW56ZWUpPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+VGhpcyBpcyBub3QgYSBmYWlyIGNoYXJhY3Rlcml6YXRpb24gb2YgdGhlIHBvaW50IHRoYXQg aGFzIGJlZW4gbWFkZSwgYW5kIEknZCBhcHByZWNpYXRlIHlvdXIgYmVpbmcgY2FyZWZ1bCB3aXRo IHlvdXIgd29yZGluZy4mbmJzcDsgVGhlIHBvaW50IHRoYXQgaGFzIGJlZW4gbWFkZSBpcyB0aGF0 IHRoZXJlIHdpbGwgYmUgYSByYW5nZQ0KIGltcG9zZWQgYnkgYnJvd3NlcnMgYW5kIHRoYXQgc3Rh bmRhcmRpemluZyB0aGF0IHJhbmdlIGF2b2lkcyB0aGUgY29tcGxleGl0eSBvZiBkaXNjb3Zlcnkg YW5kL29yIHJhbmRvbSBmYWlsdXJlIG1vZGVzLiZuYnNwOyBJZiB5b3UgYXJlIGFyZ3VpbmcgdGhh dCB0aGVyZSB3aWxsIGJlIG5vIGVuZm9yY2VkIHJhbmdlIGF0IGFsbCwgdGhlbiB0aGUgYnJvd3Nl ciBtYWtlcnMnIGFzc2VydGlvbiB0byB0aGUgY29udHJhcnkgc2VlbXMgdG8gYmUgcHJvYmxlbWF0 aWMNCiBmb3IgYWNjZXB0aW5nIHlvdXIgYXJndW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPnJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_SN1PR0301MB15514DE72ED6C92766D32E80B2BD0SN1PR0301MB1551_-- From nobody Thu Mar 3 03:49:25 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8761A90CA for ; Thu, 3 Mar 2016 03:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 clwOav0pt-hp for ; Thu, 3 Mar 2016 03:49:22 -0800 (PST) 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 C0C9F1A90C9 for ; Thu, 3 Mar 2016 03:49:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id A4ED27C79C2; Thu, 3 Mar 2016 12:49:19 +0100 (CET) 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 M8d85dT-a10J; Thu, 3 Mar 2016 12:49:19 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:39f3:54ad:a6bd:8883] (unknown [IPv6:2001:470:de0a:1:39f3:54ad:a6bd:8883]) by mork.alvestrand.no (Postfix) with ESMTPSA id C70047C79C0; Thu, 3 Mar 2016 12:49:18 +0100 (CET) To: "Asveren, Tolga" , Ted Hardie References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D55FE9.60408@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> From: Harald Alvestrand Message-ID: <56D824BD.2080305@alvestrand.no> Date: Thu, 3 Mar 2016 12:49:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 11:49:24 -0000 Den 03. mars 2016 11:47, skrev Asveren, Tolga: > i- But is “X told so” really a technical argument and shouldn’t we base > our decisions on technical aspects? What I am suggesting (browsers > supporting “default” values instead of “enforced ranges”) has the > technical merits that it both provides flexibility for application, > which know what they are doing and need the flexibility, and at the same > time covers the case of non-savvy users. You've made this argument before. I cannot see that anything new has been brought to the table that is likely to alter the WEBRTC WG consensus to have these enforced limits. > ii- RTCWeb is not only about browsers. There are gateways and native > applications as well. RTCWeb specifications should cover use by all > these types of entities IMHO. The API is about a Javascript interface, and it is the remit of the W3C WEBRTC WG. You're on the wrong list. From nobody Thu Mar 3 08:06:17 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309491A1DBE for ; Thu, 3 Mar 2016 08:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 tJ03nna8toy6 for ; Thu, 3 Mar 2016 08:06:08 -0800 (PST) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A07161A1E0B for ; Thu, 3 Mar 2016 08:06:08 -0800 (PST) Received: by mail-ig0-x22d.google.com with SMTP id y8so22823837igp.0 for ; Thu, 03 Mar 2016 08:06:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=NxyjeRDmWaQnIIXvG0EHABb2j5SnqsGUYxQJDEPzKKA=; b=zYDBztlR+dS3wtaBcjqGxnWxeS5X7kCi0bpgiDBe3lz8uwneDKBr+dXSUBmIiHeyyl KlEx629XeLGzoqv2Qh57yUdAQHGXmluFtQptl62rQpKRhroyRTWQJGznJUXid0JVHbqI yWaWtVWNQBz6maqKiMfKSsqUG7beGxT12BFZpfnkUP7u7EQTcVec675ithZ+baxyHeJx //9l5DiRhR4CZOffuxhhB+YrOxOU7a1w/eMKPJjoRZ5TyR6cF7ZiS1P+vsVHewFZ/CEi sBunzjOGeIYcI+/aAfOcRN1PBRGiYzWGZfiQICsSsybF+Lb4MC/CgWvssLiVSHcIUHIk IY7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=NxyjeRDmWaQnIIXvG0EHABb2j5SnqsGUYxQJDEPzKKA=; b=fDhslJpzdhVzyYkJzPh4c9CrXeufzZEmrYYTmbUu6UR9iTN0amscLpvLu1lBiga+eW vFHINaH/ovrOL6Pkdl6BnXk53V90oXCn/SQb5Jtcb1REqoZkoD1R5RVwmG6OpRVWZbxd Q5sc0Vb2IHeAjwwKwEwImvQkuPHRrCvwBhZNra06jywaAqf1Yk7FVmyAfpapm5Nx6sMv N2PK1PohcYoU5otgVd8KczXzQ/NxDyaN9HWj90gWG58Qxm4DkpCN6jPNUgRnAJXC4FaL pXVSYs2PplG/eEJTHloNiuSoCthVGyZ1i5KFGy5CsFhNQ/NHaPioR3hnl1mPsWpLhsSH M62Q== X-Gm-Message-State: AD7BkJI07z1pGLKOFXBeZe6DVJp6EwzfN3CUcNdZp+AutL7246WiX+bHGl29MlcohrxypQ== X-Received: by 10.50.178.180 with SMTP id cz20mr6183039igc.44.1457021168067; Thu, 03 Mar 2016 08:06:08 -0800 (PST) Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com. [209.85.213.180]) by smtp.gmail.com with ESMTPSA id n5sm3785927iga.15.2016.03.03.08.06.06 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Mar 2016 08:06:06 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id g6so22848573igt.1 for ; Thu, 03 Mar 2016 08:06:06 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.30.104 with SMTP id r8mr6532850igh.2.1457021165958; Thu, 03 Mar 2016 08:06:05 -0800 (PST) Received: by 10.36.105.77 with HTTP; Thu, 3 Mar 2016 08:06:05 -0800 (PST) In-Reply-To: <56D824BD.2080305@alvestrand.no> References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D55FE9.60408@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> <56D824BD.2080305@alvestrand.no> Date: Thu, 3 Mar 2016 11:06:05 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=047d7bdca2ec070570052d272dcc Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 16:06:15 -0000 --047d7bdca2ec070570052d272dcc Content-Type: text/plain; charset=UTF-8 On Thu, Mar 3, 2016 at 6:49 AM, Harald Alvestrand wrote: > You've made this argument before. I cannot see that anything new has > been brought to the table that is likely to alter the WEBRTC WG > consensus to have these enforced limits. > Am I correct to understand that WEBRTC WG decided that there should be limits on DTMF tone generation and it is up to this group (IETF rtcweb) to decide the exact values of these limits? In this case, as I have stated before, the maximum tone duration should be 8000 ms to match possible tone duration for RFC 2833 DTMF tone. RFC 2833 was in use for the past 15 years and no one reported any issues with this limit. Minimum tone duration of 40 ms and minimum gap duration of 30 ms are minimum physically required to transmit DTMF tone as 8 KHz audio signal and still satisfy the talk-off specifications. These limitations have not caused any practical issues for the past 50 years. I would like to mention that shorter tones are used during call setup since it can be guaranteed that no audio signal is present and talk-off requirements are relaxed. Furthermore VoIP only networks, which use RFC 2833/RFC 4733 tones, can support tones and gaps of anything from 0 ms and up. This is why I initially advocated for 0 ms min duration. On the other hand if the group decides that removing one more potential foot gun is more important, I will not be too upset. If anybody can come up with the practical example where tones longer then 8 sec or shorter then 40 ms with less then 30 ms gaps are used, please report them to the list. Otherwise, let's document what is in W3C TR and move on. Regards, _____________ Roman Shpount --047d7bdca2ec070570052d272dcc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 3, 2016 at 6:49 AM, Harald Alvestrand &l= t;harald@alvestra= nd.no> wrote:
You've made this argument before. I cannot see that anythin= g new has
been brought to the table that is likely to alter the WEBRTC WG
consensus to have these enforced limits.

Am I correct to understand that WEBRTC WG decided that there should be li= mits on DTMF tone generation and it is up to this group (IETF rtcweb) to de= cide the exact values of these limits?

In this cas= e, as I have stated before, the maximum tone duration should be 8000 ms to = match possible tone duration for RFC 2833 DTMF tone. RFC 2833 was in use fo= r the past 15 years and no one reported any issues with this limit.

Minimum tone duration of 40 ms and minimum gap duration o= f 30 ms are minimum physically required to transmit DTMF tone as 8 KHz audi= o signal and still satisfy the talk-off specifications. These limitations h= ave not caused any practical issues for the past 50 years. I would like to = mention that shorter tones are used during call setup since it can be guara= nteed that no audio signal is present and talk-off requirements are relaxed= . Furthermore VoIP only networks, which use RFC 2833/RFC 4733 tones, can su= pport tones and gaps of anything from 0 ms and up. This is why I initially = advocated for 0 ms min duration. On the other hand if the group decides tha= t removing one more potential foot gun is more important, I will not be too= upset.

If anybody can come up with the practical = example where tones longer then 8 sec or shorter then 40 ms with less then = 30 ms gaps are used, please report them to the list. Otherwise, let's d= ocument what is in W3C TR and move on.

Regards,
_____________
Roman Shpount
=
=C2=A0
--047d7bdca2ec070570052d272dcc-- From nobody Thu Mar 3 08:46:04 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762241A8771 for ; Thu, 3 Mar 2016 08:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 iRZ9ZhyYam4W for ; Thu, 3 Mar 2016 08:46:01 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFBA81A6FAC for ; Thu, 3 Mar 2016 08:46:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 21F1C7C79D8; Thu, 3 Mar 2016 17:45:59 +0100 (CET) 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 J-7LD8lkvKYi; Thu, 3 Mar 2016 17:45:58 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:f587:762f:126a:a806] (unknown [IPv6:2001:470:de0a:1:f587:762f:126a:a806]) by mork.alvestrand.no (Postfix) with ESMTPSA id 2288D7C79D7; Thu, 3 Mar 2016 17:45:58 +0100 (CET) To: Roman Shpount References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D55FE9.60408@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> <56D824BD.2080305@alvestrand.no> From: Harald Alvestrand Message-ID: <56D86A45.70406@alvestrand.no> Date: Thu, 3 Mar 2016 17:45:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 16:46:03 -0000 Den 03. mars 2016 17:06, skrev Roman Shpount: > On Thu, Mar 3, 2016 at 6:49 AM, Harald Alvestrand > wrote: > > You've made this argument before. I cannot see that anything new has > been brought to the table that is likely to alter the WEBRTC WG > consensus to have these enforced limits. > > > Am I correct to understand that WEBRTC WG decided that there should be > limits on DTMF tone generation and it is up to this group (IETF rtcweb) > to decide the exact values of these limits? Formally, the RTCWEB group can advise the WEBRTC group about appropriate values, but in practice, the result is indistinguishable from your formulation :-) > In this case, as I have stated before, the maximum tone duration should > be 8000 ms to match possible tone duration for RFC 2833 DTMF tone. RFC > 2833 was in use for the past 15 years and no one reported any issues > with this limit. > > Minimum tone duration of 40 ms and minimum gap duration of 30 ms are > minimum physically required to transmit DTMF tone as 8 KHz audio signal > and still satisfy the talk-off specifications. These limitations have > not caused any practical issues for the past 50 years. I would like to > mention that shorter tones are used during call setup since it can be > guaranteed that no audio signal is present and talk-off requirements are > relaxed. Furthermore VoIP only networks, which use RFC 2833/RFC 4733 > tones, can support tones and gaps of anything from 0 ms and up. This is > why I initially advocated for 0 ms min duration. On the other hand if > the group decides that removing one more potential foot gun is more > important, I will not be too upset. > > If anybody can come up with the practical example where tones longer > then 8 sec or shorter then 40 ms with less then 30 ms gaps are used, > please report them to the list. Otherwise, let's document what is in W3C > TR and move on. Sounds good. From nobody Fri Mar 4 02:08:08 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD451B35F3 for ; Fri, 4 Mar 2016 02:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.909 X-Spam-Level: X-Spam-Status: No, score=0.909 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=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 8o0WARuQYWSi for ; Fri, 4 Mar 2016 02:08:06 -0800 (PST) Received: from qproxy4-pub.mail.unifiedlayer.com (qproxy4-pub.mail.unifiedlayer.com [66.147.248.250]) by ietfa.amsl.com (Postfix) with SMTP id 6CFDE1B35F2 for ; Fri, 4 Mar 2016 02:08:06 -0800 (PST) Received: (qmail 30798 invoked by uid 0); 4 Mar 2016 10:08:04 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy4.mail.unifiedlayer.com with SMTP; 4 Mar 2016 10:08:04 -0000 Received: from box817.bluehost.com ([66.147.244.117]) by cmgw4 with id Rlnv1s00J2Yhrsa01lny16; Fri, 04 Mar 2016 02:48:04 -0700 X-Authority-Analysis: v=2.1 cv=FouWoQbq c=1 sm=1 tr=0 a=1ZWhLoquM75l/9xp6o4QLQ==:117 a=1ZWhLoquM75l/9xp6o4QLQ==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=MKtGQD3n3ToA:10 a=1oJP67jkp3AA:10 a=ZZnuYtJkoWoA:10 a=6U2dO19vvw8A:10 a=JMHYQVG13d8A:10 a=7OsogOcEt9IA:10 a=NTO0sfoHHJwA:10 a=N1z6yVdWAAAA:8 a=L_2qeYhXd2xazlJCLXoA:9 a=CjuIK1q_8ugA:10 a=LomR_4PctdkA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sdiwc.info; s=default; h=Message-ID:Subject:To:From:Date:Content-Transfer-Encoding: Content-Type:MIME-Version; bh=7+cmpBwbzeeBXVMSYSXVIwD00LV2MJOkSfA+rb+l5EE=; b=s9G8VCtxX9xtC1fvzjL51J5BooVr5vo/met2/A4W23/CtuQUSBJw3AeMGf2Bg48l4bct2hMTl5 NUsH6AEKC9gcJ+yaMaAbQ+IJVbc1wRkY8KqATx97E7gP9atLmGL/W+; Received: from [127.0.0.1] (port=33942 helo=box817.bluehost.com) by box817.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1abmKx-0000Of-Gr for rtcweb@ietf.org; Fri, 04 Mar 2016 02:47:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 04 Mar 2016 02:47:53 -0700 From: Jackie Blanco To: rtcweb@ietf.org Message-ID: <078740c5b72c6e641fd54a31b6e45091@sdiwc.info> X-Sender: jackie@sdiwc.info User-Agent: Roundcube Webmail/1.0.6 X-Identified-User: {1337:box817.bluehost.com:sdiwcnet:sdiwc.info} {sentby:smtp auth 127.0.0.1 authed with jackie@sdiwc.info} Archived-At: Subject: [rtcweb] Third CSCESM2016 - Computer Science, Computer Engineering, and Social Media - Greece X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 10:08:07 -0000 The Third International Conference on Computer Science, Computer Engineering, and Social Media (CSCESM2016) Metropolitan College, Thessaloniki, Greece May 13-15, 2016 http://www.sdiwc.net/conferences/cscesm2016/ cscesm16@sdiwc.net The published proceedings will be submitted for indexing in ResearchBib, ProQuest, ResearchGate, Academia and Google Scholar Databases. In addition, they will be reviewed for possible inclusion within the INSPEC, EI, DBLP, and Microsoft Academic Research Databases. BEST registered papers will be published in one of the following special issues provided that the author do major improvements and extension within the time frame that will be set by the conference and his/her paper is approved by the chief editor: - International Journal of New Computer Architectures and their Applications (IJNCAA); EISSN 2220-9085, ISSN 2412-3587 - International Journal of Cyber-Security and Digital Forensics (IJCSDF); EISSN 2225-658X, ISSN 2412-6551 - International Journal of Digital Information and Wireless Communications (IJDIWC); EISSN 2305-0012 - International Journal of New Computer Architectures and their Applications (IJNCAA); EISSN 2410-0439 The conference welcomes papers on the following (but not limited to) research topics: *Computer Science Access Controls Biometrics Technologies Computer Forensics Computer Security Data Mining Cryptography and Data Protection E-Learning Network Security Wireless Communications *Computer Engineering Computer Architecture Computer-aided Design Computer Networks Multimedia Applications Network Security and Cryptography Computer Animation Expert Systems *Social Media Image / multimedia processing Human-computer interaction Social networking sites Social innovation and effecting change Collaborative filtering Social networks and online education Researchers are encouraged to submit their work electronically. All papers will be fully refereed by a minimum of two specialized referees. Before final acceptance, all referees comments must be considered. Important Dates =============== Submission Deadline April 13, 2016 Acceptance Notification 2-4 weeks from the date of submission Final Notification April 23, 2016 Camera Ready Deadline May 3, 2016 Registration Deadline May 3, 2016 Conference Dates May 13-15, 2016 From nobody Fri Mar 4 02:34:42 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9581B362F for ; Fri, 4 Mar 2016 02:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham 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 VKOLUqD9NMQL for ; Fri, 4 Mar 2016 02:34:39 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0620.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:620]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D726B1B3633 for ; Fri, 4 Mar 2016 02:34:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=faSsWEE7+iyfMEqevOe6c7GFteT45yY2lCegg+VHNy0=; b=tOUGQ4c4p57J6w4/KLOxzEjN5z+9/cQegKiq21ZUARKX3RQxQfgPA4VuQZeWXbxMv7Wgd2t2v6xi48ndGkmOkjb1nvtWOlEAet1M/BupvQVQaZ72+StShVqTUEOgw0ZLBEplXUnZQtmz1uNhy+jlKcfj6eB2XnG1ak51zMupAlc= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1552.namprd03.prod.outlook.com (10.162.129.158) with Microsoft SMTP Server (TLS) id 15.1.427.16; Fri, 4 Mar 2016 10:34:10 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Fri, 4 Mar 2016 10:34:11 +0000 From: "Asveren, Tolga" To: Harald Alvestrand , Roman Shpount Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p9EeOUQgAB4VQCAAAJvQIAABQwAgAAAciCAAdggAIAAwScAgAATEICAAEfAgIAACySAgAEinnA= Date: Fri, 4 Mar 2016 10:34:10 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D55FE9.60408@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> <56D824BD.2080305@alvestrand.no> <56D86A45.70406@alvestrand.no> In-Reply-To: <56D86A45.70406@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alvestrand.no; dkim=none (message not signed) header.d=none; alvestrand.no; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 6840161c-e4be-4a20-9e41-08d344188642 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1552; 5:H1lWOX37ncRGORgxKkD/uDTzUp9tOH/d49XiG+pTYkRoFe7Of8EmY2t5eBmpBH03JNzq1n2cJ3HqB2ZZmjfAolrWJDncxwx2qNlgRGy8zdfxCNxa3Lxobzo2joEhjDG091+7+vDZZvXeNj/6aq/tMA==; 24:P7x1MuVzNqVfBcantXbDQY6HQ0MSM62DUC8pBt1oajWKmQ7jNZaE66Z/RMmfgVDH1lXzWqPUZF2WdxmG2Qov9sTLQPjmABd8TVAl7he7GDI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1552; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR0301MB1552; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1552; x-forefront-prvs: 0871917CDA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(2473001)(24454002)(164054003)(377454003)(13464003)(86362001)(5001770100001)(1220700001)(230783001)(93886004)(40100003)(1096002)(5003600100002)(50986999)(586003)(189998001)(74316001)(76576001)(81166005)(4326007)(3660700001)(99286002)(19580395003)(102836003)(2906002)(5008740100001)(92566002)(3846002)(3280700002)(6116002)(33656002)(106116001)(10400500002)(19580405001)(2900100001)(5004730100002)(66066001)(122556002)(2950100001)(54356999)(77096005)(76176999)(87936001)(5002640100001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1552; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2016 10:34:10.9444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1552 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 10:34:42 -0000 aS0gSSBkb24ndCB0aGluayBzYXRpc2ZhY3RvcnkgdGVjaG5pY2FsIGV4cGxhbmF0aW9uIGlzIHBy b3ZpZGVkIHdoeSAiZW5mb3JjaW5nIGEgcmFuZ2UiIGlzIHN1cGVyaW9yIHRvIGEgImRlZmF1bHQg cmFuZ2UiLiBJIHdpbGwgbGVhdmUgdGhpcyBoZXJlIGFuZCBvYnZpb3VzbHkgdGhpcyBpcyBqdXN0 IG15IHBlcnNvbmFsIC1idXQgaG9uZXN0LSBvcGluaW9uLg0KDQppaS0gSSBnb3QgY29uZnVzZWQg YWJvdXQgd2hhdCBXRUJSVEMgV0cgcmVmZXJzIHRvLCBtYXliZSB0byBXM0M/IElmIHNvLCBpcyBy dGN3ZWItYXVkaW8gc3BlY2lmaWNhdGlvbiBvbmx5IGFib3V0IGJyb3dzZXJzPyBJIHdvdWxkbuKA mXQgdGhpbmsgc28uIFRoZXJlIGFyZSBvdGhlciB0eXBlcyBvZiBlbnRpdGllcyBwbGF5aW5nIGlu IHRoZSBSVENXZWIgZG9tYWluLCBlLmcuIGdhdGV3YXlzLiBUaGUgbGltaXRzIHdlIGFyZSB0YWxr aW5nIGFib3V0LCBhcmUgdGhleSBhcHBsaWNhYmxlIG9ubHkgZm9yIGRpZ2l0cyBzZW50IGJ5IGJy b3dzZXJzPyBXaGF0IGFib3V0IGRpZ2l0cyBlbWl0dGVkIGJ5IGEgbmF0aXZlIGFwcGxpY2F0aW9u IG9yIGEgZ2F0ZXdheT8gV2lsbCBhIGJyb3dzZXIgYmUgYWJsZSB0byBhY2NlcHQgdGhlbSBpZiB0 aGV5IGFyZSBvdXQgb2YgdGhlIHJhbmdlIChhc3N1bWluZyB0aGF0IHRoZSBmaW5hbCBvdXRjb21l IGlzIHRvIHVzZSBlbmZvcmNlZCByYW5nZXMpPw0KDQppaWktIEp1c3QgYXMgYW4gZXhhbXBsZSwg SSBhbSBhd2FyZSBvZiBzeXN0ZW1zLCB3aGljaCBjYW4gZGV0ZWN0IGRpZ2l0cyA8NDBtcy4NCg0K aXYtIFdoYXQgYWJvdXQgdGhlIGdhcCBiZXR3ZWVuIHRoZSBmaW5hbCBwYWNrZXQgKHdpdGggRS1i aXQgc2V0KSByZXRyYW5zbWlzc2lvbnM/IA0KDQp2LSBBcyB1c2UgY2FzZXMgZm9yIHRoZSBuZWVk IGZvciBsb25nZXIgZHVyYXRpb24gKGFsbCB0aGVzZSBhcmUgYmFzZWQgb24gdGhlIHNhbWUgZGVw bG95bWVudCBtb2RlbDogQSAibGVnYWN5IiBhcHBsaWNhdGlvbiBjb250cm9sbGVkIGJ5IHBob25l IG5lZWRzIHRvIGJlIGV4dGVuZGVkIHNvIHRoYXQgaXQgY2FuIGJlIGFjY2Vzc2VkIGJ5IEludGVy bmV0IGNvbm5lY3RlZCBkZXZpY2VzLCBlLmcuIGEgd2ViLWJvb2suIERhdGFDaGFubmVsIGlzIG5v dCB1c2VkLCBlLmcuIG5vdCBzdXBwb3J0ZWQgYnkgZ2F0ZXdheSwgYnkgYXBwbGljYXRpb24gZXRj Li4uLCBoZW5jZSBkaWdpdHMgYXJlIHVzZWQgZm9yIGNvbnRyb2wuDQoNCi0gVFYgZ2FtaW5nIHNo b3cNClVzZXIgcmVnaXN0ZXJzIGZvciB0aGUgZ2FtZSBhbmQgaXMgc2VsZWN0ZWQgZm9yIHRoYXQg ZGF5J3Mgc2hvdy4NClRoZSB1c2VyIHNlZXMgd2hhdCBpcyBoYXBwZW5pbmcgb24gdGhlIGdhbWUg b24gaGlzIFRWIGFuZCBjb250cm9scyBpdCBieSBkaWdpdHMNClRoZSBnYW1lIChiYWxsb29uIGVz Y2FwZSkgcmVxdWlyZXMgdGhhdCBhdCB0aGUgYmVnaW5uaW5nIHRoZSB1c2VyIHB1bXBzIGFpciBp bnRvIHRoZSBiYWxsb29uLiBUaGlzIGlzIGRvbmUgYnkgY29udGludW91c2x5IHByZXNzaW5nICI1 Ig0KDQotIFJlbW90ZSB2YWx2ZS9kb29yL2xvY2sgY29udHJvbA0KQXV0aG9yaXplZCBwZXJzb24g bWFrZXMgYSBjYWxsIGFuZCB0aGVuIGNvbnRpbnVvdXNseSBwcmVzc2VzICI2IiB0byBrZWVwIHRo ZSB2YWx2ZS9kb29yL2xvY2sgb3BlbiBmb3IgdGhhdCBwZXJpb2QuDQoNCi0gUGFuaWMgYnV0dG9u DQpBbiBhcHBsaWNhdGlvbiBmb3Igd29tZW4gd2hvIGFyZSBtaXN0cmVhdGVkIGJ5IHRoZWlyIGh1 c2JhbmRzLiBQb2xpY2UvU29jaWFsIHNlcnZpY2Ugd29ya2VycyBydXNoIHRvIHRoZSByZWdpc3Rl cmVkIGFkZHJlc3MgaWYgc2hlIHByZXNzZXMgIjciIGNvbnRpbnVvdXNseSBmb3IgbG9uZ2VyIHRo YW4gMTAgc2Vjb25kcy4NCg0KSSBhbSBqdXN0IHRyeWluZyB0byBzaG93IHRoYXQgdGhlcmUgYXJl IG1hbnkgZGlmZmVyZW50L2ltYWdpbmF0aXZlIHdheXMgdXNpbmcgdGhlICJkaWdpdCBVSSIuDQoN Cg0KVGhhbmtzLA0KVG9sZ2ENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBIYXJhbGQgQWx2ZXN0cmFuZCBbbWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vXQ0KPiBTZW50 OiBUaHVyc2RheSwgTWFyY2ggMDMsIDIwMTYgMTE6NDYgQU0NCj4gVG86IFJvbWFuIFNocG91bnQg PHJvbWFuQHRlbHVyaXguY29tPg0KPiBDYzogQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVz bmV0LmNvbT47IFRlZCBIYXJkaWUNCj4gPHRlZC5pZXRmQGdtYWlsLmNvbT47IFN0ZWZhbiBIw6Vr YW5zc29uIExLDQo+IDxzdGVmYW4ubGsuaGFrYW5zc29uQGVyaWNzc29uLmNvbT47IHJ0Y3dlYkBp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3J0Y3dlYl0gRndkOiBMYXN0IENhbGw6IDxkcmFmdC1p ZXRmLXJ0Y3dlYi1hdWRpby0xMC50eHQ+DQo+IChXZWJSVEMgQXVkaW8gQ29kZWMgYW5kIFByb2Nl c3NpbmcgUmVxdWlyZW1lbnRzKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiANCj4gRGVuIDAzLiBt YXJzIDIwMTYgMTc6MDYsIHNrcmV2IFJvbWFuIFNocG91bnQ6DQo+ID4gT24gVGh1LCBNYXIgMywg MjAxNiBhdCA2OjQ5IEFNLCBIYXJhbGQgQWx2ZXN0cmFuZA0KPiA+IDxoYXJhbGRAYWx2ZXN0cmFu ZC5ubyA8bWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vPj4gd3JvdGU6DQo+ID4NCj4gPiAgICAg WW91J3ZlIG1hZGUgdGhpcyBhcmd1bWVudCBiZWZvcmUuIEkgY2Fubm90IHNlZSB0aGF0IGFueXRo aW5nIG5ldyBoYXMNCj4gPiAgICAgYmVlbiBicm91Z2h0IHRvIHRoZSB0YWJsZSB0aGF0IGlzIGxp a2VseSB0byBhbHRlciB0aGUgV0VCUlRDIFdHDQo+ID4gICAgIGNvbnNlbnN1cyB0byBoYXZlIHRo ZXNlIGVuZm9yY2VkIGxpbWl0cy4NCj4gPg0KPiA+DQo+ID4gQW0gSSBjb3JyZWN0IHRvIHVuZGVy c3RhbmQgdGhhdCBXRUJSVEMgV0cgZGVjaWRlZCB0aGF0IHRoZXJlIHNob3VsZCBiZQ0KPiA+IGxp bWl0cyBvbiBEVE1GIHRvbmUgZ2VuZXJhdGlvbiBhbmQgaXQgaXMgdXAgdG8gdGhpcyBncm91cCAo SUVURg0KPiA+IHJ0Y3dlYikgdG8gZGVjaWRlIHRoZSBleGFjdCB2YWx1ZXMgb2YgdGhlc2UgbGlt aXRzPw0KPiANCj4gRm9ybWFsbHksIHRoZSBSVENXRUIgZ3JvdXAgY2FuIGFkdmlzZSB0aGUgV0VC UlRDIGdyb3VwIGFib3V0IGFwcHJvcHJpYXRlDQo+IHZhbHVlcywgYnV0IGluIHByYWN0aWNlLCB0 aGUgcmVzdWx0IGlzIGluZGlzdGluZ3Vpc2hhYmxlIGZyb20geW91ciBmb3JtdWxhdGlvbiA6LQ0K PiApDQo+IA0KPiA+IEluIHRoaXMgY2FzZSwgYXMgSSBoYXZlIHN0YXRlZCBiZWZvcmUsIHRoZSBt YXhpbXVtIHRvbmUgZHVyYXRpb24NCj4gPiBzaG91bGQgYmUgODAwMCBtcyB0byBtYXRjaCBwb3Nz aWJsZSB0b25lIGR1cmF0aW9uIGZvciBSRkMgMjgzMyBEVE1GDQo+ID4gdG9uZS4gUkZDDQo+ID4g MjgzMyB3YXMgaW4gdXNlIGZvciB0aGUgcGFzdCAxNSB5ZWFycyBhbmQgbm8gb25lIHJlcG9ydGVk IGFueSBpc3N1ZXMNCj4gPiB3aXRoIHRoaXMgbGltaXQuDQo+ID4NCj4gPiBNaW5pbXVtIHRvbmUg ZHVyYXRpb24gb2YgNDAgbXMgYW5kIG1pbmltdW0gZ2FwIGR1cmF0aW9uIG9mIDMwIG1zIGFyZQ0K PiA+IG1pbmltdW0gcGh5c2ljYWxseSByZXF1aXJlZCB0byB0cmFuc21pdCBEVE1GIHRvbmUgYXMg OCBLSHogYXVkaW8NCj4gPiBzaWduYWwgYW5kIHN0aWxsIHNhdGlzZnkgdGhlIHRhbGstb2ZmIHNw ZWNpZmljYXRpb25zLiBUaGVzZQ0KPiA+IGxpbWl0YXRpb25zIGhhdmUgbm90IGNhdXNlZCBhbnkg cHJhY3RpY2FsIGlzc3VlcyBmb3IgdGhlIHBhc3QgNTANCj4gPiB5ZWFycy4gSSB3b3VsZCBsaWtl IHRvIG1lbnRpb24gdGhhdCBzaG9ydGVyIHRvbmVzIGFyZSB1c2VkIGR1cmluZyBjYWxsDQo+ID4g c2V0dXAgc2luY2UgaXQgY2FuIGJlIGd1YXJhbnRlZWQgdGhhdCBubyBhdWRpbyBzaWduYWwgaXMg cHJlc2VudCBhbmQNCj4gPiB0YWxrLW9mZiByZXF1aXJlbWVudHMgYXJlIHJlbGF4ZWQuIEZ1cnRo ZXJtb3JlIFZvSVAgb25seSBuZXR3b3JrcywNCj4gPiB3aGljaCB1c2UgUkZDIDI4MzMvUkZDIDQ3 MzMgdG9uZXMsIGNhbiBzdXBwb3J0IHRvbmVzIGFuZCBnYXBzIG9mDQo+ID4gYW55dGhpbmcgZnJv bSAwIG1zIGFuZCB1cC4gVGhpcyBpcyB3aHkgSSBpbml0aWFsbHkgYWR2b2NhdGVkIGZvciAwIG1z DQo+ID4gbWluIGR1cmF0aW9uLiBPbiB0aGUgb3RoZXIgaGFuZCBpZiB0aGUgZ3JvdXAgZGVjaWRl cyB0aGF0IHJlbW92aW5nIG9uZQ0KPiA+IG1vcmUgcG90ZW50aWFsIGZvb3QgZ3VuIGlzIG1vcmUg aW1wb3J0YW50LCBJIHdpbGwgbm90IGJlIHRvbyB1cHNldC4NCj4gPg0KPiA+IElmIGFueWJvZHkg Y2FuIGNvbWUgdXAgd2l0aCB0aGUgcHJhY3RpY2FsIGV4YW1wbGUgd2hlcmUgdG9uZXMgbG9uZ2Vy DQo+ID4gdGhlbiA4IHNlYyBvciBzaG9ydGVyIHRoZW4gNDAgbXMgd2l0aCBsZXNzIHRoZW4gMzAg bXMgZ2FwcyBhcmUgdXNlZCwNCj4gPiBwbGVhc2UgcmVwb3J0IHRoZW0gdG8gdGhlIGxpc3QuIE90 aGVyd2lzZSwgbGV0J3MgZG9jdW1lbnQgd2hhdCBpcyBpbg0KPiA+IFczQyBUUiBhbmQgbW92ZSBv bi4NCj4gDQo+IFNvdW5kcyBnb29kLg0K From nobody Fri Mar 4 02:46:45 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16B01B3658 for ; Fri, 4 Mar 2016 02:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.206 X-Spam-Level: X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006] autolearn=ham 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 oAqVwna87qbm for ; Fri, 4 Mar 2016 02:46:40 -0800 (PST) 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 35EFB1A8785 for ; Fri, 4 Mar 2016 02:46:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id A7F8F7C79A8; Fri, 4 Mar 2016 11:46:38 +0100 (CET) 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 RtZW5bfqtd6I; Fri, 4 Mar 2016 11:46:37 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:f587:762f:126a:a806] (unknown [IPv6:2001:470:de0a:1:f587:762f:126a:a806]) by mork.alvestrand.no (Postfix) with ESMTPSA id D42657C799D; Fri, 4 Mar 2016 11:46:36 +0100 (CET) To: "Asveren, Tolga" , Roman Shpount References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> <56D824BD.2080305@alvestrand.no> <56D86A45.70406@alvestrand.no> From: Harald Alvestrand X-Enigmail-Draft-Status: N1110 Message-ID: <56D9678C.5050405@alvestrand.no> Date: Fri, 4 Mar 2016 11:46:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 10:46:44 -0000 Den 04. mars 2016 11:34, skrev Asveren, Tolga: > i- I don't think satisfactory technical explanation is provided why "enforcing a range" is superior to a "default range". I will leave this here and obviously this is just my personal -but honest- opinion. I interpret this as "the explanations that have been given do not convince me". Sorry about that. > ii- I got confused about what WEBRTC WG refers to, maybe to W3C? If so, is rtcweb-audio specification only about browsers? Again, for the umpteenth time: The hard limits are *not* in rtcweb-audio. They're in the WEBRTC WG (which is a WG of the W3C, not the IETF) API specification. > I wouldn’t think so. There are other types of entities playing in the RTCWeb domain, e.g. gateways. The limits we are talking about, are they applicable only for digits sent by browsers? What about digits emitted by a native application or a gateway? Will a browser be able to accept them if they are out of the range (assuming that the final outcome is to use enforced ranges)? If you don't understand which parts of the spec are done by the IETF and which by the W3C, some more reading might be in order. And if you don't have any experience in designing Javascript APIs, you might want to talk to someone who has that experience. > > iii- Just as an example, I am aware of systems, which can detect digits <40ms. > > iv- What about the gap between the final packet (with E-bit set) retransmissions? > > v- As use cases for the need for longer duration (all these are based on the same deployment model: A "legacy" application controlled by phone needs to be extended so that it can be accessed by Internet connected devices, e.g. a web-book. DataChannel is not used, e.g. not supported by gateway, by application etc..., hence digits are used for control. > > - TV gaming show > User registers for the game and is selected for that day's show. > The user sees what is happening on the game on his TV and controls it by digits > The game (balloon escape) requires that at the beginning the user pumps air into the balloon. This is done by continuously pressing "5" Reference? To a game that actually works on current (mobile) phones? > > - Remote valve/door/lock control > Authorized person makes a call and then continuously presses "6" to keep the valve/door/lock open for that period. > > - Panic button > An application for women who are mistreated by their husbands. Police/Social service workers rush to the registered address if she presses "7" continuously for longer than 10 seconds. > > I am just trying to show that there are many different/imaginative ways using the "digit UI". If you want to assert an use case, please assert one that is seen in the real world. The whole DTMF stuff is a wart that was added to the specification to address use cases with real, existing, deployed hardware. It was not a goal to stimulate people to imagine new ways in which DTMF could be used. It remains a wart. It's a design goal to keep the cost of supporting the wart low. Removing the limits in the API would raise the support cost. > > > Thanks, > Tolga > >> -----Original Message----- >> From: Harald Alvestrand [mailto:harald@alvestrand.no] >> Sent: Thursday, March 03, 2016 11:46 AM >> To: Roman Shpount >> Cc: Asveren, Tolga ; Ted Hardie >> ; Stefan Håkansson LK >> ; rtcweb@ietf.org >> Subject: Re: [rtcweb] Fwd: Last Call: >> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard >> >> Den 03. mars 2016 17:06, skrev Roman Shpount: >>> On Thu, Mar 3, 2016 at 6:49 AM, Harald Alvestrand >>> > wrote: >>> >>> You've made this argument before. I cannot see that anything new has >>> been brought to the table that is likely to alter the WEBRTC WG >>> consensus to have these enforced limits. >>> >>> >>> Am I correct to understand that WEBRTC WG decided that there should be >>> limits on DTMF tone generation and it is up to this group (IETF >>> rtcweb) to decide the exact values of these limits? >> >> Formally, the RTCWEB group can advise the WEBRTC group about appropriate >> values, but in practice, the result is indistinguishable from your formulation :- >> ) >> >>> In this case, as I have stated before, the maximum tone duration >>> should be 8000 ms to match possible tone duration for RFC 2833 DTMF >>> tone. RFC >>> 2833 was in use for the past 15 years and no one reported any issues >>> with this limit. >>> >>> Minimum tone duration of 40 ms and minimum gap duration of 30 ms are >>> minimum physically required to transmit DTMF tone as 8 KHz audio >>> signal and still satisfy the talk-off specifications. These >>> limitations have not caused any practical issues for the past 50 >>> years. I would like to mention that shorter tones are used during call >>> setup since it can be guaranteed that no audio signal is present and >>> talk-off requirements are relaxed. Furthermore VoIP only networks, >>> which use RFC 2833/RFC 4733 tones, can support tones and gaps of >>> anything from 0 ms and up. This is why I initially advocated for 0 ms >>> min duration. On the other hand if the group decides that removing one >>> more potential foot gun is more important, I will not be too upset. >>> >>> If anybody can come up with the practical example where tones longer >>> then 8 sec or shorter then 40 ms with less then 30 ms gaps are used, >>> please report them to the list. Otherwise, let's document what is in >>> W3C TR and move on. >> >> Sounds good. From nobody Fri Mar 4 03:23:26 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF111B36A5 for ; Fri, 4 Mar 2016 03:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_PASS=-0.001] autolearn=ham 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 1BvpPQS6b9u8 for ; Fri, 4 Mar 2016 03:23:19 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0607.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:607]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1E81B36DE for ; Fri, 4 Mar 2016 03:23:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IrDToIie4ry27Xdy/DoESb2vfsQS8f/XOCWOZgnOh/U=; b=P6Ekv13rX0rgwINdQbQt6fz9lEKzUn6fMvVmLncu9yxyygCANvq4HCP+8QTupI3yB/KUSpxiVeVLL2vLCSzO2uOFdaN3h25rrWyDx3Uy4+MHiynj4DDIvPZFY7OEJSQaGPMVuKWcCF57vL54+f3xCVxfEwqhiKg9NEAqE3Dt6sQ= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) with Microsoft SMTP Server (TLS) id 15.1.409.15; Fri, 4 Mar 2016 11:22:57 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Fri, 4 Mar 2016 11:22:57 +0000 From: "Asveren, Tolga" To: Harald Alvestrand , Roman Shpount Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p9EeOUQgAB4VQCAAAJvQIAABQwAgAAAciCAAdggAIAAwScAgAATEICAAEfAgIAACySAgAEinnCAAAtQAIAAB1uw Date: Fri, 4 Mar 2016 11:22:56 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> <56D824BD.2080305@alvestrand.no> <56D86A45.70406@alvestrand.no> <56D9678C.5050405@alvestrand.no> In-Reply-To: <56D9678C.5050405@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alvestrand.no; dkim=none (message not signed) header.d=none; alvestrand.no; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: ca91297c-f630-4c19-30f6-08d3441f5633 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1551; 5:FR2OzWoyGNvxExwjSlvde7MGR/nRtyN0qG8W5dFzU9bPV9OK0zlkfAKCFrGNuzm7FTxxvSePbhOJbGILEBijudDbzEznzMYnZr5n7+BJ3xbizCzIaldzHhVZkn3GQoTenebovaZfsD+T3DFR0L8GhQ==; 24:CsX8mAyk6j7OgxLAk1zgpj36R2qGusjNfeKaUH8/3pwLa5eWRV8EwRlhGFkYAJPS2gKh3h4MTu4uLmW1kKXQzQGybBfe/JTAmE0rDTfB6Pc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1551; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:SN1PR0301MB1551; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1551; x-forefront-prvs: 0871917CDA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(38284003)(2473001)(24454002)(13464003)(164054003)(377454003)(50986999)(11100500001)(3660700001)(2906002)(6116002)(5004730100002)(102836003)(5001770100001)(586003)(19580395003)(19580405001)(1220700001)(5008740100001)(86362001)(40100003)(1096002)(189998001)(81166005)(33656002)(74316001)(122556002)(3846002)(4326007)(54356999)(76176999)(3280700002)(10400500002)(87936001)(2900100001)(2950100001)(77096005)(230783001)(5002640100001)(66066001)(76576001)(5003600100002)(99286002)(106116001)(92566002)(93886004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1551; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2016 11:22:56.7429 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1551 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 11:23:22 -0000 KEkgZmVlbCBzb21lICJ1bmZyaWVuZGxpbmVzcyIgaW4gdGhlIHJlcGx5IEkgcmVjZWl2ZWQgYnV0 IHRoYXQgaXMgcHJvYmFibHkganVzdCBteSBtaXNpbnRlcnByZXRhdGlvbiA7LSkgKQ0KDQppLSBJ IHVuZGVyc3RhbmQgdmVyeSB3ZWxsIHdoYXQgaXMgZGVmaW5lZCBieSBXM0MgYW5kIHdoYXQgYnkg SUVURiBSVENXRUIgV0cuIFRoZSBwb2ludCBJIGFtIHRyeWluZyB0byBtYWtlIGlzIHRoYXQgaW4g dGhpcyBpc3N1ZSwgdGhlIG9yZGVyIG9mIGV2ZW50cyBzZWVtIHRvIGJlIHVwc2lkZS1kb3duIHRv IG1lIGFzIHdoYXQgaXMgc3BlY2lmaWVkIGluIHRoZSBydGN3ZWItYXVkaW8gaXMgbm90IG9ubHkg YXBwbGljYWJsZSBmb3IgYnJvd3NlcnMuIEFuZCwgd2hhdCBwcmV2ZW50cyBXM0MgdG8gZW5mb3Jj ZSBsaW1pdHMgaW4gdGhlIEFQSSBldmVuIGlmIHN1Y2ggbGltaXRzIGFyZSBub3QgY2l0ZWQgaW4g cnRjd2ViLWF1ZGlvPw0KDQppaS0gQXMgZmFyIGFzIHVzZSBjYXNlcyBhcmUgY29uY2VybmVkLCB5 b3VyIHBvaW50IHNlZW1zIHRvIGJlICJJZiBpdCBpcyBub3QgZG9uZSB1bnRpbCBkb25lLCBpdCBk b2VzIG5vdCBuZWVkIHRvIGJlIGNvdmVyZWQiLiBJIGRpc2FncmVlIGJ1dCB3aWxsIGxlYXZlIHRo aXMgb25lIGhlcmUgYXMgd2VsbCBhcyBJIGRvbuKAmXQgaGF2ZSBhbnl0aGluZyB0byBhZGQuDQoN CmlpaS0gSnVzdCBzbyB0aGF0IHRoZXkgYXJlIG5vdCBsb3N0OyB3b3VsZCBhcHByZWNpYXRlIGFu c3dlcnMgYWJvdXQgc3lzdGVtcyBkZXRlY3RpbmcgZGlnaXRzIHdpdGggPDQwbXMgZHVyYXRpb24g YW5kIGFib3V0IHRoZSBnYXAgYmV0d2VlbiB0aGUgZmluYWwgcGFja2V0IHJldHJhbnNtaXNzaW9u cy4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBIYXJhbGQgQWx2ZXN0cmFuZCBbbWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vXQ0KPiBT ZW50OiBGcmlkYXksIE1hcmNoIDA0LCAyMDE2IDU6NDcgQU0NCj4gVG86IEFzdmVyZW4sIFRvbGdh IDx0YXN2ZXJlbkBzb251c25ldC5jb20+OyBSb21hbiBTaHBvdW50DQo+IDxyb21hbkB0ZWx1cml4 LmNvbT4NCj4gQ2M6IFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdtYWlsLmNvbT47IFN0ZWZhbiBIw6Vr YW5zc29uIExLDQo+IDxzdGVmYW4ubGsuaGFrYW5zc29uQGVyaWNzc29uLmNvbT47IHJ0Y3dlYkBp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3J0Y3dlYl0gRndkOiBMYXN0IENhbGw6IDxkcmFmdC1p ZXRmLXJ0Y3dlYi1hdWRpby0xMC50eHQ+DQo+IChXZWJSVEMgQXVkaW8gQ29kZWMgYW5kIFByb2Nl c3NpbmcgUmVxdWlyZW1lbnRzKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiANCj4gRGVuIDA0LiBt YXJzIDIwMTYgMTE6MzQsIHNrcmV2IEFzdmVyZW4sIFRvbGdhOg0KPiA+IGktIEkgZG9uJ3QgdGhp bmsgc2F0aXNmYWN0b3J5IHRlY2huaWNhbCBleHBsYW5hdGlvbiBpcyBwcm92aWRlZCB3aHkgImVu Zm9yY2luZw0KPiBhIHJhbmdlIiBpcyBzdXBlcmlvciB0byBhICJkZWZhdWx0IHJhbmdlIi4gSSB3 aWxsIGxlYXZlIHRoaXMgaGVyZSBhbmQgb2J2aW91c2x5DQo+IHRoaXMgaXMganVzdCBteSBwZXJz b25hbCAtYnV0IGhvbmVzdC0gb3Bpbmlvbi4NCj4gDQo+IEkgaW50ZXJwcmV0IHRoaXMgYXMgInRo ZSBleHBsYW5hdGlvbnMgdGhhdCBoYXZlIGJlZW4gZ2l2ZW4gZG8gbm90IGNvbnZpbmNlDQo+IG1l Ii4NCj4gU29ycnkgYWJvdXQgdGhhdC4NCj4gDQo+ID4gaWktIEkgZ290IGNvbmZ1c2VkIGFib3V0 IHdoYXQgV0VCUlRDIFdHIHJlZmVycyB0bywgbWF5YmUgdG8gVzNDPyBJZiBzbywgaXMNCj4gcnRj d2ViLWF1ZGlvIHNwZWNpZmljYXRpb24gb25seSBhYm91dCBicm93c2Vycz8NCj4gDQo+IEFnYWlu LCBmb3IgdGhlIHVtcHRlZW50aCB0aW1lOg0KPiBUaGUgaGFyZCBsaW1pdHMgYXJlICpub3QqIGlu IHJ0Y3dlYi1hdWRpby4gVGhleSdyZSBpbiB0aGUgV0VCUlRDIFdHICh3aGljaA0KPiBpcyBhIFdH IG9mIHRoZSBXM0MsIG5vdCB0aGUgSUVURikgQVBJIHNwZWNpZmljYXRpb24uDQo+IA0KPiA+IEkg d291bGRu4oCZdCB0aGluayBzby4gVGhlcmUgYXJlIG90aGVyIHR5cGVzIG9mIGVudGl0aWVzIHBs YXlpbmcgaW4gdGhlIFJUQ1dlYg0KPiBkb21haW4sIGUuZy4gZ2F0ZXdheXMuIFRoZSBsaW1pdHMg d2UgYXJlIHRhbGtpbmcgYWJvdXQsIGFyZSB0aGV5IGFwcGxpY2FibGUNCj4gb25seSBmb3IgZGln aXRzIHNlbnQgYnkgYnJvd3NlcnM/IFdoYXQgYWJvdXQgZGlnaXRzIGVtaXR0ZWQgYnkgYSBuYXRp dmUNCj4gYXBwbGljYXRpb24gb3IgYSBnYXRld2F5PyBXaWxsIGEgYnJvd3NlciBiZSBhYmxlIHRv IGFjY2VwdCB0aGVtIGlmIHRoZXkgYXJlDQo+IG91dCBvZiB0aGUgcmFuZ2UgKGFzc3VtaW5nIHRo YXQgdGhlIGZpbmFsIG91dGNvbWUgaXMgdG8gdXNlIGVuZm9yY2VkDQo+IHJhbmdlcyk/DQo+IA0K PiANCj4gSWYgeW91IGRvbid0IHVuZGVyc3RhbmQgd2hpY2ggcGFydHMgb2YgdGhlIHNwZWMgYXJl IGRvbmUgYnkgdGhlIElFVEYgYW5kDQo+IHdoaWNoIGJ5IHRoZSBXM0MsIHNvbWUgbW9yZSByZWFk aW5nIG1pZ2h0IGJlIGluIG9yZGVyLg0KPiBBbmQgaWYgeW91IGRvbid0IGhhdmUgYW55IGV4cGVy aWVuY2UgaW4gZGVzaWduaW5nIEphdmFzY3JpcHQgQVBJcywgeW91IG1pZ2h0DQo+IHdhbnQgdG8g dGFsayB0byBzb21lb25lIHdobyBoYXMgdGhhdCBleHBlcmllbmNlLg0KPiANCj4gPg0KPiA+IGlp aS0gSnVzdCBhcyBhbiBleGFtcGxlLCBJIGFtIGF3YXJlIG9mIHN5c3RlbXMsIHdoaWNoIGNhbiBk ZXRlY3QgZGlnaXRzDQo+IDw0MG1zLg0KPiA+DQo+ID4gaXYtIFdoYXQgYWJvdXQgdGhlIGdhcCBi ZXR3ZWVuIHRoZSBmaW5hbCBwYWNrZXQgKHdpdGggRS1iaXQgc2V0KQ0KPiByZXRyYW5zbWlzc2lv bnM/DQo+ID4NCj4gPiB2LSBBcyB1c2UgY2FzZXMgZm9yIHRoZSBuZWVkIGZvciBsb25nZXIgZHVy YXRpb24gKGFsbCB0aGVzZSBhcmUgYmFzZWQgb24gdGhlDQo+IHNhbWUgZGVwbG95bWVudCBtb2Rl bDogQSAibGVnYWN5IiBhcHBsaWNhdGlvbiBjb250cm9sbGVkIGJ5IHBob25lIG5lZWRzDQo+IHRv IGJlIGV4dGVuZGVkIHNvIHRoYXQgaXQgY2FuIGJlIGFjY2Vzc2VkIGJ5IEludGVybmV0IGNvbm5l Y3RlZCBkZXZpY2VzLA0KPiBlLmcuIGEgd2ViLWJvb2suIERhdGFDaGFubmVsIGlzIG5vdCB1c2Vk LCBlLmcuIG5vdCBzdXBwb3J0ZWQgYnkgZ2F0ZXdheSwgYnkNCj4gYXBwbGljYXRpb24gZXRjLi4u LCBoZW5jZSBkaWdpdHMgYXJlIHVzZWQgZm9yIGNvbnRyb2wuDQo+ID4NCj4gPiAtIFRWIGdhbWlu ZyBzaG93DQo+ID4gVXNlciByZWdpc3RlcnMgZm9yIHRoZSBnYW1lIGFuZCBpcyBzZWxlY3RlZCBm b3IgdGhhdCBkYXkncyBzaG93Lg0KPiA+IFRoZSB1c2VyIHNlZXMgd2hhdCBpcyBoYXBwZW5pbmcg b24gdGhlIGdhbWUgb24gaGlzIFRWIGFuZCBjb250cm9scyBpdA0KPiA+IGJ5IGRpZ2l0cyBUaGUg Z2FtZSAoYmFsbG9vbiBlc2NhcGUpIHJlcXVpcmVzIHRoYXQgYXQgdGhlIGJlZ2lubmluZyB0aGUg dXNlcg0KPiBwdW1wcyBhaXIgaW50byB0aGUgYmFsbG9vbi4gVGhpcyBpcyBkb25lIGJ5IGNvbnRp bnVvdXNseSBwcmVzc2luZyAiNSINCj4gDQo+IA0KPiBSZWZlcmVuY2U/IFRvIGEgZ2FtZSB0aGF0 IGFjdHVhbGx5IHdvcmtzIG9uIGN1cnJlbnQgKG1vYmlsZSkgcGhvbmVzPw0KPiANCj4gPg0KPiA+ IC0gUmVtb3RlIHZhbHZlL2Rvb3IvbG9jayBjb250cm9sDQo+ID4gQXV0aG9yaXplZCBwZXJzb24g bWFrZXMgYSBjYWxsIGFuZCB0aGVuIGNvbnRpbnVvdXNseSBwcmVzc2VzICI2IiB0byBrZWVwDQo+ IHRoZSB2YWx2ZS9kb29yL2xvY2sgb3BlbiBmb3IgdGhhdCBwZXJpb2QuDQo+ID4NCj4gPiAtIFBh bmljIGJ1dHRvbg0KPiA+IEFuIGFwcGxpY2F0aW9uIGZvciB3b21lbiB3aG8gYXJlIG1pc3RyZWF0 ZWQgYnkgdGhlaXIgaHVzYmFuZHMuDQo+IFBvbGljZS9Tb2NpYWwgc2VydmljZSB3b3JrZXJzIHJ1 c2ggdG8gdGhlIHJlZ2lzdGVyZWQgYWRkcmVzcyBpZiBzaGUgcHJlc3NlcyAiNyINCj4gY29udGlu dW91c2x5IGZvciBsb25nZXIgdGhhbiAxMCBzZWNvbmRzLg0KPiA+DQo+ID4gSSBhbSBqdXN0IHRy eWluZyB0byBzaG93IHRoYXQgdGhlcmUgYXJlIG1hbnkgZGlmZmVyZW50L2ltYWdpbmF0aXZlIHdh eXMNCj4gdXNpbmcgdGhlICJkaWdpdCBVSSIuDQo+IA0KPiBJZiB5b3Ugd2FudCB0byBhc3NlcnQg YW4gdXNlIGNhc2UsIHBsZWFzZSBhc3NlcnQgb25lIHRoYXQgaXMgc2VlbiBpbiB0aGUgcmVhbA0K PiB3b3JsZC4NCj4gDQo+IFRoZSB3aG9sZSBEVE1GIHN0dWZmIGlzIGEgd2FydCB0aGF0IHdhcyBh ZGRlZCB0byB0aGUgc3BlY2lmaWNhdGlvbiB0bw0KPiBhZGRyZXNzIHVzZSBjYXNlcyB3aXRoIHJl YWwsIGV4aXN0aW5nLCBkZXBsb3llZCBoYXJkd2FyZS4gSXQgd2FzIG5vdCBhIGdvYWwgdG8NCj4g c3RpbXVsYXRlIHBlb3BsZSB0byBpbWFnaW5lIG5ldyB3YXlzIGluIHdoaWNoIERUTUYgY291bGQg YmUgdXNlZC4NCj4gDQo+IEl0IHJlbWFpbnMgYSB3YXJ0LiBJdCdzIGEgZGVzaWduIGdvYWwgdG8g a2VlcCB0aGUgY29zdCBvZiBzdXBwb3J0aW5nIHRoZSB3YXJ0DQo+IGxvdy4NCj4gUmVtb3Zpbmcg dGhlIGxpbWl0cyBpbiB0aGUgQVBJIHdvdWxkIHJhaXNlIHRoZSBzdXBwb3J0IGNvc3QuDQo+IA0K PiA+DQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gVG9sZ2ENCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBIYXJhbGQgQWx2ZXN0cmFuZCBbbWFpbHRvOmhhcmFs ZEBhbHZlc3RyYW5kLm5vXQ0KPiA+PiBTZW50OiBUaHVyc2RheSwgTWFyY2ggMDMsIDIwMTYgMTE6 NDYgQU0NCj4gPj4gVG86IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPg0KPiA+PiBD YzogQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbT47IFRlZCBIYXJkaWUNCj4g Pj4gPHRlZC5pZXRmQGdtYWlsLmNvbT47IFN0ZWZhbiBIw6VrYW5zc29uIExLDQo+ID4+IDxzdGVm YW4ubGsuaGFrYW5zc29uQGVyaWNzc29uLmNvbT47IHJ0Y3dlYkBpZXRmLm9yZw0KPiA+PiBTdWJq ZWN0OiBSZTogW3J0Y3dlYl0gRndkOiBMYXN0IENhbGw6DQo+ID4+IDxkcmFmdC1pZXRmLXJ0Y3dl Yi1hdWRpby0xMC50eHQ+IChXZWJSVEMgQXVkaW8gQ29kZWMgYW5kIFByb2Nlc3NpbmcNCj4gPj4g UmVxdWlyZW1lbnRzKSB0byBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+Pg0KPiA+PiBEZW4gMDMuIG1h cnMgMjAxNiAxNzowNiwgc2tyZXYgUm9tYW4gU2hwb3VudDoNCj4gPj4+IE9uIFRodSwgTWFyIDMs IDIwMTYgYXQgNjo0OSBBTSwgSGFyYWxkIEFsdmVzdHJhbmQNCj4gPj4+IDxoYXJhbGRAYWx2ZXN0 cmFuZC5ubyA8bWFpbHRvOmhhcmFsZEBhbHZlc3RyYW5kLm5vPj4gd3JvdGU6DQo+ID4+Pg0KPiA+ Pj4gICAgIFlvdSd2ZSBtYWRlIHRoaXMgYXJndW1lbnQgYmVmb3JlLiBJIGNhbm5vdCBzZWUgdGhh dCBhbnl0aGluZyBuZXcgaGFzDQo+ID4+PiAgICAgYmVlbiBicm91Z2h0IHRvIHRoZSB0YWJsZSB0 aGF0IGlzIGxpa2VseSB0byBhbHRlciB0aGUgV0VCUlRDIFdHDQo+ID4+PiAgICAgY29uc2Vuc3Vz IHRvIGhhdmUgdGhlc2UgZW5mb3JjZWQgbGltaXRzLg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBBbSBJ IGNvcnJlY3QgdG8gdW5kZXJzdGFuZCB0aGF0IFdFQlJUQyBXRyBkZWNpZGVkIHRoYXQgdGhlcmUg c2hvdWxkDQo+ID4+PiBiZSBsaW1pdHMgb24gRFRNRiB0b25lIGdlbmVyYXRpb24gYW5kIGl0IGlz IHVwIHRvIHRoaXMgZ3JvdXAgKElFVEYNCj4gPj4+IHJ0Y3dlYikgdG8gZGVjaWRlIHRoZSBleGFj dCB2YWx1ZXMgb2YgdGhlc2UgbGltaXRzPw0KPiA+Pg0KPiA+PiBGb3JtYWxseSwgdGhlIFJUQ1dF QiBncm91cCBjYW4gYWR2aXNlIHRoZSBXRUJSVEMgZ3JvdXAgYWJvdXQNCj4gPj4gYXBwcm9wcmlh dGUgdmFsdWVzLCBidXQgaW4gcHJhY3RpY2UsIHRoZSByZXN1bHQgaXMgaW5kaXN0aW5ndWlzaGFi bGUNCj4gPj4gZnJvbSB5b3VyIGZvcm11bGF0aW9uIDotDQo+ID4+ICkNCj4gPj4NCj4gPj4+IElu IHRoaXMgY2FzZSwgYXMgSSBoYXZlIHN0YXRlZCBiZWZvcmUsIHRoZSBtYXhpbXVtIHRvbmUgZHVy YXRpb24NCj4gPj4+IHNob3VsZCBiZSA4MDAwIG1zIHRvIG1hdGNoIHBvc3NpYmxlIHRvbmUgZHVy YXRpb24gZm9yIFJGQyAyODMzIERUTUYNCj4gPj4+IHRvbmUuIFJGQw0KPiA+Pj4gMjgzMyB3YXMg aW4gdXNlIGZvciB0aGUgcGFzdCAxNSB5ZWFycyBhbmQgbm8gb25lIHJlcG9ydGVkIGFueSBpc3N1 ZXMNCj4gPj4+IHdpdGggdGhpcyBsaW1pdC4NCj4gPj4+DQo+ID4+PiBNaW5pbXVtIHRvbmUgZHVy YXRpb24gb2YgNDAgbXMgYW5kIG1pbmltdW0gZ2FwIGR1cmF0aW9uIG9mIDMwIG1zDQo+IGFyZQ0K PiA+Pj4gbWluaW11bSBwaHlzaWNhbGx5IHJlcXVpcmVkIHRvIHRyYW5zbWl0IERUTUYgdG9uZSBh cyA4IEtIeiBhdWRpbw0KPiA+Pj4gc2lnbmFsIGFuZCBzdGlsbCBzYXRpc2Z5IHRoZSB0YWxrLW9m ZiBzcGVjaWZpY2F0aW9ucy4gVGhlc2UNCj4gPj4+IGxpbWl0YXRpb25zIGhhdmUgbm90IGNhdXNl ZCBhbnkgcHJhY3RpY2FsIGlzc3VlcyBmb3IgdGhlIHBhc3QgNTANCj4gPj4+IHllYXJzLiBJIHdv dWxkIGxpa2UgdG8gbWVudGlvbiB0aGF0IHNob3J0ZXIgdG9uZXMgYXJlIHVzZWQgZHVyaW5nDQo+ ID4+PiBjYWxsIHNldHVwIHNpbmNlIGl0IGNhbiBiZSBndWFyYW50ZWVkIHRoYXQgbm8gYXVkaW8g c2lnbmFsIGlzDQo+ID4+PiBwcmVzZW50IGFuZCB0YWxrLW9mZiByZXF1aXJlbWVudHMgYXJlIHJl bGF4ZWQuIEZ1cnRoZXJtb3JlIFZvSVAgb25seQ0KPiA+Pj4gbmV0d29ya3MsIHdoaWNoIHVzZSBS RkMgMjgzMy9SRkMgNDczMyB0b25lcywgY2FuIHN1cHBvcnQgdG9uZXMgYW5kDQo+ID4+PiBnYXBz IG9mIGFueXRoaW5nIGZyb20gMCBtcyBhbmQgdXAuIFRoaXMgaXMgd2h5IEkgaW5pdGlhbGx5IGFk dm9jYXRlZA0KPiA+Pj4gZm9yIDAgbXMgbWluIGR1cmF0aW9uLiBPbiB0aGUgb3RoZXIgaGFuZCBp ZiB0aGUgZ3JvdXAgZGVjaWRlcyB0aGF0DQo+ID4+PiByZW1vdmluZyBvbmUgbW9yZSBwb3RlbnRp YWwgZm9vdCBndW4gaXMgbW9yZSBpbXBvcnRhbnQsIEkgd2lsbCBub3QgYmUNCj4gdG9vIHVwc2V0 Lg0KPiA+Pj4NCj4gPj4+IElmIGFueWJvZHkgY2FuIGNvbWUgdXAgd2l0aCB0aGUgcHJhY3RpY2Fs IGV4YW1wbGUgd2hlcmUgdG9uZXMgbG9uZ2VyDQo+ID4+PiB0aGVuIDggc2VjIG9yIHNob3J0ZXIg dGhlbiA0MCBtcyB3aXRoIGxlc3MgdGhlbiAzMCBtcyBnYXBzIGFyZSB1c2VkLA0KPiA+Pj4gcGxl YXNlIHJlcG9ydCB0aGVtIHRvIHRoZSBsaXN0LiBPdGhlcndpc2UsIGxldCdzIGRvY3VtZW50IHdo YXQgaXMgaW4NCj4gPj4+IFczQyBUUiBhbmQgbW92ZSBvbi4NCj4gPj4NCj4gPj4gU291bmRzIGdv b2QuDQo= From nobody Fri Mar 4 03:33:33 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA3D1B36F5 for ; Fri, 4 Mar 2016 03:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 lau5zIxB4Xyb for ; Fri, 4 Mar 2016 03:33:29 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C841B36F3 for ; Fri, 4 Mar 2016 03:33:29 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id l127so59326086iof.3 for ; Fri, 04 Mar 2016 03:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=RHSPkU5JmA+l+QBw9O+bd0YeKRwR9hFuKClTwLRuiO8=; b=wMashlsN6znp8njzKwy8Ruthu2Az07wEsc/6fij3LYz/zapaTZKuiogDYLJdo8AefR cgJ8vRbvnGNq96X5zTxOvhRjFhyJoUbTKUfBAyqGNOq0pWmjuqV4MMKzqvN83KNgS7kZ yDvZsnVhes0vGWsEVtQebyc/UZuUlqKONAX546bdvc0TDB3Y+HnYkA2xzw1zIlZN2Brg rTcYx1CWPwacGScvjXtyzxirKT7h3mPhfpw8ONksMr2vrvW7TS+tE3ZWyoAk1gCvlnTB uuYbbrtKVWX8mCpiPWYtw531+N1QqS/ZtwwyxwuFETSTxEbbpQnGtiYrBThfTGdRPIj0 JdXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RHSPkU5JmA+l+QBw9O+bd0YeKRwR9hFuKClTwLRuiO8=; b=RzikLa/aTtPgQUi9Mo4ofdBGS4zWnm6i99+F+kAT5/BhSKWebAfTPa4eKRiAYI8ISZ UxA7n7Qt0tWwJMiH6Nx9dn7thhdeNmaDcDqiTuAt3EfyJ8iJwm4I5ZOIBX1Lha4mQ/Wy uyyEZBMKLunr78d5SWpRsWwzo2GGKgXE6DYu1rV5+Tl/gLwB2FZsIh8ankltn8req7WW F9iA8DLBth3Mlll2LrVacw2c8BsBg/AfhJbIeBX754andhUbZhqlRhfw1d+eTU++v96y CNhw0qKPFsvmpGBMPXr/bkAzCW8yQ+BKflJlj/UKBbmjM14FvocBJ/nAQGuIwuz2tGyk 2B8A== X-Gm-Message-State: AD7BkJLhzYStRVF4CDHRlNpyQuPc2Sn+tFbvTEc84d4lYwTazLU4vKnK/NLl005RzxNP0N8pNBBQsTyDhBxRlg== MIME-Version: 1.0 X-Received: by 10.107.41.133 with SMTP id p127mr8213813iop.100.1457091208474; Fri, 04 Mar 2016 03:33:28 -0800 (PST) Received: by 10.36.43.5 with HTTP; Fri, 4 Mar 2016 03:33:28 -0800 (PST) In-Reply-To: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> <56D824BD.2080305@alvestrand.no> <56D86A45.70406@alvestrand.no> <56D9678C.5050405@alvestrand.no> Date: Fri, 4 Mar 2016 22:33:28 +1100 Message-ID: From: Martin Thomson To: "Asveren, Tolga" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 11:33:30 -0000 This thread has gone on too long. On 4 March 2016 at 22:22, Asveren, Tolga wrote: > I understand very well what is defined by W3C and what by IETF RTCWEB WG. Let's do away with that nonsense and address the issue squarely. Both Roman and Harald have provided you with solid technical arguments. You have chosen to be un-swayed by those arguments, which is fine, that's your prerogative. However, it is clear that you have not convinced anyone else to support your position either. Thus, from my observer position, *this* working group has consensus to impose limits. Maybe one of the chairs is able to make a similar assessment and, please, close this thread. --Martin (who is for some reason unable to mute this thread) From nobody Fri Mar 4 04:07:47 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85AA11B376E for ; Fri, 4 Mar 2016 04:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 6FSM99_SXPtI for ; Fri, 4 Mar 2016 04:07:43 -0800 (PST) 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 BC7AF1B376A for ; Fri, 4 Mar 2016 04:07:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id C6A5D7C797F; Fri, 4 Mar 2016 13:07:40 +0100 (CET) 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 Z3-hYqfVtDgR; Fri, 4 Mar 2016 13:07:39 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:d01b:4dcd:df6f:495d] (unknown [IPv6:2001:470:de0a:1:d01b:4dcd:df6f:495d]) by mork.alvestrand.no (Postfix) with ESMTPSA id 10DC77C7911; Fri, 4 Mar 2016 13:07:39 +0100 (CET) To: "Asveren, Tolga" , Roman Shpount References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D824BD.2080305@alvestrand.no> <56D86A45.70406@alvestrand.no> <56D9678C.5050405@alvestrand.no> From: Harald Alvestrand X-Enigmail-Draft-Status: N1110 Message-ID: <56D97A8A.9070303@alvestrand.no> Date: Fri, 4 Mar 2016 13:07:38 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 12:07:45 -0000 Den 04. mars 2016 12:22, skrev Asveren, Tolga: > (I feel some "unfriendliness" in the reply I received but that is probably just my misinterpretation ;-) ) I see why it could be interpreted as such. I will endeavor to maintain a neutral tone. > i- I understand very well what is defined by W3C and what by IETF RTCWEB WG. Thank you. I was a bit confused about your knowledge given that you said "I got confused about what WEBRTC WG refers to, maybe to W3C?" > The point I am trying to make is that in this issue, the order of events seem to be upside-down to me as what is specified in the rtcweb-audio is not only applicable for browsers. And, what prevents W3C to enforce limits in the API even if such limits are not cited in rtcweb-audio? Nothing. I thought your argument was against there being limits at all. > > ii- As far as use cases are concerned, your point seems to be "If it is not done until done, it does not need to be covered". I disagree but will leave this one here as well as I don’t have anything to add. If it's not done until now, there's a chance that there are genuine problems with doing it at all. We're not here to solve those problems; not part of our requirement set. > > iii- Just so that they are not lost; would appreciate answers about systems detecting digits with <40ms duration and about the gap between the final packet retransmissions. I will leave that argument to others. > > Thanks, > Tolga > >> -----Original Message----- >> From: Harald Alvestrand [mailto:harald@alvestrand.no] >> Sent: Friday, March 04, 2016 5:47 AM >> To: Asveren, Tolga ; Roman Shpount >> >> Cc: Ted Hardie ; Stefan Håkansson LK >> ; rtcweb@ietf.org >> Subject: Re: [rtcweb] Fwd: Last Call: >> (WebRTC Audio Codec and Processing Requirements) to Proposed Standard >> >> Den 04. mars 2016 11:34, skrev Asveren, Tolga: >>> i- I don't think satisfactory technical explanation is provided why "enforcing >> a range" is superior to a "default range". I will leave this here and obviously >> this is just my personal -but honest- opinion. >> >> I interpret this as "the explanations that have been given do not convince >> me". >> Sorry about that. >> >>> ii- I got confused about what WEBRTC WG refers to, maybe to W3C? If so, is >> rtcweb-audio specification only about browsers? >> >> Again, for the umpteenth time: >> The hard limits are *not* in rtcweb-audio. They're in the WEBRTC WG (which >> is a WG of the W3C, not the IETF) API specification. >> >>> I wouldn’t think so. There are other types of entities playing in the RTCWeb >> domain, e.g. gateways. The limits we are talking about, are they applicable >> only for digits sent by browsers? What about digits emitted by a native >> application or a gateway? Will a browser be able to accept them if they are >> out of the range (assuming that the final outcome is to use enforced >> ranges)? >> >> >> If you don't understand which parts of the spec are done by the IETF and >> which by the W3C, some more reading might be in order. >> And if you don't have any experience in designing Javascript APIs, you might >> want to talk to someone who has that experience. >> >>> >>> iii- Just as an example, I am aware of systems, which can detect digits >> <40ms. >>> >>> iv- What about the gap between the final packet (with E-bit set) >> retransmissions? >>> >>> v- As use cases for the need for longer duration (all these are based on the >> same deployment model: A "legacy" application controlled by phone needs >> to be extended so that it can be accessed by Internet connected devices, >> e.g. a web-book. DataChannel is not used, e.g. not supported by gateway, by >> application etc..., hence digits are used for control. >>> >>> - TV gaming show >>> User registers for the game and is selected for that day's show. >>> The user sees what is happening on the game on his TV and controls it >>> by digits The game (balloon escape) requires that at the beginning the user >> pumps air into the balloon. This is done by continuously pressing "5" >> >> >> Reference? To a game that actually works on current (mobile) phones? >> >>> >>> - Remote valve/door/lock control >>> Authorized person makes a call and then continuously presses "6" to keep >> the valve/door/lock open for that period. >>> >>> - Panic button >>> An application for women who are mistreated by their husbands. >> Police/Social service workers rush to the registered address if she presses "7" >> continuously for longer than 10 seconds. >>> >>> I am just trying to show that there are many different/imaginative ways >> using the "digit UI". >> >> If you want to assert an use case, please assert one that is seen in the real >> world. >> >> The whole DTMF stuff is a wart that was added to the specification to >> address use cases with real, existing, deployed hardware. It was not a goal to >> stimulate people to imagine new ways in which DTMF could be used. >> >> It remains a wart. It's a design goal to keep the cost of supporting the wart >> low. >> Removing the limits in the API would raise the support cost. >> >>> >>> >>> Thanks, >>> Tolga >>> >>>> -----Original Message----- >>>> From: Harald Alvestrand [mailto:harald@alvestrand.no] >>>> Sent: Thursday, March 03, 2016 11:46 AM >>>> To: Roman Shpount >>>> Cc: Asveren, Tolga ; Ted Hardie >>>> ; Stefan Håkansson LK >>>> ; rtcweb@ietf.org >>>> Subject: Re: [rtcweb] Fwd: Last Call: >>>> (WebRTC Audio Codec and Processing >>>> Requirements) to Proposed Standard >>>> >>>> Den 03. mars 2016 17:06, skrev Roman Shpount: >>>>> On Thu, Mar 3, 2016 at 6:49 AM, Harald Alvestrand >>>>> > wrote: >>>>> >>>>> You've made this argument before. I cannot see that anything new has >>>>> been brought to the table that is likely to alter the WEBRTC WG >>>>> consensus to have these enforced limits. >>>>> >>>>> >>>>> Am I correct to understand that WEBRTC WG decided that there should >>>>> be limits on DTMF tone generation and it is up to this group (IETF >>>>> rtcweb) to decide the exact values of these limits? >>>> >>>> Formally, the RTCWEB group can advise the WEBRTC group about >>>> appropriate values, but in practice, the result is indistinguishable >>>> from your formulation :- >>>> ) >>>> >>>>> In this case, as I have stated before, the maximum tone duration >>>>> should be 8000 ms to match possible tone duration for RFC 2833 DTMF >>>>> tone. RFC >>>>> 2833 was in use for the past 15 years and no one reported any issues >>>>> with this limit. >>>>> >>>>> Minimum tone duration of 40 ms and minimum gap duration of 30 ms >> are >>>>> minimum physically required to transmit DTMF tone as 8 KHz audio >>>>> signal and still satisfy the talk-off specifications. These >>>>> limitations have not caused any practical issues for the past 50 >>>>> years. I would like to mention that shorter tones are used during >>>>> call setup since it can be guaranteed that no audio signal is >>>>> present and talk-off requirements are relaxed. Furthermore VoIP only >>>>> networks, which use RFC 2833/RFC 4733 tones, can support tones and >>>>> gaps of anything from 0 ms and up. This is why I initially advocated >>>>> for 0 ms min duration. On the other hand if the group decides that >>>>> removing one more potential foot gun is more important, I will not be >> too upset. >>>>> >>>>> If anybody can come up with the practical example where tones longer >>>>> then 8 sec or shorter then 40 ms with less then 30 ms gaps are used, >>>>> please report them to the list. Otherwise, let's document what is in >>>>> W3C TR and move on. >>>> >>>> Sounds good. From nobody Fri Mar 4 04:10:12 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7761B377B for ; Fri, 4 Mar 2016 04:10:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 z0w_qAg0nMHF for ; Fri, 4 Mar 2016 04:10:09 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161141B373F for ; Fri, 4 Mar 2016 04:10:09 -0800 (PST) Received: by mail-ob0-x22d.google.com with SMTP id xx9so47949986obc.2 for ; Fri, 04 Mar 2016 04:10:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qkK+3+iSA1eoU6HuDfrz8CJVGebywjGbEfbbLzAZsWE=; b=ePlG64SGsNVKq7vrYB1e0PwozucMoBYWCty1zkNot6s9XjBUcAdaqTsKZMMFwlLSmO RoRF2xOONx2HyB/fnZAC9ZU7QOSjw1nn3O8TyMutJ54sQh/cM1pVs6VHtSCMAJvNxr5J 9hqP9buV7GvaTk6R/QOhPw8c7Q+X3e0dMZutU/jYGXoPY2Sn7EzH+oT9ajhp8y0ryiQ/ 77llvmIBsCxeluqVFgx/V4BQkcWReLEIqTFqw6xYeABEs/8MkSGCGBc3GLsqtr9FtVd4 zT/YnsTw/ySJXScwWYHo9DNcXORt8eUoPWhILJ9Fs0J8pD84Nx7yOJMPZL0Zzgk2rQDz tY3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qkK+3+iSA1eoU6HuDfrz8CJVGebywjGbEfbbLzAZsWE=; b=Z7IgYa/c83oamamVWfpeTr/QYEBgXUqAOou8PbcAN90qxZv+OCRf7VZ+Q4Spb2QpOH 0u6nFP6Tg4Q7YXQaukqSYCA/MLi2QjeYIiiCxOQoEEsWnNT/Gu/w/xo+Sv9Jn6M5Mq/E oinzBcnkcXqdQ/778JoSE0sQ9MJAYE35Ga/fc8rDtMOTgjr1zus+oSzZOArlHIbgz6S7 /VfMPqvEhGkxouMSIrg2z3eIR9ENM4GbGn/SA2XpQDc3Nc65llitU23ZgYB/QXqdZxYR CocKJbWrSa5ZJs+6mGt7gizZvp5gMYZ2qP0m7AkIKepbusmwHrxiw4UZ+rkAQJnDDDwB GRNA== X-Gm-Message-State: AD7BkJLT8pZC20Ecr8t2gzZIoLE+wcb/+sLp8/6PIfg+PDFiucRvdMfg0xtdETOeX2d5KVDeTxzPRW/EUdsioA== X-Received: by 10.182.196.104 with SMTP id il8mr5593543obc.71.1457093408460; Fri, 04 Mar 2016 04:10:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.17.69 with HTTP; Fri, 4 Mar 2016 04:09:48 -0800 (PST) In-Reply-To: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> <56D824BD.2080305@alvestrand.no> <56D86A45.70406@alvestrand.no> <56D9678C.5050405@alvestrand.no> From: Barry Dingle Date: Fri, 4 Mar 2016 23:09:48 +1100 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=089e0149c6360416af052d37ff01 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 12:10:10 -0000 --089e0149c6360416af052d37ff01 Content-Type: text/plain; charset=UTF-8 I endorse Martin's comments. DTMF is >50 yo technology. We are supporting it in WebRTC/rtcweb to enable interworking with legacy real-time communications. If you want to add App-specific user signalling in WebRTC/rtcweb, I suggest you look at using the *WebRTC/rtcweb Data Channel*. Really simple to set up - and there are no analog-telephony type limitations. Cheers, /Barry Barry Dingle University of Melbourne, Australia On Fri, Mar 4, 2016 at 10:33 PM, Martin Thomson wrote: > This thread has gone on too long. > > On 4 March 2016 at 22:22, Asveren, Tolga wrote: > > I understand very well what is defined by W3C and what by IETF RTCWEB WG. > > Let's do away with that nonsense and address the issue squarely. Both > Roman and Harald have provided you with solid technical arguments. > You have chosen to be un-swayed by those arguments, which is fine, > that's your prerogative. However, it is clear that you have not > convinced anyone else to support your position either. > > Thus, from my observer position, *this* working group has consensus to > impose limits. Maybe one of the chairs is able to make a similar > assessment and, please, close this thread. > > --Martin (who is for some reason unable to mute this thread) > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e0149c6360416af052d37ff01 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I endorse Martin's comments.

DT= MF is >50 yo technology. We are supporting it in WebRTC/rtcweb to enable= interworking with legacy real-time communications.

If you wa= nt to add App-specific user signalling in WebRTC/rtcweb, I suggest you look= at using the WebRTC/rtcweb Data Channel. Really simple to set up - = and there are no analog-telephony type limitations.

Cheers,
/Barry

Barry Dingle
Universi= ty of Melbourne, Australia

On Fri, Mar 4, 2016 at 10:33 PM, Martin Thom= son <martin.thomson@gmail.com> wrote:
This thread has gone on too long.

On 4 March 2016 at 22:22, Asveren, Tolga <tasveren@sonusnet.com> wrote:
> I understand very well what is defined by W3C and what by IETF RTCWEB = WG.

Let's do away with that nonsense and address the issue squarely.= =C2=A0 Both
Roman and Harald have provided you with solid technical arguments.
You have chosen to be un-swayed by those arguments, which is fine,
that's your prerogative.=C2=A0 However, it is clear that you have not convinced anyone else to support your position either.

Thus, from my observer position, *this* working group has consensus to
impose limits.=C2=A0 Maybe one of the chairs is able to make a similar
assessment and, please, close this thread.

--Martin (who is for some reason unable to mute this thread)

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--089e0149c6360416af052d37ff01-- From nobody Fri Mar 4 05:52:46 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D100F1A00DF for ; Fri, 4 Mar 2016 05:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 5rhcCRDGanb9 for ; Fri, 4 Mar 2016 05:52:41 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0072.outbound.protection.outlook.com [65.55.169.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21DB51A00DC for ; Fri, 4 Mar 2016 05:52:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TEAl5NzW+MwCee54kMFKB3rx8pE03tgG2Y+swaeDuLE=; b=JRLxH7x8d9Y5OeiFspAP3sz9+l0aGA6IsQtELI6Ugg9XJ+Ik99Y5LROuXPmFZUGqCkcfyvdZ0zNfOGjP7L2bf2Bzax4TYZwyEsgRGxCreBbjrB98OB/6KGmd6UDOxbCW6UJr6E1orGvZIIWfqC3/bGO8iCoyZNmP0gtd9B2nQA4= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) with Microsoft SMTP Server (TLS) id 15.1.409.15; Fri, 4 Mar 2016 13:52:39 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Fri, 4 Mar 2016 13:52:39 +0000 From: "Asveren, Tolga" To: Harald Alvestrand , Roman Shpount Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p9EeOUQgAB4VQCAAAJvQIAABQwAgAAAciCAAdggAIAAwScAgAATEICAAEfAgIAACySAgAEinnCAAAtQAIAAB1uwgAAPSQCAABqTYA== Date: Fri, 4 Mar 2016 13:52:38 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D824BD.2080305@alvestrand.no> <56D86A45.70406@alvestrand.no> <56D9678C.5050405@alvestrand.no> <56D97A8A.9070303@alvestrand.no> In-Reply-To: <56D97A8A.9070303@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alvestrand.no; dkim=none (message not signed) header.d=none; alvestrand.no; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: a937aeec-6793-4b07-0e63-08d344343fe1 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1551; 5:F6PleVosDcShVa6xAI8I4RrgOo+KzELlVQe/FOTCjfIRDWd6hz7XoZppm0vLLR6EFvAJtHI+9WvWV2ffT4OQqpplRkh0/UgboDQDeJdqc56JOXgAwURdiJiBC5CgdfttShI3HVn0uvJOij1b7ZJadA==; 24:dkAAokBEyUHBBEns1UfSFWxmOR1i5EamO1z7d1CuGYlCVGAy9sKOf1Xw6jckxcS9jpapNXNWmrT+ikfC/KKowagLlOLfM1ZnmzyftbyQO2w= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1551; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:SN1PR0301MB1551; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1551; x-forefront-prvs: 0871917CDA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(2473001)(24454002)(13464003)(164054003)(377454003)(50986999)(11100500001)(3660700001)(2906002)(6116002)(102836003)(5001770100001)(586003)(19580395003)(19580405001)(1220700001)(5008740100001)(40100003)(86362001)(1096002)(189998001)(81166005)(33656002)(74316001)(122556002)(3846002)(4326007)(54356999)(76176999)(3280700002)(10400500002)(87936001)(2900100001)(2950100001)(77096005)(230783001)(5002640100001)(66066001)(76576001)(5003600100002)(99286002)(106116001)(92566002)(93886004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1551; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2016 13:52:38.7573 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1551 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 13:52:45 -0000 PkFuZCwgd2hhdCBwcmV2ZW50cyBXM0MgdG8gZW5mb3JjZQ0KPiBsaW1pdHMgaW4gdGhlIEFQSSBl dmVuIGlmIHN1Y2ggbGltaXRzIGFyZSBub3QgY2l0ZWQgaW4gcnRjd2ViLWF1ZGlvPw0KPiANCj4g Tm90aGluZy4gSSB0aG91Z2h0IHlvdXIgYXJndW1lbnQgd2FzIGFnYWluc3QgdGhlcmUgYmVpbmcg bGltaXRzIGF0IGFsbC4NClllcywgSSB3YXMgYWR2b2NhdGluZyBub3QgdG8gZW5mb3JjZSBhbnkg bGltaXRzIG9uIHRoZSBicm93c2VyIChidXQgd29u4oCZdCBoYXJwIG9uIGl0IGFueW1vcmUsIG5v dGhpbmcgdG8gYWRkKS4gT1RPSCwgZW5mb3JjaW5nIGxpbWl0cyBpbiB0aGUgYnJvd3NlciB2LnMu IGluIHRoZSBydGN3ZWItYXVkaW8gc3BlY2lmaWNhdGlvbiBhcmUgbm90IGV4YWN0bHkgdGhlIHNh bWUgdGhpbmcgQUZBSUNTLiBXb3VsZCBsZWF2aW5nIFJGQzQ3MzMgLWluZGlyZWN0bHktIHVudG91 Y2hlZCBjYXVzZSBhbnkgcHJvYmxlbXM/IElmIHdoYXQgVzNDIG5lZWRzIGlzIGEgcmVjb21tZW5k YXRpb24gZnJvbSBSVENXZWIgV0csIGNhbuKAmXQgdGhpcyBiZSBjb252ZXllZCBqdXN0IGJ5IG90 aGVyIG1lYW5zIChhbmQgdGhvc2UgbGltaXRzIGNhbiBiZSBpbXBvc2VkIGJ5IHRoZSBicm93c2Vy IHZlbmRvcnMgYXMgdGhleSBzZWUgZml0KS4gTGltaXRzIGluIHJ0Y3dlYi1hdWRpbyB3aWxsIG9w ZW4gdGhlIGRvb3IgZm9yIHRoZSBuZWVkIGZvciB5ZXQgYW5vdGhlciB0eXBlIG9mIGludGVyd29y a2luZyAodG8gbWFrZSBzdXJlIHRoYXQgUlRDV2ViIGxlZyBjb21wbGllcyB3aXRoIHRoZSBsaW1p dHMpIGFuZCB3b3VsZG7igJl0IGl0IGJlIHByZWZlcmFibGUgdG8gZWxpbWluYXRlIHN1Y2ggYSBu ZWVkIHVubGVzcyBkb2luZyBvdGhlcndpc2UgaXMgYWJzb2x1dGVseSBuZWVkZWQ/DQoNClRoYW5r cywNClRvbGdhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSGFyYWxk IEFsdmVzdHJhbmQgW21haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ub10NCj4gU2VudDogRnJpZGF5 LCBNYXJjaCAwNCwgMjAxNiA3OjA4IEFNDQo+IFRvOiBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5A c29udXNuZXQuY29tPjsgUm9tYW4gU2hwb3VudA0KPiA8cm9tYW5AdGVsdXJpeC5jb20+DQo+IENj OiBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb20+OyBTdGVmYW4gSMOla2Fuc3NvbiBMSw0K PiA8c3RlZmFuLmxrLmhha2Fuc3NvbkBlcmljc3Nvbi5jb20+OyBydGN3ZWJAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFtydGN3ZWJdIEZ3ZDogTGFzdCBDYWxsOiA8ZHJhZnQtaWV0Zi1ydGN3ZWIt YXVkaW8tMTAudHh0Pg0KPiAoV2ViUlRDIEF1ZGlvIENvZGVjIGFuZCBQcm9jZXNzaW5nIFJlcXVp cmVtZW50cykgdG8gUHJvcG9zZWQgU3RhbmRhcmQNCj4gDQo+IERlbiAwNC4gbWFycyAyMDE2IDEy OjIyLCBza3JldiBBc3ZlcmVuLCBUb2xnYToNCj4gPiAoSSBmZWVsIHNvbWUgInVuZnJpZW5kbGlu ZXNzIiBpbiB0aGUgcmVwbHkgSSByZWNlaXZlZCBidXQgdGhhdCBpcw0KPiA+IHByb2JhYmx5IGp1 c3QgbXkgbWlzaW50ZXJwcmV0YXRpb24gOy0pICkNCj4gDQo+IEkgc2VlIHdoeSBpdCBjb3VsZCBi ZSBpbnRlcnByZXRlZCBhcyBzdWNoLg0KPiBJIHdpbGwgZW5kZWF2b3IgdG8gbWFpbnRhaW4gYSBu ZXV0cmFsIHRvbmUuDQo+IA0KPiANCj4gDQo+ID4gaS0gSSB1bmRlcnN0YW5kIHZlcnkgd2VsbCB3 aGF0IGlzIGRlZmluZWQgYnkgVzNDIGFuZCB3aGF0IGJ5IElFVEYgUlRDV0VCDQo+IFdHLg0KPiAN Cj4gVGhhbmsgeW91LiBJIHdhcyBhIGJpdCBjb25mdXNlZCBhYm91dCB5b3VyIGtub3dsZWRnZSBn aXZlbiB0aGF0IHlvdSBzYWlkICJJDQo+IGdvdCBjb25mdXNlZCBhYm91dCB3aGF0IFdFQlJUQyBX RyByZWZlcnMgdG8sIG1heWJlIHRvIFczQz8iDQo+IA0KPiA+IFRoZSBwb2ludCBJIGFtIHRyeWlu ZyB0byBtYWtlIGlzIHRoYXQgaW4gdGhpcyBpc3N1ZSwgdGhlIG9yZGVyIG9mDQo+IGV2ZW50cyBz ZWVtIHRvIGJlIHVwc2lkZS1kb3duIHRvIG1lIGFzIHdoYXQgaXMgc3BlY2lmaWVkIGluIHRoZSBy dGN3ZWItDQo+IGF1ZGlvIGlzIG5vdCBvbmx5IGFwcGxpY2FibGUgZm9yIGJyb3dzZXJzLiBBbmQs IHdoYXQgcHJldmVudHMgVzNDIHRvIGVuZm9yY2UNCj4gbGltaXRzIGluIHRoZSBBUEkgZXZlbiBp ZiBzdWNoIGxpbWl0cyBhcmUgbm90IGNpdGVkIGluIHJ0Y3dlYi1hdWRpbz8NCj4gDQo+IE5vdGhp bmcuIEkgdGhvdWdodCB5b3VyIGFyZ3VtZW50IHdhcyBhZ2FpbnN0IHRoZXJlIGJlaW5nIGxpbWl0 cyBhdCBhbGwuDQo+IA0KPiA+DQo+ID4gaWktIEFzIGZhciBhcyB1c2UgY2FzZXMgYXJlIGNvbmNl cm5lZCwgeW91ciBwb2ludCBzZWVtcyB0byBiZSAiSWYgaXQgaXMgbm90DQo+IGRvbmUgdW50aWwg ZG9uZSwgaXQgZG9lcyBub3QgbmVlZCB0byBiZSBjb3ZlcmVkIi4gSSBkaXNhZ3JlZSBidXQgd2ls bCBsZWF2ZQ0KPiB0aGlzIG9uZSBoZXJlIGFzIHdlbGwgYXMgSSBkb27igJl0IGhhdmUgYW55dGhp bmcgdG8gYWRkLg0KPiANCj4gSWYgaXQncyBub3QgZG9uZSB1bnRpbCBub3csIHRoZXJlJ3MgYSBj aGFuY2UgdGhhdCB0aGVyZSBhcmUgZ2VudWluZSBwcm9ibGVtcw0KPiB3aXRoIGRvaW5nIGl0IGF0 IGFsbC4gV2UncmUgbm90IGhlcmUgdG8gc29sdmUgdGhvc2UgcHJvYmxlbXM7IG5vdCBwYXJ0IG9m IG91cg0KPiByZXF1aXJlbWVudCBzZXQuDQo+IA0KPiA+DQo+ID4gaWlpLSBKdXN0IHNvIHRoYXQg dGhleSBhcmUgbm90IGxvc3Q7IHdvdWxkIGFwcHJlY2lhdGUgYW5zd2VycyBhYm91dCBzeXN0ZW1z DQo+IGRldGVjdGluZyBkaWdpdHMgd2l0aCA8NDBtcyBkdXJhdGlvbiBhbmQgYWJvdXQgdGhlIGdh cCBiZXR3ZWVuIHRoZSBmaW5hbA0KPiBwYWNrZXQgcmV0cmFuc21pc3Npb25zLg0KPiANCj4gSSB3 aWxsIGxlYXZlIHRoYXQgYXJndW1lbnQgdG8gb3RoZXJzLg0KPiANCj4gPg0KPiA+IFRoYW5rcywN Cj4gPiBUb2xnYQ0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZy b206IEhhcmFsZCBBbHZlc3RyYW5kIFttYWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm9dDQo+ID4+ IFNlbnQ6IEZyaWRheSwgTWFyY2ggMDQsIDIwMTYgNTo0NyBBTQ0KPiA+PiBUbzogQXN2ZXJlbiwg VG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbT47IFJvbWFuIFNocG91bnQNCj4gPj4gPHJvbWFu QHRlbHVyaXguY29tPg0KPiA+PiBDYzogVGVkIEhhcmRpZSA8dGVkLmlldGZAZ21haWwuY29tPjsg U3RlZmFuIEjDpWthbnNzb24gTEsNCj4gPj4gPHN0ZWZhbi5say5oYWthbnNzb25AZXJpY3Nzb24u Y29tPjsgcnRjd2ViQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBGd2Q6IExh c3QgQ2FsbDoNCj4gPj4gPGRyYWZ0LWlldGYtcnRjd2ViLWF1ZGlvLTEwLnR4dD4gKFdlYlJUQyBB dWRpbyBDb2RlYyBhbmQgUHJvY2Vzc2luZw0KPiA+PiBSZXF1aXJlbWVudHMpIHRvIFByb3Bvc2Vk IFN0YW5kYXJkDQo+ID4+DQo+ID4+IERlbiAwNC4gbWFycyAyMDE2IDExOjM0LCBza3JldiBBc3Zl cmVuLCBUb2xnYToNCj4gPj4+IGktIEkgZG9uJ3QgdGhpbmsgc2F0aXNmYWN0b3J5IHRlY2huaWNh bCBleHBsYW5hdGlvbiBpcyBwcm92aWRlZCB3aHkNCj4gPj4+ICJlbmZvcmNpbmcNCj4gPj4gYSBy YW5nZSIgaXMgc3VwZXJpb3IgdG8gYSAiZGVmYXVsdCByYW5nZSIuIEkgd2lsbCBsZWF2ZSB0aGlz IGhlcmUgYW5kDQo+ID4+IG9idmlvdXNseSB0aGlzIGlzIGp1c3QgbXkgcGVyc29uYWwgLWJ1dCBo b25lc3QtIG9waW5pb24uDQo+ID4+DQo+ID4+IEkgaW50ZXJwcmV0IHRoaXMgYXMgInRoZSBleHBs YW5hdGlvbnMgdGhhdCBoYXZlIGJlZW4gZ2l2ZW4gZG8gbm90DQo+ID4+IGNvbnZpbmNlIG1lIi4N Cj4gPj4gU29ycnkgYWJvdXQgdGhhdC4NCj4gPj4NCj4gPj4+IGlpLSBJIGdvdCBjb25mdXNlZCBh Ym91dCB3aGF0IFdFQlJUQyBXRyByZWZlcnMgdG8sIG1heWJlIHRvIFczQz8gSWYNCj4gPj4+IHNv LCBpcw0KPiA+PiBydGN3ZWItYXVkaW8gc3BlY2lmaWNhdGlvbiBvbmx5IGFib3V0IGJyb3dzZXJz Pw0KPiA+Pg0KPiA+PiBBZ2FpbiwgZm9yIHRoZSB1bXB0ZWVudGggdGltZToNCj4gPj4gVGhlIGhh cmQgbGltaXRzIGFyZSAqbm90KiBpbiBydGN3ZWItYXVkaW8uIFRoZXkncmUgaW4gdGhlIFdFQlJU QyBXRw0KPiA+PiAod2hpY2ggaXMgYSBXRyBvZiB0aGUgVzNDLCBub3QgdGhlIElFVEYpIEFQSSBz cGVjaWZpY2F0aW9uLg0KPiA+Pg0KPiA+Pj4gSSB3b3VsZG7igJl0IHRoaW5rIHNvLiBUaGVyZSBh cmUgb3RoZXIgdHlwZXMgb2YgZW50aXRpZXMgcGxheWluZyBpbg0KPiA+Pj4gdGhlIFJUQ1dlYg0K PiA+PiBkb21haW4sIGUuZy4gZ2F0ZXdheXMuIFRoZSBsaW1pdHMgd2UgYXJlIHRhbGtpbmcgYWJv dXQsIGFyZSB0aGV5DQo+ID4+IGFwcGxpY2FibGUgb25seSBmb3IgZGlnaXRzIHNlbnQgYnkgYnJv d3NlcnM/IFdoYXQgYWJvdXQgZGlnaXRzDQo+ID4+IGVtaXR0ZWQgYnkgYSBuYXRpdmUgYXBwbGlj YXRpb24gb3IgYSBnYXRld2F5PyBXaWxsIGEgYnJvd3NlciBiZSBhYmxlDQo+ID4+IHRvIGFjY2Vw dCB0aGVtIGlmIHRoZXkgYXJlIG91dCBvZiB0aGUgcmFuZ2UgKGFzc3VtaW5nIHRoYXQgdGhlIGZp bmFsDQo+ID4+IG91dGNvbWUgaXMgdG8gdXNlIGVuZm9yY2VkIHJhbmdlcyk/DQo+ID4+DQo+ID4+ DQo+ID4+IElmIHlvdSBkb24ndCB1bmRlcnN0YW5kIHdoaWNoIHBhcnRzIG9mIHRoZSBzcGVjIGFy ZSBkb25lIGJ5IHRoZSBJRVRGDQo+ID4+IGFuZCB3aGljaCBieSB0aGUgVzNDLCBzb21lIG1vcmUg cmVhZGluZyBtaWdodCBiZSBpbiBvcmRlci4NCj4gPj4gQW5kIGlmIHlvdSBkb24ndCBoYXZlIGFu eSBleHBlcmllbmNlIGluIGRlc2lnbmluZyBKYXZhc2NyaXB0IEFQSXMsDQo+ID4+IHlvdSBtaWdo dCB3YW50IHRvIHRhbGsgdG8gc29tZW9uZSB3aG8gaGFzIHRoYXQgZXhwZXJpZW5jZS4NCj4gPj4N Cj4gPj4+DQo+ID4+PiBpaWktIEp1c3QgYXMgYW4gZXhhbXBsZSwgSSBhbSBhd2FyZSBvZiBzeXN0 ZW1zLCB3aGljaCBjYW4gZGV0ZWN0DQo+ID4+PiBkaWdpdHMNCj4gPj4gPDQwbXMuDQo+ID4+Pg0K PiA+Pj4gaXYtIFdoYXQgYWJvdXQgdGhlIGdhcCBiZXR3ZWVuIHRoZSBmaW5hbCBwYWNrZXQgKHdp dGggRS1iaXQgc2V0KQ0KPiA+PiByZXRyYW5zbWlzc2lvbnM/DQo+ID4+Pg0KPiA+Pj4gdi0gQXMg dXNlIGNhc2VzIGZvciB0aGUgbmVlZCBmb3IgbG9uZ2VyIGR1cmF0aW9uIChhbGwgdGhlc2UgYXJl DQo+ID4+PiBiYXNlZCBvbiB0aGUNCj4gPj4gc2FtZSBkZXBsb3ltZW50IG1vZGVsOiBBICJsZWdh Y3kiIGFwcGxpY2F0aW9uIGNvbnRyb2xsZWQgYnkgcGhvbmUNCj4gPj4gbmVlZHMgdG8gYmUgZXh0 ZW5kZWQgc28gdGhhdCBpdCBjYW4gYmUgYWNjZXNzZWQgYnkgSW50ZXJuZXQgY29ubmVjdGVkDQo+ ID4+IGRldmljZXMsIGUuZy4gYSB3ZWItYm9vay4gRGF0YUNoYW5uZWwgaXMgbm90IHVzZWQsIGUu Zy4gbm90IHN1cHBvcnRlZA0KPiA+PiBieSBnYXRld2F5LCBieSBhcHBsaWNhdGlvbiBldGMuLi4s IGhlbmNlIGRpZ2l0cyBhcmUgdXNlZCBmb3IgY29udHJvbC4NCj4gPj4+DQo+ID4+PiAtIFRWIGdh bWluZyBzaG93DQo+ID4+PiBVc2VyIHJlZ2lzdGVycyBmb3IgdGhlIGdhbWUgYW5kIGlzIHNlbGVj dGVkIGZvciB0aGF0IGRheSdzIHNob3cuDQo+ID4+PiBUaGUgdXNlciBzZWVzIHdoYXQgaXMgaGFw cGVuaW5nIG9uIHRoZSBnYW1lIG9uIGhpcyBUViBhbmQgY29udHJvbHMNCj4gPj4+IGl0IGJ5IGRp Z2l0cyBUaGUgZ2FtZSAoYmFsbG9vbiBlc2NhcGUpIHJlcXVpcmVzIHRoYXQgYXQgdGhlDQo+ID4+ PiBiZWdpbm5pbmcgdGhlIHVzZXINCj4gPj4gcHVtcHMgYWlyIGludG8gdGhlIGJhbGxvb24uIFRo aXMgaXMgZG9uZSBieSBjb250aW51b3VzbHkgcHJlc3NpbmcgIjUiDQo+ID4+DQo+ID4+DQo+ID4+ IFJlZmVyZW5jZT8gVG8gYSBnYW1lIHRoYXQgYWN0dWFsbHkgd29ya3Mgb24gY3VycmVudCAobW9i aWxlKSBwaG9uZXM/DQo+ID4+DQo+ID4+Pg0KPiA+Pj4gLSBSZW1vdGUgdmFsdmUvZG9vci9sb2Nr IGNvbnRyb2wNCj4gPj4+IEF1dGhvcml6ZWQgcGVyc29uIG1ha2VzIGEgY2FsbCBhbmQgdGhlbiBj b250aW51b3VzbHkgcHJlc3NlcyAiNiIgdG8NCj4gPj4+IGtlZXANCj4gPj4gdGhlIHZhbHZlL2Rv b3IvbG9jayBvcGVuIGZvciB0aGF0IHBlcmlvZC4NCj4gPj4+DQo+ID4+PiAtIFBhbmljIGJ1dHRv bg0KPiA+Pj4gQW4gYXBwbGljYXRpb24gZm9yIHdvbWVuIHdobyBhcmUgbWlzdHJlYXRlZCBieSB0 aGVpciBodXNiYW5kcy4NCj4gPj4gUG9saWNlL1NvY2lhbCBzZXJ2aWNlIHdvcmtlcnMgcnVzaCB0 byB0aGUgcmVnaXN0ZXJlZCBhZGRyZXNzIGlmIHNoZSBwcmVzc2VzDQo+ICI3Ig0KPiA+PiBjb250 aW51b3VzbHkgZm9yIGxvbmdlciB0aGFuIDEwIHNlY29uZHMuDQo+ID4+Pg0KPiA+Pj4gSSBhbSBq dXN0IHRyeWluZyB0byBzaG93IHRoYXQgdGhlcmUgYXJlIG1hbnkgZGlmZmVyZW50L2ltYWdpbmF0 aXZlDQo+ID4+PiB3YXlzDQo+ID4+IHVzaW5nIHRoZSAiZGlnaXQgVUkiLg0KPiA+Pg0KPiA+PiBJ ZiB5b3Ugd2FudCB0byBhc3NlcnQgYW4gdXNlIGNhc2UsIHBsZWFzZSBhc3NlcnQgb25lIHRoYXQg aXMgc2VlbiBpbg0KPiA+PiB0aGUgcmVhbCB3b3JsZC4NCj4gPj4NCj4gPj4gVGhlIHdob2xlIERU TUYgc3R1ZmYgaXMgYSB3YXJ0IHRoYXQgd2FzIGFkZGVkIHRvIHRoZSBzcGVjaWZpY2F0aW9uIHRv DQo+ID4+IGFkZHJlc3MgdXNlIGNhc2VzIHdpdGggcmVhbCwgZXhpc3RpbmcsIGRlcGxveWVkIGhh cmR3YXJlLiBJdCB3YXMgbm90DQo+ID4+IGEgZ29hbCB0byBzdGltdWxhdGUgcGVvcGxlIHRvIGlt YWdpbmUgbmV3IHdheXMgaW4gd2hpY2ggRFRNRiBjb3VsZCBiZQ0KPiB1c2VkLg0KPiA+Pg0KPiA+ PiBJdCByZW1haW5zIGEgd2FydC4gSXQncyBhIGRlc2lnbiBnb2FsIHRvIGtlZXAgdGhlIGNvc3Qg b2Ygc3VwcG9ydGluZw0KPiA+PiB0aGUgd2FydCBsb3cuDQo+ID4+IFJlbW92aW5nIHRoZSBsaW1p dHMgaW4gdGhlIEFQSSB3b3VsZCByYWlzZSB0aGUgc3VwcG9ydCBjb3N0Lg0KPiA+Pg0KPiA+Pj4N Cj4gPj4+DQo+ID4+PiBUaGFua3MsDQo+ID4+PiBUb2xnYQ0KPiA+Pj4NCj4gPj4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+IEZyb206IEhhcmFsZCBBbHZlc3RyYW5kIFttYWls dG86aGFyYWxkQGFsdmVzdHJhbmQubm9dDQo+ID4+Pj4gU2VudDogVGh1cnNkYXksIE1hcmNoIDAz LCAyMDE2IDExOjQ2IEFNDQo+ID4+Pj4gVG86IFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXgu Y29tPg0KPiA+Pj4+IENjOiBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPjsg VGVkIEhhcmRpZQ0KPiA+Pj4+IDx0ZWQuaWV0ZkBnbWFpbC5jb20+OyBTdGVmYW4gSMOla2Fuc3Nv biBMSw0KPiA+Pj4+IDxzdGVmYW4ubGsuaGFrYW5zc29uQGVyaWNzc29uLmNvbT47IHJ0Y3dlYkBp ZXRmLm9yZw0KPiA+Pj4+IFN1YmplY3Q6IFJlOiBbcnRjd2ViXSBGd2Q6IExhc3QgQ2FsbDoNCj4g Pj4+PiA8ZHJhZnQtaWV0Zi1ydGN3ZWItYXVkaW8tMTAudHh0PiAoV2ViUlRDIEF1ZGlvIENvZGVj IGFuZCBQcm9jZXNzaW5nDQo+ID4+Pj4gUmVxdWlyZW1lbnRzKSB0byBQcm9wb3NlZCBTdGFuZGFy ZA0KPiA+Pj4+DQo+ID4+Pj4gRGVuIDAzLiBtYXJzIDIwMTYgMTc6MDYsIHNrcmV2IFJvbWFuIFNo cG91bnQ6DQo+ID4+Pj4+IE9uIFRodSwgTWFyIDMsIDIwMTYgYXQgNjo0OSBBTSwgSGFyYWxkIEFs dmVzdHJhbmQNCj4gPj4+Pj4gPGhhcmFsZEBhbHZlc3RyYW5kLm5vIDxtYWlsdG86aGFyYWxkQGFs dmVzdHJhbmQubm8+PiB3cm90ZToNCj4gPj4+Pj4NCj4gPj4+Pj4gICAgIFlvdSd2ZSBtYWRlIHRo aXMgYXJndW1lbnQgYmVmb3JlLiBJIGNhbm5vdCBzZWUgdGhhdCBhbnl0aGluZyBuZXcNCj4gaGFz DQo+ID4+Pj4+ICAgICBiZWVuIGJyb3VnaHQgdG8gdGhlIHRhYmxlIHRoYXQgaXMgbGlrZWx5IHRv IGFsdGVyIHRoZSBXRUJSVEMgV0cNCj4gPj4+Pj4gICAgIGNvbnNlbnN1cyB0byBoYXZlIHRoZXNl IGVuZm9yY2VkIGxpbWl0cy4NCj4gPj4+Pj4NCj4gPj4+Pj4NCj4gPj4+Pj4gQW0gSSBjb3JyZWN0 IHRvIHVuZGVyc3RhbmQgdGhhdCBXRUJSVEMgV0cgZGVjaWRlZCB0aGF0IHRoZXJlDQo+ID4+Pj4+ IHNob3VsZCBiZSBsaW1pdHMgb24gRFRNRiB0b25lIGdlbmVyYXRpb24gYW5kIGl0IGlzIHVwIHRv IHRoaXMNCj4gPj4+Pj4gZ3JvdXAgKElFVEYNCj4gPj4+Pj4gcnRjd2ViKSB0byBkZWNpZGUgdGhl IGV4YWN0IHZhbHVlcyBvZiB0aGVzZSBsaW1pdHM/DQo+ID4+Pj4NCj4gPj4+PiBGb3JtYWxseSwg dGhlIFJUQ1dFQiBncm91cCBjYW4gYWR2aXNlIHRoZSBXRUJSVEMgZ3JvdXAgYWJvdXQNCj4gPj4+ PiBhcHByb3ByaWF0ZSB2YWx1ZXMsIGJ1dCBpbiBwcmFjdGljZSwgdGhlIHJlc3VsdCBpcw0KPiA+ Pj4+IGluZGlzdGluZ3Vpc2hhYmxlIGZyb20geW91ciBmb3JtdWxhdGlvbiA6LQ0KPiA+Pj4+ICkN Cj4gPj4+Pg0KPiA+Pj4+PiBJbiB0aGlzIGNhc2UsIGFzIEkgaGF2ZSBzdGF0ZWQgYmVmb3JlLCB0 aGUgbWF4aW11bSB0b25lIGR1cmF0aW9uDQo+ID4+Pj4+IHNob3VsZCBiZSA4MDAwIG1zIHRvIG1h dGNoIHBvc3NpYmxlIHRvbmUgZHVyYXRpb24gZm9yIFJGQyAyODMzDQo+ID4+Pj4+IERUTUYgdG9u ZS4gUkZDDQo+ID4+Pj4+IDI4MzMgd2FzIGluIHVzZSBmb3IgdGhlIHBhc3QgMTUgeWVhcnMgYW5k IG5vIG9uZSByZXBvcnRlZCBhbnkNCj4gPj4+Pj4gaXNzdWVzIHdpdGggdGhpcyBsaW1pdC4NCj4g Pj4+Pj4NCj4gPj4+Pj4gTWluaW11bSB0b25lIGR1cmF0aW9uIG9mIDQwIG1zIGFuZCBtaW5pbXVt IGdhcCBkdXJhdGlvbiBvZiAzMCBtcw0KPiA+PiBhcmUNCj4gPj4+Pj4gbWluaW11bSBwaHlzaWNh bGx5IHJlcXVpcmVkIHRvIHRyYW5zbWl0IERUTUYgdG9uZSBhcyA4IEtIeiBhdWRpbw0KPiA+Pj4+ PiBzaWduYWwgYW5kIHN0aWxsIHNhdGlzZnkgdGhlIHRhbGstb2ZmIHNwZWNpZmljYXRpb25zLiBU aGVzZQ0KPiA+Pj4+PiBsaW1pdGF0aW9ucyBoYXZlIG5vdCBjYXVzZWQgYW55IHByYWN0aWNhbCBp c3N1ZXMgZm9yIHRoZSBwYXN0IDUwDQo+ID4+Pj4+IHllYXJzLiBJIHdvdWxkIGxpa2UgdG8gbWVu dGlvbiB0aGF0IHNob3J0ZXIgdG9uZXMgYXJlIHVzZWQgZHVyaW5nDQo+ID4+Pj4+IGNhbGwgc2V0 dXAgc2luY2UgaXQgY2FuIGJlIGd1YXJhbnRlZWQgdGhhdCBubyBhdWRpbyBzaWduYWwgaXMNCj4g Pj4+Pj4gcHJlc2VudCBhbmQgdGFsay1vZmYgcmVxdWlyZW1lbnRzIGFyZSByZWxheGVkLiBGdXJ0 aGVybW9yZSBWb0lQDQo+ID4+Pj4+IG9ubHkgbmV0d29ya3MsIHdoaWNoIHVzZSBSRkMgMjgzMy9S RkMgNDczMyB0b25lcywgY2FuIHN1cHBvcnQNCj4gPj4+Pj4gdG9uZXMgYW5kIGdhcHMgb2YgYW55 dGhpbmcgZnJvbSAwIG1zIGFuZCB1cC4gVGhpcyBpcyB3aHkgSQ0KPiA+Pj4+PiBpbml0aWFsbHkg YWR2b2NhdGVkIGZvciAwIG1zIG1pbiBkdXJhdGlvbi4gT24gdGhlIG90aGVyIGhhbmQgaWYNCj4g Pj4+Pj4gdGhlIGdyb3VwIGRlY2lkZXMgdGhhdCByZW1vdmluZyBvbmUgbW9yZSBwb3RlbnRpYWwg Zm9vdCBndW4gaXMNCj4gPj4+Pj4gbW9yZSBpbXBvcnRhbnQsIEkgd2lsbCBub3QgYmUNCj4gPj4g dG9vIHVwc2V0Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJZiBhbnlib2R5IGNhbiBjb21lIHVwIHdpdGgg dGhlIHByYWN0aWNhbCBleGFtcGxlIHdoZXJlIHRvbmVzDQo+ID4+Pj4+IGxvbmdlciB0aGVuIDgg c2VjIG9yIHNob3J0ZXIgdGhlbiA0MCBtcyB3aXRoIGxlc3MgdGhlbiAzMCBtcyBnYXBzDQo+ID4+ Pj4+IGFyZSB1c2VkLCBwbGVhc2UgcmVwb3J0IHRoZW0gdG8gdGhlIGxpc3QuIE90aGVyd2lzZSwg bGV0J3MNCj4gPj4+Pj4gZG9jdW1lbnQgd2hhdCBpcyBpbiBXM0MgVFIgYW5kIG1vdmUgb24uDQo+ ID4+Pj4NCj4gPj4+PiBTb3VuZHMgZ29vZC4NCg== From nobody Fri Mar 4 11:39:09 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44A71A8898 for ; Fri, 4 Mar 2016 11:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 Ng80Cqi4SF7L for ; Fri, 4 Mar 2016 11:39:07 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2DC51A8896 for ; Fri, 4 Mar 2016 11:39:06 -0800 (PST) Received: by mail-ig0-x230.google.com with SMTP id i18so2923299igh.1 for ; Fri, 04 Mar 2016 11:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=30fBBinhrpA+J4FAAnvV9IWuyOTjP7iaVQskAde3+Vs=; b=2TSZpCG0vUSK905fLkIa1j4mxn0EMuRAgV4482pRq3T2fJPecXs/RcWQGBxN1wDaXz eMxlDKQ0rTGvMBpmQHMNkDsNMYevu8ormRtqPaB2MIH3hucAuc5BLNcyyZGowABHmMVX uXclu3VbgAiwghv7EO41iN+/ieh0UFPdrjyGSUlNrq2qjofzv0WHtUasXVTh/Mz2ov1R /bCxwtuTOmiDtD9cJuraV5Ai72nrCBIYdwuWSoYestFJ/TS5zXcIQGNVjeZHuPdrwAym NWMYpyERbffu99u0MIV34g6KW3Ubv1ccYS9XFqkDZt9oCzdmqR6wR5os2yIyrmR7Aryg N4LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=30fBBinhrpA+J4FAAnvV9IWuyOTjP7iaVQskAde3+Vs=; b=a/CGmO1UUn4RoLSUqNqaY98hCa0rpeINHQStvkDosi/bkYM4HBVwKYQQtu0eS6tl25 vN0QLpx0PdM/Q+Xe4vczSqwHcFICi735Z0z5L6eGnJA8IN/5XvyajGmgDXw+YAGhEuvY wDNEOO2m2LkgFK+EvEqcA/gAyBtrmb2+dZQgA/YVciLgOdQzLJ2dIsIKUduPXiPQJW1o dzyDrzYysPsbZAKo/ePktm9HtZcDBzqA7vltkIyBX1yZCfdZOTFP+S6xsOCiRJll0Je0 75k9ajHys593xHEOu+SdCCzkoq8MCGhNIchMvFNUqS1TavASOXberlcTu8TiOanFoZ/k UYZQ== X-Gm-Message-State: AD7BkJLgDkGOW5Gxj1yx7uEtd7BfDziMSfK6mTuGS8aqm6fLO1AumlB66kTUK6IAN7a/mA== X-Received: by 10.50.138.72 with SMTP id qo8mr602307igb.81.1457120346285; Fri, 04 Mar 2016 11:39:06 -0800 (PST) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com. [209.85.223.172]) by smtp.gmail.com with ESMTPSA id me7sm216425igb.12.2016.03.04.11.39.04 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Mar 2016 11:39:04 -0800 (PST) Received: by mail-io0-f172.google.com with SMTP id g203so73049059iof.2 for ; Fri, 04 Mar 2016 11:39:04 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.30.71 with SMTP id e68mr8785563ioe.145.1457120343890; Fri, 04 Mar 2016 11:39:03 -0800 (PST) Received: by 10.36.105.77 with HTTP; Fri, 4 Mar 2016 11:39:03 -0800 (PST) In-Reply-To: <56D9678C.5050405@alvestrand.no> References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> <56D824BD.2080305@alvestrand.no> <56D86A45.70406@alvestrand.no> <56D9678C.5050405@alvestrand.no> Date: Fri, 4 Mar 2016 14:39:03 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a1140d71e7e29ab052d3e445e Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 19:39:08 -0000 --001a1140d71e7e29ab052d3e445e Content-Type: text/plain; charset=UTF-8 On Fri, Mar 4, 2016 at 5:46 AM, Harald Alvestrand wrote: > The hard limits are *not* in rtcweb-audio. They're in the WEBRTC WG > (which is a WG of the W3C, not the IETF) API specification. > We are discussing adding tone and gap duration limits in rtcweb-audio. I would argue that these limits should come from rtcweb-audio draft and referenced in WEBRTC TR document. Not the other way around. Do you disagree with this and do you think tone and gap duration limits should only stay in WEBRTC TR? Regards, _____________ Roman Shpount --001a1140d71e7e29ab052d3e445e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 4, 2016 at 5:46 AM, Harald Alvestrand &l= t;harald@alvestra= nd.no> wrote:
The hard limits are *not* in rtcweb-audio. They're in the W= EBRTC WG
(which is a WG of the W3C, not the IETF) API specification.

We are discussing adding tone and gap duration limits = in rtcweb-audio. I would argue that these limits should come from rtcweb-au= dio draft and referenced in WEBRTC TR document. Not the other way around.

Do you disagree with this and do you think tone and= gap duration limits should only stay in WEBRTC TR?
=C2=A0
<= div>Regards,
_____________
Roma= n Shpount
=C2=A0
--001a1140d71e7e29ab052d3e445e-- From nobody Fri Mar 4 11:48:05 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6961A88DB for ; Fri, 4 Mar 2016 11:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 sl1u0x3tyDx8 for ; Fri, 4 Mar 2016 11:48:01 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0087.outbound.protection.outlook.com [207.46.100.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4F571A88C7 for ; Fri, 4 Mar 2016 11:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RalZ1OVeMDne1PAg0musOwrPIj/jrdW6V87/mW/8xwQ=; b=uMunIOG6CQyCLXLeLFZXuDFWhQJqC3jIKC9FfXsjTsdnOjqXnIPrmmTk5CrX7igEyZn2h3wD+2TljxYx1/zKkVPlbUUZtY9MSTqQeiGvlte43WaYy0K3otnCNYZdYHLLTK0lxOrRhwysSGA9aCcFdqUnVMlRu9kgoobFMZwTRtg= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.427.16; Fri, 4 Mar 2016 19:47:59 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Fri, 4 Mar 2016 19:47:59 +0000 From: "Asveren, Tolga" To: Roman Shpount , Harald Alvestrand Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p9EeOUQgAB4VQCAAAJvQIAABQwAgAAAciCAAdggAIAAwScAgAATEICAAEfAgIAACySAgAEinnCAAAtQAIAAlMSAgAACCL0= Date: Fri, 4 Mar 2016 19:47:59 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> <56D824BD.2080305@alvestrand.no> <56D86A45.70406@alvestrand.no> <56D9678C.5050405@alvestrand.no>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: cd8a2680-0d70-46ec-1992-08d34465e422 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:NE61vCCBMiQvOYjce6QLcKeaXgXNTcQILOocO8mCmAPwvRuD2++eXsCrc9G1bvwDd75pbUoeyuciUI3P6cQDk2pu+6LYvRmfQ3jdJn7eIi/K4OJMxyhUxszOvx7SmBAbwjY68fLE8xojX4GHnf2+og==; 24:I026GHi3I2tUbc19cfekWhoaMDM7S6K5EtlyvBleVRx7/5S4PrviIpf/iXx0ZjNWILyWF1Sdy/70MaorY0GfuJbxUOhNYzYJ8HsKT5jg0Mw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 0871917CDA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(2473001)(24454002)(164054003)(377454003)(93886004)(87936001)(92566002)(1096002)(1220700001)(3846002)(102836003)(6116002)(19580405001)(586003)(19580395003)(81166005)(77096005)(5004730100002)(11100500001)(2950100001)(2900100001)(5003600100002)(5002640100001)(66066001)(3900700001)(189998001)(106116001)(40100003)(74316001)(10400500002)(5001770100001)(19627405001)(76576001)(4326007)(122556002)(54356999)(50986999)(3280700002)(86362001)(76176999)(33656002)(16236675004)(3660700001)(230783001)(2906002)(5008740100001)(19625215002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB155106EB460584246C3F83EDB2BE0SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2016 19:47:59.6853 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 19:48:04 -0000 --_000_SN1PR0301MB155106EB460584246C3F83EDB2BE0SN1PR0301MB1551_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That they stay only in WEBRTC TC would address my practical concerns. And *= if* the main argument for the limits is making appellations less error pron= e, i.e. browsers enforcing limits, wouldn't this approach address the probl= em to be solved? Thanks, Tolga ________________________________ From: Roman Shpount Sent: Friday, March 4, 2016 2:39 PM To: Harald Alvestrand Cc: Asveren, Tolga; Ted Hardie; Stefan H=E5kansson LK; rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: Last Call: (Web= RTC Audio Codec and Processing Requirements) to Proposed Standard On Fri, Mar 4, 2016 at 5:46 AM, Harald Alvestrand > wrote: The hard limits are *not* in rtcweb-audio. They're in the WEBRTC WG (which is a WG of the W3C, not the IETF) API specification. We are discussing adding tone and gap duration limits in rtcweb-audio. I wo= uld argue that these limits should come from rtcweb-audio draft and referen= ced in WEBRTC TR document. Not the other way around. Do you disagree with this and do you think tone and gap duration limits sho= uld only stay in WEBRTC TR? Regards, _____________ Roman Shpount --_000_SN1PR0301MB155106EB460584246C3F83EDB2BE0SN1PR0301MB1551_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

That they stay only in WEBRTC TC would address my practical concerns. An= d *if* the main argument for the limits is making appellations less error p= rone, i.e. browsers enforcing limits, wouldn't this approach address t= he problem to be solved?


Thanks,

Tolga



From: Roman Shpount <rom= an@telurix.com>
Sent: Friday, March 4, 2016 2:39 PM
To: Harald Alvestrand
Cc: Asveren, Tolga; Ted Hardie; Stefan H=E5kansson LK; rtcweb@ietf.o= rg
Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10= .txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Stand= ard
 
On Fri, Mar 4, 2016 at 5:46 AM, Harald Alves= trand <harald@alvest= rand.no> wrote:
The hard limits are *not* in rtcweb-audio. They're in the WEBRTC WG
(which is a WG of the W3C, not the IETF) API specification.

We are discussing adding tone and gap duration limits in rtcweb-audio.= I would argue that these limits should come from rtcweb-audio draft and re= ferenced in WEBRTC TR document. Not the other way around.

Do you disagree with this and do you think tone and gap duration limit= s should only stay in WEBRTC TR?
 
Regards,
_____________
Roman Shpount
 
--_000_SN1PR0301MB155106EB460584246C3F83EDB2BE0SN1PR0301MB1551_-- From nobody Fri Mar 4 11:50:34 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC161A8901 for ; Fri, 4 Mar 2016 11:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 FNOyQ2m7uckj for ; Fri, 4 Mar 2016 11:50:31 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 176971A88F3 for ; Fri, 4 Mar 2016 11:50:31 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id g203so73362479iof.2 for ; Fri, 04 Mar 2016 11:50:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Z6R+TA9JfZ2wnjfcEEubF3l1pMG254DAL/ro9u23aS4=; b=odaPWlAc+y9PAjbUnT+uZ3FlN01JvFv4WR218afK/oGV/b05HwQQ/TOAnZH1sMr8Pd 4UpG39OLXkG/cEwj0LANWaQMvp9IxZfILn9/xYCOmaL2xg7L6he6y04xh9vM1X+rg/h7 fUZNFihOa1mcpcPdtzx6ZyqeBICLkJlqxGsNqxmZc5RjU9ghjHGaazSA3h8Pjb2YL1QH kpHCPCF2umWWPFpd2hf18436dSsO87JPXR+gdviZwMSzSuRrQkUuPbaGm0uTdmDftrLA fT06TKXkC+rgHlm+YMzwI6fIfe5OofgySWVf6z0RgYe2NttCxtXHUdSJM+Eksu0Y1qbL UqYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Z6R+TA9JfZ2wnjfcEEubF3l1pMG254DAL/ro9u23aS4=; b=B32nRMe1jvNAmftxvXI3RUqS63W4GQO3LjhLehtdv39depuvkcps6Th/FIlLiki68P 1mJ1CDjnzjgc8PB3hrxJXFvx9pzVq8eeeRYG20MPj6CPNHrCOjTbLDMiup5hArpeZX5n kOHCKW1U/xrhWfXt4BSjm6cRurKd3mLtFetu+1QdXNyWY4OMDrTGK3UUo6DOM0BOD2ca rSnFLDlZzAsmhMbskoF5tCcXa6P5XuFNqn1fpuDTRzLLB0AXWbYKScxP6lg5WzKsKGFc gvIgI7PTVPmLY7JeY28R88cLr7ScdvoteS5QcKDSE9vySarrY9w9wWunViRhQIGGMqjk XQvw== X-Gm-Message-State: AD7BkJIS16VCPWv6/drtnh/PXvjzjhxRtPkYfrZF1vu1RXmV4Frkb6/tSiZkDxM8Dgwh7A== X-Received: by 10.107.41.148 with SMTP id p142mr11212351iop.182.1457121030519; Fri, 04 Mar 2016 11:50:30 -0800 (PST) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com. [209.85.213.173]) by smtp.gmail.com with ESMTPSA id x3sm235660igl.11.2016.03.04.11.50.28 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Mar 2016 11:50:28 -0800 (PST) Received: by mail-ig0-f173.google.com with SMTP id i18so3136791igh.1 for ; Fri, 04 Mar 2016 11:50:28 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.30.104 with SMTP id r8mr740408igh.2.1457121028187; Fri, 04 Mar 2016 11:50:28 -0800 (PST) Received: by 10.36.105.77 with HTTP; Fri, 4 Mar 2016 11:50:27 -0800 (PST) In-Reply-To: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> <56D824BD.2080305@alvestrand.no> <56D86A45.70406@alvestrand.no> <56D9678C.5050405@alvestrand.no> Date: Fri, 4 Mar 2016 14:50:27 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=047d7bdca2ec47b1df052d3e6df7 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 19:50:32 -0000 --047d7bdca2ec47b1df052d3e6df7 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 4, 2016 at 2:47 PM, Asveren, Tolga wrote: > That they stay only in WEBRTC TC would address my practical concerns. And > *if* the main argument for the limits is making appellations less error > prone, i.e. browsers enforcing limits, > W3C WEBRTC working group is not the right to group define the acceptable limits for DTMF tone duration. They can determine that API needs to have a valid parameter range but defining the range should be in IETF. _____________ Roman Shpount --047d7bdca2ec47b1df052d3e6df7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 4, 2016 at 2:47 PM, Asveren, Tolga <<= a href=3D"mailto:tasveren@sonusnet.com" target=3D"_blank">tasveren@sonusnet= .com> wrote:

That they stay only in WEBRTC TC would address my practical concerns. An= d *if* the main argument for the limits is making appellations less error p= rone, i.e. browsers enforcing limits,=C2=A0

W3C WEBRTC working group is not the right to group define the acceptable = limits for DTMF tone duration. They can determine that API needs to have a = valid parameter range but defining the range should be in IETF.
<= div class=3D"gmail_signature">_____________
Roman Shpount
=C2=A0
--047d7bdca2ec47b1df052d3e6df7-- From nobody Fri Mar 4 11:55:44 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56ACB1A8902 for ; Fri, 4 Mar 2016 11:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 kh6-8ajqcTdh for ; Fri, 4 Mar 2016 11:55:41 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B9431A8901 for ; Fri, 4 Mar 2016 11:55:41 -0800 (PST) Received: by mail-ig0-x230.google.com with SMTP id i18so3231700igh.1 for ; Fri, 04 Mar 2016 11:55:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=cHEYqkLjp5XpRKxRobDa0O9MB9RLvVS7/em7iZh/DXw=; b=aXDcC6viRyfLTdv1MHQTWtSrziFy89y9VQRFBNyiJ2+j+8XkwQfErgpiIjVDqc/VGk BvQUO+QrTHTZ69e500Zq9v80kKDxrcBlXNtCC8ikJhHbodCE62oExxBG/npcPZD34TSk FlH+eMKlDh9E9CVgukTZBljSYkhW2kfswJvGdfcPmId36gbw+A+WgutFZvNWle5EROFd HfD4Ox7ZpAvIQBaPofaWyDreUkUU/Ppxp8TsIxfeEiy64KXIyI23GhHCLOsI8jbCxPAb UUAHCJ/JFO64kMMemr0cXyqXwuMrtp52QVrgZ+6zhz/B+u6CL9knaveyZDvOup2OFkiM FYPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=cHEYqkLjp5XpRKxRobDa0O9MB9RLvVS7/em7iZh/DXw=; b=VCYanpv0WGbj5ADP+ahflylllSR43vl9f+d4KRHSVFpQg5b0hZp2stCb4fs9cdui/l 6pY9Bp1o1ZdnBVyZi2Q6wAF6IXhgKJF8oGhhbdKC/byV2MFipBb1wmkJneDehbeAyXXq KhMHvGBMZfboLECFkAUvIR89V1wez177ZsDDook7CHxp0huB28ePIEl1pSuyMzhLcGWp 1kpFUmJI6JJdYJQdPkbCevLqt9SGCNbQ680ySfVlAHkQ9cQ3L/b2SekfnOcN+uYazQhZ wHj1+D2oUm613N18EEEj1qLxA193sq7j78LQ3Kj/rwQ5e1C+1ef881xJJ6dAWqwSmTey eEVA== X-Gm-Message-State: AD7BkJLuFrzMFOCZLGiAwoDgXeFnz8GnPZOwFjE3KDDbUJrMceFjhI/L6VgiqLwKVHPOpQ== X-Received: by 10.50.109.196 with SMTP id hu4mr735698igb.24.1457121340974; Fri, 04 Mar 2016 11:55:40 -0800 (PST) Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com. [209.85.213.177]) by smtp.gmail.com with ESMTPSA id j9sm1961769iof.1.2016.03.04.11.55.39 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Mar 2016 11:55:39 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id i18so3231062igh.1 for ; Fri, 04 Mar 2016 11:55:39 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.30.104 with SMTP id r8mr759770igh.2.1457121338669; Fri, 04 Mar 2016 11:55:38 -0800 (PST) Received: by 10.36.105.77 with HTTP; Fri, 4 Mar 2016 11:55:38 -0800 (PST) In-Reply-To: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D55FE9.60408@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> <56D824BD.2080305@alvestrand.no> <56D86A45.70406@alvestrand.no> Date: Fri, 4 Mar 2016 14:55:38 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=047d7bdca2ecc9490a052d3e7fc9 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 19:55:43 -0000 --047d7bdca2ecc9490a052d3e7fc9 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 4, 2016 at 5:34 AM, Asveren, Tolga wrote: > i- I don't think satisfactory technical explanation is provided why > "enforcing a range" is superior to a "default range". I will leave this > here and obviously this is just my personal -but honest- opinion. > Having well defined limits simplifies interop. Most of existing systems break down with tones below or above certain length. This way you can validate that tones from 40 ms to 8 sec are correctly delivered by the network. > iii- Just as an example, I am aware of systems, which can detect digits > <40ms. > What systems? It is physically impossible to detect DTMF tone of duration less then 40 ms in 8KHz tone and satisfy the original bellcore talk-off specification. There are some PSTN gateways that detect shorter tones, but they usually have a higher then acceptable talk-off error rate on general speech. iv- What about the gap between the final packet (with E-bit set) > retransmissions? > The gap between final packets is not even discussed here. We are not discussing the duration values or re-transmit intervals for RFC 4733 packets. We are only discussing overall duration of the DTMF tones and gaps between them. It is up to an application to pick the interval for transmitting RFC 4733 tone updates or final packets. Furthermore, web browsers will not process RFC 4733 packets (except processing necessary to safely discard them). This specification only limits the tone and gap duration for tones generated by web browsers. > v- As use cases for the need for longer duration (all these are based on > the same deployment model: A "legacy" application controlled by phone needs > to be extended so that it can be accessed by Internet connected devices, > e.g. a web-book. DataChannel is not used, e.g. not supported by gateway, by > application etc..., hence digits are used for control. > > - TV gaming show > User registers for the game and is selected for that day's show. > The user sees what is happening on the game on his TV and controls it by > digits > The game (balloon escape) requires that at the beginning the user pumps > air into the balloon. This is done by continuously pressing "5" > All long duration DTMF digits break into several tones. The application you described typically considers several identical DTMF tones separated by less then predefined gap duration a single tone. It probably makes sense to note, that support for such application is impossible from the current WebRTC API which only allows to play DTMF tone of predefined length. To implement this application you need start play tone/stop play tone API which is not provided. - Remote valve/door/lock control > Authorized person makes a call and then continuously presses "6" to keep > the valve/door/lock open for that period. > Same not as above applies here. - Panic button > An application for women who are mistreated by their husbands. > Police/Social service workers rush to the registered address if she presses > "7" continuously for longer than 10 seconds. > The "long press" for DTMF one is typically 1-4 sec. Most of current PSTN networks will not pass a tone longer then 8 sec as a single tone due to RFC 2833 tone duration limitation. > I am just trying to show that there are many different/imaginative ways > using the "digit UI". > Unfortunately application you are referring to are unimplementable using WebRTC. Regards, _____________ Roman Shpount --047d7bdca2ecc9490a052d3e7fc9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 4, 2016 at 5:34 AM, Asveren, Tolga <<= a href=3D"mailto:tasveren@sonusnet.com" target=3D"_blank">tasveren@sonusnet= .com> wrote:
i- I don't think satisfactory technical explanation is provi= ded why "enforcing a range" is superior to a "default range&= quot;. I will leave this here and obviously this is just my personal -but h= onest- opinion.

Having well defined lim= its simplifies interop. Most of existing systems break down with tones belo= w or above certain length. This way you can validate that tones from 40 ms = to 8 sec are correctly delivered by the network.
=C2=A0
iii- Just as an example, I am aware of systems, which can dete= ct digits <40ms.
=C2=A0
What systems? It = is physically impossible to detect DTMF tone of duration less then 40 ms in= 8KHz tone and satisfy the original bellcore talk-off specification. There = are some PSTN gateways that detect shorter tones, but they usually have a h= igher then acceptable talk-off error rate on general speech.

=
iv- What about the gap between the final packet (wit= h E-bit set) retransmissions?

The gap b= etween final packets is not even discussed here. We are not discussing the = duration values or re-transmit intervals for RFC 4733 packets. We are only = discussing overall duration of the DTMF tones and gaps between them. It is = up to an application to pick the interval for transmitting RFC 4733 tone up= dates or final packets.

Furthermore, web browsers = will not process RFC 4733 packets (except processing necessary to safely di= scard them). This specification only limits the tone and gap duration for t= ones generated by web browsers.
=C2=A0
v- As use cases for the need for longer duration (all these are based on th= e same deployment model: A "legacy" application controlled by pho= ne needs to be extended so that it can be accessed by Internet connected de= vices, e.g. a web-book. DataChannel is not used, e.g. not supported by gate= way, by application etc..., hence digits are used for control.

- TV gaming show
User registers for the game and is selected for that day's show.
The user sees what is happening on the game on his TV and controls it by di= gits
The game (balloon escape) requires that at the beginning the user pumps air= into the balloon. This is done by continuously pressing "5"
<= /blockquote>
=C2=A0
All long duration DTMF digits break into = several tones. The application you described typically considers several id= entical DTMF tones separated by less then predefined gap duration a single = tone.

It probably makes sense to note, that suppor= t for such application is impossible from the current WebRTC API which only= allows to play DTMF tone of predefined length. To implement this applicati= on you need start play tone/stop play tone API which is not provided.
=

- Remote valve/door/lock control
Authorized person makes a call and then continuously presses "6" = to keep the valve/door/lock open for that period.
=C2= =A0
Same not as above applies here.

- Panic button
An application for women who are mistreated by their husbands. Police/Socia= l service workers rush to the registered address if she presses "7&quo= t; continuously for longer than 10 seconds.
=C2=A0
The "long press" for DTMF one is typically 1-4 sec. Most o= f current PSTN networks will not pass a tone longer then 8 sec as a single = tone due to RFC 2833 tone duration limitation.
=C2=A0
I am just trying to show that there are many different/imaginati= ve ways using the "digit UI".

Unfortunately application you are referring to are unimplementable using W= ebRTC.

Regards,
_____________
Roman Shpount
=C2=A0
--047d7bdca2ecc9490a052d3e7fc9-- From nobody Fri Mar 4 12:14:15 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9912C1A893B for ; Fri, 4 Mar 2016 12:14:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham 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 0akwAZijDfM1 for ; Fri, 4 Mar 2016 12:14:11 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0057.outbound.protection.outlook.com [207.46.100.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6A51A894E for ; Fri, 4 Mar 2016 12:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gTzEaJe3Oqbv4bqnQ0STCnf7E05cRBX8QxRFSDjFUHY=; b=P6QRaqnvko1ufhHeYvr2ZmPi95DPO2qMZ8c0P9U2yxlniEJtSCufdCzd3k8H2hwUd6WumUaVzfMJsjvf6gyPR+eCCWvHrX+Sewj8HCYBHFlNdEw2HhwTJbMPxVi2qX75dYyOnzC6NdAlUASCMtRNS54B5Ey5uxJNnPPcV6eWe9A= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.427.16; Fri, 4 Mar 2016 20:14:10 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0409.024; Fri, 4 Mar 2016 20:14:10 +0000 From: "Asveren, Tolga" To: Roman Shpount Thread-Topic: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard Thread-Index: AQHRb/eiM09Ybg6t2Eavei5prgOW+p9EeOUQgAB4VQCAAAJvQIAABQwAgAAAciCAAdggAIAAwScAgAATEICAAEfAgIAACySAgAEinnCAAAtQAIAAlMSAgAACCL2AAAEngIAABZm6 Date: Fri, 4 Mar 2016 20:14:10 +0000 Message-ID: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> <56D824BD.2080305@alvestrand.no> <56D86A45.70406@alvestrand.no> <56D9678C.5050405@alvestrand.no> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alvestrand.no; dkim=none (message not signed) header.d=none; alvestrand.no; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 64918898-1984-4d15-4aaf-08d344698c3d x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:A9yrivDfTFGd4HhuRynB1hyHzHiLNVyVHCu3NXbIYBIZqlJywqi15npRDz477hMy9nftITaoC/8l6xccYGQ277SCw7uWCG3gVkK7Y7fAVYKyzyvMLFayqa5Zc7J093zYNMHfk6OsvC3LOpdytl1jng==; 24:o8vkdV6nQ1Jyv1Zf9UhmI9vfsz94zIJEjGnTcQt/bw7A6DGi4n3oRJHvwInMw3tF4ovltJSFWLxs0IJ9YDCLtO6GjDhNN0DUUMDaECvxOOY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 0871917CDA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(164054003)(377454003)(2473001)(10400500002)(74316001)(40100003)(106116001)(3900700001)(66066001)(189998001)(110136002)(2906002)(5008740100001)(230783001)(3660700001)(16236675004)(19625215002)(4326007)(122556002)(54356999)(50986999)(19627405001)(76576001)(76176999)(33656002)(3280700002)(86362001)(1220700001)(1096002)(92566002)(19580405001)(586003)(19580395003)(3846002)(102836003)(6116002)(93886004)(87936001)(2900100001)(2950100001)(5003600100002)(11100500001)(5002640100001)(81166005)(77096005)(5004730100002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551701D6CFA3BC5B8BF9549B2BE0SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2016 20:14:10.2735 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Fwd: Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 20:14:13 -0000 --_000_SN1PR0301MB1551701D6CFA3BC5B8BF9549B2BE0SN1PR0301MB1551_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Considering different points in your replies (please keep me honest if I mi= sread/misinterpreted anything) that you think limit should be defined in RT= CWeb WG but should be applicable only for digits generated by browsers. Tha= t sounds good to me (defining the limit only on API level in W3C is fine fr= om my perspective too). Thanks, Tolga ________________________________ From: Roman Shpount Sent: Friday, March 4, 2016 2:50 PM To: Asveren, Tolga Cc: Harald Alvestrand; Ted Hardie; Stefan H=E5kansson LK; rtcweb@ietf.org Subject: Re: [rtcweb] Fwd: Last Call: (Web= RTC Audio Codec and Processing Requirements) to Proposed Standard On Fri, Mar 4, 2016 at 2:47 PM, Asveren, Tolga > wrote: That they stay only in WEBRTC TC would address my practical concerns. And *= if* the main argument for the limits is making appellations less error pron= e, i.e. browsers enforcing limits, W3C WEBRTC working group is not the right to group define the acceptable li= mits for DTMF tone duration. They can determine that API needs to have a va= lid parameter range but defining the range should be in IETF. _____________ Roman Shpount --_000_SN1PR0301MB1551701D6CFA3BC5B8BF9549B2BE0SN1PR0301MB1551_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Considering different points in your replies (please keep me honest if I= misread/misinterpreted anything) that you think limit should be defined in= RTCWeb WG but should be applicable only for digits generated by browsers. = That sounds good to me (defining the limit only on API level in W3C is fine from my perspective too).


Thanks,

Tolga



From: Roman Shpount <rom= an@telurix.com>
Sent: Friday, March 4, 2016 2:50 PM
To: Asveren, Tolga
Cc: Harald Alvestrand; Ted Hardie; Stefan H=E5kansson LK; rtcweb@iet= f.org
Subject: Re: [rtcweb] Fwd: Last Call: <draft-ietf-rtcweb-audio-10= .txt> (WebRTC Audio Codec and Processing Requirements) to Proposed Stand= ard
 
On Fri, Mar 4, 2016 at 2:47 PM, Asveren, Tol= ga <tasveren@son= usnet.com> wrote:

That they stay only in WEBRTC TC would address my practical concerns. An= d *if* the main argument for the limits is making appellations less error p= rone, i.e. browsers enforcing limits, 

W3C WEBRTC working group is not the right to group define the acceptab= le limits for DTMF tone duration. They can determine that API needs to have= a valid parameter range but defining the range should be in IETF.
_____________
Roman Shpount
 
--_000_SN1PR0301MB1551701D6CFA3BC5B8BF9549B2BE0SN1PR0301MB1551_-- From nobody Sat Mar 5 14:44:42 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3631A8F37 for ; Sat, 5 Mar 2016 14:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 3FmcPxlRRlrg for ; Sat, 5 Mar 2016 14:44:39 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE661A90DB for ; Sat, 5 Mar 2016 14:44:39 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B89A920706 for ; Sat, 5 Mar 2016 17:44:38 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Sat, 05 Mar 2016 17:44:38 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=28K INR0kzBEKfUT+TTI92+l219o=; b=bHXV9Neuy41ilnQobsESelWIGqFad6GUNed V0JHn/3EfRK8bXmfyQIm3vIucFCH679LSVr4mMGLTgjccq9TOuwDpNyW+a+Er392 6BnzmKIFsC9B0+gG9FLOzCrXY0KLi/FhqRwIqTjrMPlxEc0kEiRlpiLsuInXcKnR T5jKPwzs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=28KINR0kzBEKfUT+TTI92+l219o=; b=gZqKZ rLiGniUutTuUX9bGRrUvx2JqOY/2bO1+uVGd/7oibc/5Zw0pZSncfPg16b078ADP tds81d8NnAMlYRL6CHFWmIVAx85qcFtwHNdkJf9Ee4kol32u5D8JDyvLYNgfbtQK lmf7MbUaRtZd6nedBi+OvUvY9Fv2Veqd65qcc0= X-Sasl-enc: YC7yjM0NHZWalHSgTDvYi4D9AmpGdg/R2k2287x7m3nT 1457217869 Received: from [192.168.100.235] (unknown [199.168.151.104]) by mail.messagingengine.com (Postfix) with ESMTPA id 4AA246801E3 for ; Sat, 5 Mar 2016 17:44:29 -0500 (EST) From: Alissa Cooper Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <6B474A50-6399-472F-BD7B-5286DCD209BA@cooperw.in> Date: Sat, 5 Mar 2016 22:44:22 +0000 To: rtcweb@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [rtcweb] AD evaluation: draft-ietf-rtcweb-alpn-02 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 22:44:41 -0000 I have reviewed this draft in preparation for IETF LC. I have a couple = of questions and comments that should be resolved before IETF LC, and = some nits. Comments/questions: =3D General =3D =E2=80=9CConfidentiality protection=E2=80=9D is a fairly general term, = but it seems to be used throughout this document to mean something much = more specific, i.e., media that is confidential to two peers in a webrtc = connection. I think this needs to be clarified in the abstract and = Sections 1, 2, and 5 where the more specific meaning is intended. = Otherwise this document makes it sound as though data is being sent in = the clear when it is not. E.g., in Section 2 this text should be more = specific to confidentiality vis a vis the application: "However, data = provided over data channels does not receive confidentiality = protection.=E2=80=9D=20 =3D Section 3 =3D "Any entity that forwards content, or records content for later access by entities other than the authenticated peer, SHOULD NOT offer or accept a session with the "c-webrtc" identifier.=E2=80=9D Acknowledging the there are other recommendations in this draft that = basically up to the implementation to follow, why is this requirement a = SHOULD NOT rather than a MUST NOT? Nits: =3D Section 1.1 =3D Since this document uses RFC 2119 keywords, why does it not include the = standard disclaimer recommended by RFC 2119? I think it=E2=80=99s fine = to add further words to indicate that the normative requirements are = aimed at implementation behavior, but the standard text shouldn=E2=80=99t = be omitted. Also, I=E2=80=99m not sure what it means for the document to "fall back = on shorthands for establishing interoperability requirements on = implementations.=E2=80=9D What is the alternative that it is falling = back from?=20 =3D Section 2 =3D s/a Secure/Secure/ =3D Section 3 =3D s/between session/between a session/ =3D Section 4 =3D s/This is not a digital rights management mechanism./The mechanism = specified in this document is not a digital rights management = mechanism./ Cute, but suggest deleting this as it seems superfluous: "In other = cases, effects might not be temporally localized: transmitted smells could linger for a period after communications cease.=E2=80=9D =3D Section 6.3 =3D Is there a reason this reference is listed this way? From nobody Mon Mar 7 02:47:47 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEDD71B3E85 for ; Mon, 7 Mar 2016 02:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 SasnoDQUT6Dz for ; Mon, 7 Mar 2016 02:47:44 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFED11B3DF2 for ; Mon, 7 Mar 2016 02:47:43 -0800 (PST) Received: (qmail 90224 invoked from network); 7 Mar 2016 10:47:42 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 3490 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 7 Mar 2016 10:47:42 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 244B018A0A5D; Mon, 7 Mar 2016 10:47:42 +0000 (GMT) Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 136DC18A0A86; Mon, 7 Mar 2016 10:47:42 +0000 (GMT) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id EB63D18A0A5D; Mon, 7 Mar 2016 10:47:41 +0000 (GMT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Panton In-Reply-To: Date: Mon, 7 Mar 2016 10:47:41 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D55FE9.60408@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> <56D824BD.2080305@alvestrand.no> <56D86A45.70406@al vestrand.no> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [rtcweb] Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 10:47:46 -0000 > On 4 Mar 2016, at 19:55, Roman Shpount wrote: >=20 > On Fri, Mar 4, 2016 at 5:34 AM, Asveren, Tolga = wrote: > i- I don't think satisfactory technical explanation is provided why = "enforcing a range" is superior to a "default range". I will leave this = here and obviously this is just my personal -but honest- opinion. >=20 =E2=80=A6. snip=E2=80=A6.=20 > It probably makes sense to note, that support for such application is = impossible from the current WebRTC API which only allows to play DTMF = tone of predefined length. To implement this application you need start = play tone/stop play tone API which is not provided. >=20 > - Remote valve/door/lock control > Authorized person makes a call and then continuously presses "6" to = keep the valve/door/lock open for that period. > =20 > Same not as above applies here. >=20 > - Panic button > An application for women who are mistreated by their husbands. = Police/Social service workers rush to the registered address if she = presses "7" continuously for longer than 10 seconds. > =20 > The "long press" for DTMF one is typically 1-4 sec. Most of current = PSTN networks will not pass a tone longer then 8 sec as a single tone = due to RFC 2833 tone duration limitation. > =20 > I am just trying to show that there are many different/imaginative = ways using the "digit UI". >=20 > Unfortunately application you are referring to are unimplementable = using WebRTC. Actually they are all implementable with webRTC - if combined with = webAudio. You just generate the DTMF tones with webAudio, mix (as appropriate) = with the mic signal and then inject the result into the outgoing using=20 AudioContext.createMediaStreamDestination() and friends. We could add a caveat that all the DTMF apis are optional if the browser = also implements webAudio. As it is possible to write a a javascript polyfill that = implements the current api in=20 terms of webaudio, which should be adequate for the legacy compatibility = needs. Also we should add a note that _all_ these sorts of usages would be = better served by carrying the data over the DataChannel, DTMF is for legacy interop only. Tim. From nobody Mon Mar 7 02:48:25 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82BEE1B3E8A for ; Mon, 7 Mar 2016 02:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 aBOFwiZmOhFS for ; Mon, 7 Mar 2016 02:48:23 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FC21B2B13 for ; Mon, 7 Mar 2016 02:48:22 -0800 (PST) Received: (qmail 88583 invoked from network); 7 Mar 2016 10:48:21 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 3502 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 7 Mar 2016 10:48:21 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 273B318A0A5D for ; Mon, 7 Mar 2016 10:48:21 +0000 (GMT) Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 18C5018A0A86 for ; Mon, 7 Mar 2016 10:48:21 +0000 (GMT) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 0D4C018A0A5D for ; Mon, 7 Mar 2016 10:48:21 +0000 (GMT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Panton In-Reply-To: Date: Mon, 7 Mar 2016 10:48:20 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <942769E1-6782-4933-B4C8-2F52D36CAFCB@phonefromhere.com> References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> <56D824BD.2080305@alvestrand.no> <56D86A45.70406@alvestrand.no> <56D9678C.5050405@ alvestrand.no> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [rtcweb] Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 10:48:24 -0000 > On 4 Mar 2016, at 11:33, Martin Thomson = wrote: >=20 > This thread has gone on too long. Since it is so hard to reach agreement on DTMF perhaps we could shelve=20= all support for it =E2=80=98till after 1.0, then we can gain experience = of actual requirements (if any). T.= From nobody Mon Mar 7 03:10:43 2016 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841C41B3EDA for ; Mon, 7 Mar 2016 03:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 8mQvkxw6tyHJ for ; Mon, 7 Mar 2016 03:10:40 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC7A1B3ED9 for ; Mon, 7 Mar 2016 03:10:39 -0800 (PST) Received: (qmail 22523 invoked from network); 7 Mar 2016 11:10:37 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 3968 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 7 Mar 2016 11:10:37 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id C834818A02F3; Mon, 7 Mar 2016 11:10:37 +0000 (GMT) Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id B97FC18A05A2; Mon, 7 Mar 2016 11:10:37 +0000 (GMT) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id A673618A02F3; Mon, 7 Mar 2016 11:10:37 +0000 (GMT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Panton In-Reply-To: Date: Mon, 7 Mar 2016 11:10:37 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9618BC5B-64AF-4285-AFC0-F7A5265E1B08@phonefromhere.com> References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D55FE9.60408@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> <56D824BD.2080305@alvestrand.no> <56D86A45.70406@al vestrand.no> To: Tim Panton X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 11:10:41 -0000 > On 7 Mar 2016, at 10:47, Tim Panton wrote: >=20 >=20 >> On 4 Mar 2016, at 19:55, Roman Shpount wrote: >>=20 >> On Fri, Mar 4, 2016 at 5:34 AM, Asveren, Tolga = wrote: >> i- I don't think satisfactory technical explanation is provided why = "enforcing a range" is superior to a "default range". I will leave this = here and obviously this is just my personal -but honest- opinion. >>=20 > =E2=80=A6. snip=E2=80=A6.=20 >> It probably makes sense to note, that support for such application is = impossible from the current WebRTC API which only allows to play DTMF = tone of predefined length. To implement this application you need start = play tone/stop play tone API which is not provided. >>=20 >> - Remote valve/door/lock control >> Authorized person makes a call and then continuously presses "6" to = keep the valve/door/lock open for that period. >>=20 >> Same not as above applies here. >>=20 >> - Panic button >> An application for women who are mistreated by their husbands. = Police/Social service workers rush to the registered address if she = presses "7" continuously for longer than 10 seconds. >>=20 >> The "long press" for DTMF one is typically 1-4 sec. Most of current = PSTN networks will not pass a tone longer then 8 sec as a single tone = due to RFC 2833 tone duration limitation. >>=20 >> I am just trying to show that there are many different/imaginative = ways using the "digit UI". >>=20 >> Unfortunately application you are referring to are unimplementable = using WebRTC. >=20 > Actually they are all implementable with webRTC - if combined with = webAudio. > You just generate the DTMF tones with webAudio, mix (as appropriate) = with the mic signal and then > inject the result into the outgoing using=20 > AudioContext.createMediaStreamDestination() > and friends. >=20 > We could add a caveat that all the DTMF apis are optional if the = browser also implements > webAudio. As it is possible to write a a javascript polyfill that = implements the current api in=20 > terms of webaudio, which should be adequate for the legacy = compatibility needs. And as proof by example : = https://hacks.mozilla.org/2015/11/webrtc-sending-dtmf-in-firefox/ (thanks to Adam Roach for the code and Philipp Hancke for pointing it = out)-=20 I=E2=80=99d done a simpler version some years ago in phonoSDK -=20 = https://github.com/phono/PhonoSDK/commit/d6bb7ca54402aba3c0dd34dbd1912731f= 5af111b >=20 > Also we should add a note that _all_ these sorts of usages would be = better served by > carrying the data over the DataChannel, DTMF is for legacy interop = only. >=20 > Tim. From nobody Mon Mar 7 10:35:58 2016 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0BF601CD81F for ; Mon, 7 Mar 2016 10:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koeUtmgHk4DR for ; Mon, 7 Mar 2016 10:35:56 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 1B47F1CD820 for ; Mon, 7 Mar 2016 10:35:56 -0800 (PST) Received: by mail-ig0-x230.google.com with SMTP id hb3so47278806igb.0 for ; Mon, 07 Mar 2016 10:35:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=bQPDoDaylZZkN4guyynySxTRqnd5iHCDe/2f7ERwvDw=; b=TjC/JxU1D2SbEqc9+f/5zYRjl1jHZptwnVZOZtqP1/heZY/vQOs468AuMPbwBLzfin aruehWM3xx7k5KEmX2EfsFWTXfGj+sQL2NRPb6oW9uskZoOcSj7BEuxzj9nqzD1vV/O0 Ew9ymVnAmhNqhEPFTGbdvrlzdd2/iMl/naHLoe3baF6037YwwG2W2ZtgiJm2JlzJPCMs k2UjjO+mb/jt+D0TIpoTRHqlTLjvPIT7/jYfBgoR+lunTYhVGs29lsowvlZL+nAodPAC O8EKe6fJO7qjrrayJej/+9OiqJeMKEq3KXfzGXR4aNSwY13dIqFcI+xAvDdTMAMoyfVx 8cow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=bQPDoDaylZZkN4guyynySxTRqnd5iHCDe/2f7ERwvDw=; b=e80WzEX62ppQaW3rb400orAKA8ZRarfDzhAb6/fNz+vvwu6lmQshPJjWbbNWFoN3Lg B7Kg2SYZtuLgil3kw3xRCBDIh1R16K5mWXoEZECkx6kFyivBOLlvZXo4iKe7BidSFipp qzwR4rli2TE2XIazspJ8IK+Qu7dn7ABwSutHXECJhS9vVqQE5M07mayh+YNac6aIC/ht Q+G9WtKvynKyByHDtK7V1YOSVYyxhRJ0FBOmxZmudliXhXkZOsq9OcLMdM9i48rMRcoZ Gz1AHHF7XFWQHTsCCDRzVy3mtHa0ir3/r6Scwow0gKaAh1W0lFdgC9FNlv89vV2Ndm0A sFNw== X-Gm-Message-State: AD7BkJIbfzfgsQ0rkrwCVoS/DZASQHFK255eT7UZSBFj7uK4JFRiRxrPD9AEYcoBwWCE2Q== X-Received: by 10.50.131.233 with SMTP id op9mr14076959igb.0.1457375755448; Mon, 07 Mar 2016 10:35:55 -0800 (PST) Received: from mail-io0-f182.google.com (mail-io0-f182.google.com. [209.85.223.182]) by smtp.gmail.com with ESMTPSA id m7sm6852382ioa.42.2016.03.07.10.35.53 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2016 10:35:53 -0800 (PST) Received: by mail-io0-f182.google.com with SMTP id g203so141256901iof.2 for ; Mon, 07 Mar 2016 10:35:53 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.157.70 with SMTP id g67mr20665616ioe.38.1457375752909; Mon, 07 Mar 2016 10:35:52 -0800 (PST) Received: by 10.36.105.77 with HTTP; Mon, 7 Mar 2016 10:35:52 -0800 (PST) In-Reply-To: References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D55FE9.60408@alvestrand.no> <1447FA0C20ED5147A1AA0EF02890A64B374B9596@ESESSMB209.ericsson.se> <56D824BD.2080305@alvestrand.no> Date: Mon, 7 Mar 2016 13:35:52 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Tim Panton Content-Type: multipart/alternative; boundary=001a1140b4720e8552052d79bcd1 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 18:35:57 -0000 --001a1140b4720e8552052d79bcd1 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 7, 2016 at 5:47 AM, Tim Panton wrote: > Actually they are all implementable with webRTC - if combined with > webAudio. > You just generate the DTMF tones with webAudio, mix (as appropriate) with > the mic signal and then > inject the result into the outgoing using > AudioContext.createMediaStreamDestination() > and friends. > > We could add a caveat that all the DTMF apis are optional if the browser > also implements > webAudio. As it is possible to write a a javascript polyfill that > implements the current api in > terms of webaudio, which should be adequate for the legacy compatibility > needs. > > Also we should add a note that _all_ these sorts of usages would be better > served by > carrying the data over the DataChannel, DTMF is for legacy interop only. > > This would be really unwise. DTMF generated as inband media is not delivered by all codecs. Inband DTMF has much higher error rate then RFC 4733 in case of packet loss. Not supporting RFC 4733 will negatively affect interop. P.S. We already spent more time discussing DTMF then it would take to implement it. _____________ Roman Shpount --001a1140b4720e8552052d79bcd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 7, 2016 at 5:47 AM, Tim Panton <tim@phonefromhere.com><= /span> wrote:
Actually they are all implementable with = webRTC - if combined with webAudio.
You just generate the DTMF tones with webAudio, mix (as appropriate)=C2=A0 = with the mic signal and then
inject the result into the outgoing using
AudioContext.createMediaStreamDestination()
and friends.

We could add a caveat that all the DTMF apis are optional if the browser al= so implements
webAudio. As it is possible to write a a javascript polyfill that implement= s the current api in
terms of webaudio, which should be adequate for the legacy compatibility ne= eds.

Also we should add a note that _all_ these sorts of usages would be better = served by
carrying the data over the DataChannel, DTMF is for legacy interop only.

This would be really unwise. DTMF generated as inband medi= a is not delivered by all codecs. Inband DTMF has much higher error rate th= en RFC 4733 in case of packet loss. Not supporting RFC 4733 will negatively= affect interop.

P.S. We already spent more time d= iscussing DTMF then it would take to implement it.
_____________
Roman Shpount
=C2=A0
--001a1140b4720e8552052d79bcd1-- From nobody Mon Mar 7 10:57:37 2016 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A9D1A1CD8F1 for ; Mon, 7 Mar 2016 10:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoTiCPXnWyxw for ; Mon, 7 Mar 2016 10:57:33 -0800 (PST) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 24C571CD8F0 for ; Mon, 7 Mar 2016 10:57:32 -0800 (PST) Received: by mail-pf0-x231.google.com with SMTP id 129so40229885pfw.1 for ; Mon, 07 Mar 2016 10:57:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=NaKjVuPwIwZQQqC+KYtK23Tj07xty04TTY/FlUoiSv4=; b=h4+qrag5hqBchzBYJy0bJy1hquc4pFBCYvaPdNC4DEh1R1t5Rm0vO7WW6vMyS74BXc GKxjwGKbEOYvMmziTkIyoM1RrNwfI4SUFvGldfXs4ieZs0NW9nbpxb6cnCl4Z6+r8VW5 aSIlmId4h66wJ6G7QxhgOWJPlmfm+cq7wkjnyyN0N5C/8S3alwF0ayL944ydVUTXF4Zy MtewHYLfGwgMsFGZ+zs43vCSvTgP/eYwV8OOP8e5d2kO5XWR+grljufJL0OnEhVDHUQ4 A1VIXqdl87/l21cvpirAH7lgk1m5LlU2/VdVbk5fgOrF+y7x0BIBPhyBl/iofje+0Uns sYWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=NaKjVuPwIwZQQqC+KYtK23Tj07xty04TTY/FlUoiSv4=; b=WoR2HxeUH/r9xjFrS0mTxXtRL19Io4AavKLqbPsUYBkzUJFpIJSlHXzZE/vltnauM/ cXxnb5CmkpR3MLjvsmc+Pa/NNOcbETekSPmhmm86jkWAHtuVhXCWwj09J5+A538Q4DJU gIdXeVDC8hmR9SQVoUNc2tDU32YZssgbAMEf5kbs5dWuHpCp4TRh9oqgVRmk6gBfk4kU 305s9SEYmgFbjedlH2USl84N92SDcvMHQ2586VWR7TjuaxJQdTelFVtwmF+Yq5YGrYy7 bq/tEg3NR3JqBfxUYO26NHKCUV3nRqDTwiuR58F1ttfFxCVLRZ0kiTFzNv3tOSvqaZL+ m00w== X-Gm-Message-State: AD7BkJJw6JaXtTLa479BageqhIEm8KsqYOI0Xt+bu9MG4mywAHTkjpGf5ytXip96iivuqTqT X-Received: by 10.98.72.193 with SMTP id q62mr35952960pfi.117.1457377052472; Mon, 07 Mar 2016 10:57:32 -0800 (PST) Received: from panoramix.jmvalin.ca ([2620:101:80fc:224:7e7a:91ff:fe20:963f]) by smtp.gmail.com with ESMTPSA id tb10sm25841772pab.22.2016.03.07.10.57.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2016 10:57:30 -0800 (PST) To: Tim Panton , "rtcweb@ietf.org" References: <20160224213121.376.85278.idtracker@ietfa.amsl.com> <56D824BD.2080305@alvestrand.no> <56D86A45.70406@alvestrand.no> <56D9678C.5050405@ alvestrand.no> <942769E1-6782-4933-B4C8-2F52D36CAFCB@phonefromhere.com> From: Jean-Marc Valin Message-ID: <56DDCF19.40201@mozilla.com> Date: Mon, 7 Mar 2016 13:57:29 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <942769E1-6782-4933-B4C8-2F52D36CAFCB@phonefromhere.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] Last Call: (WebRTC Audio Codec and Processing Requirements) to Proposed Standard X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 18:57:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/07/2016 05:48 AM, Tim Panton wrote: > Since it is so hard to reach agreement on DTMF perhaps we could > shelve all support for it ‘till after 1.0, then we can gain > experience of actual requirements (if any). Let's not throw the baby out with the bath water. So far there's agreement on most of the content. I think everyone agrees with the lower bound on the DTMF duration and gap (without it bad things will happen), so it's all down to whether there should be an upper bound. My personal opinion is that a 6-8 second limit is reasonable and would avoid problems, but it's not worth giving up on DTMF just for this issue . Cheers, Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW3c8WAAoJEJ6/8sItn9q9V2kH/0Kk9KRtrlnGiKJK7mUBZ8NH M2qL8DdRJFc2EWzdAYGzAqrq3usT4gZu+LAAuxbWF6nJVvQ6+IuFcJci9h7L2r+T UAUPnL3MHw6m2r8OA0jbX8OEQW7kZnueAen4xqANmc+XyDd28wLyV5J3R1IKt+34 3kqNBWKu0NHMwfKJKEctlBkw7xaLhUTP6/CfbSSWe8kRcNssJouLf7Tw5D3eywGi bDelkQ/S6bLI55O27wTAkSPx93zhxW2WiK3Ul6gDO9PZJFJVl9nNQa0qfojJ7UF0 +Xqa3PnJp1htvY+DheSJQxCXFdQIB8A9bhzg4JFKEmSlKvwfKPUAnM+ZQkff7GU= =BEU0 -----END PGP SIGNATURE----- From nobody Mon Mar 7 12:36:13 2016 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 69AAD1CDB39 for ; Mon, 7 Mar 2016 12:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcrZmOmLcbTp for ; Mon, 7 Mar 2016 12:36:11 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 0F4E21CDB37 for ; Mon, 7 Mar 2016 12:36:11 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id o6so51704388qkc.2 for ; Mon, 07 Mar 2016 12:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=kVXNQg4EFoRu+Cdfqw5t2i2FNCnqUMUaDKlY3hqCWLU=; b=vWLzSPbAA/dHkeoYKgUgQgcZKG3/KLv83PBOft8Ata8ECajbr4qwlvFwR7oCn9/NI8 uVtZ/BEn6RyNSR88BONunKyNpOtSKZU4Adq2oMK069rWCTDQcSN7WWTUiSRhuI+8WWf9 g5h4lh1nb47Fp7Z21GC0Mx1GotD7rpgEY1PHafKtsGcqGeIqk+YY/wroRlbaT3d5wmNE +oeqOKm+E/nRdkIpEt0TLjvrXrFiwYX+L1P/fvJHgSlN/2tFACbMB/vCu4u8kGAjSW5C SGejjvH+E9y2LCIPIKDHxdccwnTgMSY9DcMri0ma0NOHIVmxO4/4IvB56lDw3rq9O+lh +Ehw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kVXNQg4EFoRu+Cdfqw5t2i2FNCnqUMUaDKlY3hqCWLU=; b=ZTkFQD3Giw1TzPyilVgAv+eAT199XhziC2HOCQnmT00PasaR+8noLOX+VkCBN/CCO6 4LN7SlBUOvz7QTkBTlbch3CyusfY8k0cHmaoiL4lHFs5VVCHk32KHu6d0JpRigQ7or6y fGWxyDFe350Rj/SmrigUgi1dE7HKxJd5DvLuGRvZLNQMyhbvCIsiH68scPT6MhR++eKO jF4wkfWUtiDJ2OuuBvRuAn+oNgDYFvYD5XXcPP5TRXfwA8GA8Pi191FHHrJN5hlHB6eM VgIUsDA3oE+F+WA6sreGWj3WKfNYbZTqzkH0AUlFk/MmmncSYZeZ3/alcTgGQOctPvtY x41w== X-Gm-Message-State: AD7BkJJD5eNjdiIJLQhAP8tqijetEaTGj+SXonszKRGDOeoTLQx7UOgf2Am+C3e+cLlRhYtdRnHID0c0yrusBg== X-Received: by 10.55.192.154 with SMTP id v26mr17580326qkv.36.1457382969997; Mon, 07 Mar 2016 12:36:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.6.13 with HTTP; Mon, 7 Mar 2016 12:35:50 -0800 (PST) From: Ted Hardie Date: Mon, 7 Mar 2016 12:35:50 -0800 Message-ID: To: "rtcweb@ietf.org" , Cullen Jennings , Sean Turner Content-Type: multipart/alternative; boundary=001a1147a3f03a9ecd052d7b6a8c Archived-At: Subject: [rtcweb] DTMF resolution proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 20:36:12 -0000 --001a1147a3f03a9ecd052d7b6a8c Content-Type: text/plain; charset=UTF-8 We've had about 60 or so messages on this topic, and the rough consensus seems to be align this document with the limits set out in the W3C work here: https://www.w3.org/TR/webrtc/#rtcdtmfsender However, there was also a proposal to slightly modify those limits. They are currently: "The duration cannot be more than 6000 ms or less than 40 ms. The default duration is 100 ms for each tone." Based on Roman's note, a minimum of 40ms and a maximum 8000 ms to align with the ITU and RFC2833. To resolve this, I propose that we ask the WebRTC group to raise their max to 8000 and, on receiving a positive response, publish this document with 40/8000 as the min and max. If they give a negative response, we retain 40/6000. This values alignment between the two documents higher than the reference 2833, but that seems sensible in this context. If you have an objection to this way forward, please send your reasoning to the list by March 14th. thanks, Ted --001a1147a3f03a9ecd052d7b6a8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To resolve this, I propose that we ask the WebRTC group to raise = their max to 8000 and, on receiving a positive response, publish this docum= ent with 40/8000 as the min and max.=C2=A0 If they give a negative response= , we retain 40/6000.=C2=A0 This values alignment between the two documents = higher than the reference 2833, but that seems sensible in this context.
--001a1147a3f03a9ecd052d7b6a8c-- From nobody Mon Mar 7 13:23:18 2016 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0D0A21CDBF6 for ; Mon, 7 Mar 2016 13:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tl6B4R3nDLFl for ; Mon, 7 Mar 2016 13:23:14 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 7129D1CDBF8 for ; Mon, 7 Mar 2016 13:23:14 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id 63so86280013pfe.3 for ; Mon, 07 Mar 2016 13:23:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=yuWT4FtRa5JD7PLviPv8ZLujlHWDVihTHUNk41vcY5A=; b=ddhB+wkj+/tngQS+ujEPGdXQMy52sI5DsjBpuKfoWH0fyBinmzEOzhEKIhYYXNOArV T2LkIfUFAK4Xsc5YHiI6V6owKTyX1B6h/E/xa+M7JOo1E5CcOhYStcIvKvX1d14qjXxh p37s1P3URIJP7Ltlfv2nwxfPLZ8/Bfl39RzQ4n6cXLbdL8u7XTI0Y099q0itaqhWw+s7 aCzfexyuM2KxASbi9osOvXGpiLpsw6Nr9d1qnapLycLF6u7gk+6V5c0ab9QcVp1JEIYb Npow4LBTypyibd7X8rpnZHZhZu/sMWT7jLGW0kQcdG8UNR+1rsyWBm+Y87tH2gdB36ek Uy9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=yuWT4FtRa5JD7PLviPv8ZLujlHWDVihTHUNk41vcY5A=; b=f/INcZI+wVwxvgHQlDRWzibgozfzttH3VwtneWdNXEliX+/kqiCcRpX6lry6ApKFOj qEfTI0t5qGd8oXo5Hd/RQQSJSwv7LcY7F6idxqlqkq3fkKVCaj+/fX0Q7JkrgT7n+aHm 3Ts2GlKUS+x+kojQvfHt5KBytFr3TsrWEwqmASxP5Yq0LfWj9bkCJkSaSoEMr/tyQcM1 8aEwPk0oUftAkFS01HTqUFhLTn58jC+MTC1Mp5r8XFQbNVM3WUuw4ZNTQWtX1AxK4Xfe d4kAXHU/g03AzwLxQ/X5coDoc5J6MBXXLoLkm25rIOMPmfDEg6QewvlRuqc6jZw6TF15 3biA== X-Gm-Message-State: AD7BkJIgPyds2kG+mV79Pie1FdurtXFCORtu/4EXmfWCdJ9P7Ni3G3Ux5zHy7ZMz2wXedoaD X-Received: by 10.98.80.78 with SMTP id e75mr36873878pfb.147.1457385793883; Mon, 07 Mar 2016 13:23:13 -0800 (PST) Received: from panoramix.jmvalin.ca ([2620:101:80fc:224:7e7a:91ff:fe20:963f]) by smtp.gmail.com with ESMTPSA id 144sm26082216pfa.83.2016.03.07.13.23.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2016 13:23:12 -0800 (PST) To: Ted Hardie , "rtcweb@ietf.org" , Cullen Jennings , Sean Turner References: From: Jean-Marc Valin X-Enigmail-Draft-Status: N1110 Message-ID: <56DDF13F.1050505@mozilla.com> Date: Mon, 7 Mar 2016 16:23:11 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] DTMF resolution proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 21:23:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 As proposed by Roman, I think we should also include the "minimum gap of 30 ms". Otherwise, I support the proposal. Jean-Marc On 03/07/2016 03:35 PM, Ted Hardie wrote: > We've had about 60 or so messages on this topic, and the rough > consensus seems to be align this document with the limits set out > in the W3C work here: > > https://www.w3.org/TR/webrtc/#rtcdtmfsender > > However, there was also a proposal to slightly modify those limits. > They are currently: > > "The duration cannot be more than 6000 ms or less than 40 ms. The > default duration is 100 ms for each tone." > > Based on Roman's note, a minimum of 40ms and a maximum 8000 ms to > align with the ITU and RFC2833. > > To resolve this, I propose that we ask the WebRTC group to raise > their max to 8000 and, on receiving a positive response, publish > this document with 40/8000 as the min and max. If they give a > negative response, we retain 40/6000. This values alignment > between the two documents higher than the reference 2833, but that > seems sensible in this context. > > If you have an objection to this way forward, please send your > reasoning to the list by March 14th. > > thanks, > > Ted > > > > _______________________________________________ rtcweb mailing > list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW3fE5AAoJEJ6/8sItn9q9KDgH/j4bSutkSjUmvt6aTtt26qF6 FKF2JMkrZc8pjSg6IDTq9MJradJr8WSzr27VSpedWOHHPFf5z4jDn6IpVVMyTUtP Jj6MvAPTyf9uB7UGq8rfA9y6az9OjChsJZ3j2/yPk7i/bnVYObg0OXOItyPA2+kA 7KCJAIWUiIBdfifKV8W1qre5DbUVi4iXnGIzbQ5KJIpxrO3Cxrq+vlPy7Gznc1a1 o4B50DU6p3nBILGgCXpFwAMW5PBfco/oAOzCH90gqcM8hzEROW50LTJED/OP0K/b S3LMG3M+BriuAaslwW/Tj0qm3VUqtFpKaE3I0zjlxUbvfsxg/JYju2ebGSslZ7I= =dpJA -----END PGP SIGNATURE----- From nobody Mon Mar 7 14:19:24 2016 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B60411CDC79 for ; Mon, 7 Mar 2016 14:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYUtyRrcMOHp for ; Mon, 7 Mar 2016 14:19:21 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 3C9A81CDC70 for ; Mon, 7 Mar 2016 14:19:21 -0800 (PST) Received: by mail-qg0-x22a.google.com with SMTP id u110so108948769qge.3 for ; Mon, 07 Mar 2016 14:19:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bkt3/+4tJ6U+0MUTDQSsm8psB5KZMulhOO/IsPb68Ic=; b=kYVxx+mg1dhdRaO25HJqgEWVAkBrFD5SIBPsIKdxuP6phhrbwVg5kxT38cW+kmyb+U 4ymxEiA539S0Dbb/fb13r8XOiTdv5aXsdkwAL5HQ4ovpQumIgyBGoN2Qyj3c3rHg3VwQ fLC7xERlUpTCWrT6G1UbCVx7161jJgv62mxFVYaJCdBWBSOjhoYKy9Hb9PtLSB6nkKny qHUqkdijpNPoZQBT2v4Y2knKnb2h8XjuFMWWv6gOJraVRvO1Tb4TBAcGWdbibwK7+WVh aFdpYAt7khTWjyyyGcMSTJFq3KtuzbzFc9Dqjm94b4O52L2OnX73oZfM1Opt3/rwNp3Z DtOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bkt3/+4tJ6U+0MUTDQSsm8psB5KZMulhOO/IsPb68Ic=; b=S/BbzD3ox6e6X+GbGRBqYtwi3/USHxjMKvk0gf5A8ockTjFs5gdpVVk3a8m2lRu5P9 MBs/pEwPZ3lRxQU7nAV67Q7DnoWxeUeqtY5Zp5N+UJZHYKCJrpPgDd3FNUPXSMhnKUJe TeJhmV+VurSzFtunj58r0L0HuvstBwzwYlt+qkgQKV+xpsTz2dqaZUrqSbHdjxq01SMh u2lEXUB5hlTU3//YwM+m0L1VY5Bl2KRH5mygPSQAqwQcoP9Bo3SbV+AkqyicQGSWGyRV 9Qrxz6ceyBJvsPa0ahDVtEREWl7tAYCQE1fjcXulSA96chev2IbR465X8Qr24EfTNJa8 SedQ== X-Gm-Message-State: AD7BkJIfoM0DvOdIzWj+svv4btwB//QU7OyoOx1x5ctk8BuX2Zhvnt4zoKWoYykR4yqza3dVrsbIUeoE5yzNbQ== X-Received: by 10.140.235.137 with SMTP id g131mr33710487qhc.43.1457389160297; Mon, 07 Mar 2016 14:19:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.6.13 with HTTP; Mon, 7 Mar 2016 14:19:00 -0800 (PST) In-Reply-To: <56DDF13F.1050505@mozilla.com> References: <56DDF13F.1050505@mozilla.com> From: Ted Hardie Date: Mon, 7 Mar 2016 14:19:00 -0800 Message-ID: To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=001a1135585e32fc33052d7cdbb4 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] DTMF resolution proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 22:19:22 -0000 --001a1135585e32fc33052d7cdbb4 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 7, 2016 at 1:23 PM, Jean-Marc Valin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > As proposed by Roman, I think we should also include the "minimum gap > of 30 ms". Otherwise, I support the proposal. > > Thank you Jean-Marc; I had not thought to include that in my note, but I agree. regards, Ted > Jean-Marc > > On 03/07/2016 03:35 PM, Ted Hardie wrote: > > We've had about 60 or so messages on this topic, and the rough > > consensus seems to be align this document with the limits set out > > in the W3C work here: > > > > https://www.w3.org/TR/webrtc/#rtcdtmfsender > > > > However, there was also a proposal to slightly modify those limits. > > They are currently: > > > > "The duration cannot be more than 6000 ms or less than 40 ms. The > > default duration is 100 ms for each tone." > > > > Based on Roman's note, a minimum of 40ms and a maximum 8000 ms to > > align with the ITU and RFC2833. > > > > To resolve this, I propose that we ask the WebRTC group to raise > > their max to 8000 and, on receiving a positive response, publish > > this document with 40/8000 as the min and max. If they give a > > negative response, we retain 40/6000. This values alignment > > between the two documents higher than the reference 2833, but that > > seems sensible in this context. > > > > If you have an objection to this way forward, please send your > > reasoning to the list by March 14th. > > > > thanks, > > > > Ted > > > > > > > > _______________________________________________ rtcweb mailing > > list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJW3fE5AAoJEJ6/8sItn9q9KDgH/j4bSutkSjUmvt6aTtt26qF6 > FKF2JMkrZc8pjSg6IDTq9MJradJr8WSzr27VSpedWOHHPFf5z4jDn6IpVVMyTUtP > Jj6MvAPTyf9uB7UGq8rfA9y6az9OjChsJZ3j2/yPk7i/bnVYObg0OXOItyPA2+kA > 7KCJAIWUiIBdfifKV8W1qre5DbUVi4iXnGIzbQ5KJIpxrO3Cxrq+vlPy7Gznc1a1 > o4B50DU6p3nBILGgCXpFwAMW5PBfco/oAOzCH90gqcM8hzEROW50LTJED/OP0K/b > S3LMG3M+BriuAaslwW/Tj0qm3VUqtFpKaE3I0zjlxUbvfsxg/JYju2ebGSslZ7I= > =dpJA > -----END PGP SIGNATURE----- > --001a1135585e32fc33052d7cdbb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 7, 2016 at 1:23 PM,= Jean-Marc Valin <jmvalin@mozilla.com> wrote:
-----BEGIN PGP SIGNED MESS= AGE-----
Hash: SHA256

As proposed by Roman, I think we should also include the "minimum gap<= br> of 30 ms". Otherwise, I support the proposal.


Thank you Jean-Marc; I had not thought= to include that in my note, but I agree.

regards,
Ted

=C2=A0

On 03/07/2016 03:35 PM, Ted Hardie wrote:
> We've had about 60 or so messages on this topic, and the rough
> consensus seems to be align this document with the limits set out
> in the W3C work here:
>
> https://www.w3.org/TR/webrtc/#rtcdtmfsender
>
> However, there was also a proposal to slightly modify those limits. >=C2=A0 They are currently:
>
> "The duration cannot be more than 6000 ms or less than 40 ms. The=
> default duration is 100 ms for each tone."
>
> Based on Roman's note, a minimum of 40ms and a maximum 8000 ms to<= br> > align with the ITU and RFC2833.
>
> To resolve this, I propose that we ask the WebRTC group to raise
> their max to 8000 and, on receiving a positive response, publish
> this document with 40/8000 as the min and max.=C2=A0 If they give a > negative response, we retain 40/6000.=C2=A0 This values alignment
> between the two documents higher than the reference 2833, but that
> seems sensible in this context.
>
> If you have an objection to this way forward, please send your
> reasoning to the list by March 14th.
>
> thanks,
>
> Ted
>
>
>
> _______________________________________________ rtcweb mai= ling
> list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJW3fE5AAoJEJ6/8sItn9q9KDgH/j4bSutkSjUmvt6aTtt26qF6
FKF2JMkrZc8pjSg6IDTq9MJradJr8WSzr27VSpedWOHHPFf5z4jDn6IpVVMyTUtP
Jj6MvAPTyf9uB7UGq8rfA9y6az9OjChsJZ3j2/yPk7i/bnVYObg0OXOItyPA2+kA
7KCJAIWUiIBdfifKV8W1qre5DbUVi4iXnGIzbQ5KJIpxrO3Cxrq+vlPy7Gznc1a1
o4B50DU6p3nBILGgCXpFwAMW5PBfco/oAOzCH90gqcM8hzEROW50LTJED/OP0K/b
S3LMG3M+BriuAaslwW/Tj0qm3VUqtFpKaE3I0zjlxUbvfsxg/JYju2ebGSslZ7I=3D
=3DdpJA
-----END PGP SIGNATURE-----

--001a1135585e32fc33052d7cdbb4-- From nobody Mon Mar 7 15:45:10 2016 Return-Path: X-Original-To: rtcweb@ietfc.amsl.com Delivered-To: rtcweb@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D8A0D1CDE34 for ; Mon, 7 Mar 2016 15:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpHDKHxMl41t for ; Mon, 7 Mar 2016 15:45:07 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id C15901CDE2E for ; Mon, 7 Mar 2016 15:45:07 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id s5so53751433qkd.0 for ; Mon, 07 Mar 2016 15:45:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=BiVRD66dCaD7kw0Iw1klAf9/NOgkXcyVYM95xkfXIaA=; b=VFQTMpPRlVfYvaRDHq1nifHbPWP7+hhrlVU9nQaofZtksH3Gfi5rLpHFocsZUDBcNN soJwmZGx6s7H3pnJrajYDDN5a0HPPM6OZFXC1yrwqYw6vr+kesny4M7NUKED2+uPqqEn 7z3ERo31AkVFj0feQwCBFqiAFluI/QoAQNupw+SrHr3bsww3vx7fE6Vy5v38LGfB3+qu 94K1epPqlZagxyVJ1pSlZA5qMEVGnl+/T62RDQ2rjSQFsgFwjuvcYPKG0p0x2Ddmne26 lkGPX4RKBgh2kiByAP2Cl11qyTyE+UOBsmqBMxTr6RznJuINNiAUvjZKHUMolPyXTkCm Rd8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=BiVRD66dCaD7kw0Iw1klAf9/NOgkXcyVYM95xkfXIaA=; b=VX2xBLZdbF9MNAueFGD4FjFOW6tODRlKRHAD/Mf4qnih9GBmYvRY57OqrX30IqQ0Xs RQS42s31bFvG0OGrPXRSKyMbBztPjYfy/9gF/+pU/w8Oz0ZauY15Dw79D/X6BUY4mXAM Mv13+uFvM/ZSyxZVZ+jgnKRBjfAaYeuEBWOxOkDlSA2jLM0QYowIM7dOohTQZP5sApcv Tdo4HbUtTqsaSaBJKegY1W4TSp1zsgS0HpJzJN2JeinGha9MohzbTlP+LrgcZJGZYzl7 RZoewbBr+Q5UCXerpmRO0o8O60IQ4PcmD/WBVjusPeYoaSQoHZK+a1KL0gA1SRqPsYvK etAA== X-Gm-Message-State: AD7BkJLNuDcDCf5kZPvhxKD84I6BKnRrHfHiGIRjFqO+FDX8Plse0b5e+K6ZByED0TaiNvVALLqDs1bMsg9zaQ== X-Received: by 10.55.74.141 with SMTP id x135mr31626365qka.20.1457394306740; Mon, 07 Mar 2016 15:45:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.6.13 with HTTP; Mon, 7 Mar 2016 15:44:47 -0800 (PST) From: Ted Hardie Date: Mon, 7 Mar 2016 15:44:47 -0800 Message-ID: To: "rtcweb@ietf.org" , Sean Turner , Cullen Jennings Content-Type: multipart/alternative; boundary=001a114a7c6ef37a58052d7e0d0c Archived-At: Subject: [rtcweb] Interim reading list X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 23:45:09 -0000 --001a114a7c6ef37a58052d7e0d0c Content-Type: text/plain; charset=UTF-8 The authors of JSEP have been working hard on a new update and are still trying to land a few pull requests prior to the meeting on Thursday. Once they have done that, they will emit a new version into the drafts directory. In the mean time, you can review the current state of play by reviewing the editor pages at: https://github.com/rtcweb-wg/jsep/blob/gh-pages/draft-ietf-rtcweb-jsep.txt plus the list of pull requests at: https://github.com/rtcweb-wg/jsep/pulls Quite a few issues have already been closed, so please review. Webex details should be out later today or tomorrow morning. thanks, Ted --001a114a7c6ef37a58052d7e0d0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The authors of JSEP have been working = hard on a new update and are still trying to land a few pull requests prior= to the meeting on Thursday.=C2=A0 Once they have done that, they will emit= a new version into the drafts directory.=C2=A0 In the mean time, you can r= eview the current state of play by reviewing the editor pages at:

https://github.com/rtcweb-wg/jsep/blob/gh-pages/draft-ietf-rtcweb= -jsep.txt

plus the list of pull requests at:

https://github.com/rtcweb-wg/= jsep/pulls

Quite a few issues have already been closed, so= please review.=C2=A0 Webex details should be out later today or tomorrow m= orning.

thanks,

Ted
--001a114a7c6ef37a58052d7e0d0c-- From nobody Tue Mar 8 00:09:40 2016 Return-Path: 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 47D2912D505 for ; Mon, 7 Mar 2016 23:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id betF0DKNWUSW for ; Mon, 7 Mar 2016 23:41:39 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0072.outbound.protection.outlook.com [207.46.100.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD9712D501 for ; Mon, 7 Mar 2016 23:41:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zOjAqkA3JXMdhgCXexw5a/ciSlAucLb50GgndvH59Ac=; b=X0hnjokYlbRz4TrJ0/F6efSYnde9gDAFU7940lF6mWOkuxFv3EwzXLnnQpQgJJ66WXauwgTpfd+ihM40o6nczW5HwwGcUqWXnz15ygwPhGOzfKUJOqt6PssgJ8SC2MsgU4M5ExV5XGTMVIa68AuQcm+prfbglFMrklsPNe4U7B0= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) with Microsoft SMTP Server (TLS) id 15.1.427.16; Tue, 8 Mar 2016 07:24:48 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0427.019; Tue, 8 Mar 2016 07:24:48 +0000 From: "Asveren, Tolga" To: Ted Hardie , Jean-Marc Valin Thread-Topic: [rtcweb] DTMF resolution proposal Thread-Index: AQHReLEGZXQ6ENs53U20okwQmfoJbJ9OfbeAgAAPmQCAAJd7oA== Date: Tue, 8 Mar 2016 07:24:48 +0000 Message-ID: References: <56DDF13F.1050505@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: a35b335e-07e1-4e5f-878a-08d34722bb2a x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1551; 5:RPwXzXz1uqd4a01u8nybr4kSYx+4dVFUI8Meqjz8WYdgU8hbBCkMKrWKZZ7GZcLfzMtTcnO4EfR3Jasxa2xw8X/MoRLtQybv+3KrqcuUafZBa/+B9M4l0H1vJgSR5SQ9I8GS2MeM5uC4aQqgHVjI9Q==; 24:658GTB4Yf+0Idmn0nw999wx0Ww69sPC+SXbdK/JMhWRvhlMuK5TEc/IaXP9USmvUVif9wuk3ZbMWKHCRoh0RcIp6GexI4NA8gA2a/ac9tO4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1551; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:SN1PR0301MB1551; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1551; x-forefront-prvs: 08756AC3C8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(479174004)(24454002)(164054003)(575784001)(86362001)(19580395003)(19580405001)(11100500001)(5008740100001)(106116001)(33656002)(561944003)(2950100001)(19625215002)(66066001)(77096005)(2900100001)(92566002)(122556002)(15975445007)(16236675004)(19609705001)(81166005)(19617315012)(5004730100002)(5001770100001)(87936001)(1096002)(3846002)(3280700002)(6116002)(1220700001)(102836003)(790700001)(3660700001)(586003)(76576001)(4326007)(2906002)(19300405004)(74316001)(54356999)(5002640100001)(40100003)(50986999)(10400500002)(5003600100002)(76176999)(189998001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1551; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB15514F08779F54B3CD74BA34B2B20SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2016 07:24:48.2239 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1551 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] DTMF resolution proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 07:41:42 -0000 --_000_SN1PR0301MB15514F08779F54B3CD74BA34B2B20SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V291bGQgdGhlIHRleHQgYmUgY3JhZnRlZCBzbyB0aGF0IGl0IHBlcnRhaW5zICpvbmx5KiB0byB0 aGUgUkZDNDczMyBkaWdpdCBwYWNrZXRzIGVtaXR0ZWQgYnkgYSBicm93c2VyPw0KDQpJbmZvcm1h dGlvbiBhYm91dCBnYXAgYmV0d2VlbiByZXRyYW5zbWlzc2lvbiBvZiB0aGUgZmluYWwgcGFja2V0 IGNvdWxkIGJlIHVzZWZ1bCBhcyB3ZWxsIGFuZCBJIHN1Z2dlc3QgMjBtcyBmb3IgdGhhdCBvbmUu DQoNClRoYW5rcywNClRvbGdhDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVkIEhhcmRpZQ0KU2VudDogTW9uZGF5LCBNYXJjaCAw NywgMjAxNiA1OjE5IFBNDQpUbzogSmVhbi1NYXJjIFZhbGluIDxqbXZhbGluQG1vemlsbGEuY29t Pg0KQ2M6IEN1bGxlbiBKZW5uaW5ncyA8Zmx1ZmZ5QGNpc2NvLmNvbT47IHJ0Y3dlYkBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIERUTUYgcmVzb2x1dGlvbiBwcm9wb3NhbA0KDQpPbiBN b24sIE1hciA3LCAyMDE2IGF0IDE6MjMgUE0sIEplYW4tTWFyYyBWYWxpbiA8am12YWxpbkBtb3pp bGxhLmNvbTxtYWlsdG86am12YWxpbkBtb3ppbGxhLmNvbT4+IHdyb3RlOg0KLS0tLS1CRUdJTiBQ R1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCkFzIHByb3Bvc2VkIGJ5IFJv bWFuLCBJIHRoaW5rIHdlIHNob3VsZCBhbHNvIGluY2x1ZGUgdGhlICJtaW5pbXVtIGdhcA0Kb2Yg MzAgbXMiLiBPdGhlcndpc2UsIEkgc3VwcG9ydCB0aGUgcHJvcG9zYWwuDQoNClRoYW5rIHlvdSBK ZWFuLU1hcmM7IEkgaGFkIG5vdCB0aG91Z2h0IHRvIGluY2x1ZGUgdGhhdCBpbiBteSBub3RlLCBi dXQgSSBhZ3JlZS4NCnJlZ2FyZHMsDQpUZWQNCg0KDQogICAgICAgIEplYW4tTWFyYw0KDQpPbiAw My8wNy8yMDE2IDAzOjM1IFBNLCBUZWQgSGFyZGllIHdyb3RlOg0KPiBXZSd2ZSBoYWQgYWJvdXQg NjAgb3Igc28gbWVzc2FnZXMgb24gdGhpcyB0b3BpYywgYW5kIHRoZSByb3VnaA0KPiBjb25zZW5z dXMgc2VlbXMgdG8gYmUgYWxpZ24gdGhpcyBkb2N1bWVudCB3aXRoIHRoZSBsaW1pdHMgc2V0IG91 dA0KPiBpbiB0aGUgVzNDIHdvcmsgaGVyZToNCj4NCj4gaHR0cHM6Ly93d3cudzMub3JnL1RSL3dl YnJ0Yy8jcnRjZHRtZnNlbmRlcg0KPg0KPiBIb3dldmVyLCB0aGVyZSB3YXMgYWxzbyBhIHByb3Bv c2FsIHRvIHNsaWdodGx5IG1vZGlmeSB0aG9zZSBsaW1pdHMuDQo+ICBUaGV5IGFyZSBjdXJyZW50 bHk6DQo+DQo+ICJUaGUgZHVyYXRpb24gY2Fubm90IGJlIG1vcmUgdGhhbiA2MDAwIG1zIG9yIGxl c3MgdGhhbiA0MCBtcy4gVGhlDQo+IGRlZmF1bHQgZHVyYXRpb24gaXMgMTAwIG1zIGZvciBlYWNo IHRvbmUuIg0KPg0KPiBCYXNlZCBvbiBSb21hbidzIG5vdGUsIGEgbWluaW11bSBvZiA0MG1zIGFu ZCBhIG1heGltdW0gODAwMCBtcyB0bw0KPiBhbGlnbiB3aXRoIHRoZSBJVFUgYW5kIFJGQzI4MzMu DQo+DQo+IFRvIHJlc29sdmUgdGhpcywgSSBwcm9wb3NlIHRoYXQgd2UgYXNrIHRoZSBXZWJSVEMg Z3JvdXAgdG8gcmFpc2UNCj4gdGhlaXIgbWF4IHRvIDgwMDAgYW5kLCBvbiByZWNlaXZpbmcgYSBw b3NpdGl2ZSByZXNwb25zZSwgcHVibGlzaA0KPiB0aGlzIGRvY3VtZW50IHdpdGggNDAvODAwMCBh cyB0aGUgbWluIGFuZCBtYXguICBJZiB0aGV5IGdpdmUgYQ0KPiBuZWdhdGl2ZSByZXNwb25zZSwg d2UgcmV0YWluIDQwLzYwMDAuICBUaGlzIHZhbHVlcyBhbGlnbm1lbnQNCj4gYmV0d2VlbiB0aGUg dHdvIGRvY3VtZW50cyBoaWdoZXIgdGhhbiB0aGUgcmVmZXJlbmNlIDI4MzMsIGJ1dCB0aGF0DQo+ IHNlZW1zIHNlbnNpYmxlIGluIHRoaXMgY29udGV4dC4NCj4NCj4gSWYgeW91IGhhdmUgYW4gb2Jq ZWN0aW9uIHRvIHRoaXMgd2F5IGZvcndhcmQsIHBsZWFzZSBzZW5kIHlvdXINCj4gcmVhc29uaW5n IHRvIHRoZSBsaXN0IGJ5IE1hcmNoIDE0dGguDQo+DQo+IHRoYW5rcywNCj4NCj4gVGVkDQo+DQo+ DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHJ0 Y3dlYiBtYWlsaW5nDQo+IGxpc3QgcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5v cmc+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+DQotLS0t LUJFR0lOIFBHUCBTSUdOQVRVUkUtLS0tLQ0KVmVyc2lvbjogR251UEcgdjINCg0KaVFFY0JBRUJD QUFHQlFKVzNmRTVBQW9KRUo2LzhzSXRuOXE5S0RnSC9qNGJTdXRrU2pVbXZ0NmFUdHQyNnFGNg0K RktGMkpNa3JaYzhwalNnNklEVHE5TUpyYWRKcjhXU3pyMjdWU3BlZFdPSEhQRmY1ejRqRG42SXBW Vk15VFV0UA0KSmo2TXZBUFR5Zjl1QjdVR3E4cmZBOXk2YXo5T2pDaHNKWjNqMi95UGs3aS9iblZZ T2JnME9YT0l0eVBBMitrQQ0KN0tDSkFJV1VpSUJkZmlmS1Y4VzFxcmU1RGJVVmk0aVhuR0l6YlE1 S0pJcHhyTzNDeHJxK3ZsUHk3R3puYzFhMQ0KbzRCNTBEVTZwM25CSUxHZ0NYcEZ3QU1XNVBCZmNv L29BT3pDSDkwZ3FjTThoekVST1c1MExUSkVEL09QMEsvYg0KUzNMTUczTStCcml1QWFzbHdXL1Rq MHFtM1ZVcXRGcEthRTNJMHpqbHhVYnZmc3hnL0pZanUyZWJHU3NsWjdJPQ0KPWRwSkENCi0tLS0t RU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0KDQo= --_000_SN1PR0301MB15514F08779F54B3CD74BA34B2B20SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldvdWxkIHRoZSB0ZXh0IGJlIGNyYWZ0ZWQg c28gdGhhdCBpdCBwZXJ0YWlucyAqPGI+b25seTwvYj4qIHRvIHRoZSBSRkM0NzMzIGRpZ2l0IHBh Y2tldHMgZW1pdHRlZCBieSBhIGJyb3dzZXI/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkluZm9ybWF0aW9uIGFib3V0IGdhcCBiZXR3ZWVuIHJldHJhbnNtaXNz aW9uIG9mIHRoZSBmaW5hbCBwYWNrZXQgY291bGQgYmUgdXNlZnVsIGFzIHdlbGwgYW5kIEkgc3Vn Z2VzdCAyMG1zIGZvciB0aGF0IG9uZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VG9sZ2E8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBydGN3 ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ VGVkIEhhcmRpZTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1hcmNoIDA3LCAyMDE2IDU6MTkg UE08YnI+DQo8Yj5Ubzo8L2I+IEplYW4tTWFyYyBWYWxpbiAmbHQ7am12YWxpbkBtb3ppbGxhLmNv bSZndDs8YnI+DQo8Yj5DYzo8L2I+IEN1bGxlbiBKZW5uaW5ncyAmbHQ7Zmx1ZmZ5QGNpc2NvLmNv bSZndDs7IHJ0Y3dlYkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0g RFRNRiByZXNvbHV0aW9uIHByb3Bvc2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1hciA3LCAyMDE2IGF0IDE6MjMg UE0sIEplYW4tTWFyYyBWYWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptdmFsaW5AbW96aWxsYS5j b20iIHRhcmdldD0iX2JsYW5rIj5qbXZhbGluQG1vemlsbGEuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0Ut LS0tLTxicj4NCkhhc2g6IFNIQTI1Njxicj4NCjxicj4NCkFzIHByb3Bvc2VkIGJ5IFJvbWFuLCBJ IHRoaW5rIHdlIHNob3VsZCBhbHNvIGluY2x1ZGUgdGhlICZxdW90O21pbmltdW0gZ2FwPGJyPg0K b2YgMzAgbXMmcXVvdDsuIE90aGVyd2lzZSwgSSBzdXBwb3J0IHRoZSBwcm9wb3NhbC48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhhbmsgeW91IEplYW4tTWFyYzsgSSBoYWQgbm90 IHRob3VnaHQgdG8gaW5jbHVkZSB0aGF0IGluIG15IG5vdGUsIGJ1dCBJIGFncmVlLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij5yZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBKZWFuLU1hcmM8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KT24gMDMvMDcvMjAxNiAwMzozNSBQTSwgVGVkIEhhcmRpZSB3cm90ZTo8 YnI+DQomZ3Q7IFdlJ3ZlIGhhZCBhYm91dCA2MCBvciBzbyBtZXNzYWdlcyBvbiB0aGlzIHRvcGlj LCBhbmQgdGhlIHJvdWdoPGJyPg0KJmd0OyBjb25zZW5zdXMgc2VlbXMgdG8gYmUgYWxpZ24gdGhp cyBkb2N1bWVudCB3aXRoIHRoZSBsaW1pdHMgc2V0IG91dDxicj4NCiZndDsgaW4gdGhlIFczQyB3 b3JrIGhlcmU6PGJyPg0KJmd0Ozxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cudzMub3Jn L1RSL3dlYnJ0Yy8jcnRjZHRtZnNlbmRlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lncz Lm9yZy9UUi93ZWJydGMvI3J0Y2R0bWZzZW5kZXI8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDsgSG93 ZXZlciwgdGhlcmUgd2FzIGFsc28gYSBwcm9wb3NhbCB0byBzbGlnaHRseSBtb2RpZnkgdGhvc2Ug bGltaXRzLjxicj4NCiZndDsmbmJzcDsgVGhleSBhcmUgY3VycmVudGx5Ojxicj4NCiZndDs8YnI+ DQomZ3Q7ICZxdW90O1RoZSBkdXJhdGlvbiBjYW5ub3QgYmUgbW9yZSB0aGFuIDYwMDAgbXMgb3Ig bGVzcyB0aGFuIDQwIG1zLiBUaGU8YnI+DQomZ3Q7IGRlZmF1bHQgZHVyYXRpb24gaXMgMTAwIG1z IGZvciBlYWNoIHRvbmUuJnF1b3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgQmFzZWQgb24gUm9tYW4n cyBub3RlLCBhIG1pbmltdW0gb2YgNDBtcyBhbmQgYSBtYXhpbXVtIDgwMDAgbXMgdG88YnI+DQom Z3Q7IGFsaWduIHdpdGggdGhlIElUVSBhbmQgUkZDMjgzMy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBU byByZXNvbHZlIHRoaXMsIEkgcHJvcG9zZSB0aGF0IHdlIGFzayB0aGUgV2ViUlRDIGdyb3VwIHRv IHJhaXNlPGJyPg0KJmd0OyB0aGVpciBtYXggdG8gODAwMCBhbmQsIG9uIHJlY2VpdmluZyBhIHBv c2l0aXZlIHJlc3BvbnNlLCBwdWJsaXNoPGJyPg0KJmd0OyB0aGlzIGRvY3VtZW50IHdpdGggNDAv ODAwMCBhcyB0aGUgbWluIGFuZCBtYXguJm5ic3A7IElmIHRoZXkgZ2l2ZSBhPGJyPg0KJmd0OyBu ZWdhdGl2ZSByZXNwb25zZSwgd2UgcmV0YWluIDQwLzYwMDAuJm5ic3A7IFRoaXMgdmFsdWVzIGFs aWdubWVudDxicj4NCiZndDsgYmV0d2VlbiB0aGUgdHdvIGRvY3VtZW50cyBoaWdoZXIgdGhhbiB0 aGUgcmVmZXJlbmNlIDI4MzMsIGJ1dCB0aGF0PGJyPg0KJmd0OyBzZWVtcyBzZW5zaWJsZSBpbiB0 aGlzIGNvbnRleHQuPGJyPg0KJmd0Ozxicj4NCiZndDsgSWYgeW91IGhhdmUgYW4gb2JqZWN0aW9u IHRvIHRoaXMgd2F5IGZvcndhcmQsIHBsZWFzZSBzZW5kIHlvdXI8YnI+DQomZ3Q7IHJlYXNvbmlu ZyB0byB0aGUgbGlzdCBieSBNYXJjaCAxNHRoLjxicj4NCiZndDs8YnI+DQomZ3Q7IHRoYW5rcyw8 YnI+DQomZ3Q7PGJyPg0KJmd0OyBUZWQ8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHJ0Y3dlYiBtYWls aW5nPGJyPg0KJmd0OyBsaXN0IDxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5vcmciPnJ0Y3dl YkBpZXRmLm9yZzwvYT4gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9ydGN3ZWIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnRjd2ViPC9hPjxicj4NCiZndDs8YnI+DQotLS0tLUJFR0lOIFBHUCBTSUdO QVRVUkUtLS0tLTxicj4NClZlcnNpb246IEdudVBHIHYyPGJyPg0KPGJyPg0KaVFFY0JBRUJDQUFH QlFKVzNmRTVBQW9KRUo2LzhzSXRuOXE5S0RnSC9qNGJTdXRrU2pVbXZ0NmFUdHQyNnFGNjxicj4N CkZLRjJKTWtyWmM4cGpTZzZJRFRxOU1KcmFkSnI4V1N6cjI3VlNwZWRXT0hIUEZmNXo0akRuNklw VlZNeVRVdFA8YnI+DQpKajZNdkFQVHlmOXVCN1VHcThyZkE5eTZhejlPakNoc0paM2oyL3lQazdp L2JuVllPYmcwT1hPSXR5UEEyJiM0MztrQTxicj4NCjdLQ0pBSVdVaUlCZGZpZktWOFcxcXJlNURi VVZpNGlYbkdJemJRNUtKSXB4ck8zQ3hycSYjNDM7dmxQeTdHem5jMWExPGJyPg0KbzRCNTBEVTZw M25CSUxHZ0NYcEZ3QU1XNVBCZmNvL29BT3pDSDkwZ3FjTThoekVST1c1MExUSkVEL09QMEsvYjxi cj4NClMzTE1HM00mIzQzO0JyaXVBYXNsd1cvVGowcW0zVlVxdEZwS2FFM0kwempseFVidmZzeGcv SllqdTJlYkdTc2xaN0k9PGJyPg0KPWRwSkE8YnI+DQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0t LS08bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN1PR0301MB15514F08779F54B3CD74BA34B2B20SN1PR0301MB1551_-- From nobody Tue Mar 8 04:43:39 2016 Return-Path: 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 4C8FE12D6A4 for ; Tue, 8 Mar 2016 04:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZ7sFLgoyIpa for ; Tue, 8 Mar 2016 04:43:36 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3B112D69D for ; Tue, 8 Mar 2016 04:43:36 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id C0A9264A16964 for ; Tue, 8 Mar 2016 12:43:32 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u28ChYu2028026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 8 Mar 2016 12:43:34 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u28ChYDg016858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 8 Mar 2016 13:43:34 +0100 Received: from [149.204.68.190] (135.239.27.41) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 8 Mar 2016 13:43:34 +0100 To: From: Juergen Stoetzer-Bradler Message-ID: <56DEC8F5.4070101@alcatel-lucent.com> Date: Tue, 8 Mar 2016 13:43:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [135.239.27.41] Archived-At: Subject: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 12:43:38 -0000 Hello, If a WebRTC endpoint uses the data channel establishment protocol in orde= r to open a data channel,=20 it may add a non-empty protocol identifier to the DATA_CHANNEL_OPEN messa= ge. Is the endpoint, which=20 receives this DATA_CHANNEL_OPEN message, assumed to process this protocol= id string in a case=20 sensitive or case insensitive way? Or would that actually be up to the re= ceiving WebRTC endpoint's=20 implementation? As far as I see draft-ietf-rtcweb-data-protocol doesn't seem to specify t= his. Background is draft-ietf-mmusic-data-channel-sdpneg, where the subprotoco= l identifiers are signaled=20 as part of an SDP attribute and where it is not yet clarified if these id= entifiers are assumed to be=20 case sensitive or case insensitive. Thanks, Juergen From nobody Tue Mar 8 08:31:57 2016 Return-Path: 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 3946012D80A for ; Tue, 8 Mar 2016 08:31:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95ijk78V_leW for ; Tue, 8 Mar 2016 08:31:49 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE5912D806 for ; Tue, 8 Mar 2016 08:31:33 -0800 (PST) Received: by mail-qg0-x229.google.com with SMTP id u110so16606963qge.3 for ; Tue, 08 Mar 2016 08:31:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LfeI3S4f+3sYuEQDAIGI8pBW6/GdR5T3Dux5cYTS/T0=; b=MKVMgPImrq+sBGwYKsx7KdtzbrUggnsP8uDLUOAA+W8ppLY/HzPZyZLYULFJQmAnuj r8XZXIEtYIUEZozhZ1TVsSKKlN2StepWfTZZWk+DMjA9QuRGMk19b94ekpA+aUi/z4c1 d/6Hs+wd5LJ3NGlTlu9Oa/aCFbs/YyrG7bp6ecFcxl33k0iU65H02Upi4UiF232bsr2/ 491PFFbeGbxwzS/pMfNJUsnxHq0+0+9UPWVCDo2ndZ7tPVo7l1yzCB9CsXEdR1SclcU/ /bFpp7VliHqlv/lQozwDV/7KWIxUto3zLdrdXreNl4YbHAT5fsq1NHLX8GA6xFWplEy6 1xvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LfeI3S4f+3sYuEQDAIGI8pBW6/GdR5T3Dux5cYTS/T0=; b=TVy9qms8vUGm2r6QL0iHerK51PkWlmscff0ezgaTmHVTa/7qn5cb+38zvdU13H3B4w 9zOTwCGlto7ZiFpk3wtjug1Yk4WpixwSewY+91twe2BL5pDZx1oBoNAithxxv3DVQQAU VGn93jDPfoAunPQQ415Ie9x/U9Xr3mS+6AS4coAw0hbL+47N0V7IQmiGlkl3C9W62OXP jc6V1JNw++VpS3ixalund/ZlHucogzQY+IxjNK2CyAEuGgpmzDR3lPb45i4o0p1+CUTx WZfaBLmy3fZiJ3k8l+3xptfxqNNjVSkxhLgpYvgU80uyNSxtdk7NbiYpEwXddjwT1MaQ 3Sdg== X-Gm-Message-State: AD7BkJJQjBFFYbfjaTbM8CbgUCy/QxgB6OA0z4kQ+kP/8mnu+vYPX3aftU3Aw63gcaZTWNGZOWOXK5WGLbjK9w== X-Received: by 10.140.128.21 with SMTP id 21mr39746179qha.36.1457454692068; Tue, 08 Mar 2016 08:31:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.6.13 with HTTP; Tue, 8 Mar 2016 08:31:12 -0800 (PST) In-Reply-To: <56DEC8F5.4070101@alcatel-lucent.com> References: <56DEC8F5.4070101@alcatel-lucent.com> From: Ted Hardie Date: Tue, 8 Mar 2016 08:31:12 -0800 Message-ID: To: Juergen Stoetzer-Bradler Content-Type: multipart/alternative; boundary=001a11c17314327257052d8c1dac Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 16:31:55 -0000 --001a11c17314327257052d8c1dac Content-Type: text/plain; charset=UTF-8 Hi Juergen, On Tue, Mar 8, 2016 at 4:43 AM, Juergen Stoetzer-Bradler < juergen.stoetzer-bradler@nokia.com> wr > > As far as I see draft-ietf-rtcweb-data-protocol doesn't seem to specify > this. > > Following the chain on this is a bit tedious, but section 5.1 specifies that this re-uses the registry set up by Websockets and described in RFC 6455. That, in turn, says: The elements that comprise this value MUST be non-empty strings with characters in the range U+0021 to U+007E not including separator characters as defined in [RFC2616 ] and MUST all be unique strings. The ABNF for the value of this header field is 1#token, where the definitions of constructs and rules are as given in [RFC2616 ]. The current registry is here: http://www.iana.org/assignments/websocket/websocket.xhtml#subprotocol-name regards, Ted > Background is draft-ietf-mmusic-data-channel-sdpneg, where the subprotocol > identifiers are signaled as part of an SDP attribute and where it is not > yet clarified if these identifiers are assumed to be case sensitive or case > insensitive. > > Thanks, > Juergen > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11c17314327257052d8c1dac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Juergen,

On Tue, Mar 8, 2016 at 4:43 AM, Juergen Stoetzer-Bradler <= span dir=3D"ltr"><juergen.stoetzer-bradler@nokia.com> wr
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
As far as I see draft-ietf-rtcweb-data-protocol doesn't seem to specify= this.


Following the chain on this is a bit t= edious, but section 5.1 specifies that this re-uses the registry set up by = Websockets and described in RFC 6455.=C2=A0 That, in turn, says:

The elements that comprise this value MUST be non-empty strings with characters in the range U+0021 to U+007E not including separator characters as defined in [RFC2616] and MUST all be un= ique strings. The ABNF for the value of this header field is 1#token, where the definitions of constructs and rules are as given in [RFC2616]. The current registry is here:

http://www.iana.org= /assignments/websocket/websocket.xhtml#subprotocol-name

regards,

Ted

=C2=A0
Background is draft-ietf-mmusic-data-channel-sdpneg, where the subprotocol = identifiers are signaled as part of an SDP attribute and where it is not ye= t clarified if these identifiers are assumed to be case sensitive or case i= nsensitive.

Thanks,
Juergen

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

--001a11c17314327257052d8c1dac-- From nobody Tue Mar 8 08:54:53 2016 Return-Path: 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 70F1012D836 for ; Tue, 8 Mar 2016 08:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFyh64TDvyMd for ; Tue, 8 Mar 2016 08:54:50 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4038A12D811 for ; Tue, 8 Mar 2016 08:54:50 -0800 (PST) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-07v.sys.comcast.net with comcast id TUu01s00457bBgG01Uupes; Tue, 08 Mar 2016 16:54:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-13v.sys.comcast.net with comcast id TUup1s0013KdFy101UupQq; Tue, 08 Mar 2016 16:54:49 +0000 To: rtcweb@ietf.org References: <56DEC8F5.4070101@alcatel-lucent.com> From: Paul Kyzivat Message-ID: <56DF03D8.6070308@alum.mit.edu> Date: Tue, 8 Mar 2016 11:54:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457456089; bh=UVzxrdzZ7XZil/PgFN7e+61zio0L1ilfZikcCzBn3Xo=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=kCDOoLvIomNcCJNFeOff6geGmnywF2s1IRPtJ89KcMQFL9r3yUwTBtkNlVBBH7c0G 7iKbstAotW6sCCN12+xJUA10Sw9pWsnDPHNyGLfvU6YamXsLO66ATfdkJsDlEgc1YU UEoEN7UI/W7kPCiH5z09AWXUmP4h1UFPHPXtWyGeDpCi4aGyA/29PixAXub3ouxqHj LxdsMok0EApJJh24frej0TSy0dhkpC/exa/Uz3nXXF1AO2iTnOm+XKxhRgRGzI+Y7u 9u/neU3IUWbyuUJPw+UebAcUGBK41hqnjNFCB4XzNi41EKnTmPjdzZObafAjmGRmNE YmDCcR8WMQyeA== Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 16:54:51 -0000 Ted, On 3/8/16 11:31 AM, Ted Hardie wrote: > Hi Juergen, > > On Tue, Mar 8, 2016 at 4:43 AM, Juergen Stoetzer-Bradler > > wr > > > As far as I see draft-ietf-rtcweb-data-protocol doesn't seem to > specify this. > > > Following the chain on this is a bit tedious, but section 5.1 specifies > that this re-uses the registry set up by Websockets and described in RFC > 6455. That, in turn, says: > > The elements that comprise this value > MUST be non-empty strings with characters in the range U+0021 to > U+007E not including separator characters as defined in > [RFC2616 ] and MUST all be unique strings. The ABNF for the > value of this header field is 1#token, where the definitions of > constructs and rules are as given in [RFC2616 ]. > > The current registry is here: > > http://www.iana.org/assignments/websocket/websocket.xhtml#subprotocol-name I had already investigated this. This only talks about the registry, not how values passed in the protocol are compared to registered values. Nor does it explicitly say whether "unique strings" is to be determined via case-sensitive comparison or case-insensitive comparison. (Without any other information to go on I guess I would assume case-sensitive comparison.) What is most *important* to me is that this be made entirely clear, that IANA have clear instructions to enforce, and that both websocket and data channel specs consistently specify what implementations must do in this regard. It is less important to me *which* choice is made. My *preference* would be minimally that the registry not permit two different names that differ only by case. If that is so, then in some sense it doesn't matter how implementations of the protocols do the comparison. Thanks, Paul > regards, > > Ted > > Background is draft-ietf-mmusic-data-channel-sdpneg, where the > subprotocol identifiers are signaled as part of an SDP attribute and > where it is not yet clarified if these identifiers are assumed to be > case sensitive or case insensitive. > > Thanks, > Juergen > > _______________________________________________ > 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 > From nobody Tue Mar 8 11:22:52 2016 Return-Path: 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 479DE12D9ED for ; Tue, 8 Mar 2016 11:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dACxsF6QPQX3 for ; Tue, 8 Mar 2016 11:22:47 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD97012D984 for ; Tue, 8 Mar 2016 11:22:46 -0800 (PST) Received: by mail-qg0-x233.google.com with SMTP id y89so21362138qge.2 for ; Tue, 08 Mar 2016 11:22:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lS+j7nEW2WkJ1lquVh+9MQhYVGQdzSZY7MlPULESfLs=; b=UPt0LF9YgJDfbZ0DWoAUfjYXST7xBh76Cx8aFLBz5EFvCYHapx0RcGrtmyOOoLm8Zj jZWhExcjz5U8W2zMMlRgn5IGASQEARiyqZtAUgYSy9TGuaxAnWpWvh/fb50o7PeubI01 txACq9SaFqVdW22BV+SgxXtH6/MqXQmMOmHctDg5ov42VJKbjCPxDmcxPeWlgJ+zWiW9 G3tKCyCno5tSlBs3NYcg5MwaO9ItbJjZ5kEvnyhXCCLpfKevmhNL6pX7URMaHdg8UhpJ owtMRpeDkpcTm4VAmAXD/CQRvgDvZ7rxRq5t8RYT6YJc7qcXkeZF33/0k1DX9lCQHD6e P96A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lS+j7nEW2WkJ1lquVh+9MQhYVGQdzSZY7MlPULESfLs=; b=Jnx27dY1HCE+0Uh2dnXo9JV0NqeTytaMxB0RKGG3ArXrOCkpU/kbWVCcG+rkFz34zL 1AzBB+6VWDSLauJeWZPpbltwlKohY+kGuavwTRaYVjICE6KViyawwSHULFPcflgwfKrQ nnRKrrVBEXo4Z/oB4S/WAz6e5TZv6zFgJhxj6naIcKwruxCpTFeYIuRM7tJ4TRpijZeH KwVj6JgoNy+NdwobzgRrDKuLKRR82xErwAJoGtoWqsSdmstQKd8zinVsHL9EXdTqTr28 /N5sx03SeRG99dkatM4TcNafyyrG5++LaPCP3ie8URrKBWankL6/qS1LnD9SPq14NYBQ WdGQ== X-Gm-Message-State: AD7BkJLWmvDseYOJ9Qjr32k4/BlDThQ4xnmD6bhlU2HIpKxhd8jJTUJwafiekkMHWIwWdqA3vqzQ0w95O3zjlA== X-Received: by 10.140.94.69 with SMTP id f63mr10956708qge.0.1457464965948; Tue, 08 Mar 2016 11:22:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.6.13 with HTTP; Tue, 8 Mar 2016 11:22:26 -0800 (PST) In-Reply-To: <56DF03D8.6070308@alum.mit.edu> References: <56DEC8F5.4070101@alcatel-lucent.com> <56DF03D8.6070308@alum.mit.edu> From: Ted Hardie Date: Tue, 8 Mar 2016 11:22:26 -0800 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a113a7326916ee4052d8e813d Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 19:22:50 -0000 --001a113a7326916ee4052d8e813d Content-Type: text/plain; charset=UTF-8 On Tue, Mar 8, 2016 at 8:54 AM, Paul Kyzivat wrote: > > The elements that comprise this value >> MUST be non-empty strings with characters in the range U+0021 to >> U+007E not including separator characters as defined in >> [RFC2616 ] and MUST all be >> unique strings. The ABNF for the >> value of this header field is 1#token, where the definitions of >> constructs and rules are as given in [RFC2616 < >> https://tools.ietf.org/html/rfc2616>]. >> >> The current registry is here: >> >> http://www.iana.org/assignments/websocket/websocket.xhtml#subprotocol-name >> > > I had already investigated this. This only talks about the registry, not > how values passed in the protocol are compared to registered values. Nor > does it explicitly say whether "unique strings" is to be determined via > case-sensitive comparison or case-insensitive comparison. > > (Without any other information to go on I guess I would assume > case-sensitive comparison.) > > Is there any token example in RFC 2616 that is case sensitive? As far as I can tell they are all case-insensitive, but I may have missed something. The Postel principle seems to indicate that we should always use the registered form, but be willing to understand a case insensitive variant. What is most *important* to me is that this be made entirely clear, that > IANA have clear instructions to enforce, and that both websocket and data > channel specs consistently specify what implementations must do in this > regard. > > It is less important to me *which* choice is made. My *preference* would be > minimally that the registry not permit two different names that differ only > by case. If that is so, then in some sense it doesn't matter how > implementations of the protocols do the comparison. > > How likely do you see this being? Anyone going to register XMPP (instead of xmpp) is going to be hurting themselves as much as users of xmpp if they actually use it. I'm happy to clean this up at some point, but I find it hard to believe this is the biggest rock. regards, Ted > Thanks, > Paul > > regards, >> >> Ted >> >> Background is draft-ietf-mmusic-data-channel-sdpneg, where the >> subprotocol identifiers are signaled as part of an SDP attribute and >> where it is not yet clarified if these identifiers are assumed to be >> case sensitive or case insensitive. >> >> Thanks, >> Juergen >> >> _______________________________________________ >> 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 > --001a113a7326916ee4052d8e813d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 8, 2016 at 8:54 AM, Paul Kyzivat <pkyziva= t@alum.mit.edu> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The elements that comprise this value
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be non-empty strings with characters= in the range U+0021 to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0U+007E not including separator characters= as defined in
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC2616 <https://tools.ietf= .org/html/rfc2616>] and MUST all be unique strings.=C2=A0 The ABNF f= or the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0value of this header field is 1#token, wh= ere the definitions of
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0constructs and rules are as given in [RFC= 2616 <https://tools.ietf.org/html/rfc2616>].

The current registry is here:

http://www.iana.org/assign= ments/websocket/websocket.xhtml#subprotocol-name

I had already investigated this. This only talks about the registry, not ho= w values passed in the protocol are compared to registered values. Nor does= it explicitly say whether "unique strings" is to be determined v= ia case-sensitive comparison or case-insensitive comparison.

(Without any other information to go on I guess I would assume case-sensiti= ve comparison.)

Is there any token example in RFC 2616 that is case s= ensitive?=C2=A0 As far as I can tell they are all case-insensitive, but I m= ay have missed something.=C2=A0

The Postel pr= inciple seems to indicate that we should always use the registered form, bu= t be willing to understand a case insensitive variant.

What is most *important* to me is that this be made entirely clear, that IA= NA have clear instructions to enforce, and that both websocket and data cha= nnel specs consistently specify what implementations must do in this regard= .
=C2=A0
It is less important to me *which* choice is made. My *preference* would be= minimally that the registry not permit two different names that differ onl= y by case. If that is so, then in some sense it doesn't matter how impl= ementations of the protocols do the comparison.

How likely do you see this being?=C2=A0 Anyone going = to register XMPP (instead of xmpp) is going to be hurting themselves as muc= h as users of xmpp if they actually use it.=C2=A0 I'm happy to clean th= is up at some point, but I find it hard to believe this is the biggest rock= .

regards,

Ted
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

regards,

Ted

=C2=A0 =C2=A0 Background is draft-ietf-mmusic-data-channel-sdpneg, where th= e
=C2=A0 =C2=A0 subprotocol identifiers are signaled as part of an SDP attrib= ute and
=C2=A0 =C2=A0 where it is not yet clarified if these identifiers are assume= d to be
=C2=A0 =C2=A0 case sensitive or case insensitive.

=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 Juergen

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 rtcweb mailing list
 =C2=A0 =C2=A0 rtcweb@i= etf.org <mailto:rtcweb@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/rtc= web




_______________________________________________
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

--001a113a7326916ee4052d8e813d-- From nobody Tue Mar 8 12:07:20 2016 Return-Path: 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 B181312DA77 for ; Tue, 8 Mar 2016 12:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7IcjyCRCMCw for ; Tue, 8 Mar 2016 12:07:16 -0800 (PST) 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 7ACFC12DA73 for ; Tue, 8 Mar 2016 12:07:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E82777C78C9 for ; Tue, 8 Mar 2016 21:07:13 +0100 (CET) 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 sINpQj5F3Vqh for ; Tue, 8 Mar 2016 21:07:12 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:e859:9b66:9bb7:6edc] (unknown [IPv6:2001:470:de0a:1:e859:9b66:9bb7:6edc]) by mork.alvestrand.no (Postfix) with ESMTPSA id E61D67C783C for ; Tue, 8 Mar 2016 21:07:11 +0100 (CET) To: rtcweb@ietf.org References: <56DEC8F5.4070101@alcatel-lucent.com> <56DF03D8.6070308@alum.mit.edu> From: Harald Alvestrand X-Enigmail-Draft-Status: N1110 Message-ID: <56DF30EF.7040404@alvestrand.no> Date: Tue, 8 Mar 2016 21:07:11 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010602000106030009020500" Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 20:07:19 -0000 This is a multi-part message in MIME format. --------------010602000106030009020500 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This is a sidetrack, but the grammar in RFC 2616: token =3D 1* separators =3D "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=3D" | "{" | "}" | SP | HT + the ancient # rule means that "1#token" is a comma-separated list of tokens, where each token is separated by LWS. Not only do we (or someone) have to decide whether "xmpp" matches "XMPP", we also have to decide whether "iam,thegreatest" matches "iam , thegreatest" or even "iam, thegreatest" (yes, there's a newline in there). All tokens registered so far are single tokens. Would it be possible to advise against using identifiers with comma in them? (for the base question, since this is ASCII only, lowercase is well-defined, so I have no strong objection to either choice.) On 03/08/2016 08:22 PM, Ted Hardie wrote: > On Tue, Mar 8, 2016 at 8:54 AM, Paul Kyzivat > wrote: > > > The elements that comprise this value > MUST be non-empty strings with characters in the > range U+0021 to > U+007E not including separator characters as defined i= n > [RFC2616 ] and > MUST all be unique strings. The ABNF for the > value of this header field is 1#token, where the > definitions of > constructs and rules are as given in [RFC2616 > ]. > > The current registry is here: > > http://www.iana.org/assignments/websocket/websocket.xhtml#subpr= otocol-name > > > I had already investigated this. This only talks about the > registry, not how values passed in the protocol are compared to > registered values. Nor does it explicitly say whether "unique > strings" is to be determined via case-sensitive comparison or > case-insensitive comparison. > > (Without any other information to go on I guess I would assume > case-sensitive comparison.) > > Is there any token example in RFC 2616 that is case sensitive? As far > as I can tell they are all case-insensitive, but I may have missed > something.=20 > > The Postel principle seems to indicate that we should always use the > registered form, but be willing to understand a case insensitive varian= t. > > What is most *important* to me is that this be made entirely > clear, that IANA have clear instructions to enforce, and that both > websocket and data channel specs consistently specify what > implementations must do in this regard. > =20 > > It is less important to me *which* choice is made. My *preference* > would be minimally that the registry not permit two different > names that differ only by case. If that is so, then in some sense > it doesn't matter how implementations of the protocols do the > comparison. > > How likely do you see this being? Anyone going to register XMPP > (instead of xmpp) is going to be hurting themselves as much as users > of xmpp if they actually use it. I'm happy to clean this up at some > point, but I find it hard to believe this is the biggest rock. > > regards, > > Ted > =20 > > Thanks, > Paul > > regards, > > Ted > > Background is draft-ietf-mmusic-data-channel-sdpneg, where = the > subprotocol identifiers are signaled as part of an SDP > attribute and > where it is not yet clarified if these identifiers are > assumed to be > case sensitive or case insensitive. > > Thanks, > Juergen > > _______________________________________________ > 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 > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Surveillance is pervasive. Go Dark. --------------010602000106030009020500 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
This is a sidetrack, but the grammar in RFC 2616:

      token          = 1*<any CHAR except CTLs or separators>
       separators     = "(" | ")" | "<" | ">" | "@"
                      | "," | ";" | ":" | "\" | <">
                      | "/" | "[" | "]" | "?" | "="
                      | "{" | "}" | SP | HT

+ the ancient # rule
means that "1#token" is a comma-separated list of tokens, where each token is separated by LWS.

Not only do we (or someone) have to decide whether "xmpp" matches "XMPP", we also have to decide whether "iam,thegreatest" matches "iam , thegreatest" or even "iam,
thegreatest" (yes, there's a newline in there).

All tokens registered so far are single tokens. Would it be possible to advise against using identifiers with comma in them?

(for the base question, since this is ASCII only, lowercase is well-defined, so I have no strong objection to either choice.)


On 03/08/2016 08:22 PM, Ted Hardie wrote:
On Tue, Mar 8, 2016 at 8:54 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

The elements that comprise this value
MUST be non-empty strings with characters in the range U+0021 to
U+007E not including separator characters as defined in
 [RFC2616 <https://tools.ietf.org/html/rfc2616>] and MUST all be unique strings. The ABNF for the
value of this header field is 1#token, where the definitions of
 constructs and rules are as given in [RFC2616 <https://tools.ietf.org/html/rfc2616>].

The current registry is here:

http://www.iana.org/assignments/websocket/websocket.xhtml#subprotocol-name

I had already investigated this. This only talks about the registry, not how values passed in the protocol are compared to registered values. Nor does it explicitly say whether "unique strings" is to be determined via case-sensitive comparison or case-insensitive comparison.

(Without any other information to go on I guess I would assume case-sensitive comparison.)

Is there any token example in RFC 2616 that is case sensitive? As far as I can tell they are all case-insensitive, but I may have missed something.

The Postel principle seems to indicate that we should always use the registered form, but be willing to understand a case insensitive variant.

What is most *important* to me is that this be made entirely clear, that IANA have clear instructions to enforce, and that both websocket and data channel specs consistently specify what implementations must do in this regard.

It is less important to me *which* choice is made. My *preference* would be minimally that the registry not permit two different names that differ only by case. If that is so, then in some sense it doesn't matter how implementations of the protocols do the comparison.

How likely do you see this being? Anyone going to register XMPP (instead of xmpp) is going to be hurting themselves as much as users of xmpp if they actually use it. I'm happy to clean this up at some point, but I find it hard to believe this is the biggest rock.

regards,

Ted
Thanks,
Paul

regards,

Ted

Background is draft-ietf-mmusic-data-channel-sdpneg, where the
subprotocol identifiers are signaled as part of an SDP attribute and
where it is not yet clarified if these identifiers are assumed to be
case sensitive or case insensitive.

Thanks,
Juergen

_______________________________________________
rtcweb mailing list
 rtcweb@ietf.org <mailto: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



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb



-- 
Surveillance is pervasive. Go Dark.
--------------010602000106030009020500-- From nobody Tue Mar 8 12:58:29 2016 Return-Path: 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 A303612DA74 for ; Tue, 8 Mar 2016 12:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJBcrk2j88Np for ; Tue, 8 Mar 2016 12:58:20 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113E712D70E for ; Tue, 8 Mar 2016 12:58:20 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id s5so11706371qkd.0 for ; Tue, 08 Mar 2016 12:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v+TyWkdthl6Fg8iG50qWkVqcquZ15FY+S7mJQxSDous=; b=F7Q89xYo0tg2w3g/rGHqsbiAIK/n/fC1UzxZt5Zx2lsTHK+EFM0IS+fx0rph6sxe7s XUveobF1PME1mC9bCSqkTm9sm2TAJ0UPJrWH2a2PIpO7iPR/fmFLmfOx49KJ9wBggglS 05oErBXZW3Y3B5ahO6x5FyOXjNllXHjZOmI5cTlQBWcJfLcDEkJB+zfs/t4Wm6omqx3J PuRSdtjxrZ6oYotAAHwQD1jeONv2oHYCVri1yF5wMVc/0qmsz32uUt18/bqKlQVxGMe4 Zkr/QFLLOKYWKDmt5E+kA9ogIFh5qyIL2Yvs0EnnGj+qQko6y8MAaOsemQgGzxnLiCjX b45A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=v+TyWkdthl6Fg8iG50qWkVqcquZ15FY+S7mJQxSDous=; b=mm2RgmALtwKLRZ7dBz9YKYtelyD4LVFFrIz4dre2sfMNp0B9BPZ9JjLs123+HxcZa/ T942mhbGbFShFd4za3Z063R3QLL69ePpBXybH5HgqeZPRKL3793AnyYvIS/BuN1JFZzf dOubIhKg5jnEN2ybl8bw7HX6QlAjRSEBX0yBaHCwvyx1t+3oPbOFWAcoO47gaTQ1q9Tr ZkQ6DWqFrcPPA5+FljwbB87ETIdndCJOYtFxEsO6W2NKkiO4B8g9FLJfIMMrEuvSgCNF +lg4boLqNtC+GCIMmUZRtnBFnfBrYxFlenMGab53Ht0sncORIQbea5L26F82qbHh00El Nfyg== X-Gm-Message-State: AD7BkJJCg5pXKdboyy9PHaTCYU8MFzZp3HwsCYONHNgqye0Gvd/Qa8Efe5z6MGzm0ejQwHHMmsqwfqwxDjVWWQ== X-Received: by 10.55.71.66 with SMTP id u63mr38656046qka.67.1457470699171; Tue, 08 Mar 2016 12:58:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.6.13 with HTTP; Tue, 8 Mar 2016 12:57:59 -0800 (PST) In-Reply-To: <56DF30EF.7040404@alvestrand.no> References: <56DEC8F5.4070101@alcatel-lucent.com> <56DF03D8.6070308@alum.mit.edu> <56DF30EF.7040404@alvestrand.no> From: Ted Hardie Date: Tue, 8 Mar 2016 12:57:59 -0800 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a114a79744b74bb052d8fd76b Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 20:58:24 -0000 --001a114a79744b74bb052d8fd76b Content-Type: text/plain; charset=UTF-8 On Tue, Mar 8, 2016 at 12:07 PM, Harald Alvestrand wrote: > This is a sidetrack, but the grammar in RFC 2616: > > token = 1* > separators = "(" | ")" | "<" | ">" | "@" > | "," | ";" | ":" | "\" | <"> > | "/" | "[" | "]" | "?" | "=" > | "{" | "}" | SP | HT > > > + the ancient # rule > means that "1#token" is a comma-separated list of tokens, where each token > is separated by LWS. > > So, what RFC 6455 says is: The request MAY include a header field with the name |Sec-WebSocket-Protocol|. If present, this value indicates one or more comma-separated subprotocol the client wishes to speak, ordered by preference. The elements that comprise this value MUST be non-empty strings with characters in the range U+0021 to U+007E not including separator characters as defined in [RFC2616 ] and MUST all be unique strings. The ABNF for the value of this header field is 1#token, where the definitions of constructs and rules are as given in [RFC2616 ]. I think that text is clear enough that comma is used as a separator of sub-protocols and that "seperator charactors" are generally not allowed in the elements. So, I believe that faced with iam,thegreatest you would have to parse it as two tokens: "iam" and "the greatest". Ted > Not only do we (or someone) have to decide whether "xmpp" matches "XMPP", > we also have to decide whether "iam,thegreatest" matches "iam , > thegreatest" or even "iam, > thegreatest" (yes, there's a newline in there). > > All tokens registered so far are single tokens. Would it be possible to > advise against using identifiers with comma in them? > > (for the base question, since this is ASCII only, lowercase is > well-defined, so I have no strong objection to either choice.) > > > > On 03/08/2016 08:22 PM, Ted Hardie wrote: > > On Tue, Mar 8, 2016 at 8:54 AM, Paul Kyzivat > wrote: > >> >> The elements that comprise this value >>> MUST be non-empty strings with characters in the range U+0021 to >>> U+007E not including separator characters as defined in >>> [RFC2616 ] and MUST all >>> be unique strings. The ABNF for the >>> value of this header field is 1#token, where the definitions of >>> constructs and rules are as given in [RFC2616 < >>> https://tools.ietf.org/html/rfc2616>]. >>> >>> The current registry is here: >>> >>> >>> http://www.iana.org/assignments/websocket/websocket.xhtml#subprotocol-name >>> >> >> I had already investigated this. This only talks about the registry, not >> how values passed in the protocol are compared to registered values. Nor >> does it explicitly say whether "unique strings" is to be determined via >> case-sensitive comparison or case-insensitive comparison. >> >> (Without any other information to go on I guess I would assume >> case-sensitive comparison.) >> >> Is there any token example in RFC 2616 that is case sensitive? As far as > I can tell they are all case-insensitive, but I may have missed something. > > The Postel principle seems to indicate that we should always use the > registered form, but be willing to understand a case insensitive variant. > > What is most *important* to me is that this be made entirely clear, that >> IANA have clear instructions to enforce, and that both websocket and data >> channel specs consistently specify what implementations must do in this >> regard. >> >> > It is less important to me *which* choice is made. My *preference* would >> be minimally that the registry not permit two different names that differ >> only by case. If that is so, then in some sense it doesn't matter how >> implementations of the protocols do the comparison. >> >> How likely do you see this being? Anyone going to register XMPP (instead > of xmpp) is going to be hurting themselves as much as users of xmpp if they > actually use it. I'm happy to clean this up at some point, but I find it > hard to believe this is the biggest rock. > > regards, > > Ted > > >> Thanks, >> Paul >> >> regards, >>> >>> Ted >>> >>> Background is draft-ietf-mmusic-data-channel-sdpneg, where the >>> subprotocol identifiers are signaled as part of an SDP attribute and >>> where it is not yet clarified if these identifiers are assumed to be >>> case sensitive or case insensitive. >>> >>> Thanks, >>> Juergen >>> >>> _______________________________________________ >>> 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 >> > > > > _______________________________________________ > rtcweb mailing listrtcweb@ietf.orghttps://www.ietf.org/mailman/listinfo/rtcweb > > > > -- > Surveillance is pervasive. Go Dark. > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a114a79744b74bb052d8fd76b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 8, 2016 at 12:07 PM, Harald Alvestrand <ha= rald@alvestrand.no> wrote:
=20 =20 =20
This is a sidetrack, but the grammar in RFC 2616:

=20 
      token          =3D 1*<any CHAR e=
xcept CTLs or separators>
       separators     =3D "(" | ")" | "<" =
| ">" | "@"
                      | "," | ";" | ":" | &qu=
ot;\" | <">
                      | "/" | "[" | "]" | &qu=
ot;?" | "=3D"
                      | "{" | "}" | SP | HT

+ the ancient # rule
means that "1#token" is a comma-separated list of tokens, w= here each token is separated by LWS.

So, what RFC 6455 says is:
The request MAY include a header field with the name |Sec-WebSocket-Protocol|. If present, this value indicates one or more comma-separated subprotocol the client wishes to speak, ordered by preference. The elements that comprise this value MUST be non-empty strings with characters in the range U+0021 to U+007E not including separator characters as defined in [RFC2616] and MUST all be un= ique strings. The ABNF for the value of this header field is 1#token, where the definitions of constructs and rules are as given in [RFC2616].I think that text is clear enough that comma is us= ed as a separator of sub-protocols and that "seperator charactors"= ; are generally not allowed in the elements.=C2=A0 So, I believe that faced= with iam,thegreatest you would have to parse it as two tokens: "iam&q= uot; and "the greatest".

Ted

= =C2=A0
Not only do we (or someone) have to decide whether "xmpp" m= atches "XMPP", we also have to decide whether "iam,thegreates= t" matches "iam ,=C2=A0=C2=A0 thegreatest"=C2=A0 or even "iam, thegreatest" (yes, there's a newline in there).

All tokens registered so far are single tokens. Would it be possible to advise against using identifiers with comma in them?

(for the base question, since this is ASCII only, lowercase is well-defined, so I have no strong objection to either choice.)



On 03/08/2016 08:22 PM, Ted Hardie wrote:
On Tue, Mar 8, 2016 at 8:54 AM, Paul Kyzivat <p= kyzivat@alum.mit.edu> wrote:
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The elements that compr= ise this value
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0MUST be non-empty strin= gs with characters in the range U+0021 to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0U+007E not including se= parator characters as defined in
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[RFC2616 <ht= tps://tools.ietf.org/html/rfc2616>] and MUST all be unique strings.=C2=A0 The ABNF for the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0value of this header fi= eld is 1#token, where the definitions of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0constructs and rules are = as given in [RFC2616 <https://tools.ietf.org/html/rfc2616>].=

The current registry is here:

http://w= ww.iana.org/assignments/websocket/websocket.xhtml#subprotocol-name

I had already investigated this. This only talks about the registry, not how values passed in the protocol are compared to registered values. Nor does it explicitly say whether "unique strings" is to be determined via case-sensitive comparison or case-insensitive comparison.

(Without any other information to go on I guess I would assume case-sensitive comparison.)

Is there any token example in RFC 2616 that is case sensitive?=C2=A0 As far as I can tell they are all case-insensitive, but I may have missed something.=C2=A0

The Postel principle seems to indicate that we should always use the registered form, but be willing to understand a case insensitive variant.

What is most *important* to me is that this be made entirely clear, that IANA have clear instructions to enforce, and that both websocket and data channel specs consistently specify what implementations must do in this regard.
=C2=A0
It is less important to me *which* choice is made. My *preference* would be minimally that the registry not permit two different names that differ only by case. If that is so, then in some sense it doesn't matter how implementations of the protocols do the comparison.

How likely do you see this being?=C2=A0 Anyone going to register XMPP (instead of xmpp) is going to be hurting themselves as much as users of xmpp if they actually use it.=C2=A0 I'm happy to clean this up at some point, but I= find it hard to believe this is the biggest rock.

regards,

Ted
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

regards,

Ted

=C2=A0 =C2=A0 Background is draft-ietf-mmusic-data-channel-sdpneg, where the
=C2=A0 =C2=A0 subprotocol identifiers are signaled as par= t of an SDP attribute and
=C2=A0 =C2=A0 where it is not yet clarified if these iden= tifiers are assumed to be
=C2=A0 =C2=A0 case sensitive or case insensitive.

=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 Juergen

=C2=A0 =C2=A0 ___________________________________________= ____
=C2=A0 =C2=A0 rtcweb mailing list
 =C2=A0 =C2=A0 rtcweb@ietf.org <mailto:rtcweb@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailm= an/listinfo/rtcweb




_______________________________________________
rtcweb mailing list
rtcw= eb@ietf.org
https://www.ietf.org/mailman/listinfo/= rtcweb


_______________________________________________
rtcweb mailing list
rtcw= eb@ietf.org
https://www.ietf.org/mailman/listinfo/= rtcweb



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
=
https://www.ietf.org/mailman/listinfo/rtcweb



-=
-=20
Surveillance is pervasive. Go Dark.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--001a114a79744b74bb052d8fd76b-- From nobody Tue Mar 8 13:03:53 2016 Return-Path: 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 D31DD12DAD4 for ; Tue, 8 Mar 2016 13:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.011 X-Spam-Level: X-Spam-Status: No, score=0.011 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBt9Zl_KaKz5 for ; Tue, 8 Mar 2016 13:03:44 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1031112D552 for ; Tue, 8 Mar 2016 13:03:44 -0800 (PST) Received: by mail-qg0-x22f.google.com with SMTP id w104so24077655qge.1 for ; Tue, 08 Mar 2016 13:03:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=ADjDYX4x/fEz3o9XhZaVg3NqRdP5MqjDRDSE6m6t/KU=; b=KSUwqRuCLKI/TlI6auvyeu4ilRwY6ef10xPuzzRx9swOvoGbrM5QkN1OnfVi9C2AYG xoAhL0f7jPTsmv/mt02kSsEftreag/pyQbdWN2ljSnqrWUwtRzh4JXKuISquXl4Tokvi nV595KGsaGAAV5XXghDDLS1VY7eDm9w/TCPoTe74Nm7s6M/hJj6B4E6/8gjLNOjekA+G HS84V/PyCgBzgmq4M3gYR+pSDDcv/63oabuCku+IGzwk8lG+1Chzo416scKv/PVaTVow S+pB2rI20KQ7Apsd77sMWZjHtUubQsXoGaCW0yGwy2w4LuwHL6RZ0u6reWCYoxY14qBB dSfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ADjDYX4x/fEz3o9XhZaVg3NqRdP5MqjDRDSE6m6t/KU=; b=Kdqb+nRcsqEJXxKhpOh8gnHmbU1cRS/1qm/MiCpFmtZyR2fRXDWpJywp9HyzTkynkR Lou2yYGfrcU89FmcRBmco16F4wIOp4MaU4O15ElRn4cbX0VY40bObKLNhctpBj+OuZ7h sYj1rbMMACaGHcrOYnlwrVkGr+kV+Kvx3+hy8t4EN5fHbSEWB6a7jQD03mYDfWYia5b8 vcUwM0w8UBh/B0Bha6CMENCLjOvWhDGCnryI2VTWW/jzSMc0Te5OmXmGqkWcqihqkgw9 ciPWhTykoSLiAQFVm94x8M2q9u+eVZouhu2qDVAUXex4/lBws07gS8pIX2jTi6hT9AwH 6JLg== X-Gm-Message-State: AD7BkJIydweMYOIZ/WnB8YIJFReI0KO/gXDBSC5zwEgxQHawsmr33C/6l7jWWFc0hK6wUWf/THxE0+Z1oRapFQ== X-Received: by 10.140.106.11 with SMTP id d11mr38579248qgf.80.1457471023177; Tue, 08 Mar 2016 13:03:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.6.13 with HTTP; Tue, 8 Mar 2016 13:03:23 -0800 (PST) From: Ted Hardie Date: Tue, 8 Mar 2016 13:03:23 -0800 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a113952889b67cd052d8fea90 Archived-At: Subject: [rtcweb] Webex Details for upcoming meeting X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 21:03:50 -0000 --001a113952889b67cd052d8fea90 Content-Type: text/plain; charset=UTF-8 *From: *Cullen Jennings *Subject: **(Forward to others) WebEx meeting invitation: IETF RTCWeb* *Date: *February 23, 2016 at 9:32:23 AM MST *To: * *Reply-To: * Hello, Cullen Jennings invites you to join this WebEx meeting. *IETF RTCWeb* Thursday, March 10, 2016 9:00 am | Pacific Standard Time (San Francisco, GMT-08:00) | 2 hrs *Join WebEx meeting* Meeting number: 207 722 149 Meeting password: rtcweb *Join by phone* *+1-408-525-6800 <%2B1-408-525-6800>* Call-in toll number (US/Canada) *+1-866-432-9903 <%2B1-866-432-9903>* Call-in toll-free number (US/Canada) Access code: 207 722 149 Numeric meeting password: 91034272 Global call-in numbers | Toll-free calling restrictions Add this meeting to your calendar. (Cannot add from mobile devices.) Can't join the meeting? Contact support. IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. --001a113952889b67cd052d8fea90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<= div class=3D"" style=3D"min-height:1px;width:1157.33px">
=
From:=C2=A0Cullen Jennings <messenger@webex.com>
Subject:=C2=A0(= Forward to others) WebEx meeting invitation: IETF RTCWeb
Date:<= span class=3D"">=C2=A0February 23, 2= 016 at 9:32:23 AM MST
To:=C2=A0<= span style=3D"font-family:-webkit-system-font,"Helvetica Neue",He= lvetica,sans-serif"><fluffy@cisco.com>
=
Reply-To= :=C2=A0<fluffy@cisco.com>

<= td style=3D"font-family:Arial;margin:0px;word-wrap:break-word;font-size:15p= x;color:rgb(102,102,102);padding:0px">Access code:=C2=A0207 722 149

=
<= td style=3D"font-family:Arial;margin:0px;word-wrap:break-word;font-size:15p= x;color:rgb(77,77,77);padding:10px 0px 0px">Cullen Jennings invites you to = join this WebEx meeting.
Hello,
=C2=A0
9:00 am=C2=A0=C2=A0|=C2=A0=C2=A0Pacifi= c Standard Time (San Francisco, GMT-08:00)=C2=A0=C2=A0|=C2=A0=C2=A02 hrs
IETF RTCWeb
Thu= rsday, March 10, 2016
=C2=A0
Join WebEx m= eeting
Meet= ing number:207 722 149
Meeting password:rtcweb=
=C2=A0
<= table style=3D"border-collapse:separate;border:0px none white;border-spacin= g:0px;width:524.667px;max-width:525px!important;min-width:279px!important">=
<= td style=3D"font-family:Arial;margin:0px;word-wrap:break-word;font-size:15p= x;color:rgb(102,102,102);padding:0px">+1-= 408-525-6800=C2=A0Call-in toll number (US/Canada)
+1-866-432-9903=C2=A0Call-in toll-f= ree number (US/Canada)
Numeric meeting password: 91034272
Global cal= l-in numbers=C2=A0=C2=A0|=C2=A0=C2=A0Toll-f= ree calling restrictions
=C2=A0=
Add this meeting=C2=A0to your calendar. (Can= not add from mobile devices.)
=C2= =A0
Can't join the meeting?=C2=A0Contact support.
=C2=A0
=
IMPORTANT NOTICE: Please note that t= his WebEx service allows audio and other information sent during the sessio= n to be recorded, which may be discoverable in a legal matter. By joining t= his session, you automatically consent to such recordings. If you do not co= nsent to being recorded, discuss your concerns with the host or do not join= the session.
=

--001a113952889b67cd052d8fea90-- From nobody Tue Mar 8 16:57:10 2016 Return-Path: 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 53FAB12DCE4 for ; Tue, 8 Mar 2016 16:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OprRx1kofoGF for ; Tue, 8 Mar 2016 16:57:05 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9673712DCE1 for ; Tue, 8 Mar 2016 16:57:05 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id n190so48237555iof.0 for ; Tue, 08 Mar 2016 16:57:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Xxtvq8V+G8vobfe0sMOuoMh1DbVpBB93XXnbIawnd3o=; b=ztAzzDqp7UcUi4X50xKV77Zu8uZhRohZQWlSpEGTKWU9lNg/OYfNYz3Y6NTXnEntie xZhuIJYuH2FkIPD1BgUDF5Lwa1Ln040ECP8X4zkIcHw2N9t738UPqeVoh+YkYfrRImgz wqGLSHTO72Y6OqOX4N3+JjgC6mGj+D0b3LmGJqf0jozJVbty7JS6qwdI+U2CnPyIRCB/ Lcyi83J+W3K8fVN+FQ8oCNfnVSCtVBqLmoMfCwriz64CGY0IHWmCdABIUN4RHNXCj1dh jf7Z/kAUX2MByMB2Un540H7hDf/Wv4deEkH7WOzpxn0r/Lg+YfCdrv/CerOEGLPX4qgB RMmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Xxtvq8V+G8vobfe0sMOuoMh1DbVpBB93XXnbIawnd3o=; b=e2ai5yVbb9NId39X0dcCY5tTHlZyijSc7/VOgYSMZwsr1Gh5WVgoeluxGAiMJMKTAj 1Bszf+jndYdiaT8wUJPRjoHxgQDGHpZbhoh1Eyx5Doh3ABxdyRqR1YAhhT5VT7EiM0H3 HtA3bDJ8CS/7CT/Iirxujujs2wnogyAOKKJnGYg/N4LwIqZDCEEzBRgra8K6h8KjU0eQ ah8JPKHJGOyub+gIt3O++REf/s4cUMyx059Lr6mGOAvLLkztfDHWfYMalUOVYHeTxR9H RgYbsaXdeBnQ9+KfOuc5t+9OoaEkNu7oZaKlu6hRiuteNLRXt8zxdMgI+DDTUz+YBBKE nklw== X-Gm-Message-State: AD7BkJKnj0ptK6ll+E3wrm5WbJ1TaD04WFT75CiR39Sko/7vO0dz/8qViKgrMBNqBZRiTQ== X-Received: by 10.107.18.214 with SMTP id 83mr20727797ios.130.1457485024909; Tue, 08 Mar 2016 16:57:04 -0800 (PST) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com. [209.85.213.172]) by smtp.gmail.com with ESMTPSA id c193sm2187746ioe.18.2016.03.08.16.57.03 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Mar 2016 16:57:03 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id av4so3795208igc.1 for ; Tue, 08 Mar 2016 16:57:03 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.18.113 with SMTP id v17mr12284561igd.2.1457485022972; Tue, 08 Mar 2016 16:57:02 -0800 (PST) Received: by 10.36.105.77 with HTTP; Tue, 8 Mar 2016 16:57:02 -0800 (PST) In-Reply-To: References: <56DDF13F.1050505@mozilla.com> Date: Tue, 8 Mar 2016 19:57:02 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=089e01494ff20f5af1052d932d88 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] DTMF resolution proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 00:57:08 -0000 --089e01494ff20f5af1052d932d88 Content-Type: text/plain; charset=UTF-8 Unless someone objects, I think the language would be: WebRTC endpoints generated events MUST have duration of no more than 8000 ms and no less than 40 ms with the recommended default duration of 100 ms for each tone. The gap between events MUST be no less then 30 ms with the recommended default duration of 70 ms. WebRTC endpoints limits this language to browsers and removes this requirements from the gateways. I do not think we should add any language about retransmission of the final packets since this will cause another unnecessary debate (for instance I think the value of 20 ms is wrong and it should be much shorter). If you want to change this please write an update draft for RFC 4733 and we can discuss it there. Regards, _____________ Roman Shpount On Tue, Mar 8, 2016 at 2:24 AM, Asveren, Tolga wrote: > Would the text be crafted so that it pertains **only** to the RFC4733 > digit packets emitted by a browser? > > > > Information about gap between retransmission of the final packet could be > useful as well and I suggest 20ms for that one. > > > > Thanks, > > Tolga > > > > *From:* rtcweb [mailto:rtcweb-bounces@ietf.org] *On Behalf Of *Ted Hardie > *Sent:* Monday, March 07, 2016 5:19 PM > *To:* Jean-Marc Valin > *Cc:* Cullen Jennings ; rtcweb@ietf.org > *Subject:* Re: [rtcweb] DTMF resolution proposal > > > > On Mon, Mar 7, 2016 at 1:23 PM, Jean-Marc Valin > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > As proposed by Roman, I think we should also include the "minimum gap > of 30 ms". Otherwise, I support the proposal. > > > > Thank you Jean-Marc; I had not thought to include that in my note, but I > agree. > > regards, > > Ted > > > > > Jean-Marc > > > On 03/07/2016 03:35 PM, Ted Hardie wrote: > > We've had about 60 or so messages on this topic, and the rough > > consensus seems to be align this document with the limits set out > > in the W3C work here: > > > > https://www.w3.org/TR/webrtc/#rtcdtmfsender > > > > However, there was also a proposal to slightly modify those limits. > > They are currently: > > > > "The duration cannot be more than 6000 ms or less than 40 ms. The > > default duration is 100 ms for each tone." > > > > Based on Roman's note, a minimum of 40ms and a maximum 8000 ms to > > align with the ITU and RFC2833. > > > > To resolve this, I propose that we ask the WebRTC group to raise > > their max to 8000 and, on receiving a positive response, publish > > this document with 40/8000 as the min and max. If they give a > > negative response, we retain 40/6000. This values alignment > > between the two documents higher than the reference 2833, but that > > seems sensible in this context. > > > > If you have an objection to this way forward, please send your > > reasoning to the list by March 14th. > > > > thanks, > > > > Ted > > > > > > > > > _______________________________________________ rtcweb mailing > > list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJW3fE5AAoJEJ6/8sItn9q9KDgH/j4bSutkSjUmvt6aTtt26qF6 > FKF2JMkrZc8pjSg6IDTq9MJradJr8WSzr27VSpedWOHHPFf5z4jDn6IpVVMyTUtP > Jj6MvAPTyf9uB7UGq8rfA9y6az9OjChsJZ3j2/yPk7i/bnVYObg0OXOItyPA2+kA > 7KCJAIWUiIBdfifKV8W1qre5DbUVi4iXnGIzbQ5KJIpxrO3Cxrq+vlPy7Gznc1a1 > o4B50DU6p3nBILGgCXpFwAMW5PBfco/oAOzCH90gqcM8hzEROW50LTJED/OP0K/b > S3LMG3M+BriuAaslwW/Tj0qm3VUqtFpKaE3I0zjlxUbvfsxg/JYju2ebGSslZ7I= > =dpJA > -----END PGP SIGNATURE----- > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --089e01494ff20f5af1052d932d88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Unless someone objects, I think the language would be:
WebRTC endpoints generated events=C2=A0MUST have duration of no more than 8000 = ms and no less=C2=A0than 40 ms with the recommended default duration of 100= ms for each tone. The gap between events MUST be no less then 30 ms with t= he recommended=C2=A0default duration of 70 ms.

WebRTC endpoints limits this la= nguage to browsers and removes this requirements from the gateways.

I do not think we should add an= y language about retransmission of the final packets since this will cause = another unnecessary debate (for instance I think the value of 20 ms is wron= g and it should be much shorter). If you want to change this please write a= n update draft for RFC 4733 and we can discuss it there.=C2=A0

Regards,
_____________
Roman Shpount=

On Tue, Mar 8, 2016 at 2:24 AM, Asveren, Tol= ga <tasveren@sonusnet.com> wrote:

Would the text be crafted so that it pertain= s *only* to the RFC4733 digit packets emitted by a browser?

=C2=A0

Information about gap between retransmission= of the final packet could be useful as well and I suggest 20ms for that on= e.

=C2=A0

Thanks,

Tolga

=C2=A0

From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: Monday, March 07, 2016 5:19 PM
To: Jean-Marc Valin <jmvalin@mozilla.com>
Cc: Cullen Jennings <fluffy@cisco.com>; rtcweb@ietf.org
Subject: Re: [rtcweb] DTMF resolution proposal<= /p>

=C2=A0

On Mon, Mar 7, 2016 at 1:23 PM, Jean-Marc Valin <= jmvalin@mozilla.co= m> wrote:

-----BEGIN PGP SIGNED M= ESSAGE-----
Hash: SHA256

As proposed by Roman, I think we should also include the "minimum gap<= br> of 30 ms". Otherwise, I support the proposal.

=C2=A0

Thank you Jean-Marc; I = had not thought to include that in my note, but I agree.

regards,<= /p>

Ted


=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jean-Marc<= /p>


On 03/07/2016 03:35 PM, Ted Hardie wrote:
> We've had about 60 or so messages on this topic, and the rough
> consensus seems to be align this document with the limits set out
> in the W3C work here:
>
> https://www.w3.org/TR/webrtc/#rtcdtmfsender
>
> However, there was also a proposal to slightly modify those limits. >=C2=A0 They are currently:
>
> "The duration cannot be more than 6000 ms or less than 40 ms. The=
> default duration is 100 ms for each tone."
>
> Based on Roman's note, a minimum of 40ms and a maximum 8000 ms to<= br> > align with the ITU and RFC2833.
>
> To resolve this, I propose that we ask the WebRTC group to raise
> their max to 8000 and, on receiving a positive response, publish
> this document with 40/8000 as the min and max.=C2=A0 If they give a > negative response, we retain 40/6000.=C2=A0 This values alignment
> between the two documents higher than the reference 2833, but that
> seems sensible in this context.
>
> If you have an objection to this way forward, please send your
> reasoning to the list by March 14th.
>
> thanks,
>
> Ted
>
>
>

> _______________________________________________= rtcweb mailing
> list rtcweb@ietf.= org https://www.ietf.org/mailman/listinfo/rtcweb
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJW3fE5AAoJEJ6/8sItn9q9KDgH/j4bSutkSjUmvt6aTtt26qF6
FKF2JMkrZc8pjSg6IDTq9MJradJr8WSzr27VSpedWOHHPFf5z4jDn6IpVVMyTUtP
Jj6MvAPTyf9uB7UGq8rfA9y6az9OjChsJZ3j2/yPk7i/bnVYObg0OXOItyPA2+kA
7KCJAIWUiIBdfifKV8W1qre5DbUVi4iXnGIzbQ5KJIpxrO3Cxrq+vlPy7Gznc1a1
o4B50DU6p3nBILGgCXpFwAMW5PBfco/oAOzCH90gqcM8hzEROW50LTJED/OP0K/b
S3LMG3M+BriuAaslwW/Tj0qm3VUqtFpKaE3I0zjlxUbvfsxg/JYju2ebGSslZ7I=3D
=3DdpJA
-----END PGP SIGNATURE-----

=C2=A0


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--089e01494ff20f5af1052d932d88-- From nobody Tue Mar 8 17:29:24 2016 Return-Path: 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 997B712DD2D for ; Tue, 8 Mar 2016 17:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpPJOqXgw3E8 for ; Tue, 8 Mar 2016 17:29:19 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4BC12DD2E for ; Tue, 8 Mar 2016 17:29:19 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id 129so26153173pfw.1 for ; Tue, 08 Mar 2016 17:29:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=C8dExjVDeHmCXbvBDLBFhNufPPs1yOVqraFtG+Dw6rA=; b=S2Bf2/ERiQLO035b2BWSvGKmxXfZXPikqYRMQHd+sY8ek/v9fsc/52a2NKNINIp6ps /6s1kxKMCZb1l9JzGtg/e3HNNFVCGZsBUvq9FFWHcJc73/ZsQIE75w8L5Nsg8hgPg7Bc szv7wQb/i1Y/3IZ/xhnt+Js9RwzSSGTBlox2MaXqAWJj51PaDfEiGcplGCvZtYLlxlTi l7Wg8cKFmQGPCQZYKLIpVhiWAE2SB3+hPAPKPY6sY/K6i7vLShQWykZrPYEQb31EbAYH 7frFbnfmPYPTouWCuYglhqSMLnfcwIrI5lVQ2V0HCLR+RXZ1sbIGfREoYB/EpzDBJGKu F/XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=C8dExjVDeHmCXbvBDLBFhNufPPs1yOVqraFtG+Dw6rA=; b=mQ+VKO74XCeyLout/S4wOvMKPZbL0R46evgvsXuQx5xJk1U6X4PUQCwX5EUj2suYfP CGhw0cSJltWZDwot8ehGP2LXUsgDL8wi1GWXCxmnehAf0cn577DZM+raE8VinukU9wE9 XgGg17uyvu1vSIqo5XeoXA42s66d8XxyPm6DQHD7oz5Tc5aXece1ptSPE9hv5mUig+Yg yo+nIEydd8b93mwnqpxKlVHMU1LV+h9vZejcHMrwAjtQL52JzzSleREsaJUDCZifOmfA yZRniMnALEP0v6sZBIokOc0syIueexXc7y9DEYc2ZetVGQuBTw0BFbWKfM9eq3JLcxOb RK9Q== X-Gm-Message-State: AD7BkJL/3vOPj/G963k1dsHRtmIjy20afdAalHh0MzXJE/WLQVDaPqFx1SdvZ103rYxdSoLi X-Received: by 10.98.86.77 with SMTP id k74mr29617059pfb.28.1457486958923; Tue, 08 Mar 2016 17:29:18 -0800 (PST) Received: from panoramix.jmvalin.ca ([2620:101:80fc:224:7e7a:91ff:fe20:963f]) by smtp.gmail.com with ESMTPSA id b79sm7677743pfj.25.2016.03.08.17.29.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Mar 2016 17:29:17 -0800 (PST) To: Roman Shpount , "Asveren, Tolga" References: <56DDF13F.1050505@mozilla.com> From: Jean-Marc Valin X-Enigmail-Draft-Status: N1110 Message-ID: <56DF7C6B.4050400@mozilla.com> Date: Tue, 8 Mar 2016 20:29:15 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] DTMF resolution proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 01:29:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm not going to make a big deal out of this, but it feels to me like the default duration should be in the W3C doc rather than in the IETF doc since it describes browser behaviour rather than something can can be observed on the wire. Of course, it doesn't hurt either, so I won't object if people disagree with me. Cheers, Jean-Marc On 03/08/2016 07:57 PM, Roman Shpount wrote: > Unless someone objects, I think the language would be: > > WebRTC endpoints generated events MUST have duration of no more > than 8000 ms and no less than 40 ms with the recommended default > duration of 100 ms for each tone. The gap between events MUST be no > less then 30 ms with the recommended default duration of 70 ms. > > WebRTC endpoints limits this language to browsers and removes this > requirements from the gateways. > > I do not think we should add any language about retransmission of > the final packets since this will cause another unnecessary debate > (for instance I think the value of 20 ms is wrong and it should be > much shorter). If you want to change this please write an update > draft for RFC 4733 and we can discuss it there. > > Regards, _____________ Roman Shpount > > On Tue, Mar 8, 2016 at 2:24 AM, Asveren, Tolga > > wrote: > > Would the text be crafted so that it pertains **only** to the > RFC4733 digit packets emitted by a browser? ____ > > __ __ > > Information about gap between retransmission of the final packet > could be useful as well and I suggest 20ms for that one.____ > > __ __ > > Thanks,____ > > Tolga____ > > __ __ > > *From:*rtcweb [mailto:rtcweb-bounces@ietf.org > ] *On Behalf Of *Ted Hardie *Sent:* > Monday, March 07, 2016 5:19 PM *To:* Jean-Marc Valin > > *Cc:* Cullen > Jennings >; > rtcweb@ietf.org *Subject:* Re: [rtcweb] > DTMF resolution proposal____ > > __ __ > > On Mon, Mar 7, 2016 at 1:23 PM, Jean-Marc Valin > > wrote:____ > > As proposed by Roman, I think we should also include the "minimum > gap of 30 ms". Otherwise, I support the proposal.____ > >> __ __ > >> Thank you Jean-Marc; I had not thought to include that in my >> note, but I agree.____ > >> regards,____ > >> Ted____ > > >> ____ > > Jean-Marc____ > > > On 03/07/2016 03:35 PM, Ted Hardie wrote: >> We've had about 60 or so messages on this topic, and the rough >> consensus seems to be align this document with the limits set >> out in the W3C work here: > >> https://www.w3.org/TR/webrtc/#rtcdtmfsender > >> However, there was also a proposal to slightly modify those > limits. >> They are currently: > >> "The duration cannot be more than 6000 ms or less than 40 ms. >> The default duration is 100 ms for each tone." > >> Based on Roman's note, a minimum of 40ms and a maximum 8000 ms >> to align with the ITU and RFC2833. > >> To resolve this, I propose that we ask the WebRTC group to raise >> their max to 8000 and, on receiving a positive response, publish >> this document with 40/8000 as the min and max. If they give a >> negative response, we retain 40/6000. This values alignment >> between the two documents higher than the reference 2833, but >> that seems sensible in this context. > >> If you have an objection to this way forward, please send your >> reasoning to the list by March 14th. > >> thanks, > >> Ted > > >> ____ > >> _______________________________________________ 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 > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW33xoAAoJEJ6/8sItn9q9agEIAIDvDjcyiWb1jrDPRiPmY2z0 uOtzfmdg7FurvbEM4uIn5S30DrbB1i5ncl2xTmM24/jIHKAVtr/pXbMt5jH5a/F8 XMQs5zkgK7w1tP/EykJ3f2ti5pWc18Lia8rYMzKdm0GEwcUQMemUCZ+7WrqT0N3p BHYPZY8B4qR/7TK+AquxcWUUZsQdPi3LaGcJwJF9+KwRKuXAQcEphUVs2SnF48+F IMFlhRyT097gaz5lOFS36AeyS8SO1So8W1Y2hwGMIjmuHJAMJm4vN4E8JO4R49MF gsvqeYimx8YZtxJww02aBN/gauUwdecol5N6xXk3haWTgdgvBJjfWzRIOsSluVo= =WJ2n -----END PGP SIGNATURE----- From nobody Tue Mar 8 19:03:00 2016 Return-Path: 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 8B1B012DDAE for ; Tue, 8 Mar 2016 19:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KctteUZBKdbi for ; Tue, 8 Mar 2016 19:02:57 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB68412DDAB for ; Tue, 8 Mar 2016 19:02:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=okgWEc4XcDGER8AoPc8j2goEEzZMFr9Lx1oRWD8blWk=; b=sp6U1h/ydiu3k7YSEMB78eb1J6 3Z4/m30J1P87T4UZcyJTMMQI0+Y1knmBj88/e1Ln5XPKk4a1awJOuZCt7Xey8Y5vqGazDnA8nR7ok hhdQ0UW5xmlJOsUfERHQHMSHtyMXxstTKtqWGWyiqgaDxNRHqQxezAre5fUHBkkkblMKbK83yjwEE 1mrZ16pLC3vw4qIrdxy4r7Es8zqvWl1l+FOO8UBCI1ZpxscKfyf9J6XWU1ZabGBZRiLAWNNeBo7Hj K/4Y8oQmAuJmgW4darzrKJmPB7mRCDgqgBq6jSlZQ32UiyVmdLZd+6WlV9TDhMFqwECjRHRIEpn/J nLFB5m0A==; Received: from ppp118-209-64-163.lns20.mel4.internode.on.net ([118.209.64.163]:54438 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1adUOk-001nS1-Qp for rtcweb@ietf.org; Wed, 09 Mar 2016 14:02:54 +1100 To: rtcweb@ietf.org References: <56DEC8F5.4070101@alcatel-lucent.com> <56DF03D8.6070308@alum.mit.edu> <56DF30EF.7040404@alvestrand.no> From: Christian Groves Message-ID: <56DF925A.1050209@nteczone.com> Date: Wed, 9 Mar 2016 14:02:50 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 03:02:58 -0000 Hello, According to draft-ietf-mmusic-rfc4566bis-16 clause 5, SDP values are case significant unless specified otherwise. So that would make certain registered tokens such as MID case sensitive. So if we're using a case sensitive SDP field to define to indicate the subprotocol then I think it would follow that DCEP should maintain the case sensitivity. We might have similar issue for RTP/RTCP SDES e.g. BUNDLE MID (draft-ietf-mmusic-sdp-bundle-negotiation-27), CLUE ID (draft-ietf-clue-rtp-mapping-06). I don't think there's a general rule about maintaining case sensitivity for these cases? Christian On 9/03/2016 7:57 AM, Ted Hardie wrote: > On Tue, Mar 8, 2016 at 12:07 PM, Harald Alvestrand > > wrote: > > This is a sidetrack, but the grammar in RFC 2616: > > token = 1* > separators = "(" | ")" | "<" | ">" | "@" > | "," | ";" | ":" | "\" | <"> > | "/" | "[" | "]" | "?" | "=" > | "{" | "}" | SP | HT > > > + the ancient # rule > means that "1#token" is a comma-separated list of tokens, where > each token is separated by LWS. > > So, what RFC 6455 says is: > The request MAY include a header field with the name > |Sec-WebSocket-Protocol|. If present, this value indicates one > or more comma-separated subprotocol the client wishes to speak, > ordered by preference. The elements that comprise this value > MUST be non-empty strings with characters in the range U+0021 to > U+007E not including separator characters as defined in > [RFC2616 ] and MUST all be unique strings. The ABNF for the > value of this header field is 1#token, where the definitions of > constructs and rules are as given in [RFC2616 ]. > I think that text is clear enough that comma is used as a separator of > sub-protocols and that "seperator charactors" are generally not > allowed in the elements. So, I believe that faced with > iam,thegreatest you would have to parse it as two tokens: "iam" and > "the greatest". > > Ted > > Not only do we (or someone) have to decide whether "xmpp" matches > "XMPP", we also have to decide whether "iam,thegreatest" matches > "iam , thegreatest" or even "iam, > thegreatest" (yes, there's a newline in there). > > All tokens registered so far are single tokens. Would it be > possible to advise against using identifiers with comma in them? > > (for the base question, since this is ASCII only, lowercase is > well-defined, so I have no strong objection to either choice.) > > > > On 03/08/2016 08:22 PM, Ted Hardie wrote: >> On Tue, Mar 8, 2016 at 8:54 AM, Paul Kyzivat >> > wrote: >> >> >> The elements that comprise this value >> MUST be non-empty strings with characters in the >> range U+0021 to >> U+007E not including separator characters as >> defined in >> [RFC2616 ] >> and MUST all be unique strings. The ABNF for the >> value of this header field is 1#token, where the >> definitions of >> constructs and rules are as given in [RFC2616 >> ]. >> >> The current registry is here: >> >> http://www.iana.org/assignments/websocket/websocket.xhtml#subprotocol-name >> >> >> I had already investigated this. This only talks about the >> registry, not how values passed in the protocol are compared >> to registered values. Nor does it explicitly say whether >> "unique strings" is to be determined via case-sensitive >> comparison or case-insensitive comparison. >> >> (Without any other information to go on I guess I would >> assume case-sensitive comparison.) >> >> Is there any token example in RFC 2616 that is case sensitive? >> As far as I can tell they are all case-insensitive, but I may >> have missed something. >> >> The Postel principle seems to indicate that we should always use >> the registered form, but be willing to understand a case >> insensitive variant. >> >> What is most *important* to me is that this be made entirely >> clear, that IANA have clear instructions to enforce, and that >> both websocket and data channel specs consistently specify >> what implementations must do in this regard. >> >> It is less important to me *which* choice is made. My >> *preference* would be minimally that the registry not permit >> two different names that differ only by case. If that is so, >> then in some sense it doesn't matter how implementations of >> the protocols do the comparison. >> >> How likely do you see this being? Anyone going to register XMPP >> (instead of xmpp) is going to be hurting themselves as much as >> users of xmpp if they actually use it. I'm happy to clean this >> up at some point, but I find it hard to believe this is the >> biggest rock. >> >> regards, >> >> Ted >> >> Thanks, >> Paul >> >> regards, >> >> Ted >> >> Background is draft-ietf-mmusic-data-channel-sdpneg, >> where the >> subprotocol identifiers are signaled as part of an >> SDP attribute and >> where it is not yet clarified if these identifiers >> are assumed to be >> case sensitive or case insensitive. >> >> Thanks, >> Juergen >> >> _______________________________________________ >> 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 >> >> >> >> >> _______________________________________________ >> 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 > > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Mar 8 20:44:26 2016 Return-Path: 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 4C40A12DE84 for ; Tue, 8 Mar 2016 20:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBKC4Oha-cWy for ; Tue, 8 Mar 2016 20:44:22 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AB1B12DE8E for ; Tue, 8 Mar 2016 20:44:22 -0800 (PST) Received: by mail-ig0-x22b.google.com with SMTP id av4so6985924igc.1 for ; Tue, 08 Mar 2016 20:44:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to; bh=AaapRIjzM4a2eaMJBOIcJiMUyBMHDCDZO/kUDImkbZs=; b=YUaev1+XBQ4wwW9NE9bMxB/sLQvN3cO9aq7Dq7UDQnzxs+GVaXckLtSbU8r8/8jpHs hUOohucYWueFOqTKFQygWyvLVTJ7EQKQTDOcZlozvp4tzxY1R0CZ7F6xj8b+OQbez+M3 59sds3pjtVHkp/VRRqsenPvyos/ECRpdlwsRnFC+FI1lkqjZwHraD8ZkkXWDndyIalJc 3X4eLIlN+DTlxXRdnuryYYhNk7yLtmnTI4L/l3oZ1BXz6afrgE2XPvVYUWDHAUE/rMYR pc42MBMTOGttmvgxFSIgcUjKYJhtdBs8WhhO5I0PSlfn/gaH7gKuMxYxYx9+WPC7Eq/h VDhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to; bh=AaapRIjzM4a2eaMJBOIcJiMUyBMHDCDZO/kUDImkbZs=; b=F3zXx72T8XPokI0OOatVw0L7ennHkyv+WgO+wwDJ5zdWFosK1sSJtAULp/DmvKwPI4 4dfmHKP5ATYKxDhNcT7w+7jsdkmxrxWh0JO8dwSS8D4HnYrU8vA7DHrfik3DeHvFOScL BJBksWQB4IDOgXSAI8HzT/YGWy2H2lNQBumDRkWm3lQ9FMME6VMC4Yp+3HUBtIZZ4UuP PMd774dw6EJ0h+/rv/PA4DXRf/uR7GKZE1MdubSOVXq3Kz4JQ5Pva1TiIKrGjfLImmpi rN9bvz89nCFcK0csTpkOfI/2B84fFweKRSqLXd4fe6hBRPcGHTVd5dszAP3srC1Ix6rr d+Jg== X-Gm-Message-State: AD7BkJIN5an8i+uoOgDRQOk2/yvpO0rQR26d6kaEdAJMqB+o2eKWessJ6MU2gVTu2KgUrB/OIAZ2AvSPvrhclQ== MIME-Version: 1.0 X-Received: by 10.50.124.41 with SMTP id mf9mr23868132igb.53.1457498661500; Tue, 08 Mar 2016 20:44:21 -0800 (PST) Sender: markh.sj@gmail.com Received: by 10.107.198.5 with HTTP; Tue, 8 Mar 2016 20:44:21 -0800 (PST) In-Reply-To: <56DF7C6B.4050400@mozilla.com> References: <56DDF13F.1050505@mozilla.com> <56DF7C6B.4050400@mozilla.com> Date: Tue, 8 Mar 2016 20:44:21 -0800 X-Google-Sender-Auth: yMUl2Zkyfk3-aa5HG0px-sJGIpA Message-ID: From: Mark Harris To: Jean-Marc Valin , Roman Shpount , "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [rtcweb] DTMF resolution proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 04:44:24 -0000 Agreed. Also I assume the intention is only to restrict DTMF events, not any other audio/telephone-event events that an implementation might wish to support, and that (like the duration) the minimum gap is intended to apply to WebRTC-endpoint-generated DTMF events. How about this: Each DTMF event generated by a WebRTC endpoint MUST have a duration no less than 40 ms and no more than 8000 ms, and MUST begin no sooner than 30 ms after the end of the last generated DTMF event if any. - Mark On Tue, Mar 8, 2016 at 5:29 PM, Jean-Marc Valin wrote: > I'm not going to make a big deal out of this, but it feels to me like > the default duration should be in the W3C doc rather than in the IETF > doc since it describes browser behaviour rather than something can can > be observed on the wire. Of course, it doesn't hurt either, so I won't > object if people disagree with me. > > Cheers, > > Jean-Marc > > On 03/08/2016 07:57 PM, Roman Shpount wrote: >> Unless someone objects, I think the language would be: >> >> WebRTC endpoints generated events MUST have duration of no more >> than 8000 ms and no less than 40 ms with the recommended default >> duration of 100 ms for each tone. The gap between events MUST be no >> less then 30 ms with the recommended default duration of 70 ms. >> >> WebRTC endpoints limits this language to browsers and removes this >> requirements from the gateways. >> >> I do not think we should add any language about retransmission of >> the final packets since this will cause another unnecessary debate >> (for instance I think the value of 20 ms is wrong and it should be >> much shorter). If you want to change this please write an update >> draft for RFC 4733 and we can discuss it there. >> >> Regards, _____________ Roman Shpount >> >> On Tue, Mar 8, 2016 at 2:24 AM, Asveren, Tolga >> > wrote: >> >> Would the text be crafted so that it pertains **only** to the >> RFC4733 digit packets emitted by a browser? ____ >> >> __ __ >> >> Information about gap between retransmission of the final packet >> could be useful as well and I suggest 20ms for that one.____ >> >> __ __ >> >> Thanks,____ >> >> Tolga____ >> >> __ __ >> >> *From:*rtcweb [mailto:rtcweb-bounces@ietf.org >> ] *On Behalf Of *Ted Hardie *Sent:* >> Monday, March 07, 2016 5:19 PM *To:* Jean-Marc Valin >> > *Cc:* Cullen >> Jennings >; >> rtcweb@ietf.org *Subject:* Re: [rtcweb] >> DTMF resolution proposal____ >> >> __ __ >> >> On Mon, Mar 7, 2016 at 1:23 PM, Jean-Marc Valin >> > wrote:____ >> >> As proposed by Roman, I think we should also include the "minimum >> gap of 30 ms". Otherwise, I support the proposal.____ >> >>> __ __ >> >>> Thank you Jean-Marc; I had not thought to include that in my >>> note, but I agree.____ >> >>> regards,____ >> >>> Ted____ >> >> >>> ____ >> >> Jean-Marc____ >> >> >> On 03/07/2016 03:35 PM, Ted Hardie wrote: >>> We've had about 60 or so messages on this topic, and the rough >>> consensus seems to be align this document with the limits set >>> out in the W3C work here: >> >>> https://www.w3.org/TR/webrtc/#rtcdtmfsender >> >>> However, there was also a proposal to slightly modify those >> limits. >>> They are currently: >> >>> "The duration cannot be more than 6000 ms or less than 40 ms. >>> The default duration is 100 ms for each tone." >> >>> Based on Roman's note, a minimum of 40ms and a maximum 8000 ms >>> to align with the ITU and RFC2833. >> >>> To resolve this, I propose that we ask the WebRTC group to raise >>> their max to 8000 and, on receiving a positive response, publish >>> this document with 40/8000 as the min and max. If they give a >>> negative response, we retain 40/6000. This values alignment >>> between the two documents higher than the reference 2833, but >>> that seems sensible in this context. >> >>> If you have an objection to this way forward, please send your >>> reasoning to the list by March 14th. >> >>> thanks, >> >>> Ted >> From nobody Tue Mar 8 23:26:22 2016 Return-Path: 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 8604812DF26 for ; Tue, 8 Mar 2016 23:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yMHkv5P9RCy for ; Tue, 8 Mar 2016 23:26:15 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0615.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:615]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E949212DF2E for ; Tue, 8 Mar 2016 23:26:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0axlloOuO/TQdWluOJdLGwl5qWX7I9QQiF9i2Oxp6Q4=; b=q5CvOOhTx/FH8SC3P/VxanR+U6YOdTWOKHgPBUE2ORBDbqPKWMj3FSUxJhPtzRKOBmzLgOJdLnEUIuHK6EjAPk1oohrbmUkdkTKPM4Vo1O/j9re2pNAuqk9skw6VBinA/Q5Q833tkRVCZuoY3XvgOkWDiv7Uj/0IjL6z5ZNHURU= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1550.namprd03.prod.outlook.com (10.162.129.156) with Microsoft SMTP Server (TLS) id 15.1.427.16; Wed, 9 Mar 2016 07:25:54 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0427.019; Wed, 9 Mar 2016 07:25:55 +0000 From: "Asveren, Tolga" To: Jean-Marc Valin , Roman Shpount Thread-Topic: [rtcweb] DTMF resolution proposal Thread-Index: AQHReLEGZXQ6ENs53U20okwQmfoJbJ9OfbeAgAAPmQCAAJd7oIABJwEAgAAJAICAAGJv0A== Date: Wed, 9 Mar 2016 07:25:54 +0000 Message-ID: References: <56DDF13F.1050505@mozilla.com> <56DF7C6B.4050400@mozilla.com> In-Reply-To: <56DF7C6B.4050400@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mozilla.com; dkim=none (message not signed) header.d=none;mozilla.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: a2ddbcab-26e5-4b19-978a-08d347ec0d60 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1550; 5:n53n5ONFKfQHCu84Kx+XgZVI5p6HslqCKRW3fMKMT9LKIN8DsabkC5JgJ9ZU99gJlGCC0jlhdeD9QtxF7bIFF6l9NWR9TPKYen2agjeE6rpEwa7HWNiEwyYU9C0GE28JNhIMuyDLkmiHjEhDfCtACA==; 24:dgEYpJCnFtQmqlBvelNZHwsNmQlk8XaqduuInJwCMIquB+Ox60PaKJPbH80cQ5AuclUlZ5lSYpgSE64TSD0NjRcAPsPJtAa1aNILTe7fg6g= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1550; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR0301MB1550; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1550; x-forefront-prvs: 0876988AF0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(479174004)(54524002)(24454002)(164054003)(13464003)(6116002)(3846002)(77096005)(92566002)(102836003)(10400500002)(19580395003)(19580405001)(189998001)(87936001)(2950100001)(81166005)(2900100001)(86362001)(54356999)(1220700001)(15975445007)(586003)(76176999)(106116001)(93886004)(122556002)(5008740100001)(66066001)(3280700002)(76576001)(33656002)(99286002)(561944003)(74316001)(4326007)(2906002)(5004730100002)(1096002)(5002640100001)(575784001)(5001770100001)(50986999)(3660700001)(5003600100002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1550; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2016 07:25:54.8847 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1550 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] DTMF resolution proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 07:26:18 -0000 SSBhZ3JlZSB3aXRoIHRoaXMgSmVhbi1NYXJjJ3MgcG9zaXRpb24uIElmIHRoZSBnb2FsIGlzIHRv IGFpZCBhcHBsaWNhdGlvbnMvbGltaXQgdGhlIHJhbmdlIGluIHRoZSBicm93c2VyICh0aGlzIGhh cyBiZWVuIHByZXNlbnRlZCBhcyB0aGUgcmFpc29uIGQnZXRyZSBzbyBmYXIpLCBpdCBiZXR0ZXIg aXMgZGVmaW5lZCBpbiBXM0Mgc3BlY2lmaWNhdGlvbiByYXRoZXIgdGhhbiBiZWluZyBhIGZhY3Rv ciBmb3IgYWxsIFdlYlJUQyBlbGVtZW50cy4gVGhpcyBib3RoIG1ha2VzIGxvZ2ljYWxseSBtb3Jl IHNlbnNlIGFuZCBhbHNvIHByYWN0aWNhbGx5IGRvZXMgbm90IGludHJvZHVjZSByZXN0cmljdGlv bnMsIHdoaWNoIGFyZSBub3QgbmVlZGVkIHRvIHNhdGlzZnkgdGhlIHJlcXVpcmVtZW50Lg0KDQpU aGFua3MsDQpUb2xnYQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpl YW4tTWFyYyBWYWxpbiBbbWFpbHRvOmptdmFsaW5AbW96aWxsYS5jb21dDQo+IFNlbnQ6IFR1ZXNk YXksIE1hcmNoIDA4LCAyMDE2IDg6MjkgUE0NCj4gVG86IFJvbWFuIFNocG91bnQgPHJvbWFuQHRl bHVyaXguY29tPjsgQXN2ZXJlbiwgVG9sZ2ENCj4gPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4NCj4g Q2M6IFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdtYWlsLmNvbT47IEN1bGxlbiBKZW5uaW5ncyA8Zmx1 ZmZ5QGNpc2NvLmNvbT47DQo+IHJ0Y3dlYkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3J0Y3dl Yl0gRFRNRiByZXNvbHV0aW9uIHByb3Bvc2FsDQo+IA0KPiAtLS0tLUJFR0lOIFBHUCBTSUdORUQg TUVTU0FHRS0tLS0tDQo+IEhhc2g6IFNIQTI1Ng0KPiANCj4gSSdtIG5vdCBnb2luZyB0byBtYWtl IGEgYmlnIGRlYWwgb3V0IG9mIHRoaXMsIGJ1dCBpdCBmZWVscyB0byBtZSBsaWtlIHRoZSBkZWZh dWx0DQo+IGR1cmF0aW9uIHNob3VsZCBiZSBpbiB0aGUgVzNDIGRvYyByYXRoZXIgdGhhbiBpbiB0 aGUgSUVURiBkb2Mgc2luY2UgaXQNCj4gZGVzY3JpYmVzIGJyb3dzZXIgYmVoYXZpb3VyIHJhdGhl ciB0aGFuIHNvbWV0aGluZyBjYW4gY2FuIGJlIG9ic2VydmVkIG9uDQo+IHRoZSB3aXJlLiBPZiBj b3Vyc2UsIGl0IGRvZXNuJ3QgaHVydCBlaXRoZXIsIHNvIEkgd29uJ3Qgb2JqZWN0IGlmIHBlb3Bs ZSBkaXNhZ3JlZQ0KPiB3aXRoIG1lLg0KPiANCj4gQ2hlZXJzLA0KPiANCj4gCUplYW4tTWFyYw0K PiANCj4gT24gMDMvMDgvMjAxNiAwNzo1NyBQTSwgUm9tYW4gU2hwb3VudCB3cm90ZToNCj4gPiBV bmxlc3Mgc29tZW9uZSBvYmplY3RzLCBJIHRoaW5rIHRoZSBsYW5ndWFnZSB3b3VsZCBiZToNCj4g Pg0KPiA+IFdlYlJUQyBlbmRwb2ludHMgZ2VuZXJhdGVkIGV2ZW50cyBNVVNUIGhhdmUgZHVyYXRp b24gb2Ygbm8gbW9yZSB0aGFuDQo+ID4gODAwMCBtcyBhbmQgbm8gbGVzcyB0aGFuIDQwIG1zIHdp dGggdGhlIHJlY29tbWVuZGVkIGRlZmF1bHQgZHVyYXRpb24NCj4gPiBvZiAxMDAgbXMgZm9yIGVh Y2ggdG9uZS4gVGhlIGdhcCBiZXR3ZWVuIGV2ZW50cyBNVVNUIGJlIG5vIGxlc3MgdGhlbg0KPiA+ IDMwIG1zIHdpdGggdGhlIHJlY29tbWVuZGVkIGRlZmF1bHQgZHVyYXRpb24gb2YgNzAgbXMuDQo+ ID4NCj4gPiBXZWJSVEMgZW5kcG9pbnRzIGxpbWl0cyB0aGlzIGxhbmd1YWdlIHRvIGJyb3dzZXJz IGFuZCByZW1vdmVzIHRoaXMNCj4gPiByZXF1aXJlbWVudHMgZnJvbSB0aGUgZ2F0ZXdheXMuDQo+ ID4NCj4gPiBJIGRvIG5vdCB0aGluayB3ZSBzaG91bGQgYWRkIGFueSBsYW5ndWFnZSBhYm91dCBy ZXRyYW5zbWlzc2lvbiBvZiB0aGUNCj4gPiBmaW5hbCBwYWNrZXRzIHNpbmNlIHRoaXMgd2lsbCBj YXVzZSBhbm90aGVyIHVubmVjZXNzYXJ5IGRlYmF0ZSAoZm9yDQo+ID4gaW5zdGFuY2UgSSB0aGlu ayB0aGUgdmFsdWUgb2YgMjAgbXMgaXMgd3JvbmcgYW5kIGl0IHNob3VsZCBiZSBtdWNoDQo+ID4g c2hvcnRlcikuIElmIHlvdSB3YW50IHRvIGNoYW5nZSB0aGlzIHBsZWFzZSB3cml0ZSBhbiB1cGRh dGUgZHJhZnQgZm9yDQo+ID4gUkZDIDQ3MzMgYW5kIHdlIGNhbiBkaXNjdXNzIGl0IHRoZXJlLg0K PiA+DQo+ID4gUmVnYXJkcywgX19fX19fX19fX19fXyBSb21hbiBTaHBvdW50DQo+ID4NCj4gPiBP biBUdWUsIE1hciA4LCAyMDE2IGF0IDI6MjQgQU0sIEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBz b251c25ldC5jb20NCj4gPiA8bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4+IHdyb3RlOg0K PiA+DQo+ID4gV291bGQgdGhlIHRleHQgYmUgY3JhZnRlZCBzbyB0aGF0IGl0IHBlcnRhaW5zICoq b25seSoqIHRvIHRoZQ0KPiA+IFJGQzQ3MzMgZGlnaXQgcGFja2V0cyBlbWl0dGVkIGJ5IGEgYnJv d3Nlcj8gX19fXw0KPiA+DQo+ID4gX18gX18NCj4gPg0KPiA+IEluZm9ybWF0aW9uIGFib3V0IGdh cCBiZXR3ZWVuIHJldHJhbnNtaXNzaW9uIG9mIHRoZSBmaW5hbCBwYWNrZXQgY291bGQNCj4gPiBi ZSB1c2VmdWwgYXMgd2VsbCBhbmQgSSBzdWdnZXN0IDIwbXMgZm9yIHRoYXQgb25lLl9fX18NCj4g Pg0KPiA+IF9fIF9fDQo+ID4NCj4gPiBUaGFua3MsX19fXw0KPiA+DQo+ID4gVG9sZ2FfX19fDQo+ ID4NCj4gPiBfXyBfXw0KPiA+DQo+ID4gKkZyb206KnJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3Vu Y2VzQGlldGYub3JnDQo+ID4gPG1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZz5dICpPbiBC ZWhhbGYgT2YgKlRlZCBIYXJkaWUgKlNlbnQ6Kg0KPiA+IE1vbmRheSwgTWFyY2ggMDcsIDIwMTYg NToxOSBQTSAqVG86KiBKZWFuLU1hcmMgVmFsaW4NCj4gPiA8am12YWxpbkBtb3ppbGxhLmNvbSA8 bWFpbHRvOmptdmFsaW5AbW96aWxsYS5jb20+PiAqQ2M6KiBDdWxsZW4NCj4gPiBKZW5uaW5ncyA8 Zmx1ZmZ5QGNpc2NvLmNvbSA8bWFpbHRvOmZsdWZmeUBjaXNjby5jb20+PjsgcnRjd2ViQGlldGYu b3JnDQo+ID4gPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+ICpTdWJqZWN0OiogUmU6IFtydGN3ZWJd IERUTUYgcmVzb2x1dGlvbg0KPiA+IHByb3Bvc2FsX19fXw0KPiA+DQo+ID4gX18gX18NCj4gPg0K PiA+IE9uIE1vbiwgTWFyIDcsIDIwMTYgYXQgMToyMyBQTSwgSmVhbi1NYXJjIFZhbGluIDxqbXZh bGluQG1vemlsbGEuY29tDQo+ID4gPG1haWx0bzpqbXZhbGluQG1vemlsbGEuY29tPj4gd3JvdGU6 X19fXw0KPiA+DQo+ID4gQXMgcHJvcG9zZWQgYnkgUm9tYW4sIEkgdGhpbmsgd2Ugc2hvdWxkIGFs c28gaW5jbHVkZSB0aGUgIm1pbmltdW0gZ2FwDQo+ID4gb2YgMzAgbXMiLiBPdGhlcndpc2UsIEkg c3VwcG9ydCB0aGUgcHJvcG9zYWwuX19fXw0KPiA+DQo+ID4+IF9fIF9fDQo+ID4NCj4gPj4gVGhh bmsgeW91IEplYW4tTWFyYzsgSSBoYWQgbm90IHRob3VnaHQgdG8gaW5jbHVkZSB0aGF0IGluIG15 IG5vdGUsDQo+ID4+IGJ1dCBJIGFncmVlLl9fX18NCj4gPg0KPiA+PiByZWdhcmRzLF9fX18NCj4g Pg0KPiA+PiBUZWRfX19fDQo+ID4NCj4gPg0KPiA+PiBfX19fDQo+ID4NCj4gPiBKZWFuLU1hcmNf X19fDQo+ID4NCj4gPg0KPiA+IE9uIDAzLzA3LzIwMTYgMDM6MzUgUE0sIFRlZCBIYXJkaWUgd3Jv dGU6DQo+ID4+IFdlJ3ZlIGhhZCBhYm91dCA2MCBvciBzbyBtZXNzYWdlcyBvbiB0aGlzIHRvcGlj LCBhbmQgdGhlIHJvdWdoDQo+ID4+IGNvbnNlbnN1cyBzZWVtcyB0byBiZSBhbGlnbiB0aGlzIGRv Y3VtZW50IHdpdGggdGhlIGxpbWl0cyBzZXQgb3V0IGluDQo+ID4+IHRoZSBXM0Mgd29yayBoZXJl Og0KPiA+DQo+ID4+IGh0dHBzOi8vd3d3LnczLm9yZy9UUi93ZWJydGMvI3J0Y2R0bWZzZW5kZXIN Cj4gPg0KPiA+PiBIb3dldmVyLCB0aGVyZSB3YXMgYWxzbyBhIHByb3Bvc2FsIHRvIHNsaWdodGx5 IG1vZGlmeSB0aG9zZQ0KPiA+IGxpbWl0cy4NCj4gPj4gVGhleSBhcmUgY3VycmVudGx5Og0KPiA+ DQo+ID4+ICJUaGUgZHVyYXRpb24gY2Fubm90IGJlIG1vcmUgdGhhbiA2MDAwIG1zIG9yIGxlc3Mg dGhhbiA0MCBtcy4NCj4gPj4gVGhlIGRlZmF1bHQgZHVyYXRpb24gaXMgMTAwIG1zIGZvciBlYWNo IHRvbmUuIg0KPiA+DQo+ID4+IEJhc2VkIG9uIFJvbWFuJ3Mgbm90ZSwgYSBtaW5pbXVtIG9mIDQw bXMgYW5kIGEgbWF4aW11bSA4MDAwIG1zIHRvDQo+ID4+IGFsaWduIHdpdGggdGhlIElUVSBhbmQg UkZDMjgzMy4NCj4gPg0KPiA+PiBUbyByZXNvbHZlIHRoaXMsIEkgcHJvcG9zZSB0aGF0IHdlIGFz ayB0aGUgV2ViUlRDIGdyb3VwIHRvIHJhaXNlDQo+ID4+IHRoZWlyIG1heCB0byA4MDAwIGFuZCwg b24gcmVjZWl2aW5nIGEgcG9zaXRpdmUgcmVzcG9uc2UsIHB1Ymxpc2ggdGhpcw0KPiA+PiBkb2N1 bWVudCB3aXRoIDQwLzgwMDAgYXMgdGhlIG1pbiBhbmQgbWF4LiAgSWYgdGhleSBnaXZlIGEgbmVn YXRpdmUNCj4gPj4gcmVzcG9uc2UsIHdlIHJldGFpbiA0MC82MDAwLiAgVGhpcyB2YWx1ZXMgYWxp Z25tZW50IGJldHdlZW4gdGhlIHR3bw0KPiA+PiBkb2N1bWVudHMgaGlnaGVyIHRoYW4gdGhlIHJl ZmVyZW5jZSAyODMzLCBidXQgdGhhdCBzZWVtcyBzZW5zaWJsZSBpbg0KPiA+PiB0aGlzIGNvbnRl eHQuDQo+ID4NCj4gPj4gSWYgeW91IGhhdmUgYW4gb2JqZWN0aW9uIHRvIHRoaXMgd2F5IGZvcndh cmQsIHBsZWFzZSBzZW5kIHlvdXINCj4gPj4gcmVhc29uaW5nIHRvIHRoZSBsaXN0IGJ5IE1hcmNo IDE0dGguDQo+ID4NCj4gPj4gdGhhbmtzLA0KPiA+DQo+ID4+IFRlZA0KPiA+DQo+ID4NCj4gPj4g X19fXw0KPiA+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fIHJ0Y3dlYg0KPiBtYWlsaW5nIGxpc3QNCj4gPj4gcnRjd2ViQGlldGYub3JnIDxtYWls dG86cnRjd2ViQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnRjd2ViDQo+ID4NCj4gPg0KPiA+IF9fIF9fDQo+ID4NCj4gPg0KPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIHJ0Y3dlYg0KPiBtYWlsaW5n IGxpc3QNCj4gPiBydGN3ZWJAaWV0Zi5vcmcgPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQo+ID4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWINCj4gPg0KPiA+DQo+ IC0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQo+IFZlcnNpb246IEdudVBHIHYyDQo+IA0K PiBpUUVjQkFFQkNBQUdCUUpXMzN4b0FBb0pFSjYvOHNJdG45cTlhZ0VJQUlEdkRqY3lpV2IxanJE UFJpUG1ZMnowDQo+IHVPdHpmbWRnN0Z1cnZiRU00dUluNVMzMERyYkIxaTVuY2wyeFRtTTI0L2pJ SEtBVnRyL3BYYk10NWpINWEvRjgNCj4gWE1RczV6a2dLN3cxdFAvRXlrSjNmMnRpNXBXYzE4TGlh OHJZTXpLZG0wR0V3Y1VRTWVtVUNaKzdXcnFUDQo+IDBOM3ANCj4gQkhZUFpZOEI0cVIvN1RLK0Fx dXhjV1VVWnNRZFBpM0xhR2NKd0pGOStLd1JLdVhBUWNFcGhVVnMyU25GDQo+IDQ4K0YNCj4gSU1G bGhSeVQwOTdnYXo1bE9GUzM2QWV5UzhTTzFTbzhXMVkyaHdHTUlqbXVISkFNSm00dk40RThKTzRS NA0KPiA5TUYNCj4gZ3N2cWVZaW14OFladHhKd3cwMmFCTi9nYXVVd2RlY29sNU42eFhrM2hhV1Rn ZGd2QkpqZld6UklPc1NsdVZvDQo+ID0NCj4gPVdKMm4NCj4gLS0tLS1FTkQgUEdQIFNJR05BVFVS RS0tLS0tDQo= From nobody Wed Mar 9 01:46:19 2016 Return-Path: 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 A61DA12D56B for ; Wed, 9 Mar 2016 01:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPMh8Qpx_mqb for ; Wed, 9 Mar 2016 01:46:15 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0065.outbound.protection.outlook.com [65.55.169.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3A112D55D for ; Wed, 9 Mar 2016 01:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8TYng6hxMQrpL84TyRw9V/OVS1CVGez3IT5JRykQ/DE=; b=ntN55AGsGIFy4FU9m/WHD2Es71ZN7UQet7qhRYttoe1bHivm0WeDKOWAIUEGEUi1K4hXO4Z9IEvbGgPYFzpTnP5TsfGoAtH07kZTBQXXf1I1SHMcXWicZfD3O4ReAWjRwfDUDzJ2icduCpz5E80j7NNhNHakwITK3WPn2H7nzD8= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1549.namprd03.prod.outlook.com (10.162.129.155) with Microsoft SMTP Server (TLS) id 15.1.427.16; Wed, 9 Mar 2016 09:46:10 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0427.019; Wed, 9 Mar 2016 09:46:10 +0000 From: "Asveren, Tolga" To: Roman Shpount Thread-Topic: [rtcweb] DTMF resolution proposal Thread-Index: AQHReLEGZXQ6ENs53U20okwQmfoJbJ9OfbeAgAAPmQCAAJd7oIABJwEAgACO1FA= Date: Wed, 9 Mar 2016 09:46:10 +0000 Message-ID: References: <56DDF13F.1050505@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: telurix.com; dkim=none (message not signed) header.d=none;telurix.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: e88006d1-16ca-427e-3699-08d347ffa558 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1549; 5:SSeKY94WAAuFxR+GQIQLmUyVHpJ9DYlFrDG18Vqc2gO9UYrtxp5ABTwHVSIWH7sMXGA73/H+0AYARRBjep3ZvfWVY1ihEOOK0T6PDcahH3xb3ZLxGJvvJ2y1Iyi6eAwvepuDjDZfImZWaK27RH9xKA==; 24:J0+u16OoJZlxQqjOm3Hpd8cXtAe1ZZN4V0tEHU9uDk9g8wkpAsHjIEnCV4QdvP4BiBlt9pbpN1gIKaXLU+vW6nWEYjxdbKZFfc256Jekq8k= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1549; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:SN1PR0301MB1549; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1549; x-forefront-prvs: 0876988AF0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(54524002)(479174004)(377454003)(164054003)(24454002)(99286002)(33656002)(122556002)(19625215002)(66066001)(74316001)(77096005)(15975445007)(16236675004)(561944003)(19300405004)(2906002)(86362001)(11100500001)(3280700002)(106116001)(575784001)(54356999)(93886004)(790700001)(6116002)(50986999)(1096002)(3846002)(1220700001)(102836003)(76176999)(10400500002)(5008740100001)(5003600100002)(19609705001)(110136002)(4326007)(3660700001)(189998001)(92566002)(2950100001)(5004730100002)(2900100001)(5002640100001)(19580405001)(87936001)(19580395003)(19617315012)(76576001)(586003)(81166005); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1549; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551CBE7CF5BD02F5A957B64B2B30SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2016 09:46:10.2657 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1549 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] DTMF resolution proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 09:46:17 -0000 --_000_SN1PR0301MB1551CBE7CF5BD02F5A957B64B2B30SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 aS0gSSBwZXJzb25hbGx5IHdvdWxkIHByZWZlciBub3QgdG8gbGVhdmUgYSBncmV5IGFyZWEgKGFm dGVyIGFsbCwgdGhlIGdhcCBiZXR3ZWVuIHJldHJhbnNtaXR0ZWQgZW5kLXBhY2tldHMgaXMgYW5v dGhlciB2YWx1ZSwgd2hpY2ggbmVlZHMgdG8gYmUga25vd24vZGV0ZXJtaW5lZC9wcm92aWRlZCku DQoNCmlpLSBJIHdvdWxkbuKAmXQgbWluZCBpZiB0aGUgbWluLXZhbHVlIGZvciByZXRyYW5zbWlz c2lvbiBnYXAgaXMgMTBtcywgb3IgZXZlbiAwbXMsIGFuZCBhY3R1YWxseSB3b3VsZCBwcmVmZXIg MG1zIGFzIGl0IGRvZXMgbm90IGltcG9zZSBhbnkgcmVzdHJpY3Rpb25zICh0aGlzIGFsbCBhc3N1 bWluZyDigJN3aGljaCBJTUhPIGlzIG5vdCB0aGUgcmlnaHQgY2hvaWNlLSB0aGF0IHRoZSBsaW1p dHMgd2lsbCBiZSBzcGVjaWZpZWQgaW4gcnRjd2ViLWF1ZGlvIGRyYWZ0IHJhdGhlciB0aGFuIGlu IFczQyBzcGVjaWZpY2F0aW9uKQ0KDQppaWktIEl0IGlzIG5vdCBjbGVhciB0byBtZSB3aGV0aGVy IHRoZSB1c2Ugb2YgdGhlIHdvcmQg4oCcV2ViUlRDIGVuZHBvaW504oCdIGJ5IGRlZmF1bHQgY292 ZXJzIGdhdGV3YXlzIGFzIHdlbGwuIGRyYWZ0LWlldGYtcnRjd2ViLWdhdGV3YXlzLTAyIGhhcyB0 aGUgZm9sbG93aW5nOg0KICAgQSBXZWJSVEMgZ2F0ZXdheSBhcHBlYXJzIGFzIGEgV2ViUlRDLWNv bXBhdGlibGUgZW5kcG9pbnQsIGFuZCB3aWxsDQogICB0aHVzIG5vdCBiZSBjb25mb3JtYW50IHdp dGggYWxsIHJlcXVpcmVtZW50cyBmb3IgYSBXZWJSVEMgZW5kcG9pbnQNCiAgIChpdCBkb2VzIG5v dCBkbyBldmVyeXRoaW5nIGEgV2ViUlRDIGVuZHBvaW50IGRvZXMpLCBidXQgaXMgYWJsZSB0bw0K ICAgaW50ZXJvcGVyYXRlIHdpdGggV2ViUlRDIGVuZHBvaW50cy4NCkkgaW50ZXJwcmV0IHRoaXMg YXMg4oCcQW55dGhpbmcsIHdoaWNoIGlzIG1hbmRhdGVkIGZvciB3ZWJydGMtZW5kcG9pbnRzIGFu ZCBub3QgZXhwbGljaXRseSBzcGVjaWZpZWQgYXMgbm90IGFwcGxpY2FibGUgZm9yIGdhdGV3YXlz IGluICBydGN3ZWItZ2F0ZXdheSBkb2N1bWVudCBpcyBhcHBsaWNhYmxlIGZvciBnYXRld2F5cyB0 b2/igJ0sIGluIHdoaWNoIGNhc2UgSSB3b3VsZCBzdWdnZXN0IGFkZGluZyBhIHN0YXRlbWVudCB0 byBydGN3ZWItZ2F0ZXdheSBkb2N1bWVudCB0aGF0IFJGQzQ3MzMgbGltaXRzIGRvIG5vdCBhcHBs eSB0byBpdCAoanVzdCB0cnlpbmcgdG8gcHJldmVudCB0aGUgcG9zc2liaWxpdHkgb2YgaW50ZXJ3 b3JraW5nKS4NCg0KaXYtIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSByZXRyYW5zbWlzc2lvbiBn YXAgbGltaXQgd291bGQgcmVxdWlyZSBSRkM0NzMzIHVwZGF0ZSB3aGVyZWFzIHRoZSBvdGhlciBs aW1pdHMgdW5kZXIgY29uc2lkZXJhdGlvbiBkb27igJl0Lg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpG cm9tOiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5jb21dDQpTZW50OiBUdWVz ZGF5LCBNYXJjaCAwOCwgMjAxNiA3OjU3IFBNDQpUbzogQXN2ZXJlbiwgVG9sZ2EgPHRhc3ZlcmVu QHNvbnVzbmV0LmNvbT4NCkNjOiBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb20+OyBKZWFu LU1hcmMgVmFsaW4gPGptdmFsaW5AbW96aWxsYS5jb20+OyBDdWxsZW4gSmVubmluZ3MgPGZsdWZm eUBjaXNjby5jb20+OyBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBEVE1G IHJlc29sdXRpb24gcHJvcG9zYWwNCg0KVW5sZXNzIHNvbWVvbmUgb2JqZWN0cywgSSB0aGluayB0 aGUgbGFuZ3VhZ2Ugd291bGQgYmU6DQoNCldlYlJUQyBlbmRwb2ludHMgZ2VuZXJhdGVkIGV2ZW50 cyBNVVNUIGhhdmUgZHVyYXRpb24gb2Ygbm8gbW9yZSB0aGFuIDgwMDAgbXMgYW5kIG5vIGxlc3Mg dGhhbiA0MCBtcyB3aXRoIHRoZSByZWNvbW1lbmRlZCBkZWZhdWx0IGR1cmF0aW9uIG9mIDEwMCBt cyBmb3IgZWFjaCB0b25lLiBUaGUgZ2FwIGJldHdlZW4gZXZlbnRzIE1VU1QgYmUgbm8gbGVzcyB0 aGVuIDMwIG1zIHdpdGggdGhlIHJlY29tbWVuZGVkIGRlZmF1bHQgZHVyYXRpb24gb2YgNzAgbXMu DQoNCldlYlJUQyBlbmRwb2ludHMgbGltaXRzIHRoaXMgbGFuZ3VhZ2UgdG8gYnJvd3NlcnMgYW5k IHJlbW92ZXMgdGhpcyByZXF1aXJlbWVudHMgZnJvbSB0aGUgZ2F0ZXdheXMuDQoNCkkgZG8gbm90 IHRoaW5rIHdlIHNob3VsZCBhZGQgYW55IGxhbmd1YWdlIGFib3V0IHJldHJhbnNtaXNzaW9uIG9m IHRoZSBmaW5hbCBwYWNrZXRzIHNpbmNlIHRoaXMgd2lsbCBjYXVzZSBhbm90aGVyIHVubmVjZXNz YXJ5IGRlYmF0ZSAoZm9yIGluc3RhbmNlIEkgdGhpbmsgdGhlIHZhbHVlIG9mIDIwIG1zIGlzIHdy b25nIGFuZCBpdCBzaG91bGQgYmUgbXVjaCBzaG9ydGVyKS4gSWYgeW91IHdhbnQgdG8gY2hhbmdl IHRoaXMgcGxlYXNlIHdyaXRlIGFuIHVwZGF0ZSBkcmFmdCBmb3IgUkZDIDQ3MzMgYW5kIHdlIGNh biBkaXNjdXNzIGl0IHRoZXJlLg0KDQpSZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hw b3VudA0KDQpPbiBUdWUsIE1hciA4LCAyMDE2IGF0IDI6MjQgQU0sIEFzdmVyZW4sIFRvbGdhIDx0 YXN2ZXJlbkBzb251c25ldC5jb208bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4+IHdyb3Rl Og0KV291bGQgdGhlIHRleHQgYmUgY3JhZnRlZCBzbyB0aGF0IGl0IHBlcnRhaW5zICpvbmx5KiB0 byB0aGUgUkZDNDczMyBkaWdpdCBwYWNrZXRzIGVtaXR0ZWQgYnkgYSBicm93c2VyPw0KDQpJbmZv cm1hdGlvbiBhYm91dCBnYXAgYmV0d2VlbiByZXRyYW5zbWlzc2lvbiBvZiB0aGUgZmluYWwgcGFj a2V0IGNvdWxkIGJlIHVzZWZ1bCBhcyB3ZWxsIGFuZCBJIHN1Z2dlc3QgMjBtcyBmb3IgdGhhdCBv bmUuDQoNClRoYW5rcywNClRvbGdhDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBP ZiBUZWQgSGFyZGllDQpTZW50OiBNb25kYXksIE1hcmNoIDA3LCAyMDE2IDU6MTkgUE0NClRvOiBK ZWFuLU1hcmMgVmFsaW4gPGptdmFsaW5AbW96aWxsYS5jb208bWFpbHRvOmptdmFsaW5AbW96aWxs YS5jb20+Pg0KQ2M6IEN1bGxlbiBKZW5uaW5ncyA8Zmx1ZmZ5QGNpc2NvLmNvbTxtYWlsdG86Zmx1 ZmZ5QGNpc2NvLmNvbT4+OyBydGN3ZWJAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBEVE1GIHJlc29sdXRpb24gcHJvcG9zYWwNCg0KT24gTW9u LCBNYXIgNywgMjAxNiBhdCAxOjIzIFBNLCBKZWFuLU1hcmMgVmFsaW4gPGptdmFsaW5AbW96aWxs YS5jb208bWFpbHRvOmptdmFsaW5AbW96aWxsYS5jb20+PiB3cm90ZToNCi0tLS0tQkVHSU4gUEdQ IFNJR05FRCBNRVNTQUdFLS0tLS0NCkhhc2g6IFNIQTI1Ng0KDQpBcyBwcm9wb3NlZCBieSBSb21h biwgSSB0aGluayB3ZSBzaG91bGQgYWxzbyBpbmNsdWRlIHRoZSAibWluaW11bSBnYXANCm9mIDMw IG1zIi4gT3RoZXJ3aXNlLCBJIHN1cHBvcnQgdGhlIHByb3Bvc2FsLg0KDQpUaGFuayB5b3UgSmVh bi1NYXJjOyBJIGhhZCBub3QgdGhvdWdodCB0byBpbmNsdWRlIHRoYXQgaW4gbXkgbm90ZSwgYnV0 IEkgYWdyZWUuDQpyZWdhcmRzLA0KVGVkDQoNCg0KICAgICAgICBKZWFuLU1hcmMNCg0KT24gMDMv MDcvMjAxNiAwMzozNSBQTSwgVGVkIEhhcmRpZSB3cm90ZToNCj4gV2UndmUgaGFkIGFib3V0IDYw IG9yIHNvIG1lc3NhZ2VzIG9uIHRoaXMgdG9waWMsIGFuZCB0aGUgcm91Z2gNCj4gY29uc2Vuc3Vz IHNlZW1zIHRvIGJlIGFsaWduIHRoaXMgZG9jdW1lbnQgd2l0aCB0aGUgbGltaXRzIHNldCBvdXQN Cj4gaW4gdGhlIFczQyB3b3JrIGhlcmU6DQo+DQo+IGh0dHBzOi8vd3d3LnczLm9yZy9UUi93ZWJy dGMvI3J0Y2R0bWZzZW5kZXINCj4NCj4gSG93ZXZlciwgdGhlcmUgd2FzIGFsc28gYSBwcm9wb3Nh bCB0byBzbGlnaHRseSBtb2RpZnkgdGhvc2UgbGltaXRzLg0KPiAgVGhleSBhcmUgY3VycmVudGx5 Og0KPg0KPiAiVGhlIGR1cmF0aW9uIGNhbm5vdCBiZSBtb3JlIHRoYW4gNjAwMCBtcyBvciBsZXNz IHRoYW4gNDAgbXMuIFRoZQ0KPiBkZWZhdWx0IGR1cmF0aW9uIGlzIDEwMCBtcyBmb3IgZWFjaCB0 b25lLiINCj4NCj4gQmFzZWQgb24gUm9tYW4ncyBub3RlLCBhIG1pbmltdW0gb2YgNDBtcyBhbmQg YSBtYXhpbXVtIDgwMDAgbXMgdG8NCj4gYWxpZ24gd2l0aCB0aGUgSVRVIGFuZCBSRkMyODMzLg0K Pg0KPiBUbyByZXNvbHZlIHRoaXMsIEkgcHJvcG9zZSB0aGF0IHdlIGFzayB0aGUgV2ViUlRDIGdy b3VwIHRvIHJhaXNlDQo+IHRoZWlyIG1heCB0byA4MDAwIGFuZCwgb24gcmVjZWl2aW5nIGEgcG9z aXRpdmUgcmVzcG9uc2UsIHB1Ymxpc2gNCj4gdGhpcyBkb2N1bWVudCB3aXRoIDQwLzgwMDAgYXMg dGhlIG1pbiBhbmQgbWF4LiAgSWYgdGhleSBnaXZlIGENCj4gbmVnYXRpdmUgcmVzcG9uc2UsIHdl IHJldGFpbiA0MC82MDAwLiAgVGhpcyB2YWx1ZXMgYWxpZ25tZW50DQo+IGJldHdlZW4gdGhlIHR3 byBkb2N1bWVudHMgaGlnaGVyIHRoYW4gdGhlIHJlZmVyZW5jZSAyODMzLCBidXQgdGhhdA0KPiBz ZWVtcyBzZW5zaWJsZSBpbiB0aGlzIGNvbnRleHQuDQo+DQo+IElmIHlvdSBoYXZlIGFuIG9iamVj dGlvbiB0byB0aGlzIHdheSBmb3J3YXJkLCBwbGVhc2Ugc2VuZCB5b3VyDQo+IHJlYXNvbmluZyB0 byB0aGUgbGlzdCBieSBNYXJjaCAxNHRoLg0KPg0KPiB0aGFua3MsDQo+DQo+IFRlZA0KPg0KPg0K Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBydGN3 ZWIgbWFpbGluZw0KPiBsaXN0IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3Jn PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KPg0KLS0tLS1C RUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYyDQoNCmlRRWNCQUVCQ0FB R0JRSlczZkU1QUFvSkVKNi84c0l0bjlxOUtEZ0gvajRiU3V0a1NqVW12dDZhVHR0MjZxRjYNCkZL RjJKTWtyWmM4cGpTZzZJRFRxOU1KcmFkSnI4V1N6cjI3VlNwZWRXT0hIUEZmNXo0akRuNklwVlZN eVRVdFANCkpqNk12QVBUeWY5dUI3VUdxOHJmQTl5NmF6OU9qQ2hzSlozajIveVBrN2kvYm5WWU9i ZzBPWE9JdHlQQTIra0ENCjdLQ0pBSVdVaUlCZGZpZktWOFcxcXJlNURiVVZpNGlYbkdJemJRNUtK SXB4ck8zQ3hycSt2bFB5N0d6bmMxYTENCm80QjUwRFU2cDNuQklMR2dDWHBGd0FNVzVQQmZjby9v QU96Q0g5MGdxY004aHpFUk9XNTBMVEpFRC9PUDBLL2INClMzTE1HM00rQnJpdUFhc2x3Vy9UajBx bTNWVXF0RnBLYUUzSTB6amx4VWJ2ZnN4Zy9KWWp1MmViR1NzbFo3ST0NCj1kcEpBDQotLS0tLUVO RCBQR1AgU0lHTkFUVVJFLS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KcnRjd2ViIG1haWxpbmcgbGlzdA0KcnRjd2ViQGlldGYub3JnPG1h aWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3J0Y3dlYg0KDQo= --_000_SN1PR0301MB1551CBE7CF5BD02F5A957B64B2B30SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPmktIEkgcGVyc29uYWxseSB3b3VsZCBwcmVmZXIgbm90IHRvIGxlYXZl IGEgZ3JleSBhcmVhIChhZnRlciBhbGwsIHRoZSBnYXAgYmV0d2VlbiByZXRyYW5zbWl0dGVkIGVu ZC1wYWNrZXRzIGlzIGFub3RoZXIgdmFsdWUsIHdoaWNoIG5lZWRzIHRvIGJlIGtub3duL2RldGVy bWluZWQvcHJvdmlkZWQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+aWktIEkgd291bGRu4oCZdCBtaW5kIGlmIHRoZSBtaW4tdmFsdWUgZm9yIHJldHJhbnNtaXNz aW9uIGdhcCBpcyAxMG1zLCBvciBldmVuIDBtcywgYW5kIGFjdHVhbGx5IHdvdWxkIHByZWZlciAw bXMgYXMgaXQgZG9lcyBub3QgaW1wb3NlIGFueSByZXN0cmljdGlvbnMgKHRoaXMgYWxsDQogYXNz dW1pbmcg4oCTd2hpY2ggSU1ITyBpcyBub3QgdGhlIHJpZ2h0IGNob2ljZS0gdGhhdCB0aGUgbGlt aXRzIHdpbGwgYmUgc3BlY2lmaWVkIGluIHJ0Y3dlYi1hdWRpbyBkcmFmdCByYXRoZXIgdGhhbiBp biBXM0Mgc3BlY2lmaWNhdGlvbik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPmlpaS0gSXQgaXMgbm90IGNsZWFyIHRvIG1lIHdoZXRoZXIgdGhlIHVzZSBvZiB0aGUg d29yZCDigJxXZWJSVEMgZW5kcG9pbnTigJ0gYnkgZGVmYXVsdCBjb3ZlcnMgZ2F0ZXdheXMgYXMg d2VsbC4gZHJhZnQtaWV0Zi1ydGN3ZWItZ2F0ZXdheXMtMDIgaGFzIHRoZSBmb2xsb3dpbmc6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyBBIFdlYlJUQyBnYXRld2F5IGFwcGVhcnMgYXMgYSBXZWJSVEMtY29tcGF0aWJsZSBl bmRwb2ludCwgYW5kIHdpbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRodXMgbm90IGJlIGNvbmZvcm1hbnQgd2l0aCBh bGwgcmVxdWlyZW1lbnRzIGZvciBhIFdlYlJUQyBlbmRwb2ludDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgKGl0IGRvZXMg bm90IGRvIGV2ZXJ5dGhpbmcgYSBXZWJSVEMgZW5kcG9pbnQgZG9lcyksIGJ1dCBpcyBhYmxlIHRv PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOyZuYnNwOyBpbnRlcm9wZXJhdGUgd2l0aCBXZWJSVEMgZW5kcG9pbnRzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JIGludGVycHJldCB0aGlzIGFzIOKAnEFueXRoaW5nLCB3aGljaCBpcyBtYW5kYXRl ZCBmb3Igd2VicnRjLWVuZHBvaW50cyBhbmQgbm90IGV4cGxpY2l0bHkgc3BlY2lmaWVkIGFzIG5v dCBhcHBsaWNhYmxlIGZvciBnYXRld2F5cyBpbiAmbmJzcDtydGN3ZWItZ2F0ZXdheSBkb2N1bWVu dA0KIGlzIGFwcGxpY2FibGUgZm9yIGdhdGV3YXlzIHRvb+KAnSwgaW4gd2hpY2ggY2FzZSBJIHdv dWxkIHN1Z2dlc3QgYWRkaW5nIGEgc3RhdGVtZW50IHRvIHJ0Y3dlYi1nYXRld2F5IGRvY3VtZW50 IHRoYXQgUkZDNDczMyBsaW1pdHMgZG8gbm90IGFwcGx5IHRvIGl0IChqdXN0IHRyeWluZyB0byBw cmV2ZW50IHRoZSBwb3NzaWJpbGl0eSBvZiBpbnRlcndvcmtpbmcpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aXYtIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSBy ZXRyYW5zbWlzc2lvbiBnYXAgbGltaXQgd291bGQgcmVxdWlyZSBSRkM0NzMzIHVwZGF0ZSB3aGVy ZWFzIHRoZSBvdGhlciBsaW1pdHMgdW5kZXIgY29uc2lkZXJhdGlvbiBkb27igJl0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5Ub2xnYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21hbkB0ZWx1cml4 LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXJjaCAwOCwgMjAxNiA3OjU3IFBN PGJyPg0KPGI+VG86PC9iPiBBc3ZlcmVuLCBUb2xnYSAmbHQ7dGFzdmVyZW5Ac29udXNuZXQuY29t Jmd0Ozxicj4NCjxiPkNjOjwvYj4gVGVkIEhhcmRpZSAmbHQ7dGVkLmlldGZAZ21haWwuY29tJmd0 OzsgSmVhbi1NYXJjIFZhbGluICZsdDtqbXZhbGluQG1vemlsbGEuY29tJmd0OzsgQ3VsbGVuIEpl bm5pbmdzICZsdDtmbHVmZnlAY2lzY28uY29tJmd0OzsgcnRjd2ViQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBEVE1GIHJlc29sdXRpb24gcHJvcG9zYWw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VW5sZXNzIHNv bWVvbmUgb2JqZWN0cywgSSB0aGluayB0aGUgbGFuZ3VhZ2Ugd291bGQgYmU6PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2ViUlRDIGVuZHBvaW50 cyBnZW5lcmF0ZWQgZXZlbnRzPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtjb2xvcjpibGFj ayI+Jm5ic3A7TVVTVCBoYXZlIGR1cmF0aW9uIG9mIG5vIG1vcmUgdGhhbiA4MDAwIG1zIGFuZCBu byBsZXNzJm5ic3A7dGhhbiA0MCBtcyB3aXRoIHRoZSByZWNvbW1lbmRlZCBkZWZhdWx0IGR1cmF0 aW9uIG9mIDEwMCBtcyBmb3IgZWFjaCB0b25lLiBUaGUgZ2FwIGJldHdlZW4gZXZlbnRzIE1VU1Qg YmUNCiBubyBsZXNzIHRoZW4gMzAgbXMgd2l0aCB0aGUgcmVjb21tZW5kZWQmbmJzcDtkZWZhdWx0 IGR1cmF0aW9uIG9mIDcwIG1zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2ViUlRDIGVuZHBvaW50cyBsaW1pdHMgdGhpcyBsYW5n dWFnZSB0byBicm93c2VycyBhbmQgcmVtb3ZlcyB0aGlzIHJlcXVpcmVtZW50cyBmcm9tIHRoZSBn YXRld2F5cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSBkbyBub3QgdGhpbmsgd2Ugc2hvdWxkIGFkZCBhbnkgbGFuZ3VhZ2UgYWJvdXQgcmV0 cmFuc21pc3Npb24gb2YgdGhlIGZpbmFsIHBhY2tldHMgc2luY2UgdGhpcyB3aWxsIGNhdXNlIGFu b3RoZXIgdW5uZWNlc3NhcnkgZGViYXRlIChmb3IgaW5zdGFuY2UgSSB0aGluayB0aGUgdmFsdWUg b2YgMjAgbXMgaXMgd3JvbmcgYW5kIGl0IHNob3VsZCBiZSBtdWNoIHNob3J0ZXIpLiBJZiB5b3Ug d2FudCB0byBjaGFuZ2UNCiB0aGlzIHBsZWFzZSB3cml0ZSBhbiB1cGRhdGUgZHJhZnQgZm9yIFJG QyA0NzMzIGFuZCB3ZSBjYW4gZGlzY3VzcyBpdCB0aGVyZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8YnIgY2xlYXI9 ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+X19fX19fX19fX19fXzxicj4NClJvbWFuIFNocG91bnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE1hciA4LCAyMDE2IGF0IDI6MjQgQU0s IEFzdmVyZW4sIFRvbGdhICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29t IiB0YXJnZXQ9Il9ibGFuayI+dGFzdmVyZW5Ac29udXNuZXQuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Xb3VsZCB0aGUgdGV4dCBiZSBj cmFmdGVkIHNvIHRoYXQgaXQgcGVydGFpbnMgKjxiPm9ubHk8L2I+KiB0byB0aGUgUkZDNDczMyBk aWdpdCBwYWNrZXRzIGVtaXR0ZWQgYnkNCiBhIGJyb3dzZXI/IDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkluZm9ybWF0aW9uIGFib3V0IGdhcCBiZXR3ZWVu IHJldHJhbnNtaXNzaW9uIG9mIHRoZSBmaW5hbCBwYWNrZXQgY291bGQgYmUgdXNlZnVsIGFzIHdl bGwgYW5kIEkgc3VnZ2VzdA0KIDIwbXMgZm9yIHRoYXQgb25lLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5U b2xnYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBydGN3ZWIgW21haWx0bzo8YSBocmVmPSJtYWlsdG86cnRjd2Vi LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWItYm91bmNlc0BpZXRmLm9y ZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRlZCBIYXJkaWU8YnI+DQo8Yj5TZW50OjwvYj4g TW9uZGF5LCBNYXJjaCAwNywgMjAxNiA1OjE5IFBNPGJyPg0KPGI+VG86PC9iPiBKZWFuLU1hcmMg VmFsaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbXZhbGluQG1vemlsbGEuY29tIiB0YXJnZXQ9Il9i bGFuayI+am12YWxpbkBtb3ppbGxhLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBDdWxsZW4g SmVubmluZ3MgJmx0OzxhIGhyZWY9Im1haWx0bzpmbHVmZnlAY2lzY28uY29tIiB0YXJnZXQ9Il9i bGFuayI+Zmx1ZmZ5QGNpc2NvLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtydGN3ZWJdIERUTUYgcmVzb2x1dGlvbiBwcm9wb3NhbDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+T24gTW9uLCBNYXIgNywgMjAxNiBhdCAxOjIzIFBNLCBKZWFuLU1hcmMgVmFs aW4gJmx0OzxhIGhyZWY9Im1haWx0bzpqbXZhbGluQG1vemlsbGEuY29tIiB0YXJnZXQ9Il9ibGFu ayI+am12YWxpbkBtb3ppbGxhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij4tLS0tLUJFR0lOIFBHUCBTSUdORUQgTUVTU0FHRS0tLS0tPGJyPg0KSGFz aDogU0hBMjU2PGJyPg0KPGJyPg0KQXMgcHJvcG9zZWQgYnkgUm9tYW4sIEkgdGhpbmsgd2Ugc2hv dWxkIGFsc28gaW5jbHVkZSB0aGUgJnF1b3Q7bWluaW11bSBnYXA8YnI+DQpvZiAzMCBtcyZxdW90 Oy4gT3RoZXJ3aXNlLCBJIHN1cHBvcnQgdGhlIHByb3Bvc2FsLjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoYW5rIHlvdSBKZWFuLU1h cmM7IEkgaGFkIG5vdCB0aG91Z2h0IHRvIGluY2x1ZGUgdGhhdCBpbiBteSBub3RlLCBidXQgSSBh Z3JlZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+cmVn YXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+VGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEplYW4tTWFyYzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCk9uIDAzLzA3LzIwMTYgMDM6 MzUgUE0sIFRlZCBIYXJkaWUgd3JvdGU6PGJyPg0KJmd0OyBXZSd2ZSBoYWQgYWJvdXQgNjAgb3Ig c28gbWVzc2FnZXMgb24gdGhpcyB0b3BpYywgYW5kIHRoZSByb3VnaDxicj4NCiZndDsgY29uc2Vu c3VzIHNlZW1zIHRvIGJlIGFsaWduIHRoaXMgZG9jdW1lbnQgd2l0aCB0aGUgbGltaXRzIHNldCBv dXQ8YnI+DQomZ3Q7IGluIHRoZSBXM0Mgd29yayBoZXJlOjxicj4NCiZndDs8YnI+DQomZ3Q7IDxh IGhyZWY9Imh0dHBzOi8vd3d3LnczLm9yZy9UUi93ZWJydGMvI3J0Y2R0bWZzZW5kZXIiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy53My5vcmcvVFIvd2VicnRjLyNydGNkdG1mc2VuZGVyPC9h Pjxicj4NCiZndDs8YnI+DQomZ3Q7IEhvd2V2ZXIsIHRoZXJlIHdhcyBhbHNvIGEgcHJvcG9zYWwg dG8gc2xpZ2h0bHkgbW9kaWZ5IHRob3NlIGxpbWl0cy48YnI+DQomZ3Q7Jm5ic3A7IFRoZXkgYXJl IGN1cnJlbnRseTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmcXVvdDtUaGUgZHVyYXRpb24gY2Fubm90 IGJlIG1vcmUgdGhhbiA2MDAwIG1zIG9yIGxlc3MgdGhhbiA0MCBtcy4gVGhlPGJyPg0KJmd0OyBk ZWZhdWx0IGR1cmF0aW9uIGlzIDEwMCBtcyBmb3IgZWFjaCB0b25lLiZxdW90Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IEJhc2VkIG9uIFJvbWFuJ3Mgbm90ZSwgYSBtaW5pbXVtIG9mIDQwbXMgYW5kIGEg bWF4aW11bSA4MDAwIG1zIHRvPGJyPg0KJmd0OyBhbGlnbiB3aXRoIHRoZSBJVFUgYW5kIFJGQzI4 MzMuPGJyPg0KJmd0Ozxicj4NCiZndDsgVG8gcmVzb2x2ZSB0aGlzLCBJIHByb3Bvc2UgdGhhdCB3 ZSBhc2sgdGhlIFdlYlJUQyBncm91cCB0byByYWlzZTxicj4NCiZndDsgdGhlaXIgbWF4IHRvIDgw MDAgYW5kLCBvbiByZWNlaXZpbmcgYSBwb3NpdGl2ZSByZXNwb25zZSwgcHVibGlzaDxicj4NCiZn dDsgdGhpcyBkb2N1bWVudCB3aXRoIDQwLzgwMDAgYXMgdGhlIG1pbiBhbmQgbWF4LiZuYnNwOyBJ ZiB0aGV5IGdpdmUgYTxicj4NCiZndDsgbmVnYXRpdmUgcmVzcG9uc2UsIHdlIHJldGFpbiA0MC82 MDAwLiZuYnNwOyBUaGlzIHZhbHVlcyBhbGlnbm1lbnQ8YnI+DQomZ3Q7IGJldHdlZW4gdGhlIHR3 byBkb2N1bWVudHMgaGlnaGVyIHRoYW4gdGhlIHJlZmVyZW5jZSAyODMzLCBidXQgdGhhdDxicj4N CiZndDsgc2VlbXMgc2Vuc2libGUgaW4gdGhpcyBjb250ZXh0Ljxicj4NCiZndDs8YnI+DQomZ3Q7 IElmIHlvdSBoYXZlIGFuIG9iamVjdGlvbiB0byB0aGlzIHdheSBmb3J3YXJkLCBwbGVhc2Ugc2Vu ZCB5b3VyPGJyPg0KJmd0OyByZWFzb25pbmcgdG8gdGhlIGxpc3QgYnkgTWFyY2ggMTR0aC48YnI+ DQomZ3Q7PGJyPg0KJmd0OyB0aGFua3MsPGJyPg0KJmd0Ozxicj4NCiZndDsgVGVkPGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fIHJ0Y3dlYiBtYWlsaW5nPGJyPg0KJmd0OyBsaXN0IDxhIGhyZWY9Im1h aWx0bzpydGN3ZWJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+ IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0 YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0 Y3dlYjwvYT48YnI+DQomZ3Q7PGJyPg0KLS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS08YnI+ DQpWZXJzaW9uOiBHbnVQRyB2Mjxicj4NCjxicj4NCmlRRWNCQUVCQ0FBR0JRSlczZkU1QUFvSkVK Ni84c0l0bjlxOUtEZ0gvajRiU3V0a1NqVW12dDZhVHR0MjZxRjY8YnI+DQpGS0YySk1rclpjOHBq U2c2SURUcTlNSnJhZEpyOFdTenIyN1ZTcGVkV09ISFBGZjV6NGpEbjZJcFZWTXlUVXRQPGJyPg0K Smo2TXZBUFR5Zjl1QjdVR3E4cmZBOXk2YXo5T2pDaHNKWjNqMi95UGs3aS9iblZZT2JnME9YT0l0 eVBBMiYjNDM7a0E8YnI+DQo3S0NKQUlXVWlJQmRmaWZLVjhXMXFyZTVEYlVWaTRpWG5HSXpiUTVL SklweHJPM0N4cnEmIzQzO3ZsUHk3R3puYzFhMTxicj4NCm80QjUwRFU2cDNuQklMR2dDWHBGd0FN VzVQQmZjby9vQU96Q0g5MGdxY004aHpFUk9XNTBMVEpFRC9PUDBLL2I8YnI+DQpTM0xNRzNNJiM0 MztCcml1QWFzbHdXL1RqMHFtM1ZVcXRGcEthRTNJMHpqbHhVYnZmc3hnL0pZanUyZWJHU3NsWjdJ PTxicj4NCj1kcEpBPGJyPg0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tPG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpydGN3ZWIgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnJ0Y3dl YkBpZXRmLm9yZyI+cnRjd2ViQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGN3ZWI8L2E+PG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_SN1PR0301MB1551CBE7CF5BD02F5A957B64B2B30SN1PR0301MB1551_-- From nobody Wed Mar 9 04:12:24 2016 Return-Path: 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 35FE812D5E3 for ; Wed, 9 Mar 2016 04:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prQXNQcd2_K4 for ; Wed, 9 Mar 2016 04:12:20 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D871212D5D9 for ; Wed, 9 Mar 2016 04:12:13 -0800 (PST) Received: (qmail 48304 invoked from network); 9 Mar 2016 12:12:11 -0000 X-AV-Scan: clean X-APM-Authkey: 83769/0 4948 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 9 Mar 2016 12:12:11 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id 0949718A0BAD; Wed, 9 Mar 2016 12:12:11 +0000 (GMT) Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTPS id EEEFA18A0BAF; Wed, 9 Mar 2016 12:12:10 +0000 (GMT) Received: from limit.westhawk.co.uk (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id CB7C918A0BAD; Wed, 9 Mar 2016 12:12:10 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6CABFCF2-37EB-4817-BD03-EA1F4D4F29B2" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Tim Panton In-Reply-To: <56DEC8F5.4070101@alcatel-lucent.com> Date: Wed, 9 Mar 2016 12:12:10 +0000 Message-Id: References: <56DEC8F5.4070101@alcatel-lucent.com> To: Juergen Stoetzer-Bradler X-Mailer: Apple Mail (2.2104) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 12:12:23 -0000 --Apple-Mail=_6CABFCF2-37EB-4817-BD03-EA1F4D4F29B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 8 Mar 2016, at 12:43, Juergen Stoetzer-Bradler = > wrote: >=20 > Hello, >=20 > If a WebRTC endpoint uses the data channel establishment protocol in = order to open a data channel, it may add a non-empty protocol identifier = to the DATA_CHANNEL_OPEN message. Is the endpoint, which receives this = DATA_CHANNEL_OPEN message, assumed to process this protocol id string in = a case sensitive or case insensitive way? Or would that actually be up = to the receiving WebRTC endpoint's implementation? Since the sub-protocol definition in websockets seems to be = non-normative, this feels like a matter we can leave to post 1.0 . >=20 > As far as I see draft-ietf-rtcweb-data-protocol doesn't seem to = specify this. >=20 > Background is draft-ietf-mmusic-data-channel-sdpneg, where the = subprotocol identifiers are signaled as part of an SDP attribute and = where it is not yet clarified if these identifiers are assumed to be = case sensitive or case insensitive. I=E2=80=99m not sure I understand the point of = draft-ietf-mmusic-data-channel-sdpneg -=20 I think the new data contained in the =E2=80=98offer=E2=80=99 SDP is = exactly that in the DCEP Open - and the=20 =E2=80=98answer' contains nothing other than an ACK or NACK of that = offer? That being the case, why doesn=E2=80=99t the offer side just open a = DataChannel with the required parameters and see if it gets ACK or reset back - no = additional SDP needed ?=20 Tim. >=20 > Thanks, > Juergen >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_6CABFCF2-37EB-4817-BD03-EA1F4D4F29B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 8 Mar 2016, at 12:43, Juergen = Stoetzer-Bradler <juergen.stoetzer-bradler@nokia.com> wrote:

Hello,

If a WebRTC endpoint uses the data channel = establishment protocol in order to open a data channel, it may add a = non-empty protocol identifier to the DATA_CHANNEL_OPEN message. Is the = endpoint, which receives this DATA_CHANNEL_OPEN message, assumed to = process this protocol id string in a case sensitive or case insensitive = way? Or would that actually be up to the receiving WebRTC endpoint's = implementation?

Since the sub-protocol definition in websockets seems = to be non-normative, this feels like a matter we can leave to post 1.0 = .


As far as I see = draft-ietf-rtcweb-data-protocol doesn't seem to specify this.

Background is = draft-ietf-mmusic-data-channel-sdpneg, where the subprotocol identifiers = are signaled as part of an SDP attribute and where it is not yet = clarified if these identifiers are assumed to be case sensitive or case = insensitive.

I=E2=80=99m not sure I understand the = point of draft-ietf-mmusic-data-channel-sdpneg - 
I think the = new data contained in the =E2=80=98offer=E2=80=99 SDP is exactly that in = the DCEP Open - and the 
=E2=80=98answer' = contains nothing other than an ACK or NACK of that offer?
That being the case, why doesn=E2=80=99t the offer side just = open a DataChannel with the
required parameters and = see if it gets ACK or reset back  - no additional SDP needed = ? 

Tim.


Thanks,
Juergen

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb





= --Apple-Mail=_6CABFCF2-37EB-4817-BD03-EA1F4D4F29B2-- From nobody Wed Mar 9 07:13:39 2016 Return-Path: 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 DB05B12D6D4 for ; Wed, 9 Mar 2016 06:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDP9MPbdeTu9 for ; Wed, 9 Mar 2016 06:55:18 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0415F12E0B0 for ; Wed, 9 Mar 2016 06:51:59 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id 17CDCF8281523 for ; Wed, 9 Mar 2016 14:51:55 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u29EpvX4005606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 9 Mar 2016 14:51:57 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u29Epra5012039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 9 Mar 2016 15:51:56 +0100 Received: from [149.204.68.190] (135.239.27.39) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 9 Mar 2016 15:50:04 +0100 To: References: <56DEC8F5.4070101@alcatel-lucent.com> <56DF03D8.6070308@alum.mit.edu> <56DF30EF.7040404@alvestrand.no> <56DF925A.1050209@nteczone.com> From: Juergen Stoetzer-Bradler Message-ID: <56E0381B.6030509@alcatel-lucent.com> Date: Wed, 9 Mar 2016 15:50:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56DF925A.1050209@nteczone.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050608060004090402020402" X-Originating-IP: [135.239.27.39] Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 14:55:21 -0000 --------------ms050608060004090402020402 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Ted, Paul, Harald, Christian, Thanks for your replies. Based on your feedback it seems to me that RFC 6455 and current draft-iet= f-rtcweb-data-protocol may=20 actually not unambiguously specify if (Websocket or data channel) subprot= ocol identifiers are=20 compared case-sensitively or case-insensitively. As far as I see, in case of DCEP, the situation with the 'Label' value mi= ght be similar. Thanks, Juergen On 09.03.2016 04:02, EXT Christian Groves wrote: > Hello, > > According to draft-ietf-mmusic-rfc4566bis-16 clause 5, SDP values are c= ase significant unless=20 > specified otherwise. So that would make certain registered tokens such = as MID case sensitive. > > So if we're using a case sensitive SDP field to define to indicate the = subprotocol then I think it=20 > would follow that DCEP should maintain the case sensitivity. > > We might have similar issue for RTP/RTCP SDES e.g. BUNDLE MID=20 > (draft-ietf-mmusic-sdp-bundle-negotiation-27), CLUE ID (draft-ietf-clue= -rtp-mapping-06). I don't=20 > think there's a general rule about maintaining case sensitivity for the= se cases? > > Christian > > > On 9/03/2016 7:57 AM, Ted Hardie wrote: >> On Tue, Mar 8, 2016 at 12:07 PM, Harald Alvestrand > > wrote: >> >> This is a sidetrack, but the grammar in RFC 2616: >> >> token =3D 1* >> separators =3D "(" | ")" | "<" | ">" | "@" >> | "," | ";" | ":" | "\" | <"> >> | "/" | "[" | "]" | "?" | "=3D" >> | "{" | "}" | SP | HT >> >> >> + the ancient # rule >> means that "1#token" is a comma-separated list of tokens, where >> each token is separated by LWS. >> >> So, what RFC 6455 says is: >> The request MAY include a header field with the name >> |Sec-WebSocket-Protocol|. If present, this value indicates o= ne >> or more comma-separated subprotocol the client wishes to spea= k, >> ordered by preference. The elements that comprise this value= >> MUST be non-empty strings with characters in the range U+0021= to >> U+007E not including separator characters as defined in >> [RFC2616 ] and MUST all = be unique strings. The=20 >> ABNF for the >> value of this header field is 1#token, where the definitions = of >> constructs and rules are as given in [RFC2616 ]. >> I think that text is clear enough that comma is used as a separator of= sub-protocols and that=20 >> "seperator charactors" are generally not allowed in the elements. So,= I believe that faced with=20 >> iam,thegreatest you would have to parse it as two tokens: "iam" and "t= he greatest". >> >> Ted >> >> Not only do we (or someone) have to decide whether "xmpp" matches >> "XMPP", we also have to decide whether "iam,thegreatest" matches >> "iam , thegreatest" or even "iam, >> thegreatest" (yes, there's a newline in there). >> >> All tokens registered so far are single tokens. Would it be >> possible to advise against using identifiers with comma in them? >> >> (for the base question, since this is ASCII only, lowercase is >> well-defined, so I have no strong objection to either choice.) >> >> >> >> On 03/08/2016 08:22 PM, Ted Hardie wrote: >>> On Tue, Mar 8, 2016 at 8:54 AM, Paul Kyzivat >>> > wrote: >>> >>> >>> The elements that comprise this value >>> MUST be non-empty strings with characters in the= >>> range U+0021 to >>> U+007E not including separator characters as >>> defined in >>> [RFC2616 ] >>> and MUST all be unique strings. The ABNF for the >>> value of this header field is 1#token, where the= >>> definitions of >>> constructs and rules are as given in [RFC2616 >>> ]. >>> >>> The current registry is here: >>> >>> http://www.iana.org/assignments/websocket/websocket.xhtml#subprotocol= -name >>> >>> >>> I had already investigated this. This only talks about the >>> registry, not how values passed in the protocol are compared >>> to registered values. Nor does it explicitly say whether >>> "unique strings" is to be determined via case-sensitive >>> comparison or case-insensitive comparison. >>> >>> (Without any other information to go on I guess I would >>> assume case-sensitive comparison.) >>> >>> Is there any token example in RFC 2616 that is case sensitive? = As far as I can tell they=20 >>> are all case-insensitive, but I may >>> have missed something. >>> >>> The Postel principle seems to indicate that we should always use >>> the registered form, but be willing to understand a case >>> insensitive variant. >>> >>> What is most *important* to me is that this be made entirely >>> clear, that IANA have clear instructions to enforce, and that= >>> both websocket and data channel specs consistently specify >>> what implementations must do in this regard. >>> >>> It is less important to me *which* choice is made. My >>> *preference* would be minimally that the registry not permit >>> two different names that differ only by case. If that is so, >>> then in some sense it doesn't matter how implementations of >>> the protocols do the comparison. >>> >>> How likely do you see this being? Anyone going to register XMPP >>> (instead of xmpp) is going to be hurting themselves as much as >>> users of xmpp if they actually use it. I'm happy to clean this >>> up at some point, but I find it hard to believe this is the >>> biggest rock. >>> >>> regards, >>> >>> Ted >>> >>> Thanks, >>> Paul >>> >>> regards, >>> >>> Ted >>> >>> Background is draft-ietf-mmusic-data-channel-sdpneg, >>> where the >>> subprotocol identifiers are signaled as part of an >>> SDP attribute and >>> where it is not yet clarified if these identifiers >>> are assumed to be >>> case sensitive or case insensitive. >>> >>> Thanks, >>> Juergen >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> >> >> >> _______________________________________________ >> 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 > --------------ms050608060004090402020402 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DF8wggTdMIIDxaADAgECAgoanQrOAAAAAAAGMA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoT DkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBSb290 IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcyOFowgYUxEzARBgoJkiaJk/IsZAEZ FgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAyMRcw FQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJu YWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2Ocmcli3LbVU6TRh +JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdfkyWAiGzVWeRI rYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38VbxMvQ+ygj Eyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+VdiUwDa ry1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUw AwEB/zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsG AQQBgjcVAQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAes slr2YYl8XHzr4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5z dXBwb3J0LmFsY2F0ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5h bGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4Bggr BgEFBQcwAoYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQw OAYIKwYBBQUHMAKGLGh0dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0Eu Y3J0MA0GCSqGSIb3DQEBBQUAA4IBAQClGxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3 F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjbEhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx 4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6 rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwfRfPmwRetdnD6NC5x8aRkhr4ZNBjv YxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6/XpNOx2FyG18axeeASWtENgP vqEirM5MjwkCMIIHejCCBmKgAwIBAgIKYWH+JwAAAAFWdjANBgkqhkiG9w0BAQUFADCBhTET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT 8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVs IEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNTE4MTMwNzI0WhcNMTcwNTE3MTMwNzI0 WjBOMRAwDgYDVQQDEwdsaTYwNzYwMTowOAYJKoZIhvcNAQkBFitqdWVyZ2VuLnN0b2V0emVy LWJyYWRsZXJAYWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEA3SjiDDt1yolL0cBi5MS+Bea3hhVDSdcJ/xtfzEbTtkxo05xnMgeRTy/kNJZuR4oY j/2TE+raQenSEgROQtLgxKjxtLh9/fGEuLCyFclz9SIeIYIkZBB1NSwZKmGlJHRU5jjqSinT Hmux9chaP+TUoidoDYbfdz/uFGdPW7RP21Gxjzg9v/VC+tfc0u0idNF9Vwnkh3VgdisMf1Jf JZNINpw0ZapFKRhLEhgtXVS7tkdxxTL0uc9XtviOTSSfxgBt2MPsj0qfhsNFFO4zUO1pJiBz SBPnLt7af96oS2ZHI4Xz7zNHShDoSMMIr+7l9xgopb5qN/KMCMP9BSxxNEfphwIDAQABo4IE IDCCBBwwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIhb3FWYPjsTmHpYEqhr/DQoWUmBmB C/nmTIT9tVoCAWQCAQUwHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYIKwYBBQUHAwQwCwYDVR0P BAQDAgWgMCkGCSsGAQQBgjcVCgQcMBowDAYKKwYBBAGCNwoDBDAKBggrBgEFBQcDBDBEBgkq hkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcw CgYIKoZIhvcNAwcwHQYDVR0OBBYEFEVmlcJSxtK5Cu7FZb5XUWWuKktKMB8GA1UdIwQYMBaA FNnsa72WWCL32KZ3zf5Nge+6l70SMIIBXQYDVR0fBIIBVDCCAVAwggFMoIIBSKCCAUSGgdls ZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQlMjBJbnRlcm5hbCUyMFN1YiUyMENBLENOPXVz bmF2c3BraTAzcCxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2Vydmlj ZXMsQ049Q29uZmlndXJhdGlvbixEQz1sdWFkLERDPWx1Y2VudCxEQz1jb20/Y2VydGlmaWNh dGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50 hixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNybIY4aHR0cDov L3NlcnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmwwggFh BggrBgEFBQcBAQSCAVMwggFPMIHMBggrBgEFBQcwAoaBv2xkYXA6Ly8vQ049QWxjYXRlbCUy MEx1Y2VudCUyMEludGVybmFsJTIwU3ViJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUy MFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNl bnQsREM9Y29tP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9u QXV0aG9yaXR5MDgGCCsGAQUFBzAChixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20v UEtJL3N1YkNBLmNydDBEBggrBgEFBQcwAoY4aHR0cDovL3NlcnZpY2VzLnN1cHBvcnQuYWxj YXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcnQwNgYDVR0RBC8wLYEranVlcmdlbi5zdG9l dHplci1icmFkbGVyQGFsY2F0ZWwtbHVjZW50LmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAMrtX ZAqm6NqOAYttJjvC6pL04tEKUusax1Dr6p6NfxVfUuW8ZoFXKoxHEDaYKQR9ldfnuILHN+x7 KdLeKg+NPUs7GFGwpBmJb7PRmxnIarFJbGHzpqZ9+Fhsde1uxi+y2VJcIOVaEh/JoRdHvSUQ nwT4+FcBmS6uRv68rnCkh+KeUm6A7+6dDo/9l/Zh2Hu1+HVWw5kEH/xmO170v9Xef7efxzxv BeQ644kvErDNG26LJDUtOqaKTdz9KKZXngw+2cAV/4Kc7C9xdT29Ugm8oOK/ecqBliMhBUen WphsEDjIbKJCd40RJLKb+v49EN/IJogNDd81vtehOxDw5Lus4zGCA+0wggPpAgEBMIGUMIGF MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZIm iZPyLGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0 ZWwgTHVjZW50IEludGVybmFsIFN1YiBDQQIKYWH+JwAAAAFWdjANBglghkgBZQMEAgEFAKCC AikwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwMzA5MTQ1 MDAzWjAvBgkqhkiG9w0BCQQxIgQgv15zcC0tlRZCpQUHiDUC6zSolEkb5Klai0CzmKmshb4w bAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDCBpQYJKwYBBAGCNxAEMYGXMIGUMIGFMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZIm iZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRl bCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVybmFsIFN1YiBDQQIKYWH+ JwAAAAFWdjCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYUxEzARBgoJkiaJk/IsZAEZFgNjb20x FjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQK Ew5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgU3Vi IENBAgphYf4nAAAAAVZ2MA0GCSqGSIb3DQEBAQUABIIBAEjY+Ytwp0Rc4mkTbzTZ11pnOlyW qw96i/Tf0NwggtNmAyaDuMed3LVthMb6YICkQak9tBa0zEvPD1M/drZBfPvJxb704n5+MT0h PO5DT3ATvdFIUC8ZiCru/u8UP8699xFNYsUakqr2OzACfEKMGIRH5mn1WePU3PIBaokclueX Kv/hGTA5w4FeKrov9/wZncPtIpwmcR+FsiS0Wcp4KjiJlY+TWGeFOUjOOw4pqNh3posWedOg zNDl/yL5yk7JMexbNScakLEYdOYjGGvpNTD37DZfXmafNFqL3yqyBO6drFvnj5M8tNoDJZo2 UrXweoxU5iWzIwFjjAYYJwDeeykAAAAAAAA= --------------ms050608060004090402020402-- From nobody Wed Mar 9 07:13:42 2016 Return-Path: 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 7BBCB12D736 for ; Wed, 9 Mar 2016 06:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9JFAJ_XGKoa for ; Wed, 9 Mar 2016 06:55:25 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7C4812D52E for ; Wed, 9 Mar 2016 06:52:13 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id 60E3E4B6C7DF1; Wed, 9 Mar 2016 14:52:09 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u29EqBex006169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Mar 2016 14:52:12 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u29EpraF012039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Mar 2016 15:52:11 +0100 Received: from [149.204.68.190] (135.239.27.41) by FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 9 Mar 2016 15:50:26 +0100 To: EXT Tim Panton References: <56DEC8F5.4070101@alcatel-lucent.com> From: Juergen Stoetzer-Bradler Message-ID: <56E03831.7080507@alcatel-lucent.com> Date: Wed, 9 Mar 2016 15:50:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080606000608080509000704" X-Originating-IP: [135.239.27.41] Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 14:55:27 -0000 --------------080606000608080509000704 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Tim, Thanks for feedback. The SDP offer/answer extensions described in draft-ietf-mmusic-data-chann= el-sdpneg could be used if=20 subprotocol related properties need to be negotiated, which go beyond the= pure signaling of the=20 subprotocol identifier. If no subprotocol properties need to be negotiate= d, then usage of DCEP may=20 indeed be sufficient. I mentioned this draft as I think that the case related processing of dat= a channel subprotocol ids=20 should be the same for SDP offer/answer based data channel subprotocol ne= gotiation as for DCEP based=20 data channel subprotocol negotiation. Thanks, Juergen On 09.03.2016 13:12, EXT Tim Panton wrote: > >> On 8 Mar 2016, at 12:43, Juergen Stoetzer-Bradler > > wrote: >> >> Hello, >> >> If a WebRTC endpoint uses the data channel establishment protocol in o= rder to open a data=20 >> channel, it may add a non-empty protocol identifier to the DATA_CHANNE= L_OPEN message. Is the=20 >> endpoint, which receives this DATA_CHANNEL_OPEN message, assumed to pr= ocess this protocol id=20 >> string in a case sensitive or case insensitive way? Or would that actu= ally be up to the receiving=20 >> WebRTC endpoint's implementation? > > Since the sub-protocol definition in websockets seems to be non-normati= ve, this feels like a=20 > matter we can leave to post 1.0 . > >> >> As far as I see draft-ietf-rtcweb-data-protocol doesn't seem to specif= y this. >> >> Background is draft-ietf-mmusic-data-channel-sdpneg, where the subprot= ocol identifiers are=20 >> signaled as part of an SDP attribute and where it is not yet clarified= if these identifiers are=20 >> assumed to be case sensitive or case insensitive. > > I=E2=80=99m not sure I understand the point of draft-ietf-mmusic-data-c= hannel-sdpneg - > I think the new data contained in the =E2=80=98offer=E2=80=99 SDP is ex= actly that in the DCEP Open - and the > =E2=80=98answer' contains nothing other than an ACK or NACK of that off= er? > That being the case, why doesn=E2=80=99t the offer side just open a Dat= aChannel with the > required parameters and see if it gets ACK or reset back - no addition= al SDP needed ? > > Tim. > >> >> Thanks, >> Juergen >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > > > --------------080606000608080509000704 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit Tim,

Thanks for feedback.
The SDP offer/answer extensions described in draft-ietf-mmusic-data-channel-sdpneg could be used if subprotocol related properties need to be negotiated, which go beyond the pure signaling of the subprotocol identifier. If no subprotocol properties need to be negotiated, then usage of DCEP may indeed be sufficient.
I mentioned this draft as I think that the case related processing of data channel subprotocol ids should be the same for SDP offer/answer based data channel subprotocol negotiation as for DCEP based data channel subprotocol negotiation.

Thanks,
Juergen


On 09.03.2016 13:12, EXT Tim Panton wrote:

On 8 Mar 2016, at 12:43, Juergen Stoetzer-Bradler <juergen.stoetzer-bradler@nokia.com> wrote:

Hello,

If a WebRTC endpoint uses the data channel establishment protocol in order to open a data channel, it may add a non-empty protocol identifier to the DATA_CHANNEL_OPEN message. Is the endpoint, which receives this DATA_CHANNEL_OPEN message, assumed to process this protocol id string in a case sensitive or case insensitive way? Or would that actually be up to the receiving WebRTC endpoint's implementation?

Since the sub-protocol definition in websockets seems to be non-normative, this feels like a matter we can leave to post 1.0 .


As far as I see draft-ietf-rtcweb-data-protocol doesn't seem to specify this.

Background is draft-ietf-mmusic-data-channel-sdpneg, where the subprotocol identifiers are signaled as part of an SDP attribute and where it is not yet clarified if these identifiers are assumed to be case sensitive or case insensitive.

I’m not sure I understand the point of draft-ietf-mmusic-data-channel-sdpneg - 
I think the new data contained in the ‘offer’ SDP is exactly that in the DCEP Open - and the 
‘answer' contains nothing other than an ACK or NACK of that offer?
That being the case, why doesn’t the offer side just open a DataChannel with the
required parameters and see if it gets ACK or reset back  - no additional SDP needed ? 

Tim.


Thanks,
Juergen

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb






--------------080606000608080509000704-- From nobody Wed Mar 9 07:46:42 2016 Return-Path: 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 1BA3112E1A0 for ; Wed, 9 Mar 2016 07:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0PRKafbAWLH for ; Wed, 9 Mar 2016 07:45:54 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C1D312E0A7 for ; Wed, 9 Mar 2016 07:31:06 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id z76so69805634iof.3 for ; Wed, 09 Mar 2016 07:31:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ig4Km3e5Vw7CYmFCYuP5bXjOYfZ/Q95aqZfXis2wBVk=; b=aCBr/oIPLGeZ57v8RSoSd5xiNna4eI45zsVgCR0YjGhJ9lA0ETp28e9I3N4L/e1o5P aKXch3TgwF10GdgjymOhq4Xrx5XPgAZTlBxksgtcXobddCRjjrPOjE45An1L4PNejZbc jWhyUs2VTqq7EU0V7AtNENenYg3LTWUxoUmvz+FpTv7aCx6czBWj1JvBwPXqk7rBiVFD FC4V5Qw9P9o5ILN5WLheZ/ZhHBhtPxEHn0ChEOysXqmlz2sAg8YPDbK7bx6Ofy/vdKd+ SolNsMv/Bm6ebthwOUhPivgGxtN4rakBqi54iCvWlTWKIvgQITeo+hVIqQUt9et/lW7t 8Hjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ig4Km3e5Vw7CYmFCYuP5bXjOYfZ/Q95aqZfXis2wBVk=; b=iyYN283iFSaogY/uPU/Ia6z6JVS9tLvtpgFe7FWnXVz6Nt13ZviXINV7BOqxJcRqEi elN45BOzVNYMjPOE8gWU032b3q7bZRmGinSht2o9gbQ2GAjwXp5yAqj3HbxuM1EkKfGL P43TLJvrgIo3wix/mEF50p5EYQm3TlKofeH8E2teGvkUiDXdYheAphVAPr9f9ZrKG2Wg IJ39syonS9xC7YT702xYlHB1hEI3/kHe6t2WbzfTyetsU8KdtiQbgRATTXeDpSmOvPYS 7ojSwYTQazVKC8DEC2VqeGnJSLih9knjSU/T3oJxyo4CGDWYfT3Ckp5xXqtQ5yVtLKUA tb9w== X-Gm-Message-State: AD7BkJKHpnfL8zW5COVbBj/RVOMYiZDyyXMSjfEyHuYkRU3Od6ZPS+i2pYvoVUMf740IWw== X-Received: by 10.107.184.135 with SMTP id i129mr38378833iof.4.1457537465533; Wed, 09 Mar 2016 07:31:05 -0800 (PST) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com. [209.85.223.169]) by smtp.gmail.com with ESMTPSA id k6sm8578207igd.8.2016.03.09.07.31.03 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Mar 2016 07:31:04 -0800 (PST) Received: by mail-io0-f169.google.com with SMTP id g203so69833197iof.2 for ; Wed, 09 Mar 2016 07:31:03 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.30.71 with SMTP id e68mr32907549ioe.145.1457537463361; Wed, 09 Mar 2016 07:31:03 -0800 (PST) Received: by 10.36.106.194 with HTTP; Wed, 9 Mar 2016 07:31:03 -0800 (PST) In-Reply-To: <56DF7C6B.4050400@mozilla.com> References: <56DDF13F.1050505@mozilla.com> <56DF7C6B.4050400@mozilla.com> Date: Wed, 9 Mar 2016 10:31:03 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=001a1140d71ec08e9e052d9f62ab Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] DTMF resolution proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 15:45:56 -0000 --001a1140d71ec08e9e052d9f62ab Content-Type: text/plain; charset=UTF-8 On Tue, Mar 8, 2016 at 8:29 PM, Jean-Marc Valin wrote: > I'm not going to make a big deal out of this, but it feels to me like > the default duration should be in the W3C doc rather than in the IETF > doc since it describes browser behaviour rather than something can can > be observed on the wire. Of course, it doesn't hurt either, so I won't > object if people disagree with me. > I would prefer the recommended values to stay in audio draft. This draft already specifies preferences, such as not using CN with OPUS, so it would make sense to include DTMF tone and gap duration preferences as well. The recommendations are there to improve interoperability of WebRTC end points with traditional PSTN, so it is not something that should be defined by W3C document. This data useful in providing guidance for interop tests for gateways, SBCs. or any other equipment which is designed to work with WebRTC. I do not think gateway implementer should go through the API document to find the typical tone and gap duration for WebRTC. Finally, I have proposed to include this data as non-normative, information only value, so there is very little harm in it being there. Regards, _____________ Roman Shpount --001a1140d71ec08e9e052d9f62ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 8, 2016 at 8:29 PM, Jean-Marc Valin <= jmvalin@mozilla.co= m> wrote:
I'm not going to make a big deal out of this, but it feels to m= e like
the default duration should be in the W3C doc rather than in the IETF
doc since it describes browser behaviour rather than something can can
be observed on the wire. Of course, it doesn't hurt either, so I won= 9;t
object if people disagree with me.

I wo= uld prefer the recommended values to stay in audio draft.

This draft already specifies preferences, such as not using CN with= OPUS, so it would make sense to include DTMF tone and gap duration prefere= nces as well.

The recommendations are there to imp= rove interoperability of WebRTC end points with traditional PSTN, so it is = not something that should be defined by W3C document.

<= div>This data useful in providing guidance for interop tests for gateways, = SBCs. or any other equipment which is designed to work with WebRTC. I do no= t think gateway implementer should go through the API document to find the = typical tone and gap duration for WebRTC.

Finally,= I have proposed to include this data as non-normative, information only va= lue, so there is very little harm in it being there.

Regards,
_____________
Roman= Shpount
=C2=A0
--001a1140d71ec08e9e052d9f62ab-- From nobody Wed Mar 9 07:50:10 2016 Return-Path: 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 9CB9A12DFDD for ; Wed, 9 Mar 2016 07:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MR6QCeS7HtqV for ; Wed, 9 Mar 2016 07:49:22 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467E612D785 for ; Wed, 9 Mar 2016 07:35:49 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id 124so43627421pfg.0 for ; Wed, 09 Mar 2016 07:35:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=QZRszeLdVecuuifbS9+bWbNiBtUMWoc9USAEPOGxMsI=; b=sHMwrWculKzFt1TJzscYccnyji5ByCRxsjen/Plz1cX5stfSgTtO/xqGv4p63IjUrd Aj2+6fI6Ymfrx1ATr6CpvgGcQAdYB7U6ePDGP7/5uNsOUB5UG0VG0s7Pl1g7pPptvswH hcqAos3IaD76y+52RBjDfb+DTSWjWqa3auDgwSDIaoA3Il1e+HpS6/YdAzaZBD21VyO6 hs32lG40Bgc1cC7aoz5sYSA5xoL74oSLjWjr6qu18Sv+JqG/RclN7fYqG3ylalFlfd5B s7cAy/7Vz56a8G2yWHeJzJsyz2mRNdS5sxTho5CjqIi7NPTuXRyhMKzleVYe4flpiVbP PsFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=QZRszeLdVecuuifbS9+bWbNiBtUMWoc9USAEPOGxMsI=; b=PcgT1O/Yh0hkAhOYTFGvkPzhy5sDZUl3nuitPGY7/5gGEDtKJ0WSAqMWyQ0dQ8SRqY pdCS7+kqtFEJzx/cCbeXJsXbGUZO1dLG7lV4FV6DtgNoRDPrjqVqf1UUkLOpzEn1CmTV lE7Qn1s1Z8smaKubgysvi26tFBFoG26OnS41De1FFSvOsrgLiUJ16SHgOSqRHmmrJ18j nxlPWTzYG9esFX7HQB6lhUW3hxfMEhjyGnDFal6vDNuMZr4GOy+AO2aVNLj3NqnBCIXf Ac36UnV9nYJGZei1OPXc1QQVD8wuGiCi4NZmkce8GUlHXTaeWblS+h3Lw3CBEE92iMhf e4sQ== X-Gm-Message-State: AD7BkJIqHDvqRX8EK1S/ZM/+CugIvuU2m1IT/3fjqT9bkL3v11TeydNFkDr581RSiPuJPPrf X-Received: by 10.98.93.205 with SMTP id n74mr50984945pfj.99.1457537748765; Wed, 09 Mar 2016 07:35:48 -0800 (PST) Received: from panoramix.jmvalin.ca ([12.207.17.3]) by smtp.gmail.com with ESMTPSA id ez6sm13330280pab.12.2016.03.09.07.35.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Mar 2016 07:35:47 -0800 (PST) To: Roman Shpount References: <56DDF13F.1050505@mozilla.com> <56DF7C6B.4050400@mozilla.com> From: Jean-Marc Valin Message-ID: <56E042D2.3090907@mozilla.com> Date: Wed, 9 Mar 2016 10:35:46 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] DTMF resolution proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 15:49:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/09/2016 10:31 AM, Roman Shpount wrote: OK, I can live with that and include the text you proposed: "WebRTC endpoints generated events MUST have duration of no more than 8000 ms and no less than 40 ms with the recommended default duration of 100 ms for each tone. The gap between events MUST be no less then 30 ms with the recommended default duration of 70 ms." Cheers, Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW4ELMAAoJEJ6/8sItn9q9PmkH/iRzv1wpu0Q6JwU4xT7Rss51 qLybpByHOqdOZe3nkZtZifZXiuYaROUamuob2hwt6CDi39usl+gEdNc45WRKz0Qj fwfy9rr0s6AjDA4n9dgYJO7QuZX4b1O8wx9ozvSxBNFuOBZHAMn/7nnLO1WiqHkp 1fUPS6Wln3XE8jW7km2qS6E14ffp+Q9JHVT7cMINaAorY4dY93JCcMRbHhSeuYQB NYqwmprYBHycPpNi+gXpHwcvnfcoAijObXZZShnclevyNrp3BuslYg89VypgCe8d Ig/EggHdEgkgJD13SarlX9OSJJ6hkZ2WokPtfoVgwgTxPYCX/o+/AfhvzuD2DQI= =apR1 -----END PGP SIGNATURE----- From nobody Wed Mar 9 07:50:11 2016 Return-Path: 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 9674812E0DF for ; Wed, 9 Mar 2016 07:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mozilla-com.20150623.gappssmtp.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtzwotCCUfl3 for ; Wed, 9 Mar 2016 07:49:24 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2ECB12DFC4 for ; Wed, 9 Mar 2016 07:35:49 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id n5so5166927pfn.2 for ; Wed, 09 Mar 2016 07:35:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=0hTmmBiaxYtdLXDZEXYcjUh4/N9GagcQDMujFlJc6vU=; b=ItURj/F0aeikppjJ9yj7Lp2ne8XmvQBk1gcPrUyURfCe31yIQk0FkcD1SfYISAt4O2 buavRYkrHh/YVcYxjwgAYcndSBg/TCdHiM13+QtIQxcHcS/Tmc6OFda9KoD9Bmz6wgGl kk3W/Ie0klbmG6WYf3Rf9JGtEY4YHtnm9waYdyMLFM06ZpRuWMhp5fksu0eEZyn7EPTc HrkSSoL97Yunep8KTPFuRW+yteIbjsuSLpC653Kt0E7MhN+Dc6QcmPkZDAB3cAepPsr7 3dcLHNekTcQAGjvPhqIoFG63PH3QUUV7NX/TNZ6o84gKoxsNt0sZRQVVDKgvTAgS5FLN Alqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0hTmmBiaxYtdLXDZEXYcjUh4/N9GagcQDMujFlJc6vU=; b=l50IpuseuuXvrz20fPzbaKPFi9AyocTA7zto0dXIGgnwnLqZWNaOQbHWk6s6A3635q axlsVJU+nNEOJ7I6khS0axMSdPbWuZxudL5apfMvCVr/QN9sJlZvob97R/j1KvPPiJcg /rtKnMSe/jDe+yDOue+6x/+J02749dU1VQpITGF1ZmLgWe2oPqqmleEDErDy52alKj94 Vv7nSIpk/8SKVkhUJWk2Yxfk+zcWchwKtzMwHRR6xYCT1reqXkfHGKCb54i8+MDyoTip O8SK/48JpJ4P0V84i7XMv5fe4QbJol4kti2GlUFYlcrLFO9GThNrkysrqAY2KwHpVHce +H2w== X-Gm-Message-State: AD7BkJIN7wUQeUEvzrcbzOKsPWkk+SQ5YGRxxDV5+g3Ri8ZB25FR+rY2wFgzGMUlMwBIAxt4 X-Received: by 10.98.18.195 with SMTP id 64mr40997255pfs.131.1457537749472; Wed, 09 Mar 2016 07:35:49 -0800 (PST) Received: from panoramix.jmvalin.ca ([12.207.17.3]) by smtp.gmail.com with ESMTPSA id z5sm13316512par.21.2016.03.09.07.35.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Mar 2016 07:35:47 -0800 (PST) To: Roman Shpount References: <56DDF13F.1050505@mozilla.com> <56DF7C6B.4050400@mozilla.com> From: Jean-Marc Valin Message-ID: <56E042D2.6000806@mozilla.com> Date: Wed, 9 Mar 2016 10:35:46 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] DTMF resolution proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 15:49:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/09/2016 10:31 AM, Roman Shpount wrote: > I would prefer the recommended values to stay in audio draft. OK, I can live with that and include the text you proposed: "WebRTC endpoints generated events MUST have duration of no more than 8000 ms and no less than 40 ms with the recommended default duration of 100 ms for each tone. The gap between events MUST be no less then 30 ms with the recommended default duration of 70 ms." Cheers, Jean-Marc > This draft already specifies preferences, such as not using CN with > OPUS, so it would make sense to include DTMF tone and gap duration > preferences as well. > > The recommendations are there to improve interoperability of > WebRTC end points with traditional PSTN, so it is not something > that should be defined by W3C document. > > This data useful in providing guidance for interop tests for > gateways, SBCs. or any other equipment which is designed to work > with WebRTC. I do not think gateway implementer should go through > the API document to find the typical tone and gap duration for > WebRTC. > > Finally, I have proposed to include this data as non-normative, > information only value, so there is very little harm in it being > there. > > Regards, _____________ Roman Shpount > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW4ELMAAoJEJ6/8sItn9q9dEoH/AjAZZJc/f2CQzMOR8oPDI4n 2O4RNEu90vkGN4Tpy9JUOOEtt8pLAP+2j4e8VNz9/nG/YOsM2VZrbGMJn4LJEG/q Iyf65HKXoM6vdU3h9v1joT1qAVpKfdboP+VEEBxCl3Yg8B5b7IAshEIduqu1ucHh Oi3qzHOFUO2CAacjpSCk2ArZ+rPuse04NunV1P2Muuoge1TZt8psgtaN30MxtnDH dBhmI8tk1k7yikc4hn1tDfkSXxH2vHp6V/DwdBDOqxk9J0uWG+VJMl8zeI1Asl7i K6L2+0/vsYegJWlXN/7TwQj4ZRy1A4R05H3tDOLXkrgOs9QezOGSC1OEZuC8bqc= =oTLR -----END PGP SIGNATURE----- From nobody Wed Mar 9 08:03:25 2016 Return-Path: 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 82EA012E1E8 for ; Wed, 9 Mar 2016 08:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFGAoqMp-AYG for ; Wed, 9 Mar 2016 08:02:38 -0800 (PST) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 411C112E23B for ; Wed, 9 Mar 2016 07:52:22 -0800 (PST) Received: by mail-ig0-x230.google.com with SMTP id ig19so47534626igb.1 for ; Wed, 09 Mar 2016 07:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=oD90w6oIfSNUvmTQQnag/UN1jSqPkmALYKl6xarJt9U=; b=EbPYsQ5O5xWRaOh48IelJszV+42ZXLvpXguJ1np8mr66WiviHsuCvMyEmLGH5U+mMS SeG9oGi7ObKIG6qXEm8dWpxYchPtMiVlx+gOt6riUGxdPsk5gTnPZFeHuCvJdwcKL5gu GNcSP9m1T2LTFLvuVeaayLB51LrtUvDtEcUO9ZZFmP0RRBnu0QhGtzxZ6bph0/O4wLln jKN5NtOjOrv/cakYmATaKPFjsFIihGWV1Y/lE2ftFiUTzoTYfIny5diY6g/Bf2vmyaVC 2z8AUPX/7F4FsW0glWbj+KgDdfvPVF5HcQ36Ra54PcasRxUwJe/sB+Ol08Ypt+BLJalx GelQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=oD90w6oIfSNUvmTQQnag/UN1jSqPkmALYKl6xarJt9U=; b=kuLv+PUTMluWPCuVXMJ9m/qzE0q9bDYCEO7NXvrX1HZzOoOgoSKI5N0b3SQwrjwdnE JB6Ol4X8DzZX2+C6B4kgD4AcDCm5U/j2fMW0OER5t6oAVPaxfh29jfgUm25CtLYW1cEM 6eHK7Idr1kR3uQYyw2nSe6fD3nScrm3QLK/ZVLGujGu4qouicBtqVmPD33Zjff54jf2o qN2svSiKH0jwiHjo4RcCBoB79n/yOxCdviHrXivMoL36KfxRlf2fsVQiqfpJvDQRiiwe AXwg0cFrWDTTP5voyNWbEZaPWfftYar0A2zR8A7F9YAzJvzpcWqBdnBpeYEC1wJAgsyX zyBA== X-Gm-Message-State: AD7BkJKaNcUoAXb7sepsCNaZyDDLxXKVpq7qVBmYvubJpt3Og7EC8Kwttfsm7Or1dyPakg== X-Received: by 10.50.155.5 with SMTP id vs5mr24110353igb.0.1457538740183; Wed, 09 Mar 2016 07:52:20 -0800 (PST) Received: from mail-ig0-f172.google.com (mail-ig0-f172.google.com. [209.85.213.172]) by smtp.gmail.com with ESMTPSA id k2sm3260384ioe.19.2016.03.09.07.52.18 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Mar 2016 07:52:18 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id vf5so14570732igb.0 for ; Wed, 09 Mar 2016 07:52:18 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.61.166 with SMTP id q6mr25129297igr.96.1457538738054; Wed, 09 Mar 2016 07:52:18 -0800 (PST) Received: by 10.36.106.194 with HTTP; Wed, 9 Mar 2016 07:52:17 -0800 (PST) In-Reply-To: References: <56DDF13F.1050505@mozilla.com> Date: Wed, 9 Mar 2016 10:52:17 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=047d7bdca2f8ba98aa052d9fae92 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] DTMF resolution proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 16:02:40 -0000 --047d7bdca2f8ba98aa052d9fae92 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 9, 2016 at 4:46 AM, Asveren, Tolga wrote: > i- I personally would prefer not to leave a grey area (after all, the gap > between retransmitted end-packets is another value, which needs to be > known/determined/provided). > There are a lot of grey areas in how RFC 4733 tones are generated, including how often tone update packets should be sent when tone is being played, should audio signal be sent during tone generation, should audio packets be sent during the tone generation, should tone duration and start be extended to a regular, non-tone packet boundary, what interval should be used for the end of tone packet. This group indicated that it is not interested in defining any of these things and I would prefer to keep these things out rtcweb-audio draft. If you think (I definitely think so), that RFC 4733 can be improved with the set of recommendations on how tones should be generated, this should be discussed in a different group (avtcore or avtext) as either RFC 4733 update or an independent information draft. This information would not be rtcweb specific and most likely benefit other VoIP implementations. ii- I wouldn=E2=80=99t mind if the min-value for retransmission gap is 10ms= , or > even 0ms, and actually would prefer 0ms as it does not impose any > restrictions (this all assuming =E2=80=93which IMHO is not the right choi= ce- that > the limits will be specified in rtcweb-audio draft rather than in W3C > specification) > I believe anything network protocol related should be specified in one of the IETF groups. If it is rtcweb specific it should go into one of the rtcweb drafts. If it generic (like a general RFC 4733 update) it should be done by the group responsible for this specification. iii- It is not clear to me whether the use of the word =E2=80=9CWebRTC endp= oint=E2=80=9D by > default covers gateways as well. draft-ietf-rtcweb-gateways-02 has the > following: > > A WebRTC gateway appears as a WebRTC-compatible endpoint, and will > > thus not be conformant with all requirements for a WebRTC endpoint > > (it does not do everything a WebRTC endpoint does), but is able to > > interoperate with WebRTC endpoints. > > I interpret this as =E2=80=9CAnything, which is mandated for webrtc-endpo= ints and > not explicitly specified as not applicable for gateways in rtcweb-gatewa= y > document is applicable for gateways too=E2=80=9D, in which case I would s= uggest > adding a statement to rtcweb-gateway document that RFC4733 limits do not > apply to it (just trying to prevent the possibility of interworking). > WebRTC endpoint is specifically different from WebRTC-compatible endpoint. WebRTC-compatible endpoints do not have to implement OPUS or CN. They just need to interop with full WebRTC endpoints. iv- I don=E2=80=99t understand why retransmission gap limit would require R= FC4733 > update whereas the other limits under consideration don=E2=80=99t. > > > As I have mentioned above, there is a lot more then just final packet retransmission gap which is left to be implementation specific in RFC4733. I have a feeling this group is tired of DTMF so if you want to discuss this, we should discuss this elsewhere (avtcore or avtext). Whatever is decided there will affect rtcweb as well as other RFC 4733 implementations. Regards, _____________ Roman Shpount --047d7bdca2f8ba98aa052d9fae92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 9, 2016 at 4:46 AM, Asveren, Tolga <<= a href=3D"mailto:tasveren@sonusnet.com" target=3D"_blank">tasveren@sonusnet= .com> wrote:

i- I personally would prefer not to leave a = grey area (after all, the gap between retransmitted end-packets is another = value, which needs to be known/determined/provided).

=

There are a lot of grey areas in how RFC 4= 733 tones are generated, including how often tone update packets should be = sent when tone is being played, should audio signal be sent during tone gen= eration, should audio packets be sent during the tone generation, should to= ne duration and start be extended to a regular, non-tone packet boundary, w= hat interval should be used for the end of tone packet. This group indicate= d that it is not interested in defining any of these things and I would pre= fer to keep these things out rtcweb-audio draft.

I= f you think (I definitely think so), that RFC 4733 can be improved with the= set of recommendations on how tones should be generated, this should be di= scussed in a different group (avtcore or avtext) as either RFC 4733 update = or an independent information draft. This information would not be rtcweb s= pecific and most likely benefit other VoIP implementations.

<= /div>

ii- I wouldn=E2=80=99t mind if the min-value= for retransmission gap is 10ms, or even 0ms, and actually would prefer 0ms= as it does not impose any restrictions (this all assuming =E2=80=93which IMHO is not the right choice- that the limits will= be specified in rtcweb-audio draft rather than in W3C specification)

=C2=A0
I believe anything network pr= otocol related should be specified in one of the IETF groups. If it is rtcw= eb specific it should go into one of the rtcweb drafts. If it generic (like= a general RFC 4733 update) it should be done by the group responsible for = this specification.

iii- It is = not clear to me whether the use of the word =E2=80=9CWebRTC endpoint=E2=80= =9D by default covers gateways as well. draft-ietf-rtcweb-gateways-02 has t= he following:

=C2=A0=C2=A0 A WebRTC gateway appears as a WebRTC-compatible e= ndpoint, and will

=C2=A0=C2=A0 thus not be conformant with all requirements for = a WebRTC endpoint

=C2=A0=C2=A0 (it does not do everything a WebRTC endpoint does= ), but is able to

=C2=A0=C2=A0 interoperate with WebRTC endpoints.=

I interpret this as =E2=80=9CAnything, which= is mandated for webrtc-endpoints and not explicitly specified as not appli= cable for gateways in =C2=A0rtcweb-gateway document is applicable for gateways too=E2=80=9D, in which case I would suggest add= ing a statement to rtcweb-gateway document that RFC4733 limits do not apply= to it (just trying to prevent the possibility of interworking).

=
=C2=A0
WebRTC endpoint is specifically di= fferent from WebRTC-compatible endpoint. WebRTC-compatible endpoints do not= have to implement OPUS or CN. They just need to interop with full WebRTC e= ndpoints.

=

iv- I don=E2=80=99t understand why retransmi= ssion gap limit would require RFC4733 update whereas the other limits under= consideration don=E2=80=99t.



As I = have mentioned above, there is a lot more then just final packet retransmis= sion gap which is left to be implementation specific in RFC4733. I have a f= eeling this group is tired of DTMF so if you want to discuss this, we shoul= d discuss this elsewhere (avtcore or avtext). Whatever is decided there wil= l affect rtcweb as well as other RFC 4733 implementations.

Regards,
_____________Roman Shpount
=C2=A0
--047d7bdca2f8ba98aa052d9fae92-- From nobody Wed Mar 9 08:17:35 2016 Return-Path: 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 72ACF12D7B0 for ; Wed, 9 Mar 2016 08:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Fae83Mit3mq for ; Wed, 9 Mar 2016 08:15:39 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0674.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc09::674]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4447212E0F1 for ; Wed, 9 Mar 2016 08:10:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zvG7n6h8FY8X0jTDN5LdemmIszmfUSV8QFJC8bXFAHM=; b=S6JVZGpcxwEnEJLFJT2JBtoYRIYjmCkVxO4rBv/Oge4Cr1SUL5g/+mFDbWoLFbMwir5WeTBFJoxZ8cUj1Laq1Pv0ex9uCD5pn0q0OvsrDUii8vOr195q6W+NARTxkR6h/S/2A4Mb28k5sfeLZ1+nryni0yGfvWW7ZB9RShxiAUY= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) with Microsoft SMTP Server (TLS) id 15.1.427.16; Wed, 9 Mar 2016 16:09:52 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0427.019; Wed, 9 Mar 2016 16:09:52 +0000 From: "Asveren, Tolga" To: Roman Shpount Thread-Topic: [rtcweb] DTMF resolution proposal Thread-Index: AQHReLEGZXQ6ENs53U20okwQmfoJbJ9OfbeAgAAPmQCAAJd7oIABJwEAgACO1FCAAGtNgIAABBtg Date: Wed, 9 Mar 2016 16:09:52 +0000 Message-ID: References: <56DDF13F.1050505@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: telurix.com; dkim=none (message not signed) header.d=none;telurix.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: df84534d-eb96-4d8a-f7c6-08d348353f7e x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1551; 5:ifi+3mZKi3l3cOaUInDNNMoZuF33scPCTCG5PJSCEwLiXcoRb2nUR5fjyCk7ygbOsLlrfxR2XhROY5dhrAQ4CFGOBbzaazLu6dWvsI9egBd64aoCYH3YCPq2OKyqKeGvd2FLzaotLgiuXGSub+x0gQ==; 24:5b+pGwLBtUpVostNJ4SFKZ4TUEhHElVeUsW8HvlFiGWIoBMIYg9MVkCtApGWvc65j5/xuTRm/w9/fOr6qW1FKN9FmfasShB6euGTqf5UdiE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1551; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:SN1PR0301MB1551; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1551; x-forefront-prvs: 0876988AF0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(24454002)(164054003)(6116002)(790700001)(102836003)(1220700001)(3280700002)(2906002)(4326007)(586003)(3660700001)(76576001)(1096002)(87936001)(5003600100002)(10400500002)(50986999)(76176999)(3846002)(5004730100002)(5002640100001)(19300405004)(54356999)(189998001)(19609705001)(19580395003)(19580405001)(561944003)(93886004)(33656002)(2950100001)(106116001)(2900100001)(5008740100001)(86362001)(122556002)(16236675004)(15975445007)(74316001)(81166005)(110136002)(77096005)(66066001)(19625215002)(99286002)(92566002)(11100500001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1551; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551DEB5C6DF2628C885F988B2B30SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2016 16:09:52.2623 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1551 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] DTMF resolution proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 16:15:41 -0000 --_000_SN1PR0301MB1551DEB5C6DF2628C885F988B2B30SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IOKAnFdlYlJUQyBlbmRwb2ludCBpcyBzcGVjaWZpY2FsbHkgZGlmZmVyZW50IGZyb20gV2ViUlRD LWNvbXBhdGlibGUgZW5kcG9pbnQuIFdlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50cyBkbyBub3Qg aGF2ZSB0byBpbXBsZW1lbnQgT1BVUyBvciBDTi4gVGhleSBqdXN0IG5lZWQgdG8gaW50ZXJvcCB3 aXRoIGZ1bGwgV2ViUlRDIGVuZHBvaW50cy7igJ0NCkFzIHRoZSBib3R0b20gbGluZSwgd291bGQg YSBnYXRld2F5IG5lZWQgdG8gY29tcGx5IHdpdGggdGhlIHJhbmdlIHJlc3RyaWN0aW9ucyBmb3Ig dGhlIFJGQzQ3MzMgaXQgaXMgc2VuZGluZyB0b3dhcmQgdGhlIFdlYlJUQyBsZWcgb3Igbm90PyBJ ICp0aGluayogd2hhdCB5b3Ugc2F5IGlzIHRoYXQgaXQgZG9lcyBub3QuIEkgc3Ryb25nbHkgd291 bGQgcHJlZmVyIHRoYXQgdGhlIHRleHQgaXMgY2xlYXIgb24gdGhpcyBpc3N1ZS4NCg0KVGhhbmtz LA0KVG9sZ2ENCg0KDQpGcm9tOiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5j b21dDQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDA5LCAyMDE2IDEwOjUyIEFNDQpUbzogQXN2ZXJl biwgVG9sZ2EgPHRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4NCkNjOiBUZWQgSGFyZGllIDx0ZWQuaWV0 ZkBnbWFpbC5jb20+OyBKZWFuLU1hcmMgVmFsaW4gPGptdmFsaW5AbW96aWxsYS5jb20+OyBDdWxs ZW4gSmVubmluZ3MgPGZsdWZmeUBjaXNjby5jb20+OyBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbcnRjd2ViXSBEVE1GIHJlc29sdXRpb24gcHJvcG9zYWwNCg0KT24gV2VkLCBNYXIgOSwg MjAxNiBhdCA0OjQ2IEFNLCBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPG1h aWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20+PiB3cm90ZToNCmktIEkgcGVyc29uYWxseSB3b3Vs ZCBwcmVmZXIgbm90IHRvIGxlYXZlIGEgZ3JleSBhcmVhIChhZnRlciBhbGwsIHRoZSBnYXAgYmV0 d2VlbiByZXRyYW5zbWl0dGVkIGVuZC1wYWNrZXRzIGlzIGFub3RoZXIgdmFsdWUsIHdoaWNoIG5l ZWRzIHRvIGJlIGtub3duL2RldGVybWluZWQvcHJvdmlkZWQpLg0KDQpUaGVyZSBhcmUgYSBsb3Qg b2YgZ3JleSBhcmVhcyBpbiBob3cgUkZDIDQ3MzMgdG9uZXMgYXJlIGdlbmVyYXRlZCwgaW5jbHVk aW5nIGhvdyBvZnRlbiB0b25lIHVwZGF0ZSBwYWNrZXRzIHNob3VsZCBiZSBzZW50IHdoZW4gdG9u ZSBpcyBiZWluZyBwbGF5ZWQsIHNob3VsZCBhdWRpbyBzaWduYWwgYmUgc2VudCBkdXJpbmcgdG9u ZSBnZW5lcmF0aW9uLCBzaG91bGQgYXVkaW8gcGFja2V0cyBiZSBzZW50IGR1cmluZyB0aGUgdG9u ZSBnZW5lcmF0aW9uLCBzaG91bGQgdG9uZSBkdXJhdGlvbiBhbmQgc3RhcnQgYmUgZXh0ZW5kZWQg dG8gYSByZWd1bGFyLCBub24tdG9uZSBwYWNrZXQgYm91bmRhcnksIHdoYXQgaW50ZXJ2YWwgc2hv dWxkIGJlIHVzZWQgZm9yIHRoZSBlbmQgb2YgdG9uZSBwYWNrZXQuIFRoaXMgZ3JvdXAgaW5kaWNh dGVkIHRoYXQgaXQgaXMgbm90IGludGVyZXN0ZWQgaW4gZGVmaW5pbmcgYW55IG9mIHRoZXNlIHRo aW5ncyBhbmQgSSB3b3VsZCBwcmVmZXIgdG8ga2VlcCB0aGVzZSB0aGluZ3Mgb3V0IHJ0Y3dlYi1h dWRpbyBkcmFmdC4NCg0KSWYgeW91IHRoaW5rIChJIGRlZmluaXRlbHkgdGhpbmsgc28pLCB0aGF0 IFJGQyA0NzMzIGNhbiBiZSBpbXByb3ZlZCB3aXRoIHRoZSBzZXQgb2YgcmVjb21tZW5kYXRpb25z IG9uIGhvdyB0b25lcyBzaG91bGQgYmUgZ2VuZXJhdGVkLCB0aGlzIHNob3VsZCBiZSBkaXNjdXNz ZWQgaW4gYSBkaWZmZXJlbnQgZ3JvdXAgKGF2dGNvcmUgb3IgYXZ0ZXh0KSBhcyBlaXRoZXIgUkZD IDQ3MzMgdXBkYXRlIG9yIGFuIGluZGVwZW5kZW50IGluZm9ybWF0aW9uIGRyYWZ0LiBUaGlzIGlu Zm9ybWF0aW9uIHdvdWxkIG5vdCBiZSBydGN3ZWIgc3BlY2lmaWMgYW5kIG1vc3QgbGlrZWx5IGJl bmVmaXQgb3RoZXIgVm9JUCBpbXBsZW1lbnRhdGlvbnMuDQoNCmlpLSBJIHdvdWxkbuKAmXQgbWlu ZCBpZiB0aGUgbWluLXZhbHVlIGZvciByZXRyYW5zbWlzc2lvbiBnYXAgaXMgMTBtcywgb3IgZXZl biAwbXMsIGFuZCBhY3R1YWxseSB3b3VsZCBwcmVmZXIgMG1zIGFzIGl0IGRvZXMgbm90IGltcG9z ZSBhbnkgcmVzdHJpY3Rpb25zICh0aGlzIGFsbCBhc3N1bWluZyDigJN3aGljaCBJTUhPIGlzIG5v dCB0aGUgcmlnaHQgY2hvaWNlLSB0aGF0IHRoZSBsaW1pdHMgd2lsbCBiZSBzcGVjaWZpZWQgaW4g cnRjd2ViLWF1ZGlvIGRyYWZ0IHJhdGhlciB0aGFuIGluIFczQyBzcGVjaWZpY2F0aW9uKQ0KDQpJ IGJlbGlldmUgYW55dGhpbmcgbmV0d29yayBwcm90b2NvbCByZWxhdGVkIHNob3VsZCBiZSBzcGVj aWZpZWQgaW4gb25lIG9mIHRoZSBJRVRGIGdyb3Vwcy4gSWYgaXQgaXMgcnRjd2ViIHNwZWNpZmlj IGl0IHNob3VsZCBnbyBpbnRvIG9uZSBvZiB0aGUgcnRjd2ViIGRyYWZ0cy4gSWYgaXQgZ2VuZXJp YyAobGlrZSBhIGdlbmVyYWwgUkZDIDQ3MzMgdXBkYXRlKSBpdCBzaG91bGQgYmUgZG9uZSBieSB0 aGUgZ3JvdXAgcmVzcG9uc2libGUgZm9yIHRoaXMgc3BlY2lmaWNhdGlvbi4NCg0KaWlpLSBJdCBp cyBub3QgY2xlYXIgdG8gbWUgd2hldGhlciB0aGUgdXNlIG9mIHRoZSB3b3JkIOKAnFdlYlJUQyBl bmRwb2ludOKAnSBieSBkZWZhdWx0IGNvdmVycyBnYXRld2F5cyBhcyB3ZWxsLiBkcmFmdC1pZXRm LXJ0Y3dlYi1nYXRld2F5cy0wMiBoYXMgdGhlIGZvbGxvd2luZzoNCiAgIEEgV2ViUlRDIGdhdGV3 YXkgYXBwZWFycyBhcyBhIFdlYlJUQy1jb21wYXRpYmxlIGVuZHBvaW50LCBhbmQgd2lsbA0KICAg dGh1cyBub3QgYmUgY29uZm9ybWFudCB3aXRoIGFsbCByZXF1aXJlbWVudHMgZm9yIGEgV2ViUlRD IGVuZHBvaW50DQogICAoaXQgZG9lcyBub3QgZG8gZXZlcnl0aGluZyBhIFdlYlJUQyBlbmRwb2lu dCBkb2VzKSwgYnV0IGlzIGFibGUgdG8NCiAgIGludGVyb3BlcmF0ZSB3aXRoIFdlYlJUQyBlbmRw b2ludHMuDQpJIGludGVycHJldCB0aGlzIGFzIOKAnEFueXRoaW5nLCB3aGljaCBpcyBtYW5kYXRl ZCBmb3Igd2VicnRjLWVuZHBvaW50cyBhbmQgbm90IGV4cGxpY2l0bHkgc3BlY2lmaWVkIGFzIG5v dCBhcHBsaWNhYmxlIGZvciBnYXRld2F5cyBpbiAgcnRjd2ViLWdhdGV3YXkgZG9jdW1lbnQgaXMg YXBwbGljYWJsZSBmb3IgZ2F0ZXdheXMgdG9v4oCdLCBpbiB3aGljaCBjYXNlIEkgd291bGQgc3Vn Z2VzdCBhZGRpbmcgYSBzdGF0ZW1lbnQgdG8gcnRjd2ViLWdhdGV3YXkgZG9jdW1lbnQgdGhhdCBS RkM0NzMzIGxpbWl0cyBkbyBub3QgYXBwbHkgdG8gaXQgKGp1c3QgdHJ5aW5nIHRvIHByZXZlbnQg dGhlIHBvc3NpYmlsaXR5IG9mIGludGVyd29ya2luZykuDQoNCldlYlJUQyBlbmRwb2ludCBpcyBz cGVjaWZpY2FsbHkgZGlmZmVyZW50IGZyb20gV2ViUlRDLWNvbXBhdGlibGUgZW5kcG9pbnQuIFdl YlJUQy1jb21wYXRpYmxlIGVuZHBvaW50cyBkbyBub3QgaGF2ZSB0byBpbXBsZW1lbnQgT1BVUyBv ciBDTi4gVGhleSBqdXN0IG5lZWQgdG8gaW50ZXJvcCB3aXRoIGZ1bGwgV2ViUlRDIGVuZHBvaW50 cy4NCg0KaXYtIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSByZXRyYW5zbWlzc2lvbiBnYXAgbGlt aXQgd291bGQgcmVxdWlyZSBSRkM0NzMzIHVwZGF0ZSB3aGVyZWFzIHRoZSBvdGhlciBsaW1pdHMg dW5kZXIgY29uc2lkZXJhdGlvbiBkb27igJl0Lg0KDQoNCkFzIEkgaGF2ZSBtZW50aW9uZWQgYWJv dmUsIHRoZXJlIGlzIGEgbG90IG1vcmUgdGhlbiBqdXN0IGZpbmFsIHBhY2tldCByZXRyYW5zbWlz c2lvbiBnYXAgd2hpY2ggaXMgbGVmdCB0byBiZSBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBpbiBS RkM0NzMzLiBJIGhhdmUgYSBmZWVsaW5nIHRoaXMgZ3JvdXAgaXMgdGlyZWQgb2YgRFRNRiBzbyBp ZiB5b3Ugd2FudCB0byBkaXNjdXNzIHRoaXMsIHdlIHNob3VsZCBkaXNjdXNzIHRoaXMgZWxzZXdo ZXJlIChhdnRjb3JlIG9yIGF2dGV4dCkuIFdoYXRldmVyIGlzIGRlY2lkZWQgdGhlcmUgd2lsbCBh ZmZlY3QgcnRjd2ViIGFzIHdlbGwgYXMgb3RoZXIgUkZDIDQ3MzMgaW1wbGVtZW50YXRpb25zLg0K DQpSZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0KDQo= --_000_SN1PR0301MB1551DEB5C6DF2628C885F988B2B30SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A74oCcV2ViUlRDIGVuZHBvaW50IGlzIHNwZWNpZmljYWxseSBkaWZmZXJlbnQgZnJvbSBX ZWJSVEMtY29tcGF0aWJsZSBlbmRwb2ludC4gV2ViUlRDLWNvbXBhdGlibGUgZW5kcG9pbnRzIGRv IG5vdCBoYXZlIHRvIGltcGxlbWVudCBPUFVTIG9yIENOLiBUaGV5IGp1c3QgbmVlZCB0byBpbnRl cm9wIHdpdGggZnVsbCBXZWJSVEMgZW5kcG9pbnRzLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QXMgdGhlIGJvdHRvbSBsaW5lLCB3b3VsZCBhIGdhdGV3YXkgbmVlZCB0 byBjb21wbHkgd2l0aCB0aGUgcmFuZ2UgcmVzdHJpY3Rpb25zIGZvciB0aGUgUkZDNDczMyBpdCBp cyBzZW5kaW5nIHRvd2FyZCB0aGUgV2ViUlRDIGxlZyBvciBub3Q/IEkgKjxiPnRoaW5rPC9iPiog d2hhdCB5b3Ugc2F5IGlzIHRoYXQgaXQgZG9lcyBub3QuIEkgc3Ryb25nbHkgd291bGQgcHJlZmVy IHRoYXQgdGhlIHRleHQgaXMgY2xlYXINCiBvbiB0aGlzIGlzc3VlLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ub2xn YTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFJvbWFuIFNocG91bnQgW21haWx0bzpyb21h bkB0ZWx1cml4LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1hcmNoIDA5LCAy MDE2IDEwOjUyIEFNPGJyPg0KPGI+VG86PC9iPiBBc3ZlcmVuLCBUb2xnYSAmbHQ7dGFzdmVyZW5A c29udXNuZXQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gVGVkIEhhcmRpZSAmbHQ7dGVkLmlldGZA Z21haWwuY29tJmd0OzsgSmVhbi1NYXJjIFZhbGluICZsdDtqbXZhbGluQG1vemlsbGEuY29tJmd0 OzsgQ3VsbGVuIEplbm5pbmdzICZsdDtmbHVmZnlAY2lzY28uY29tJmd0OzsgcnRjd2ViQGlldGYu b3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBEVE1GIHJlc29sdXRpb24gcHJv cG9zYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBNYXIgOSwgMjAxNiBhdCA0OjQ2IEFNLCBB c3ZlcmVuLCBUb2xnYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnRhc3ZlcmVuQHNvbnVzbmV0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5pLSBJIHBlcnNvbmFsbHkgd291bGQgcHJlZmVyIG5vdCB0byBsZWF2ZSBhIGdyZXkgYXJlYSAo YWZ0ZXIgYWxsLCB0aGUgZ2FwIGJldHdlZW4gcmV0cmFuc21pdHRlZCBlbmQtcGFja2V0cw0KIGlz IGFub3RoZXIgdmFsdWUsIHdoaWNoIG5lZWRzIHRvIGJlIGtub3duL2RldGVybWluZWQvcHJvdmlk ZWQpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBhcmUgYSBsb3Qgb2YgZ3JleSBh cmVhcyBpbiBob3cgUkZDIDQ3MzMgdG9uZXMgYXJlIGdlbmVyYXRlZCwgaW5jbHVkaW5nIGhvdyBv ZnRlbiB0b25lIHVwZGF0ZSBwYWNrZXRzIHNob3VsZCBiZSBzZW50IHdoZW4gdG9uZSBpcyBiZWlu ZyBwbGF5ZWQsIHNob3VsZCBhdWRpbyBzaWduYWwgYmUgc2VudCBkdXJpbmcgdG9uZSBnZW5lcmF0 aW9uLCBzaG91bGQgYXVkaW8gcGFja2V0cyBiZSBzZW50IGR1cmluZw0KIHRoZSB0b25lIGdlbmVy YXRpb24sIHNob3VsZCB0b25lIGR1cmF0aW9uIGFuZCBzdGFydCBiZSBleHRlbmRlZCB0byBhIHJl Z3VsYXIsIG5vbi10b25lIHBhY2tldCBib3VuZGFyeSwgd2hhdCBpbnRlcnZhbCBzaG91bGQgYmUg dXNlZCBmb3IgdGhlIGVuZCBvZiB0b25lIHBhY2tldC4gVGhpcyBncm91cCBpbmRpY2F0ZWQgdGhh dCBpdCBpcyBub3QgaW50ZXJlc3RlZCBpbiBkZWZpbmluZyBhbnkgb2YgdGhlc2UgdGhpbmdzIGFu ZCBJIHdvdWxkIHByZWZlcg0KIHRvIGtlZXAgdGhlc2UgdGhpbmdzIG91dCBydGN3ZWItYXVkaW8g ZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPklmIHlvdSB0aGluayAoSSBkZWZpbml0ZWx5IHRoaW5rIHNvKSwgdGhhdCBSRkMgNDczMyBj YW4gYmUgaW1wcm92ZWQgd2l0aCB0aGUgc2V0IG9mIHJlY29tbWVuZGF0aW9ucyBvbiBob3cgdG9u ZXMgc2hvdWxkIGJlIGdlbmVyYXRlZCwgdGhpcyBzaG91bGQgYmUgZGlzY3Vzc2VkIGluIGEgZGlm ZmVyZW50IGdyb3VwIChhdnRjb3JlIG9yIGF2dGV4dCkgYXMgZWl0aGVyIFJGQyA0NzMzIHVwZGF0 ZSBvciBhbiBpbmRlcGVuZGVudA0KIGluZm9ybWF0aW9uIGRyYWZ0LiBUaGlzIGluZm9ybWF0aW9u IHdvdWxkIG5vdCBiZSBydGN3ZWIgc3BlY2lmaWMgYW5kIG1vc3QgbGlrZWx5IGJlbmVmaXQgb3Ro ZXIgVm9JUCBpbXBsZW1lbnRhdGlvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5paS0gSSB3b3VsZG7igJl0IG1pbmQgaWYgdGhlIG1pbi12YWx1ZSBmb3IgcmV0 cmFuc21pc3Npb24gZ2FwIGlzIDEwbXMsIG9yIGV2ZW4gMG1zLCBhbmQgYWN0dWFsbHkgd291bGQN CiBwcmVmZXIgMG1zIGFzIGl0IGRvZXMgbm90IGltcG9zZSBhbnkgcmVzdHJpY3Rpb25zICh0aGlz IGFsbCBhc3N1bWluZyDigJN3aGljaCBJTUhPIGlzIG5vdCB0aGUgcmlnaHQgY2hvaWNlLSB0aGF0 IHRoZSBsaW1pdHMgd2lsbCBiZSBzcGVjaWZpZWQgaW4gcnRjd2ViLWF1ZGlvIGRyYWZ0IHJhdGhl ciB0aGFuIGluIFczQyBzcGVjaWZpY2F0aW9uKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBiZWxpZXZl IGFueXRoaW5nIG5ldHdvcmsgcHJvdG9jb2wgcmVsYXRlZCBzaG91bGQgYmUgc3BlY2lmaWVkIGlu IG9uZSBvZiB0aGUgSUVURiBncm91cHMuIElmIGl0IGlzIHJ0Y3dlYiBzcGVjaWZpYyBpdCBzaG91 bGQgZ28gaW50byBvbmUgb2YgdGhlIHJ0Y3dlYiBkcmFmdHMuIElmIGl0IGdlbmVyaWMgKGxpa2Ug YSBnZW5lcmFsIFJGQyA0NzMzIHVwZGF0ZSkgaXQgc2hvdWxkIGJlIGRvbmUgYnkgdGhlIGdyb3Vw DQogcmVzcG9uc2libGUgZm9yIHRoaXMgc3BlY2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmlpaS0gSXQgaXMgbm90IGNsZWFyIHRvIG1lIHdoZXRo ZXIgdGhlIHVzZSBvZiB0aGUgd29yZCDigJxXZWJSVEMgZW5kcG9pbnTigJ0gYnkgZGVmYXVsdCBj b3ZlcnMgZ2F0ZXdheXMNCiBhcyB3ZWxsLiBkcmFmdC1pZXRmLXJ0Y3dlYi1nYXRld2F5cy0wMiBo YXMgdGhlIGZvbGxvd2luZzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgQSBXZWJSVEMgZ2F0ZXdheSBhcHBlYXJzIGFz IGEgV2ViUlRDLWNvbXBhdGlibGUgZW5kcG9pbnQsIGFuZCB3aWxsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHRodXMg bm90IGJlIGNvbmZvcm1hbnQgd2l0aCBhbGwgcmVxdWlyZW1lbnRzIGZvciBhIFdlYlJUQyBlbmRw b2ludDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyAoaXQgZG9lcyBub3QgZG8gZXZlcnl0aGluZyBhIFdlYlJUQyBlbmRw b2ludCBkb2VzKSwgYnV0IGlzIGFibGUgdG88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaW50ZXJvcGVyYXRlIHdpdGgg V2ViUlRDIGVuZHBvaW50cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGludGVycHJldCB0aGlzIGFz IOKAnEFueXRoaW5nLCB3aGljaCBpcyBtYW5kYXRlZCBmb3Igd2VicnRjLWVuZHBvaW50cyBhbmQg bm90IGV4cGxpY2l0bHkgc3BlY2lmaWVkDQogYXMgbm90IGFwcGxpY2FibGUgZm9yIGdhdGV3YXlz IGluICZuYnNwO3J0Y3dlYi1nYXRld2F5IGRvY3VtZW50IGlzIGFwcGxpY2FibGUgZm9yIGdhdGV3 YXlzIHRvb+KAnSwgaW4gd2hpY2ggY2FzZSBJIHdvdWxkIHN1Z2dlc3QgYWRkaW5nIGEgc3RhdGVt ZW50IHRvIHJ0Y3dlYi1nYXRld2F5IGRvY3VtZW50IHRoYXQgUkZDNDczMyBsaW1pdHMgZG8gbm90 IGFwcGx5IHRvIGl0IChqdXN0IHRyeWluZyB0byBwcmV2ZW50IHRoZSBwb3NzaWJpbGl0eSBvZiBp bnRlcndvcmtpbmcpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2ViUlRDIGVuZHBvaW50IGlzIHNwZWNp ZmljYWxseSBkaWZmZXJlbnQgZnJvbSBXZWJSVEMtY29tcGF0aWJsZSBlbmRwb2ludC4gV2ViUlRD LWNvbXBhdGlibGUgZW5kcG9pbnRzIGRvIG5vdCBoYXZlIHRvIGltcGxlbWVudCBPUFVTIG9yIENO LiBUaGV5IGp1c3QgbmVlZCB0byBpbnRlcm9wIHdpdGggZnVsbCBXZWJSVEMgZW5kcG9pbnRzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+aXYtIEkgZG9u4oCZdCB1 bmRlcnN0YW5kIHdoeSByZXRyYW5zbWlzc2lvbiBnYXAgbGltaXQgd291bGQgcmVxdWlyZSBSRkM0 NzMzIHVwZGF0ZSB3aGVyZWFzIHRoZSBvdGhlcg0KIGxpbWl0cyB1bmRlciBjb25zaWRlcmF0aW9u IGRvbuKAmXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QXMgSSBoYXZlIG1lbnRpb25lZCBhYm92ZSwgdGhlcmUgaXMgYSBs b3QgbW9yZSB0aGVuIGp1c3QgZmluYWwgcGFja2V0IHJldHJhbnNtaXNzaW9uIGdhcCB3aGljaCBp cyBsZWZ0IHRvIGJlIGltcGxlbWVudGF0aW9uIHNwZWNpZmljIGluIFJGQzQ3MzMuIEkgaGF2ZSBh IGZlZWxpbmcgdGhpcyBncm91cCBpcyB0aXJlZCBvZiBEVE1GIHNvIGlmIHlvdSB3YW50IHRvIGRp c2N1c3MgdGhpcywgd2Ugc2hvdWxkIGRpc2N1c3MNCiB0aGlzIGVsc2V3aGVyZSAoYXZ0Y29yZSBv ciBhdnRleHQpLiBXaGF0ZXZlciBpcyBkZWNpZGVkIHRoZXJlIHdpbGwgYWZmZWN0IHJ0Y3dlYiBh cyB3ZWxsIGFzIG90aGVyIFJGQyA0NzMzIGltcGxlbWVudGF0aW9ucy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19f X19fX19fPGJyPg0KUm9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_SN1PR0301MB1551DEB5C6DF2628C885F988B2B30SN1PR0301MB1551_-- From nobody Wed Mar 9 08:25:40 2016 Return-Path: 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 6554D12D5DA for ; Wed, 9 Mar 2016 08:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFG9WJDfSy_Y for ; Wed, 9 Mar 2016 08:23:38 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB8912D6BC for ; Wed, 9 Mar 2016 08:21:23 -0800 (PST) Received: by mail-ig0-x233.google.com with SMTP id ig19so82734224igb.0 for ; Wed, 09 Mar 2016 08:21:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=n2udodZU3eGORgyOmO/ndp89Osp9jV/Ae7OWRvOIulo=; b=zCvajJ28hcnQyiUk8YYg+rqls0+rpOVR0a/quguYOCHN48iKGYSez/i+xVkAX8Fngb zfbTEWakA1qvz5CRK0pV7uNobLeLI9mxuQKNgb7/j60tXATbxzomIXIBHHyR8q5Fw4kw esUNh81HTvGUWAzlxdvvveNiikLaF1j+rvgK17k51sWO/f0dQYSoy7qdXVshP7aM/F8s XWRvy8E4AvV51gPLSWXFXVfDr7Tx6Mz2rRIa+AtniyQBhpPpXyuoPVPXoTnUn6BDWy51 Xl3H8pBhsr1qtYuty4NA+PDews2a5wFAfydfVYWPO8CondERVJAVgaHxLxo3crwkP0xF KStQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=n2udodZU3eGORgyOmO/ndp89Osp9jV/Ae7OWRvOIulo=; b=bStA3ygMbq/PxNK0E27I+h/H+gwFQk9GbCPgpeyjdaXmclAEnJ4Bc2LKInOqrVYs4V uKERT/iGELSJdsLPWdCWg4pAB2UIpCmV8hQUUeYr/ugBspTY7QU2hcBkdq0e5y6ExGFx RQ0Puua63UP3kfKUg8J/sjTjKxwf82aRUs1Nss6qWRS9payIP9dSmmHCseLq3av+j3GW ExJGSSQk2HpPG0RuVaGvB/jDqUVWJZbEyOxx+19HpVryx8euO8lJvTvHVEC/rVeml2+w 7ykXtZx0w+/gBaPmwYu96REPvgx9MGLnDCm7eZ8oll+zDuKCkfXeOR9RQQUjq4kTuSKM HZlQ== X-Gm-Message-State: AD7BkJIzDIgE06j1CbrERaBkscZwJ1js8xBm1Q6zOC/2SCa68zgMivo675ToUN35YOjqQw== X-Received: by 10.50.155.107 with SMTP id vv11mr14552655igb.82.1457540483135; Wed, 09 Mar 2016 08:21:23 -0800 (PST) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com. [209.85.223.171]) by smtp.gmail.com with ESMTPSA id w184sm3329291iod.4.2016.03.09.08.21.21 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Mar 2016 08:21:21 -0800 (PST) Received: by mail-io0-f171.google.com with SMTP id z76so71804886iof.3 for ; Wed, 09 Mar 2016 08:21:21 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.30.71 with SMTP id e68mr33203961ioe.145.1457540481292; Wed, 09 Mar 2016 08:21:21 -0800 (PST) Received: by 10.36.106.194 with HTTP; Wed, 9 Mar 2016 08:21:21 -0800 (PST) In-Reply-To: References: <56DDF13F.1050505@mozilla.com> Date: Wed, 9 Mar 2016 11:21:21 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a1140d71ea24b66052da016cc Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] DTMF resolution proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 16:23:40 -0000 --001a1140d71ea24b66052da016cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 9, 2016 at 11:09 AM, Asveren, Tolga wrote: > =E2=80=9CWebRTC endpoint is specifically different from WebRTC-compatibl= e > endpoint. WebRTC-compatible endpoints do not have to implement OPUS or CN= . > They just need to interop with full WebRTC endpoints.=E2=80=9D > > As the bottom line, would a gateway need to comply with the range > restrictions for the RFC4733 it is sending toward the WebRTC leg or not? = I * > *think** what you say is that it does not. I strongly would prefer that > the text is clear on this issue. > > > WebRTC endpoints, such as browsers, will not do anything with RFC 4733 tones sent from the gateway, except gracefully drop them. There is currently no API to inform JavaScript about the received DTMF or other RFC 4733 tones. Do you want the language added to the specification that WebRTC endpoint should be able to receive any RFC 4733 tones and process them in a graceful manner? I think I have previously proposed the following: Receivers MUST be able to consume any audio/telephone-event events in such a way that it will not generate audio artifacts, jitter buffer adjustments, payload mismatches, or invalid RTCP statistics calculation. Receivers MAY generate audio corresponding to the received events but are also allowed to discard them in a manner that does not affect regular audio processing. This language was dropped as obvious, but can be included if you think is necessary and no one objects. Regards, _____________ Roman Shpount --001a1140d71ea24b66052da016cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 9, 2016 a= t 11:09 AM, Asveren, Tolga <tasveren@sonusnet.com> wrote= :

=C2=A0=E2=80=9CWebRTC endpoint is specifically diffe= rent from WebRTC-compatible endpoint. WebRTC-compatible endpoints do not ha= ve to implement OPUS or CN. They just need to interop with full WebRTC endp= oints.=E2=80=9D

As the bottom line, would a gateway need to comply w= ith the range restrictions for the RFC4733 it is sending toward the WebRTC = leg or not? I *think* what you say is that it does not. I strongly w= ould prefer that the text is clear on this issue.



WebRTC endpoints, such as browsers, will not do anything with RFC 4733 ton= es sent from the gateway, except gracefully drop them. There is currently n= o API to inform JavaScript about the received DTMF or other RFC 4733 tones.=

Do you want the language added to the specificati= on that WebRTC endpoint should be able to receive any RFC 4733 tones and pr= ocess them in a graceful manner?

I think I have pr= eviously proposed the following:

Receivers MUST be able= to consume any audio/telephone-event events
in such a way that it will = not generate audio artifacts, jitter buffer
adjustments, payload mismatc= hes, or invalid RTCP statistics calculation.
Receivers MAY generate audi= o corresponding to the received events
but are also allowed to discard = them in a manner that does not affect
regular audio processing.

This language= was dropped as obvious, but can be included if you think is necessary and = no one objects.

Regards,
_____________
Roman Shpount
<= div>=C2=A0
--001a1140d71ea24b66052da016cc-- From nobody Wed Mar 9 08:55:20 2016 Return-Path: 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 2734A12DFE5 for ; Wed, 9 Mar 2016 08:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wu8kfUaswvQd for ; Wed, 9 Mar 2016 08:52:34 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0085.outbound.protection.outlook.com [207.46.100.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1BAA12DFE3 for ; Wed, 9 Mar 2016 08:52:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cDIndCy0Fhgl1En3tunBKA3LI/jGQyuY4NHUg/2PG9g=; b=okm+8Dw6Anfb/U64x3X+ZZx0RhRJhN9woYQOGQhmyAdnaSJd6MAyNGo5uQJtdN3KGdfV/daScrNCC2i8OBii22+Z7jcQwfaTwhPQUjaU9Y/cElPsLr7WxkXBoE2HLHwJ2XSWwoGf3BsY85GhiytZdDnLyV7m4FeYfxUbf1ALcdI= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1552.namprd03.prod.outlook.com (10.162.129.158) with Microsoft SMTP Server (TLS) id 15.1.427.16; Wed, 9 Mar 2016 16:52:00 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0427.019; Wed, 9 Mar 2016 16:52:00 +0000 From: "Asveren, Tolga" To: Roman Shpount Thread-Topic: [rtcweb] DTMF resolution proposal Thread-Index: AQHReLEGZXQ6ENs53U20okwQmfoJbJ9OfbeAgAAPmQCAAJd7oIABJwEAgACO1FCAAGtNgIAABBtggAAEBICAAAcksA== Date: Wed, 9 Mar 2016 16:52:00 +0000 Message-ID: References: <56DDF13F.1050505@mozilla.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: telurix.com; dkim=none (message not signed) header.d=none;telurix.com; dmarc=none action=none header.from=sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 4415b93e-7b37-4eb9-3025-08d3483b2234 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1552; 5:FLEOFzzOfXyvjY0hKv4v3c/wZ3hxMVY4qefAHF8pNWl23W+dcmkAsq8/o6MHLlQWp1ablataDtD+OqDiFY3wJm4bB8nohhL9kKas9DdB2eCyC2KFdkoMLTa/lh+pbiw2S5+tZobMFJApCQEfhl1zxQ==; 24:D85udZot1kifzr2yGyzAv919Lt1pwiC/POMMWMi9sA7PmmgwjsGqkCW2bo0BpifsNaD4nrFfUYkvBv/Cud2wX0zKoDs28x40Loy22cx6epk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1552; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:SN1PR0301MB1552; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1552; x-forefront-prvs: 0876988AF0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(24454002)(164054003)(377454003)(2900100001)(189998001)(5004730100002)(110136002)(2950100001)(11100500001)(93886004)(1220700001)(10400500002)(74316001)(1096002)(92566002)(3846002)(76576001)(5008740100001)(66066001)(3280700002)(102836003)(81166005)(86362001)(19300405004)(122556002)(19609705001)(19580395003)(6116002)(16236675004)(561944003)(19625215002)(15975445007)(106116001)(5002640100001)(87936001)(4326007)(2906002)(76176999)(54356999)(790700001)(586003)(50986999)(33656002)(19580405001)(5003600100002)(77096005)(99286002)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1552; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB1551A43DA65C4F50DA832500B2B30SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2016 16:52:00.2237 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1552 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] DTMF resolution proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 16:52:40 -0000 --_000_SN1PR0301MB1551A43DA65C4F50DA832500B2B30SN1PR0301MB1551_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCcV2ViUlRDIGVuZHBvaW50cywgc3VjaCBhcyBicm93c2Vycywgd2lsbCBub3QgZG8gYW55dGhp bmcgd2l0aCBSRkMgNDczMyB0b25lcyBzZW50IGZyb20gdGhlIGdhdGV3YXksIGV4Y2VwdCBncmFj ZWZ1bGx5IGRyb3AgdGhlbS4gVGhlcmUgaXMgY3VycmVudGx5IG5vIEFQSSB0byBpbmZvcm0gSmF2 YVNjcmlwdCBhYm91dCB0aGUgcmVjZWl2ZWQgRFRNRiBvciBvdGhlciBSRkMgNDczMyB0b25lcy4N Cg0KRG8geW91IHdhbnQgdGhlIGxhbmd1YWdlIGFkZGVkIHRvIHRoZSBzcGVjaWZpY2F0aW9uIHRo YXQgV2ViUlRDIGVuZHBvaW50IHNob3VsZCBiZSBhYmxlIHRvIHJlY2VpdmUgYW55IFJGQyA0NzMz IHRvbmVzIGFuZCBwcm9jZXNzIHRoZW0gaW4gYSBncmFjZWZ1bCBtYW5uZXI/4oCdDQoNClRoaXMg c291bmRzIHN0cmFuZ2UgdG8gbWUgKHVzaW5nIGRpZ2l0cyB1bmlkaXJlY3Rpb25hbGx5KSBidXQg SSB3b3VsZCB0aGluayB0aGF0IGJyb3dzZXIgdmVuZG9ycyBzaG91bGQgd2VpZ2ggaW4gb24gdGhp cyBvbmUuIEZvciBtZSwgdGhlIHByYWN0aWNhbGx5IGltcG9ydGFudCBwb2ludCBpcyB0aGF0IGdh dGV3YXkgY2FuIHNlbmQgUkZDNDczMyBkaWdpdHMgdG93YXJkIHRoZSBicm93c2VyL25hdGl2ZSBX ZWJSVEMgYXBwIHdpdGhvdXQgYmVpbmcgcmVzdHJpY3RlZCBieSB0aGUgZGVmaW5lZCByYW5nZS4g VGhlcmUgd291bGRu4oCZdCBiZSBhbnkgaXNzdWUgZnJvbSBteSBwZXJzcGVjdGl2ZSBpZiBicm93 c2VycyBhcmUgYW55aG93IGdvaW5nIHRvIGRyb3AgdGhlIGRpZ2l0cyAoSSBhc3N1bWUgdGhpcyB3 b3VsZCBiZSB0aGUgc2FtZSBmb3IgbmF0aXZlIFdlYlJUQyBhcHBsaWNhdGlvbikgYnV0ICppZiog dGhpbmdzIGNoYW5nZSBzbyB0aGF0IHRoZXkgbWF5IHByb2Nlc3MgdGhlbSwgdGhlbiBJIHdvdWxk IHByZWZlciB0aGUgdGV4dCB0byBiZSBjbGVhciB0aGF0IHRoZSByYW5nZSByZXN0cmljdGlvbiBk b2VzIG5vdCBhcHBseSBmb3IgZGlnaXRzIGZyb20gYSBnYXRld2F5IHRvd2FyZCB0aGUgYnJvd3Nl ci9uYXRpdmUgYXBwLg0KDQpUaGFua3MsDQpUb2xnYQ0KDQoNCkZyb206IFJvbWFuIFNocG91bnQg W21haWx0bzpyb21hbkB0ZWx1cml4LmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMDksIDIw MTYgMTE6MjEgQU0NClRvOiBBc3ZlcmVuLCBUb2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPg0K Q2M6IFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdtYWlsLmNvbT47IEplYW4tTWFyYyBWYWxpbiA8am12 YWxpbkBtb3ppbGxhLmNvbT47IEN1bGxlbiBKZW5uaW5ncyA8Zmx1ZmZ5QGNpc2NvLmNvbT47IHJ0 Y3dlYkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtydGN3ZWJdIERUTUYgcmVzb2x1dGlvbiBwcm9w b3NhbA0KDQpPbiBXZWQsIE1hciA5LCAyMDE2IGF0IDExOjA5IEFNLCBBc3ZlcmVuLCBUb2xnYSA8 dGFzdmVyZW5Ac29udXNuZXQuY29tPG1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20+PiB3cm90 ZToNCiDigJxXZWJSVEMgZW5kcG9pbnQgaXMgc3BlY2lmaWNhbGx5IGRpZmZlcmVudCBmcm9tIFdl YlJUQy1jb21wYXRpYmxlIGVuZHBvaW50LiBXZWJSVEMtY29tcGF0aWJsZSBlbmRwb2ludHMgZG8g bm90IGhhdmUgdG8gaW1wbGVtZW50IE9QVVMgb3IgQ04uIFRoZXkganVzdCBuZWVkIHRvIGludGVy b3Agd2l0aCBmdWxsIFdlYlJUQyBlbmRwb2ludHMu4oCdDQpBcyB0aGUgYm90dG9tIGxpbmUsIHdv dWxkIGEgZ2F0ZXdheSBuZWVkIHRvIGNvbXBseSB3aXRoIHRoZSByYW5nZSByZXN0cmljdGlvbnMg Zm9yIHRoZSBSRkM0NzMzIGl0IGlzIHNlbmRpbmcgdG93YXJkIHRoZSBXZWJSVEMgbGVnIG9yIG5v dD8gSSAqdGhpbmsqIHdoYXQgeW91IHNheSBpcyB0aGF0IGl0IGRvZXMgbm90LiBJIHN0cm9uZ2x5 IHdvdWxkIHByZWZlciB0aGF0IHRoZSB0ZXh0IGlzIGNsZWFyIG9uIHRoaXMgaXNzdWUuDQoNCg0K V2ViUlRDIGVuZHBvaW50cywgc3VjaCBhcyBicm93c2Vycywgd2lsbCBub3QgZG8gYW55dGhpbmcg d2l0aCBSRkMgNDczMyB0b25lcyBzZW50IGZyb20gdGhlIGdhdGV3YXksIGV4Y2VwdCBncmFjZWZ1 bGx5IGRyb3AgdGhlbS4gVGhlcmUgaXMgY3VycmVudGx5IG5vIEFQSSB0byBpbmZvcm0gSmF2YVNj cmlwdCBhYm91dCB0aGUgcmVjZWl2ZWQgRFRNRiBvciBvdGhlciBSRkMgNDczMyB0b25lcy4NCg0K RG8geW91IHdhbnQgdGhlIGxhbmd1YWdlIGFkZGVkIHRvIHRoZSBzcGVjaWZpY2F0aW9uIHRoYXQg V2ViUlRDIGVuZHBvaW50IHNob3VsZCBiZSBhYmxlIHRvIHJlY2VpdmUgYW55IFJGQyA0NzMzIHRv bmVzIGFuZCBwcm9jZXNzIHRoZW0gaW4gYSBncmFjZWZ1bCBtYW5uZXI/DQoNCkkgdGhpbmsgSSBo YXZlIHByZXZpb3VzbHkgcHJvcG9zZWQgdGhlIGZvbGxvd2luZzoNCg0KUmVjZWl2ZXJzIE1VU1Qg YmUgYWJsZSB0byBjb25zdW1lIGFueSBhdWRpby90ZWxlcGhvbmUtZXZlbnQgZXZlbnRzDQppbiBz dWNoIGEgd2F5IHRoYXQgaXQgd2lsbCBub3QgZ2VuZXJhdGUgYXVkaW8gYXJ0aWZhY3RzLCBqaXR0 ZXIgYnVmZmVyDQphZGp1c3RtZW50cywgcGF5bG9hZCBtaXNtYXRjaGVzLCBvciBpbnZhbGlkIFJU Q1Agc3RhdGlzdGljcyBjYWxjdWxhdGlvbi4NClJlY2VpdmVycyBNQVkgZ2VuZXJhdGUgYXVkaW8g Y29ycmVzcG9uZGluZyB0byB0aGUgcmVjZWl2ZWQgZXZlbnRzDQpidXQgYXJlIGFsc28gYWxsb3dl ZCB0byBkaXNjYXJkIHRoZW0gaW4gYSBtYW5uZXIgdGhhdCBkb2VzIG5vdCBhZmZlY3QNCnJlZ3Vs YXIgYXVkaW8gcHJvY2Vzc2luZy4NCg0KVGhpcyBsYW5ndWFnZSB3YXMgZHJvcHBlZCBhcyBvYnZp b3VzLCBidXQgY2FuIGJlIGluY2x1ZGVkIGlmIHlvdSB0aGluayBpcyBuZWNlc3NhcnkgYW5kIG5v IG9uZSBvYmplY3RzLg0KDQpSZWdhcmRzLA0KX19fX19fX19fX19fXw0KUm9tYW4gU2hwb3VudA0K DQo= --_000_SN1PR0301MB1551A43DA65C4F50DA832500B2B30SN1PR0301MB1551_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJxXZWJSVEMgZW5kcG9pbnRz LCBzdWNoIGFzIGJyb3dzZXJzLCB3aWxsIG5vdCBkbyBhbnl0aGluZyB3aXRoIFJGQyA0NzMzIHRv bmVzIHNlbnQgZnJvbSB0aGUgZ2F0ZXdheSwgZXhjZXB0IGdyYWNlZnVsbHkgZHJvcCB0aGVtLiBU aGVyZSBpcyBjdXJyZW50bHkgbm8gQVBJIHRvIGluZm9ybSBKYXZhU2NyaXB0IGFib3V0IHRoZSBy ZWNlaXZlZCBEVE1GIG9yIG90aGVyIFJGQyA0NzMzIHRvbmVzLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5EbyB5b3Ugd2FudCB0aGUgbGFuZ3VhZ2UgYWRkZWQgdG8gdGhlIHNwZWNpZmljYXRpb24g dGhhdCBXZWJSVEMgZW5kcG9pbnQgc2hvdWxkIGJlIGFibGUgdG8gcmVjZWl2ZSBhbnkgUkZDIDQ3 MzMgdG9uZXMgYW5kIHByb2Nlc3MgdGhlbSBpbiBhIGdyYWNlZnVsIG1hbm5lcj/igJ08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBzb3VuZHMgc3RyYW5nZSB0byBtZSAodXNpbmcgZGlnaXRz IHVuaWRpcmVjdGlvbmFsbHkpIGJ1dCBJIHdvdWxkIHRoaW5rIHRoYXQgYnJvd3NlciB2ZW5kb3Jz IHNob3VsZCB3ZWlnaCBpbiBvbiB0aGlzIG9uZS4gRm9yIG1lLCB0aGUgcHJhY3RpY2FsbHkgaW1w b3J0YW50IHBvaW50IGlzIHRoYXQgZ2F0ZXdheSBjYW4gc2VuZCBSRkM0NzMzIGRpZ2l0cyB0b3dh cmQgdGhlIGJyb3dzZXIvbmF0aXZlIFdlYlJUQw0KIGFwcCB3aXRob3V0IGJlaW5nIHJlc3RyaWN0 ZWQgYnkgdGhlIGRlZmluZWQgcmFuZ2UuIFRoZXJlIHdvdWxkbuKAmXQgYmUgYW55IGlzc3VlIGZy b20gbXkgcGVyc3BlY3RpdmUgaWYgYnJvd3NlcnMgYXJlIGFueWhvdyBnb2luZyB0byBkcm9wIHRo ZSBkaWdpdHMgKEkgYXNzdW1lIHRoaXMgd291bGQgYmUgdGhlIHNhbWUgZm9yIG5hdGl2ZSBXZWJS VEMgYXBwbGljYXRpb24pIGJ1dCAqPGI+aWY8L2I+KiB0aGluZ3MgY2hhbmdlIHNvIHRoYXQgdGhl eSBtYXkNCiBwcm9jZXNzIHRoZW0sIHRoZW4gSSB3b3VsZCBwcmVmZXIgdGhlIHRleHQgdG8gYmUg Y2xlYXIgdGhhdCB0aGUgcmFuZ2UgcmVzdHJpY3Rpb24gZG9lcyBub3QgYXBwbHkgZm9yIGRpZ2l0 cyBmcm9tIGEgZ2F0ZXdheSB0b3dhcmQgdGhlIGJyb3dzZXIvbmF0aXZlIGFwcC48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VG9sZ2E8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBSb21hbiBTaHBvdW50IFttYWls dG86cm9tYW5AdGVsdXJpeC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXJj aCAwOSwgMjAxNiAxMToyMSBBTTxicj4NCjxiPlRvOjwvYj4gQXN2ZXJlbiwgVG9sZ2EgJmx0O3Rh c3ZlcmVuQHNvbnVzbmV0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFRlZCBIYXJkaWUgJmx0O3Rl ZC5pZXRmQGdtYWlsLmNvbSZndDs7IEplYW4tTWFyYyBWYWxpbiAmbHQ7am12YWxpbkBtb3ppbGxh LmNvbSZndDs7IEN1bGxlbiBKZW5uaW5ncyAmbHQ7Zmx1ZmZ5QGNpc2NvLmNvbSZndDs7IHJ0Y3dl YkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gRFRNRiByZXNvbHV0 aW9uIHByb3Bvc2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgTWFyIDksIDIwMTYgYXQgMTE6 MDkgQU0sIEFzdmVyZW4sIFRvbGdhICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5Ac29udXNu ZXQuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGFzdmVyZW5Ac29udXNuZXQuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A74oCcV2ViUlRDIGVuZHBv aW50IGlzIHNwZWNpZmljYWxseSBkaWZmZXJlbnQgZnJvbSBXZWJSVEMtY29tcGF0aWJsZSBlbmRw b2ludC4gV2ViUlRDLWNvbXBhdGlibGUgZW5kcG9pbnRzIGRvIG5vdCBoYXZlIHRvIGltcGxlbWVu dCBPUFVTIG9yIENOLiBUaGV5IGp1c3QgbmVlZCB0byBpbnRlcm9wIHdpdGggZnVsbA0KIFdlYlJU QyBlbmRwb2ludHMu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFz IHRoZSBib3R0b20gbGluZSwgd291bGQgYSBnYXRld2F5IG5lZWQgdG8gY29tcGx5IHdpdGggdGhl IHJhbmdlIHJlc3RyaWN0aW9ucyBmb3IgdGhlIFJGQzQ3MzMgaXQgaXMgc2VuZGluZyB0b3dhcmQg dGhlIFdlYlJUQyBsZWcgb3Igbm90PyBJICo8Yj50aGluazwvYj4qIHdoYXQgeW91IHNheSBpcyB0 aGF0DQogaXQgZG9lcyBub3QuIEkgc3Ryb25nbHkgd291bGQgcHJlZmVyIHRoYXQgdGhlIHRleHQg aXMgY2xlYXIgb24gdGhpcyBpc3N1ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2ViUlRDIGVuZHBvaW50cywgc3VjaCBh cyBicm93c2Vycywgd2lsbCBub3QgZG8gYW55dGhpbmcgd2l0aCBSRkMgNDczMyB0b25lcyBzZW50 IGZyb20gdGhlIGdhdGV3YXksIGV4Y2VwdCBncmFjZWZ1bGx5IGRyb3AgdGhlbS4gVGhlcmUgaXMg Y3VycmVudGx5IG5vIEFQSSB0byBpbmZvcm0gSmF2YVNjcmlwdCBhYm91dCB0aGUgcmVjZWl2ZWQg RFRNRiBvciBvdGhlciBSRkMgNDczMyB0b25lcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG8geW91IHdhbnQgdGhlIGxhbmd1YWdlIGFkZGVk IHRvIHRoZSBzcGVjaWZpY2F0aW9uIHRoYXQgV2ViUlRDIGVuZHBvaW50IHNob3VsZCBiZSBhYmxl IHRvIHJlY2VpdmUgYW55IFJGQyA0NzMzIHRvbmVzIGFuZCBwcm9jZXNzIHRoZW0gaW4gYSBncmFj ZWZ1bCBtYW5uZXI/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgdGhpbmsgSSBoYXZlIHByZXZpb3VzbHkgcHJvcG9zZWQgdGhlIGZvbGxvd2lu Zzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWNlaXZl cnMgTVVTVCBiZSBhYmxlIHRvIGNvbnN1bWUgYW55IGF1ZGlvL3RlbGVwaG9uZS1ldmVudCBldmVu dHM8YnI+DQppbiBzdWNoIGEgd2F5IHRoYXQgaXQgd2lsbCBub3QgZ2VuZXJhdGUgYXVkaW8gYXJ0 aWZhY3RzLCBqaXR0ZXIgYnVmZmVyPGJyPg0KYWRqdXN0bWVudHMsIHBheWxvYWQgbWlzbWF0Y2hl cywgb3IgaW52YWxpZCBSVENQIHN0YXRpc3RpY3MgY2FsY3VsYXRpb24uPGJyPg0KUmVjZWl2ZXJz IE1BWSBnZW5lcmF0ZSBhdWRpbyBjb3JyZXNwb25kaW5nIHRvIHRoZSByZWNlaXZlZCBldmVudHMg PGJyPg0KYnV0IGFyZSBhbHNvIGFsbG93ZWQgdG8gZGlzY2FyZCB0aGVtIGluIGEgbWFubmVyIHRo YXQgZG9lcyBub3QgYWZmZWN0IDxicj4NCnJlZ3VsYXIgYXVkaW8gcHJvY2Vzc2luZy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBsYW5n dWFnZSB3YXMgZHJvcHBlZCBhcyBvYnZpb3VzLCBidXQgY2FuIGJlIGluY2x1ZGVkIGlmIHlvdSB0 aGluayBpcyBuZWNlc3NhcnkgYW5kIG5vIG9uZSBvYmplY3RzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPGJyPg0K Um9tYW4gU2hwb3VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN1PR0301MB1551A43DA65C4F50DA832500B2B30SN1PR0301MB1551_-- From nobody Wed Mar 9 09:48:16 2016 Return-Path: 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 21DAA12D873 for ; Wed, 9 Mar 2016 09:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gkiRipq4jFU for ; Wed, 9 Mar 2016 09:48:12 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B8112D86D for ; Wed, 9 Mar 2016 09:48:04 -0800 (PST) Received: by mail-ob0-x22f.google.com with SMTP id ts10so54656956obc.1 for ; Wed, 09 Mar 2016 09:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6rqAXKCZ9ePxij/QkvUQoDoCq9jl/x/JaaNFEhPbDJw=; b=jxDtU0BdxxauP0cUf8EkdVtJ9MqHk2x7rBtjRIUfipofNt63HWKN0lpAS9QeKlwX7U jAh+ibNb/PvBrcYDrRiCC614Ot89NSgHvtphlFk7bWCpkD4AFjMAFvAxaMwJOk/NdOzg gEMVTJB8Ozgt7H8zTtF6vjqHmmLBQ9DKerbLwhEKbP7oUWszZytB88Qv5kXOyjGisMJH AY4CnBORgtpFBGY0tSN+LjAid4UNEcXaMzF04RXU9Vvk2OAJVwxBFgYbKpmRpFZ8I6YO Zj9PuDOgYqufaUuhmS4KczIZO+9qzFoXg5ijdX6VWHXFl4ZLCp6RuKM4X1K+jGNgdchj PdEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6rqAXKCZ9ePxij/QkvUQoDoCq9jl/x/JaaNFEhPbDJw=; b=bCOKPEtdlHfoQ2uwMoQy424Z80zW3aHANu5MzPqsbzbWqDakcEsDRao7xJ0ep5msRD sT3/gm4fXcOEXf1AR4XMg4Cphtdsi7UT/eDwsRrbE4YAyqsQBFbZ5BGGpS49nu9wZfbg U6TL66FZ+Yp/e40nJSKftITBbfp6jtnXBouFYsQqa83eWKZHWOP+9LJKeD+IV6ccxATN gKe5hItDZyZGcRDEVdGLOa5xxh2Zn5t9CqPILPTmFAUV4tfd/2RRJr/jcIuXIK6jEN6+ 2Hd29q/zlqw1zXop+aD/xjTUY+z14WTPoMrpRs2wbQLNI2OkdWMz/gmzMod0R0vSIEPe PdpQ== X-Gm-Message-State: AD7BkJKnC5P6nsM6008rjRriGgf6mzkfI29vyqXTnfz5HURqbw6Mv1WQYXr/6OBnlV3eqjfjQASWYywQEwMfFw== X-Received: by 10.60.38.37 with SMTP id d5mr21983895oek.50.1457545683838; Wed, 09 Mar 2016 09:48:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.51.6 with HTTP; Wed, 9 Mar 2016 09:47:44 -0800 (PST) In-Reply-To: <56DF7C6B.4050400@mozilla.com> References: <56DDF13F.1050505@mozilla.com> <56DF7C6B.4050400@mozilla.com> From: Ted Hardie Date: Wed, 9 Mar 2016 09:47:44 -0800 Message-ID: To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=089e013a1ee2baac05052da14c42 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] DTMF resolution proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 17:48:15 -0000 --089e013a1ee2baac05052da14c42 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 8, 2016 at 5:29 PM, Jean-Marc Valin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I'm not going to make a big deal out of this, but it feels to me like > the default duration should be in the W3C doc rather than in the IETF > doc since it describes browser behaviour rather than something can can > be observed on the wire. Of course, it doesn't hurt either, so I won't > object if people disagree with me. > > They should definitely be aligned, if included. (Insert your favorite "Why not both?" meme here). Ted > Cheers, > > Jean-Marc > > On 03/08/2016 07:57 PM, Roman Shpount wrote: > > Unless someone objects, I think the language would be: > > > > WebRTC endpoints generated events MUST have duration of no more > > than 8000 ms and no less than 40 ms with the recommended default > > duration of 100 ms for each tone. The gap between events MUST be no > > less then 30 ms with the recommended default duration of 70 ms. > > > > WebRTC endpoints limits this language to browsers and removes this > > requirements from the gateways. > > > > I do not think we should add any language about retransmission of > > the final packets since this will cause another unnecessary debate > > (for instance I think the value of 20 ms is wrong and it should be > > much shorter). If you want to change this please write an update > > draft for RFC 4733 and we can discuss it there. > > > > Regards, _____________ Roman Shpount > > > > On Tue, Mar 8, 2016 at 2:24 AM, Asveren, Tolga > > > wrote: > > > > Would the text be crafted so that it pertains **only** to the > > RFC4733 digit packets emitted by a browser? ____ > > > > __ __ > > > > Information about gap between retransmission of the final packet > > could be useful as well and I suggest 20ms for that one.____ > > > > __ __ > > > > Thanks,____ > > > > Tolga____ > > > > __ __ > > > > *From:*rtcweb [mailto:rtcweb-bounces@ietf.org > > ] *On Behalf Of *Ted Hardie *Sent:* > > Monday, March 07, 2016 5:19 PM *To:* Jean-Marc Valin > > > *Cc:* Cullen > > Jennings >; > > rtcweb@ietf.org *Subject:* Re: [rtcweb] > > DTMF resolution proposal____ > > > > __ __ > > > > On Mon, Mar 7, 2016 at 1:23 PM, Jean-Marc Valin > > > wrote:____ > > > > As proposed by Roman, I think we should also include the "minimum > > gap of 30 ms". Otherwise, I support the proposal.____ > > > >> __ __ > > > >> Thank you Jean-Marc; I had not thought to include that in my > >> note, but I agree.____ > > > >> regards,____ > > > >> Ted____ > > > > > >> ____ > > > > Jean-Marc____ > > > > > > On 03/07/2016 03:35 PM, Ted Hardie wrote: > >> We've had about 60 or so messages on this topic, and the rough > >> consensus seems to be align this document with the limits set > >> out in the W3C work here: > > > >> https://www.w3.org/TR/webrtc/#rtcdtmfsender > > > >> However, there was also a proposal to slightly modify those > > limits. > >> They are currently: > > > >> "The duration cannot be more than 6000 ms or less than 40 ms. > >> The default duration is 100 ms for each tone." > > > >> Based on Roman's note, a minimum of 40ms and a maximum 8000 ms > >> to align with the ITU and RFC2833. > > > >> To resolve this, I propose that we ask the WebRTC group to raise > >> their max to 8000 and, on receiving a positive response, publish > >> this document with 40/8000 as the min and max. If they give a > >> negative response, we retain 40/6000. This values alignment > >> between the two documents higher than the reference 2833, but > >> that seems sensible in this context. > > > >> If you have an objection to this way forward, please send your > >> reasoning to the list by March 14th. > > > >> thanks, > > > >> Ted > > > > > >> ____ > > > >> _______________________________________________ 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 > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQEcBAEBCAAGBQJW33xoAAoJEJ6/8sItn9q9agEIAIDvDjcyiWb1jrDPRiPmY2z0 > uOtzfmdg7FurvbEM4uIn5S30DrbB1i5ncl2xTmM24/jIHKAVtr/pXbMt5jH5a/F8 > XMQs5zkgK7w1tP/EykJ3f2ti5pWc18Lia8rYMzKdm0GEwcUQMemUCZ+7WrqT0N3p > BHYPZY8B4qR/7TK+AquxcWUUZsQdPi3LaGcJwJF9+KwRKuXAQcEphUVs2SnF48+F > IMFlhRyT097gaz5lOFS36AeyS8SO1So8W1Y2hwGMIjmuHJAMJm4vN4E8JO4R49MF > gsvqeYimx8YZtxJww02aBN/gauUwdecol5N6xXk3haWTgdgvBJjfWzRIOsSluVo= > =WJ2n > -----END PGP SIGNATURE----- > --089e013a1ee2baac05052da14c42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 8, 2016 at 5:29 PM, Jean-Marc Valin <jmval= in@mozilla.com> wrote:
-----BEG= IN PGP SIGNED MESSAGE-----
Hash: SHA256

I'm not going to make a big deal out of this, but it feels to me= like
the default duration should be in the W3C doc rather than in the IETF
doc since it describes browser behaviour rather than something can can
be observed on the wire. Of course, it doesn't hurt either, so I won= 9;t
object if people disagree with me.

They should definitely be aligned, if included.=C2=A0= (Insert your favorite "Why not both?" meme here).
=
Ted
=C2=A0
Cheers,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Jean-Marc

On 03/08/2016 07:57 PM, Roman Shpount wrote:
> Unless someone objects, I think the language would be:
>
> WebRTC endpoints generated events MUST have duration of no more
> than 8000 ms and no less than 40 ms with the recommended default
> duration of 100 ms for each tone. The gap between events MUST be no > less then 30 ms with the recommended default duration of 70 ms.
>
> WebRTC endpoints limits this language to browsers and removes this
> requirements from the gateways.
>
> I do not think we should add any language about retransmission of
> the final packets since this will cause another unnecessary debate
> (for instance I think the value of 20 ms is wrong and it should be
> much shorter). If you want to change this please write an update
> draft for RFC 4733 and we can discuss it there.
>
> Regards, _____________ Roman Shpount
>
> On Tue, Mar 8, 2016 at 2:24 AM, Asveren, Tolga
> <tasveren@sonusnet.= com <mailto:tasveren@sonusn= et.com>> wrote:
>
> Would the text be crafted so that it pertains **only** to the
> RFC4733 digit packets emitted by a browser? ____
>
> __ __
>
> Information about gap between retransmission of the final packet
> could be useful as well and I suggest 20ms for that one.____ >
> __ __
>
> Thanks,____
>
> Tolga____
>
> __ __
>
> *From:*rtcweb [mailto:rtcwe= b-bounces@ietf.org
> <mailto:rtcweb-bounces@i= etf.org>] *On Behalf Of *Ted Hardie *Sent:*
> Monday, March 07, 2016 5:19 PM *To:* Jean-Marc Valin
> <jmvalin@mozilla.com <= ;mailto:jmvalin@mozilla.com>&= gt; *Cc:* Cullen
> Jennings <fluffy@cisco.com = <mailto:fluffy@cisco.com>>= ;
> rtcweb@ietf.org <mailto:rtcweb@ietf.org> *Subject:* Re: [rtcw= eb]
> DTMF resolution proposal____
>
> __ __
>
> On Mon, Mar 7, 2016 at 1:23 PM, Jean-Marc Valin
> <jmvalin@mozilla.com<= /a> <mailto:jmvalin@mozilla.com>> wrote:____
>
> As proposed by Roman, I think we should also include the "minimum=
> gap of 30 ms". Otherwise, I support the proposal.____
>
>> __ __
>
>> Thank you Jean-Marc; I had not thought to include that in my
>> note, but I agree.____
>
>> regards,____
>
>> Ted____
>
>
>> ____
>
> Jean-Marc____
>
>
> On 03/07/2016 03:35 PM, Ted Hardie wrote:
>> We've had about 60 or so messages on this topic, and the rough=
>> consensus seems to be align this document with the limits set
>> out in the W3C work here:
>
>> https://www.w3.org/TR/webrtc/#rtcdtmfsender<= br> >
>> However, there was also a proposal to slightly modify those
> limits.
>> They are currently:
>
>> "The duration cannot be more than 6000 ms or less than 40 ms.=
>> The default duration is 100 ms for each tone."
>
>> Based on Roman's note, a minimum of 40ms and a maximum 8000 ms=
>> to align with the ITU and RFC2833.
>
>> To resolve this, I propose that we ask the WebRTC group to raise >> their max to 8000 and, on receiving a positive response, publish >> this document with 40/8000 as the min and max.=C2=A0 If they give = a
>> negative response, we retain 40/6000.=C2=A0 This values alignment<= br> >> between the two documents higher than the reference 2833, but
>> that seems sensible in this context.
>
>> If you have an objection to this way forward, please send your
>> reasoning to the list by March 14th.
>
>> thanks,
>
>> Ted
>
>
>> ____
>
>> _______________________________________________ rtcweb mailing
>> list rtcweb@ietf.org= <mailto:rtcweb@ietf.org>
> https://www.ietf.org/mailman/listinfo/rtcweb >
>
> __ __
>
>
> _______________________________________________ rtcweb mailing
> list rtcweb@ietf.org <mailto= :rtcweb@ietf.org>
> https://www.ietf.org/mailman/listi= nfo/rtcweb
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJW33xoAAoJEJ6/8sItn9q9agEIAIDvDjcyiWb1jrDPRiPmY2z0
uOtzfmdg7FurvbEM4uIn5S30DrbB1i5ncl2xTmM24/jIHKAVtr/pXbMt5jH5a/F8
XMQs5zkgK7w1tP/EykJ3f2ti5pWc18Lia8rYMzKdm0GEwcUQMemUCZ+7WrqT0N3p
BHYPZY8B4qR/7TK+AquxcWUUZsQdPi3LaGcJwJF9+KwRKuXAQcEphUVs2SnF48+F
IMFlhRyT097gaz5lOFS36AeyS8SO1So8W1Y2hwGMIjmuHJAMJm4vN4E8JO4R49MF
gsvqeYimx8YZtxJww02aBN/gauUwdecol5N6xXk3haWTgdgvBJjfWzRIOsSluVo=3D
=3DWJ2n
-----END PGP SIGNATURE-----

--089e013a1ee2baac05052da14c42-- From nobody Wed Mar 9 09:58:14 2016 Return-Path: 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 7226E12D87E for ; Wed, 9 Mar 2016 09:58:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8a5Vd1MXxeL for ; Wed, 9 Mar 2016 09:58:11 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F09A12D87C for ; Wed, 9 Mar 2016 09:57:55 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id g203so75427597iof.2 for ; Wed, 09 Mar 2016 09:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=qXMrQYqXZqe0M+tYBwB/P4z+QFLgG1mAu7tnSdjzLRI=; b=MnUzcUenGcoSzvrmfUy2VwG3lPUc/e7q9CIaejA7da/zuh+moOz+e1aPG6Cxz940Zq 99PYNboQgdmXrE3tXaZ9CSf+xkWPGBVQGzTQPEEgHrwOgdvCLSr3BUqd72JI4Ogzun4w k9V4TdH+DUGXCv05ZsSeZIAbU2uNXJoBWW14lS2b3SLW2XBcf5eK4Ix9GGJzZOJS07lt NdeSScJuugFq30WC1SbaQAddbjW7W+WsFCk5uSnoIPNKJ4nn00s0yKzCC5njOgKGvGWF co+azYGc6Ff75hvgtsOCfBw4tFaWOkDs/OUzEtGb3/ugre3XgP7S9kpFmkHI2ee5vi2B hj7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=qXMrQYqXZqe0M+tYBwB/P4z+QFLgG1mAu7tnSdjzLRI=; b=HGszS8eyvUllapX4J+0zaMYafPzNkA5N2pn+qNrBwbubXkGv9Q9hg9lUJZICgyf+Yh ToRIYSMYtCK7CVyw5uQ64LldrBqMSQU8SwM9quPPCT9q5yNtlLk9BgQOjnAxDWx89MJq Pg5+WNZEvDqHVwk9WDBp0IZ7ZgWoxsiIZzR86Y/SXGJS8wEdVpxcAUZGSWlij+ML9IaC RbpgRe5Uus/PX8OdEBF4SNQiF8vX85hUb2lx48fydzHwSiuqgWKPNr/MFaitA3M5smWr q8IguiqJm+PLGHokaSDV9IM+00r3+lWmBvJMG+0V7KSSD8ece7XI2C5D8ORFFO6mNrz3 vQyg== X-Gm-Message-State: AD7BkJIyWN+Qz1+w+jazJ/Y7XqKcppFA/7WCChITynT3pnedGr4XRDEIMxnFrnW4x5ypEQ== X-Received: by 10.107.134.202 with SMTP id q71mr433260ioi.74.1457546274640; Wed, 09 Mar 2016 09:57:54 -0800 (PST) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com. [209.85.223.174]) by smtp.gmail.com with ESMTPSA id me7sm3431092igb.12.2016.03.09.09.57.52 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 09 Mar 2016 09:57:53 -0800 (PST) Received: by mail-io0-f174.google.com with SMTP id z76so75400898iof.3 for ; Wed, 09 Mar 2016 09:57:52 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.107.12.207 with SMTP id 76mr458633iom.70.1457546272487; Wed, 09 Mar 2016 09:57:52 -0800 (PST) Received: by 10.36.106.194 with HTTP; Wed, 9 Mar 2016 09:57:52 -0800 (PST) In-Reply-To: References: <56DDF13F.1050505@mozilla.com> Date: Wed, 9 Mar 2016 12:57:52 -0500 X-Gmail-Original-Message-ID: Message-ID: From: Roman Shpount To: "Asveren, Tolga" Content-Type: multipart/alternative; boundary=001a113eca06d0cadc052da16fa4 Archived-At: Cc: Cullen Jennings , "rtcweb@ietf.org" Subject: Re: [rtcweb] DTMF resolution proposal X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2016 17:58:13 -0000 --001a113eca06d0cadc052da16fa4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 9, 2016 at 11:52 AM, Asveren, Tolga wrote: > =E2=80=9CWebRTC endpoints, such as browsers, will not do anything with RF= C 4733 > tones sent from the gateway, except gracefully drop them. There is > currently no API to inform JavaScript about the received DTMF or other RF= C > 4733 tones. > > > > Do you want the language added to the specification that WebRTC endpoint > should be able to receive any RFC 4733 tones and process them in a gracef= ul > manner?=E2=80=9D > > > > This sounds strange to me (using digits unidirectionally) but I would > think that browser vendors should weigh in on this one. For me, the > practically important point is that gateway can send RFC4733 digits towar= d > the browser/native WebRTC app without being restricted by the defined > range. There wouldn=E2=80=99t be any issue from my perspective if browser= s are > anyhow going to drop the digits (I assume this would be the same for nati= ve > WebRTC application) but **if** things change so that they may process > them, then I would prefer the text to be clear that the range restriction > does not apply for digits from a gateway toward the browser/native app. > > > > > WebRTC enabled browsers are clients, so they do not normally need to process digits. This is similar VoIP Phones, which will send RFC 4733 DTMF tones but have no reason to process them. Native applications can do whatever they want with the digits that they receive. So, does anybody needs the language that gateways can generate any RFC 4733 digits they like and WebRTC end point can ignore them? Regards, _____________ Roman Shpount --001a113eca06d0cadc052da16fa4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 9, 2016 at 11:52 AM, Asveren, Tolga <= tasveren@sonusne= t.com> wrote:

=E2=80=9CWebRTC endpoints, such as browsers, will no= t do anything with RFC 4733 tones sent from the gateway, except gracefully = drop them. There is currently no API to inform JavaScript about the receive= d DTMF or other RFC 4733 tones.

=C2=A0

Do you want the language added to the specification = that WebRTC endpoint should be able to receive any RFC 4733 tones and proce= ss them in a graceful manner?=E2=80=9D

=C2=A0

This sounds strange to me (using digits unidirection= ally) but I would think that browser vendors should weigh in on this one. F= or me, the practically important point is that gateway can send RFC4733 dig= its toward the browser/native WebRTC app without being restricted by the defined range. There wouldn=E2=80=99t = be any issue from my perspective if browsers are anyhow going to drop the d= igits (I assume this would be the same for native WebRTC application) but *= if* things change so that they may process them, then I would prefer the text to be clear that the range rest= riction does not apply for digits from a gateway toward the browser/native = app.

=C2=A0


WebRTC enabled= browsers are clients, so they do not normally need to process digits. This= is similar VoIP Phones, which will send RFC 4733 DTMF tones but have no re= ason to process them.

Native applications can do w= hatever they want with the digits that they receive.

So, does anybody needs the language that gateways can generate any RFC 4= 733 digits they like and WebRTC end point can ignore them?

Regards,
_____________Roman Shpount
=C2=A0
--001a113eca06d0cadc052da16fa4-- From nobody Wed Mar 9 20:15:53 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3055812DD78; Wed, 9 Mar 2016 20:15:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160310041551.665.73630.idtracker@ietfa.amsl.com> Date: Wed, 09 Mar 2016 20:15:51 -0800 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-13.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 04:15:51 -0000 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 of the IETF. Title : Javascript Session Establishment Protocol Authors : Justin Uberti Cullen Jennings Eric Rescorla Filename : draft-ietf-rtcweb-jsep-13.txt Pages : 82 Date : 2016-03-09 Abstract: This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-13 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/ From nobody Thu Mar 10 08:09:55 2016 Return-Path: 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 BD99C12D9BB for ; Thu, 10 Mar 2016 08:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 eX1kFMneYi2u for ; Thu, 10 Mar 2016 08:09:51 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B8612D97A for ; Thu, 10 Mar 2016 08:09:51 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id c203so64607926oia.2 for ; Thu, 10 Mar 2016 08:09:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=ooWcjEeG8jSbgiWpS9UR6JLg5eCid6HpmfsnFiDDo0I=; b=cvy2HNZLQRWNERV3OBHaaFCL2eNLlrPUcWY3zAyeVmfz4YZXr6v9wQquWBe88ocZZB nIucDdm/IgbO4PMDvWd9FqQEx00DZjpk9Ls5Iy1SfSybkVNi1566kVeLnl6RqHqhF2vE IWD3L/7P6r8pFQizC2aHnpRDPDUZJMGwbtD4Hnk6xYbvzAVXC8RiW0DldrO381zQdJwu nagXL2vHWaJZiCIg3dGtHFUjxARYJT2X0fWxYmbOziqyIB+OheAmH0vePsEHYcpj5jLl vkLnzixfwztoenm+1+y7mJgbQ+/zrOwLMbZG4FPAQwGnf0owH/CemnPjffQI+KQwwHaJ HtuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ooWcjEeG8jSbgiWpS9UR6JLg5eCid6HpmfsnFiDDo0I=; b=JYQUhYRO7ydvYkUhfuYMgEJO4DWPorjePWQ/yZuMA89aqabDV/G6eX8m/HdN90QhSr g2fDkJ/2yijmlhzBnJkeeTVEJ8Sen7m/YmGb1qcI3XMrq2ZRtkU82bEsR3iCu2SHzpZn bgpeLWPPQcxR6MbmqMLVDZUbVKP1KcL8qpA+EZjH+qidUDRuhRomkdpHzJBlCtfbMzyK 8aEzeuLtx/agsxtnyLfnP1lLtm5GnWgZKxCDtpILLo6t8bHfxDkwKkcKcErEqW7hegM6 SioZqo4d+75/3hoY8YYGJXt1Cp8E6HpUnao/IktEwBiShudlyncoTiYNHh05LTs3ysTw m8ZA== X-Gm-Message-State: AD7BkJIDcYoai1csPwJTt6+H+aI3iSAMALpS8wMkWei8WE+aqDI2Kqvm43hUAE2ztfwFrJ97KckOLCeiD1EPNg== X-Received: by 10.202.217.136 with SMTP id q130mr2535989oig.127.1457626190999; Thu, 10 Mar 2016 08:09:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.51.6 with HTTP; Thu, 10 Mar 2016 08:09:31 -0800 (PST) From: Ted Hardie Date: Thu, 10 Mar 2016 08:09:31 -0800 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a11496c545481d5052db40b57 Archived-At: Subject: [rtcweb] Jabber issues/Today's interim X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 16:09:54 -0000 --001a11496c545481d5052db40b57 Content-Type: text/plain; charset=UTF-8 We've been told that there are some issues reaching the ietf.org jabber servers from some other xmpp servers, including jabber.org. They're working on it, but we joining the jabber room for the interim may not work. Please use the webex chat room as a side channel if jabber is not working for you. thanks, Ted --001a11496c545481d5052db40b57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a11496c545481d5052db40b57-- From nobody Thu Mar 10 11:02:11 2016 Return-Path: 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 8C82812DB8D for ; Thu, 10 Mar 2016 11:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 lW7YLIe30g7k for ; Thu, 10 Mar 2016 11:02:08 -0800 (PST) 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 5268B12DB83 for ; Thu, 10 Mar 2016 11:02:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 79E257C7833; Thu, 10 Mar 2016 20:02:06 +0100 (CET) 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 z7Jzdlqke3Fm; Thu, 10 Mar 2016 20:02:05 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:78ac:35ba:4524:3964] (unknown [IPv6:2001:470:de0a:1:78ac:35ba:4524:3964]) by mork.alvestrand.no (Postfix) with ESMTPSA id CEB577C760E; Thu, 10 Mar 2016 20:02:05 +0100 (CET) To: Juergen Stoetzer-Bradler , rtcweb@ietf.org References: <56DEC8F5.4070101@alcatel-lucent.com> <56DF03D8.6070308@alum.mit.edu> <56DF30EF.7040404@alvestrand.no> <56DF925A.1050209@nteczone.com> <56E0381B.6030509@alcatel-lucent.com> From: Harald Alvestrand Message-ID: <56E1C4AD.7000300@alvestrand.no> Date: Thu, 10 Mar 2016 20:02:05 +0100 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: <56E0381B.6030509@alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 19:02:10 -0000 Den 09. mars 2016 15:50, skrev Juergen Stoetzer-Bradler: > Ted, Paul, Harald, Christian, > > Thanks for your replies. > Based on your feedback it seems to me that RFC 6455 and current > draft-ietf-rtcweb-data-protocol may actually not unambiguously specify > if (Websocket or data channel) subprotocol identifiers are compared > case-sensitively or case-insensitively. > > As far as I see, in case of DCEP, the situation with the 'Label' value > might be similar. Having thought a little more about this, I think the answer is actually out of scope for this WG. In my opinion: The subprotocol and label attributes MUST be transported unchanged from the source to the destination. This protocol has no operation whereby one compares the values to anything. Therefore, this protocol should say nothing about how to compare them. Harald From nobody Thu Mar 10 12:13:01 2016 Return-Path: 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 C093E12DC96 for ; Thu, 10 Mar 2016 12:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jV5KxRoat7NU for ; Thu, 10 Mar 2016 12:12:59 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA5F412DC92 for ; Thu, 10 Mar 2016 12:12:58 -0800 (PST) Received: by mail-ob0-x22f.google.com with SMTP id fz5so92540181obc.0 for ; Thu, 10 Mar 2016 12:12:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/xXdJj7Vv87qwT95Qs2e6JLnPgFrfbBolem12gb/vts=; b=TLyCwXcqfw3SQ+SdHsuifGqOriDqTSSbSbKZMkrq+SEmZrAkpq4pGndBgRC9Y83hCZ A/+qORZJeA87ETM8PkHe9UB8+ScTaNjL5czZzD1pzTAlRAGii+8nMA4r9MtV2CbeVOsY hZYOmTSccHKTzEOTtUI1imHM82jQeYvNQgAbcI0r/2NmQTPCBOF1KOBEgQIbFejqLgSi ZyOGyvERawPzhstchwDgsI7k+Eo12MBE+gUjHB/IkhhAhXiAC0PFa5Rh49uKqvmYE32A trMTXOVVHQS7+tqRzbVoZqOkDBEz3FA3ljphS/yFjGGIWbFONvlouzjgZzqatqKWniIX BLqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/xXdJj7Vv87qwT95Qs2e6JLnPgFrfbBolem12gb/vts=; b=LosrduwlnFaAS1Irx9MlM5fhHWlPDAOSRm1HhY7bu8mrHmpoDFnK+eo5Z/gkHygzkh 9Lp85Fg0i8xWrb83IAjvogsYLbI+LRHCXZJYY7nHr3T5Zlz3mxzR2RL06k9FR1L6QTWm RrBVjXOsrCWpk5lYsHgnTS8ydOoAi7d8qeQWuPe+IcpWYURdaGXAfFWEZ6FmVTOrbaDZ TeicusJ8NHPxChOUQItLSq7hKD5E5n7TwyAP0qnbZEvqik8G/VDVkTxea7zWmmA00LZn pG81i/vUAfzl1qFvQeDyPhYOklb+vyuPJItGwPqsjQ6jzMoG4ETEMJbuRfOM96zSavoD rogA== X-Gm-Message-State: AD7BkJJstZDEMGRzhSIH2VrOcjhoW6ti+yRQkH5Ug1bm+LLWMRhlIuQ5lRPyZJncJ+1nwzt2g+qb9byrlXQutA== X-Received: by 10.182.107.137 with SMTP id hc9mr3226444obb.74.1457640778210; Thu, 10 Mar 2016 12:12:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.51.6 with HTTP; Thu, 10 Mar 2016 12:12:38 -0800 (PST) In-Reply-To: <56E1C4AD.7000300@alvestrand.no> References: <56DEC8F5.4070101@alcatel-lucent.com> <56DF03D8.6070308@alum.mit.edu> <56DF30EF.7040404@alvestrand.no> <56DF925A.1050209@nteczone.com> <56E0381B.6030509@alcatel-lucent.com> <56E1C4AD.7000300@alvestrand.no> From: Ted Hardie Date: Thu, 10 Mar 2016 12:12:38 -0800 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=089e011763bbcba500052db770b1 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 20:13:01 -0000 --089e011763bbcba500052db770b1 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 10, 2016 at 11:02 AM, Harald Alvestrand wrote: > Den 09. mars 2016 15:50, skrev Juergen Stoetzer-Bradler: > > Having thought a little more about this, I think the answer is actually > out of scope for this WG. > > In my opinion: The subprotocol and label attributes MUST be transported > unchanged from the source to the destination. So far, I agree. > This protocol has no > operation whereby one compares the values to anything. Therefore, this > protocol should say nothing about how to compare them. > > Does this equate to your taking an action item to specify the comparison in the API? Ted > Harald > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --089e011763bbcba500052db770b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 10, 2016 at 11:02 AM, Harald Alvestrand <h= arald@alvestrand.no> wrote:
Den= 09. mars 2016 15:50, skrev Juergen Stoetzer-Bradler:

Having thought a little more about this, I think the answer is actua= lly
out of scope for this WG.

In my opinion: The subprotocol and label attributes MUST be transported
unchanged from the source to the destination.

So far,= I agree.=C2=A0
=C2=A0
T= his protocol has no
operation whereby one compares the values to anything. Therefore, this
protocol should say nothing about how to compare them.


Does this equate to your taking an action item to sp= ecify the comparison in the API?

Ted

= =C2=A0
Harald

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--089e011763bbcba500052db770b1-- From nobody Thu Mar 10 12:51:20 2016 Return-Path: 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 4FAE412DCFA for ; Thu, 10 Mar 2016 12:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] 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 3UY1csXO_FLR for ; Thu, 10 Mar 2016 12:51:16 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 180A912DCFB for ; Thu, 10 Mar 2016 12:51:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 531B97C791B; Thu, 10 Mar 2016 21:51:12 +0100 (CET) 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 2Jif6z39YvMd; Thu, 10 Mar 2016 21:51:11 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:d432:cc27:fb9b:d302] (unknown [IPv6:2001:470:de0a:1:d432:cc27:fb9b:d302]) by mork.alvestrand.no (Postfix) with ESMTPSA id 35C2E7C77F6; Thu, 10 Mar 2016 21:51:11 +0100 (CET) To: Ted Hardie References: <56DEC8F5.4070101@alcatel-lucent.com> <56DF03D8.6070308@alum.mit.edu> <56DF30EF.7040404@alvestrand.no> <56DF925A.1050209@nteczone.com> <56E0381B.6030509@alcatel-lucent.com> <56E1C4AD.7000300@alvestrand.no> From: Harald Alvestrand Message-ID: <56E1DE3E.2060208@alvestrand.no> Date: Thu, 10 Mar 2016 21:51:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020902010806030402030109" Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 20:51:18 -0000 This is a multi-part message in MIME format. --------------020902010806030402030109 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/10/2016 09:12 PM, Ted Hardie wrote: > On Thu, Mar 10, 2016 at 11:02 AM, Harald Alvestrand > > wrote: > > Den 09. mars 2016 15:50, skrev Juergen Stoetzer-Bradler: > > Having thought a little more about this, I think the answer is > actually > out of scope for this WG. > > In my opinion: The subprotocol and label attributes MUST be > transported > unchanged from the source to the destination. > > > So far, I agree. > > > This protocol has no > operation whereby one compares the values to anything. Therefore, this > protocol should say nothing about how to compare them. > > > Does this equate to your taking an action item to specify the > comparison in the API? The Javascript API specified in WebRTC doesn't have any business comparing them either. Once we have a specification that says "if the incoming value of the protocol field matches , then...", that specification needs to say what "matches" means. Currently we don't have one in either of our WGs. --------------020902010806030402030109 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 03/10/2016 09:12 PM, Ted Hardie wrote:
On Thu, Mar 10, 2016 at 11:02 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
Den 09. mars 2016 15:50, skrev Juergen Stoetzer-Bradler:

Having thought a little more about this, I think the answer is actually
out of scope for this WG.

In my opinion: The subprotocol and label attributes MUST be transported
unchanged from the source to the destination.

So far, I agree. 
 
This protocol has no
operation whereby one compares the values to anything. Therefore, this
protocol should say nothing about how to compare them.


Does this equate to your taking an action item to specify the comparison in the API?

The Javascript API specified in WebRTC doesn't have any business comparing them either.

Once we have a specification that says "if the incoming value of the protocol field matches <X>, then...", that specification needs to say what "matches" means.

Currently we don't have one in either of our WGs.

--------------020902010806030402030109-- From nobody Thu Mar 10 19:00:42 2016 Return-Path: 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 2F9B712DA88 for ; Thu, 10 Mar 2016 19:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 TPzi3nsVhOMx for ; Thu, 10 Mar 2016 19:00:40 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5DFE12D920 for ; Thu, 10 Mar 2016 19:00:40 -0800 (PST) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-03v.sys.comcast.net with comcast id UT0X1s0012VvR6D01T0fa2; Fri, 11 Mar 2016 03:00:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-19v.sys.comcast.net with comcast id UT0f1s0093KdFy101T0fnn; Fri, 11 Mar 2016 03:00:39 +0000 To: rtcweb@ietf.org References: <56DEC8F5.4070101@alcatel-lucent.com> <56DF03D8.6070308@alum.mit.edu> <56DF30EF.7040404@alvestrand.no> <56DF925A.1050209@nteczone.com> <56E0381B.6030509@alcatel-lucent.com> <56E1C4AD.7000300@alvestrand.no> From: Paul Kyzivat Message-ID: <56E234D5.9070301@alum.mit.edu> Date: Thu, 10 Mar 2016 22:00:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56E1C4AD.7000300@alvestrand.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457665239; bh=R+RPajsFb4bhb34V0oPRVv0H7WbhRQGuPQ/26RsSPp4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=c6xMbGf4lXJYdRI8L/HJ0aeAsjwMPVscTiZawY9Ze32NORt9HbEwlEFnYYWA1Yy0e kxl7DWm6BryLTnT8vdN4NtMJ3PJTULH4XhOWQeryd8widMckMRJbihNw8p/WkEMNQi EqB9m3W5tuHYOhYgPNAGTYiUHPysneh+QolyIkZMthfoh08cThPI+QaTZovKU+yhbQ UxjQJymE4B6odj+J2as3NzR0mpG0psW3wHk/uIKSPguLQPHJZye4SVbkeG5D4qGW9I h1T9ADL7garz8R5jmwMUp0C5ZGPxFxqHYgy7k2kkr1pyNE/EUGj8zb9k+qT4pAaGrT wDkZ16ZGPbIbQ== Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 03:00:42 -0000 On 3/10/16 2:02 PM, Harald Alvestrand wrote: > Den 09. mars 2016 15:50, skrev Juergen Stoetzer-Bradler: >> Ted, Paul, Harald, Christian, >> >> Thanks for your replies. >> Based on your feedback it seems to me that RFC 6455 and current >> draft-ietf-rtcweb-data-protocol may actually not unambiguously specify >> if (Websocket or data channel) subprotocol identifiers are compared >> case-sensitively or case-insensitively. >> >> As far as I see, in case of DCEP, the situation with the 'Label' value >> might be similar. > > Having thought a little more about this, I think the answer is actually > out of scope for this WG. > > In my opinion: The subprotocol and label attributes MUST be transported > unchanged from the source to the destination. This protocol has no > operation whereby one compares the values to anything. Therefore, this > protocol should say nothing about how to compare them. If that is the case, where should the specification of this belong? The protocol is pretty useless if it says we exchange a token to agree on the subprotocol but doesn't specify how we determine what the token means. I think the minimal safe thing to do is to forbid the registration of values that differ only in case. Then, a case-sensitive implementation can interoperate with a case-insensitive implementation withou problem as long as they use only registered values. Thanks, Paul From nobody Thu Mar 10 19:09:58 2016 Return-Path: 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 C389D12DFB5 for ; Thu, 10 Mar 2016 19:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 2RGSVEEG6KZF for ; Thu, 10 Mar 2016 19:09:55 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 095F212DE2C for ; Thu, 10 Mar 2016 19:09:54 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-06v.sys.comcast.net with comcast id UT9k1s0022XD5SV01T9uHF; Fri, 11 Mar 2016 03:09:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-20v.sys.comcast.net with comcast id UT9t1s00A3KdFy101T9tn3; Fri, 11 Mar 2016 03:09:54 +0000 To: Ted Hardie References: <56DEC8F5.4070101@alcatel-lucent.com> <56DF03D8.6070308@alum.mit.edu> From: Paul Kyzivat Message-ID: <56E23700.1060206@alum.mit.edu> Date: Thu, 10 Mar 2016 22:09:52 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457665794; bh=DtvQuh9jBD7wmKr5sMB3OAHQ2gw7KsqOG6YMiQS3iKk=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=bUOIQridhFC8mVxQz+eW6r6IED5i/7ldANBrva1XnullVSL2EXuU1qBxS60riQNx/ UfKqVRpzUrCO7cJltn3JG/3IqarFYJEvKlYABfazHUYOTq3CW0tVcKcdeOqLWo3j8k ovbcR+DM03tOBWCz2/dPKWb/fZdsas5o0O5mYU8ZCWqQJPtob8FfziDDA1DeOtT2Nx Zwo0/toxOup6VpBf0h2H1B0/42eHGB396bprRUMNOWjGgxIT0D+r1XsEKSGDnD61Xr 0oUEEgDJdotjJ54F04YB2ymD2bfo2Z1ak5J/vfR4B+VSonepxbdkPrjx8p8k0DKeeH eVpH3YWVE0vsA== Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 03:09:57 -0000 On 3/8/16 2:22 PM, Ted Hardie wrote: > On Tue, Mar 8, 2016 at 8:54 AM, Paul Kyzivat > wrote: > > > The elements that comprise this value > MUST be non-empty strings with characters in the range > U+0021 to > U+007E not including separator characters as defined in > [RFC2616 ] and > MUST all be unique strings. The ABNF for the > value of this header field is 1#token, where the > definitions of > constructs and rules are as given in [RFC2616 > ]. > > The current registry is here: > > http://www.iana.org/assignments/websocket/websocket.xhtml#subprotocol-name > > > I had already investigated this. This only talks about the registry, > not how values passed in the protocol are compared to registered > values. Nor does it explicitly say whether "unique strings" is to be > determined via case-sensitive comparison or case-insensitive comparison. > > (Without any other information to go on I guess I would assume > case-sensitive comparison.) > > Is there any token example in RFC 2616 that is case sensitive? As far > as I can tell they are all case-insensitive, but I may have missed > something. > > The Postel principle seems to indicate that we should always use the > registered form, but be willing to understand a case insensitive variant. While I think the Postel principle is often good practice for implementers, it is still a DWIM approach. It only works in cases where there is only one reasonable interpretation of what to do. If it is relied upon, then it becomes an unwritten normative requirement. At the end of the day DWIS is more reliable than DWIM. Being explicit is a cheap way of avoiding future trouble. > What is most *important* to me is that this be made entirely clear, > that IANA have clear instructions to enforce, and that both > websocket and data channel specs consistently specify what > implementations must do in this regard. > > It is less important to me *which* choice is made. My *preference* > would be minimally that the registry not permit two different names > that differ only by case. If that is so, then in some sense it > doesn't matter how implementations of the protocols do the comparison. > > How likely do you see this being? Anyone going to register XMPP > (instead of xmpp) is going to be hurting themselves as much as users of > xmpp if they actually use it. I'm happy to clean this up at some point, > but I find it hard to believe this is the biggest rock. I think we already have encountered a case where MSRP has been proposed to be spelled "MSRP" and "msrp", once for websocket use and once for data channel use. (I am not sure of this, and don't want to go look it up right now.) Technically that might not be a problem, but it would be at least annoying and a source of confusion. Thanks, Paul > regards, > > Ted > > Thanks, > Paul > > regards, > > Ted > > Background is draft-ietf-mmusic-data-channel-sdpneg, where the > subprotocol identifiers are signaled as part of an SDP > attribute and > where it is not yet clarified if these identifiers are > assumed to be > case sensitive or case insensitive. > > Thanks, > Juergen > > _______________________________________________ > 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 > > From nobody Fri Mar 11 00:41:35 2016 Return-Path: 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 2542C12D57B for ; Fri, 11 Mar 2016 00:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 hxg7439RoCX5 for ; Fri, 11 Mar 2016 00:41:31 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1D012D57E for ; Fri, 11 Mar 2016 00:41:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 113087C79DE for ; Fri, 11 Mar 2016 09:41:29 +0100 (CET) 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 GcSQZZnKA7sk for ; Fri, 11 Mar 2016 09:41:28 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:78ac:35ba:4524:3964] (unknown [IPv6:2001:470:de0a:1:78ac:35ba:4524:3964]) by mork.alvestrand.no (Postfix) with ESMTPSA id 2BAB37C7822 for ; Fri, 11 Mar 2016 09:41:28 +0100 (CET) To: rtcweb@ietf.org References: <56DEC8F5.4070101@alcatel-lucent.com> <56DF03D8.6070308@alum.mit.edu> <56DF30EF.7040404@alvestrand.no> <56DF925A.1050209@nteczone.com> <56E0381B.6030509@alcatel-lucent.com> <56E1C4AD.7000300@alvestrand.no> <56E234D5.9070301@alum.mit.edu> From: Harald Alvestrand X-Enigmail-Draft-Status: N1110 Message-ID: <56E284B6.10507@alvestrand.no> Date: Fri, 11 Mar 2016 09:41:26 +0100 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: <56E234D5.9070301@alum.mit.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 08:41:34 -0000 Den 11. mars 2016 04:00, skrev Paul Kyzivat: > On 3/10/16 2:02 PM, Harald Alvestrand wrote: >> Den 09. mars 2016 15:50, skrev Juergen Stoetzer-Bradler: >>> Ted, Paul, Harald, Christian, >>> >>> Thanks for your replies. >>> Based on your feedback it seems to me that RFC 6455 and current >>> draft-ietf-rtcweb-data-protocol may actually not unambiguously specify >>> if (Websocket or data channel) subprotocol identifiers are compared >>> case-sensitively or case-insensitively. >>> >>> As far as I see, in case of DCEP, the situation with the 'Label' value >>> might be similar. >> >> Having thought a little more about this, I think the answer is actually >> out of scope for this WG. >> >> In my opinion: The subprotocol and label attributes MUST be transported >> unchanged from the source to the destination. This protocol has no >> operation whereby one compares the values to anything. Therefore, this >> protocol should say nothing about how to compare them. > > If that is the case, where should the specification of this belong? > > The protocol is pretty useless if it says we exchange a token to agree > on the subprotocol but doesn't specify how we determine what the token > means. > > I think the minimal safe thing to do is to forbid the registration of > values that differ only in case. Then, a case-sensitive implementation > can interoperate with a case-insensitive implementation withou problem > as long as they use only registered values. The specification that sets up the registry seems like the logical place. Amending RFC 6455 (WebSocket), anyone? Errata? Updating document? From nobody Fri Mar 11 01:09:49 2016 Return-Path: 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 BE5FF12D595 for ; Fri, 11 Mar 2016 01:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Wxi4Ctts00H1 for ; Fri, 11 Mar 2016 01:09:47 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FA412D59E for ; Fri, 11 Mar 2016 01:09:47 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id g203so137771653iof.2 for ; Fri, 11 Mar 2016 01:09:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=YZiz6X0WIpKCb2BYnbiGDkmMfYmIJod+ib7/gw8kqXo=; b=s+mgQGeO5zqnrtA+4rUoriZThWduc7vD5yjBjlvZmMpe793vnGKhKU/3WGjXrP4mnr RCekDny4ZeC2Q5D5qQShD5o2+WBMO2dumu+d6oAx47UkK1n9ALu2tUsIAOo3l/gGU7WD nHbU8rsl86ILzZcBnVJea8VNT70c/Q7SAqPtoCngWJcfoslayzpVaK289zpqjXnzDOV2 o/6mukQtpcLwplqRkvG2JWyPbka1NptTO/tWD5JFU/6jiYskTTjH2PzOe2HIB0ZIOeoc QQR3yx8ulCr5Yuh9OxzuN+he/bh6DDn3QFTEbPlxbsXBcvOn7C/fOb47Q5UpwDLRlcj/ xwYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=YZiz6X0WIpKCb2BYnbiGDkmMfYmIJod+ib7/gw8kqXo=; b=cwCkhewybI/hHOn9jk2+ISa/sxIkqWfTaWwZIBdDZENGzHLY6W7oIAGMVG0VohQVcJ WdlZq3/R0FZtkCVWeobX8wISwelomlndO4zSI4UG3zc+rIuflnCl5QxekAHwhHW4/HDc DO9TXvRldvjpAvMfMFqikyOwkzVYlYAZ/buARlp2oqyM0+5Btnz1ztlUocD+1CWUM0Ap cvVSH0x2F1aNfjT9ReDX8PipSmMFirZDku3sFqrR+SOved1RkMfq8kb7irXjPHsi2LlO nkrUOgJkOsBsKgw0UQTitmaphDZ2IKzcYSGfqxS/KfcOGTiYV8scT9uHfbOLZiK8FJYw J7Hg== X-Gm-Message-State: AD7BkJJrNeYdY1hoZgMtf4eChptJUcn2ESTjxc/baEBZzc6gOsHEjD3OgvTBPCUVDdwKE8AJZ1h1AG/MHKI5qg== MIME-Version: 1.0 X-Received: by 10.107.131.105 with SMTP id f102mr8939189iod.190.1457687386526; Fri, 11 Mar 2016 01:09:46 -0800 (PST) Received: by 10.36.43.5 with HTTP; Fri, 11 Mar 2016 01:09:46 -0800 (PST) In-Reply-To: <56E1DE3E.2060208@alvestrand.no> References: <56DEC8F5.4070101@alcatel-lucent.com> <56DF03D8.6070308@alum.mit.edu> <56DF30EF.7040404@alvestrand.no> <56DF925A.1050209@nteczone.com> <56E0381B.6030509@alcatel-lucent.com> <56E1C4AD.7000300@alvestrand.no> <56E1DE3E.2060208@alvestrand.no> Date: Fri, 11 Mar 2016 20:09:46 +1100 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 09:09:48 -0000 On 11 March 2016 at 07:51, Harald Alvestrand wrote: > Once we have a specification that says "if the incoming value of the > protocol field matches , then...", that specification needs to say what > "matches" means. > > Currently we don't have one in either of our WGs. Thankfully. We probably should use USVString rather than DOMString so that we can avoid the Unicode issues that DOMString creates, but other than that, I don't see any future in standardized values for protocol, it is simply too poorly defined. From nobody Fri Mar 11 04:34:37 2016 Return-Path: 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 0E5FC12D6A9 for ; Fri, 11 Mar 2016 04:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 wTvXC9xBL3cB for ; Fri, 11 Mar 2016 04:34:28 -0800 (PST) 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 596A212D698 for ; Fri, 11 Mar 2016 04:33:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id DB8C97C79F8; Fri, 11 Mar 2016 13:33:45 +0100 (CET) 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 feyrSvCHHTuM; Fri, 11 Mar 2016 13:33:45 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:78ac:35ba:4524:3964] (unknown [IPv6:2001:470:de0a:1:78ac:35ba:4524:3964]) by mork.alvestrand.no (Postfix) with ESMTPSA id E67537C79F6; Fri, 11 Mar 2016 13:33:44 +0100 (CET) To: Martin Thomson References: <56DEC8F5.4070101@alcatel-lucent.com> <56DF03D8.6070308@alum.mit.edu> <56DF30EF.7040404@alvestrand.no> <56DF925A.1050209@nteczone.com> <56E0381B.6030509@alcatel-lucent.com> <56E1C4AD.7000300@alvestrand.no> <56E1DE3E.2060208@alvestrand.no> From: Harald Alvestrand Message-ID: <56E2BB28.3090701@alvestrand.no> Date: Fri, 11 Mar 2016 13:33:44 +0100 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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 12:34:37 -0000 Den 11. mars 2016 10:09, skrev Martin Thomson: > On 11 March 2016 at 07:51, Harald Alvestrand wrote: >> Once we have a specification that says "if the incoming value of the >> protocol field matches , then...", that specification needs to say what >> "matches" means. >> >> Currently we don't have one in either of our WGs. > > > Thankfully. We probably should use USVString rather than DOMString so > that we can avoid the Unicode issues that DOMString creates, but other > than that, I don't see any future in standardized values for protocol, > it is simply too poorly defined. > Good idea, https://github.com/w3c/webrtc-pc/issues/543 filed. From nobody Fri Mar 11 10:44:28 2016 Return-Path: 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 3D04512D6F1 for ; Fri, 11 Mar 2016 10:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 uxRFnAV1VnC6 for ; Fri, 11 Mar 2016 10:44:24 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C33A12DA0C for ; Fri, 11 Mar 2016 10:44:24 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id r187so92318092oih.3 for ; Fri, 11 Mar 2016 10:44:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S9p5iKSkjS/Vj+UflBLwSTIFTe9sXbKHj3ybouoT6NA=; b=uX+ZrdqZmBU5fRkC68kx3L9GoPxLWRguHCf+gZnjWRzQwxwd1fxHzpetDUDoXapkIv y6qxk2RBRQ34Tf+MCvro2t0bsFd8fgORVq3vpMJNfiJAJa8UDOS+5qATSnrj0qA5U2Hm eXx/w0GwpPaEMR9EiQE9A8844k0K+ibZqwFBWIoAJMV7KSW1COaGxP/cY3uKlelIg3IZ laMCkr6Vomr/JEkIFgDT5po3Jzdx8nk2ffIemLFEyFKdepJV8Lt+16r73y2CywE2mFJv GgsWm9u75Kk2E3MJTUT2KlXU1bSIHb53whHLUtT6BIIsXl0cHCJkVEPiJeg+3tepupES 9VTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S9p5iKSkjS/Vj+UflBLwSTIFTe9sXbKHj3ybouoT6NA=; b=FYIaRYM8yhw3oGo/Y3r9E2mdtndoA/sFNtnlmF1aiqLfu4IKL6PeP9Lw8uTd4GLmIx 7y7s8BbTVJ39RpDfPbJCurU2bYj5M2AeikL1OLI70UDrKPcWHVuZybw5W0r/Ml3F1KvP rSxdtzFNrKin+KzgWyzoCEdhmJ3WxCIXLkQutPqmxy1aEfjD6QZJbUDS2JRNgMwaQAyf 4EhoL9YbFv1V3vEwmqq1a0Wq+xhJloqwky/vfpSPa/GJyEXoppOVab0QIB/nl/t3ZcqN x7ABTyoVdhrWXB5Olm85uQH1RyH8/N442GNWyHEhRzjS7uJmzrCdd6IhJqQMbro6ZBO8 TmQg== X-Gm-Message-State: AD7BkJJl0JkFRQNg1CH7XecLJNpcf2DpXTMG6IqhPEzJ5Y/ziVU0cKySyu15kP8hWDhhlusujaxayXOLUo4twA== X-Received: by 10.202.189.10 with SMTP id n10mr6444038oif.101.1457721864007; Fri, 11 Mar 2016 10:44:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.51.6 with HTTP; Fri, 11 Mar 2016 10:44:04 -0800 (PST) In-Reply-To: <56E284B6.10507@alvestrand.no> References: <56DEC8F5.4070101@alcatel-lucent.com> <56DF03D8.6070308@alum.mit.edu> <56DF30EF.7040404@alvestrand.no> <56DF925A.1050209@nteczone.com> <56E0381B.6030509@alcatel-lucent.com> <56E1C4AD.7000300@alvestrand.no> <56E234D5.9070301@alum.mit.edu> <56E284B6.10507@alvestrand.no> From: Ted Hardie Date: Fri, 11 Mar 2016 10:44:04 -0800 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a113d74c4e2b825052dca5102 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 18:44:26 -0000 --001a113d74c4e2b825052dca5102 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 11, 2016 at 12:41 AM, Harald Alvestrand wrote: > Den 11. mars 2016 04:00, skrev Paul Kyzivat: > > > The specification that sets up the registry seems like the logical place. > > Amending RFC 6455 (WebSocket), anyone? Errata? Updating document? > > Okay, the message asking if there is any heartburn on this change is in a moderation queue; I'll report back when I hear anything. A cursory glance at libwebsockets repo on github only shows case-sensitive matching during the pick function, but I still think folks would be happy to avoid the confusion. Ted --001a113d74c4e2b825052dca5102 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 11, 2016 at 12:41 AM, Harald Alvestrand <h= arald@alvestrand.no> wrote:
Den 11. mars 2016 04:00, skrev Paul Kyzivat:


The specification that sets up the registry seems like the logi= cal place.

Amending RFC 6455 (WebSocket), anyone? Errata? Updating document?


Okay, the message asking if there is any hea= rtburn on this change is in a moderation queue; I'll report back when I= hear anything.=C2=A0 A cursory glance at libwebsockets repo on github only= shows case-sensitive matching during the pick function, but I still think = folks would be happy to avoid the confusion.

Ted
--001a113d74c4e2b825052dca5102-- From nobody Fri Mar 11 11:13:46 2016 Return-Path: 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 A478712DAB3 for ; Fri, 11 Mar 2016 11:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 Q2tTIQgZ5n-2 for ; Fri, 11 Mar 2016 11:13:32 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1E212DABE for ; Fri, 11 Mar 2016 11:13:27 -0800 (PST) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-08v.sys.comcast.net with comcast id UjDQ1s00452QWKC01jDSCp; Fri, 11 Mar 2016 19:13:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-09v.sys.comcast.net with comcast id UjDS1s0023KdFy101jDSPh; Fri, 11 Mar 2016 19:13:26 +0000 To: rtcweb@ietf.org References: <56DEC8F5.4070101@alcatel-lucent.com> <56DF03D8.6070308@alum.mit.edu> <56DF30EF.7040404@alvestrand.no> <56DF925A.1050209@nteczone.com> <56E0381B.6030509@alcatel-lucent.com> <56E1C4AD.7000300@alvestrand.no> <56E234D5.9070301@alum.mit.edu> <56E284B6.10507@alvestrand.no> From: Paul Kyzivat Message-ID: <56E318D5.4020504@alum.mit.edu> Date: Fri, 11 Mar 2016 14:13:25 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457723606; bh=ICQ6ZOXfdmlg7clu1uqLZyBRi3ysmtYtNg0hF6XuVbc=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=PJ/o7Mr/cLuP3eW+smpk1zB6TauynMq9kX5ChKfO+UJfq5V2VjEYJAQvxX6Te86mK Vyjh1aGsGdp3hazxvbtuo13Sh/MIjD4eAv9HfScWWqWhRaEADZDGh4YH/wlzmYJKN4 6OM5E+Hd9/Kfp4C0H5+6IFPygs50sMrDJdSfG8Nvg9NtvHscRS44Fafm3hdJZ44wPD ncbQDIM7weo5/y6hdc2X+ec+Kn7BsNiDZfmYK2umK+pGwgjKpZq9jHEveDJLHZSzfE 2J57KxReQ/64NTpZsXAa8eO6zwV53kuuKbwdh7iuyuee6FY6oojbYIRoSICUeForaL l6Sv4mJnod+Vg== Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 19:13:43 -0000 On 3/11/16 1:44 PM, Ted Hardie wrote: > On Fri, Mar 11, 2016 at 12:41 AM, Harald Alvestrand > > wrote: > > Den 11. mars 2016 04:00, skrev Paul Kyzivat: > > > The specification that sets up the registry seems like the logical > place. > > Amending RFC 6455 (WebSocket), anyone? Errata? Updating document? > > > Okay, the message asking if there is any heartburn on this change is in > a moderation queue; I'll report back when I hear anything. A cursory > glance at libwebsockets repo on github only shows case-sensitive > matching during the pick function, but I still think folks would be > happy to avoid the confusion. Yes. I don't really care what the answer is as long as it is clear. Nor do I care what mechanism is used to clarify it. An erratum might be simplest if this sort of question is allowed to be handled that way. Thanks, Paul From nobody Fri Mar 11 11:18:31 2016 Return-Path: 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 D777C12DACD for ; Fri, 11 Mar 2016 11:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 2gneT6sPtGhy for ; Fri, 11 Mar 2016 11:18:28 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46E212DACB for ; Fri, 11 Mar 2016 11:18:28 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-05v.sys.comcast.net with comcast id UjHM1s00129Cfhx01jJT78; Fri, 11 Mar 2016 19:18:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-03v.sys.comcast.net with comcast id UjJT1s00C3KdFy101jJTQ5; Fri, 11 Mar 2016 19:18:27 +0000 To: rtcweb@ietf.org References: <56DEC8F5.4070101@alcatel-lucent.com> From: Paul Kyzivat Message-ID: <56E31A02.7010409@alum.mit.edu> Date: Fri, 11 Mar 2016 14:18:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457723907; bh=JDhjTDKh6/BxYV6S6eN+lFaLRF/vaSzJYdfE+6Z7cTE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ICTowy+hpLx7Ho1Gsf4xt5KdPPH5rKisZ/dc+RmO7sQWxz9CVdN6qLGYf3ePZ/xXT qNXULbAqhghJalZSDBqWVeqWtu35j+kfmN8rlc5ThuiyUhKvEYUh+/d9FjrRyjW1oc L61iX+oj3wM4ke4W5ZZx5HXP4VzL9rFy2Sap5i+D8b3XH14QXTg9S8v4r3nx0CG79i MD+aJwBAf3xjD1dHj9pVArP1MPKE93880mLDfVoaW/ZWYYom0RTp1zShm59W+c1g7Q 1+zsoWrgocWyy8LOk5gmHW4zbj1TlCm6F+2FfKVmK4TO0Y6Y4kP3tvv4vjiRGbCXoh J/l29144SPurw== Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-data-protocol - DCEP: Is the "Protocol" value case sensitive? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 19:18:30 -0000 On 3/9/16 7:12 AM, Tim Panton wrote: > >> On 8 Mar 2016, at 12:43, Juergen Stoetzer-Bradler >> > > wrote: >> >> Hello, >> >> If a WebRTC endpoint uses the data channel establishment protocol in >> order to open a data channel, it may add a non-empty protocol >> identifier to the DATA_CHANNEL_OPEN message. Is the endpoint, which >> receives this DATA_CHANNEL_OPEN message, assumed to process this >> protocol id string in a case sensitive or case insensitive way? Or >> would that actually be up to the receiving WebRTC endpoint's >> implementation? > > Since the sub-protocol definition in websockets seems to be > non-normative, this feels like a matter we can leave to post 1.0 . > >> >> As far as I see draft-ietf-rtcweb-data-protocol doesn't seem to >> specify this. >> >> Background is draft-ietf-mmusic-data-channel-sdpneg, where the >> subprotocol identifiers are signaled as part of an SDP attribute and >> where it is not yet clarified if these identifiers are assumed to be >> case sensitive or case insensitive. > > Im not sure I understand the point of > draft-ietf-mmusic-data-channel-sdpneg - > I think the new data contained in the offer SDP is exactly that in the > DCEP Open - and the > answer' contains nothing other than an ACK or NACK of that offer? > That being the case, why doesnt the offer side just open a DataChannel > with the > required parameters and see if it gets ACK or reset back - no > additional SDP needed ? Note that DCEP is *optional* for data channels. The alternative is to externally agree on the use of channels. This is what the draft provides for. Thanks, Paul From nobody Fri Mar 11 15:28:32 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DA412DDEF; Fri, 11 Mar 2016 15:05:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230531.15028.33668.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:31 -0800 Archived-At: X-Mailman-Approved-At: Fri, 11 Mar 2016 15:28:31 -0800 Cc: rtcweb@ietf.org Subject: [rtcweb] rtcweb - Requested sessions have been scheduled for IETF 95 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:31 -0000 Dear Ted Hardie, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. rtcweb Session 1 (2:00:00) Friday, Morning Session I 1000-1200 Room Name: Pacifico A size: 300 --------------------------------------------- rtcweb Session 2 (1:00:00) Tuesday, Afternoon Session II 1620-1720 Room Name: Pacifico A size: 300 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Real-Time Communication in WEB-browsers Area Name: Applications and Real-Time Area Session Requester: Ted Hardie Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 150 Conflicts to Avoid: First Priority: netvc dice tls rmcat aqm avtcore avtext clue dispatch httpbis stir acme mmusic payload sipcore opsawg perc ianaplan capport Second Priority: dprive tcpinc straw drinks tsvwg tsvarea dane ace uta maprg Third Priority: insipid irtfopen Special Requests: Apologies for the long set of conflicts. If possible, we would like meeting 1 and meeting 2 to have a day (or more) between them, as we often see resolutions hammered out between sessions. Thanks! --------------------------------------------------------- From nobody Tue Mar 15 09:06:34 2016 Return-Path: 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 88E8C12D5B8 for ; Tue, 15 Mar 2016 09:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2uOo88WBCsDu for ; Tue, 15 Mar 2016 09:06:31 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CC4A12DC7C for ; Tue, 15 Mar 2016 09:06:09 -0700 (PDT) Received: by mail-ob0-x231.google.com with SMTP id ts10so22132187obc.1 for ; Tue, 15 Mar 2016 09:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=GuNDVUV2SfYAZtx0xxq9wQQAXVskIaq4+WRGl7AbIwk=; b=SS4gUCdAu5OfSAlnT6r+gYWGj5ZjHMfrX0KIzlXqAeY5dmUIWxxksyqhsNuudfBmSG JbFyQ/8QE40v382JRBrBqs4Q2KWZ5HxxokQBG4YstBjWfn7HSTbP+DjPNyG9qMJ6dbJw Hg2rhIKkeq8CW42155Th/HYHO2JMC/V6lHsM2nBB6CsvfOURirKRNL0IzgH8/Vq8jSJ0 oNqKXxtcPvoaBzA3IIQ7CfPB2HQtY14ejfQQlSKNgalR/bef1mt5a4nEjGw/cS7hnTZa JR5Nwexr5mhwVjYV+CuwbgWSnL5BuX2ggLI3k9GvU7EHckYqKyP+xvR1MbXgSq9EjpR+ +29g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GuNDVUV2SfYAZtx0xxq9wQQAXVskIaq4+WRGl7AbIwk=; b=al/9n6r4mH0mUOhcWi9z8yOSxaK8BrgavX/5nBWxERdMq8LfstCIrZVA3o1CnymFV8 dEj1OAVNy9xGnbp+U0ftZCVu7s6ulfFh9qobvlPnx/cfoEY4jlrTIVVNI5WRBb7jNv0w TZVyw6QHtV/Kr7BnWYyLg+qzCEGb9HwXYrcmN64dCurlFH22Gum5NzFQitL2MnLY5ufl 0xrQOKwZuHz6Bo0T/jj+0K2G5haHY+UK1gR9q3Zhe2+arvLbOY8V4xKYyl9qM2wn/Q5s g0motWt5lXSGzeC1aUJb55qil285JW6fOscDTEtzOOqw1KXAPSj54t82jyvn8LX39h6u mnug== X-Gm-Message-State: AD7BkJJXIQKkFYOGdc2Q2d5K+WPWjkIgX6FQ35APDI6PfF8uCiAa8r1KcYEluonoQbTdmaoagY4HfwD7MEPNsA== X-Received: by 10.60.227.105 with SMTP id rz9mr18823282oec.72.1458057968689; Tue, 15 Mar 2016 09:06:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.51.6 with HTTP; Tue, 15 Mar 2016 09:05:49 -0700 (PDT) From: Ted Hardie Date: Tue, 15 Mar 2016 09:05:49 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a1134c97a493506052e189353 Archived-At: Subject: [rtcweb] Sub-protocol registry update X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 16:06:33 -0000 --001a1134c97a493506052e189353 Content-Type: text/plain; charset=UTF-8 So, I'll wait a day or two more for objections, but folks on the websockets side seem to be generally okay with this text: "The tokens registered in the Websockets sub-protocol registry created by RFC 6445 Section 11.5 are matched using case-sensitive string match. IANA is, however, instructed to decline registrations in the registry which differ only as to case, in order to minimize potential confusion among different registered versions. For other useful advice on avoiding collision, registrants are encourage to consult the non-normative section 1.9 of RFC 6445." (See the thread starting here: https://mailarchive.ietf.org/arch/msg/hybi/Ax-UqERaQ1P8KDzroBTQYhocjt0. Note especially Takeshi Yoshino's note, which points out that even websockets needs this clarification, as the behavior of Chrome and Firefox differs. ) I think the cleanest approach here is a very short update to RFC 6445. Anyone on this list have heartburn with that approach to resolving this? regards, Ted --001a1134c97a493506052e189353 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So, I'll wait a day or two more for obj= ections, but folks on the websockets side seem to be generally okay with th= is text:

"The tokens registered in the Websockets sub-protocol = registry created=20 by RFC 6445 Section 11.5 are matched using case-sensitive string match.=C2= =A0 IANA is, however, instructed to decline registrations in the registry=20 which differ only as to case, in order to minimize potential confusion=20 among different registered versions.=C2=A0 For other useful advice on=20 avoiding collision, registrants are encourage to consult the=20 non-normative section 1.9 of RFC 6445."

(See the thread s= tarting here:=C2=A0 https://mailarchive.ietf.org/arch/msg/hybi/Ax-U= qERaQ1P8KDzroBTQYhocjt0.=C2=A0 Note especially Takeshi Yoshino's no= te, which points out that even websockets needs this clarification, as the = behavior of Chrome and Firefox differs. )

I think the cleanest appr= oach here is a very short update to RFC 6445.=C2=A0 Anyone on this list hav= e heartburn with that approach to resolving this?

regards,
=
Ted

--001a1134c97a493506052e189353-- From nobody Tue Mar 15 11:39:02 2016 Return-Path: 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 66C9912D6B2 for ; Tue, 15 Mar 2016 11:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] 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 swLcMmCsNUFi for ; Tue, 15 Mar 2016 11:38:57 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE32812D629 for ; Tue, 15 Mar 2016 11:38:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B33B57C79A8 for ; Tue, 15 Mar 2016 19:38:53 +0100 (CET) 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 O0lhHDP9PZNe for ; Tue, 15 Mar 2016 19:38:52 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:79bd:223c:1078:159b]) by mork.alvestrand.no (Postfix) with ESMTPSA id 7FF5A7C7A2A for ; Tue, 15 Mar 2016 19:38:51 +0100 (CET) To: rtcweb@ietf.org References: From: Harald Alvestrand Message-ID: <56E856BB.4080502@alvestrand.no> Date: Tue, 15 Mar 2016 19:38:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050200040201090907000702" Archived-At: Subject: Re: [rtcweb] Sub-protocol registry update X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 18:39:00 -0000 This is a multi-part message in MIME format. --------------050200040201090907000702 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 03/15/2016 05:05 PM, Ted Hardie wrote: > So, I'll wait a day or two more for objections, but folks on the > websockets side seem to be generally okay with this text: > > "The tokens registered in the Websockets sub-protocol registry created > by RFC 6445 Section 11.5 are matched using case-sensitive string > match. IANA is, however, instructed to decline registrations in the > registry which differ only as to case, in order to minimize potential > confusion among different registered versions. For other useful > advice on avoiding collision, registrants are encourage to consult the > non-normative section 1.9 of RFC 6445." > > (See the thread starting here: > https://mailarchive.ietf.org/arch/msg/hybi/Ax-UqERaQ1P8KDzroBTQYhocjt0. > Note especially Takeshi Yoshino's note, which points out that even > websockets needs this clarification, as the behavior of Chrome and > Firefox differs. ) > > I think the cleanest approach here is a very short update to RFC > 6445. Anyone on this list have heartburn with that approach to > resolving this? I'm very happy with this approach and resolution. > > regards, > > Ted > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --------------050200040201090907000702 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 03/15/2016 05:05 PM, Ted Hardie wrote:
So, I'll wait a day or two more for objections, but folks on the websockets side seem to be generally okay with this text:

"The tokens registered in the Websockets sub-protocol registry created by RFC 6445 Section 11.5 are matched using case-sensitive string match. IANA is, however, instructed to decline registrations in the registry which differ only as to case, in order to minimize potential confusion among different registered versions. For other useful advice on avoiding collision, registrants are encourage to consult the non-normative section 1.9 of RFC 6445."

(See the thread starting here: https://mailarchive.ietf.org/arch/msg/hybi/Ax-UqERaQ1P8KDzroBTQYhocjt0. Note especially Takeshi Yoshino's note, which points out that even websockets needs this clarification, as the behavior of Chrome and Firefox differs. )

I think the cleanest approach here is a very short update to RFC 6445. Anyone on this list have heartburn with that approach to resolving this?

I'm very happy with this approach and resolution.


regards,

Ted



_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--------------050200040201090907000702-- From nobody Tue Mar 15 12:55:54 2016 Return-Path: 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 A0BFD12DD49; Tue, 15 Mar 2016 12:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.522 X-Spam-Level: X-Spam-Status: No, score=-114.522 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 DJyMPHLfwT9T; Tue, 15 Mar 2016 12:48:00 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A719B12DD48; Tue, 15 Mar 2016 12:47:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2673; q=dns/txt; s=iport; t=1458071278; x=1459280878; h=from:to:cc:subject:date:message-id:mime-version; bh=QyfZs2yAYtYdSpPMUuibQCzIlQz5z0a0RBXeMweAQD4=; b=JXcWkOJ7Du50bBRpPLH5N7hlMGcr712xdbhX8CwEPZj0Cp9bi/yxDVbp YUWRS4V7eEwmX7LGH9nyTaE/8aSuAiu08HrNg5mHZlt9GK+9GDfoZ1mPZ EmaOMjgvKqE3ju+Wtc1f/CXPk+NPrrvXguWL2IGf7KXHs4MaY4KJgXxW4 s=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJBQCdZehW/4ENJK1eg0aBSLpXgW6GD?= =?us-ascii?q?YE+ORMBAQEBAQEBZBwLhEQEaw4SAYEAJwQOE4gZvmcBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEQCIgNijWBDwWXTwGDG4FmiH+PBY5+ASICPoIDGYFJihIEOX4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,340,1454976000"; d="asc'?scan'208";a="249846297" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Mar 2016 19:47:57 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u2FJlvgg028138 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Mar 2016 19:47:57 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Mar 2016 14:47:56 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1104.009; Tue, 15 Mar 2016 14:47:56 -0500 From: "Fred Baker (fred)" To: "ops-dir@ietf.org" Thread-Topic: Operational Review of draft-ietf-rtcweb-audio Thread-Index: AQHRfvOSYsHU717oaUOEajRs5b51pg== Date: Tue, 15 Mar 2016 19:47:56 +0000 Message-ID: <21D848A1-9D2F-46F5-AB78-85DDBC09E809@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.117] Content-Type: multipart/signed; boundary="Apple-Mail=_CD19AEC8-9F4D-4154-90C0-9F1C0A0665DC"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 15 Mar 2016 12:55:53 -0700 Cc: "rtcweb@ietf.org" , "draft-ietf-rtcweb-audio.all@tools.ietf.org" Subject: [rtcweb] Operational Review of draft-ietf-rtcweb-audio X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2016 19:48:01 -0000 --Apple-Mail=_CD19AEC8-9F4D-4154-90C0-9F1C0A0665DC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have reviewed this document as part of the Operational directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written with the intent of improving the operational = aspects of the IETF drafts. Comments that are not addressed in last call = may be included in AD reviews during the IESG review. Document editors = and WG chairs should treat these comments just like any other last call = comments. I will start with a disclaimer on my own expertise; the draft has to do = with codec requirements - availability of codecs, echo cancelling = characteristics, DMTF signals, comfort noise, and so on. I can't say I = personally know much about any of those. That said, I don't think = network operators deal with those much either; they are part of the = payload. I suspect, therefore, that the draft has little impact that would affect = a network operator unless that operator was dealing specifically with a = WebRTC application. If the operator is dealing with such an application, = the fact that it requires a common codec, and only requires one, seems = reasonable. As such, I think the draft is ready with one nit. The nit point is the reference to I-D.ietf-payload-rtp-opus. That draft = has been published as RFC 7587, and should be referred to accordingly. --Apple-Mail=_CD19AEC8-9F4D-4154-90C0-9F1C0A0665DC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVuhm60ayAOS/EQ8MAQJZURAAvUOkuFpuS2KBD+b1wyDg+WqBefBpAV/8 kryibOoGaCjfwNHywZ87R1HbOOcDs7EOzx+1Faq2DUgzXyjZJzAhbngMLRLf7Ao0 FspZxGxYvxt3e66YHo+1uaYVz3hVxQGSjWOPnlQ2NrafLytMAPMRJNz8HAplelQu 2Irn4QuU6CYejIVXox9gHq5ioCAb5ZyvxlbY4S25PP4ogr5TfhT3/D3lLtZpcj51 xWtVfc+7dn7JK4MrTyqCsjp1ByTKmQpuwFrrB5j/56noESHDZsQK0z390OMSsBf1 1mKqbhEkYdYWM5ASEqKBcW0Y/KCqldUZ+QEjcQjOZEqiLz97Nh56WNFraQyGF+iS jeL885ApGIXJafGNlSMOkMKNbJfPXn0t4BVcD58NHj1x82KbY3HrOi+viK3X4ONR 0KTknFj90HdQ/U9LHeNwj3ONHqEu22o0Fu/ksBO1gZZ6WIS4DELoi0M5QRL4XGwR xtlLjXK7kSjZlcBDMRgYmBcHciKZJ44j1jdjo/zKhL0+2IoA7SXibEEhJt4r1XUF LtuD3b6rVSjug9m8c6uId9NNK8suJWxci08HoxDVSFIzc+J3FADmc2yAINI1ksAe VRt24hyS2QyQnKaoV8brz4ES4f02gM3c9W9bUlIAB1uZpIqjJGxe+cCxapIVZtsf JzFlsGxzdk4= =tw8c -----END PGP SIGNATURE----- --Apple-Mail=_CD19AEC8-9F4D-4154-90C0-9F1C0A0665DC-- From nobody Tue Mar 15 18:04:28 2016 Return-Path: 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 6595B12D816 for ; Tue, 15 Mar 2016 18:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 tUxrawfbk_Qk for ; Tue, 15 Mar 2016 18:04:12 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E6812DEBD for ; Tue, 15 Mar 2016 18:04:10 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id g203so45572903iof.2 for ; Tue, 15 Mar 2016 18:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=9HY6mfo6h+L/DbW0DaIQlCoUz8WvHxKSN9VRQXEyqDU=; b=IMmG1ua3Gkz3b1Hn8hgw1lRxfCgd7HoQNFTdck046hEFx9p1QdoWGn6M85J7D7+Uv2 w1IlbtEmH0rTaPiQEF3nyYNB46/13XulYYdyavjVphGO0iB9hRcf22ml2QwtLtrcdIVz 8kQXiIj1vFc4cQwphJ00Kw2IqTHKvzvL8ubyZcEeawcDTThE/9NTKolPwbL3PQYtQPRE AWGAqWLd3xmUHOTevSA1GekjENjuEnTF9Pxm1q0S86Abhuf1kC+KK6ZLsB1KkHWw2LGT BFnIlBVF2nnOXcMJWbI6y0sIk10u/zsd4OIPq0vVZPk9Tq0bAG+iN55Uc1/8mVFAbVb7 rgyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=9HY6mfo6h+L/DbW0DaIQlCoUz8WvHxKSN9VRQXEyqDU=; b=F8OBiiwqAbgXWmiAvtl73zhF3VFux12ljTEWkKm8FlPPIxJxyeUQYghoptVU2hSO44 HVt9HzvSaeOhXtKOurMT+ZbuJnfieP/Xb4DOIm46hhkZ4+zHPAR1bxL55jki/JY+SEgK C3F9H0+rLYMSlkmtyGbZnKDDErq5Pzgj2IAOCD/jmhVKn1+/t8rNvxKK1IDvgrSnKPU2 1ytCewBbW76xHFxKFxPOI3krq+9Vzx3UEcc51wtsaPwwROAkxZ32NoLYIZmpLG0WqPsn nRA+gJoZBZjn0GqAFitAwaYPZjDI8h2voDAvxHpgQNMpBktr8Jx6PVlhy9OGxCsk5r18 Ljxg== X-Gm-Message-State: AD7BkJLGd8JKf8+c2NR6BfqIVL5Fhg+B+ucVlabpXsQQCx4eBlQITJiNb4N+/kw3KWffdgB54KYNLQbUsch47Q== MIME-Version: 1.0 X-Received: by 10.107.131.105 with SMTP id f102mr1721518iod.190.1458090249390; Tue, 15 Mar 2016 18:04:09 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Tue, 15 Mar 2016 18:04:09 -0700 (PDT) In-Reply-To: <56E856BB.4080502@alvestrand.no> References: <56E856BB.4080502@alvestrand.no> Date: Wed, 16 Mar 2016 12:04:09 +1100 Message-ID: From: Martin Thomson To: Harald Alvestrand Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Sub-protocol registry update X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 01:04:19 -0000 This looks fine. I checked. I shouldn't have checked. "(=E2=95=AF=C2=B0=E2=96=A1=C2=B0=EF=BC=89=E2=95=AF=EF=B8=B5 =E2=94=BB=E2=94= =81=E2=94=BB)" is a valid subprotocol name according to both the WebRTC spec and draft-ietf-rtcweb-data-protocol-09. However, this is not permitted in thewebsocketprotocol. RFC 6455 says that I can't register it, but what happens if I try to use it? FWIW, I have no problem whatsoever with the protocol accepting more values than might be permitted elsewhere. But we should confirm that this is fine; acknowledging the highly advanced state of the protocol document (RFC editor queue, MISSREF). Maybe our friends in the WebRTC WG in the W3C (whoever they are) should address this. On 16 March 2016 at 05:38, Harald Alvestrand wrote: > On 03/15/2016 05:05 PM, Ted Hardie wrote: > > So, I'll wait a day or two more for objections, but folks on the websocke= ts > side seem to be generally okay with this text: > > "The tokens registered in the Websockets sub-protocol registry created by > RFC 6445 Section 11.5 are matched using case-sensitive string match. IAN= A > is, however, instructed to decline registrations in the registry which > differ only as to case, in order to minimize potential confusion among > different registered versions. For other useful advice on avoiding > collision, registrants are encourage to consult the non-normative section > 1.9 of RFC 6445." > > (See the thread starting here: > https://mailarchive.ietf.org/arch/msg/hybi/Ax-UqERaQ1P8KDzroBTQYhocjt0. > Note especially Takeshi Yoshino's note, which points out that even > websockets needs this clarification, as the behavior of Chrome and Firefo= x > differs. ) > > I think the cleanest approach here is a very short update to RFC 6445. > Anyone on this list have heartburn with that approach to resolving this? > > > I'm very happy with this approach and resolution. > > > regards, > > Ted > > > > _______________________________________________ > 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 > From nobody Wed Mar 16 00:49:48 2016 Return-Path: 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 2580F12D4FF for ; Wed, 16 Mar 2016 00:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 jV5_Ce38U9yz for ; Wed, 16 Mar 2016 00:49:45 -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 9611D12D528 for ; Wed, 16 Mar 2016 00:49:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E4CF47C79A0; Wed, 16 Mar 2016 08:49:42 +0100 (CET) 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 vw8Xwxh2twHk; Wed, 16 Mar 2016 08:49:42 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:79bd:223c:1078:159b]) by mork.alvestrand.no (Postfix) with ESMTPSA id 048547C7976; Wed, 16 Mar 2016 08:49:42 +0100 (CET) To: Martin Thomson References: <56E856BB.4080502@alvestrand.no> From: Harald Alvestrand Message-ID: <56E91015.7040509@alvestrand.no> Date: Wed, 16 Mar 2016 08:49:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Sub-protocol registry update X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 07:49:47 -0000 On 03/16/2016 02:04 AM, Martin Thomson wrote: > This looks fine. I checked. > > I shouldn't have checked. > > "(╯°□°）╯︵ ┻━┻)" is a valid subprotocol name according to both the > WebRTC spec and draft-ietf-rtcweb-data-protocol-09. However, this is > not permitted in thewebsocketprotocol. RFC 6455 says that I can't > register it, but what happens if I try to use it? I don't think RFC 6455 restricts you to using registered values in the protocol field - in fact section 1.9 contains the typical language of someone who thinks that using a domain name as part of an identifier is enough for uniqueness (which is true for such a large fraction of cases that in most cases, the failures caused by this are far down the list of issues one has to deal with). So if you send "(╯°□°）╯︵ ┻━┻)" to me, dealing with it is my problem. As long as I can find any commas in it, I'm OK. > > FWIW, I have no problem whatsoever with the protocol accepting more > values than might be permitted elsewhere. But we should confirm that > this is fine; acknowledging the highly advanced state of the protocol > document (RFC editor queue, MISSREF). > > Maybe our friends in the WebRTC WG in the W3C (whoever they are) > should address this. > > On 16 March 2016 at 05:38, Harald Alvestrand wrote: >> On 03/15/2016 05:05 PM, Ted Hardie wrote: >> >> So, I'll wait a day or two more for objections, but folks on the websockets >> side seem to be generally okay with this text: >> >> "The tokens registered in the Websockets sub-protocol registry created by >> RFC 6445 Section 11.5 are matched using case-sensitive string match. Of course "case-sensitive string match" is not well defined either :-) (cue the dragons of NFC vs NFKC vs no-normalization). But it's well defined for the ASCII subset that can be registered, which I regard as "good enough". >> IANA >> is, however, instructed to decline registrations in the registry which >> differ only as to case, in order to minimize potential confusion among >> different registered versions. For other useful advice on avoiding >> collision, registrants are encourage to consult the non-normative section >> 1.9 of RFC 6445." >> >> (See the thread starting here: >> https://mailarchive.ietf.org/arch/msg/hybi/Ax-UqERaQ1P8KDzroBTQYhocjt0. >> Note especially Takeshi Yoshino's note, which points out that even >> websockets needs this clarification, as the behavior of Chrome and Firefox >> differs. ) >> >> I think the cleanest approach here is a very short update to RFC 6445. >> Anyone on this list have heartburn with that approach to resolving this? >> >> >> I'm very happy with this approach and resolution. >> >> >> regards, >> >> Ted >> >> >> >> _______________________________________________ >> 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 >> From nobody Wed Mar 16 07:57:43 2016 Return-Path: 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 023E712D6F5 for ; Wed, 16 Mar 2016 07:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1kIDhL13Umct for ; Wed, 16 Mar 2016 07:57:39 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA4C812D532 for ; Wed, 16 Mar 2016 07:57:38 -0700 (PDT) Received: by mail-ob0-x22c.google.com with SMTP id m7so53237091obh.3 for ; Wed, 16 Mar 2016 07:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pvdarYLBUEVTj0qYugwVEIBkEyoxbSkTyyQ3DbfFWxk=; b=YRNdnRTzSbSmVdtCiCQXVCJLn7acCwCDa5Ui17sF8EAvuHkq1uICX/yQx3QBc7ypyx Yhha3jSUV4koqDPhFLvUlKwF9+MRPoyCy8MXz/LCFOxv/EPEcYJx7E7MTBB74TCq40QL pfysRIvY10HnJITKQN8VAPAdcr4mcibNI3Ul6X33vlt2ZGyXV2E//0q00i+rXeNeoHOB DDOSbwzxjAlu9+7mRB3eh5tSEEqLypMD80VRRFsCAyg/lopbzvMnLVifd7BE/nSZ0gAm j3BimhaaQ2NTQxaL/6HGenT5NwN4+/UKpLy0pQNP1uh8cGgF1/wNlZuo5pRLAppczGF7 g5cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pvdarYLBUEVTj0qYugwVEIBkEyoxbSkTyyQ3DbfFWxk=; b=dEHRrVNKZA+GyybnnnD2atg18g8tE6PwC8TopGB+7njcI1AbJfYzxVKgPR8lf08igi 2OvJz4B6EgnQ9pn1VLZpmEMqF26RKucEYPWS66C8dg4jj8hzXmE164zw0im8iCuqo4TP mSOmvUeZxMoTk6JDVnN+drc4+mXiQ6ObYVehdXJRpaA2FeN9Si5TWviPoaC2enhYIobw Gfy65Tm/8nqq/8EbewnMG6xKEZSDcIf1U5yqvLYXgQ1Seo8VmkOJF62lVF7FFxKeRdC2 Fo4KUDgtULK12pkfHfPqlAxK+wv8TZtLTO84BAgVqGIYX16AtkSXK0j22XZljifWL2kG VSFg== X-Gm-Message-State: AD7BkJKHH8vTgihYSuv9Yoiunbn5ulF9C6VMuC0ByL7lHek5gA8e6z0dlxg9EumG1pYRVojpkImW1FnqX3n2NQ== X-Received: by 10.182.107.137 with SMTP id hc9mr2577851obb.74.1458140258005; Wed, 16 Mar 2016 07:57:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.51.6 with HTTP; Wed, 16 Mar 2016 07:57:17 -0700 (PDT) In-Reply-To: <56E91015.7040509@alvestrand.no> References: <56E856BB.4080502@alvestrand.no> <56E91015.7040509@alvestrand.no> From: Ted Hardie Date: Wed, 16 Mar 2016 07:57:17 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=089e011763bb1c789f052e2bbc83 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Sub-protocol registry update X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 14:57:41 -0000 --089e011763bb1c789f052e2bbc83 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 16, 2016 at 12:49 AM, Harald Alvestrand wrote: > On 03/16/2016 02:04 AM, Martin Thomson wrote: > > > So if you send "(=E2=95=AF=C2=B0=E2=96=A1=C2=B0=EF=BC=89=E2=95=AF=EF=B8= =B5 =E2=94=BB=E2=94=81=E2=94=BB)" to me, dealing with it is my problem. > As long as I can find any commas in it, I'm OK. > > Of course "case-sensitive string match" is not well defined either :-) > (cue the dragons of NFC vs NFKC vs no-normalization). > But it's well defined for the ASCII subset that can be registered, which > I regard as "good enough". > > I could replace that with one of the PRECIS definitions, but my personal take is that it will be confusing, given that only ASCII can be registered. But If you'd like a citable reference, we could also call it simple string comparison, and cite RFC 3986 section 6.2.1. I personally like that term because it "simple string comparison" seemed likely to invite confusion, but it would work for anyone who followed the reference. So, I think the simplest description that works for the registry is "case-sensitive string match", but I will shift as needed. Ted > >> IANA > >> is, however, instructed to decline registrations in the registry which > >> differ only as to case, in order to minimize potential confusion among > >> different registered versions. For other useful advice on avoiding > >> collision, registrants are encourage to consult the non-normative > section > >> 1.9 of RFC 6445." > >> > >> (See the thread starting here: > >> https://mailarchive.ietf.org/arch/msg/hybi/Ax-UqERaQ1P8KDzroBTQYhocjt0= . > >> Note especially Takeshi Yoshino's note, which points out that even > >> websockets needs this clarification, as the behavior of Chrome and > Firefox > >> differs. ) > >> > >> I think the cleanest approach here is a very short update to RFC 6445. > >> Anyone on this list have heartburn with that approach to resolving thi= s? > >> > >> > >> I'm very happy with this approach and resolution. > >> > >> > >> regards, > >> > >> Ted > >> > >> > >> > >> _______________________________________________ > >> 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 > --089e011763bb1c789f052e2bbc83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 16, 2016 at 12:49 AM, Harald Alvestrand <h= arald@alvestrand.no> wrote:
On = 03/16/2016 02:04 AM, Martin Thomson wrote:


So if you send=C2=A0 "(=E2=95=AF=C2=B0=E2=96=A1=C2=B0=EF=BC=89=E2=95= =AF=EF=B8=B5 =E2=94=BB=E2=94=81=E2=94=BB)" to me, dealing with it is m= y problem.
As long as I can find any commas in it, I'm OK.

Of course "case-sensitive string match" is not well define= d either :-)
(cue the dragons of NFC vs NFKC vs no-normalization).
But it's well defined for the ASCII subset that can be registered, whic= h
I regard as "good enough".

I= could replace that with one of the PRECIS definitions, but my personal tak= e
is that it will be confusing, given that only ASCII can be = registered.=C2=A0 But If you'd
like a citable reference, = we could also call it simple string comparison, and cite
RFC = 3986 section 6.2.1.=C2=A0 I personally like that term because it "simp= le string comparison"
seemed likely to invite confusion, but it wo= uld work for anyone who followed the
reference.

=
So, I think the simplest description that works for the registry is &q= uot;case-sensitive string match",
but I will shift as ne= eded.

Ted
=C2=A0
>>=C2=A0 =C2=A0IANA
>> is, however, instructed to decline registrations in the registry w= hich
>> differ only as to case, in order to minimize potential confusion a= mong
>> different registered versions.=C2=A0 For other useful advice on av= oiding
>> collision, registrants are encourage to consult the non-normative = section
>> 1.9 of RFC 6445."
>>
>> (See the thread starting here:
>> https://mailarchive.i= etf.org/arch/msg/hybi/Ax-UqERaQ1P8KDzroBTQYhocjt0.
>> Note especially Takeshi Yoshino's note, which points out that = even
>> websockets needs this clarification, as the behavior of Chrome and= Firefox
>> differs. )
>>
>> I think the cleanest approach here is a very short update to RFC 6= 445.
>> Anyone on this list have heartburn with that approach to resolving= this?
>>
>>
>> I'm very happy with this approach and resolution.
>>
>>
>> regards,
>>
>> Ted
>>
>>
>>
>> _______________________________________________
>> 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

--089e011763bb1c789f052e2bbc83-- From nobody Wed Mar 16 12:47:59 2016 Return-Path: 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 BC38212D6CF for ; Wed, 16 Mar 2016 12:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 n1N1qDumMe8s for ; Wed, 16 Mar 2016 12:47:57 -0700 (PDT) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7E412D6EC for ; Wed, 16 Mar 2016 12:47:57 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-04v.sys.comcast.net with comcast id Wjmc1s0022D5gil01jnxJ9; Wed, 16 Mar 2016 19:47:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-06v.sys.comcast.net with comcast id Wjnw1s00J3KdFy101jnwGt; Wed, 16 Mar 2016 19:47:57 +0000 To: rtcweb@ietf.org References: <56E856BB.4080502@alvestrand.no> <56E91015.7040509@alvestrand.no> From: Paul Kyzivat Message-ID: <56E9B86C.8060806@alum.mit.edu> Date: Wed, 16 Mar 2016 15:47:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56E91015.7040509@alvestrand.no> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458157677; bh=HdYP5pjwWAE3zsQJvbc4/T3Q5o0jkjIYyre96EnlAVU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=VK+j0gY0ea+65oHGtNW1LMRm8qwv820cZ6P2tRqXim+RFO4Ovz1qyXLMSs0qMzucD ZnLygZ34lCMpu1t3Q81b4wpGfSZx5QGyZsNS44VSwgNUCah6iPYiySKUnZDz5n3/PD /vJn1NDLYVh8UuZPEpfkOf/HSB+OXfZJvxQTp+VR5zkB4nrSc1DntSuqnt0WTNP47B FRB35nB6tu2LoXNmlL4ZRdb+hytgJchnIxqv5XZnpUUhUSuF4DPvx1qQGfL5zqPOtE fnBXcoV8eCQX5YnUoHzlSJfWOP68N8cPfq5zj2RO4g5hr2jxfwvpCh7tS10NTbQGwr XLWSU2g/B3DfA== Archived-At: Subject: Re: [rtcweb] Sub-protocol registry update X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 19:47:58 -0000 On 3/16/16 3:49 AM, Harald Alvestrand wrote: >>> "The tokens registered in the Websockets sub-protocol registry created by >>> RFC 6445 Section 11.5 are matched using case-sensitive string match. > > Of course "case-sensitive string match" is not well defined either :-) > (cue the dragons of NFC vs NFKC vs no-normalization). > But it's well defined for the ASCII subset that can be registered, which > I regard as "good enough". How about "are matched byte-by-byte"? (Or bit-by-bit) Thanks, Paul From nobody Wed Mar 16 13:49:11 2016 Return-Path: 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 83A8A12D597 for ; Wed, 16 Mar 2016 13:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 oE_IkvMTe4xJ for ; Wed, 16 Mar 2016 13:49:06 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B94712D545 for ; Wed, 16 Mar 2016 13:49:05 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id m82so48252164oif.1 for ; Wed, 16 Mar 2016 13:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+hZhjTiJLQxj9/5hJJxpWHcE+TXtqgrxeAN6ZkDK3Bw=; b=bxdOeMJbHc4v2KFIqPrpSjTNZvb1SmfwPD74VU2DyLii+JVsG0qNUOqaYEeMJxjHmg mjJrM2JTW5enu26b5R3/f7K2tUOLqbsnAEEpFsMJSpkzs/jzLJ9FgYZkEc6ZLjJgp6gj HSliPPm2PqaTLcoGchCAe4d1TDWMspWyGNBpaBuW5ycakZUyd0Ij/nVeB5qXUQR1Iww1 2GHXKr/YB+ejdQLfKjNaYk4lU7+SUdQYQptvpLLtbp6bBaHz8K7WqI71UIEbbuuYk3Bl NU0zjyCpI/A9/pqRja5Iwrgxvx30d1TrVvs1TdettK2QxnBnR5jaguXTyR/77Z6nuNPw CX1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+hZhjTiJLQxj9/5hJJxpWHcE+TXtqgrxeAN6ZkDK3Bw=; b=bZLBuj9PN8SzKa92t/nA2Iw9XwE62+ivTcFiqzXXFYQOdGYZq2J5YzDURFTdoVPwzP vYztbFfgw7GWrfRoQQ6Z8KEm+3mO3Ij8cDflH8RlvXxKUubxxUG+DWLOq+LY0TF4RpFc xWrdvvPrXzAJG7jFPGEWrFOeZKKcxWeTlsXyh87dZLOIbl0ga8SQ/qgJqiZkAo1ft1mm avokOPO3oKpirrlQD/0hoNUN8+M7apdLZw3wPeHYzCUqQe+Mw01HLqCPoXdCbRLg0ecC jm7sFXOIVcpn4wfNNqvbqEGZFKcZHD4Ao0WKeSFBsw7gtpMY5qE+TQ6S6VDx4LT8Yso8 EcFA== X-Gm-Message-State: AD7BkJJjp/HJmzuF+OsOIWzdDJuA+YDVMkrvnUtWLFmHPOyn5paZsddg1ZhSBCG3IKNkeJtuCzT6DNzUUeav2g== X-Received: by 10.202.189.10 with SMTP id n10mr3712442oif.101.1458161345231; Wed, 16 Mar 2016 13:49:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.51.6 with HTTP; Wed, 16 Mar 2016 13:48:45 -0700 (PDT) In-Reply-To: <56E9B86C.8060806@alum.mit.edu> References: <56E856BB.4080502@alvestrand.no> <56E91015.7040509@alvestrand.no> <56E9B86C.8060806@alum.mit.edu> From: Ted Hardie Date: Wed, 16 Mar 2016 13:48:45 -0700 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a113d74c40228cc052e30a552 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Sub-protocol registry update X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 20:49:08 -0000 --001a113d74c40228cc052e30a552 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 16, 2016 at 12:47 PM, Paul Kyzivat wrote: > On 3/16/16 3:49 AM, Harald Alvestrand wrote: > > "The tokens registered in the Websockets sub-protocol registry created by >>>> RFC 6445 Section 11.5 are matched using case-sensitive string match. >>>> >>> >> Of course "case-sensitive string match" is not well defined either :-) >> (cue the dragons of NFC vs NFKC vs no-normalization). >> But it's well defined for the ASCII subset that can be registered, which >> I regard as "good enough". >> > > How about "are matched byte-by-byte"? (Or bit-by-bit) > > So, RFC 3986 actually goes into why that terminology is potentially confusing. Its reasoning likely does not apply here, because the issues when there is not a common character encoding; I think in this case octet-by-octet matching will be equivalent to case-sensitive string match. regards, Ted > Thanks, > Paul > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a113d74c40228cc052e30a552 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 16, 2016 at 12:47 PM, Paul Kyzivat <pky= zivat@alum.mit.edu> wrote:
On 3/16/16 3:49 AM, Harald Alvestrand wrote:

"The tokens registered in the Websockets sub-protocol registry created= by
RFC 6445 Section 11.5 are matched using case-sensitive string match.

Of course "case-sensitive string match" is not well defined eithe= r :-)
(cue the dragons of NFC vs NFKC vs no-normalization).
But it's well defined for the ASCII subset that can be registered, whic= h
I regard as "good enough".

How about "are matched byte-by-byte"? (Or bit-by-bit)

So, RFC 3986 actually goes into why that terminology = is potentially confusing.=C2=A0 Its reasoning likely does not apply here, b= ecause the issues when there is not a common character encoding; I think in= this case octet-by-octet matching will be equivalent to case-sensitive str= ing match.

regards,

Ted
<= pre class=3D"">
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb

--001a113d74c40228cc052e30a552-- From nobody Thu Mar 17 08:24:20 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B14112D98D; Thu, 17 Mar 2016 08:24:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160317152417.806.3053.idtracker@ietfa.amsl.com> Date: Thu, 17 Mar 2016 08:24:17 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-26.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 15:24:17 -0000 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 of the IETF. Title : Web Real-Time Communication (WebRTC): Media Transport and Use of RTP Authors : Colin Perkins Magnus Westerlund Joerg Ott Filename : draft-ietf-rtcweb-rtp-usage-26.txt Pages : 46 Date : 2016-03-17 Abstract: The Web Real-Time Communication (WebRTC) framework provides support for direct interactive rich communication using audio, video, text, collaboration, games, etc. between two peers' web-browsers. This memo describes the media transport aspects of the WebRTC framework. It specifies how the Real-time Transport Protocol (RTP) is used in the WebRTC context, and gives requirements for which RTP features, profiles, and extensions need to be supported. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-26 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-26 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/ From nobody Thu Mar 17 08:35:26 2016 Return-Path: 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 181C212D61C for ; Thu, 17 Mar 2016 08:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 11cmEGDVoYKe for ; Thu, 17 Mar 2016 08:35:17 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44CDB12D5BA for ; Thu, 17 Mar 2016 08:35:17 -0700 (PDT) Received: from [130.209.247.112] (port=49465 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1agZxC-0007fi-ES; Thu, 17 Mar 2016 15:35:15 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Colin Perkins In-Reply-To: <46276723-F9BF-4D5F-BDA3-76A00A8C27A1@sn3rd.com> Date: Thu, 17 Mar 2016 15:35:12 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9D74D454-3E42-4E7D-8EE1-B1075DB574F1@csperkins.org> References: <46276723-F9BF-4D5F-BDA3-76A00A8C27A1@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3112) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] time to revise rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 15:35:25 -0000 I=E2=80=99ve just submitted an update to the rtp-usage draft. It makes = three changes: - In Section 4.5, clarify that support for sending RTP and RTCP using = two separate transport layer flows is OPTIONAL.=20 - Change RTP Packet Stream to RTP Stream throughout, to align = terminology with RFC 7656. - Update references There=E2=80=99s a diff from the previous version at = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-rtcweb-rtp-usage-25&url2=3D= draft-ietf-rtcweb-rtp-usage-26 Colin > On 26 Feb 2016, at 15:33, Sean Turner wrote: >=20 > All, >=20 > Now that draft-ietf-mmusic-mux-exclusive is in WGLC over in MMUSIC = [0][1], the chairs of this WG think it=E2=80=99s time to revise = draft-ietf-rtcweb-rtp-usage with the text the WG discussed on list, = which was discussed in this thread [2]. Once the rtp-usage authors have = submitted a new draft, we'll be reconfirming the consensus on = draft-ietf-rtcweb-rtp-usage, i.e., we need to yank it back from the RFC = editor, make these changes, and then go through the process of getting = it back in the RFC editor=E2=80=99s queue. >=20 > Cheers, >=20 > spt >=20 > [0] = https://mailarchive.ietf.org/arch/msg/mmusic/KxrTeCaOF_LTDeWJtLKSP06nH9U > [1] And kudos to them for moving out so smartly. > [2] = https://mailarchive.ietf.org/arch/msg/rtcweb/Yb3NpKuKSKIxRYYqPMNoNvyuIrc > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins https://csperkins.org/ From nobody Thu Mar 17 10:52:39 2016 Return-Path: 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 DDB5F12D5EF for ; Thu, 17 Mar 2016 10:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] 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 bXHzXbohGuut for ; Thu, 17 Mar 2016 10:52:35 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C955A12D724 for ; Thu, 17 Mar 2016 10:51:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 1928F7C7A8A for ; Thu, 17 Mar 2016 18:51:03 +0100 (CET) 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 m5AktCtBV7V6 for ; Thu, 17 Mar 2016 18:51:02 +0100 (CET) Received: from hta-hippo.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:ca3:83c5:ee1e:bb31]) by mork.alvestrand.no (Postfix) with ESMTPSA id 3E1167C7A89 for ; Thu, 17 Mar 2016 18:51:02 +0100 (CET) To: rtcweb@ietf.org References: <56E856BB.4080502@alvestrand.no> <56E91015.7040509@alvestrand.no> <56E9B86C.8060806@alum.mit.edu> From: Harald Alvestrand Message-ID: <56EAEE85.5030701@alvestrand.no> Date: Thu, 17 Mar 2016 18:51:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040509090505000906080406" Archived-At: Subject: Re: [rtcweb] Sub-protocol registry update X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 17:52:38 -0000 This is a multi-part message in MIME format. --------------040509090505000906080406 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 03/16/2016 09:48 PM, Ted Hardie wrote: > On Wed, Mar 16, 2016 at 12:47 PM, Paul Kyzivat > wrote: > > On 3/16/16 3:49 AM, Harald Alvestrand wrote: > > "The tokens registered in the Websockets sub-protocol > registry created by > RFC 6445 Section 11.5 are matched using case-sensitive > string match. > > > Of course "case-sensitive string match" is not well defined > either :-) > (cue the dragons of NFC vs NFKC vs no-normalization). > But it's well defined for the ASCII subset that can be > registered, which > I regard as "good enough". > > > How about "are matched byte-by-byte"? (Or bit-by-bit) > > So, RFC 3986 actually goes into why that terminology is potentially > confusing. Its reasoning likely does not apply here, because the > issues when there is not a common character encoding; I think in this > case octet-by-octet matching will be equivalent to case-sensitive > string match. Octet-by-octet will be equivalent to case-sensitive string match with no normalization before comparision - we already know the strings will be UTF-8 (happily). > > regards, > > Ted > > > Thanks, > Paul > > > _______________________________________________ > 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 --------------040509090505000906080406 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 03/16/2016 09:48 PM, Ted Hardie wrote:
On Wed, Mar 16, 2016 at 12:47 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 3/16/16 3:49 AM, Harald Alvestrand wrote:

"The tokens registered in the Websockets sub-protocol registry created by
RFC 6445 Section 11.5 are matched using case-sensitive string match.

Of course "case-sensitive string match" is not well defined either :-)
(cue the dragons of NFC vs NFKC vs no-normalization).
But it's well defined for the ASCII subset that can be registered, which
I regard as "good enough".

 How about "are matched byte-by-byte"? (Or bit-by-bit)

So, RFC 3986 actually goes into why that terminology is potentially confusing. Its reasoning likely does not apply here, because the issues when there is not a common character encoding; I think in this case octet-by-octet matching will be equivalent to case-sensitive string match.

Octet-by-octet will be equivalent to case-sensitive string match with no normalization before comparision - we already know the strings will be UTF-8 (happily).



regards,

Ted
Thanks,
Paul


_______________________________________________
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

--------------040509090505000906080406-- From nobody Thu Mar 17 15:39:21 2016 Return-Path: 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 5CBD812DD63 for ; Thu, 17 Mar 2016 15:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 KQr2k5Ywp6qA for ; Thu, 17 Mar 2016 15:39:18 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DAA012DD61 for ; Thu, 17 Mar 2016 15:39:18 -0700 (PDT) Received: by mail-qg0-x22d.google.com with SMTP id w104so85464875qge.1 for ; Thu, 17 Mar 2016 15:39:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nmOubazNx3zOTVZoYF8+ntJBTA8uzHb/8PzXn89WgP4=; b=PJYKROarDSOGM1q1KjCXmNqHml5DTS31RS851pmW/mCNLHu3nckW8M9J5wzDiXoxhO YuuBGOatRHMx+BmdgbEX2z6i9V2MdfwGbdDvkvcWsMHF9Q4NlRp/R8d/4t3Q5WuaOA23 HChDinXXm/YQH9xT0LJ8kRtLr/rke4y06YxDw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nmOubazNx3zOTVZoYF8+ntJBTA8uzHb/8PzXn89WgP4=; b=mzCkoBPeTDV7IqrP5XhY/v6/EAsDNofZwGslU4c0tBFS2LHrPRR5kRSLbvdCKUMgub PoSYllSKOs3jb1QRZYOdeSvdk+Qeeh0XCE5K1RpoT8gs/ImtRGgdADWxhgRpzp8Cjzvg YkZfKeb9Y3JqQqIat6wE1HSGPIH3WjyEf27WEO7ml47yxWdqlJCvp4/+4nH1fik1KTp4 Rzae6bDj+SIUbJn3XMftrep42+3NBUbeszHGv7GeTDaXGz8mrLBt8qQcqklhh+WzAkV2 CbNugBaJfCEgSviG1ldjhsXpHmXKJKRr2B4YhHFC73oju2fDZ4/yzRJgbpmE+XSZR5FP pVuA== X-Gm-Message-State: AD7BkJLl+z8pLACpBLRX8kWtciSm8Dvh9Cp8E46BUlbrFmkkVqADNW6jXJPPRIAhkAtUdw== X-Received: by 10.140.236.68 with SMTP id h65mr19001326qhc.13.1458254357276; Thu, 17 Mar 2016 15:39:17 -0700 (PDT) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id 64sm4707099qhf.40.2016.03.17.15.39.16 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2016 15:39:16 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Sean Turner In-Reply-To: <9D74D454-3E42-4E7D-8EE1-B1075DB574F1@csperkins.org> Date: Thu, 17 Mar 2016 18:39:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <14F19EA3-DC9D-4404-99E8-AFAB9F358C97@sn3rd.com> References: <46276723-F9BF-4D5F-BDA3-76A00A8C27A1@sn3rd.com> <9D74D454-3E42-4E7D-8EE1-B1075DB574F1@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.3112) Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] time to revise rtp-usage X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 22:39:20 -0000 Colin, Thanks for this. I=E2=80=99ll circle the wagons with Cullen/Ted/Alissa = and we=E2=80=99ll get this re-done. spt > On Mar 17, 2016, at 11:35, Colin Perkins wrote: >=20 > I=E2=80=99ve just submitted an update to the rtp-usage draft. It makes = three changes: >=20 > - In Section 4.5, clarify that support for sending RTP and RTCP using = two separate transport layer flows is OPTIONAL.=20 >=20 > - Change RTP Packet Stream to RTP Stream throughout, to align = terminology with RFC 7656. >=20 > - Update references >=20 > There=E2=80=99s a diff from the previous version at = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-rtcweb-rtp-usage-25&url2=3D= draft-ietf-rtcweb-rtp-usage-26 >=20 > Colin >=20 >=20 >> On 26 Feb 2016, at 15:33, Sean Turner wrote: >>=20 >> All, >>=20 >> Now that draft-ietf-mmusic-mux-exclusive is in WGLC over in MMUSIC = [0][1], the chairs of this WG think it=E2=80=99s time to revise = draft-ietf-rtcweb-rtp-usage with the text the WG discussed on list, = which was discussed in this thread [2]. Once the rtp-usage authors have = submitted a new draft, we'll be reconfirming the consensus on = draft-ietf-rtcweb-rtp-usage, i.e., we need to yank it back from the RFC = editor, make these changes, and then go through the process of getting = it back in the RFC editor=E2=80=99s queue. >>=20 >> Cheers, >>=20 >> spt >>=20 >> [0] = https://mailarchive.ietf.org/arch/msg/mmusic/KxrTeCaOF_LTDeWJtLKSP06nH9U >> [1] And kudos to them for moving out so smartly. >> [2] = https://mailarchive.ietf.org/arch/msg/rtcweb/Yb3NpKuKSKIxRYYqPMNoNvyuIrc >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > --=20 > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 From nobody Thu Mar 17 19:53:15 2016 Return-Path: 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 C7A8712DAEB for ; Thu, 17 Mar 2016 19:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 d3kYrSgMSw2Z for ; Thu, 17 Mar 2016 19:53:11 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73D5112DAD1 for ; Thu, 17 Mar 2016 19:53:11 -0700 (PDT) Received: by mail-ig0-x22f.google.com with SMTP id av4so29511189igc.1 for ; Thu, 17 Mar 2016 19:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=q4OoeSM3boqJETjNqX5GVEdJixI89ImoD+E9z63zBiY=; b=CmMe9SLQm0zD/Thd1mw9fse3maM72OX5J85PpfgiUSdIa3Wqzi2PzvO5Yp2BvMTPLt shnelPtvNPyk2YOhNltoDRUEGLjIHDf4nmTrNgRYtRrOLBu0GjdPWYzbgkjUyZCI0HvD Fu9ChOj+wYToPB1qZqAuS6JB1WW1z8ml1+udFeJ6u2bdGY+VvsHRYr5Dp9xahiC+YWoV dUiBneG6WsZp3XWBNtLXqCiewIfLEsWQzsbZa85J7R8mMCu1QQ3PQ1k9kxzHLA3B7ptZ 1hn+5rmf4d6Uz7VTKWL7C84CyHQUV7rcibw4SXUKckEwxjSAljzm0HEEZcWukdD6K+QM ycEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=q4OoeSM3boqJETjNqX5GVEdJixI89ImoD+E9z63zBiY=; b=Evdva+hMQOnIKImTiQewYqjV6V1miY6YNKePJ8L0cOYwoFEkX3MsgkdRpQr7Up+pJV QRDFsKbLbTIhAYzZ7xqiFJWBbGjUD9GS9QY24mcZbFzdE3qLfQ6x7ghYRbemjKwoyNXF PfxhYvNcSV41RBZudx0MXXZrABUWBUS03hMG453xv6661JKkZas9PH6ffnnNiDmtTZOm qY5i6e+8ukfHKvrc71d0X78T34TgQ+lYs5HC/nChxFPsd9L6RhvenkuR/4c469mz/ec9 ToqUnYbIM5/YpufJtezVFFs/u+nWaTGJijpHQk4lwU4gObixi4N2aKVl5oSy763LcivG vMbg== X-Gm-Message-State: AD7BkJI/mnuyk5qzkC6lxB/n7RZFTGOL3Nrqh3SAxDlAtujUuDNAha/z/kxGGNQnqjhhHpHNNsK5rmqk2jveZw== MIME-Version: 1.0 X-Received: by 10.50.60.34 with SMTP id e2mr16100376igr.77.1458269590689; Thu, 17 Mar 2016 19:53:10 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Thu, 17 Mar 2016 19:53:10 -0700 (PDT) In-Reply-To: <6B474A50-6399-472F-BD7B-5286DCD209BA@cooperw.in> References: <6B474A50-6399-472F-BD7B-5286DCD209BA@cooperw.in> Date: Fri, 18 Mar 2016 13:53:10 +1100 Message-ID: From: Martin Thomson To: Alissa Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-alpn-02 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 02:53:14 -0000 Thanks for the review Alissa, I've put the changes up here: https://github.com/martinthomson/drafts/pull/= 30 I realize that you won't get a lot of time to look at this before I want to push -03, but I thought that I'd offer you the chance at least. On 6 March 2016 at 09:44, Alissa Cooper wrote: > =E2=80=9CConfidentiality protection=E2=80=9D is a fairly general term, bu= t it seems to be used throughout this document to mean something much more = specific, i.e., media that is confidential to two peers in a webrtc connect= ion. I think this needs to be clarified in the abstract and Sections 1, 2, = and 5 where the more specific meaning is intended. Otherwise this document = makes it sound as though data is being sent in the clear when it is not. E.= g., in Section 2 this text should be more specific to confidentiality vis a= vis the application: "However, data provided over data channels does not r= eceive confidentiality protection.=E2=80=9D Yes, the early sections only implicitly rely on the definition in Section 3, and that isn't particularly strong. I've given this a spin. > =3D Section 3 =3D > > "Any entity that forwards > content, or records content for later access by entities other than > the authenticated peer, SHOULD NOT offer or accept a session with the > "c-webrtc" identifier.=E2=80=9D > > Acknowledging the there are other recommendations in this draft that basi= cally up to the implementation to follow, why is this requirement a SHOULD = NOT rather than a MUST NOT? Made it a MUST. > Nits: > > =3D Section 1.1 =3D > > Since this document uses RFC 2119 keywords, why does it not include the s= tandard disclaimer recommended by RFC 2119? I think it=E2=80=99s fine to ad= d further words to indicate that the normative requirements are aimed at im= plementation behavior, but the standard text shouldn=E2=80=99t be omitted. OK, should that be the post-erratum boilerplate? > Also, I=E2=80=99m not sure what it means for the document to "fall back o= n shorthands for establishing interoperability requirements on implementati= ons.=E2=80=9D What is the alternative that it is falling back from? Actually saying what is meant using words. > =3D Section 6.3 =3D > > Is there a reason this reference is listed this way? Blame the tools, which are a mystery to me. I wanted to cite a specific section of the HTML5 spec, because finding a specific section in there is a nightmare. From nobody Fri Mar 18 13:32:24 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A44FD12D584; Fri, 18 Mar 2016 13:32:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160318203219.922.67120.idtracker@ietfa.amsl.com> Date: Fri, 18 Mar 2016 13:32:19 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-sdp-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 20:32:19 -0000 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 of the IETF. Title : SDP for the WebRTC Authors : Suhas Nandakumar Cullen Jennings Filename : draft-ietf-rtcweb-sdp-01.txt Pages : 107 Date : 2016-03-18 Abstract: The Web Real-Time Communication [WebRTC] working group is charged to provide protocol support for direct interactive rich communication using audio, video and data between two peers' web browsers. With in the WebRTC framework, Session Description protocol (SDP) [RFC4566] is used for negotiating session capabilities between the peers. Such a negotiation happens based on the SDP Offer/Answer exchange mechanism described in [RFC3264]. This document provides an informational reference in describing the role of SDP and the Offer/Answer exchange mechanism for the most common WebRTC use-cases. This SDP examples provided in this document is still a work in progress, but it aims to align closest to the evolving standards work. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-sdp-01 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/ From nobody Fri Mar 18 13:34:14 2016 Return-Path: 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 BE86812D653 for ; Fri, 18 Mar 2016 13:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 4Ob4Zvwb0PxN for ; Fri, 18 Mar 2016 13:34:10 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B5212D5CB for ; Fri, 18 Mar 2016 13:34:10 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id k1so156024926vkb.0 for ; Fri, 18 Mar 2016 13:34:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=CLXfa68cu7e1ZzvirWGPq6t9hJGrPZrYA3A04uN/lFM=; b=hjht51DymkcEBsJArgmE0PnREv+lzWnzo+A3ie9jbozo/rv9p9ZFJ+18lN+AFIKa7L bW9b0u9NiEyRsOmVsS1CRaDltO/8PKLVY8ml4c8VWGmbbgXXITwZWWkmfsWzb30u4ebf ImCOMe4WWTZahIREvoUAj8S5v9y/OaJwNz/Uacim79eZto6OiSrTmcjQCKkRr3V2Yest PNOmGjbZKCXEUB1NdgfjICNEFRT7YNTttLZaeZDe2lJ4zwzvuhhNSAk1SQcNa7ZvsZhc NL1uYclweyo6eUgbr7IfsIVg1QrGEVn/ncBA95F79p1UtLgwahLRosMf3SsDU0HTwC34 qhTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=CLXfa68cu7e1ZzvirWGPq6t9hJGrPZrYA3A04uN/lFM=; b=lHRiGkdfESQDG8XXRM+NElkipPbPvgIHY/CG4MaUWOJ4w2Gno0yRhOQ+olGlLKR5MT zJF8DFR9nqVz2+Fu1q3rokmtguudRVXtJxWxaHWIWwuIZqTz06iYBKlAkra1ykoeXER1 sJ6e9qOjjDfjr2YwP8SU0wke06MtjZ0B0IfxJNrK2BZMw3sYENjiqTkIFtO6fFr4CkVR WWyjPHy3/72yNiIiNI01bhBCFPu5IRodMbYGsYLbWiq6ujWYBWm1rm0aV0P8HaHPGw5V ONM+cwKfK253OetbjaIo5xOVFAH0Xzp+T2sQvpTuXbO3KemP/UFftZ85nNojgfdkKPLi VnZQ== X-Gm-Message-State: AD7BkJKbtb7WApFMNxh4LjdcgwGiVorl76xGaacJIdOgjGrVjVLH7Hwbzty0NjScP5ZiiI2wjsn7bK71gRNksQ== MIME-Version: 1.0 X-Received: by 10.31.50.65 with SMTP id y62mr19419817vky.11.1458333249714; Fri, 18 Mar 2016 13:34:09 -0700 (PDT) Received: by 10.176.66.199 with HTTP; Fri, 18 Mar 2016 13:34:09 -0700 (PDT) In-Reply-To: <20160318203219.922.67120.idtracker@ietfa.amsl.com> References: <20160318203219.922.67120.idtracker@ietfa.amsl.com> Date: Fri, 18 Mar 2016 13:34:09 -0700 Message-ID: From: Suhas Nandakumar To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a1143158a503edf052e58ab68 Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-sdp-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 20:34:12 -0000 --001a1143158a503edf052e58ab68 Content-Type: text/plain; charset=UTF-8 Hello All Version -01 updates the Multi-resolution examples to use new RID framework and the Simulcast-04 updates Thanks Suhas On Fri, Mar 18, 2016 at 1:32 PM, wrote: > > 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 > of the IETF. > > Title : SDP for the WebRTC > Authors : Suhas Nandakumar > Cullen Jennings > Filename : draft-ietf-rtcweb-sdp-01.txt > Pages : 107 > Date : 2016-03-18 > > Abstract: > The Web Real-Time Communication [WebRTC] working group is charged to > provide protocol support for direct interactive rich communication > using audio, video and data between two peers' web browsers. With in > the WebRTC framework, Session Description protocol (SDP) [RFC4566] is > used for negotiating session capabilities between the peers. Such a > negotiation happens based on the SDP Offer/Answer exchange mechanism > described in [RFC3264]. > > This document provides an informational reference in describing the > role of SDP and the Offer/Answer exchange mechanism for the most > common WebRTC use-cases. > > This SDP examples provided in this document is still a work in > progress, but it aims to align closest to the evolving standards > work. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-sdp/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-sdp-01 > > > 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/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a1143158a503edf052e58ab68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello All

=C2=A0 Version -01 updates th= e Multi-resolution examples to use new RID framework and the Simulcast-04 u= pdates

Thanks
Suhas

On Fri, Mar 18, 2016 at 1:32 PM, = <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Real-Time Communication in WEB-browsers of= the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= SDP for the WebRTC
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Suha= s Nandakumar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Cullen Jennings
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-sdp-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 107
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-03-18

Abstract:
=C2=A0 =C2=A0The Web Real-Time Communication [WebRTC] working group is char= ged to
=C2=A0 =C2=A0provide protocol support for direct interactive rich communica= tion
=C2=A0 =C2=A0using audio, video and data between two peers' web browser= s.=C2=A0 With in
=C2=A0 =C2=A0the WebRTC framework, Session Description protocol (SDP) [RFC4= 566] is
=C2=A0 =C2=A0used for negotiating session capabilities between the peers.= =C2=A0 Such a
=C2=A0 =C2=A0negotiation happens based on the SDP Offer/Answer exchange mec= hanism
=C2=A0 =C2=A0described in [RFC3264].

=C2=A0 =C2=A0This document provides an informational reference in describin= g the
=C2=A0 =C2=A0role of SDP and the Offer/Answer exchange mechanism for the mo= st
=C2=A0 =C2=A0common WebRTC use-cases.

=C2=A0 =C2=A0This SDP examples provided in this document is still a work in=
=C2=A0 =C2=A0progress, but it aims to align closest to the evolving standar= ds
=C2=A0 =C2=A0work.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-r= tcweb-sdp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-sd= p-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-rtcweb-sdp-01


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--001a1143158a503edf052e58ab68-- From nobody Sun Mar 20 12:25:22 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F26112D547; Sun, 20 Mar 2016 12:25:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160320192519.8965.29008.idtracker@ietfa.amsl.com> Date: Sun, 20 Mar 2016 12:25:19 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 19:25:19 -0000 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 of the IETF. Title : WebRTC Forward Error Correction Requirements Author : Justin Uberti Filename : draft-ietf-rtcweb-fec-03.txt Pages : 9 Date : 2016-03-20 Abstract: This document provides information and requirements for how Forward Error Correction (FEC) should be used by WebRTC applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-fec-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-03 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/ From nobody Sun Mar 20 12:34:54 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA6912D627; Sun, 20 Mar 2016 12:34:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160320193450.8970.69066.idtracker@ietfa.amsl.com> Date: Sun, 20 Mar 2016 12:34:50 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-00.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 19:34:50 -0000 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 of the IETF. Title : WebRTC IP Address Handling Recommendations Authors : Guo-wei Shieh Justin Uberti Filename : draft-ietf-rtcweb-ip-handling-00.txt Pages : 7 Date : 2016-03-20 Abstract: This document provides best practices for how IP addresses should be handled by WebRTC applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-00 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/ From nobody Sun Mar 20 15:31:17 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1636012D50C; Sun, 20 Mar 2016 15:31:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> Date: Sun, 20 Mar 2016 15:31:16 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 22:31:16 -0000 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 of the IETF. Title : WebRTC IP Address Handling Recommendations Authors : Justin Uberti Guo-wei Shieh Filename : draft-ietf-rtcweb-ip-handling-01.txt Pages : 8 Date : 2016-03-20 Abstract: This document provides best practices for how IP addresses should be handled by WebRTC applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-01 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/ From nobody Sun Mar 20 16:45:02 2016 Return-Path: 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 06A9B12D64B for ; Sun, 20 Mar 2016 16:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 BjFD2VuvUBgk for ; Sun, 20 Mar 2016 16:44:58 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98A8112D63A for ; Sun, 20 Mar 2016 16:44:58 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id p65so103056456wmp.0 for ; Sun, 20 Mar 2016 16:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=InlQk9/22oK0fR7U1/wIWAEfOUjoTovMFwAOQjmwxwU=; b=koBQ1WJNMqlDZodW2fx1dA7duVKxg9nFgiFdMermnqc9ACxKp+JJ2lBLzlWpET2lGT 8hi0MdP9XmxFXVChHszSPHA8j9zQ/Yf5eMaZpUthfW+a1Zb9CIldfc0X1ux4Qj6K8vYT m344BunJZL/hOp7eYfRr2aMoFDAMTsTXOHgjqOfh27ag3thvnBnwpeivJWekvM1Spvd7 EbkHIKcSOqoxGXmJ+VCQDLUHeNfxOPOJW1UqSt7EGMTEHQ7at8b+fXdeQ0mZSuSDYMbD 22PznK3te1Nj4mq+7tHwbsGddagTu6f70TxuQU6peHy2BDZ55XIW5vposmy9haaTsJvx Vbdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=InlQk9/22oK0fR7U1/wIWAEfOUjoTovMFwAOQjmwxwU=; b=DnY/jW6NbkLJsCuOUU/R5jrAXwlbqpAkcwcj71PpcAptChpdY4sSwcQA6IR4jJGDWh f0gdxH9hYm8fVUfFHte2A28vxUL/oMjC7wQhjV6HbkjTdV2cJlw5W+Fbg1txUzylyId4 ZEHq2Xhi+bA6akFICnFzreVodiFCPomDyOeYfBzegcaMzJHcCTxumnrmzOhOfE0cuSLK zqvzoHYOJwHePDfOc1rKB9nVCyCkF4remrxfY0qzQwA4UOPBWsYsgWggx4AE0yZYn9w6 M06g5Am1tA31gQrtjBJ0rEDOWUg/bMaduxMQ3LnISonRmMG/PMiL0HndFK4kkUURoEdK YVSg== X-Gm-Message-State: AD7BkJL7QIdka1v7mGUWsWj6+im1zUxoHZxwLtOgyYSTpoaDArliOCI4hbwqjNY14IKTcu9j4olECHPMPmfC/ROr X-Received: by 10.194.184.234 with SMTP id ex10mr25815856wjc.8.1458517497066; Sun, 20 Mar 2016 16:44:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.148.79 with HTTP; Sun, 20 Mar 2016 16:44:37 -0700 (PDT) In-Reply-To: <20160320192519.8965.29008.idtracker@ietfa.amsl.com> References: <20160320192519.8965.29008.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Sun, 20 Mar 2016 16:44:37 -0700 Message-ID: To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=047d7b86cc1e500943052e83917d Archived-At: Cc: "rtcweb@ietf.org" , i-d-announce@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 23:45:01 -0000 --047d7b86cc1e500943052e83917d Content-Type: text/plain; charset=UTF-8 This update incorporates changes suggested by Magnus in his review of the -02 document. On Sun, Mar 20, 2016 at 12:25 PM, wrote: > > 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 > of the IETF. > > Title : WebRTC Forward Error Correction Requirements > Author : Justin Uberti > Filename : draft-ietf-rtcweb-fec-03.txt > Pages : 9 > Date : 2016-03-20 > > Abstract: > This document provides information and requirements for how Forward > Error Correction (FEC) should be used by WebRTC applications. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-fec-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-03 > > > 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/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --047d7b86cc1e500943052e83917d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This update incorporates changes suggested by Magnus in hi= s review of the -02 document.

On Sun, Mar 20, 2016 at 12:25 PM, <= internet-draf= ts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Real-Time Communication in WEB-browsers of= the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= WebRTC Forward Error Correction Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Just= in Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-fec-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-03-20

Abstract:
=C2=A0 =C2=A0This document provides information and requirements for how Fo= rward
=C2=A0 =C2=A0Error Correction (FEC) should be used by WebRTC applications.<= br>

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-r= tcweb-fec/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-fe= c-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-rtcweb-fec-03


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--047d7b86cc1e500943052e83917d-- From nobody Sun Mar 20 16:46:33 2016 Return-Path: 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 7B81F12D58A for ; Sun, 20 Mar 2016 16:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 yjVL_KE8zRni for ; Sun, 20 Mar 2016 16:46:29 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5CE812D7DB for ; Sun, 20 Mar 2016 16:46:28 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id l68so90851412wml.0 for ; Sun, 20 Mar 2016 16:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gzeuyHJ0uszYVUyIKa6ff0xIeywhe1dYKia+1bZpJEE=; b=GqdehHgOuw2nQYZYE1bFGdIxh8SIWsWG1hqSxQajBXTUMvUtjgMsE/QOQe5o2THzVh PWexq9hjsXrfF6XPwIdMSuV4umrUuV3yMbVtEjQUHc8jgjJu7kPkEp1I5KJgGnMfzAi6 qKuf78gah7gneNJNRn4IOo8q6IIZTdLNwx+zdxZyc0ChrsfXqy6yfx/oT9p7+kxYLXPE njaJJD7UBOIfu3HL/cBHbOj2s5yHk7ytuudCJJSQO33tDFjaP4r6Xt7JJm8bP8GOO6Gt m2lmjLTuS1TBmfjTVK097iM4ZSPA5TwO6zu9aWYx1HpMOwPyr4oqIrI1gRPTg2QfvMa8 RUlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gzeuyHJ0uszYVUyIKa6ff0xIeywhe1dYKia+1bZpJEE=; b=iB0TmTpaNQTvB6u1zU1TIvJlUPAgbJw2KY3eKjsgs15EznTKcf1Ub+Azoi5aX4iP/A M7NByfUyN9KZ9Tkgl3iowJXFgcAKHBCqDEEW5D2lerK3+635iyLCm63LGkKb9gUq7z7C ROWNa++ZMK62MELHnZlLgPyZnaCqD7TAXStJrbrBJRDB+3DcfkJVOwiQZEw0BuDgAUM3 l4TkiloxTTUkKu5tDZ9Lni8etZcLRm+7zltuBz23ShJwu3I49F9FOwRxqoW9QKRAyEwK K16ZuX+2rAHeKAORlE0W8F6fWtT7654Oxu5faqhx5yCg42MP+G4nlRFLMLPcvwS5dw0p 2fIw== X-Gm-Message-State: AD7BkJLQO/MMsuzlwZaYBvlOGa/6dWHqgCoYvsL/xscuZozXkOFiLv4CzgsufYk/wz+biVCDfhhdtKDum868I1Mc X-Received: by 10.28.101.133 with SMTP id z127mr10981757wmb.84.1458517587249; Sun, 20 Mar 2016 16:46:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.148.79 with HTTP; Sun, 20 Mar 2016 16:46:07 -0700 (PDT) In-Reply-To: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Sun, 20 Mar 2016 16:46:07 -0700 Message-ID: To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=001a114b741eb0125e052e839605 Archived-At: Cc: "rtcweb@ietf.org" , i-d-announce@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 23:46:32 -0000 --001a114b741eb0125e052e839605 Content-Type: text/plain; charset=UTF-8 This update incorporates changes suggested by Adam in his review of the -00 document, mainly around clarifying how the combined permission for cam/mic and IPs should be discussed, and also how the force proxy mode should work. On Sun, Mar 20, 2016 at 3:31 PM, wrote: > > 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 > of the IETF. > > Title : WebRTC IP Address Handling Recommendations > Authors : Justin Uberti > Guo-wei Shieh > Filename : draft-ietf-rtcweb-ip-handling-01.txt > Pages : 8 > Date : 2016-03-20 > > Abstract: > This document provides best practices for how IP addresses should be > handled by WebRTC applications. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-01 > > > 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/ > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a114b741eb0125e052e839605 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This update incorporates changes suggested by Adam in his = review of the -00 document, mainly around clarifying how the combined permi= ssion for cam/mic and IPs should be discussed, and also how the force proxy= mode should work.

On Sun, Mar 20, 2016 at 3:31 PM, <internet-drafts@ietf.org<= /a>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Real-Time Communication in WEB-browsers of= the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= WebRTC IP Address Handling Recommendations
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Just= in Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Guo-wei Shieh
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-ip-handling-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-03-20

Abstract:
=C2=A0 =C2=A0This document provides best practices for how IP addresses sho= uld be
=C2=A0 =C2=A0handled by WebRTC applications.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draf= t-ietf-rtcweb-ip-handling/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-r= tcweb-ip-handling-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url= 2=3Ddraft-ietf-rtcweb-ip-handling-01


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--001a114b741eb0125e052e839605-- From nobody Sun Mar 20 16:48:36 2016 Return-Path: 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 80E7C12D58E for ; Sun, 20 Mar 2016 16:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 yeNNjpm2U0K4 for ; Sun, 20 Mar 2016 16:48:33 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6117C12D614 for ; Sun, 20 Mar 2016 16:48:33 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id l68so103063381wml.1 for ; Sun, 20 Mar 2016 16:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=prydBGv7MKGGvyyPrmbqLE7QX3m47ZNPYgRZyfozOnw=; b=ocYQTKm8qp0BAafCJB3ywqotDXNVQS5HPSBxe7zkxZWzD6OGfruBZghttlTwk2s9Df upClqy3qPJKUO0tNaBuqwc+GCF34504YBm/n4K+vhfzA2B7gOsuotDhKJiz2htgVP8p8 I5fJr+cb8n8ko/zrnjnvuq5N1Byp0u1RCNE2pm84mwptIcek1Osbg93ldfbKvgiMarqM 91WlG2NpICbxkpEvkNtFe0EBJDhaosyvkJNRyy2Jj9DD4tnqjrbclNoPQFAq6TiObqZb PLzzzjVK/SGczgXyMu7RcqCc82IYFnFcgtYRiNm3LtlOMf2ZE2RB9zWYH/rJQldakiSa ybiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=prydBGv7MKGGvyyPrmbqLE7QX3m47ZNPYgRZyfozOnw=; b=WdEPz5Zhnkk0KyPBdyz7dBHzjc8TeOJjrOpAKLuwlvyfVMqagiY1AYEUHW5qtOyl/v U22vuXFJg3Z8FpoidRyzcQP52okxJcaDcdfXyuyjUX1wGIDrLMdocDyKLKZJdCBJj0Eu 1TSQ/Xruj+Uf1uMG4xFCyntMAWrVI6HBPdyPsZVp8+82fYxO4Eu5Totrn1XCVLHnYHMR xJZcvYZ5sUYTJS3b4HD+wLLkKuGZ1fol97sjq88cFCzKmhFlbXwUwejnqXeK4Yv6kKGe y8JKnc9Rqn+WwBnARmAarYvWoIyaoNVHk7DJoHtakNTa6l5gZqexliQjwfiEUhspQrCc aRvw== X-Gm-Message-State: AD7BkJKFl6pN5iP/Y8EWIcIaZvOR57Zmj2q16tCT7QBMIM4vhwauZs6YM5+X1zjpK/MapKs6zTgGrNyQJpIGRyQY X-Received: by 10.194.6.36 with SMTP id x4mr27261534wjx.122.1458517711899; Sun, 20 Mar 2016 16:48:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.148.79 with HTTP; Sun, 20 Mar 2016 16:48:12 -0700 (PDT) In-Reply-To: References: <20160320192519.8965.29008.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Sun, 20 Mar 2016 16:48:12 -0700 Message-ID: Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=047d7b5d295c1e1f83052e839eca Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-03.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 23:48:34 -0000 --047d7b5d295c1e1f83052e839eca Content-Type: text/plain; charset=UTF-8 [fixing to: line] On Sun, Mar 20, 2016 at 4:44 PM, Justin Uberti wrote: > This update incorporates changes suggested by Magnus in his review of the > -02 document. > > On Sun, Mar 20, 2016 at 12:25 PM, wrote: > >> >> 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 >> of the IETF. >> >> Title : WebRTC Forward Error Correction Requirements >> Author : Justin Uberti >> Filename : draft-ietf-rtcweb-fec-03.txt >> Pages : 9 >> Date : 2016-03-20 >> >> Abstract: >> This document provides information and requirements for how Forward >> Error Correction (FEC) should be used by WebRTC applications. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-rtcweb-fec-03 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-fec-03 >> >> >> 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/ >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > --047d7b5d295c1e1f83052e839eca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[fixing to: line]

On Sun, Mar 20, 2016 at 4:44 PM, Justin Uberti <ju= berti@google.com> wrote:
This update incorporates changes suggested by Magnus in his = review of the -02 document.

On Sun, Mar 20, 201= 6 at 12:25 PM, <internet-drafts@ietf.org> wrote:
=

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Real-Time Communication in WEB-browsers of= the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= WebRTC Forward Error Correction Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Just= in Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-fec-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 9
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-03-20

Abstract:
=C2=A0 =C2=A0This document provides information and requirements for how Fo= rward
=C2=A0 =C2=A0Error Correction (FEC) should be used by WebRTC applications.<= br>

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-r= tcweb-fec/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-rtcweb-fe= c-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-rtcweb-fec-03


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb


--047d7b5d295c1e1f83052e839eca-- From nobody Sun Mar 20 16:49:01 2016 Return-Path: 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 ED1A612D58E for ; Sun, 20 Mar 2016 16:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 H_YxZuL8_Foa for ; Sun, 20 Mar 2016 16:48:56 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5522B12D7AF for ; Sun, 20 Mar 2016 16:48:54 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id p65so133109890wmp.1 for ; Sun, 20 Mar 2016 16:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=gP5Dg7FCXTcfR5HcbFtxDIS1cuzP5wVZV7TUORYvMPE=; b=ER2Zw0AyhJxRTiJHmrKPO9haasXmes3jlIBO10ZLbCZilu0p/prXqcROU4YwpdTwxE Uhpp5nLO5tgW4CWs5xVjHUvpWOwJJEjR8PBQ8fzldqQsfgj8QGYcgQDbBkORG2EafMrX yV9VqKlkbRP3eB13ReTk65ezVvlhuaDiFdKjCuM9fQVeK9yP0KCb9kKY1CCHwQAblDw0 /zVcypS4HS4x6PVtmT6JIrDxcYOCS9JAWrM7NzRwgpas7FMQpvz3rOvOCXzf8l/BJiqN Uzx/O2cHYnkGno8CgnkrWRf4IyBks/cYUe9Q/uIh4QTdg9ANDNX9xbmqq4qvCF/xb/md ETfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=gP5Dg7FCXTcfR5HcbFtxDIS1cuzP5wVZV7TUORYvMPE=; b=e0CbIABhNeOWNlBJdcV1SE4JkkiLHmtYS/LuB5VXpEQPMGnbapBFX48G41RjI3Ze6p gBV1lMl79i8XdlUq2XnuJ32EnmwUPxYfxT8r3WERFY2z+OiN+PBjAOw4fKr7YwgchzuL U2+hIA8cANr76Fc46lLiJDKCnkwihv7zrbRT+wzj4mqAjWLQHrMPJaJFy9CxuQWudpQO yFgE7Bvtti+zZAD/L/DjIyeZpF0rH2JjgE868HhKvEofjKSh2bcENbSyraTNQaBfHN2s ItGS6tP4+V4s7Rs0LmcWc+tTmxi8knsIxdSbq318iQVJHWMHqF4a34pCQ3auznFY6xfk 0g3Q== X-Gm-Message-State: AD7BkJLWHJ4gkACcnxDKmas6aCW52A7+aJ16hV3L9lHOCb4F617JCE8d2Du/2VfB9hyQB/2K+i9ydc3pwfTuSaMT X-Received: by 10.28.4.147 with SMTP id 141mr10246156wme.44.1458517732758; Sun, 20 Mar 2016 16:48:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.148.79 with HTTP; Sun, 20 Mar 2016 16:48:32 -0700 (PDT) In-Reply-To: References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> From: Justin Uberti Date: Sun, 20 Mar 2016 16:48:32 -0700 Message-ID: Cc: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary=001a1141e7565c6fed052e839fbd Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 23:48:58 -0000 --001a1141e7565c6fed052e839fbd Content-Type: text/plain; charset=UTF-8 [fixing to: line] On Sun, Mar 20, 2016 at 4:46 PM, Justin Uberti wrote: > This update incorporates changes suggested by Adam in his review of the > -00 document, mainly around clarifying how the combined permission for > cam/mic and IPs should be discussed, and also how the force proxy mode > should work. > > On Sun, Mar 20, 2016 at 3:31 PM, wrote: > >> >> 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 >> of the IETF. >> >> Title : WebRTC IP Address Handling Recommendations >> Authors : Justin Uberti >> Guo-wei Shieh >> Filename : draft-ietf-rtcweb-ip-handling-01.txt >> Pages : 8 >> Date : 2016-03-20 >> >> Abstract: >> This document provides best practices for how IP addresses should be >> handled by WebRTC applications. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-01 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-ip-handling-01 >> >> >> 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/ >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > > --001a1141e7565c6fed052e839fbd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
[fixing to: line]

On Sun, Mar 20, 2016 at 4:46 PM, Justin Uberti <jube= rti@google.com> wrote:
This update incorporates changes suggested by Adam in his revi= ew of the -00 document, mainly around clarifying how the combined permissio= n for cam/mic and IPs should be discussed, and also how the force proxy mod= e should work.

On Sun, Mar 20, 2016 at 3:31 PM, <internet-drafts@iet= f.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Real-Time Communication in WEB-browsers of= the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= WebRTC IP Address Handling Recommendations
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Just= in Uberti
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Guo-wei Shieh
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-rtcweb-ip-handling-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-03-20

Abstract:
=C2=A0 =C2=A0This document provides best practices for how IP addresses sho= uld be
=C2=A0 =C2=A0handled by WebRTC applications.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draf= t-ietf-rtcweb-ip-handling/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-r= tcweb-ip-handling-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url= 2=3Ddraft-ietf-rtcweb-ip-handling-01


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb


--001a1141e7565c6fed052e839fbd-- From nobody Mon Mar 21 08:49:39 2016 Return-Path: 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 5842812D8D7 for ; Mon, 21 Mar 2016 08:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 OA26uanVicuV for ; Mon, 21 Mar 2016 08:49:32 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1EE012D8D4 for ; Mon, 21 Mar 2016 08:49:31 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id s5so80746608qkd.0 for ; Mon, 21 Mar 2016 08:49:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=IbW49CxkudhX6uhRlWLymQLb8TMt7jAiWRhQ84T8XbU=; b=XqaYNvk28YqYrhuqCDYwkHlODjqC5cA4G222vnylTXsXnEgA9DNl1RyvmxBfOOHOh8 4Qz/VuQ6kuagziUy4ekbCKo9DC+x4oU5C9VIWRUrO7lCNm6xJ70P1LEDYu+oezdDBISr h1qXts6XOLh+gLNMGyRNe46LwDbqOTG2mLAGk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=IbW49CxkudhX6uhRlWLymQLb8TMt7jAiWRhQ84T8XbU=; b=JNCXUixRKZsrlucsmDdTMLk5LzNalToewre4TWSwMSZfZEi8oV1CjIDhDFRCfVmk4o cLJt/W0/5yAW+7w3dpFh4u3L1uKBDE/LCAf7VfQkXsvxlZ9sBunGgkjweAl9JqTCzSEY XMxWicgPr52vxV7zPuB/Ee0AM8negJW4Yj9V1VzvfAI8WYxpe1Zv65L9MtdvdrWfMvx1 KrLurDNtF1k38RA3rlAUcPnd26cFwcf887hocA6kJWGQES6CgzogvLg0y8V6ifluUzU+ 3Emyvdps9sHB1bG72v2DmwTkzvj7bzjjhhZuLTaLzt8+FE7tC3iN2ay0GFGFFcfwmcoL fQjA== X-Gm-Message-State: AD7BkJJC5LhFRORusd+L1ZdqmWtXjSDAlS7GIzNhC9qvW/m5A5mvx5khngLps8ASQlO6tQ== X-Received: by 10.55.71.76 with SMTP id u73mr41942800qka.6.1458575370986; Mon, 21 Mar 2016 08:49:30 -0700 (PDT) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id 94sm12474233qgj.10.2016.03.21.08.49.29 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2016 08:49:29 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Sean Turner In-Reply-To: Date: Mon, 21 Mar 2016 11:49:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> To: "rtcweb@ietf.org" X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 15:49:37 -0000 I updated the =E2=80=9CReplaces=E2=80=9D info so everybody can easily = see the history of changes from the original individual draft. spt > On Mar 20, 2016, at 19:48, Justin Uberti wrote: >=20 > [fixing to: line] >=20 > On Sun, Mar 20, 2016 at 4:46 PM, Justin Uberti = wrote: > This update incorporates changes suggested by Adam in his review of = the -00 document, mainly around clarifying how the combined permission = for cam/mic and IPs should be discussed, and also how the force proxy = mode should work. >=20 > On Sun, Mar 20, 2016 at 3:31 PM, wrote: >=20 > 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 of the IETF. >=20 > Title : WebRTC IP Address Handling Recommendations > Authors : Justin Uberti > Guo-wei Shieh > Filename : draft-ietf-rtcweb-ip-handling-01.txt > Pages : 8 > Date : 2016-03-20 >=20 > Abstract: > This document provides best practices for how IP addresses should = be > handled by WebRTC applications. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-ip-handling-01 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Mar 21 09:03:19 2016 Return-Path: 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 E206712D8B4 for ; Mon, 21 Mar 2016 09:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 bOuFBMdqcHdn for ; Mon, 21 Mar 2016 09:03:11 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE02E12D8F7 for ; Mon, 21 Mar 2016 09:03:08 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id w20so88792544oia.2 for ; Mon, 21 Mar 2016 09:03:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8uP9HbqgjdIcNuz8GmVIrpH1NlhfsLxydZ2QeeQc23c=; b=K0/Qmyj3Op0sapdLKIMlixEPzGVJyNAMMChswMcgKzVUwFXPrE1oerwcQo1aqkDJKZ 7SLsFvHQKi6Ex9xCrQMaRV1FGU/Lh+nKKmlIpshx9cEbanVp63UpOG/QL1+al5Q/tC0R VEA+bc33Gw3bZiObpaRGgIxq5Zb6gJ5i2LDB002qqXgDIR0XAVTqiT3PYuU7mSkGnOGF zinYVIpLjIPpCdQFLXwH2O2sZD12I5Mg0dpz9u4mlFVhIHVULa3rcC94uh912FKXRVwC bD+YC+8jFg/vNPqYqiQUCN4Z/NuE8lN66LhRR1air8wtCFjlfaHafpF+zLsIXeAJ4DJm Z5Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8uP9HbqgjdIcNuz8GmVIrpH1NlhfsLxydZ2QeeQc23c=; b=LaHfFePHHygzj3tf+vNiDHdwXC6Kmcw+a9eLifAM8jGHiwF/0PUVEpXEbaX5B4QcnL MgleDB6voU9mS8lKq9hnMM4EZ1XtKoqfpLro8e7nx1zkgF0Y1/WJ51s+6IO4uzD5ZmzJ Cln+UMgVYVQGGrwWUifgCyaBmRTF2kxiLEs2LbDkOPvT5gwWQvRsCOtOIdW6OjlQoxk4 FBxvlZahiwB8ubtJiybT9UqSlKaIGXbVNEyWHP29YH7RbOCUAzF+jB0CRZrOdalx1wgY jyXlW6yNqJCOmolZZTv+N/DMZDaIh1tVI7Yb835rtilDbjPBWtvNOkKJTPXCJfDBD6Os cFCA== X-Gm-Message-State: AD7BkJI5ukH4OUnLut4B8ZSKXoNq8HLG6jkglUsFk7SmC8eKDcOKYu2mXHob2srqeKFu2r/Czquj/h0Flo4vDA== X-Received: by 10.157.15.132 with SMTP id d4mr1352157otd.79.1458576188120; Mon, 21 Mar 2016 09:03:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.51.6 with HTTP; Mon, 21 Mar 2016 09:02:48 -0700 (PDT) In-Reply-To: <56EAEE85.5030701@alvestrand.no> References: <56E856BB.4080502@alvestrand.no> <56E91015.7040509@alvestrand.no> <56E9B86C.8060806@alum.mit.edu> <56EAEE85.5030701@alvestrand.no> From: Ted Hardie Date: Mon, 21 Mar 2016 09:02:48 -0700 Message-ID: To: Harald Alvestrand Content-Type: multipart/alternative; boundary=001a113edca892284a052e913b39 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Sub-protocol registry update X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 16:03:18 -0000 --001a113edca892284a052e913b39 Content-Type: text/plain; charset=UTF-8 Just FYI, I did post a short draft to update the registry, which will need to get a little discussion on the hybi list before going forward: https://datatracker.ietf.org/doc/draft-hardie-rfc6455-iana-clarification/ (Likely not really for BCP, by the way, just not sure if I can get away with informational). Ted --001a113edca892284a052e913b39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just FYI, I did post a short draft to update the= registry, which will need to get a little discussion on the hybi list befo= re going forward:

https://datatracker.ietf.org/doc/draft-= hardie-rfc6455-iana-clarification/

(Likely not really for = BCP, by the way, just not sure if I can get away with informational).
Ted
--001a113edca892284a052e913b39-- From nobody Mon Mar 21 14:16:24 2016 Return-Path: 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 3DC4012DB40 for ; Mon, 21 Mar 2016 14:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 H884FmzYRV3c for ; Mon, 21 Mar 2016 14:16:22 -0700 (PDT) Received: from smtp97.ord1c.emailsrvr.com (smtp97.ord1c.emailsrvr.com [108.166.43.97]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EFF112D86D for ; Mon, 21 Mar 2016 14:16:21 -0700 (PDT) Received: from smtp13.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp13.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 989C838037B for ; Mon, 21 Mar 2016 17:16:20 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp13.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 6582638031A for ; Mon, 21 Mar 2016 17:16:20 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.26.15] ([UNAVAILABLE]. [128.107.241.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.5.4); Mon, 21 Mar 2016 17:16:20 -0400 From: Cullen Jennings Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <5DCD43C8-0EF5-485A-B0B0-69BDC685BB24@iii.ca> Date: Mon, 21 Mar 2016 14:16:20 -0700 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [rtcweb] Draft Agenda for RTCWEB at IETF95 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 21:16:23 -0000 * Day 1: * 5 min - Welcome/Note Well/ (insert pretty pic of BA) + Thank you = to Barry * 10 min - WG drafts=E2=80=99 status (Chairs) * 10 min - DTMF issue (Mo?) * 5 min - FEC (Justin) * 20 min - IP-address handling (Justin?) * Day 2: * 120 min - JSEP (Eric Rescorla) From nobody Mon Mar 21 15:37:39 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A0412D133; Mon, 21 Mar 2016 15:37:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321223732.12239.92688.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 15:37:32 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-12.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 22:37:32 -0000 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 of the IETF. Title : Transports for WebRTC Author : Harald Alvestrand Filename : draft-ietf-rtcweb-transports-12.txt Pages : 17 Date : 2016-03-21 Abstract: This document describes the data transport protocols used by WebRTC, including the protocols used for interaction with intermediate boxes such as firewalls, relays and NAT boxes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-transports/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-transports-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-transports-12 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/ From nobody Mon Mar 21 16:38:31 2016 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6B112D181; Mon, 21 Mar 2016 16:38:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321233828.10905.57296.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 16:38:28 -0700 Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-14.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 23:38:28 -0000 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 of the IETF. Title : Javascript Session Establishment Protocol Authors : Justin Uberti Cullen Jennings Eric Rescorla Filename : draft-ietf-rtcweb-jsep-14.txt Pages : 85 Date : 2016-03-21 Abstract: This document describes the mechanisms for allowing a Javascript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API, and discusses how this relates to existing signaling protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-jsep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-jsep-14 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/ From nobody Tue Mar 22 03:32:01 2016 Return-Path: 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 CF58712D673 for ; Tue, 22 Mar 2016 03:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 V2uhL-H_rwjC for ; Tue, 22 Mar 2016 03:31:57 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E892812D728 for ; Tue, 22 Mar 2016 03:31:54 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id BDD55C7FF7FE6 for ; Tue, 22 Mar 2016 10:31:50 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2MAVqhc029370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 22 Mar 2016 10:31:52 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u2MAVVNL012849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 22 Mar 2016 11:31:52 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.185]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Tue, 22 Mar 2016 11:31:47 +0100 From: "Drage, Keith (Nokia - GB)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt Thread-Index: AQHRgvg79H6EjfH6EUm6FTBySzZ8HZ9kqXjQ Date: Tue, 22 Mar 2016 10:31:46 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> In-Reply-To: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 10:32:01 -0000 The header of this document says "standards track". The title of the document says "recommendations" which would equate to a no= rmative document of SHOULD strength The abstract says "best practices" Throughout the document I detected lots of lower case usage of RFC 2119 ter= ms but did not see any upper case usage (but may have missed it). All of which leaves me confused. Would the chairs like to clarify the intent of this document in terms of do= cument type? Regards Keith Drage -----Original Message----- From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of EXT internet-dra= fts@ietf.org Sent: 20 March 2016 22:31 To: i-d-announce@ietf.org Cc: rtcweb@ietf.org Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Real-Time Communication in WEB-browsers of= the IETF. Title : WebRTC IP Address Handling Recommendations Authors : Justin Uberti Guo-wei Shieh Filename : draft-ietf-rtcweb-ip-handling-01.txt Pages : 8 Date : 2016-03-20 Abstract: This document provides best practices for how IP addresses should be handled by WebRTC applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-ip-handling/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-ip-handling-01 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Mar 22 07:45:40 2016 Return-Path: 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 5789F12D98C for ; Tue, 22 Mar 2016 07:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 hbN5eIZUnnft for ; Tue, 22 Mar 2016 07:45:35 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A82212D9A5 for ; Tue, 22 Mar 2016 07:45:29 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1aiNYk-0002ZR-D8; Tue, 22 Mar 2016 15:45:26 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1aiNYj-00005b-UH; Tue, 22 Mar 2016 15:45:26 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <20160321223732.12239.92688.idtracker@ietfa.amsl.com> Date: Tue, 22 Mar 2016 15:45:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <84BAECBC-E849-424B-9EA1-6B80BA925F5F@ifi.uio.no> References: <20160321223732.12239.92688.idtracker@ietfa.amsl.com> To: rtcweb@ietf.org, harald@alvestrand.no X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 4 sum msgs/h 3 total rcpts 39554 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 30D188E5457DD79E2D96FD369248E97FF205050C X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 9490 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-12.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 14:45:38 -0000 Hi, On 26 February, I sent an email to rtcweb in which I made some = suggestions to this document. I see that these have not been = incorporated, and my email has also never been answered (except that = I-D.ietf-dart-dscp-rtp was replaced by RFC 7657, but that may not have = been due to my email). I can understand that: probably my prior email = just drowned in the WebRTC Audio Codec related thread. However I do = think that these comments would be good to address, so I'm copying in = the email again below. Cheers, Michael ---- Hi, Overall, I like this document a lot - it makes for a very good read! - but I think it would make sense for section 4.1 to explicitly point to = draft-ietf-rmcat-coupled-cc (the next version of which is going to = explain how weights much be set to adhere to the priority levels that = are described in this section; it's easy, we just didn't have this text = in there yet). To be concrete, I suggest the following two changes: *** When an WebRTC implementation has packets to send on multiple streams that are congestion-controlled under the same congestion controller, the WebRTC implementation SHOULD cause data to be emitted in such a way that each stream at each level of priority is being given approximately twice the transmission capacity (measured in payload bytes) of the level below. *** should be: *** When a WebRTC implementation has packets to send on multiple streams that are congestion-controlled under the same congestion controller or multiple coupled congestion controllers (e.g. using the mechanism = in [draft-ietf-rmcat-coupled-cc]), the WebRTC implementation SHOULD cause data to be emitted in such a way that each stream at each level of priority is being given approximately twice the transmission capacity (measured in payload bytes) of the level below. *** (note a fixed nit in there: the second word is "a" instead of "an") and, perhaps even more importantly, a small change in section 4.2: *** More advice on the use of DSCP code points with RTP is given in [I-D.ietf-dart-dscp-rtp]. *** should be: *** More advice on the use of DSCP code points with RTP as well as coupled congestion control is given in [I-D.ietf-dart-dscp-rtp]. *** and in fact I-D.ietf-dart-dscp-rtp should now be RFC 7657. Cheers, Michael= From nobody Tue Mar 22 08:14:09 2016 Return-Path: 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 1D7AE12DA1C for ; Tue, 22 Mar 2016 08:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 DwNICib1v15n for ; Tue, 22 Mar 2016 08:14:05 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9B112D882 for ; Tue, 22 Mar 2016 08:14:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E8D097C7777; Tue, 22 Mar 2016 16:14:02 +0100 (CET) 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 9MIRq4N-92vy; Tue, 22 Mar 2016 16:14:01 +0100 (CET) Received: from [IPv6:2001:470:de0a:1:35d8:7af6:5c73:857b] (unknown [IPv6:2001:470:de0a:1:35d8:7af6:5c73:857b]) by mork.alvestrand.no (Postfix) with ESMTPSA id C31D67C7776; Tue, 22 Mar 2016 16:14:01 +0100 (CET) To: Michael Welzl , rtcweb@ietf.org References: <20160321223732.12239.92688.idtracker@ietfa.amsl.com> <84BAECBC-E849-424B-9EA1-6B80BA925F5F@ifi.uio.no> From: Harald Alvestrand Message-ID: <56F16139.8010804@alvestrand.no> Date: Tue, 22 Mar 2016 16:14:01 +0100 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: <84BAECBC-E849-424B-9EA1-6B80BA925F5F@ifi.uio.no> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-12.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 15:14:08 -0000 Thank you - yes, it was lost. I've filed this suggestion as https://github.com/rtcweb-wg/rtcweb-transport/issues/16 My queries are of course: - Is the reference to [coupled] normative or informative? - What is the expected timeline for emission of [coupled]? I see that RFC 7657 got published with [coupled] as an informative reference. The "e.g." in your first suggestion might be loose enough to warrant an informative reference. Den 22. mars 2016 15:45, skrev Michael Welzl: > Hi, > > On 26 February, I sent an email to rtcweb in which I made some suggestions to this document. I see that these have not been incorporated, and my email has also never been answered (except that I-D.ietf-dart-dscp-rtp was replaced by RFC 7657, but that may not have been due to my email). I can understand that: probably my prior email just drowned in the WebRTC Audio Codec related thread. However I do think that these comments would be good to address, so I'm copying in the email again below. > > Cheers, > Michael > > ---- > > Hi, > > Overall, I like this document a lot - it makes for a very good read! > > - but I think it would make sense for section 4.1 to explicitly point to draft-ietf-rmcat-coupled-cc (the next version of which is going to explain how weights much be set to adhere to the priority levels that are described in this section; it's easy, we just didn't have this text in there yet). > > > To be concrete, I suggest the following two changes: > > *** > When an WebRTC implementation has packets to send on multiple streams > that are congestion-controlled under the same congestion controller, > the WebRTC implementation SHOULD cause data to be emitted in such a > way that each stream at each level of priority is being given > approximately twice the transmission capacity (measured in payload > bytes) of the level below. > *** > > should be: > > *** > When a WebRTC implementation has packets to send on multiple streams > that are congestion-controlled under the same congestion controller > or multiple coupled congestion controllers (e.g. using the mechanism in > [draft-ietf-rmcat-coupled-cc]), > the WebRTC implementation SHOULD cause data to be emitted in such a > way that each stream at each level of priority is being given > approximately twice the transmission capacity (measured in payload > bytes) of the level below. > *** > > (note a fixed nit in there: the second word is "a" instead of "an") > > > and, perhaps even more importantly, a small change in section 4.2: > > *** > More advice on the use of DSCP code points with RTP is given in > [I-D.ietf-dart-dscp-rtp]. > *** > > should be: > > *** > More advice on the use of DSCP code points with RTP as well as coupled > congestion control is given in [I-D.ietf-dart-dscp-rtp]. > *** > > and in fact I-D.ietf-dart-dscp-rtp should now be RFC 7657. > > > Cheers, > Michael > From nobody Tue Mar 22 16:10:33 2016 Return-Path: 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 AF67912D1A1 for ; Tue, 22 Mar 2016 16:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 TGMus5dqI0vM for ; Tue, 22 Mar 2016 16:10:31 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E552312D09B for ; Tue, 22 Mar 2016 16:10:30 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id d205so194508305oia.0 for ; Tue, 22 Mar 2016 16:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NrV1ooD9GfI87597kpC/Dwv5iY0nzWmhEJKn+1sVytA=; b=F8uEkjRmUbAnyfnP3wMGRHK96PBuZvZXIEUjcTIhYfizGw5U4x7/n/UX6iIbCosx6J GA8XnIkI8J3EivgQgliFGI10Dal4xvlZNNabi+JoFo7tbDK6lHpuAdN4KrBGUrntWVl7 9VSCi0gL10pPELg7Km6taL4/luESQqKzmpEcF/SKJcmpJFHr4pWXgQOCtfC29yOKB5Rn XKQuzBVDTsloWKJa9SPG9yrkS5wRRLSDnZmDJfR7LRE//2mb0CQXI16A/2sAmjlnx+qC CA5LqEn1OYm386pdN07kwRj5QGQy9Fv4u0vfXoH4oZ3bHDYRalTnf1cCkZXEEDb5nVJE BAEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NrV1ooD9GfI87597kpC/Dwv5iY0nzWmhEJKn+1sVytA=; b=nH4muU7irDPHHnJI5LyM+hTLEQGatEhPo0DJfaZX6B4MwjVadj5lnD6i3n2y+W6FFp UCjR41rH9LWwKfOZzEIyKS19OyNu+9+S5Q+aWJURZEBC+Qg7IJYHJa6g/9DhAaaAh5+Q Sls/lYQgp9baxKVBYshZUFCX959WFyQz+MG27iNXdv2cEDowsTjzFAvcCWE/OAPDEvLV +a0Xql6UbK4vjJboX3r7RxOElAyLzU/hwtzD+9MT/BFVRNdKqM5oOk/KDUwMLu+3CaSH IXZgeU0W1DyFXutXBVxCGLkRI7EFYlceMyUz6e4cMRnY00K6c58baWeF0J8F/jLNQabb kRQA== X-Gm-Message-State: AD7BkJLvPzhRto/G2l7Gx8rCoNNeSaFb5uCdeNZumwfYTvPmxbtN22MrNcp6iCsP9B13aSrajquVrrJFaJW8oA== X-Received: by 10.157.15.132 with SMTP id d4mr4746417otd.79.1458688230302; Tue, 22 Mar 2016 16:10:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.51.6 with HTTP; Tue, 22 Mar 2016 16:10:10 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Ted Hardie Date: Tue, 22 Mar 2016 16:10:10 -0700 Message-ID: To: "Drage, Keith (Nokia - GB)" Content-Type: multipart/alternative; boundary=001a113edca8ce28c7052eab5157 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 23:10:32 -0000 --001a113edca8ce28c7052eab5157 Content-Type: text/plain; charset=UTF-8 Speaking as an individual, rather than chair: On Tue, Mar 22, 2016 at 3:31 AM, Drage, Keith (Nokia - GB) < keith.drage@nokia.com> wrote: > The header of this document says "standards track". > > The title of the document says "recommendations" which would equate to a > normative document of SHOULD strength > > The abstract says "best practices" > > Throughout the document I detected lots of lower case usage of RFC 2119 > terms but did not see any upper case usage (but may have missed it). > > All of which leaves me confused. > > Would the chairs like to clarify the intent of this document in terms of > document type? > > Regards > > Keith Drage > > I don't think this document describes any new protocol mechanisms, so the lack of upper case RFC 2119 terms seems to me personally fairly natural. What it does instead is lay out the results of doing IP address handling in specific modes, along with a recommendation on which would make a reasonable default. Clearly it could have been part of JSEP, which would have made it part of a standards track doc. The value to me of it being separate is that the advice can be revised independently of the core protocol specification. To that extent, it is somewhere between "Applicability statement" and "BCP" in our formal terminology, with a thumb very slightly on the scale toward BCP. Ultimately, though, I am willing to be guided by our ADs or the community about the exact status. The high order bits are the advice and its decomposability. regards, Ted --001a113edca8ce28c7052eab5157 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Speaking as an individual, rather than chair:

On Tue, Mar 22, 2016 at 3:= 31 AM, Drage, Keith (Nokia - GB) <keith.drage@nokia.com>= wrote:
The header of = this document says "standards track".

The title of the document says "recommendations" which would equa= te to a normative document of SHOULD strength

The abstract says "best practices"

Throughout the document I detected lots of lower case usage of RFC 2119 ter= ms but did not see any upper case usage (but may have missed it).

All of which leaves me confused.

Would the chairs like to clarify the intent of this document in terms of do= cument type?

Regards

Keith Drage


I don't think this documen= t describes any new protocol mechanisms, so the lack of upper case RFC 2119= terms seems to me personally fairly natural.=C2=A0 What it does instead is= lay out the results of doing IP address handling in specific modes, along = with a recommendation on which would make a reasonable default.

Cle= arly it could have been part of JSEP, which would have made it part of a st= andards track doc.=C2=A0 The value to me of it being separate is that the a= dvice can be revised independently of the core protocol specification.=C2= =A0 To that extent, it is somewhere between "Applicability statement&= quot; and "BCP" in our formal terminology, with a thumb very slig= htly on the scale toward BCP. Ultimately, though, I am willing to be guided= by our ADs or the community about the exact status.=C2=A0 The high order b= its are the advice and its decomposability.

regards,

Ted
--001a113edca8ce28c7052eab5157-- From nobody Wed Mar 23 01:40:52 2016 Return-Path: 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 3184A12D61C for ; Wed, 23 Mar 2016 01:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 M3mnIyYsWrCG for ; Wed, 23 Mar 2016 01:40:47 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B2F12D17B for ; Wed, 23 Mar 2016 01:40:46 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1aieLN-0007SA-25; Wed, 23 Mar 2016 09:40:45 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1aieLM-0000bU-Jh; Wed, 23 Mar 2016 09:40:45 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <56F16139.8010804@alvestrand.no> Date: Wed, 23 Mar 2016 09:40:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7E0CB31A-B52C-49C1-A631-F57A76820970@ifi.uio.no> References: <20160321223732.12239.92688.idtracker@ietfa.amsl.com> <84BAECBC-E849-424B-9EA1-6B80BA925F5F@ifi.uio.no> <56F16139.8010804@alvestrand.no> To: Harald Alvestrand X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 6 sum rcpts/h 15 sum msgs/h 8 total rcpts 39585 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D203B453AC4D8CCA22E1515DCB11AF1EA7BFD829 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 6 total 9502 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: rtcweb@ietf.org Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-transports-12.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 08:40:50 -0000 > On 22 Mar 2016, at 16:14, Harald Alvestrand = wrote: >=20 > Thank you - yes, it was lost. >=20 > I've filed this suggestion as > https://github.com/rtcweb-wg/rtcweb-transport/issues/16 Thanks! > My queries are of course: >=20 > - Is the reference to [coupled] normative or informative? Seeing that you made I-D.ietf-tsvwg-rtcweb-qos a normative reference, = I'd say this one should be normative too. For streams that are known to = share a bottleneck (e.g. between the same hosts and multiplexed), this = *always* works, not only when routers on your path happen to support it. > - What is the expected timeline for emission of [coupled]? I think we're quite close to the finish line. (I'll follow up with a = private email) > I see that RFC 7657 got published with [coupled] as an informative > reference. > The "e.g." in your first suggestion might be loose enough to warrant = an > informative reference. Well, I find it strange for I-D.ietf-tsvwg-rtcweb-qos to be normative = and [coupled] to be informative. Cheers, Michael >=20 > Den 22. mars 2016 15:45, skrev Michael Welzl: >> Hi, >>=20 >> On 26 February, I sent an email to rtcweb in which I made some = suggestions to this document. I see that these have not been = incorporated, and my email has also never been answered (except that = I-D.ietf-dart-dscp-rtp was replaced by RFC 7657, but that may not have = been due to my email). I can understand that: probably my prior email = just drowned in the WebRTC Audio Codec related thread. However I do = think that these comments would be good to address, so I'm copying in = the email again below. >>=20 >> Cheers, >> Michael >>=20 >> ---- >>=20 >> Hi, >>=20 >> Overall, I like this document a lot - it makes for a very good read! >>=20 >> - but I think it would make sense for section 4.1 to explicitly point = to draft-ietf-rmcat-coupled-cc (the next version of which is going to = explain how weights much be set to adhere to the priority levels that = are described in this section; it's easy, we just didn't have this text = in there yet). >>=20 >>=20 >> To be concrete, I suggest the following two changes: >>=20 >> *** >> When an WebRTC implementation has packets to send on multiple = streams >> that are congestion-controlled under the same congestion controller, >> the WebRTC implementation SHOULD cause data to be emitted in such a >> way that each stream at each level of priority is being given >> approximately twice the transmission capacity (measured in payload >> bytes) of the level below. >> *** >>=20 >> should be: >>=20 >> *** >> When a WebRTC implementation has packets to send on multiple streams >> that are congestion-controlled under the same congestion controller >> or multiple coupled congestion controllers (e.g. using the mechanism = in >> [draft-ietf-rmcat-coupled-cc]), >> the WebRTC implementation SHOULD cause data to be emitted in such a >> way that each stream at each level of priority is being given >> approximately twice the transmission capacity (measured in payload >> bytes) of the level below. >> *** >>=20 >> (note a fixed nit in there: the second word is "a" instead of "an") >>=20 >>=20 >> and, perhaps even more importantly, a small change in section 4.2: >>=20 >> *** >> More advice on the use of DSCP code points with RTP is given in >> [I-D.ietf-dart-dscp-rtp]. >> *** >>=20 >> should be: >>=20 >> *** >> More advice on the use of DSCP code points with RTP as well as = coupled >> congestion control is given in [I-D.ietf-dart-dscp-rtp]. >> *** >>=20 >> and in fact I-D.ietf-dart-dscp-rtp should now be RFC 7657. >>=20 >>=20 >> Cheers, >> Michael >>=20 From nobody Wed Mar 23 02:19:33 2016 Return-Path: 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 EF05812DB92 for ; Wed, 23 Mar 2016 02:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 B6--b6YUJpEz for ; Wed, 23 Mar 2016 02:19:24 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21CC812DB94 for ; Wed, 23 Mar 2016 02:19:23 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 7634A747741F8; Wed, 23 Mar 2016 09:09:09 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2N99Bgf026454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Mar 2016 09:09:11 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u2N996Lx032681 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Mar 2016 10:09:10 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.185]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 23 Mar 2016 10:09:08 +0100 From: "Drage, Keith (Nokia - GB)" To: EXT Ted Hardie Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt Thread-Index: AQHRgvg79H6EjfH6EUm6FTBySzZ8HZ9kqXjQgAFfygCAABr1wA== Date: Wed, 23 Mar 2016 09:09:08 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADEB0D16FR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 09:19:31 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADEB0D16FR712WXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXNzdW1pbmcgaXQgZG9lcyBub3QgY29udGFpbiBub3JtYXRpdmUgbGFuZ3VhZ2UgaW4gaXRzIG93 biByaWdodCwgdGhlbiBpdCBtaWdodCB3ZWxsIGJlIGEgQkNQLCBidXQgdGhlbiBpdCBuZWVkcyB0 byB0aWdodGVuIHVwIG9uIHNvbWUgb2YgaXRzIGludGVybmFsIGxhbmd1YWdlIOKAkyBpZiB3ZSBk b27igJl0IG1lYW4gUkZDIDIxMTkgbGFuZ3VhZ2UgdGhlbiB3ZSBzaG91bGQgdHJ5IGFuZCBhdm9p ZCB0aGUgbG93ZXIgY2FzZSBmb3JtcyBhcyB3ZWxsLCBpbiBvcmRlciB0byBhdm9pZCBjb25mdXNp b24uDQoNCknigJlkIG5vdGUgdGhhdCBpbiB0aGUgcGFzdCB0aGVyZSBoYXMgYmVlbiBzb21lIGRp c2N1c3Npb24gb2Ygd2hhdCBhIEJDUCByZWFsbHkgaXMgc28gdGhhdCBtaWdodCBhbHNvIHJlcXVp cmUgc29tZSBtb3JlIGRlYmF0ZS4NCg0KTXkgdW5kZXJzdGFuZGluZyBvZiBhbiBhcHBsaWNhYmls aXR5IGRvY3VtZW50IGlzIHRoYXQgaXQgaXMgYSBQUk9GSUxFIGFzIGRlZmluZWQgYnkgSVNPIDk2 NDYuIFRoYXQgbWVhbnMgdGhhdCBpdCBjb252ZXJ0cyBvcHRpb25hbCBjYXBhYmlsaXRpZXMgaW50 byBtYW5kYXRvcnkgb25lcyBhbmQgc28gb24uIFRob3NlIGluIHRoZW1zZWx2ZXMgYXJlIG5vcm1h dGl2ZSBzdGF0ZW1lbnRzIHRoYXQgd291bGQgcmVxdWlyZSBSRkMgMjExOSBsYW5ndWFnZS4gVGhp cyBkb2N1bWVudCBkb2VzIG5vdCBhcHBlYXIgdG8gYmUgc3VjaCBhIGRvY3VtZW50Lg0KDQpSZWdh cmRzDQoNCktlaXRoDQoNCkZyb206IEVYVCBUZWQgSGFyZGllIFttYWlsdG86dGVkLmlldGZAZ21h aWwuY29tXQ0KU2VudDogMjIgTWFyY2ggMjAxNiAyMzoxMA0KVG86IERyYWdlLCBLZWl0aCAoTm9r aWEgLSBHQikNCkNjOiBydGN3ZWJAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLXJ0Y3dlYi1pcC1oYW5kbGluZy0wMS50eHQNCg0KU3BlYWtpbmcg YXMgYW4gaW5kaXZpZHVhbCwgcmF0aGVyIHRoYW4gY2hhaXI6DQoNCk9uIFR1ZSwgTWFyIDIyLCAy MDE2IGF0IDM6MzEgQU0sIERyYWdlLCBLZWl0aCAoTm9raWEgLSBHQikgPGtlaXRoLmRyYWdlQG5v a2lhLmNvbTxtYWlsdG86a2VpdGguZHJhZ2VAbm9raWEuY29tPj4gd3JvdGU6DQpUaGUgaGVhZGVy IG9mIHRoaXMgZG9jdW1lbnQgc2F5cyAic3RhbmRhcmRzIHRyYWNrIi4NCg0KVGhlIHRpdGxlIG9m IHRoZSBkb2N1bWVudCBzYXlzICJyZWNvbW1lbmRhdGlvbnMiIHdoaWNoIHdvdWxkIGVxdWF0ZSB0 byBhIG5vcm1hdGl2ZSBkb2N1bWVudCBvZiBTSE9VTEQgc3RyZW5ndGgNCg0KVGhlIGFic3RyYWN0 IHNheXMgImJlc3QgcHJhY3RpY2VzIg0KDQpUaHJvdWdob3V0IHRoZSBkb2N1bWVudCBJIGRldGVj dGVkIGxvdHMgb2YgbG93ZXIgY2FzZSB1c2FnZSBvZiBSRkMgMjExOSB0ZXJtcyBidXQgZGlkIG5v dCBzZWUgYW55IHVwcGVyIGNhc2UgdXNhZ2UgKGJ1dCBtYXkgaGF2ZSBtaXNzZWQgaXQpLg0KDQpB bGwgb2Ygd2hpY2ggbGVhdmVzIG1lIGNvbmZ1c2VkLg0KDQpXb3VsZCB0aGUgY2hhaXJzIGxpa2Ug dG8gY2xhcmlmeSB0aGUgaW50ZW50IG9mIHRoaXMgZG9jdW1lbnQgaW4gdGVybXMgb2YgZG9jdW1l bnQgdHlwZT8NCg0KUmVnYXJkcw0KDQpLZWl0aCBEcmFnZQ0KDQoNCkkgZG9uJ3QgdGhpbmsgdGhp cyBkb2N1bWVudCBkZXNjcmliZXMgYW55IG5ldyBwcm90b2NvbCBtZWNoYW5pc21zLCBzbyB0aGUg bGFjayBvZiB1cHBlciBjYXNlIFJGQyAyMTE5IHRlcm1zIHNlZW1zIHRvIG1lIHBlcnNvbmFsbHkg ZmFpcmx5IG5hdHVyYWwuICBXaGF0IGl0IGRvZXMgaW5zdGVhZCBpcyBsYXkgb3V0IHRoZSByZXN1 bHRzIG9mIGRvaW5nIElQIGFkZHJlc3MgaGFuZGxpbmcgaW4gc3BlY2lmaWMgbW9kZXMsIGFsb25n IHdpdGggYSByZWNvbW1lbmRhdGlvbiBvbiB3aGljaCB3b3VsZCBtYWtlIGEgcmVhc29uYWJsZSBk ZWZhdWx0Lg0KDQpDbGVhcmx5IGl0IGNvdWxkIGhhdmUgYmVlbiBwYXJ0IG9mIEpTRVAsIHdoaWNo IHdvdWxkIGhhdmUgbWFkZSBpdCBwYXJ0IG9mIGEgc3RhbmRhcmRzIHRyYWNrIGRvYy4gIFRoZSB2 YWx1ZSB0byBtZSBvZiBpdCBiZWluZyBzZXBhcmF0ZSBpcyB0aGF0IHRoZSBhZHZpY2UgY2FuIGJl IHJldmlzZWQgaW5kZXBlbmRlbnRseSBvZiB0aGUgY29yZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9u LiAgVG8gdGhhdCBleHRlbnQsIGl0IGlzIHNvbWV3aGVyZSBiZXR3ZWVuICJBcHBsaWNhYmlsaXR5 IHN0YXRlbWVudCIgYW5kICJCQ1AiIGluIG91ciBmb3JtYWwgdGVybWlub2xvZ3ksIHdpdGggYSB0 aHVtYiB2ZXJ5IHNsaWdodGx5IG9uIHRoZSBzY2FsZSB0b3dhcmQgQkNQLiBVbHRpbWF0ZWx5LCB0 aG91Z2gsIEkgYW0gd2lsbGluZyB0byBiZSBndWlkZWQgYnkgb3VyIEFEcyBvciB0aGUgY29tbXVu aXR5IGFib3V0IHRoZSBleGFjdCBzdGF0dXMuICBUaGUgaGlnaCBvcmRlciBiaXRzIGFyZSB0aGUg YWR2aWNlIGFuZCBpdHMgZGVjb21wb3NhYmlsaXR5Lg0KcmVnYXJkcywNClRlZA0K --_000_949EF20990823C4C85C18D59AA11AD8BADEB0D16FR712WXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXNzdW1pbmcgaXQgZG9lcyBub3QgY29udGFp biBub3JtYXRpdmUgbGFuZ3VhZ2UgaW4gaXRzIG93biByaWdodCwgdGhlbiBpdCBtaWdodCB3ZWxs IGJlIGEgQkNQLCBidXQgdGhlbiBpdCBuZWVkcyB0byB0aWdodGVuIHVwIG9uIHNvbWUgb2YgaXRz IGludGVybmFsIGxhbmd1YWdlDQog4oCTIGlmIHdlIGRvbuKAmXQgbWVhbiBSRkMgMjExOSBsYW5n dWFnZSB0aGVuIHdlIHNob3VsZCB0cnkgYW5kIGF2b2lkIHRoZSBsb3dlciBjYXNlIGZvcm1zIGFz IHdlbGwsIGluIG9yZGVyIHRvIGF2b2lkIGNvbmZ1c2lvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmWQgbm90 ZSB0aGF0IGluIHRoZSBwYXN0IHRoZXJlIGhhcyBiZWVuIHNvbWUgZGlzY3Vzc2lvbiBvZiB3aGF0 IGEgQkNQIHJlYWxseSBpcyBzbyB0aGF0IG1pZ2h0IGFsc28gcmVxdWlyZSBzb21lIG1vcmUgZGVi YXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+TXkgdW5kZXJzdGFuZGluZyBvZiBhbiBhcHBsaWNhYmlsaXR5IGRvY3Vt ZW50IGlzIHRoYXQgaXQgaXMgYSBQUk9GSUxFIGFzIGRlZmluZWQgYnkgSVNPIDk2NDYuIFRoYXQg bWVhbnMgdGhhdCBpdCBjb252ZXJ0cyBvcHRpb25hbCBjYXBhYmlsaXRpZXMgaW50byBtYW5kYXRv cnkNCiBvbmVzIGFuZCBzbyBvbi4gVGhvc2UgaW4gdGhlbXNlbHZlcyBhcmUgbm9ybWF0aXZlIHN0 YXRlbWVudHMgdGhhdCB3b3VsZCByZXF1aXJlIFJGQyAyMTE5IGxhbmd1YWdlLiBUaGlzIGRvY3Vt ZW50IGRvZXMgbm90IGFwcGVhciB0byBiZSBzdWNoIGEgZG9jdW1lbnQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdh cmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5LZWl0aA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBFWFQgVGVkIEhhcmRpZSBbbWFpbHRv OnRlZC5pZXRmQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyMiBNYXJjaCAyMDE2IDIz OjEwPGJyPg0KPGI+VG86PC9iPiBEcmFnZSwgS2VpdGggKE5va2lhIC0gR0IpPGJyPg0KPGI+Q2M6 PC9iPiBydGN3ZWJAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtcnRjd2ViLWlwLWhhbmRsaW5nLTAxLnR4dDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3BlYWtpbmcgYXMgYW4gaW5kaXZp ZHVhbCwgcmF0aGVyIHRoYW4gY2hhaXI6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVHVlLCBNYXIgMjIsIDIwMTYgYXQgMzozMSBBTSwgRHJhZ2UsIEtlaXRoIChOb2tp YSAtIEdCKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtlaXRoLmRyYWdlQG5va2lhLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmtlaXRoLmRyYWdlQG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGhlYWRlciBvZiB0aGlzIGRvY3VtZW50IHNh eXMgJnF1b3Q7c3RhbmRhcmRzIHRyYWNrJnF1b3Q7Ljxicj4NCjxicj4NClRoZSB0aXRsZSBvZiB0 aGUgZG9jdW1lbnQgc2F5cyAmcXVvdDtyZWNvbW1lbmRhdGlvbnMmcXVvdDsgd2hpY2ggd291bGQg ZXF1YXRlIHRvIGEgbm9ybWF0aXZlIGRvY3VtZW50IG9mIFNIT1VMRCBzdHJlbmd0aDxicj4NCjxi cj4NClRoZSBhYnN0cmFjdCBzYXlzICZxdW90O2Jlc3QgcHJhY3RpY2VzJnF1b3Q7PGJyPg0KPGJy Pg0KVGhyb3VnaG91dCB0aGUgZG9jdW1lbnQgSSBkZXRlY3RlZCBsb3RzIG9mIGxvd2VyIGNhc2Ug dXNhZ2Ugb2YgUkZDIDIxMTkgdGVybXMgYnV0IGRpZCBub3Qgc2VlIGFueSB1cHBlciBjYXNlIHVz YWdlIChidXQgbWF5IGhhdmUgbWlzc2VkIGl0KS48YnI+DQo8YnI+DQpBbGwgb2Ygd2hpY2ggbGVh dmVzIG1lIGNvbmZ1c2VkLjxicj4NCjxicj4NCldvdWxkIHRoZSBjaGFpcnMgbGlrZSB0byBjbGFy aWZ5IHRoZSBpbnRlbnQgb2YgdGhpcyBkb2N1bWVudCBpbiB0ZXJtcyBvZiBkb2N1bWVudCB0eXBl Pzxicj4NCjxicj4NClJlZ2FyZHM8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJy Pg0KS2VpdGggRHJhZ2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PkkgZG9uJ3QgdGhpbmsgdGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYW55IG5ldyBwcm90b2NvbCBt ZWNoYW5pc21zLCBzbyB0aGUgbGFjayBvZiB1cHBlciBjYXNlIFJGQyAyMTE5IHRlcm1zIHNlZW1z IHRvIG1lIHBlcnNvbmFsbHkgZmFpcmx5IG5hdHVyYWwuJm5ic3A7IFdoYXQgaXQgZG9lcyBpbnN0 ZWFkIGlzIGxheSBvdXQgdGhlIHJlc3VsdHMgb2YgZG9pbmcgSVAgYWRkcmVzcw0KIGhhbmRsaW5n IGluIHNwZWNpZmljIG1vZGVzLCBhbG9uZyB3aXRoIGEgcmVjb21tZW5kYXRpb24gb24gd2hpY2gg d291bGQgbWFrZSBhIHJlYXNvbmFibGUgZGVmYXVsdC4NCjxicj4NCjxicj4NCkNsZWFybHkgaXQg Y291bGQgaGF2ZSBiZWVuIHBhcnQgb2YgSlNFUCwgd2hpY2ggd291bGQgaGF2ZSBtYWRlIGl0IHBh cnQgb2YgYSBzdGFuZGFyZHMgdHJhY2sgZG9jLiZuYnNwOyBUaGUgdmFsdWUgdG8gbWUgb2YgaXQg YmVpbmcgc2VwYXJhdGUgaXMgdGhhdCB0aGUgYWR2aWNlIGNhbiBiZSByZXZpc2VkIGluZGVwZW5k ZW50bHkgb2YgdGhlIGNvcmUgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbi4mbmJzcDsgVG8gdGhhdCBl eHRlbnQsIGl0IGlzIHNvbWV3aGVyZSBiZXR3ZWVuDQogJnF1b3Q7QXBwbGljYWJpbGl0eSBzdGF0 ZW1lbnQmcXVvdDsgYW5kICZxdW90O0JDUCZxdW90OyBpbiBvdXIgZm9ybWFsIHRlcm1pbm9sb2d5 LCB3aXRoIGEgdGh1bWIgdmVyeSBzbGlnaHRseSBvbiB0aGUgc2NhbGUgdG93YXJkIEJDUC4gVWx0 aW1hdGVseSwgdGhvdWdoLCBJIGFtIHdpbGxpbmcgdG8gYmUgZ3VpZGVkIGJ5IG91ciBBRHMgb3Ig dGhlIGNvbW11bml0eSBhYm91dCB0aGUgZXhhY3Qgc3RhdHVzLiZuYnNwOyBUaGUgaGlnaCBvcmRl ciBiaXRzIGFyZSB0aGUgYWR2aWNlIGFuZCBpdHMNCiBkZWNvbXBvc2FiaWxpdHkuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPnJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UZWQgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_949EF20990823C4C85C18D59AA11AD8BADEB0D16FR712WXCHMBA11z_-- From nobody Wed Mar 23 13:31:32 2016 Return-Path: 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 0BB7712D154 for ; Wed, 23 Mar 2016 13:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=L7QJPC2S; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=JMhMYE1h 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 yLNqfvtWCDT3 for ; Wed, 23 Mar 2016 13:31:30 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B72412D66C for ; Wed, 23 Mar 2016 13:31:30 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 735C52097F for ; Wed, 23 Mar 2016 16:31:29 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 23 Mar 2016 16:31:29 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=CmTE3rl6MpSHLiM3RnGCwr7u6Ws=; b=L7QJPC 2S6im4NN3FtrshUu3hV8omZ7+TznJCpPDeFdZMLKj+OfYJaOVX5kuj8yUDLlr87/ +pIj/I41ca6G6EPGSPEUezcFq/vLxTAOL2jH8HBuixvnL9QCQR1RF6rkXGIvkqjQ HxL2FB6dBrpNrNsEpGBerlV9Wz32oSNK3bHuA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=CmTE3rl6MpSHLiM 3RnGCwr7u6Ws=; b=JMhMYE1hPdUgthw1Hq9bSRlWRBveBUYNLhWcGZLpcd4xlwA S6Xl89hJgn6ailJIkn5tW8vJdcc0l2vqUxSWLkKjWEnTzhjb2TRP++Pwi5lafwAo tFbREtHrIXwk0K1w8JJPfiXjdah3iLItcevi+aSa6yAV7VLoHQ2Ph8mwpiMA= X-Sasl-enc: 7Oez5Elbo+Or+UFruTYUJRa5KenZS+nP1zv/LcYE1y87 1458765089 Received: from dhcp-171-68-122-59.cisco.com (dhcp-171-68-122-59.cisco.com [171.68.122.59]) by mail.messagingengine.com (Postfix) with ESMTPA id 031D0680230; Wed, 23 Mar 2016 16:31:28 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alissa Cooper In-Reply-To: Date: Wed, 23 Mar 2016 13:31:48 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7D1A3727-4AD3-49C4-B45F-25FF3EB01E85@cooperw.in> References: <6B474A50-6399-472F-BD7B-5286DCD209BA@cooperw.in> To: Martin Thomson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] AD evaluation: draft-ietf-rtcweb-alpn-02 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 20:31:32 -0000 These changes look good to me. Will issue IETF LC when you submit the = -03. Thanks, Alissa > On Mar 17, 2016, at 7:53 PM, Martin Thomson = wrote: >=20 > Thanks for the review Alissa, >=20 > I've put the changes up here: = https://github.com/martinthomson/drafts/pull/30 >=20 > I realize that you won't get a lot of time to look at this before I > want to push -03, but I thought that I'd offer you the chance at > least. >=20 > On 6 March 2016 at 09:44, Alissa Cooper wrote: >> =E2=80=9CConfidentiality protection=E2=80=9D is a fairly general = term, but it seems to be used throughout this document to mean something = much more specific, i.e., media that is confidential to two peers in a = webrtc connection. I think this needs to be clarified in the abstract = and Sections 1, 2, and 5 where the more specific meaning is intended. = Otherwise this document makes it sound as though data is being sent in = the clear when it is not. E.g., in Section 2 this text should be more = specific to confidentiality vis a vis the application: "However, data = provided over data channels does not receive confidentiality = protection.=E2=80=9D >=20 > Yes, the early sections only implicitly rely on the definition in > Section 3, and that isn't particularly strong. I've given this a > spin. >=20 >> =3D Section 3 =3D >>=20 >> "Any entity that forwards >> content, or records content for later access by entities other than >> the authenticated peer, SHOULD NOT offer or accept a session with = the >> "c-webrtc" identifier.=E2=80=9D >>=20 >> Acknowledging the there are other recommendations in this draft that = basically up to the implementation to follow, why is this requirement a = SHOULD NOT rather than a MUST NOT? >=20 > Made it a MUST. >=20 >> Nits: >>=20 >> =3D Section 1.1 =3D >>=20 >> Since this document uses RFC 2119 keywords, why does it not include = the standard disclaimer recommended by RFC 2119? I think it=E2=80=99s = fine to add further words to indicate that the normative requirements = are aimed at implementation behavior, but the standard text shouldn=E2=80=99= t be omitted. >=20 > OK, should that be the post-erratum boilerplate? >=20 >> Also, I=E2=80=99m not sure what it means for the document to "fall = back on shorthands for establishing interoperability requirements on = implementations.=E2=80=9D What is the alternative that it is falling = back from? >=20 > Actually saying what is meant using words. >=20 >> =3D Section 6.3 =3D >>=20 >> Is there a reason this reference is listed this way? >=20 > Blame the tools, which are a mystery to me. I wanted to cite a > specific section of the HTML5 spec, because finding a specific section > in there is a nightmare. From nobody Wed Mar 23 13:43:53 2016 Return-Path: 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 C0CC112D809 for ; Wed, 23 Mar 2016 13:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=ZLLhsn1X; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=N/GFEEk3 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 QNf8FbP1ToKs for ; Wed, 23 Mar 2016 13:43:50 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458D912D79C for ; Wed, 23 Mar 2016 13:43:50 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id ABEDC20B42 for ; Wed, 23 Mar 2016 16:43:49 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 23 Mar 2016 16:43:49 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=JOs Zh/nO0AinSuvmsSfVFGwLjy0=; b=ZLLhsn1XmqOrqUe8JcdQG2js+n4kVlbVAXy GxSw1Pq1vzq9c+IqaWW5e8JBzMeKNwbmHf8A5AHO3uRmWQmj2kJIYCokJN7ye6ss anwfIBYiiTQBYqtuSUjoKlNnDC+w+UwX447mDbEFZlO5umHndGYIv5hWrFJKR2hF ip5Xphr0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=JOsZh/nO0AinSuvmsSfVFGwLjy0=; b=N/GFE Ek3N/Q1KKWTCPJd8WoUvR/iZc0mZrennKvWZ4TVWluS+WW48XRLw/hA/CSGXKG/H A3tY4UygsVBIKw/cS4GykhYDNYdfckmg4csXOqy1fVH8cAu4tMP82J1051jl00tU 4D/c5UP4c0mCka6fAEDbfD9m/1sXt+dhP9eC2k= X-Sasl-enc: jal8dsLWhkF4TcOpxHJCQeya46xwmn7MixeCkphfagfB 1458765829 Received: from dhcp-171-68-122-59.cisco.com (dhcp-171-68-122-59.cisco.com [171.68.122.59]) by mail.messagingengine.com (Postfix) with ESMTPA id 2DE616801C9; Wed, 23 Mar 2016 16:43:49 -0400 (EDT) From: Alissa Cooper Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Mar 2016 13:44:08 -0700 Message-Id: <4F3B615A-A77A-434E-B3A9-DDABE8994373@cooperw.in> To: ietf@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Cc: rtcweb@ietf.org Subject: [rtcweb] Last call redux: draft-ietf-rtcweb-rtp-usage-26 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 20:43:51 -0000 draft-ietf-rtcweb-rtp-usage-25 was approved for publication in July 2015 = and is in the RFC Editor's queue. Subsequently, the RTCWEB WG identified = a change that needed to be made in Section 4.5 related to multiplexing = RTP and RTCP. The change is reflected in draft-ietf-rtcweb-rtp-usage-26 = and copied below. The IESG will not revisit its decision to approve this document for = publication unless it receives feedback from the community indicating a = need to do so. Please send substantive comments to the ietf@ietf.org = mailing list by 2016-04-13. Exceptionally, comments may be sent to = iesg@ietf.org instead. The change is: OLD: If SDP is used for signalling, this negotiation MUST use the attributes defined in [RFC5761]. For backwards compatibility, implementations are also REQUIRED to support RTP and RTCP sent on separate transport-layer flows. NEW: If SDP is used for signalling, this negotiation MUST use the mechanism defined in [RFC5761]. Implementations can also support sending RTP and RTCP on separate transport-layer flows, but this is OPTIONAL to implement. If an implementation does not support RTP and RTCP sent on separate transport-layer flows, it MUST indicate that using the mechanism defined in [I-D.ietf-mmusic-mux-exclusive]. =20 The document is available at = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/= From nobody Thu Mar 24 14:00:00 2016 Return-Path: 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 5769712D87D; Thu, 24 Mar 2016 13:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 lR-8exbQwnuS; Thu, 24 Mar 2016 13:59:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A67512D876; Thu, 24 Mar 2016 13:59:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 569D7180209; Thu, 24 Mar 2016 13:59:38 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160324205938.569D7180209@rfc-editor.org> Date: Thu, 24 Mar 2016 13:59:38 -0700 (PDT) Archived-At: Cc: rtcweb@ietf.org, rfc-editor@rfc-editor.org Subject: [rtcweb] RFC 7742 on WebRTC Video Processing and Codec Requirements X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 20:59:59 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7742 Title: WebRTC Video Processing and Codec Requirements Author: A.B. Roach Status: Standards Track Stream: IETF Date: March 2016 Mailbox: adam@nostrum.com Pages: 10 Characters: 21184 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-rtcweb-video-06.txt URL: https://www.rfc-editor.org/info/rfc7742 DOI: http://dx.doi.org/10.17487/RFC7742 This specification provides the requirements and considerations for WebRTC applications to send and receive video across a network. It specifies the video processing that is required as well as video codecs and their parameters. This document is a product of the Real-Time Communication in WEB-browsers Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sun Mar 27 01:42:55 2016 Return-Path: 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 6041912D0FA for ; Sun, 27 Mar 2016 01:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 8T72w-nLph4n for ; Sun, 27 Mar 2016 01:42:50 -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 47F6312D119 for ; Sun, 27 Mar 2016 01:42:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 56AC27C7B6A for ; Sun, 27 Mar 2016 10:42:48 +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 GFNHPa8BnBM6 for ; Sun, 27 Mar 2016 10:42:46 +0200 (CEST) Received: from [IPv6:2001:470:de0a:1:883d:c8db:314c:bb59] (unknown [IPv6:2001:470:de0a:1:883d:c8db:314c:bb59]) by mork.alvestrand.no (Postfix) with ESMTPSA id B07027C7B10 for ; Sun, 27 Mar 2016 10:42:46 +0200 (CEST) To: rtcweb@ietf.org References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Harald Alvestrand X-Enigmail-Draft-Status: N1110 Message-ID: <56F79D05.8070004@alvestrand.no> Date: Sun, 27 Mar 2016 10:42:45 +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: <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 08:42:53 -0000 Den 23. mars 2016 10:09, skrev Drage, Keith (Nokia - GB): > Assuming it does not contain normative language in its own right, then > it might well be a BCP, but then it needs to tighten up on some of its > internal language if we dont mean RFC 2119 language then we should > try and avoid the lower case forms as well, in order to avoid confusion. Matter of principle: I've argued against this idea for the last 10 years .... avoiding common verbs makes it harder to write English. Enough people have a hard time with that already that we shouldn't make it harder. If we mean something by the UPPERCASE form, we should stop trying to police the lowercase ones. Indeed, the policing of the lowercase forms serves to increase confusion between the forms, not decrease it: "if this lowercase should is still there, does it mean that it wasn't policed out, or that it was intended to be uppercase?" > > > > Id note that in the past there has been some discussion of what a BCP > really is so that might also require some more debate. BCP is a blanket term used to cover a multitude of sins. In this particular instance, I'd prefer to have it standards track. It's a practice that might change over time, and where multiple variants can exist at the same time (each endpoint practices it independently of all the others). I haven't made specific wording change proposals yet; I might get to it. > > My understanding of an applicability document is that it is a PROFILE as > defined by ISO 9646. That means that it converts optional capabilities > into mandatory ones and so on. Those in themselves are normative > statements that would require RFC 2119 language. This document does not > appear to be such a document. The number of ASes emitted is low.... RFC 7603 Energy Management AS RFC 7057 Update to the EAP AS for... RFC 6944 AS: DSNS ecurity (DNNSSEC) DNSKEY Algorithm Implementation Status RFC 6936 AS for the use of IPv6 UDP Datagrams with Zero Checksums There are a few. > > > > Regards > > > > Keith > > > > *From:*EXT Ted Hardie [mailto:ted.ietf@gmail.com] > *Sent:* 22 March 2016 23:10 > *To:* Drage, Keith (Nokia - GB) > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt > > > > Speaking as an individual, rather than chair: > > > > On Tue, Mar 22, 2016 at 3:31 AM, Drage, Keith (Nokia - GB) > > wrote: > > The header of this document says "standards track". > > The title of the document says "recommendations" which would equate to a > normative document of SHOULD strength > > The abstract says "best practices" > > Throughout the document I detected lots of lower case usage of RFC 2119 > terms but did not see any upper case usage (but may have missed it). > > All of which leaves me confused. > > Would the chairs like to clarify the intent of this document in terms of > document type? > > Regards > > Keith Drage > > > > > > I don't think this document describes any new protocol mechanisms, so > the lack of upper case RFC 2119 terms seems to me personally fairly > natural. What it does instead is lay out the results of doing IP > address handling in specific modes, along with a recommendation on which > would make a reasonable default. > > Clearly it could have been part of JSEP, which would have made it part > of a standards track doc. The value to me of it being separate is that > the advice can be revised independently of the core protocol > specification. To that extent, it is somewhere between "Applicability > statement" and "BCP" in our formal terminology, with a thumb very > slightly on the scale toward BCP. Ultimately, though, I am willing to be > guided by our ADs or the community about the exact status. The high > order bits are the advice and its decomposability. > > regards, > > Ted > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > From nobody Sun Mar 27 09:19:48 2016 Return-Path: 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 293EA12D151 for ; Sun, 27 Mar 2016 09:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 TT3uXf_k69aN for ; Sun, 27 Mar 2016 09:19:44 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0738.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::738]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8FCE12D106 for ; Sun, 27 Mar 2016 09:19:43 -0700 (PDT) Received: from BLUPR17MB0275.namprd17.prod.outlook.com (10.162.235.146) by BLUPR17MB0274.namprd17.prod.outlook.com (10.162.235.145) with Microsoft SMTP Server (TLS) id 15.1.443.12; Sun, 27 Mar 2016 16:19:24 +0000 Received: from BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) by BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) with mapi id 15.01.0443.016; Sun, 27 Mar 2016 16:19:24 +0000 From: Stephan Wenger To: Harald Alvestrand , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt Thread-Index: AQHRgvg6v7NgHmzhqkyBuF0Tb9YB1p9lRiAAgADT5QCAAKdaAIAGQfSAgAAKOwA= Date: Sun, 27 Mar 2016 16:19:24 +0000 Message-ID: <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> In-Reply-To: <56F79D05.8070004@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alvestrand.no; dkim=none (message not signed) header.d=none;alvestrand.no; dmarc=none action=none header.from=stewe.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.174.30.183] x-ms-office365-filtering-correlation-id: d6fafba4-e97d-4042-e51b-08d3565b9000 x-microsoft-exchange-diagnostics: 1; BLUPR17MB0274; 5:A/dt7so4WNq0qcWUEP9uv7Y26PTpHWeT9OFIJmYvABHFAQUm2LGIzvBN44yS4XNOsbxeq2vr9mlfA8/KzET9tECvYCzfc/jWTTHUJ6fUeBUd4a+kra8kqf58sVPaPpTGsd/ztZHfGF5mPSVBWbZ2+A==; 24:Zpy4kmLkZRJPkYYP80MgsKyK8GRbuyi4ilSTjbLCME/9smw4Ro+77670KNt7jBmfcLuwFFjM4kNqdoH2lYuUTmfUoBUFBjxbZj02/zub9CM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR17MB0274; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040046)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041046)(6043046); SRVR:BLUPR17MB0274; BCL:0; PCL:0; RULEID:; SRVR:BLUPR17MB0274; x-forefront-prvs: 089473E5FE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(3280700002)(1096002)(102836003)(92566002)(1220700001)(93886004)(6116002)(54356999)(76176999)(50986999)(122556002)(107886002)(230783001)(11100500001)(106116001)(36756003)(189998001)(5001770100001)(3660700001)(99286002)(5002640100001)(2900100001)(19580405001)(19580395003)(2950100001)(83716003)(66066001)(82746002)(86362001)(10400500002)(33656002)(81166005)(586003)(2906002)(2501003)(5008740100001)(5004730100002)(3846002)(77096005)(87936001)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR17MB0274; H:BLUPR17MB0275.namprd17.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2016 16:19:24.0487 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR17MB0274 Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 16:19:47 -0000 DQoNCg0KDQoNCk9uIDMvMjcvMTYsIDAxOjQyLCAicnRjd2ViIG9uIGJlaGFsZiBvZiBIYXJhbGQg QWx2ZXN0cmFuZCIgPHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBoYXJhbGRA YWx2ZXN0cmFuZC5ubz4gd3JvdGU6DQoNCj5EZW4gMjMuIG1hcnMgMjAxNiAxMDowOSwgc2tyZXYg RHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdCKToNCj4+IEFzc3VtaW5nIGl0IGRvZXMgbm90IGNvbnRh aW4gbm9ybWF0aXZlIGxhbmd1YWdlIGluIGl0cyBvd24gcmlnaHQsIHRoZW4NCj4+IGl0IG1pZ2h0 IHdlbGwgYmUgYSBCQ1AsIGJ1dCB0aGVuIGl0IG5lZWRzIHRvIHRpZ2h0ZW4gdXAgb24gc29tZSBv ZiBpdHMNCj4+IGludGVybmFsIGxhbmd1YWdlIOKAkyBpZiB3ZSBkb27igJl0IG1lYW4gUkZDIDIx MTkgbGFuZ3VhZ2UgdGhlbiB3ZSBzaG91bGQNCj4+IHRyeSBhbmQgYXZvaWQgdGhlIGxvd2VyIGNh c2UgZm9ybXMgYXMgd2VsbCwgaW4gb3JkZXIgdG8gYXZvaWQgY29uZnVzaW9uLg0KPg0KPk1hdHRl ciBvZiBwcmluY2lwbGU6DQo+DQo+SSd2ZSBhcmd1ZWQgYWdhaW5zdCB0aGlzIGlkZWEgZm9yIHRo ZSBsYXN0IDEwIHllYXJzIC4uLi4gYXZvaWRpbmcgY29tbW9uDQo+dmVyYnMgbWFrZXMgaXQgaGFy ZGVyIHRvIHdyaXRlIEVuZ2xpc2guIEVub3VnaCBwZW9wbGUgaGF2ZSBhIGhhcmQgdGltZQ0KPndp dGggdGhhdCBhbHJlYWR5IHRoYXQgd2Ugc2hvdWxkbid0IG1ha2UgaXQgaGFyZGVyLg0KPg0KPklm IHdlIG1lYW4gc29tZXRoaW5nIGJ5IHRoZSBVUFBFUkNBU0UgZm9ybSwgd2Ugc2hvdWxkIHN0b3Ag dHJ5aW5nIHRvDQo+cG9saWNlIHRoZSBsb3dlcmNhc2Ugb25lcy4gSW5kZWVkLCB0aGUgcG9saWNp bmcgb2YgdGhlIGxvd2VyY2FzZSBmb3Jtcw0KPnNlcnZlcyB0byBpbmNyZWFzZSBjb25mdXNpb24g YmV0d2VlbiB0aGUgZm9ybXMsIG5vdCBkZWNyZWFzZSBpdDogImlmDQo+dGhpcyBsb3dlcmNhc2Ug c2hvdWxkIGlzIHN0aWxsIHRoZXJlLCBkb2VzIGl0IG1lYW4gdGhhdCBpdCB3YXNuJ3QNCj5wb2xp Y2VkIG91dCwgb3IgdGhhdCBpdCB3YXMgaW50ZW5kZWQgdG8gYmUgdXBwZXJjYXNlPyINCg0KVGhp cyBjYW4gYmUgdHJpdmlhbGx5IGFjY29tcGxpc2hlZCwgd2l0aG91dCBwb2xpY3kgY2hhbmdlLiAg SSBoYXZlIHB1dCB0aGUgbGFuZ3VhZ2UgYmVsb3cgb24gbW9zdCAob3IgYWxsPykgb2YgbXkgcmVj ZW50IGRyYWZ0cyBhbmQgUkZDcy4gIEFuIGV4YW1wbGUgZnJvbSBSRkMgNzc5ODoNCg0KIg0KICAg VGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJT SEFMTA0KICAgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1B WSIsIGFuZA0KICAgIk9QVElPTkFMIiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnBy ZXRlZCBhcyBkZXNjcmliZWQgaW4NCiAgIEJDUCAxNCwgUkZDIDIxMTkgW1JGQzIxMTldLg0KDQog ICBJbiB0aGlzIGRvY3VtZW50LCB0aGVzZSBrZXkgd29yZHMgd2lsbCBhcHBlYXIgd2l0aCB0aGF0 DQogICBpbnRlcnByZXRhdGlvbiBvbmx5IHdoZW4gaW4gQUxMIENBUFMuICBMb3dlciBjYXNlIHVz ZXMgb2YgdGhlc2UNCiAgIHdvcmRzIGFyZSBub3QgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgY2Fycnlp bmcgdGhlIFJGQyAyMTE5DQogICBzaWduaWZpY2FuY2UuDQoNCuKAnA0KDQpTdGVwaGFuDQoNCg== From nobody Sun Mar 27 13:28:38 2016 Return-Path: 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 8EFCE12D551 for ; Sun, 27 Mar 2016 13:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3ZnuptQ2vHSs for ; Sun, 27 Mar 2016 13:28:34 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50A212D18F for ; Sun, 27 Mar 2016 13:28:33 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id e185so136305170vkb.1 for ; Sun, 27 Mar 2016 13:28:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=kfcYJ0y3k26fCAZe1+Kfc6z85I4qBv3wKk6aODsg4QA=; b=caq5S2SbG8QUc2bq7dEimo0piOtSk3qtrx0p/qjRof441JuiIwKB5/GaFkZjYpSiCf GMstrSBzhDRYjE8cwGLWRhE7NI7cTLXgRVWrPyaprt92q/HOo7DNgQ9Z9XzeXrBaK2gR KbpMoqBk7GGPqDsT0RAET9xXHViIdw7a1By7QlSjEPf9Vgv19ELbjtCQt/j8J+U5q/ld JNNrVGbJf9rea0OcyMQl3JidhCzYsrndPgNxcwfjho6EvIBibBqVjuQrNYK/Qr5LP531 R05xG5jhZCdopw0zWKnbZjlQgy5sVETN5giglBfo7uQ1bWpXbUEOYr2j1Z397AQMjdkd CdQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kfcYJ0y3k26fCAZe1+Kfc6z85I4qBv3wKk6aODsg4QA=; b=J96p4mXxG/Da+pSIcNDCtt6vCXKjZxaZjzlFmGoNyuvRW58YNxnNLAiOWDD2BWgstC BAE/eu59ZNWLIu1FpTILd3gTnlb3253PY+hh6h+vt3J4do8UzaD03b+bBjUyHftbeS4z 9JO2zGysBZsHjBKq0+K9cSGQ3yrXK3KM01KFa9vdGiv9hA0InJmu/V3HP9+t+VNKls+w 3J9iQuae/8eRWP91WjOwyV7X9/Q5+DWeb3w/KItlsOWoQz5GetwCVJoEjbjaBJcZyZoT 6Ff4SuwOhL9alRPDjfeW1drqkGv4vLcnxk6os/psWoBZmNL9Nc98e5BGXsMNw0wYbXpx V8hQ== X-Gm-Message-State: AD7BkJJhSB5pAXSvjC1zv6aFxHfQLpE+CednWphQ3NznG/cWnpsBkCbq0w45gXRqzhMJrAOqfLurx9GXg/gEbA== MIME-Version: 1.0 X-Received: by 10.31.154.21 with SMTP id c21mr12443295vke.38.1459110512714; Sun, 27 Mar 2016 13:28:32 -0700 (PDT) Received: by 10.176.66.199 with HTTP; Sun, 27 Mar 2016 13:28:32 -0700 (PDT) In-Reply-To: <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> Date: Sun, 27 Mar 2016 13:28:32 -0700 Message-ID: From: Suhas Nandakumar To: Stephan Wenger Content-Type: multipart/alternative; boundary=001a1140ed44cc6ad1052f0da37a Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2016 20:28:36 -0000 --001a1140ed44cc6ad1052f0da37a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sunday, March 27, 2016, Stephan Wenger wrote: > > > > > > On 3/27/16, 01:42, "rtcweb on behalf of Harald Alvestrand" < > rtcweb-bounces@ietf.org on behalf of harald@alvestrand.no > > wrote: > > >Den 23. mars 2016 10:09, skrev Drage, Keith (Nokia - GB): > >> Assuming it does not contain normative language in its own right, then > >> it might well be a BCP, but then it needs to tighten up on some of its > >> internal language =E2=80=93 if we don=E2=80=99t mean RFC 2119 language= then we should > >> try and avoid the lower case forms as well, in order to avoid confusio= n. > > > >Matter of principle: > > > >I've argued against this idea for the last 10 years .... avoiding common > >verbs makes it harder to write English. Enough people have a hard time > >with that already that we shouldn't make it harder. > > > >If we mean something by the UPPERCASE form, we should stop trying to > >police the lowercase ones. Indeed, the policing of the lowercase forms > >serves to increase confusion between the forms, not decrease it: "if > >this lowercase should is still there, does it mean that it wasn't > >policed out, or that it was intended to be uppercase?" > > This can be trivially accomplished, without policy change. I have put th= e > language below on most (or all?) of my recent drafts and RFCs. An exampl= e > from RFC 7798: > > " > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > BCP 14, RFC 2119 [RFC2119]. > > In this document, these key words will appear with that > interpretation only when in ALL CAPS. Lower case uses of these > words are not to be interpreted as carrying the RFC 2119 > significance. > > =E2=80=9C Like this approach +1 > > Stephan > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a1140ed44cc6ad1052f0da37a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sunday, March 27, 2016, Stephan Wenger <stewe@stewe.org> wrote:





On 3/27/16, 01:42, "rtcweb on behalf of Harald Alvestrand" <rtcweb-bounces@ietf.org on behalf of harald@alvestrand.no> wrote:

>Den 23. mars 2016 10:09, skrev Drage, Keith (Nokia - GB):
>> Assuming it does not contain normative language in its own right, = then
>> it might well be a BCP, but then it needs to tighten up on some of= its
>> internal language =E2=80=93 if we don=E2=80=99t mean RFC 2119 lang= uage then we should
>> try and avoid the lower case forms as well, in order to avoid conf= usion.
>
>Matter of principle:
>
>I've argued against this idea for the last 10 years .... avoiding c= ommon
>verbs makes it harder to write English. Enough people have a hard time<= br> >with that already that we shouldn't make it harder.
>
>If we mean something by the UPPERCASE form, we should stop trying to >police the lowercase ones. Indeed, the policing of the lowercase forms<= br> >serves to increase confusion between the forms, not decrease it: "= if
>this lowercase should is still there, does it mean that it wasn't >policed out, or that it was intended to be uppercase?"

This can be trivially accomplished, without policy change.=C2=A0 I have put= the language below on most (or all?) of my recent drafts and RFCs.=C2=A0 A= n example from RFC 7798:

"
=C2=A0 =C2=A0The key words "MUST", "MUST NOT", "RE= QUIRED", "SHALL", "SHALL
=C2=A0 =C2=A0NOT", "SHOULD", "SHOULD NOT", "R= ECOMMENDED", "MAY", and
=C2=A0 =C2=A0"OPTIONAL" in this document are to be interpreted as= described in
=C2=A0 =C2=A0BCP 14, RFC 2119 [RFC2119].

=C2=A0 =C2=A0In this document, these key words will appear with that
=C2=A0 =C2=A0interpretation only when in ALL CAPS.=C2=A0 Lower case uses of= these
=C2=A0 =C2=A0words are not to be interpreted as carrying the RFC 2119
=C2=A0 =C2=A0significance.

=E2=80=9C

Like this approach +1=C2=A0

Stephan

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--001a1140ed44cc6ad1052f0da37a-- From nobody Sun Mar 27 18:51:26 2016 Return-Path: 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 3685A12D0A2; Sun, 27 Mar 2016 18:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 cj-faWe2vs56; Sun, 27 Mar 2016 18:51:22 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on0090.outbound.protection.outlook.com [104.47.125.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCCFF12D106; Sun, 27 Mar 2016 18:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=C/t8VOQynwG4yJb9YD7+sZAuOWGhIPQRm+/3uYr61kg=; b=IRsFrBdnv0Bi1evc2+I8vcvn1jojeqVcUoAP9dAGKrpMhl3gEQ1uj4eWp39Qjh2ycpBq1G9Qn7+UTcqVCKD6v9wAK7n7cVtHwV0gkkRKSsi8Fnwc/2GChDvNHORZ1yj7rTAdaWDD+4TP2lIlTyndnqNZzvDI22cBdcxcmOOWHz0= Authentication-Results: rfc-editor.org; dkim=none (message not signed) header.d=none;rfc-editor.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by OS2PR01MB0915.jpnprd01.prod.outlook.com (10.167.178.21) with Microsoft SMTP Server (TLS) id 15.1.447.15; Mon, 28 Mar 2016 01:51:18 +0000 To: Stephan Wenger , Harald Alvestrand , "rtcweb@ietf.org" References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <56F88E18.2060506@it.aoyama.ac.jp> Date: Mon, 28 Mar 2016 10:51:20 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: KAWPR01CA0004.jpnprd01.prod.outlook.com (10.161.24.14) To OS2PR01MB0915.jpnprd01.prod.outlook.com (10.167.178.21) X-MS-Office365-Filtering-Correlation-Id: eaa0ff4e-03a1-4737-0373-08d356ab74b6 X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0915; 2:2NgLCuTQp6ukZ1N79oB8Euayct5UnaQccjCReXsNoLKOnNHSVU7pmA8lkCAr5O0jzEM38l0GNwqmXL5g1OfmwxcA+lbXoDa19wTCJR+lRQokmmGv4bZRaC9QLUtqYScRj7ImWsnMAADaUcA+6I7RbpD5qOJnXLhXSILBjfX57tnN07cN0FEi+FMfHat96wzk; 3:wu1KHvgT9dOc/iq5Mq8PyzstvDfwKjIFkCRf4iYuBv+6/ctP422B6bkYprOEnv8QlM+BRnazxk5Zo0FfGIfVlcjWVk48JL2BM6cj8usljgvGChmJRWb5MCQNsFDGK3dn X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS2PR01MB0915; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0915; 25:r7AW67Fpu1G7fshp2lUkpuDYglSOKLcQK1cHFfFtLHtzohoypHbgMbk6xG/qe8hL3dSA1XfzhJga574lqUJu9pCHJ9FA99mwrORnJVKSeHiCm74iCu/a3KPxtdOcbSbL8SkcAQLEzIOKk8gz046DSz1r4XIiP31O5Z3G0tgZfAT1ZQpv7wzf9wzDYuS7N9DwTKjEu/iWzkQObRJJSIL5Rv6JbwVXC6ySfm367WJnYu7SOHKr68RTDZVo7UW1/EdMQ9MjDcwlK49A86tN6wP/AzgcF+YX/YN8MUc8G/xMhOpmazC77T3E+AAOz0xktOzQbq0A6/OmwYIJ0UMCbEwUFD+SUsX6hVV5rAcV6dFopn8HbTSjzU+vAOwuqsGmYX2uKBob0kGe0Y8VckcS8PXQvLM8CBRNKFyn7NWTwZipP4fqqmkTuY7BoMDHf5tLZFGCFgQHEWvVhmIhcTcDBzz+jMQLvk5+wVW7P8WuzfJysFRNfDjOXmlP/9Mo+vcX0nDUTj0FFPCNBs7RXcNzKjU1eEfGtkeZ5O4aF4pPtdnBTEDztboyDAqIWjD0WshCW+vAstemGQ6ygSftgCRcvXZhfxYQtzOvMckvpY9AMDGlv75oqcwf73Dmca1tc0gm9TNPdKzb1TaFmHH4ZIQ5eQwubTYiUgytxL9d7eDWNn4UkKs= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040046)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041046)(6042046)(6043046); SRVR:OS2PR01MB0915; BCL:0; PCL:0; RULEID:; SRVR:OS2PR01MB0915; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0915; 4:iu9/ofgCxOKnMi6R7FvCfS4Vqg7yXUKf5LYeGbVQ7hKtwGrz0f4tmpk0o7KKx7Xow1toG+Yz7lhH3UBb/6QP6nd0LV1/dKWpLqxDR/ixpgOKGLL6EaUgDckP4JCEe3SN/5wmdZHh9xsYr5QW6e66Jd+kwouqIk8dbePa+l0LWPz138oCRZz5RGqV/ak4TCT1rl84RgOJWRNKXE9nD7ginOMgHNEq+DCcIH9Hl4yYkDeo5quWD+O8iIhPh8aQYH9+MqXzfBgyzKrC6lfEl6Y9MaNzy1IVooFrNfCxSxT+Mt9hO4itrtNvJ7I+qLc6AvaKs29JxOypmLrGm9hhBEqALdxfGNalwisnAcKJsTxsjm0hVOyuRaEfYZAPn3gaspZ+h6PMSamB0X2q96LDJAhABapiodiOJacGwNDxVac3wUw= X-Forefront-PRVS: 0895DF8FFD X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(24454002)(23676002)(64126003)(2870700001)(83506001)(33656002)(47776003)(230783001)(93886004)(2501003)(65956001)(65806001)(66066001)(6116002)(3846002)(86362001)(5001770100001)(92566002)(5008740100001)(4326007)(50466002)(1096002)(5004730100002)(19580395003)(54356999)(189998001)(2950100001)(50986999)(15975445007)(81166005)(586003)(2906002)(74482002)(19580405001)(80316001)(77096005)(65816999)(76176999)(42186005)(87266999)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0915; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwOTE1OzIzOmNEbmpXOWNaVGN0Q2txVjdjZjJXV3JldUpn?= =?utf-8?B?L3BpOVVYYThKcXZFYjNkenZrV041RG9OWTlUcE0wcGU0Zm00c3I2d2xVMHJW?= =?utf-8?B?VnNvai9SVUZKeEo4ZzdJNVUraEFLODNjNlRqTUJMdmNFT09PejZ6V0VLbVJV?= =?utf-8?B?UVpGdkFvVjYwSFBJRkJ6L3hjNWo0UTVLZWliNTZCV0pETUxybXpJbTV5QU45?= =?utf-8?B?QlZXZVZXUDVBK1ZpK3VvbUdZalZQdU9xWjY4MEFzc2R0OEh6ZFB2blFQQmVh?= =?utf-8?B?SEZXdkVHaTR6QUcvcjYvRWJHWW5QZ2k0VkxDRkJESGFPYmN2aDhINnRmRHNY?= =?utf-8?B?QytqeVh3VkJCbFBmM0hXSXM1VWZjZVVQUDhsbzlMUnJ5NzhqMENrVjNCTFc0?= =?utf-8?B?ZWJTUzVKZUthdDY0MVhST3dPUnQ1dTBiQ09La1VkNlJrVnVldTBUbEhJZmJX?= =?utf-8?B?V05qT1RpbUk2VUlKT3hGbWdlNGoycXJFajRYRDdrOWpLdnlaQ2w2cnBzekdJ?= =?utf-8?B?VjQyUXJrck1kWUQzWW45bEJOWDB0OEZaRWxDeE5rMnV6eGxtWGRuSW1mWXpq?= =?utf-8?B?U2lZVU9obHZLQUc5dlZBTFRUa3ZTSWJiVEFCU2ZIMWc3aUVlMzNaZkpEWWVY?= =?utf-8?B?dm91bForTnVLcmlPVXZ1aC9FOGVGMCtCZzhyUU1tOXc1YkRMUUZwc1BnOGsw?= =?utf-8?B?bmltdmY1Q24rMUZDUSsrY0wrb0poVzFlSHJ3eXQ3aDZHd01OelVCMFdqNlVI?= =?utf-8?B?dzhUZkFRNmVPd2RYRm1wK0lYVklRWXdOcS9WZGFvM3NwdEhNKy9KUm9DQWdV?= =?utf-8?B?OEFXdHpaeU96MVNWQjZqQ0xpL3BmVWFJb05lbWRleEozeDRmKzRGYk11VGkr?= =?utf-8?B?V0xEbFFqblJ6cGRDQmM0eEJPSFphdHYzWDZRZmZ1aEFrMk5TUjZCNVhZbTBI?= =?utf-8?B?L0VWM09EU3oxakp1bDUxTkRQMlRoY3E3akh3dTRacklhNWJKM0NDTzFReGdz?= =?utf-8?B?ZEJCNEVrMzluVExUVTd4SXJuTU1UVUM0RG4yRzc0bWNsSzd4VXNpd1FuaGpt?= =?utf-8?B?Q21UMDRsWVNRNzc0ZUsvMXRiQXRyMStEZXBoZ3pyZ1UwczI0Y2hQN1NjbVZo?= =?utf-8?B?a205SXU5MEQ3djI5c3FGcjAxVndaRlp5MXVrNktHcG9zdXNTOEJtM3VudzVL?= =?utf-8?B?YjMzaTByRW9EOUp0V3VoOWt1M1VPOTQxVGJ1SEl4Qm1sMDR1SGdlcE8xU0s1?= =?utf-8?B?eUdINlBQYXZRbmM3Z3VUTllnT2sydVZhcmJCclRqR0hqYnMzL0lRV1R5WVZE?= =?utf-8?B?djExNE9lWDA2SXNiUHptS2tMYWRta29reExzc2NOZmV4SUd3NWl6TjFRTFlr?= =?utf-8?B?UExBRVI2S3dLTEI3N2dvamJzbE9wQzZ1ckxNbGFnQnZURFIxNmo3NlRZaXJt?= =?utf-8?B?NFZ1QmNNa0k1ZHZ6Q2FHNk4rS1BtSkltZmd3eExaeG1hazdYbEVoTG5SMUFZ?= =?utf-8?B?V2dXWUZnWFF3bjNXTElXMS9nUjhaV1FmZUVjOUc0Zks4Q1QzY2RGZkpOa3Zp?= =?utf-8?B?dlgrOXppOWlVMDFxVFNicm1QdHpKUFE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0915; 5:tjPyJj6ZqeTBeHUaWrIQe0wN7OrE4Zk2vg0EHa+Qf1lEyZR+ACo55z+6Nkw0eAhnoDbj1W25eiQMAqRXcuiw46nGY6EHZN4XruKiTOsDflAye1liKCZAetuXnzRHObkMw4HutU3TF4SWN+49XOrjlg==; 24:qJZCvpYdJsRxksoCv8yRHp28boOqAztniAPlKDvIxwA+rqfbIDI+JSU8vo2hDUagQ9aO4Vtq3mSW0NO5gdMjnECvzhdO+Ah3kx46wUbIlYU= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Mar 2016 01:51:18.4978 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0915 Archived-At: Cc: "Heather Flanagan \(RFC Series Editor\)" , IESG IESG Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 01:51:25 -0000 > On 3/27/16, 01:42, "rtcweb on behalf of Harald Alvestrand" wrote: > >> Den 23. mars 2016 10:09, skrev Drage, Keith (Nokia - GB): >>> Assuming it does not contain normative language in its own right, then >>> it might well be a BCP, but then it needs to tighten up on some of its >>> internal language – if we don’t mean RFC 2119 language then we should >>> try and avoid the lower case forms as well, in order to avoid confusion. >> >> Matter of principle: >> >> I've argued against this idea for the last 10 years .... avoiding common >> verbs makes it harder to write English. Enough people have a hard time >> with that already that we shouldn't make it harder. >> >> If we mean something by the UPPERCASE form, we should stop trying to >> police the lowercase ones. Indeed, the policing of the lowercase forms >> serves to increase confusion between the forms, not decrease it: "if >> this lowercase should is still there, does it mean that it wasn't >> policed out, or that it was intended to be uppercase?" If I'd have to decide, I'd lean to the other side, because while for some people, the difference between upper and lower case is very strong, for others, it's not perceived that strongly. Examples may include people who's native script doesn't make such a distinction, and those people for whom software makers create OSes which treat upper and lower case as (mostly) equivalent, or default to case-insensitive for search and similar stuff. In addition to that, there's the issue of getting it right, which is more difficult if the difference is only one of case, and the issue that styling may change case. Also, for those who have difficulties finding additional words, there's https://tools.ietf.org/html/draft-hansen-nonkeywords-non2119. On the other hand, for those really addicted to case differences, there was also an RFC that defined keywords such as MUst and mUsT. You can guess the date of that one. As Harald says, this issue has come up many times over the past 10 (or more) years, in many different places. It would be good if the relevant entity (I have copied the IESG and the RFC Editor, but somebody else may be in charge here) would just decide. That way, WGs wouldn't have to spend time on this. And readers (who may not check the start of a document every time they check some detail), when they see a "must", won't have to worry whether it's a "MUST" erroneously spelled lower case, or just the equivalent of "need" or so. Regards, Martin. From nobody Mon Mar 28 03:47:43 2016 Return-Path: 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 BFF6912D83C; Mon, 28 Mar 2016 03:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 wepk9hg7flBA; Mon, 28 Mar 2016 03:47:40 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 148A812D14E; Mon, 28 Mar 2016 03:47:40 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 626F7C94BD; Mon, 28 Mar 2016 06:47:31 -0400 (EDT) Date: Mon, 28 Mar 2016 06:47:31 -0400 From: John Leslie To: =?us-ascii?B?PT9VVEYtOD9RP01hcnRpbl9KLg==?= _D=c3=bcrst?= Message-ID: <20160328104731.GO88304@verdi> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56F88E18.2060506@it.aoyama.ac.jp> User-Agent: Mutt/1.4.1i Archived-At: Cc: "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IESG IESG Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 10:47:41 -0000 On the issue of lower-case "must", etc., =?UTF-8?Q?Martin_J. _D=c3=bcrst?= wrote: > >... It would be good if the relevant entity (I have copied the IESG > and the RFC Editor, but somebody else may be in charge here) (indeed, the IESG may or may not be in charge here; but this is a definite mine-field as we try to escape the ASCII straitjacket when preparing RFCs) > would just decide. That way, WGs wouldn't have to spend time on this. I truly wish WGs WOULD avoid spending time on this!!! > And readers (who may not check the start of a document every time they > check some detail), Alas, that is being too careless: RFC 2119 simply _doesn't_ apply unless its warning-sentence is inculded. > when they see a "must", won't have to worry whether it's a "MUST" > erroneously spelled lower case, There is _no_ error there: just an ambiguity! > or just the equivalent of "need" or so. IMHO, the intent (when 2119 was written), was to define new words using ASCII uppercase, not to redefine English words. As evidence, I cite the three uses of lowercase "must", four uses of lowercase "should", and five uses of lowercase "may", which are a true challenge to interpret as 2119 keywords. But I specifically disclaim that my _opinion_ has any value! Please do remember that when RFC2119 was written, there was no question that RFCs were written in English, using ASCII (where uppercase is a different code from lowercase). (I've always thought that draft-hansen-nonkeywords would be good an an April-first RFC, myself... ;^) -- John Leslie From nobody Mon Mar 28 05:03:37 2016 Return-Path: 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 797DF12D158; Mon, 28 Mar 2016 05:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAD_ENC_HEADER=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 PcLOTc4OKplx; Mon, 28 Mar 2016 05:03:31 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 985BE12D174; Mon, 28 Mar 2016 05:03:30 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id x64so66748689qkd.1; Mon, 28 Mar 2016 05:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=RncFKk7CQ/EpOwgTwc4WORKD34c6LW52XGGqti7Dbzg=; b=AaUX0I+0fQUIktt+uqRs8IhZ0G4V+69jaHZA5QyF6XCTPsH7FEgR/U/acn1dTGrkGP poog2CcMaV1J6nzCtrEYvRVSP/CCnX8LliCB9AW8k4FLWrXkck+OpjXL6k4TfSP0lYsh iM5IqurUW4yysKyn9dEpo/oNoClxDPPCKRcWo2USlv2b9kzdY0Kab+BFBTIbvAwKUIme +vvop9nub6ZFaDK5PY3k5xa7G8aq58zwErxVW6gPDOg4FeiySjZFgN0nv6glsrz1k9n7 1wgxRSuribsI9ZLfb5jHnWf/mvTgZulxJ158dZ7bYB8HPMxoPE4ydwVMf7QbAkD1yZn9 TcIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=RncFKk7CQ/EpOwgTwc4WORKD34c6LW52XGGqti7Dbzg=; b=l4s9EPejyJ1O2CQG2uO2jxq/Ng4USwd84dcrSzooHuBdNp997TKfKSwvCFXhI6DjPk oRQZgcdVy8HMsv4YLPpIG+VWHdtGchZaPl/16cZcb7E7svQVUz1+Q/mPHLBdhsj+n59F FdgfbFVlKHQ87vCxBKsWUVGEKMqyFOmevp9tJzoG6ZvaefT5CRMsB84bw0isfzRwdhuR 6IRzJlXRB2NU7ZbgWyeUNNLAXST1ugfjfgAqR0RsX7roM+tad07yn83ncLApKKVNuz9C N3UC0WmzbM2sVJXhOuO6/n8UzKGuUv3shHH5skZVm7qV/u+6mjlzOY4vBieqkF39Snjx RdhQ== X-Gm-Message-State: AD7BkJK/xRfKLnMN1valzEMainrOr7NDHt6RbhyCjUfWwK45g5H804b8cmSQ6WKCqm7R8VXuh3rnbLfMpy+96g== MIME-Version: 1.0 X-Received: by 10.129.103.133 with SMTP id b127mr13514580ywc.127.1459166609677; Mon, 28 Mar 2016 05:03:29 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.83.28.67 with HTTP; Mon, 28 Mar 2016 05:03:29 -0700 (PDT) In-Reply-To: <20160328104731.GO88304@verdi> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> Date: Mon, 28 Mar 2016 08:03:29 -0400 X-Google-Sender-Auth: ZJ7TwtqzpAjRAr8N5Jmy__AkW_c Message-ID: From: Barry Leiba To: John Leslie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IESG IESG Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 12:03:33 -0000 Martin says: > If I'd have to decide, I'd lean to the other side, because while for some > people, the difference between upper and lower case is very strong, for > others, it's not perceived that strongly. Examples may include people who's > native script doesn't make such a distinction This has been brought up before. I know Martin lives in such a country, so perhaps he has different data, but I have checked with my own Chinese colleagues, and they confirm that they *do* understand, notice, and pay attention to the difference in case when they're reading the documents. (It's entirely possible that they're more prone to making case errors when they're writing, but that speaks to the "getting it right" part, which I always consider a problem -- there are a great many wrong uses of 2119 key words that show up often, and some of those are, no doubt, due to authors writing "should" or "may" or "must" and thinking they ought to put that in upper case.) John comments: >>... It would be good if the relevant entity (I have copied the IESG >> and the RFC Editor, but somebody else may be in charge here) > > (indeed, the IESG may or may not be in charge here; but this is a > definite mine-field as we try to escape the ASCII straitjacket when > preparing RFCs) I believe the IESG is *not* in charge here, other than to have different ADs pick at different things in our reviews. I believe the community is in charge. The key point is the second sentence of the Abstract from RFC 2119: In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. The problem here is that it's explanatory, not normative. The explanation -- and the usage custom -- leads many of us to think we can use capitalization to make the distinction, while the fact that its not normative leads many of us to think that "should" means "SHOULD". My suggestion is to write a tiny draft (I'm willing to be the editor of that) that updates 2119, which makes one of the following changes: NEW -- alternative 1 In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized, as shown below, but they have special, requirements meanings regardless of capitalization. NEW -- alternative 2 In many standards track documents several words are used to signify the requirements in the specification. These words have special, requirements meanings only when they appear in ALL CAPITALS, as shown below. The hard bit, of course, will be to determine which of those alternatives the community has rough consensus on. Perhaps I will post an I-D when the pre-meeting fog lifts, and we can bash it out on the IETF discussion list. Barry From nobody Mon Mar 28 06:29:16 2016 Return-Path: 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 3944C12D93F; Mon, 28 Mar 2016 06:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 ZuF472Uo_VKz; Mon, 28 Mar 2016 06:29:08 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id AD09712D933; Mon, 28 Mar 2016 06:29:07 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 222A3C94BD; Mon, 28 Mar 2016 09:28:59 -0400 (EDT) Date: Mon, 28 Mar 2016 09:28:59 -0400 From: John Leslie To: Barry Leiba Message-ID: <20160328132859.GP88304@verdi> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: Cc: "Heather Flanagan \(RFC Series Editor\)" , rtcweb@ietf.org, ietf@ietf.org, iesg@ietf.org Subject: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: ietf@ietf.org List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 13:29:10 -0000 NB this IMHO belongs on , and I'm directing Reply-To there Barry Leiba wrote: > Martin says: > >>... while for some people, the difference between upper and lower case >> is very strong, for others, it's not perceived that strongly. Examples >> may include people whose native script doesn't make such a distinction > > This has been brought up before. I know Martin lives in such a > country, so perhaps he has different data, but I have checked with my > own Chinese colleagues, and they confirm that they *do* understand, > notice, and pay attention to the difference in case when they're > reading the documents. (It's entirely possible that they're more > prone to making case errors when they're writing, but that speaks to > the "getting it right" part, which I always consider a problem -- > there are a great many wrong uses of 2119 key words that show up > often, and some of those are, no doubt, due to authors writing > "should" or "may" or "must" and thinking they ought to put that in > upper case.) > > John comments: > >>>... It would be good if the relevant entity (I have copied the IESG >>> and the RFC Editor, but somebody else may be in charge here) >> >> (indeed, the IESG may or may not be in charge here; but this is a >> definite mine-field as we try to escape the ASCII straitjacket when >> preparing RFCs) > > I believe the IESG is *not* in charge here, other than to have > different ADs pick at different things in our reviews. I believe the > community is in charge. I agree with Barry: the community should be in charge. > The key point is the second sentence of the Abstract from RFC 2119: > > In many standards track documents several words are used to signify > the requirements in the specification. These words are often > capitalized. Please note that an Abstract is never supposed to override the document itself. (But I agree this is the source of the issue.) > The problem here is that it's explanatory, not normative. The > explanation -- and the usage custom -- leads many of us to think we > can use capitalization to make the distinction, while the fact that > its not normative leads many of us to think that "should" means > "SHOULD". I think Barry has it right; but I hope our readers don't confuse the Abstract with the explanation in the body of the document. > My suggestion is to write a tiny draft (I'm willing to be the editor > of that) that updates 2119, which makes one of the following changes: > > NEW -- alternative 1 > In many standards track documents several words are used to signify > the requirements in the specification. These words are often > capitalized, as shown below, but they have special, requirements > meanings regardless of capitalization. > > NEW -- alternative 2 > In many standards track documents several words are used to signify > the requirements in the specification. These words have special, > requirements meanings only when they appear in ALL CAPITALS, > as shown below. Needless to say, I prefer alternative 2... > The hard bit, of course, will be to determine which of those > alternatives the community has rough consensus on. And for that determination, the IESG _is_ in charge. > Perhaps I will post an I-D when the pre-meeting fog lifts, and we can > bash it out on the IETF discussion list. Actually, I suggest on-list discussion before that, and Barry posting _after_ the plenary, when he has left the IESG (and returned to the _actually_ important work of IESG scribing ;^) I know this is a religious-war; and I apologize in advance for not being present in Buenos Aires to receive the in-person flamage. Nonetheless, I restate my opinion: ] IMHO, the intent (when 2119 was written), was to define new words ] using ASCII uppercase, not to redefine English words. As evidence, ] I cite the three uses of lowercase "must", four uses of lowercase ] "should", and five uses of lowercase "may", which are a true challenge ] to interpret as 2119 keywords. And I beg folks to respect the convention that an Abstract must not _change_ the meaning of a document. (I'll wait for later to argue why I believe alternative 2 is a better way to run a railroad...) -- John Leslie From nobody Mon Mar 28 07:10:59 2016 Return-Path: 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 BEA3B12D9A1; Mon, 28 Mar 2016 07:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ypjeybcTN3sB; Mon, 28 Mar 2016 07:10:52 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0742112D9AE; Mon, 28 Mar 2016 07:09:53 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id x64so71752817qkd.1; Mon, 28 Mar 2016 07:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=imrsYo2RnMVUEwykjyuR9pfJLMSj21pJWtRlkoho9WA=; b=iIMuwmPG9TXSqR3LGrvZi22l8wUueSYGXPxe1V2DRkGXTl+2pPl91Zqb/rWzb4yeyd S8tGrQLAM5RQk06fOMd4id8H95bqKnnqngPSs2KjGY4Y8c4GULhoHUS6NsNUqMy8CR9L sNjAHLmF/3R06Se/2Q5TWaqRNKvdNMVmSiV9wZfOtEaU+QjUL3DZ3BPz2YG+Gpo31t0h HC8AoCaAGa++QbPAvHV/KdfZbAvWdY8CeTSfQ0cqIwAisCZkHAkri8nfzKvcNHMWyuXw jS1nJShdFR9Wsy/jqWDspOTT6vyfRZIVfiRQ9AO91XkbnRkoss2CcjNykzAKzhj+JC7c 4NKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=imrsYo2RnMVUEwykjyuR9pfJLMSj21pJWtRlkoho9WA=; b=Ozj8HnlWNRqYx18l+fBPjIVSFTEXhK9aXj2Ei9x9JVEQZRSkzdwA9qtbSqbtM7rUC9 tZS8ZgJbtMUry5bPDE6+6TL+hMTKTFl8v41Ou+QLwIFnHn/nSjDskNJcQ5x+MDQVSs22 r8IRD6klZjZp8G9hrk+r/nwSJt10J/9gsVgxB3xNeyfd8jBWC73qRdAjs4QmIgwvinOV 6+TDnTTO78qevAUYdevzG8j7OMgwTMgf8uA07r0hnr82qWL+oogbx2OxNclcdBtkfCG8 Dm9P5i9B0X4yjBpNVp7RwgbJwTQtTsW+XoJx++v8qhM4A0++M0NSes9hhhLXHx+lvnos +wgQ== X-Gm-Message-State: AD7BkJJ1WzKliO2RPlHsOgYlkkn4JVi52XqITtrU/QrSZb6mYP2MvNiuOt7x1Wm7FTttc3fwJfDlCawVgXij7A== MIME-Version: 1.0 X-Received: by 10.37.50.210 with SMTP id y201mr13428902yby.10.1459174191972; Mon, 28 Mar 2016 07:09:51 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.83.28.67 with HTTP; Mon, 28 Mar 2016 07:09:51 -0700 (PDT) In-Reply-To: <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> Date: Mon, 28 Mar 2016 10:09:51 -0400 X-Google-Sender-Auth: TFOkGJJF42EmBVzRPLCQCT4WCpI Message-ID: From: Barry Leiba To: "Scott O. Bradner" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IETF discussion list , IESG Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 14:10:54 -0000 > The wishy washy descriptive rather than proscriptive language in the abst= ract was because I, > the IESG and the community were not of one mind to say that the use of su= ch capitalized > terms should be mandatory - quite a few people felt that the english lang= uage was at > least good enough to convey the writer=E2=80=99s intent without having t= o aggrandize specific words. > Thus the abstract basically was saying: if you want to use capitalized wo= rds here is a standard > way to say what they mean Ah. Then perhaps the clarification needs to go a little further and make this clear: - We're defining specific terms that specifications can use. - These terms are always capitalized when these definitions are used. - You don't have to use them. If you do, they're capitalized and their meanings are as specified here. - There are similar-looking English words that are not capitalized, and they have their normal English meanings; this document has nothing to do with them. ...and I'd like to add one more, because so many people think that text isn't normative unless it has 2119 key words in all caps in it: - Normative text doesn't require the use of these key words. They're used for clarity and consistency when you want that, but lots of normative text doesn't need to use them, and doesn't use them. Barry From nobody Mon Mar 28 12:10:00 2016 Return-Path: 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 C465412DBBC; Mon, 28 Mar 2016 12:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qwwdd6PBDIQY; Mon, 28 Mar 2016 12:09:55 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A557D12D8E8; Mon, 28 Mar 2016 12:09:54 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id i4so86294142qkc.3; Mon, 28 Mar 2016 12:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=l5SgB7bTV5Z6FGV2ZPU+jB5kA6xWZMS7eRJVTJnMD9M=; b=xkuYyeC9qLMRst0JMaEesChXEg+T9GNzbcL0+/X8+JTaxLoaUlKN+/lTkE9/EnraNI /Sxrow0tfkyCPoKIY9ZVrjhZ5p3zj7xjwR5Zr3q3n2rsTBUO3bf32Pcray+g7feiJvo4 4QJ45kQnret82UZrl+aaY0BGkdcyaK9FdXj3B2CFDQPdKq87pZrpUmU4OJU0Ku/9w6V3 +/mZrdnOUrzVyNERv4kIh8D0r1/jSDJ3m9epZlV3s19swAItESUmnTTFYaEbJ3ZVwid4 I0jH0ESgu/Zh8CWNL/TXIq9Pk7Q0x99dQBqxLJMsyJYq96+Mc6EOwh+URyzJtfKrx8wM 9W1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=l5SgB7bTV5Z6FGV2ZPU+jB5kA6xWZMS7eRJVTJnMD9M=; b=chMX4qihH2JdKtd3tjXWOwjLpYSbFNQILcnMVEr7nzh81FHuMuvuOkoIkmeiKKFpPh Fq/CH2GPkI2uR8AcYWjg3MIaRpR+qPJt23o4QOpLt13dfLDVPYfUSKlQQTbzlB+NoCCi /Yb1VJdJa+MQQX+CY4n63o/tr69fW9ZhWIYMLQEl5G90DMfb+gbESAVgDeXbXuK8SLWA qJcaOZiRDx1cdIJq1kGe6rNeKWRQW/yeceGBn1hqQF2/Yjq+QXdWQZwcIC3spj18jZ1k gH2mDh5otm/d3mJGbq797NXbj/jkmR/tthDvpha5kLwwe/+lyOebwPlfRg5uMUyB2jYW SMYQ== X-Gm-Message-State: AD7BkJIyMlvMiP3s3xMNDPQdbKWvrWTRyqAlNiheemGlwnNd/71LRd2hw9gP7BIdEWRkV4nh/XqBRGeAWY9OpA== MIME-Version: 1.0 X-Received: by 10.37.18.198 with SMTP id 189mr11630305ybs.102.1459192193728; Mon, 28 Mar 2016 12:09:53 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.83.28.67 with HTTP; Mon, 28 Mar 2016 12:09:53 -0700 (PDT) In-Reply-To: <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> Date: Mon, 28 Mar 2016 15:09:53 -0400 X-Google-Sender-Auth: OeHWXHxYoU3SmMqXZHVYM71ZJJQ Message-ID: From: Barry Leiba To: "Scott O. Bradner" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IETF discussion list , IESG Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 19:09:57 -0000 > one minor tweak A fine tweak. I'll write it up and pass it to a few people before I post the I-D. I'd rather do it as an update to 2119, rather than a complete revision, even though 2119 is so short, for two reasons: 1. I don't want to get into arguments about other changes. 2. I don't want to make 2119 obsolete: there's value in continuing to refer to it with that RFC number. Barry >> On Mar 28, 2016, at 10:09 AM, Barry Leiba wrot= e: >> >>> The wishy washy descriptive rather than proscriptive language in the ab= stract was because I, >>> the IESG and the community were not of one mind to say that the use of = such capitalized >>> terms should be mandatory - quite a few people felt that the english la= nguage was at >>> least good enough to convey the writer=E2=80=99s intent without having= to aggrandize specific words. >>> Thus the abstract basically was saying: if you want to use capitalized = words here is a standard >>> way to say what they mean >> >> Ah. Then perhaps the clarification needs to go a little further and >> make this clear: >> - We're defining specific terms that specifications can use. >> - These terms are always capitalized when these definitions are used. > > these definitions are only meaningful if the words are capitalized > >> - You don't have to use them. If you do, they're capitalized and >> their meanings are as specified here. >> - There are similar-looking English words that are not capitalized, >> and they have their normal English meanings; this document has nothing >> to do with them. >> >> ...and I'd like to add one more, because so many people think that >> text isn't normative unless it has 2119 key words in all caps in it: >> >> - Normative text doesn't require the use of these key words. They're >> used for clarity and consistency when you want that, but lots of >> normative text doesn't need to use them, and doesn't use them. >> >> Barry > From nobody Mon Mar 28 13:30:47 2016 Return-Path: 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 CEE1812D526; Mon, 28 Mar 2016 13:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 30uQPKQhguEZ; Mon, 28 Mar 2016 13:30:37 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53A0C12D538; Mon, 28 Mar 2016 13:30:37 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id i4so89635850qkc.3; Mon, 28 Mar 2016 13:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=8DzbuAPLRwbfcVHLJ1XCNK4FwQdLyvjZw8cK8S5Kf8A=; b=TZCMd90+7J/3oSG1Iivdno+5axZRsPX6u8ZwCmA/xzT3CFU8M7IxQM9paxKueQyO5V dhQw9U72MY3tkvG57NQudfYc6JY726lJGPsHuX7kUGRBpyhxiD32nH16ma+korwzxuxQ 7FKuGBQeJnD2nLM3pLwMP7sbH2sC2uUdZN7U1BxmzeWtBYt78qpsn8UrZh2eGBQskuNq O5dL95Yhc59xtOkaWaUCvjHcnehownYDW+I9zHyAuSDJLHvfFeZnY1BFCNZisA3bH9T0 5nOWpt171rYOqufPnW9kbSblxsiT+mnrIsZYuqujhRVmPwVMXC70cUJdYRLQOqNcsDMf cxUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=8DzbuAPLRwbfcVHLJ1XCNK4FwQdLyvjZw8cK8S5Kf8A=; b=kt2SXTbL86RAnMTDuwNefmF43vZj3NOGS5gDS1BS4sC4pBaJip9B4DKd7GrVETkvsk Wq2bJDFqhF3I2E22WQ5m1yJhVTwtVE3gaYujH0lu3ESbOcz6f+UZuRVsRJX/LDZt/xcz XzCeEF2uihtxXg7VJdQ4jK0vInRWkqMm2hQF9bqQ7Me7WEjOlolTyJTBrPU/twhLfwaY tjuCx8WPMnO7j5jxhYSisQyvu2KhKCDRmQF7EaSJCpWp6iUB7LHEnpq8QRptUM1TYlTm s+ucPZNicjiImdIT43jigvlyXKHn0e8UdMUfdkFW1F1Y60phUstusS8eXGI+yNWTD5kc YWMA== X-Gm-Message-State: AD7BkJJJ2Vo3THf/fi+9jbH2XLUIaWvOZWfK4xkBpYhD/0RAh8Zk+Xo2ItS8VzM+ZbfaG+T36vxp1A6flQQhTw== MIME-Version: 1.0 X-Received: by 10.37.230.67 with SMTP id d64mr8926543ybh.159.1459197036324; Mon, 28 Mar 2016 13:30:36 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.83.28.67 with HTTP; Mon, 28 Mar 2016 13:30:36 -0700 (PDT) In-Reply-To: <56F98CD1.10706@gmail.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> Date: Mon, 28 Mar 2016 16:30:36 -0400 X-Google-Sender-Auth: Ml2IqVgirJknZRCDgaQNt_uXLOU Message-ID: From: Barry Leiba To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IETF discussion list , "Scott O. Bradner" , IESG Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 20:30:42 -0000 Brian, I think your note goes to how important it is to write clearly and to get a lot of eyes on it before we publish it. Well-written documents, with or without 2119 key words, and with or without lower-case look-alikes, can still be clear. Fuzzily written documents will be fuzzy. In particular: > they mean? It can be very unclear. If a node receives a message containin= g > an element covered in the spec by "allowed" instead of "OPTIONAL", is the > receiver supposed to interoperate or to reject the message? Well, this is where 2119 advises that we *use* the key words when interoperability is at stake. It's fine to be fuzzy when it doesn't matter, though even then, I'd argue for more explanation: Every frobotz MUST contain a valid bleeg. The glorp field in the frobotz is an unsigned integer that is normally between 0 and 666, inclusive. Values greater than 666 are allowed, but recipients using older software might not be able to handle such values. ... When processing a frobotz that does not meet the requirements in section 3.1.4, it is permissible to reject the frobotz outright, or to attempt to process the parts of it that make sense; the choice is an implementation decision. However, any frobotz that does not contain a valid bleeg MUST be rejected. That sort of thing. Barry On Mon, Mar 28, 2016 at 3:58 PM, Brian E Carpenter wrote: > There are times when I think RFC2119 was a really bad idea, despite it ha= ving > become probably the most frequently cited RFC (inside and outside the IET= F). > It seems to create as much confusion as it avoids. > > There are four words whose RFC2119 meaning is different from the dictiona= ry > meaning: should, recommended, may and optional. Having special typography > for them is useful, because it signals the RFC2119 meanings. But if a spe= c > uses, for example, a mixture of SHOULD and should, who knows what the aut= hors > intended? To that extent, the proposed clarification is helpful. > > The other words (must, shall, required, not) mean what they always mean. > The only argument for upper-casing them is aesthetic symmetry. If a spec > uses alternatives like mandatory, necessary or forbidden, they are just a= s > powerful. > > So >> these definitions are only meaningful if the words are capitalized > can be applied to should, recommended, may and optional if we want, > but strictly doesn't apply to must, shall, required, not, mandatory, > necessary, forbidden, need, or any other such words. > > Where we can get into real trouble is if a spec contains should, recommen= ded, > may and optional *plus* other non-categorical (fuzzy) words like ought, > encourage, suggest, can, might, allowed, permit (and I did not pull those > words out of the air, but out of draft-hansen-nonkeywords-non2119). What = do > they mean? It can be very unclear. If a node receives a message containin= g > an element covered in the spec by "allowed" instead of "OPTIONAL", is the > receiver supposed to interoperate or to reject the message? > > If we are issuing guidance, it should probably include a specific warning > to use any such fuzzy words with extreme care. > > Brian > On 29/03/2016 03:13, Scott O. Bradner wrote: >> one minor tweak >> >>> On Mar 28, 2016, at 10:09 AM, Barry Leiba wro= te: >>> >>>> The wishy washy descriptive rather than proscriptive language in the a= bstract was because I, >>>> the IESG and the community were not of one mind to say that the use of= such capitalized >>>> terms should be mandatory - quite a few people felt that the english l= anguage was at >>>> least good enough to convey the writer=E2=80=99s intent without havin= g to aggrandize specific words. >>>> Thus the abstract basically was saying: if you want to use capitalized= words here is a standard >>>> way to say what they mean >>> >>> Ah. Then perhaps the clarification needs to go a little further and >>> make this clear: >>> - We're defining specific terms that specifications can use. >>> - These terms are always capitalized when these definitions are used. >> >> these definitions are only meaningful if the words are capitalized >> >>> - You don't have to use them. If you do, they're capitalized and >>> their meanings are as specified here. >>> - There are similar-looking English words that are not capitalized, >>> and they have their normal English meanings; this document has nothing >>> to do with them. >>> >>> ...and I'd like to add one more, because so many people think that >>> text isn't normative unless it has 2119 key words in all caps in it: >>> >>> - Normative text doesn't require the use of these key words. They're >>> used for clarity and consistency when you want that, but lots of >>> normative text doesn't need to use them, and doesn't use them. >>> >>> Barry >> >> > From nobody Mon Mar 28 14:26:18 2016 Return-Path: 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 3B67712D0C1 for ; Mon, 28 Mar 2016 14:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.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 w8boSmg7j6Ew for ; Mon, 28 Mar 2016 14:26:14 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85D6612D97B for ; Mon, 28 Mar 2016 14:26:08 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id i4so91752720qkc.3 for ; Mon, 28 Mar 2016 14:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=VqtrDDYvd2NTuFxeF2LP+I9B7CNzo2Iqekta15bZKlQ=; b=WT41laBGlyNFsbhCvG9kEpXg0o0oTd8+ZrRNLuxK0SOVZmtV23CsvLiy12qMpZq9s7 CgL5vJ3abWZ0iNiPKk9PbV3Ojz2kRsVH1rGwnZEcdL9chA/DkzvbJvSY6Wm7YibNLv3y g3zO37OvM5cdFkLo4N8BJ+eHu9S9CtqGJgBqnUJXxmg+10meiztORWw86ZIUnXY93Gnb 2Eln1tOpUbaXjdQIEftaxJj/UjVac4dXbE/JzW5vRpr6ivvRVTMJ0MBdM9BcS0/Z1ZFg Jg7RXiQG5SNV/adHj+FNixil867RchdAFoTHWNIvOW0TwvMf8sNtvLl6d/5gGYe3j4y1 FJdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=VqtrDDYvd2NTuFxeF2LP+I9B7CNzo2Iqekta15bZKlQ=; b=EJhydLmIwQ5BsohUFbLntWejBBrD48DJ4ZefVB4BmsJm8Tt32o+n2BnJk9O+e7WN3z 75aNX5AgqHI489KIFA6LkhK1fwBZp6eo5Ak7rWxarrUQFxfzX+Znq6zUEKLcONkSvQU7 +ixP532gORF8MQojdFECvmeX2mSaC04tMo02ZMhPMbo9uK9SWw2HLQ70GbB9s0cmMh/7 /vLgauXsU12DKjm5NAQzS8ew8PpLkFe3Ef+ymwUbQjHWjgw+HtYjZwYbdisgJHocX3GZ vD2lQzm71qCLahHvzQTtI/AB+2iO3VtCdrvN57NrdpEsze5S2hZjp4N48bbYfFRu6Sau IVSQ== X-Gm-Message-State: AD7BkJIV/SoDebSFnOJotKFp+9ITqymIVV697Um00T4iHgIpBQBlq+od8/+g/2SCKB9K3Ede8GhClMdfAiMUtQ== X-Received: by 10.37.92.215 with SMTP id q206mr14407527ybb.172.1459200367566; Mon, 28 Mar 2016 14:26:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.201.132 with HTTP; Mon, 28 Mar 2016 14:25:48 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 28 Mar 2016 23:25:48 +0200 Message-ID: To: "rtcweb@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [rtcweb] Adding previously "discarded" codecs in SDP renegotiation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 21:26:17 -0000 Hi, the scenario is the following: - Alice sends SDP offer to Bob by offering VP8 (PT 100) and H264 packetization-mode=3D1 (PT 101). - Bob answers with just VP8 (let's say it sets PT 110) in the m=3D line, regardless he also supports H264. At this time Alice must send VP8 (PT 110) to Bob, and Bob must send VP8 (PT 100) to Alice. Fine. Later Bob wants to change to H264, so he sends a SDP reoffer to Alice by just offering H264 packetization-mode=3D1 (PT 111). Assuming this is valid (re-enabling a previously discarded codec), Alice answers the reoffer with just H264 (PT 101). Is this valid? And a more pragmatic questions: should I assume that current WebRTC implementations would support this scenario? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From nobody Mon Mar 28 16:13:06 2016 Return-Path: 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 71CF312D16A for ; Mon, 28 Mar 2016 16:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 j0DCbL3mMQ4z for ; Mon, 28 Mar 2016 16:13:02 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD5012D0E5 for ; Mon, 28 Mar 2016 16:13:01 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id h129so101607692ywb.1 for ; Mon, 28 Mar 2016 16:13:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=+Aexe4r8YBJ+qnBrDUGqcXIzAxVlEMOaW1lYcGj0LAw=; b=h3XRYoP3VexD2kRl5M+o7ozxCT2uBsnVeRbQnulK5Tj/SA38q8GEXSmhBWehoANjiv A9S2d56A5nplNgRufnrRsCmpfvfxZmnTcZ1XQfFxMpyhzz7+a+7EZw5XeI/GV7jdKyJ2 lvbcT9yqMmOMMjaM21ysXii/7hx7lgjBQk+iPXgaSGPudw8W6LiqmKuHgK6eNUFKjevK FyfuoF5GbcJCrhUV69wN57ukHJbPNle42UBKe01heH1bjFwX7xoMdtZEv9VkDBFCNsPK wbM8m1vFgEtt7KE0zn6rYwDE8Cyv4vWf0tI7+ZLDVjd+KRO/wxuqhFrN364ebrfeqlWo SdPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+Aexe4r8YBJ+qnBrDUGqcXIzAxVlEMOaW1lYcGj0LAw=; b=Lp48XHwj4rAfjLQo9rvXwH4atZBB3mJr6Nbsfn7qR1O/bDCMuiH8hGRJ24JiC+J1VO PSGfkCWdNAAKQHOTZXGwzGWNvhdwPhBSqzae5e9THi52tsls7hg8h3Zkwq9mrYHI4nYi 7Uv/bO4buFAU6Q85ez1Q5oH8pGy12ultm492X7xPjg2I8w/9dxXdV2WQFdvYjoqyfqSB jEVWp9qdpyAtWqf7TVsdKtrzIAiHdSzOxSgUmeu1q9RUrkjXciCd6f269zP2tX5F8bxG FDJouKpacI6Ftz5mg5GSPGQzi/R4zQw0I2i25rdxwektCUrBIf6eZx+a1j64ZIyG3kp+ tNoQ== X-Gm-Message-State: AD7BkJK9YO6GaLSQQ8ZE9fXbB8X0IzWNvxnLOYN8Ld9JEhrRFXFaJzrFWZVoMs5ZCR+rPZLbDKu2UlIWs6CClpcW MIME-Version: 1.0 X-Received: by 10.129.35.6 with SMTP id j6mr14714308ywj.133.1459206780877; Mon, 28 Mar 2016 16:13:00 -0700 (PDT) Received: by 10.129.42.196 with HTTP; Mon, 28 Mar 2016 16:13:00 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Mar 2016 16:13:00 -0700 Message-ID: From: Taylor Brandstetter To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001a11429e68d468ac052f240d62 Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Adding previously "discarded" codecs in SDP renegotiation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 23:13:04 -0000 --001a11429e68d468ac052f240d62 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This seems like a bit of a gray area. JSEP says that for subsequent offers: o The m=3D line and corresponding "a=3Drtpmap" and "a=3Dfmtp" lines MUS= T > only include codecs present in the remote description. In this situation, the remote description *does* still contain H.264, so it seems it would technically be valid to offer it. *However*, if Alice were to send a reoffer, she *could not* offer H.264. And then Bob's remote description wouldn't contain H.264, so he couldn't offer it even if he wants to. I'm thinking this may be an oversight in the spec. I created an issue for it: https://github.com/rtcweb-wg/jsep/issues/266 As for current implementations: Chrome will freely let you add previously discarded codecs, and it even creates offers with discarded codecs. Though this is currently considered a bug. I just created an issue to track it: https://bugs.chromium.org/p/webrtc/issues/detail?id=3D5697 On Mon, Mar 28, 2016 at 2:25 PM, I=C3=B1aki Baz Castillo wr= ote: > Hi, the scenario is the following: > > - Alice sends SDP offer to Bob by offering VP8 (PT 100) and H264 > packetization-mode=3D1 (PT 101). > > - Bob answers with just VP8 (let's say it sets PT 110) in the m=3D line, > regardless he also supports H264. > > At this time Alice must send VP8 (PT 110) to Bob, and Bob must send > VP8 (PT 100) to Alice. Fine. > > Later Bob wants to change to H264, so he sends a SDP reoffer to Alice > by just offering H264 packetization-mode=3D1 (PT 111). > > Assuming this is valid (re-enabling a previously discarded codec), > Alice answers the reoffer with just H264 (PT 101). > > > Is this valid? And a more pragmatic questions: should I assume that > current WebRTC implementations would support this scenario? > > Thanks a lot. > > > -- > I=C3=B1aki Baz Castillo > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --001a11429e68d468ac052f240d62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This seems like a bit of a gray area. JSEP says that for s= ubsequent offers:

=C2=A0 =C2=A0o =C2=A0= The m=3D line and corresponding "a=3Drtpmap" and "a=3Dfmtp&q= uot; lines MUST
=C2=A0 =C2=A0 =C2=A0 only include codecs present in the = remote description.

In this situation= , the remote description does still contain H.264, so it seems it wo= uld technically be valid to offer it. However, if Alice were to send= a reoffer, she could not=C2=A0offer H.264. And then Bob's remot= e description wouldn't contain H.264, so he couldn't offer it even = if he wants to.

I'm thinking this may be an ov= ersight in the spec. I created an issue for it:=C2=A0https://github.com/rtcweb-wg/jsep/issues= /266

As for current implementations: Chrome wi= ll freely let you add previously discarded codecs, and it even creates offe= rs with discarded codecs. Though this is currently considered a bug. I just= created an issue to track it:=C2=A0https://bugs.chromium.org/p/webrtc/issues/d= etail?id=3D5697

On Mon, Mar 28, 2016 at 2:25 PM, I=C3=B1aki Baz Castillo <ibc@al= iax.net> wrote:
Hi, the sce= nario is the following:

- Alice sends SDP offer to Bob by offering VP8 (PT 100) and H264
packetization-mode=3D1 (PT 101).

- Bob answers with just VP8 (let's say it sets PT 110) in the m=3D line= ,
regardless he also supports H264.

At this time Alice must send VP8 (PT 110) to Bob, and Bob must send
VP8 (PT 100) to Alice. Fine.

Later Bob wants to change to H264, so he sends a SDP reoffer to Alice
by just offering H264 packetization-mode=3D1 (PT 111).

Assuming this is valid (re-enabling a previously discarded codec),
Alice answers the reoffer with just H264 (PT 101).


Is this valid? And a more pragmatic questions: should I assume that
current WebRTC implementations would support this scenario?

Thanks a lot.


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--001a11429e68d468ac052f240d62-- From nobody Mon Mar 28 17:05:36 2016 Return-Path: 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 EE75412D977; Mon, 28 Mar 2016 06:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 kfvHBN6iFljZ; Mon, 28 Mar 2016 06:58:02 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70AE12D920; Mon, 28 Mar 2016 06:58:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id DB0971A0A099; Mon, 28 Mar 2016 09:57:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAwnhtdSDoQC; Mon, 28 Mar 2016 09:57:58 -0400 (EDT) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id A9DCC1A0A088; Mon, 28 Mar 2016 09:57:58 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Scott O. Bradner" In-Reply-To: <20160328132859.GP88304@verdi> Date: Mon, 28 Mar 2016 09:57:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> To: ietf@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: X-Mailman-Approved-At: Mon, 28 Mar 2016 17:05:34 -0700 Cc: "Heather Flanagan \(RFC Series Editor\)" , Barry Leiba , rtcweb@ietf.org, iesg@ietf.org Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 13:58:06 -0000 > On Mar 28, 2016, at 9:28 AM, John Leslie wrote: >=20 >=20 > Nonetheless, I restate my opinion: >=20 > ] IMHO, the intent (when 2119 was written), was to define new words > ] using ASCII uppercase, not to redefine English words. As evidence, > ] I cite the three uses of lowercase "must", four uses of lowercase > ] "should", and five uses of lowercase "may", which are a true = challenge > ] to interpret as 2119 keywords. well, not quite - it was to make more consistent an existing practice the use of capitalized words in IETF documents predates RFC 2119 by = quite a bit - see, for example, RFC 1023. The use became codified by RFC 1122, where the = definitions in=20 RFC 2119 come from. As an AD I became frustrated by the number of IDs I was reviewing that = used upper case words but did not include any statement of what the reader was to make of the = fact that some words were=20 capitalized. I, and the rest of the IESG at the time, were returning = the IDs requesting that the=20 authors add some explanation. The explanations that were added were , = to say the least,=20 inconsistent. After rather many of these I wrote what became RFC 2119 so = that we would at lets have a consistent explanation of the capitalized words that authors = could use if they wanted to. =20 There was some interaction on the list that resulted in what is now = section 6 of RFC 2119 to provide guidance on when to use the capitalized words The wishy washy descriptive rather than proscriptive language in the = abstract was because I, the IESG and the community were not of one mind to say that the use of = such capitalized terms should be mandatory - quite a few people felt that the english = language was at=20 least good enough to convey the writer=E2=80=99s intent without having = to aggrandize specific words. Thus the abstract basically was saying: if you want to use capitalized = words here is a standard way to say what they mean - as I recall some RFCs even after 2119 was = published included their own definitions for the capitalized terms because the authors = thought they had better definitions. Scott= From nobody Mon Mar 28 17:05:38 2016 Return-Path: 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 B3B5212D9E3; Mon, 28 Mar 2016 07:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 YZRk-sKAep7s; Mon, 28 Mar 2016 07:14:21 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB9D612D9C7; Mon, 28 Mar 2016 07:13:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id E96601A0A6C9; Mon, 28 Mar 2016 10:13:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlWCj-3KwaJX; Mon, 28 Mar 2016 10:13:10 -0400 (EDT) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id EA6021A0A6B7; Mon, 28 Mar 2016 10:13:10 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Scott O. Bradner" In-Reply-To: Date: Mon, 28 Mar 2016 10:13:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> To: Barry Leiba X-Mailer: Apple Mail (2.3124) Archived-At: X-Mailman-Approved-At: Mon, 28 Mar 2016 17:05:34 -0700 Cc: "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IETF discussion list , IESG Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 14:14:22 -0000 one minor tweak > On Mar 28, 2016, at 10:09 AM, Barry Leiba = wrote: >=20 >> The wishy washy descriptive rather than proscriptive language in the = abstract was because I, >> the IESG and the community were not of one mind to say that the use = of such capitalized >> terms should be mandatory - quite a few people felt that the english = language was at >> least good enough to convey the writer=E2=80=99s intent without = having to aggrandize specific words. >> Thus the abstract basically was saying: if you want to use = capitalized words here is a standard >> way to say what they mean >=20 > Ah. Then perhaps the clarification needs to go a little further and > make this clear: > - We're defining specific terms that specifications can use. > - These terms are always capitalized when these definitions are used. these definitions are only meaningful if the words are capitalized > - You don't have to use them. If you do, they're capitalized and > their meanings are as specified here. > - There are similar-looking English words that are not capitalized, > and they have their normal English meanings; this document has nothing > to do with them. >=20 > ...and I'd like to add one more, because so many people think that > text isn't normative unless it has 2119 key words in all caps in it: >=20 > - Normative text doesn't require the use of these key words. They're > used for clarity and consistency when you want that, but lots of > normative text doesn't need to use them, and doesn't use them. >=20 > Barry From nobody Mon Mar 28 17:05:40 2016 Return-Path: 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 66EE812D1D3; Mon, 28 Mar 2016 11:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 v_T_T6j5VVSt; Mon, 28 Mar 2016 11:23:50 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A798012D4FE; Mon, 28 Mar 2016 11:23:50 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1akbpH-000GH8-8o; Mon, 28 Mar 2016 14:23:43 -0400 Date: Mon, 28 Mar 2016 14:23:38 -0400 From: John C Klensin To: Barry Leiba , "Scott O. Bradner" Message-ID: <4D8EE9FD4F1B5C0FC90322DE@JcK-HP8200.jck.com> In-Reply-To: References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: X-Mailman-Approved-At: Mon, 28 Mar 2016 17:05:34 -0700 Cc: "Heather Flanagan \(RFC Series Editor\)" , rtcweb@ietf.org, IETF discussion list , IESG Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 18:23:52 -0000 Yes. +1. About time and long overdue. john --On Monday, March 28, 2016 10:09 -0400 Barry Leiba wrote: > Ah. Then perhaps the clarification needs to go a little > further and make this clear: > - We're defining specific terms that specifications can use. > - These terms are always capitalized when these definitions > are used. - You don't have to use them. If you do, they're > capitalized and their meanings are as specified here. > - There are similar-looking English words that are not > capitalized, and they have their normal English meanings; this > document has nothing to do with them. > > ...and I'd like to add one more, because so many people think > that text isn't normative unless it has 2119 key words in all > caps in it: > > - Normative text doesn't require the use of these key words. > They're used for clarity and consistency when you want that, > but lots of normative text doesn't need to use them, and > doesn't use them. From nobody Mon Mar 28 17:05:43 2016 Return-Path: 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 5AB1012D155; Mon, 28 Mar 2016 12:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 35HiHBDb--xO; Mon, 28 Mar 2016 12:58:14 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A9412D183; Mon, 28 Mar 2016 12:58:14 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id n5so144801869pfn.2; Mon, 28 Mar 2016 12:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=3crMLs86+6DTIjfXPjKkTBomscUba+IhnLSIDEpHwgo=; b=KGoshIMGMcFgSsHMUVegyBcvESLtSyCGSqgXuhUqGn27CAecwBSAMLRvFJpn8yVLFn wvD9OIZctbLVGlUfEmS8dA8fAlO70EpcZ95aR0TKVI2rEBwR+ax09kzHF0UCvAVj5/qi GppvGhxfqW1F/nq9QB5xsQ5C50tBE1/83QI6xBGuI+0wcvnczy1T1c2iFW0igHCCoaC9 jkvNm6A3Sf7rXvLiMOeBlZGaGei6iDPGJlPEPFc3ovw82wHBjwUDY/PG382DDADLXxHx N2ZY30mGwd4+hxT34wO70he5PiR7Nu4d02QIef6JB8GTzBHPxipQWnFX2CKgY4uo6qiU 2YWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=3crMLs86+6DTIjfXPjKkTBomscUba+IhnLSIDEpHwgo=; b=lDldzNKghwh0Kgy09xRP8LJVuD1aaM0X9stdMcKAoV6pc8UnINRuzLBaW0n2KC/2Lt S7R71sTyhOOo+Jhp6NJCP3SNffdu3Ctaf55dakZeBHreZRki1mfTE8cc2rc6otjqW4lS QzBRVmGprUta2RuLl+uKBlUEojrcWL3Gey+NwhymNA8uy/lXgzDaqeuPw7ulYyn8XXlj g1x+jtOdv8GjwaqH52f9pjkjSfIDWn3LkBbjXkaGQEexcVwyXR9DlAj24XY78uGKXN7/ n0wMeauOG3LVSCVdTYCKoVu2YgWqLrM4jCgAqnwzXlq7wUtlgmwXlQ252XThvRs+osW1 6pPA== X-Gm-Message-State: AD7BkJIMRKNOElgdgOHULOyyWnw+7AwSlgv2NWBC2Y74HoOHOiQHw41phOYfUoH89z16wg== X-Received: by 10.98.8.219 with SMTP id 88mr45820899pfi.51.1459195094192; Mon, 28 Mar 2016 12:58:14 -0700 (PDT) Received: from ?IPv6:2406:e007:71e7:1:28cc:dc4c:9703:6781? ([2406:e007:71e7:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id tb10sm37690885pab.22.2016.03.28.12.58.09 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2016 12:58:12 -0700 (PDT) To: "Scott O. Bradner" , Barry Leiba References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56F98CD1.10706@gmail.com> Date: Tue, 29 Mar 2016 08:58:09 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Mon, 28 Mar 2016 17:05:34 -0700 Cc: "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IETF discussion list , IESG Subject: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 19:58:16 -0000 There are times when I think RFC2119 was a really bad idea, despite it ha= ving become probably the most frequently cited RFC (inside and outside the IET= F). It seems to create as much confusion as it avoids. There are four words whose RFC2119 meaning is different from the dictiona= ry meaning: should, recommended, may and optional. Having special typography= for them is useful, because it signals the RFC2119 meanings. But if a spe= c uses, for example, a mixture of SHOULD and should, who knows what the aut= hors intended? To that extent, the proposed clarification is helpful. The other words (must, shall, required, not) mean what they always mean. The only argument for upper-casing them is aesthetic symmetry. If a spec uses alternatives like mandatory, necessary or forbidden, they are just a= s powerful. So > these definitions are only meaningful if the words are capitalized can be applied to should, recommended, may and optional if we want, but strictly doesn't apply to must, shall, required, not, mandatory, necessary, forbidden, need, or any other such words. Where we can get into real trouble is if a spec contains should, recommen= ded, may and optional *plus* other non-categorical (fuzzy) words like ought, encourage, suggest, can, might, allowed, permit (and I did not pull those= words out of the air, but out of draft-hansen-nonkeywords-non2119). What = do they mean? It can be very unclear. If a node receives a message containin= g an element covered in the spec by "allowed" instead of "OPTIONAL", is the= receiver supposed to interoperate or to reject the message? If we are issuing guidance, it should probably include a specific warning= to use any such fuzzy words with extreme care. Brian On 29/03/2016 03:13, Scott O. Bradner wrote: > one minor tweak >=20 >> On Mar 28, 2016, at 10:09 AM, Barry Leiba wr= ote: >> >>> The wishy washy descriptive rather than proscriptive language in the = abstract was because I, >>> the IESG and the community were not of one mind to say that the use o= f such capitalized >>> terms should be mandatory - quite a few people felt that the english = language was at >>> least good enough to convey the writer=E2=80=99s intent without havi= ng to aggrandize specific words. >>> Thus the abstract basically was saying: if you want to use capitalize= d words here is a standard >>> way to say what they mean >> >> Ah. Then perhaps the clarification needs to go a little further and >> make this clear: >> - We're defining specific terms that specifications can use. >> - These terms are always capitalized when these definitions are used. >=20 > these definitions are only meaningful if the words are capitalized >=20 >> - You don't have to use them. If you do, they're capitalized and >> their meanings are as specified here. >> - There are similar-looking English words that are not capitalized, >> and they have their normal English meanings; this document has nothing= >> to do with them. >> >> ...and I'd like to add one more, because so many people think that >> text isn't normative unless it has 2119 key words in all caps in it: >> >> - Normative text doesn't require the use of these key words. They're >> used for clarity and consistency when you want that, but lots of >> normative text doesn't need to use them, and doesn't use them. >> >> Barry >=20 >=20 From nobody Mon Mar 28 17:05:46 2016 Return-Path: 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 8BD7B12D19B; Mon, 28 Mar 2016 13:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 fSKmlUxycqIC; Mon, 28 Mar 2016 13:27:23 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C3A112D1B0; Mon, 28 Mar 2016 13:27:18 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-15-56f993810c81 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id C9.C3.22441.18399F65; Mon, 28 Mar 2016 22:26:42 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0248.002; Mon, 28 Mar 2016 16:27:17 -0400 From: Eric Gray To: Brian E Carpenter , "Scott O. Bradner" , Barry Leiba Thread-Topic: Fuzzy words [was Uppercase question for RFC2119 words] Thread-Index: AQHRiSw33A+4lBlJ1EWj5YxJCPJ3Tp9vRxEQ Date: Mon, 28 Mar 2016 20:27:15 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF644AC2AFC@eusaamb107.ericsson.se> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> In-Reply-To: <56F98CD1.10706@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyuXRPiG7T5J9hBqvDLQ4tvsRq0XZxH5PF jD8TmS2ebZzPYnH7mZXF2n/t7BbHO5Ud2D1aVvUye+ycdZfdY8mSn0weDW3HWD1eHPjGHMAa xWWTkpqTWZZapG+XwJVx9uB3poIvthVTt69naWBcYdPFyMkhIWAicanxGSuELSZx4d56ti5G Lg4hgaOMEi/+dLFDOMsZJQ492McOUsUmoCFx7M5aRpCEiEADo8TbuZPBHGaBJYwSU/ZfYQKp EhZwlvjwaR4LiC0i4CKxcsNpKNtIYs/GbrB9LAKqEscmXWYDsXkFfCW2TlsCtfs7q8TcJb+Z QRKcAuoS5xc9AVvNCHTg91NrwBYwC4hL3HoynwnicAGJJXvOM0PYohIvH/+DekhRYl//dKBe DqB6TYn1u/QhWhUlpnQ/ZIfYKyhxcuYTlgmMYrOQTJ2F0DELSccsJB0LGFlWMXKUFhfk5KYb GW5iBMbcMQk2xx2Me3s9DzEKcDAq8fA+CP8RJsSaWFZcmXuIUYKDWUmEd92kn2FCvCmJlVWp RfnxRaU5qcWHGKU5WJTEeb99vBwmJJCeWJKanZpakFoEk2Xi4JRqYFz0MffuxZKGWX5hgoxr 3FgfZWkutj/QK8gUs+6Js+LxdS3lD9ZZ/9uf+Wdqs1oaS0d4Jnvwp/6jQhMMPv/TZPytyPbD 703qJrYIGW/Buts1DVO//C6bPXFXSe+aKbw1884XflAw8BPJ/j9Fuklq56SJVjMmF384aCf5 UVjpR8Lqu5FxXmqH1JRYijMSDbWYi4oTAVyu75i1AgAA Archived-At: X-Mailman-Approved-At: Mon, 28 Mar 2016 17:05:34 -0700 Cc: "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IETF discussion list , IESG Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2016 20:27:25 -0000 QnJpYW4sDQoNCgkgSSBhZ3JlZSB3aXRoIG1vc3Qgb2Ygd2hhdCB5b3Ugc2F5LiAgTXkgaW1wcmVz c2lvbiBoYXMgYmVlbiB0aGF0IG1hbnkgdGltZXMgdGhlIHVzZSBvZiBzb21lIA0Kb2YgdGhlIGZ1 enppZXIgd29yZHMgc3RlbXMgZnJvbSB0aGUgZmFjdCB0aGF0IHRoZSBhdXRob3IocykgaGF2ZSBv Y2Nhc2lvbmFsbHkgZm9yZ290dGVuIHRoYXQgdGhleSBhcmUgDQp3cml0aW5nIGEgc3BlY2lmaWNh dGlvbiwgYW5kIG5vdCBhIGJpdCBvZiBsaXRlcmFyeSBwcm9zZS4NCg0KCVVzaW5nIHZhcmlhdGlv biBpbiB3b3JkaW5nIGRvZXMgbm90IG1ha2UgYSBzcGVjaWZpY2F0aW9uIG1vcmUgcmVhZGFibGUs IGFzIGl0IG1pZ2h0IGEgcGllY2Ugb2YNCmxpdGVyYXR1cmUuICBJdCBtYWtlcyBpdCBsZXNzIHJl YWRhYmxlLCBldmVuIGlmIGl0IG1pZ2h0IG1ha2UgaXQgYSBsZXNzIGJvcmluZyByZWFkLg0KDQoJ SSBhbSBub3QgY2VydGFpbiB0aGF0IG1ha2luZyBhIHNwZWNpZmljYXRpb24gZXhjaXRpbmcgZW5v dWdoIHRvIGtlZXAgdGhlIGF2ZXJhZ2UgcmVhZGVyIGF3YWtlIGlzIA0KYSBnb2FsLg0KDQoJT25l IGFyZWEgd2hlcmUgSSBkbyBzbGlnaHRseSBkaXNhZ3JlZSBpcyBpbiB5b3VyIGNoYXJhY3Rlcml6 YXRpb24gb2YgdGhlIHVzZSBvZiBtdXN0IHZlcnNlcyBNVVNULA0KYW5kIHNpbWlsYXIgd29yZHMu ICBUaGUgRW5nbGlzaCB1c2FnZSBvZiB0aGUgd29yZCAibXVzdCIgY2FuIHZhcnkgc2xpZ2h0bHkg ZnJvbSB0aGUgbm9ybWF0aXZlIHVzZSBvZiB0aGUgDQp3b3JkICJNVVNULiINCg0KCUFzIGFuIGV4 YW1wbGUgLSBpbiB0aGUgc3RhdGVtZW50ICJ3aGF0IGdvZXMgdXAsIG11c3QgY29tZSBkb3duIiAt IHRoZSB3b3JkICJtdXN0IiBpcyBhbG1vc3QgDQpjZXJ0YWlubHkgbWVhbnQgdG8gcmVmbGVjdCBh IGZhY3Qgb2YgbmF0dXJlLCBhcyBvcHBvc2VkIHRvIGFuIGltcGxlbWVudGF0aW9uIGNob2ljZSB0 aGF0IGlzIG5lZWRlZCBpZiB3ZQ0Kd2FudCB0byBoYXZlIGludGVyb3BlcmFibGUgaW1wbGVtZW50 YXRpb25zIG9mIGEgc3BlY2lmaWNhdGlvbi4gDQoNCglJZiB5b3UgY291bGQgdGhyb3cgYSBiYWxs IGludG8gdGhlIGFpciwgYW5kIGl0IGp1c3QgaHVuZyB0aGVyZSwgSSdtIG5vdCBzdXJlIHdlIHNo b3VsZCByZWZlciB0byBpdCBhcw0KIm5vbi1jb21wbGlhbnQuIiAgOi0pDQoNCglBbHNvLCBhIHN0 YXRlbWVudCBhbG9uZyB0aGUgbGluZXMgb2YgImVsZWN0cm9uaWMgZXF1aXBtZW50IE1VU1QgaGF2 ZSBhIHBvd2VyIHNvdXJjZSBvZiBzb21lIA0Kc29ydCIgaXMgbm90IHBhcnRpY3VsYXJseSB1c2Vm dWwgZm9yIGludGVyb3BlcmFiaWxpdHkgLSBldmVuIHRob3VnaCBpdCBzZWVtcyBsaWtlbHkgdG8g YmUgdHJ1ZS4NCg0KCU5vciBkbyBJIHRoaW5rIHdlIHdvdWxkIHdhbnQgYW4gaW1wbGVtZW50YXRp b24gdGhhdCBkaWQgbm90IGhhdmUgdGhpcyBsaW1pdGF0aW9uIHRvIGJlIGRlZW1lZA0Kbm9uLWNv bXBsaWFudC4NCg0KCVRoZXJlIGFyZSBzaW1pbGFyIHVzZXMgZm9yICJuZWVkIiBmb3IgaW5zdGFu Y2UuICBBbmQgLSB3aGlsZSBJIGNhbm5vdCB0aGluayBvZiBhbiBleGFtcGxlIGF0IHRoZSANCm1v bWVudCAtIEkgYW0gbm90IHByZXBhcmVkIHRvIGJldCB0aGUgZmFybSB0aGF0IHRoZXJlIGFyZSBu byBzdWNoIHNpbWlsYXIgdXNlcyBmb3IgInJlcXVpcmVkLiIgIE1heWJlDQp0aGlzIG1pZ2h0IGJl IHRoZSBjYXNlIGZvciBhIGxlZ2FsIHJlcXVpcmVtZW50IHRoYXQgaGFzIG5vdGhpbmcgdG8gZG8g d2l0aCBjb21wYXRpYmxlIGltcGxlbWVudGF0aW9uPw0KDQoJSW4gYW55IGNhc2UsIGl0IGlzIG9j Y2FzaW9uYWxseSBuZWNlc3NhcnkgdG8gdXNlIHRoZXNlIHRlcm1zIGluIGFuIGV4cGxhbmF0b3J5 IHNlbnNlLCBoYXZpbmcgbm90IA0KdmVyeSBtdWNoIHRvIGRvIHdpdGggc3BlY2lmaWNhdGlvbiBv ZiBub3JtYXRpdmUgYmVoYXZpb3IuICBUaGUgZ29vZCBuZXdzIGlzIHRoYXQgbW9zdCBvZiB1cyBj YW4gdGVsbCBpZg0KdGhlIG1lYW5pbmcgaXMgZXhwbGFuYXRvcnksIHZlcnNlcyBub3JtYXRpdmUu DQoNCi0tDQpFcmljDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpZXRmIFtt YWlsdG86aWV0Zi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gRSBDYXJwZW50 ZXINClNlbnQ6IE1vbmRheSwgTWFyY2ggMjgsIDIwMTYgMzo1OCBQTQ0KVG86IFNjb3R0IE8uIEJy YWRuZXI7IEJhcnJ5IExlaWJhDQpDYzogSGVhdGhlciBGbGFuYWdhbiAoUkZDIFNlcmllcyBFZGl0 b3IpOyBydGN3ZWJAaWV0Zi5vcmc7IElFVEYgZGlzY3Vzc2lvbiBsaXN0OyBJRVNHDQpTdWJqZWN0 OiBGdXp6eSB3b3JkcyBbd2FzIFVwcGVyY2FzZSBxdWVzdGlvbiBmb3IgUkZDMjExOSB3b3Jkc10N Cg0KVGhlcmUgYXJlIHRpbWVzIHdoZW4gSSB0aGluayBSRkMyMTE5IHdhcyBhIHJlYWxseSBiYWQg aWRlYSwgZGVzcGl0ZSBpdCBoYXZpbmcNCmJlY29tZSBwcm9iYWJseSB0aGUgbW9zdCBmcmVxdWVu dGx5IGNpdGVkIFJGQyAoaW5zaWRlIGFuZCBvdXRzaWRlIHRoZSBJRVRGKS4NCkl0IHNlZW1zIHRv IGNyZWF0ZSBhcyBtdWNoIGNvbmZ1c2lvbiBhcyBpdCBhdm9pZHMuDQoNClRoZXJlIGFyZSBmb3Vy IHdvcmRzIHdob3NlIFJGQzIxMTkgbWVhbmluZyBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgZGljdGlv bmFyeQ0KbWVhbmluZzogc2hvdWxkLCByZWNvbW1lbmRlZCwgbWF5IGFuZCBvcHRpb25hbC4gSGF2 aW5nIHNwZWNpYWwgdHlwb2dyYXBoeQ0KZm9yIHRoZW0gaXMgdXNlZnVsLCBiZWNhdXNlIGl0IHNp Z25hbHMgdGhlIFJGQzIxMTkgbWVhbmluZ3MuIEJ1dCBpZiBhIHNwZWMNCnVzZXMsIGZvciBleGFt cGxlLCBhIG1peHR1cmUgb2YgU0hPVUxEIGFuZCBzaG91bGQsIHdobyBrbm93cyB3aGF0IHRoZSBh dXRob3JzDQppbnRlbmRlZD8gVG8gdGhhdCBleHRlbnQsIHRoZSBwcm9wb3NlZCBjbGFyaWZpY2F0 aW9uIGlzIGhlbHBmdWwuDQoNClRoZSBvdGhlciB3b3JkcyAobXVzdCwgc2hhbGwsIHJlcXVpcmVk LCBub3QpIG1lYW4gd2hhdCB0aGV5IGFsd2F5cyBtZWFuLg0KVGhlIG9ubHkgYXJndW1lbnQgZm9y IHVwcGVyLWNhc2luZyB0aGVtIGlzIGFlc3RoZXRpYyBzeW1tZXRyeS4gSWYgYSBzcGVjDQp1c2Vz IGFsdGVybmF0aXZlcyBsaWtlIG1hbmRhdG9yeSwgbmVjZXNzYXJ5IG9yIGZvcmJpZGRlbiwgdGhl eSBhcmUganVzdCBhcw0KcG93ZXJmdWwuDQoNClNvDQo+IHRoZXNlIGRlZmluaXRpb25zIGFyZSBv bmx5IG1lYW5pbmdmdWwgaWYgdGhlIHdvcmRzIGFyZSBjYXBpdGFsaXplZA0KY2FuIGJlIGFwcGxp ZWQgdG8gc2hvdWxkLCByZWNvbW1lbmRlZCwgbWF5IGFuZCBvcHRpb25hbCBpZiB3ZSB3YW50LA0K YnV0IHN0cmljdGx5IGRvZXNuJ3QgYXBwbHkgdG8gbXVzdCwgc2hhbGwsIHJlcXVpcmVkLCBub3Qs IG1hbmRhdG9yeSwNCm5lY2Vzc2FyeSwgZm9yYmlkZGVuLCBuZWVkLCBvciBhbnkgb3RoZXIgc3Vj aCB3b3Jkcy4NCg0KV2hlcmUgd2UgY2FuIGdldCBpbnRvIHJlYWwgdHJvdWJsZSBpcyBpZiBhIHNw ZWMgY29udGFpbnMgc2hvdWxkLCByZWNvbW1lbmRlZCwNCm1heSBhbmQgb3B0aW9uYWwgKnBsdXMq IG90aGVyIG5vbi1jYXRlZ29yaWNhbCAoZnV6enkpIHdvcmRzIGxpa2Ugb3VnaHQsDQplbmNvdXJh Z2UsIHN1Z2dlc3QsIGNhbiwgbWlnaHQsIGFsbG93ZWQsIHBlcm1pdCAoYW5kIEkgZGlkIG5vdCBw dWxsIHRob3NlDQp3b3JkcyBvdXQgb2YgdGhlIGFpciwgYnV0IG91dCBvZiBkcmFmdC1oYW5zZW4t bm9ua2V5d29yZHMtbm9uMjExOSkuIFdoYXQgZG8NCnRoZXkgbWVhbj8gSXQgY2FuIGJlIHZlcnkg dW5jbGVhci4gSWYgYSBub2RlIHJlY2VpdmVzIGEgbWVzc2FnZSBjb250YWluaW5nDQphbiBlbGVt ZW50IGNvdmVyZWQgaW4gdGhlIHNwZWMgYnkgImFsbG93ZWQiIGluc3RlYWQgb2YgIk9QVElPTkFM IiwgaXMgdGhlDQpyZWNlaXZlciBzdXBwb3NlZCB0byBpbnRlcm9wZXJhdGUgb3IgdG8gcmVqZWN0 IHRoZSBtZXNzYWdlPw0KDQpJZiB3ZSBhcmUgaXNzdWluZyBndWlkYW5jZSwgaXQgc2hvdWxkIHBy b2JhYmx5IGluY2x1ZGUgYSBzcGVjaWZpYyB3YXJuaW5nDQp0byB1c2UgYW55IHN1Y2ggZnV6enkg d29yZHMgd2l0aCBleHRyZW1lIGNhcmUuDQoNCiAgIEJyaWFuDQpPbiAyOS8wMy8yMDE2IDAzOjEz LCBTY290dCBPLiBCcmFkbmVyIHdyb3RlOg0KPiBvbmUgbWlub3IgdHdlYWsNCj4gDQo+PiBPbiBN YXIgMjgsIDIwMTYsIGF0IDEwOjA5IEFNLCBCYXJyeSBMZWliYSA8YmFycnlsZWliYUBjb21wdXRl ci5vcmc+IHdyb3RlOg0KPj4NCj4+PiBUaGUgd2lzaHkgd2FzaHkgZGVzY3JpcHRpdmUgcmF0aGVy IHRoYW4gcHJvc2NyaXB0aXZlIGxhbmd1YWdlIGluIHRoZSBhYnN0cmFjdCB3YXMgYmVjYXVzZSBJ LA0KPj4+IHRoZSBJRVNHIGFuZCB0aGUgY29tbXVuaXR5IHdlcmUgbm90IG9mIG9uZSBtaW5kIHRv IHNheSB0aGF0IHRoZSB1c2Ugb2Ygc3VjaCBjYXBpdGFsaXplZA0KPj4+IHRlcm1zIHNob3VsZCBi ZSBtYW5kYXRvcnkgLSBxdWl0ZSBhIGZldyBwZW9wbGUgZmVsdCB0aGF0IHRoZSBlbmdsaXNoIGxh bmd1YWdlIHdhcyBhdA0KPj4+IGxlYXN0IGdvb2QgZW5vdWdoIHRvIGNvbnZleSAgdGhlIHdyaXRl cuKAmXMgaW50ZW50IHdpdGhvdXQgaGF2aW5nIHRvIGFnZ3JhbmRpemUgc3BlY2lmaWMgd29yZHMu DQo+Pj4gVGh1cyB0aGUgYWJzdHJhY3QgYmFzaWNhbGx5IHdhcyBzYXlpbmc6IGlmIHlvdSB3YW50 IHRvIHVzZSBjYXBpdGFsaXplZCB3b3JkcyBoZXJlIGlzIGEgc3RhbmRhcmQNCj4+PiB3YXkgdG8g c2F5IHdoYXQgdGhleSBtZWFuDQo+Pg0KPj4gQWguICBUaGVuIHBlcmhhcHMgdGhlIGNsYXJpZmlj YXRpb24gbmVlZHMgdG8gZ28gYSBsaXR0bGUgZnVydGhlciBhbmQNCj4+IG1ha2UgdGhpcyBjbGVh cjoNCj4+IC0gV2UncmUgZGVmaW5pbmcgc3BlY2lmaWMgdGVybXMgdGhhdCBzcGVjaWZpY2F0aW9u cyBjYW4gdXNlLg0KPj4gLSBUaGVzZSB0ZXJtcyBhcmUgYWx3YXlzIGNhcGl0YWxpemVkIHdoZW4g dGhlc2UgZGVmaW5pdGlvbnMgYXJlIHVzZWQuDQo+IA0KPiB0aGVzZSBkZWZpbml0aW9ucyBhcmUg b25seSBtZWFuaW5nZnVsIGlmIHRoZSB3b3JkcyBhcmUgY2FwaXRhbGl6ZWQNCj4gDQo+PiAtIFlv dSBkb24ndCBoYXZlIHRvIHVzZSB0aGVtLiAgSWYgeW91IGRvLCB0aGV5J3JlIGNhcGl0YWxpemVk IGFuZA0KPj4gdGhlaXIgbWVhbmluZ3MgYXJlIGFzIHNwZWNpZmllZCBoZXJlLg0KPj4gLSBUaGVy ZSBhcmUgc2ltaWxhci1sb29raW5nIEVuZ2xpc2ggd29yZHMgdGhhdCBhcmUgbm90IGNhcGl0YWxp emVkLA0KPj4gYW5kIHRoZXkgaGF2ZSB0aGVpciBub3JtYWwgRW5nbGlzaCBtZWFuaW5nczsgdGhp cyBkb2N1bWVudCBoYXMgbm90aGluZw0KPj4gdG8gZG8gd2l0aCB0aGVtLg0KPj4NCj4+IC4uLmFu ZCBJJ2QgbGlrZSB0byBhZGQgb25lIG1vcmUsIGJlY2F1c2Ugc28gbWFueSBwZW9wbGUgdGhpbmsg dGhhdA0KPj4gdGV4dCBpc24ndCBub3JtYXRpdmUgdW5sZXNzIGl0IGhhcyAyMTE5IGtleSB3b3Jk cyBpbiBhbGwgY2FwcyBpbiBpdDoNCj4+DQo+PiAtIE5vcm1hdGl2ZSB0ZXh0IGRvZXNuJ3QgcmVx dWlyZSB0aGUgdXNlIG9mIHRoZXNlIGtleSB3b3Jkcy4gIFRoZXkncmUNCj4+IHVzZWQgZm9yIGNs YXJpdHkgYW5kIGNvbnNpc3RlbmN5IHdoZW4geW91IHdhbnQgdGhhdCwgYnV0IGxvdHMgb2YNCj4+ IG5vcm1hdGl2ZSB0ZXh0IGRvZXNuJ3QgbmVlZCB0byB1c2UgdGhlbSwgYW5kIGRvZXNuJ3QgdXNl IHRoZW0uDQo+Pg0KPj4gQmFycnkNCj4gDQo+IA0KDQo= From nobody Mon Mar 28 17:23:25 2016 Return-Path: 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 E3A6912D0E8 for ; Mon, 28 Mar 2016 17:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 Kjgdf_2y9NPj for ; Mon, 28 Mar 2016 17:23:22 -0700 (PDT) Received: from smtp113.ord1c.emailsrvr.com (smtp113.ord1c.emailsrvr.com [108.166.43.113]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DDFF12D0DF for ; Mon, 28 Mar 2016 17:23:20 -0700 (PDT) Received: from smtp15.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp15.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id C96F9380130; Mon, 28 Mar 2016 20:23:19 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp15.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 5C9A5380125; Mon, 28 Mar 2016 20:23:19 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Mon, 28 Mar 2016 20:23:19 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Mon, 28 Mar 2016 18:23:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <74244AD7-31A4-42DC-B0AB-5F24EE2C7599@iii.ca> References: To: Taylor Brandstetter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Adding previously "discarded" codecs in SDP renegotiation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 00:23:24 -0000 So I think Offer/Answer would allow that, but JSEP says not to do it in = the normal re-offer case as the desire was not to have codecs change on = reoffer, however, if the JS wanted to do redo the offer that way, if it = removed the Track, then added the Track back, I suspect that JSEP would = re-offer will full set of codecs. That sound about right ?=20 > On Mar 28, 2016, at 5:13 PM, Taylor Brandstetter = wrote: >=20 > This seems like a bit of a gray area. JSEP says that for subsequent = offers: >=20 > o The m=3D line and corresponding "a=3Drtpmap" and "a=3Dfmtp" = lines MUST > only include codecs present in the remote description. >=20 > In this situation, the remote description does still contain H.264, so = it seems it would technically be valid to offer it. However, if Alice = were to send a reoffer, she could not offer H.264. And then Bob's remote = description wouldn't contain H.264, so he couldn't offer it even if he = wants to. >=20 > I'm thinking this may be an oversight in the spec. I created an issue = for it: https://github.com/rtcweb-wg/jsep/issues/266 >=20 > As for current implementations: Chrome will freely let you add = previously discarded codecs, and it even creates offers with discarded = codecs. Though this is currently considered a bug. I just created an = issue to track it: = https://bugs.chromium.org/p/webrtc/issues/detail?id=3D5697 >=20 > On Mon, Mar 28, 2016 at 2:25 PM, I=C3=B1aki Baz Castillo = wrote: > Hi, the scenario is the following: >=20 > - Alice sends SDP offer to Bob by offering VP8 (PT 100) and H264 > packetization-mode=3D1 (PT 101). >=20 > - Bob answers with just VP8 (let's say it sets PT 110) in the m=3D = line, > regardless he also supports H264. >=20 > At this time Alice must send VP8 (PT 110) to Bob, and Bob must send > VP8 (PT 100) to Alice. Fine. >=20 > Later Bob wants to change to H264, so he sends a SDP reoffer to Alice > by just offering H264 packetization-mode=3D1 (PT 111). >=20 > Assuming this is valid (re-enabling a previously discarded codec), > Alice answers the reoffer with just H264 (PT 101). >=20 >=20 > Is this valid? And a more pragmatic questions: should I assume that > current WebRTC implementations would support this scenario? >=20 > Thanks a lot. >=20 >=20 > -- > I=C3=B1aki Baz Castillo > >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Mar 28 17:36:55 2016 Return-Path: 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 893BF12D195 for ; Mon, 28 Mar 2016 17:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ueYD-9lbbowM for ; Mon, 28 Mar 2016 17:36:51 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C268112D0AC for ; Mon, 28 Mar 2016 17:36:50 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id h65so591668ywe.0 for ; Mon, 28 Mar 2016 17:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=zJCOefAnITO4ndzY/72aLDYJkQlzk6cRtsxQl4AnmH8=; b=fUH4+9YsOEgKCllCIwc3AImfAvua4YJps5oPbuAtsXyEx0c7u9a1iN3H0snl3on+h5 8uv61ePNOHk3aQ2m3svNQZPlDuBpUW9M0DAhxN6dEuYq16ROTIANorWXeMlWno9Natbl MAWlmLIpjfh0nfyV6J4sF2Q4I8z2X7BIJLwsLBCxI2AavY0Fziwq4jw0FqgaGzZHX8g7 gAAl8E91Gx6iJo7EXfSDKFS+cXW1eup7jMLIEaDc5JeTv3QAmKz+9mYMvRsarPhDD5JC FYEm6OA82YsqlzOgDrXPoVgT7JyLpjgHJeY7JzeBmXiP/36Y/xgAf1PoBXkos7VseXbX vXaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=zJCOefAnITO4ndzY/72aLDYJkQlzk6cRtsxQl4AnmH8=; b=XuRRvh+rsudkGoAFJwAvH68nI4bmDkJpV1q5T4Oxv5GHCMtp5g4gvq/EghOaVByh1h EO/wCBVoJRwe8Ma2N/ZhaS6iGvin3uqe/9lsHlp61EIE9P6fBYj/XN+Jm+8G8VmAk+f4 Ztvh5E1Q5nR3+liAQB8QiUYbr2W9G3DbJQqIsKXGGkrdEwKsrFx4I3hlkEF9KhtstxUD FhxihXvxdvdfzgJ/uspMGBFYUJYqhbEdp7ZaDm7ZqNcX+auXNFrJaf3cPhXocH3OJXez 3fgYtJZOjjKuMoH/wi+LEjY0gzlzWZdqyY2C4xXfmVkwp1MhvvLt4eXhr/Vu6hAdodqR /s0g== X-Gm-Message-State: AD7BkJKx4PEYiOBOFusWUfi69/cs0WpUBbXLFC4c3YtawcADF4eUUxZXodQqPBZDWrYhAQgmRbSCFjywUbsA+oPN MIME-Version: 1.0 X-Received: by 10.129.95.9 with SMTP id t9mr14135195ywb.94.1459211809864; Mon, 28 Mar 2016 17:36:49 -0700 (PDT) Received: by 10.129.42.196 with HTTP; Mon, 28 Mar 2016 17:36:49 -0700 (PDT) In-Reply-To: <74244AD7-31A4-42DC-B0AB-5F24EE2C7599@iii.ca> References: <74244AD7-31A4-42DC-B0AB-5F24EE2C7599@iii.ca> Date: Mon, 28 Mar 2016 17:36:49 -0700 Message-ID: From: Taylor Brandstetter To: Cullen Jennings Content-Type: multipart/alternative; boundary=001a1147e8c094ef17052f25395b Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Adding previously "discarded" codecs in SDP renegotiation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 00:36:54 -0000 --001a1147e8c094ef17052f25395b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > So I think Offer/Answer would allow that, but JSEP says not to do it in the normal re-offer case as the desire was not to have codecs change on reoffer By "normal re-offer case", do you mean when the re-offer is generated by the same peer that generated the initial offer? If so, is there a reason why this should work differently than an "abnormal" re-offer case (where the re-offer is generated by the peer that generated the initial answer)? > if the JS wanted to do redo the offer that way, if it removed the Track, then added the Track back, I suspect that JSEP would re-offer will full set of codecs. As the specs are currently written, removing and re-adding a track would create a new transceiver. So it would definitely have the full set of codecs. On Mon, Mar 28, 2016 at 5:23 PM, Cullen Jennings wrote: > > So I think Offer/Answer would allow that, but JSEP says not to do it in > the normal re-offer case as the desire was not to have codecs change on > reoffer, however, if the JS wanted to do redo the offer that way, if it > removed the Track, then added the Track back, I suspect that JSEP would > re-offer will full set of codecs. That sound about right ? > > > > On Mar 28, 2016, at 5:13 PM, Taylor Brandstetter > wrote: > > > > This seems like a bit of a gray area. JSEP says that for subsequent > offers: > > > > o The m=3D line and corresponding "a=3Drtpmap" and "a=3Dfmtp" lines= MUST > > only include codecs present in the remote description. > > > > In this situation, the remote description does still contain H.264, so > it seems it would technically be valid to offer it. However, if Alice wer= e > to send a reoffer, she could not offer H.264. And then Bob's remote > description wouldn't contain H.264, so he couldn't offer it even if he > wants to. > > > > I'm thinking this may be an oversight in the spec. I created an issue > for it: https://github.com/rtcweb-wg/jsep/issues/266 > > > > As for current implementations: Chrome will freely let you add > previously discarded codecs, and it even creates offers with discarded > codecs. Though this is currently considered a bug. I just created an issu= e > to track it: https://bugs.chromium.org/p/webrtc/issues/detail?id=3D5697 > > > > On Mon, Mar 28, 2016 at 2:25 PM, I=C3=B1aki Baz Castillo > wrote: > > Hi, the scenario is the following: > > > > - Alice sends SDP offer to Bob by offering VP8 (PT 100) and H264 > > packetization-mode=3D1 (PT 101). > > > > - Bob answers with just VP8 (let's say it sets PT 110) in the m=3D line= , > > regardless he also supports H264. > > > > At this time Alice must send VP8 (PT 110) to Bob, and Bob must send > > VP8 (PT 100) to Alice. Fine. > > > > Later Bob wants to change to H264, so he sends a SDP reoffer to Alice > > by just offering H264 packetization-mode=3D1 (PT 111). > > > > Assuming this is valid (re-enabling a previously discarded codec), > > Alice answers the reoffer with just H264 (PT 101). > > > > > > Is this valid? And a more pragmatic questions: should I assume that > > current WebRTC implementations would support this scenario? > > > > Thanks a lot. > > > > > > -- > > I=C3=B1aki Baz Castillo > > > > > > _______________________________________________ > > 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 > > --001a1147e8c094ef17052f25395b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0So I think Offer/Answer would allow that, but JS= EP says not to do it in the normal re-offer case as the desire was not to h= ave codecs change on reoffer
By "normal re-offer case", do yo= u mean when the re-offer is generated by the same peer that generated the i= nitial offer? If so, is there a reason why this should work differently tha= n an "abnormal" re-offer case (where the re-offer is=C2=A0generat= ed by the peer that generated the initial answer)?

> = if the JS wanted to do redo the offer that way, if it removed the Track, th= en added the Track back, I suspect that JSEP would re-offer will full set o= f codecs.
As the specs are currently written, removing and re-add= ing a track would create a new transceiver. So it would definitely have the= full set of codecs.

On Mon, Mar 28, 2016 at 5:23 PM, Cullen Jennings <fluffy@iii.ca&g= t; wrote:

So I think Offer/Answer would allow that, but JSEP says not to do it in the= normal re-offer case as the desire was not to have codecs change on reoffe= r, however, if the JS wanted to do redo the offer that way, if it removed t= he Track, then added the Track back, I suspect that JSEP would re-offer wil= l full set of codecs. That sound about right ?


> On Mar 28, 2016, at 5:13 PM, Taylor Brandstetter <deadbeef@google.com> wrote:
>
> This seems like a bit of a gray area. JSEP says that for subsequent of= fers:
>
>=C2=A0 =C2=A0 o=C2=A0 The m=3D line and corresponding "a=3Drtpmap&= quot; and "a=3Dfmtp" lines MUST
>=C2=A0 =C2=A0 =C2=A0 =C2=A0only include codecs present in the remote de= scription.
>
> In this situation, the remote description does still contain H.264, so= it seems it would technically be valid to offer it. However, if Alice were= to send a reoffer, she could not offer H.264. And then Bob's remote de= scription wouldn't contain H.264, so he couldn't offer it even if h= e wants to.
>
> I'm thinking this may be an oversight in the spec. I created an is= sue for it: https://github.com/rtcweb-wg/jsep/issues/266=
>
> As for current implementations: Chrome will freely let you add previou= sly discarded codecs, and it even creates offers with discarded codecs. Tho= ugh this is currently considered a bug. I just created an issue to track it= : https://bugs.chromium.org/p/webrtc/issue= s/detail?id=3D5697
>
> On Mon, Mar 28, 2016 at 2:25 PM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
> Hi, the scenario is the following:
>
> - Alice sends SDP offer to Bob by offering VP8 (PT 100) and H264
> packetization-mode=3D1 (PT 101).
>
> - Bob answers with just VP8 (let's say it sets PT 110) in the m=3D= line,
> regardless he also supports H264.
>
> At this time Alice must send VP8 (PT 110) to Bob, and Bob must send > VP8 (PT 100) to Alice. Fine.
>
> Later Bob wants to change to H264, so he sends a SDP reoffer to Alice<= br> > by just offering H264 packetization-mode=3D1 (PT 111).
>
> Assuming this is valid (re-enabling a previously discarded codec),
> Alice answers the reoffer with just H264 (PT 101).
>
>
> Is this valid? And a more pragmatic questions: should I assume that > current WebRTC implementations would support this scenario?
>
> Thanks a lot.
>
>
> --
> I=C3=B1aki Baz Castillo
> <ibc@aliax.net>
>
> _______________________________________________
> 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

--001a1147e8c094ef17052f25395b-- From nobody Mon Mar 28 18:07:57 2016 Return-Path: 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 04CFA12D0B8 for ; Mon, 28 Mar 2016 18:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.531 X-Spam-Level: X-Spam-Status: No, score=-114.531 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 SiHM3VjfxHzz for ; Mon, 28 Mar 2016 18:07:54 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF1F112D0A5 for ; Mon, 28 Mar 2016 18:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1627; q=dns/txt; s=iport; t=1459213673; x=1460423273; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YXd61d+W+zcnaSuYq0up3RDc5gwWRex9KTccwPtzp6g=; b=cYaIWl+e9I4VpuWs4Ge61OXB9zkqldbMGQR9Zay1aIz3aJFVHdnj2MrF KEYO3iikxs75FvqF0nC07njeIemmwtyq4ENCuXOLVj1GVvgL8i+oXXuXX yU0OBCjciCgEqrUHbrP5FYn6ovU8ZkY4TmWb6LicPqZjnrsqvf9UmugcM s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAgB31PlW/5xdJa1dgy6BVrp1AQ2Bc?= =?us-ascii?q?IYNAoElOBQBAQEBAQEBZBwLhEIBAQMBOk8CAQg2EDIlAgSIMgjAawEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBFogQCIJJhDqDLYIrBZdkAY4FgWaHdYUyhhGIegEeAQFCg?= =?us-ascii?q?gMZgUmIaH4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,409,1454976000"; d="scan'208";a="85715053" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Mar 2016 01:07:53 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u2T17qK0011569 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 29 Mar 2016 01:07:53 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 28 Mar 2016 21:07:52 -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; Mon, 28 Mar 2016 21:07:51 -0400 From: "Cullen Jennings (fluffy)" To: "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt Thread-Index: AQHRiVdqsfD9L22j3EOs3+YtS9XvKg== Date: Tue, 29 Mar 2016 01:07:51 +0000 Message-ID: <35A3DA21-CF81-45B0-9617-28323A02101E@cisco.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> In-Reply-To: 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="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-ip-handling-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 01:07:56 -0000 (Reduce the to line to the relevant WG list ...) >=20 > My suggestion is to write a tiny draft (I'm willing to be the editor > of that) that updates 2119, which makes one of the following changes: >=20 > NEW -- alternative 1 > In many standards track documents several words are used to signify > the requirements in the specification. These words are often > capitalized, as shown below, but they have special, requirements > meanings regardless of capitalization. >=20 > NEW -- alternative 2 > In many standards track documents several words are used to signify > the requirements in the specification. These words have special, > requirements meanings only when they appear in ALL CAPITALS, > as shown below. >=20 How about the authors of this document make it clear which of these two con= ventions they are using in this document and we can avoid the whole debate = as it become more or less an editorial nit at that point.=20 Personally, I can't imagine while the words from 2119 are in CAP if it did = not mean that CAP has special meaning, so I have always read 2119 to line u= p with alt 1 but really, I don't care. I'd be perfectly happy for the autho= rs to remove all mention of 2119 and use whatever words captured the consen= sus of the WG. IMHO, there are topics that are much more important that thi= s WG needs to get done - perhaps some other WG could work on an update to 2= 119 but in the meantime the internet seems to have survived with specs usin= g the possibly under defined meanings in 2119.=20 (Cullen with my individual contributor hat on) From nobody Tue Mar 29 01:10:12 2016 Return-Path: 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 9CAE112D0DE for ; Tue, 29 Mar 2016 01:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.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 O0ppITLw-H75 for ; Tue, 29 Mar 2016 01:10:09 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B04B12D0C9 for ; Tue, 29 Mar 2016 01:10:09 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id h129so9304713ywb.1 for ; Tue, 29 Mar 2016 01:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5i7KQvaqlCm2mKJfcP3fIZbVKbJt2tNK5lIjWyTkzQU=; b=jWWMOnLyoBPYy0RTzrgqpU1YEXadqyZzdEYTG+il8k7/ytvvsZ6YV/s5YIG58V+VmP fni7Ylg1Dp3UqJ2SOlhqLBZUV4LI6Azw4Ud/EWMH3PMB7khvWGH1oCrPKxrY5aCliHn+ wimimh8byclja6A0vd177jEM9SJvPzPRfT5f0itdJkdva/YCIhjKbhP2eKg+jq333P08 tJ5uHAG56vLr/jpEc4yOHLL9t1eHowRBpfdmk6SLxLQ5Zt40BiSTBeTx5kAesm3DBoGz R+xqL73tQA+kpEqQGp79s1jfhK6hvNC374/nxAC+KSIdKbiHpFgrKyKhbjLt7W/bvGS3 bEHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5i7KQvaqlCm2mKJfcP3fIZbVKbJt2tNK5lIjWyTkzQU=; b=DhN66V7i/RmqJ5zoBsVc1UVntiwOZkCO4nKoprGG/4a6YpleXZ6M3ZLvlfq13DFUoi WsSCl3UkhdI9abKwdKm9XfGfl86LIanqe4MPOb47SDckPs5dPyF+h8A3U2zXrnGjUBAX BDGuzIRSck3YSyTfaFGfboWWBNyfj6ezLDuUROBtzptZMbBw6brPUw/RGytiy7sLv+c2 mjiffw5ACxBYwg2rJKxydO1ydELJDLo6hho6jUCVaBQO/cTc/Av/D0UW9qIb8qDoHQ3i OKw+rfYBoTncQRw2ZDbKBuV3Zb4QCgJ78NmJbb1MyBsA/mIGZuvrcCaHvH707yj/uU7V wVlg== X-Gm-Message-State: AD7BkJJYTs28LiknDFRv+ZDUvvpA2X1SgkcKxRvA36lPFZOGGftxuiCGSITAdyEE8CKpqp8Llj7bxqv/OsXmMw== X-Received: by 10.13.215.149 with SMTP id z143mr347781ywd.278.1459239008591; Tue, 29 Mar 2016 01:10:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.201.132 with HTTP; Tue, 29 Mar 2016 01:09:49 -0700 (PDT) In-Reply-To: References: <74244AD7-31A4-42DC-B0AB-5F24EE2C7599@iii.ca> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 29 Mar 2016 10:09:49 +0200 Message-ID: To: Taylor Brandstetter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Adding previously "discarded" codecs in SDP renegotiation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 08:10:11 -0000 Hi. Since a JSEP issue has been open, I've commented there: https://github.com/rtcweb-wg/jsep/issues/266 Thanks. --=20 I=C3=B1aki Baz Castillo From nobody Tue Mar 29 01:29:30 2016 Return-Path: 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 5409812D56F for ; Tue, 29 Mar 2016 01:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 b2e8l_pCougQ for ; Tue, 29 Mar 2016 01:29:26 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304D712D562 for ; Tue, 29 Mar 2016 01:29:25 -0700 (PDT) X-AuditID: c1b4fb30-f79246d00000788a-42-56fa3ce346fb Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id FF.3A.30858.3EC3AF65; Tue, 29 Mar 2016 10:29:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.45]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Tue, 29 Mar 2016 10:29:23 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "rtcweb@ietf.org" Thread-Topic: [rtcweb] Adding previously "discarded" codecs in SDP renegotiation Thread-Index: AQHRiTh8aJ5r1U4aLU6vy3Lfmn/ZD59wKJ6A Date: Tue, 29 Mar 2016 08:29:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <16CD769F6A7DAF4BA116A40A85F6B7D3@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7ve5jm19hBrefWFtM32djsfZfO7sD k8e5hvfsHkuW/GQKYIrisklJzcksSy3St0vgyui5voK5YCFXxez2m2wNjAs4uhg5OSQETCRO PT/GCGGLSVy4t56ti5GLQ0jgCKPErBW3mCGcxYwS1zsfMXUxcnCwCVhIdP/TBmkQEUiQ2Pxg CgtIWFggUGLx/kCIcJDEkhUfWSBsI4mfexpYQWwWAVWJiw39zCA2r4CVxJvWdlaQViGBAIkn p0pBwpxAU+5NaWcDsRmBzvl+ag0TiM0sIC5x68l8JogzBSSW7DnPDGGLSrx8/A9svKiAnsSO cxC2hICSxI8Nl1ggevUkbkydwgZhW0us7XwPNVNbYtnC11DnCEqcnPmEZQKj+Cwk62YhaZ+F pH0WkvZZSNoXMLKuYhQtTi1Oyk03MtJLLcpMLi7Oz9PLSy3ZxAiMtINbfhvsYHz53PEQowAH oxIPb8LKn2FCrIllxZW5hxglOJiVRHgbLH6FCfGmJFZWpRblxxeV5qQWH2KU5mBREudl/XQ5 TEggPbEkNTs1tSC1CCbLxMEp1cBY8vC7XdDvFS/kT/pc8GwS/cU3caHe2ZcPGXtOthW3/Lqh au3bMfHX5qun46Ubtq6Sa4o5sPnIVyvP9YLzvi1R50vTMyua92mZcl7iuinJQRrsU39Vr5zT sPzbgrvXX8zsEn0YMfFCrtnvu525jh9+9rbLPj8y9cM+VT9pv3vuu0/VVqtkHgrRUWIpzkg0 1GIuKk4EAO2Ypq6wAgAA Archived-At: Subject: Re: [rtcweb] Adding previously "discarded" codecs in SDP renegotiation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 08:29:28 -0000 Hi, I see no reason why one should not be allowed to add previously discarded codecs. There can be many reasons why a codec is discarded at one point, but might be accepted later. Regards, Christer On 29/03/16 00:25, "rtcweb on behalf of I=F1aki Baz Castillo" wrote: >Hi, the scenario is the following: > >- Alice sends SDP offer to Bob by offering VP8 (PT 100) and H264 >packetization-mode=3D1 (PT 101). > >- Bob answers with just VP8 (let's say it sets PT 110) in the m=3D line, >regardless he also supports H264. > >At this time Alice must send VP8 (PT 110) to Bob, and Bob must send >VP8 (PT 100) to Alice. Fine. > >Later Bob wants to change to H264, so he sends a SDP reoffer to Alice >by just offering H264 packetization-mode=3D1 (PT 111). > >Assuming this is valid (re-enabling a previously discarded codec), >Alice answers the reoffer with just H264 (PT 101). > > >Is this valid? And a more pragmatic questions: should I assume that >current WebRTC implementations would support this scenario? > >Thanks a lot. > > >--=20 >I=F1aki Baz Castillo > > >_______________________________________________ >rtcweb mailing list >rtcweb@ietf.org >https://www.ietf.org/mailman/listinfo/rtcweb From nobody Tue Mar 29 01:40:07 2016 Return-Path: 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 3DF0712D564 for ; Tue, 29 Mar 2016 01:40:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.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 cY8AgXXh1cdU for ; Tue, 29 Mar 2016 01:40:04 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC2DA12D562 for ; Tue, 29 Mar 2016 01:40:04 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id g3so9900116ywa.3 for ; Tue, 29 Mar 2016 01:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XXdm57QMuq0lDwmTDLvogC6g5vRltVeEuSCQs9mkxH8=; b=EGhDx5kYfOPjW6JrmwwOPh9pQ8ZU6wOJMN/uvr2czN4hbaUGTEdlRWQgEGVhsEk0ql fIMrPn6oc5BO9UTBc6bEFIEyBDG3giEgxOvUqwEnwe19LcC3zrLn+o8ibGlHaew4T6wt 1vtDDusq1eXJO6XSX7Ksld1SRoawFupyEiGSKXbsxUhrekNaac4zPeSB4PnVQRV9QTmq JecQME1R28M4Mph+q9lYOjDdJfRU2EGilNKr/9i1nqtLemJyG6r4NlzJet3KcsA8nZXY zwHtM1yyhzJoOnmpAXZmhQZlzEGPFC7tIZFkEnbofe9kEkIL05e6Q4u6WhcXc83MdKEC /L8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=XXdm57QMuq0lDwmTDLvogC6g5vRltVeEuSCQs9mkxH8=; b=RcvC1LEKdIPOIPrMP45jZyjCnSnk9onoTcIcE++N89LBM+pBgD+2EkNZHYgwd2HvQN aS0EjYwEgqhYkSnvrFrKoTwsYMfNFpibuCMQpgADbCqBSgK3P9Qwsnq1V4LkvF0ifT9X U042FbuuTKwo4w5mB3yjzudmkYyIoqonY1f7jsXS6JdBr7l3Vxm+W9TUEB0hpvkRewqb NNXSI8L9P7RPWyrIx8dpHDFLkEUpceK3ov9gEBSIzBy2pgyH8nNHSvQd57U6iK+fYZpr gwNrA4kjWkAlfr4aGF+3kBHQ5WgUJJEBbXJkvZHVNNYMTC1ISs+uT/i3l9yVo7+536CQ fISg== X-Gm-Message-State: AD7BkJI/N4n5Hxvxi2NSYqa/a5eD+sQwoePi+fwYZHDYZcP7JcXwb1IMkvYD6NVw3sjnYUbfStIYBloSIJnN2g== X-Received: by 10.129.124.87 with SMTP id x84mr394313ywc.209.1459240803823; Tue, 29 Mar 2016 01:40:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.201.132 with HTTP; Tue, 29 Mar 2016 01:39:44 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 29 Mar 2016 10:39:44 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "rtcweb@ietf.org" Subject: Re: [rtcweb] Adding previously "discarded" codecs in SDP renegotiation X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 08:40:06 -0000 2016-03-29 10:29 GMT+02:00 Christer Holmberg : > I see no reason why one should not be allowed to add previously discarded > codecs. There can be many reasons why a codec is discarded at one point, > but might be accepted later. Agreed. Also: https://github.com/rtcweb-wg/jsep/issues/266#issuecomment-202769776 --=20 I=C3=B1aki Baz Castillo From nobody Tue Mar 29 04:27:19 2016 Return-Path: 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 4073F12D0D8; Tue, 29 Mar 2016 04:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 LHFxFpb6D9ce; Tue, 29 Mar 2016 04:27:16 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E9C12D0A8; Tue, 29 Mar 2016 04:27:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 403051A214A3; Tue, 29 Mar 2016 07:27:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCpBoOd2ITHb; Tue, 29 Mar 2016 07:27:14 -0400 (EDT) Received: from newdev.cadm.harvard.edu (newdev.cadm.harvard.edu [128.103.229.199]) by sobco.sobco.com (Postfix) with ESMTPSA id 0D6E31A2148D; Tue, 29 Mar 2016 07:27:14 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Scott Bradner In-Reply-To: Date: Tue, 29 Mar 2016 07:27:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> To: Barry Leiba X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IESG , "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , Brian E Carpenter , IETF discussion list Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 11:27:18 -0000 fwiw - seems to me that the basic idea that MUST and must are the same = is wrong and will lead to=20 even more confusion imo - any clarification should (not SHOULD - i.e. the english language) = say 1/ some authors capitalize some words for emphasis and clarity 2/ there is no requirement to use capitalized words=20 2/ when capitalized words are used RFC 2119 says what the = capitalized words mean 3/ non capitalized words are interpreted using normal English=20 Scott > On Mar 28, 2016, at 4:30 PM, Barry Leiba = wrote: >=20 > Brian, I think your note goes to how important it is to write clearly > and to get a lot of eyes on it before we publish it. Well-written > documents, with or without 2119 key words, and with or without > lower-case look-alikes, can still be clear. Fuzzily written documents > will be fuzzy. >=20 > In particular: >=20 >> they mean? It can be very unclear. If a node receives a message = containing >> an element covered in the spec by "allowed" instead of "OPTIONAL", is = the >> receiver supposed to interoperate or to reject the message? >=20 > Well, this is where 2119 advises that we *use* the key words when > interoperability is at stake. It's fine to be fuzzy when it doesn't > matter, though even then, I'd argue for more explanation: >=20 > Every frobotz MUST contain a valid bleeg. The glorp field in the > frobotz is an unsigned integer that is normally between 0 and 666, > inclusive. Values greater than 666 are allowed, but recipients > using older software might not be able to handle such values. > ... > When processing a frobotz that does not meet the requirements in > section 3.1.4, it is permissible to reject the frobotz outright, or = to > attempt to process the parts of it that make sense; the choice is > an implementation decision. However, any frobotz that does not > contain a valid bleeg MUST be rejected. >=20 > That sort of thing. >=20 > Barry >=20 > On Mon, Mar 28, 2016 at 3:58 PM, Brian E Carpenter > wrote: >> There are times when I think RFC2119 was a really bad idea, despite = it having >> become probably the most frequently cited RFC (inside and outside the = IETF). >> It seems to create as much confusion as it avoids. >>=20 >> There are four words whose RFC2119 meaning is different from the = dictionary >> meaning: should, recommended, may and optional. Having special = typography >> for them is useful, because it signals the RFC2119 meanings. But if a = spec >> uses, for example, a mixture of SHOULD and should, who knows what the = authors >> intended? To that extent, the proposed clarification is helpful. >>=20 >> The other words (must, shall, required, not) mean what they always = mean. >> The only argument for upper-casing them is aesthetic symmetry. If a = spec >> uses alternatives like mandatory, necessary or forbidden, they are = just as >> powerful. >>=20 >> So >>> these definitions are only meaningful if the words are capitalized >> can be applied to should, recommended, may and optional if we want, >> but strictly doesn't apply to must, shall, required, not, mandatory, >> necessary, forbidden, need, or any other such words. >>=20 >> Where we can get into real trouble is if a spec contains should, = recommended, >> may and optional *plus* other non-categorical (fuzzy) words like = ought, >> encourage, suggest, can, might, allowed, permit (and I did not pull = those >> words out of the air, but out of draft-hansen-nonkeywords-non2119). = What do >> they mean? It can be very unclear. If a node receives a message = containing >> an element covered in the spec by "allowed" instead of "OPTIONAL", is = the >> receiver supposed to interoperate or to reject the message? >>=20 >> If we are issuing guidance, it should probably include a specific = warning >> to use any such fuzzy words with extreme care. >>=20 >> Brian >> On 29/03/2016 03:13, Scott O. Bradner wrote: >>> one minor tweak >>>=20 >>>> On Mar 28, 2016, at 10:09 AM, Barry Leiba = wrote: >>>>=20 >>>>> The wishy washy descriptive rather than proscriptive language in = the abstract was because I, >>>>> the IESG and the community were not of one mind to say that the = use of such capitalized >>>>> terms should be mandatory - quite a few people felt that the = english language was at >>>>> least good enough to convey the writer=E2=80=99s intent without = having to aggrandize specific words. >>>>> Thus the abstract basically was saying: if you want to use = capitalized words here is a standard >>>>> way to say what they mean >>>>=20 >>>> Ah. Then perhaps the clarification needs to go a little further = and >>>> make this clear: >>>> - We're defining specific terms that specifications can use. >>>> - These terms are always capitalized when these definitions are = used. >>>=20 >>> these definitions are only meaningful if the words are capitalized >>>=20 >>>> - You don't have to use them. If you do, they're capitalized and >>>> their meanings are as specified here. >>>> - There are similar-looking English words that are not capitalized, >>>> and they have their normal English meanings; this document has = nothing >>>> to do with them. >>>>=20 >>>> ...and I'd like to add one more, because so many people think that >>>> text isn't normative unless it has 2119 key words in all caps in = it: >>>>=20 >>>> - Normative text doesn't require the use of these key words. = They're >>>> used for clarity and consistency when you want that, but lots of >>>> normative text doesn't need to use them, and doesn't use them. >>>>=20 >>>> Barry >>>=20 >>>=20 >>=20 From nobody Tue Mar 29 05:06:53 2016 Return-Path: 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 1F9E512D111; Tue, 29 Mar 2016 05:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 AD1dxmzv8oEU; Tue, 29 Mar 2016 05:06:43 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FC5212D1E3; Tue, 29 Mar 2016 05:06:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 3E2A51A222E9; Tue, 29 Mar 2016 08:06:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxgWyLnYDljI; Tue, 29 Mar 2016 08:06:40 -0400 (EDT) Received: from newdev.cadm.harvard.edu (newdev.cadm.harvard.edu [128.103.229.199]) by sobco.sobco.com (Postfix) with ESMTPSA id 6990B1A222D7; Tue, 29 Mar 2016 08:06:40 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Scott Bradner In-Reply-To: Date: Tue, 29 Mar 2016 08:06:39 -0400 Content-Transfer-Encoding: 7bit Message-Id: <064D5F96-1FD5-4CB1-93AD-525385C1B1B8@sobco.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> To: "John C. Klensin" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Heather Flanagan \(RFC Series Editor\)" , Barry Leiba , rtcweb@ietf.org, IESG , IETF discussion list Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 12:06:49 -0000 agreed Scott > On Mar 29, 2016, at 7:57 AM, John C Klensin wrote: > > > > --On Tuesday, March 29, 2016 07:27 -0400 Scott Bradner > wrote: > >> fwiw - seems to me that the basic idea that MUST and must are >> the same is wrong and will lead to even more confusion >> >> imo - any clarification should (not SHOULD - i.e. the english >> language) say >> 1/ some authors capitalize some words for >> emphasis and clarity >> 2/ there is no requirement to use >> capitalized words >> 2/ when capitalized words are used RFC >> 2119 says what the capitalized words mean >> 3/ non capitalized words are interpreted >> using normal English > > Agreed, if your second #2 is modified to read "when capitalized > words are used and RFC 2119 is explicitly and normatively > referenced, RFC 2119 says what the capitalized words mean". In > other words, there is no universal applicability of 2119 -- if I > write a document that says "where this document says 'MUST', it > means you should (sic) do it if you find it convenient". that > might well be editorially dumb, but 2119 has nothing to do with > it, nor does it prevent such a definition. > > john > > >> > > > > From nobody Tue Mar 29 06:30:17 2016 Return-Path: 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 3F80012D817 for ; Tue, 29 Mar 2016 06:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 VOQUWTaIh3Mk for ; Tue, 29 Mar 2016 06:30:14 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8124A12D80E for ; Tue, 29 Mar 2016 06:30:03 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2TDU0K6042737 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 29 Mar 2016 08:30:01 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Scott Bradner" Date: Tue, 29 Mar 2016 08:30:00 -0500 Message-ID: <12CA94AA-E837-415E-BF7F-D5F4755F4C21@nostrum.com> In-Reply-To: References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: IETF discussion list , Heather Flanagan , "rtcweb@ietf.org" , IESG , Barry Leiba , Brian E Carpenter Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 13:30:16 -0000 On 29 Mar 2016, at 6:27, Scott Bradner wrote: > fwiw - seems to me that the basic idea that MUST and must are the same > is wrong and will lead to > even more confusion > > imo - any clarification should (not SHOULD - i.e. the english > language) say > 1/ some authors capitalize some words for emphasis and clarity > 2/ there is no requirement to use capitalized words > 2/ when capitalized words are used RFC 2119 says what the capitalized > words mean > 3/ non capitalized words are interpreted using normal English I agree heartily, especially with 3. As it is, we often get tortured language where people try to avoid such words in text. That makes the writing hard, and the reading even harder. Ben. From nobody Tue Mar 29 08:28:53 2016 Return-Path: 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 9106712D912; Tue, 29 Mar 2016 08:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.579 X-Spam-Level: X-Spam-Status: No, score=-1.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] autolearn=no 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 Jc59P8e3Rk9O; Tue, 29 Mar 2016 08:28:48 -0700 (PDT) Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 016B512D8B9; Tue, 29 Mar 2016 08:26:48 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id u2TFO4Bs007576; Tue, 29 Mar 2016 11:26:44 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 21yt027mce-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Mar 2016 11:26:43 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u2TFQhFm026315; Tue, 29 Mar 2016 11:26:43 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u2TFQVq1026001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Mar 2016 11:26:37 -0400 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 29 Mar 2016 15:26:24 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.206]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0248.002; Tue, 29 Mar 2016 11:26:23 -0400 From: "HANSEN, TONY L" Thread-Topic: Fuzzy words [was Uppercase question for RFC2119 words] Thread-Index: AQHRibJf4YX4KPSwW0Cg8uganmsWpp9wsmqA///Y4wA= Date: Tue, 29 Mar 2016 15:26:23 +0000 Message-ID: <82156918-B008-479C-BC6E-7A54930820D8@att.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.110.240.227] Content-Type: multipart/alternative; boundary="_000_82156918B008479CBC6E7A54930820D8attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-29_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1603290224 Archived-At: Cc: "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IETF discussion list , IESG Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 15:28:49 -0000 --_000_82156918B008479CBC6E7A54930820D8attcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbHNvIGZlZWwgdGhhdCBhIG1vZGlmaWVkIHZlcnNpb24gb2YgdGhlIFJGQyAyMTE5IHN0YXRl bWVudCBzaG91bGQgYmUgZGVmaW5lZCBhbmQgc3BlY2lmaWVkIGluIGEgc21hbGwgUkZDLg0KDQpJ IGxpa2UgRGF2ZSdzIGFkZGl0aW9uLCBidXQgYWxzbyB0aGluayBhZGRpbmcgdGhlIHdvcmQgIm9u bHkiIGlzIHdvcnRoIGRvaW5nOg0KDQogICAgICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1Qg Tk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMDQogICAgICBOT1QiLCAiU0hPVUxEIiwg IlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAgIk1BWSIsIGFuZA0KICAgICAgIk9QVElPTkFM IiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4N CiAgICAgIFJGQyAyMTE5IG9ubHkgd2hlbiBjYXBpdGFsaXNlZC4NCg0KTGVhdmluZyBvdXQgdGhl ICJvbmx5IiBzdGlsbCBsZWF2ZXMgdGhlIHN0YXRlbWVudCAoc2xpZ2h0bHkpIGFtYmlndW91czsg aXQncyB0aGUgc2FtZSBhcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuICJpZiIgYW5kICJpZiBhbmQg b25seSBpZiIuDQoNCi0gVG9ueSBIYW5zZW4NCg0KRnJvbTogaWV0ZiA8aWV0Zi1ib3VuY2VzQGll dGYub3JnPG1haWx0bzppZXRmLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgRGF2ZSBD cmlkbGFuZCA8ZGF2ZUBjcmlkbGFuZC5uZXQ8bWFpbHRvOmRhdmVAY3JpZGxhbmQubmV0Pj4NCkRh dGU6IFR1ZXNkYXksIE1hcmNoIDI5LCAyMDE2IGF0IDk6NDYgQU0NClRvOiBKb2huIEMgS2xlbnNp biA8am9obi1pZXRmQGpjay5jb208bWFpbHRvOmpvaG4taWV0ZkBqY2suY29tPj4NCkNjOiBJRVRG IGRpc2N1c3Npb24gbGlzdCA8aWV0ZkBpZXRmLm9yZzxtYWlsdG86aWV0ZkBpZXRmLm9yZz4+LCAi SGVhdGhlciBGbGFuYWdhbiAoUkZDIFNlcmllcyBFZGl0b3IpIiA8cnNlQHJmYy1lZGl0b3Iub3Jn PG1haWx0bzpyc2VAcmZjLWVkaXRvci5vcmc+PiwgInJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRj d2ViQGlldGYub3JnPiIgPHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPj4s IElFU0cgPGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+PiwgQmFycnkgTGVpYmEg PGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPG1haWx0bzpiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZz4+ DQpTdWJqZWN0OiBSZTogRnV6enkgd29yZHMgW3dhcyBVcHBlcmNhc2UgcXVlc3Rpb24gZm9yIFJG QzIxMTkgd29yZHNdDQoNCi4gLiAuDQpBZ3JlZWQsIGJ1dCB3ZSBzaG91bGQgKG91Z2h0IHRvLCBw cm9iYWJseSB3aXNoIHRvLCBldGMpIGNvbnNpZGVyIGEgcmVwbGFjZW1lbnQgZm9yIHRoZSBmb2xs b3dpbmc6DQoNCiAgICAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlS RUQiLCAiU0hBTEwiLCAiU0hBTEwNCiAgICAgIE5PVCIsICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIs ICJSRUNPTU1FTkRFRCIsICAiTUFZIiwgYW5kDQogICAgICAiT1BUSU9OQUwiIGluIHRoaXMgZG9j dW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbg0KICAgICAgUkZDIDIx MTkuDQoNClBlcmhhcHMgc2ltcGx5Og0KDQogICAgICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1V U1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMDQogICAgICBOT1QiLCAiU0hPVUxE IiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAgIk1BWSIsIGFuZA0KICAgICAgIk9QVElP TkFMIiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQg aW4NCiAgICAgIFJGQyAyMTE5IHdoZW4gY2FwaXRhbGlzZWQuDQoNCg0K --_000_82156918B008479CBC6E7A54930820D8attcom_ Content-Type: text/html; charset="utf-8" Content-ID: <7C1004366D4EEA4FB7EFEBD2E7AA9764@LOCAL> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj5JIGFsc28gZmVlbCB0aGF0IGEgbW9kaWZpZWQgdmVyc2lvbiBvZiB0aGUgUkZD IDIxMTkgc3RhdGVtZW50IHNob3VsZCBiZSBkZWZpbmVkIGFuZCBzcGVjaWZpZWQgaW4gYSBzbWFs bCBSRkMuPC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGxpa2UgRGF2ZSdzIGFkZGl0aW9uLCBidXQgYWxzbyB0 aGluayBhZGRpbmcgdGhlIHdvcmQgJnF1b3Q7b25seSZxdW90OyBpcyB3b3J0aCBkb2luZzo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoZSBrZXkg d29yZHMgJnF1b3Q7TVVTVCZxdW90OywgJnF1b3Q7TVVTVCBOT1QmcXVvdDssICZxdW90O1JFUVVJ UkVEJnF1b3Q7LCAmcXVvdDtTSEFMTCZxdW90OywgJnF1b3Q7U0hBTEw8L2Rpdj4NCjxkaXY+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgTk9UJnF1b3Q7LCAmcXVvdDtTSE9VTEQmcXVvdDssICZxdW90O1NI T1VMRCBOT1QmcXVvdDssICZxdW90O1JFQ09NTUVOREVEJnF1b3Q7LCAmbmJzcDsmcXVvdDtNQVkm cXVvdDssIGFuZDwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtPUFRJT05B TCZxdW90OyBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmli ZWQgaW48L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgUkZDIDIxMTkgb25seSB3aGVu IGNhcGl0YWxpc2VkLjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5MZWF2 aW5nIG91dCB0aGUgJnF1b3Q7b25seSZxdW90OyBzdGlsbCBsZWF2ZXMgdGhlIHN0YXRlbWVudCAo c2xpZ2h0bHkpIGFtYmlndW91czsgaXQncyB0aGUgc2FtZSBhcyB0aGUgZGlmZmVyZW5jZSBiZXR3 ZWVuICZxdW90O2lmJnF1b3Q7IGFuZCAmcXVvdDtpZiBhbmQgb25seSBpZiZxdW90Oy48L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi0gVG9ueSBIYW5zZW48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTJwdDsgdGV4dC1hbGlnbjpsZWZ0 OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBt ZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJ TkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdI VDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPkZyb206IDwvc3Bhbj5pZXRmICZsdDs8YSBocmVmPSJtYWlsdG86aWV0Zi1ib3Vu Y2VzQGlldGYub3JnIj5pZXRmLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2Yg RGF2ZSBDcmlkbGFuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRhdmVAY3JpZGxhbmQubmV0Ij5kYXZl QGNyaWRsYW5kLm5ldDwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBNYXJjaCAyOSwgMjAxNiBhdCA5OjQ2IEFNPGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+Sm9obiBDIEtsZW5zaW4gJmx0 OzxhIGhyZWY9Im1haWx0bzpqb2huLWlldGZAamNrLmNvbSI+am9obi1pZXRmQGpjay5jb208L2E+ Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPklFVEYg ZGlzY3Vzc2lvbiBsaXN0ICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBpZXRmLm9yZyI+aWV0ZkBp ZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDtIZWF0aGVyIEZsYW5hZ2FuIChSRkMgU2VyaWVzIEVkaXRv cikmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyc2VAcmZjLWVkaXRvci5vcmciPnJzZUByZmMt ZWRpdG9yLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3Jn Ij5ydGN3ZWJAaWV0Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpydGN3ZWJA aWV0Zi5vcmciPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7LCBJRVNHICZsdDs8YSBocmVmPSJtYWls dG86aWVzZ0BpZXRmLm9yZyI+aWVzZ0BpZXRmLm9yZzwvYT4mZ3Q7LCBCYXJyeSBMZWliYSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnIj5iYXJyeWxlaWJhQGNvbXB1 dGVyLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1Ympl Y3Q6IDwvc3Bhbj5SZTogRnV6enkgd29yZHMgW3dhcyBVcHBlcmNhc2UgcXVlc3Rpb24gZm9yIFJG QzIxMTkgd29yZHNdPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9 ImdtYWlsX3F1b3RlIj4NCjxkaXY+LiAuIC48L2Rpdj4NCjxkaXY+QWdyZWVkLCBidXQgd2Ugc2hv dWxkIChvdWdodCB0bywgcHJvYmFibHkgd2lzaCB0bywgZXRjKSBjb25zaWRlciBhIHJlcGxhY2Vt ZW50IGZvciB0aGUgZm9sbG93aW5nOjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2PiZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoZSBrZXkgd29yZHMgJnF1b3Q7TVVTVCZxdW90Oywg JnF1b3Q7TVVTVCBOT1QmcXVvdDssICZxdW90O1JFUVVJUkVEJnF1b3Q7LCAmcXVvdDtTSEFMTCZx dW90OywgJnF1b3Q7U0hBTEw8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgTk9UJnF1 b3Q7LCAmcXVvdDtTSE9VTEQmcXVvdDssICZxdW90O1NIT1VMRCBOT1QmcXVvdDssICZxdW90O1JF Q09NTUVOREVEJnF1b3Q7LCAmbmJzcDsmcXVvdDtNQVkmcXVvdDssIGFuZDwvZGl2Pg0KPGRpdj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtPUFRJT05BTCZxdW90OyBpbiB0aGlzIGRvY3VtZW50 IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW48L2Rpdj4NCjxkaXY+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgUkZDIDIxMTkuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2PlBlcmhhcHMgc2ltcGx5OjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2PiZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoZSBrZXkgd29yZHMgJnF1b3Q7TVVTVCZxdW90Oywg JnF1b3Q7TVVTVCBOT1QmcXVvdDssICZxdW90O1JFUVVJUkVEJnF1b3Q7LCAmcXVvdDtTSEFMTCZx dW90OywgJnF1b3Q7U0hBTEw8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgTk9UJnF1 b3Q7LCAmcXVvdDtTSE9VTEQmcXVvdDssICZxdW90O1NIT1VMRCBOT1QmcXVvdDssICZxdW90O1JF Q09NTUVOREVEJnF1b3Q7LCAmbmJzcDsmcXVvdDtNQVkmcXVvdDssIGFuZDwvZGl2Pg0KPGRpdj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtPUFRJT05BTCZxdW90OyBpbiB0aGlzIGRvY3VtZW50 IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW48L2Rpdj4NCjxkaXY+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgUkZDIDIxMTkgd2hlbiBjYXBpdGFsaXNlZC48L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_82156918B008479CBC6E7A54930820D8attcom_-- From nobody Tue Mar 29 09:38:07 2016 Return-Path: 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 9E67512D68E; Tue, 29 Mar 2016 03:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 V6qlibFctvge; Tue, 29 Mar 2016 03:58:04 -0700 (PDT) Received: from ppsw-43.csi.cam.ac.uk (ppsw-43.csi.cam.ac.uk [131.111.8.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F1912D694; Tue, 29 Mar 2016 03:58:03 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:49676) by ppsw-43.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1akrLR-0002va-oH (Exim 4.86_36-e07b163) (return-path ); Tue, 29 Mar 2016 11:57:57 +0100 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1akrLR-0004iR-I7 (Exim 4.72) (return-path ); Tue, 29 Mar 2016 11:57:57 +0100 Date: Tue, 29 Mar 2016 11:57:57 +0100 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Brian E Carpenter In-Reply-To: <56F98CD1.10706@gmail.com> Message-ID: References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Archived-At: X-Mailman-Approved-At: Tue, 29 Mar 2016 09:38:06 -0700 Cc: IETF discussion list , "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IESG , Barry Leiba , "Scott O. Bradner" Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 10:58:05 -0000 Brian E Carpenter wrote: > But if a spec uses, for example, a mixture of SHOULD and should, who > knows what the authors intended? To that extent, the proposed > clarification is helpful. I think if a document uses RFC 2119 keywords then it ought to avoid non-capitalized uses of the keywords, e.g. by replacing "should" with "ought to" or other rephrasings. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Rockall, Malin: Cyclonic 4 or 5, becoming west 5 or 6 later. Moderate or rough, occasionally very rough in south Rockall. Showers. Good. From nobody Tue Mar 29 09:38:09 2016 Return-Path: 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 7A33012D6D1; Tue, 29 Mar 2016 04:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 cjTBISNyqv6H; Tue, 29 Mar 2016 04:30:20 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB54E12D6D3; Tue, 29 Mar 2016 04:30:07 -0700 (PDT) Received: from [192.168.1.9] (unknown [49.149.143.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 3ABBD1802A51; Tue, 29 Mar 2016 13:30:03 +0200 (CEST) To: Scott Bradner , Barry Leiba References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> From: Loa Andersson Message-ID: <56FA6734.5090307@pi.nu> Date: Tue, 29 Mar 2016 19:29:56 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Tue, 29 Mar 2016 09:38:06 -0700 Cc: "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IESG , IETF discussion list Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 11:30:22 -0000 2nd in motion /Loa On 2016-03-29 19:27, Scott Bradner wrote: > fwiw - seems to me that the basic idea that MUST and must are the same is wrong and will lead to > even more confusion > > imo - any clarification should (not SHOULD - i.e. the english language) say > 1/ some authors capitalize some words for emphasis and clarity > 2/ there is no requirement to use capitalized words > 2/ when capitalized words are used RFC 2119 says what the capitalized words mean > 3/ non capitalized words are interpreted using normal English > > Scott > >> On Mar 28, 2016, at 4:30 PM, Barry Leiba wrote: >> >> Brian, I think your note goes to how important it is to write clearly >> and to get a lot of eyes on it before we publish it. Well-written >> documents, with or without 2119 key words, and with or without >> lower-case look-alikes, can still be clear. Fuzzily written documents >> will be fuzzy. >> >> In particular: >> >>> they mean? It can be very unclear. If a node receives a message containing >>> an element covered in the spec by "allowed" instead of "OPTIONAL", is the >>> receiver supposed to interoperate or to reject the message? >> >> Well, this is where 2119 advises that we *use* the key words when >> interoperability is at stake. It's fine to be fuzzy when it doesn't >> matter, though even then, I'd argue for more explanation: >> >> Every frobotz MUST contain a valid bleeg. The glorp field in the >> frobotz is an unsigned integer that is normally between 0 and 666, >> inclusive. Values greater than 666 are allowed, but recipients >> using older software might not be able to handle such values. >> ... >> When processing a frobotz that does not meet the requirements in >> section 3.1.4, it is permissible to reject the frobotz outright, or to >> attempt to process the parts of it that make sense; the choice is >> an implementation decision. However, any frobotz that does not >> contain a valid bleeg MUST be rejected. >> >> That sort of thing. >> >> Barry >> >> On Mon, Mar 28, 2016 at 3:58 PM, Brian E Carpenter >> wrote: >>> There are times when I think RFC2119 was a really bad idea, despite it having >>> become probably the most frequently cited RFC (inside and outside the IETF). >>> It seems to create as much confusion as it avoids. >>> >>> There are four words whose RFC2119 meaning is different from the dictionary >>> meaning: should, recommended, may and optional. Having special typography >>> for them is useful, because it signals the RFC2119 meanings. But if a spec >>> uses, for example, a mixture of SHOULD and should, who knows what the authors >>> intended? To that extent, the proposed clarification is helpful. >>> >>> The other words (must, shall, required, not) mean what they always mean. >>> The only argument for upper-casing them is aesthetic symmetry. If a spec >>> uses alternatives like mandatory, necessary or forbidden, they are just as >>> powerful. >>> >>> So >>>> these definitions are only meaningful if the words are capitalized >>> can be applied to should, recommended, may and optional if we want, >>> but strictly doesn't apply to must, shall, required, not, mandatory, >>> necessary, forbidden, need, or any other such words. >>> >>> Where we can get into real trouble is if a spec contains should, recommended, >>> may and optional *plus* other non-categorical (fuzzy) words like ought, >>> encourage, suggest, can, might, allowed, permit (and I did not pull those >>> words out of the air, but out of draft-hansen-nonkeywords-non2119). What do >>> they mean? It can be very unclear. If a node receives a message containing >>> an element covered in the spec by "allowed" instead of "OPTIONAL", is the >>> receiver supposed to interoperate or to reject the message? >>> >>> If we are issuing guidance, it should probably include a specific warning >>> to use any such fuzzy words with extreme care. >>> >>> Brian >>> On 29/03/2016 03:13, Scott O. Bradner wrote: >>>> one minor tweak >>>> >>>>> On Mar 28, 2016, at 10:09 AM, Barry Leiba wrote: >>>>> >>>>>> The wishy washy descriptive rather than proscriptive language in the abstract was because I, >>>>>> the IESG and the community were not of one mind to say that the use of such capitalized >>>>>> terms should be mandatory - quite a few people felt that the english language was at >>>>>> least good enough to convey the writer’s intent without having to aggrandize specific words. >>>>>> Thus the abstract basically was saying: if you want to use capitalized words here is a standard >>>>>> way to say what they mean >>>>> >>>>> Ah. Then perhaps the clarification needs to go a little further and >>>>> make this clear: >>>>> - We're defining specific terms that specifications can use. >>>>> - These terms are always capitalized when these definitions are used. >>>> >>>> these definitions are only meaningful if the words are capitalized >>>> >>>>> - You don't have to use them. If you do, they're capitalized and >>>>> their meanings are as specified here. >>>>> - There are similar-looking English words that are not capitalized, >>>>> and they have their normal English meanings; this document has nothing >>>>> to do with them. >>>>> >>>>> ...and I'd like to add one more, because so many people think that >>>>> text isn't normative unless it has 2119 key words in all caps in it: >>>>> >>>>> - Normative text doesn't require the use of these key words. They're >>>>> used for clarity and consistency when you want that, but lots of >>>>> normative text doesn't need to use them, and doesn't use them. >>>>> >>>>> Barry >>>> >>>> >>> > From nobody Tue Mar 29 09:38:11 2016 Return-Path: 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 A1B6912D82A for ; Tue, 29 Mar 2016 06:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net 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 p35ox1389wbN for ; Tue, 29 Mar 2016 06:46:31 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C5112D819 for ; Tue, 29 Mar 2016 06:46:22 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id p65so140005786wmp.1 for ; Tue, 29 Mar 2016 06:46:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=b0zlt7phyj/6fHDqKbvErffnm/vFsuywnQ+0KbQrcSI=; b=hGv56eEIPsw/cN78Cg8d3ubyVlpO9dnhlkkCR3vCaZaibuaQR3/QwXci7aonjtug4x P9UATYewrPiSPOyWsvGAk4KD7m7qUJ7ukR4cOaPOljljW47xR1mxSz2rsdAtkkOa2pPA oOiDsWQskbpNcnHkQ10AVMH5oWRzyujfcl3NE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=b0zlt7phyj/6fHDqKbvErffnm/vFsuywnQ+0KbQrcSI=; b=JEA06+owxbMwxNOf+hnMkXhvZtcIxmVrAv8MjKXoFN90zhsHnRTiNUlY+GG/yltzmf F7afj73clXjRtbELf7f2Q+wBnHJF/EjaXPVndq3m49ZhMTta6ovDySjz/1RgmgNkuGoY Zfs02HP9hbYJhQnp+9totbQvK2QMUpI3uV2dyd8Nui7oEEiqxWIb14qCjSXp8cgFBIHZ GvNMR5j77DNYtwgrRmOlBhoFOiR8s06QN3UBFoaFMnaE8qqTDLqUhNKMFHIGOI+cc3xh 7bfpSGBNI7/LXTdxROeZCVlpCIzF/0b80rA47rEsZBwRD2KVVPcOALEzRQeBYyn+jCPH lIPQ== X-Gm-Message-State: AD7BkJKlvJvu1el6Rmqf4c3eaf15wNoH626glCqoVAxiEDT6DV5x1GITc9fCFsVxtX2R65BLFyizp+UuHI5LRNhY MIME-Version: 1.0 X-Received: by 10.194.123.102 with SMTP id lz6mr3223951wjb.2.1459259181321; Tue, 29 Mar 2016 06:46:21 -0700 (PDT) Received: by 10.28.37.199 with HTTP; Tue, 29 Mar 2016 06:46:21 -0700 (PDT) In-Reply-To: References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> Date: Tue, 29 Mar 2016 14:46:21 +0100 Message-ID: From: Dave Cridland To: John C Klensin Content-Type: multipart/alternative; boundary=089e01160950236d26052f30418c Archived-At: X-Mailman-Approved-At: Tue, 29 Mar 2016 09:38:06 -0700 Cc: IETF discussion list , "Heather Flanagan \(RFC Series Editor\)" , rtcweb@ietf.org, IESG , Barry Leiba , Scott Bradner Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 13:46:37 -0000 --089e01160950236d26052f30418c Content-Type: text/plain; charset=UTF-8 On 29 March 2016 at 12:57, John C Klensin wrote: > > > --On Tuesday, March 29, 2016 07:27 -0400 Scott Bradner > wrote: > > > fwiw - seems to me that the basic idea that MUST and must are > > the same is wrong and will lead to even more confusion > > > > imo - any clarification should (not SHOULD - i.e. the english > > language) say > > 1/ some authors capitalize some words for > > emphasis and clarity > > 2/ there is no requirement to use > > capitalized words > > 2/ when capitalized words are used RFC > > 2119 says what the capitalized words mean > > 3/ non capitalized words are interpreted > > using normal English > > Agreed, if your second #2 is modified to read "when capitalized > words are used and RFC 2119 is explicitly and normatively > referenced, RFC 2119 says what the capitalized words mean". In > other words, there is no universal applicability of 2119 -- if I > write a document that says "where this document says 'MUST', it > means you should (sic) do it if you find it convenient". that > might well be editorially dumb, but 2119 has nothing to do with > it, nor does it prevent such a definition. > > Agreed, but we should (ought to, probably wish to, etc) consider a replacement for the following: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Perhaps simply: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 when capitalised. > john > > > > > > > > > --089e01160950236d26052f30418c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 29 March 2016 at 12:57, John C Klensin <john-ietf@jck.com> wrote:


--On Tuesday, March 29, 2016 07:27 -0400 Scott Bradner
<sob@sobco.com>= wrote:

> fwiw - seems to me that the basic idea that MUST and must are
> the same is wrong and will lead to=C2=A0 even more confusion
>
> imo - any clarification should (not SHOULD - i.e. the english
> language) say
>=C2=A0 =C2=A0 =C2=A0 =C2=A01/ some authors capitalize some words for > emphasis and clarity
>=C2=A0 =C2=A0 =C2=A0 =C2=A02/ there is no requirement to use
> capitalized words
>=C2=A0 2/ when capitalized words are used RFC
> 2119 says what the capitalized words mean
>=C2=A0 =C2=A0 =C2=A0 =C2=A03/ non capitalized words are interpreted
>=C2=A0 =C2=A0using normal English

Agreed, if your second #2 is modified to read "when capitalized=
words are used and RFC 2119 is explicitly and normatively
referenced, RFC 2119 says what the capitalized words mean".=C2=A0 =C2= =A0In
other words, there is no universal applicability of 2119 -- if I
write a document that says "where this document says 'MUST', i= t
means you should (sic) do it if you find it convenient". that
might well be editorially dumb, but 2119 has nothing to do with
it, nor does it prevent such a definition.


Agreed, but we should (ought to, proba= bly wish to, etc) consider a replacement for the following:

<= /div>
=C2=A0 =C2=A0 =C2=A0 The key words "MUST", "M= UST NOT", "REQUIRED", "SHALL", "SHALL
=C2=A0 =C2=A0 =C2=A0 NOT", "SHOULD", "SHOULD NOT&quo= t;, "RECOMMENDED", =C2=A0"MAY", and
=C2=A0 = =C2=A0 =C2=A0 "OPTIONAL" in this document are to be interpreted a= s described in
=C2=A0 =C2=A0 =C2=A0 RFC 2119.

Perhaps simply:

=C2=A0 =C2=A0 =C2= =A0 The key words "MUST", "MUST NOT", "REQUIRED&qu= ot;, "SHALL", "SHALL
=C2=A0 =C2=A0 =C2=A0 NOT"= ;, "SHOULD", "SHOULD NOT", "RECOMMENDED", =C2= =A0"MAY", and
=C2=A0 =C2=A0 =C2=A0 "OPTIONAL"= in this document are to be interpreted as described in
=C2=A0 = =C2=A0 =C2=A0 RFC 2119 when capitalised.

=C2= =A0
=C2=A0 =C2=A0john


>





--089e01160950236d26052f30418c-- From nobody Tue Mar 29 09:38:13 2016 Return-Path: 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 E380E12D83E; Tue, 29 Mar 2016 07:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 Nk7DR4KZsB21; Tue, 29 Mar 2016 07:18:35 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3577812D856; Tue, 29 Mar 2016 07:18:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 03F991E5D6A; Tue, 29 Mar 2016 07:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iW1F4vbELxhw; Tue, 29 Mar 2016 07:17:47 -0700 (PDT) Received: from Heathers-MacBook-Pro.local (unknown [98.125.209.239]) by c8a.amsl.com (Postfix) with ESMTPSA id AA46B1E5D68; Tue, 29 Mar 2016 07:17:47 -0700 (PDT) References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> From: "Heather Flanagan (RFC Series Editor)" Message-ID: <56FA8EB8.5050701@rfc-editor.org> Date: Tue, 29 Mar 2016 07:18:32 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <56F98CD1.10706@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Tue, 29 Mar 2016 09:38:06 -0700 Cc: "rtcweb@ietf.org" , IETF discussion list , IESG Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 14:18:37 -0000 On 3/28/16 12:58 PM, Brian E Carpenter wrote: > There are times when I think RFC2119 was a really bad idea, despite it having > become probably the most frequently cited RFC (inside and outside the IETF). > It seems to create as much confusion as it avoids. > > There are four words whose RFC2119 meaning is different from the dictionary > meaning: should, recommended, may and optional. Having special typography > for them is useful, because it signals the RFC2119 meanings. But if a spec > uses, for example, a mixture of SHOULD and should, who knows what the authors > intended? To that extent, the proposed clarification is helpful. > > The other words (must, shall, required, not) mean what they always mean. > The only argument for upper-casing them is aesthetic symmetry. If a spec > uses alternatives like mandatory, necessary or forbidden, they are just as > powerful. > > So >> these definitions are only meaningful if the words are capitalized > can be applied to should, recommended, may and optional if we want, > but strictly doesn't apply to must, shall, required, not, mandatory, > necessary, forbidden, need, or any other such words. > > Where we can get into real trouble is if a spec contains should, recommended, > may and optional *plus* other non-categorical (fuzzy) words like ought, > encourage, suggest, can, might, allowed, permit (and I did not pull those > words out of the air, but out of draft-hansen-nonkeywords-non2119). What do > they mean? It can be very unclear. If a node receives a message containing > an element covered in the spec by "allowed" instead of "OPTIONAL", is the > receiver supposed to interoperate or to reject the message? > > If we are issuing guidance, it should probably include a specific warning > to use any such fuzzy words with extreme care. I've been watching this thread and am thrilled to see these clarifications coming through. Changes to RFC 2219 are a community decision, not an RFC Editor decision, but the RFC Editor definitely appreciates consistency and clarity! -Heather > Brian > On 29/03/2016 03:13, Scott O. Bradner wrote: >> one minor tweak >> >>> On Mar 28, 2016, at 10:09 AM, Barry Leiba wrote: >>> >>>> The wishy washy descriptive rather than proscriptive language in the abstract was because I, >>>> the IESG and the community were not of one mind to say that the use of such capitalized >>>> terms should be mandatory - quite a few people felt that the english language was at >>>> least good enough to convey the writer’s intent without having to aggrandize specific words. >>>> Thus the abstract basically was saying: if you want to use capitalized words here is a standard >>>> way to say what they mean >>> Ah. Then perhaps the clarification needs to go a little further and >>> make this clear: >>> - We're defining specific terms that specifications can use. >>> - These terms are always capitalized when these definitions are used. >> these definitions are only meaningful if the words are capitalized >> >>> - You don't have to use them. If you do, they're capitalized and >>> their meanings are as specified here. >>> - There are similar-looking English words that are not capitalized, >>> and they have their normal English meanings; this document has nothing >>> to do with them. >>> >>> ...and I'd like to add one more, because so many people think that >>> text isn't normative unless it has 2119 key words in all caps in it: >>> >>> - Normative text doesn't require the use of these key words. They're >>> used for clarity and consistency when you want that, but lots of >>> normative text doesn't need to use them, and doesn't use them. >>> >>> Barry >> From nobody Tue Mar 29 09:45:41 2016 Return-Path: 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 28AC812DA89 for ; Tue, 29 Mar 2016 09:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net 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 2lMOWlqSWTWb for ; Tue, 29 Mar 2016 09:45:35 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285DF12D8A8 for ; Tue, 29 Mar 2016 09:36:13 -0700 (PDT) Received: by mail-ig0-x22c.google.com with SMTP id cl4so80338254igb.0 for ; Tue, 29 Mar 2016 09:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=aHKewfvqwRYeDUuJi7/etEEPOSTnHoqpKarvmCRvxIQ=; b=LR0g320JvCzt52fMnfomI2t52ZN4SeBoCXkY0N8X8XNqujT6FnoW4iAUFFc+evcGVl UKmi3FCpWc+wnR4SIr982Aork9u4FPoz4wZQc3UOho5J4QXFA/dyAAQ/FV4cG3fUtkbH G7QpKdQWwzXv9b98Tx1RkvrEIp7UkleObkXhs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=aHKewfvqwRYeDUuJi7/etEEPOSTnHoqpKarvmCRvxIQ=; b=EgMHOgORKSeM82g/RhOr2cEhJh7cADTSgHgewr0uc8noD+XNaxiLO3tO/UIT6PYDQM jzLo7Am+IweX3J2Ir55sS0uc4WC9hPp3pgGoHaMUs3Q2aRocNo8Zu3zm4fmFRXBV2i2r xCq9u0GksBpYgWkLdmfjte9Af7m+kNmUmp7e4WPjCj7GGyfD/XI3ZpJoOL76wT8yLzEC rhq6ZUBdA63M5EducSk4UcUH1EgEE0HbaNWxHbFC4LpDYMNDCH1NSwI6Lrvt2L8BbBRB ofyhdnacdk2JURKr3iNJWb+QfoFe3HwU0cPKdwaknHuM0YjnzoNR7DpEhFB7eQwXU7MB DsNg== X-Gm-Message-State: AD7BkJL47OMBZw16w+aM6X20Jq9HNPA8mM/a2j9Vqq0GMw7UQtoEY5N60KgRiqKAbFeVP9rXLZ7QPwB62Rmbak21 MIME-Version: 1.0 X-Received: by 10.50.30.73 with SMTP id q9mr17604421igh.77.1459269373060; Tue, 29 Mar 2016 09:36:13 -0700 (PDT) Received: by 10.107.181.5 with HTTP; Tue, 29 Mar 2016 09:36:12 -0700 (PDT) In-Reply-To: <82156918-B008-479C-BC6E-7A54930820D8@att.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> <82156918-B008-479C-BC6E-7A54930820D8@att.com> Date: Tue, 29 Mar 2016 17:36:12 +0100 Message-ID: From: Dave Cridland To: "HANSEN, TONY L" Content-Type: multipart/alternative; boundary=047d7bdc0a849d0837052f32a04f Archived-At: Cc: "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IETF discussion list , IESG Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 16:45:37 -0000 --047d7bdc0a849d0837052f32a04f Content-Type: text/plain; charset=UTF-8 On 29 March 2016 at 16:26, HANSEN, TONY L wrote: > I also feel that a modified version of the RFC 2119 statement should be > defined and specified in a small RFC. > > I like Dave's addition, but also think adding the word "only" is worth > doing: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > RFC 2119 only when capitalised. > > Leaving out the "only" still leaves the statement (slightly) ambiguous; > it's the same as the difference between "if" and "if and only if". > > I agree that's an improvement. > - Tony Hansen > > From: ietf on behalf of Dave Cridland < > dave@cridland.net> > Date: Tuesday, March 29, 2016 at 9:46 AM > To: John C Klensin > Cc: IETF discussion list , "Heather Flanagan (RFC Series > Editor)" , "rtcweb@ietf.org" , IESG < > iesg@ietf.org>, Barry Leiba > Subject: Re: Fuzzy words [was Uppercase question for RFC2119 words] > > . . . > Agreed, but we should (ought to, probably wish to, etc) consider a > replacement for the following: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > RFC 2119. > > Perhaps simply: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in > RFC 2119 when capitalised. > > > --047d7bdc0a849d0837052f32a04f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 29 March 2016 at 16:26, HANSEN, TONY L <tony@att.com> wrot= e:
I also feel that a modified version of the RFC 2119 statement should b= e defined and specified in a small RFC.

I like Dave's addition, but also think adding the word "only&= quot; is worth doing:

=C2=A0 =C2=A0 =C2=A0 The key words "MUST", "MUST NOT&qu= ot;, "REQUIRED", "SHALL", "SHALL
=C2=A0 =C2=A0 =C2=A0 NOT", "SHOULD", "SHOULD NOT&q= uot;, "RECOMMENDED", =C2=A0"MAY", and
=C2=A0 =C2=A0 =C2=A0 "OPTIONAL" in this document are to be i= nterpreted as described in
=C2=A0 =C2=A0 =C2=A0 RFC 2119 only when capitalised.

Leaving out the "only" still leaves the statement (slightly)= ambiguous; it's the same as the difference between "if" and = "if and only if".


I agree that= 9;s an improvement.
=C2=A0
- Tony Hansen

From: ietf <ietf-bounces@ietf.org> on beh= alf of Dave Cridland <dave@cridland.net>
Date: Tuesday, March 29, 2016 at 9:= 46 AM
To: John C Klensin <john-ietf@jck.com>
Cc: IETF discussion list <ietf@ietf.org>, "H= eather Flanagan (RFC Series Editor)" <rse@rfc-editor.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>, IESG <iesg@ie= tf.org>, Barry Leiba <barryleiba@computer.org>
Subject: Re: Fuzzy words [was Upper= case question for RFC2119 words]

. . .
Agreed, but we should (ought to, probably wish to, etc) consider a rep= lacement for the following:

=C2=A0 =C2=A0 =C2=A0 The key words "MUST", "MUST NOT&qu= ot;, "REQUIRED", "SHALL", "SHALL
=C2=A0 =C2=A0 =C2=A0 NOT", "SHOULD", "SHOULD NOT&q= uot;, "RECOMMENDED", =C2=A0"MAY", and
=C2=A0 =C2=A0 =C2=A0 "OPTIONAL" in this document are to be i= nterpreted as described in
=C2=A0 =C2=A0 =C2=A0 RFC 2119.

Perhaps simply:

=C2=A0 =C2=A0 =C2=A0 The key words "MUST", "MUST NOT&qu= ot;, "REQUIRED", "SHALL", "SHALL
=C2=A0 =C2=A0 =C2=A0 NOT", "SHOULD", "SHOULD NOT&q= uot;, "RECOMMENDED", =C2=A0"MAY", and
=C2=A0 =C2=A0 =C2=A0 "OPTIONAL" in this document are to be i= nterpreted as described in
=C2=A0 =C2=A0 =C2=A0 RFC 2119 when capitalised.

=C2=A0

--047d7bdc0a849d0837052f32a04f-- From nobody Tue Mar 29 11:43:05 2016 Return-Path: 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 0A03212E078; Tue, 29 Mar 2016 11:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001] 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 N27K55m2sUbi; Tue, 29 Mar 2016 11:42:54 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 492CE12E12A; Tue, 29 Mar 2016 11:12:00 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id u2TIAHac015896; Tue, 29 Mar 2016 14:11:55 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 21yx2v3714-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Mar 2016 14:11:55 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u2TIBrdS001482; Tue, 29 Mar 2016 14:11:54 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u2TIBg67001283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Mar 2016 14:11:46 -0400 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Tue, 29 Mar 2016 18:11:31 GMT Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.206]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0248.002; Tue, 29 Mar 2016 14:11:31 -0400 From: "HANSEN, TONY L" To: Tony Finch , Brian E Carpenter Thread-Topic: Fuzzy words [was Uppercase question for RFC2119 words] Thread-Index: AQHRiSw5ggBRfU2Eq0+VtUQm5kw+4p9whGmAgAA2FYA= Date: Tue, 29 Mar 2016 18:11:31 +0000 Message-ID: <243C17B6-48AF-469A-B93E-F9FCB8708025@att.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.110.240.227] Content-Type: text/plain; charset="utf-8" Content-ID: <4611095441F9E444A5BF638C112CD3E4@LOCAL> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-29_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1601100000 definitions=main-1603290264 Archived-At: Cc: "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IETF discussion list , Barry Leiba , IESG Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 18:42:56 -0000 T24gMy8yOS8xNiwgNjo1NyBBTSwgImlldGYgb24gYmVoYWxmIG9mIFRvbnkgRmluY2giIDxpZXRm LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGRvdEBkb3RhdC5hdD4gd3JvdGU6DQoNCg0K PkJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0K Pg0KPj4gQnV0IGlmIGEgc3BlYyB1c2VzLCBmb3IgZXhhbXBsZSwgYSBtaXh0dXJlIG9mIFNIT1VM RCBhbmQgc2hvdWxkLCB3aG8NCj4+IGtub3dzIHdoYXQgdGhlIGF1dGhvcnMgaW50ZW5kZWQ/IFRv IHRoYXQgZXh0ZW50LCB0aGUgcHJvcG9zZWQNCj4+IGNsYXJpZmljYXRpb24gaXMgaGVscGZ1bC4N Cj4NCj5JIHRoaW5rIGlmIGEgZG9jdW1lbnQgdXNlcyBSRkMgMjExOSBrZXl3b3JkcyB0aGVuIGl0 IG91Z2h0IHRvIGF2b2lkDQo+bm9uLWNhcGl0YWxpemVkIHVzZXMgb2YgdGhlIGtleXdvcmRzLCBl LmcuIGJ5IHJlcGxhY2luZyAic2hvdWxkIiB3aXRoDQo+Im91Z2h0IHRvIiBvciBvdGhlciByZXBo cmFzaW5ncy4NCj4NCj5Ub255Lg0KDQpDdWUgcmVmZXJlbmNlIHRvICJkcmFmdC1oYW5zZW4tbm9u a2V5d29yZHMtbm9uMjExOSIgOi0pDQoNCglUb255IEhhbnNlbg0KDQo= From nobody Tue Mar 29 14:02:41 2016 Return-Path: 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 931E312E137; Tue, 29 Mar 2016 13:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 3mo4xCDrF_bc; Tue, 29 Mar 2016 13:40:04 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0721112DB81; Tue, 29 Mar 2016 13:03:27 -0700 (PDT) Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1akzrD-000KQ1-HR; Tue, 29 Mar 2016 16:03:19 -0400 Date: Tue, 29 Mar 2016 16:03:14 -0400 From: John C Klensin To: "HANSEN, TONY L" , Tony Finch , Brian E Carpenter Message-ID: <8A6F6C42D7498952A293824E@JcK-HP8200.jck.com> In-Reply-To: <243C17B6-48AF-469A-B93E-F9FCB8708025@att.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> <243C17B6-48AF-469A-B93E-F9FCB8708025@att.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: X-Mailman-Approved-At: Tue, 29 Mar 2016 14:02:39 -0700 Cc: "Heather Flanagan \(RFC Series Editor\)" , rtcweb@ietf.org, IETF discussion list , Barry Leiba , IESG Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 20:40:05 -0000 --On Tuesday, March 29, 2016 18:11 +0000 "HANSEN, TONY L" wrote: > On 3/29/16, 6:57 AM, "ietf on behalf of Tony Finch" > wrote: > > >> Brian E Carpenter wrote: >> >>> But if a spec uses, for example, a mixture of SHOULD and >>> should, who knows what the authors intended? To that extent, >>> the proposed clarification is helpful. >> >> I think if a document uses RFC 2119 keywords then it ought to >> avoid non-capitalized uses of the keywords, e.g. by replacing >> "should" with "ought to" or other rephrasings. >> >> Tony. > > Cue reference to "draft-hansen-nonkeywords-non2119" :-) Tony (and Tony), it seems to me that raises a fundamental issue in editorial philosophy and style as well as some human factors issues... the latter especially for readers who have to translate (if only in their heads) between English and whatever language they "think in". I just don't know whether it is possible to fix/adjust 2119 without resolving it. There are, I think, two almost-separate problems. The first is that 2119, presumably in the interest of smooth and elegant writing and phrasing, defined and therefore preempted not only MUST, SHOULD, MAY, MUST NOT, SHOULD NOT, but several of the obvious synonyms. Had it not done that, it would have been possible to say "for IETF purposes, these are not synonyms, their meanings are different, and upper-case is just a convenience for emphasis". But those obvious synonyms are gone too, so that avoiding the non-normative versions of the terms requires some rather awkward circumlocutions as, IMO, some of the recommendations of draft-hansen-nonkeywords-non2119 rather painfully illustrates. If you want to understand how painful, pick a non-English language with with you or one of your colleagues is familiar, a language that is not closely related to English in vocabulary and semantics (i.e., not either a Germanic or a Romance language), and then toss the text of a standard with the terms recommended in your I-D mechanically substituted for the normative 2119 terms into the widely-available automatic translation tool of your choice. I've tried an experiment or two like that; the results were, IMO, appalling but YMMD. So I just don't see that as a viable solution unless you want to make writing clear I-Ds really difficult (and Heather and the Production Center are willing to let those awkward constructions make it into RFCs). Again, this is partially a philosophical disagreement, so I recognize that there are other points of view. best, john From nobody Tue Mar 29 14:41:52 2016 Return-Path: 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 883B712D147; Tue, 29 Mar 2016 14:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 6n6ILuYhe4D5; Tue, 29 Mar 2016 14:09:54 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AED6912D55E; Tue, 29 Mar 2016 13:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3175; q=dns/txt; s=iport; t=1459284237; x=1460493837; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=6N0LlT0svnJcfbLLR4y5ox7kvZV21Topc7b3rdfYFts=; b=RrDJTDqdfuqw1rzAA3iyTLmd6ROEIHUt1gkwZ1xkqqEw1pZGZMBkGud9 TBKH0impNLwaqf2kmEa6TEHVjyAbxLO/63fE5Tq/g8vMwp29SUknOJytM 0J1aW4SQedmd2hUQsXPkVOBLIF4DhvX4xV8vV2fKG47g9QtV4UH5sPZFW s=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBABn6PpW/xbLJq1dwgCGDQKCBwEBA?= =?us-ascii?q?QEBAWUnhEIBAQMBI1UBBQsLIRYLAgIJAwIBAgFFBgEMCAEBiBsIry6QXQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEPCIphgTeGBoJWAQSXbIMfgWaJAok4hVWPD2KCAw0Mg?= =?us-ascii?q?Us6iG8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,412,1454976000"; d="asc'?scan'208";a="636640169" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Mar 2016 20:43:54 +0000 Received: from [10.61.85.133] (ams3-vpn-dhcp5510.cisco.com [10.61.85.133]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u2TKhrrW008068; Tue, 29 Mar 2016 20:43:54 GMT To: Brian E Carpenter , "Scott O. Bradner" , Barry Leiba References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> From: Eliot Lear Message-ID: <56FAE909.2080805@cisco.com> Date: Tue, 29 Mar 2016 22:43:53 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F98CD1.10706@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WdcCbSefVTM5fxn0bU483e39Nas0Wppdi" Archived-At: X-Mailman-Approved-At: Tue, 29 Mar 2016 14:41:50 -0700 Cc: "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IETF discussion list , IESG Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 21:09:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WdcCbSefVTM5fxn0bU483e39Nas0Wppdi Content-Type: multipart/mixed; boundary="bcc0u7M5GUs5jqpHklv8IuQUJO2tqlp12" From: Eliot Lear To: Brian E Carpenter , "Scott O. Bradner" , Barry Leiba Cc: "Heather Flanagan (RFC Series Editor)" , "rtcweb@ietf.org" , IETF discussion list , IESG Message-ID: <56FAE909.2080805@cisco.com> Subject: Re: Fuzzy words [was Uppercase question for RFC2119 words] References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> In-Reply-To: <56F98CD1.10706@gmail.com> --bcc0u7M5GUs5jqpHklv8IuQUJO2tqlp12 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/28/16 9:58 PM, Brian E Carpenter wrote: > Where we can get into real trouble is if a spec contains should, recomm= ended, > may and optional *plus* other non-categorical (fuzzy) words like ought,= > encourage, suggest, can, might, allowed, permit (and I did not pull tho= se > words out of the air, but out of draft-hansen-nonkeywords-non2119). Wha= t do > they mean? It can be very unclear. If a node receives a message contain= ing > an element covered in the spec by "allowed" instead of "OPTIONAL", is t= he > receiver supposed to interoperate or to reject the message? Yes, this. There seems to be a sort of MUSTSHOULDMAYphobia. The contortions some people will go through to avoid the words when that is what they mean is, at times, hilarious; but at other times harmful to interoperability. Eliot --bcc0u7M5GUs5jqpHklv8IuQUJO2tqlp12-- --WdcCbSefVTM5fxn0bU483e39Nas0Wppdi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJW+ukJAAoJEIe2a0bZ0nozA4UH/Rl1dXH9+uv2D4i6ka3oKCxD QrF4dKYkomn7bANoCn9KECpef+/4Essj7N/2t6OaFPFDzUjC4mzcKa8Vh42suWTp WOHeKZFBrVEOXJFqsfPF/r+ZVL8OuDZDFdPzz9rq5ZmmHTZXBJOyNOLLOoaqLqH8 DQjQyZF0QRbs/gaToB+WuDqoiXld2b+0VtIsO8KezI2VVx0ijiwRafRpOGnqEe5y fnTyP2npMW25mRCGk60WUQpE/rRsY4DxuFfvQZ3OmwLKOiuNv9XeNzOe/B7XDUWj /AVF/kgVlmVz1a6DBd3l6cpg4+l01ra0M/16L+b6RltIf6t10FwT0eVae5bCOv4= =tvQE -----END PGP SIGNATURE----- --WdcCbSefVTM5fxn0bU483e39Nas0Wppdi-- From nobody Tue Mar 29 16:39:21 2016 Return-Path: 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 9F42212D57B; Tue, 29 Mar 2016 16:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7rtsx2BnC26T; Tue, 29 Mar 2016 16:39:12 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E67A12D0BE; Tue, 29 Mar 2016 16:39:11 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id n5so26736870pfn.2; Tue, 29 Mar 2016 16:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=7r9wHYQ8r86b+wwmG3T/CGrRi1ZiTd4SqkLH5FfN/VI=; b=m8Tnkv+9b4pDUeFILU1PADbA6/v5iQF6XOAPoAZXcfOeMwcBLYfJ8wY7zE36TkAdDG eIgGAczQ8HZ5/rEO8eUf5cZcz54C4qcbf15wC+697rL+uDpGZnWT3Llg/A7uHJg6ull2 IEkkZei7WPOeWf1lE+OSLlijivVHQWNOAVzXTi2MuuIV5mkwDOOsfTVaS1snoySmYfnV vRU8bPhhANEnHf0AW+lNEV6eLpbYgSwQRdjVwvUx3Kkk4sC3AGYeWuR/iputffMFh1nn leyy505O4rgF12imjbuZtqUWT6shNV7rIt9wnk8FElAMTz6z0McGbjp8c8nWy4hFri/j hp0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=7r9wHYQ8r86b+wwmG3T/CGrRi1ZiTd4SqkLH5FfN/VI=; b=Qg55O7aaUBXZiV75pB4SOcO8JtY9Drp1Q1TV6SZDWdC7F5s8K5o4tYD30uSR8MhKoo yc41Iphb4XqviDdlpTdahyaUSsm1ZW4img7jo6MxGRC9/akLy7eZgbY8n6apOtud/7AF 69vzAYO0NZ6Q+AONHILyeWlWncQftM8MBrYDP4FY78sZ9wqGA09mc1l/iB6L9gB05G3r PI2ikenPMGObnizZrlu1tnyR8TpgTdIihbw5yJESDi1K0Fugqz0yS0VKmti6EjN91XI/ zuYVjtAfjaCEhIwxISbJrEd3rSO/8N4zW04WvO3YnueB08iicv3quwmhjaMrsLzTrD4V lf+Q== X-Gm-Message-State: AD7BkJJ+x0laP1GZU965LNkRmZUqw8l/fYeH8ZBhsUB2XfGuZ8d5KvAT1AmXUTfcq/FNCg== X-Received: by 10.98.14.67 with SMTP id w64mr7804800pfi.154.1459294751426; Tue, 29 Mar 2016 16:39:11 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id kw10sm887644pab.0.2016.03.29.16.39.07 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2016 16:39:10 -0700 (PDT) To: Scott Bradner , Barry Leiba References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56FB121E.6070900@gmail.com> Date: Wed, 30 Mar 2016 12:39:10 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IETF discussion list , IESG Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 23:39:14 -0000 On 30/03/2016 00:27, Scott Bradner wrote: > fwiw - seems to me that the basic idea that MUST and must are the same = is wrong I disagree, specifically for MUST, SHALL, REQUIRED and NOT. RFC2119 doesn't change their meanings, because their meanings are categorical anyway. It's absolutely appropriate that RFC 2119 states their meanings, but they aren't ambiguous. > and will lead to > even more confusion >=20 > imo - any clarification should (not SHOULD - i.e. the english language)= say > 1/ some authors capitalize some words for emphasis and clarity > 2/ there is no requirement to use capitalized words=20 > 2/ when capitalized words are used RFC 2119 says what the capitalized = words mean > 3/ non capitalized words are interpreted using normal English=20 That is a change, because 2119 does not say point 3/. I'm not saying it's a bad change, but it really is a change, affecting SHOULD and MAY in particular. Honestly I don't think any of this will change the questions I sometimes have for authors, basically "Should that 'should' be 'SHOULD'?" "Should that 'may/MAY' be 'might'?" Brian >=20 > Scott >=20 >> On Mar 28, 2016, at 4:30 PM, Barry Leiba wro= te: >> >> Brian, I think your note goes to how important it is to write clearly >> and to get a lot of eyes on it before we publish it. Well-written >> documents, with or without 2119 key words, and with or without >> lower-case look-alikes, can still be clear. Fuzzily written documents= >> will be fuzzy. >> >> In particular: >> >>> they mean? It can be very unclear. If a node receives a message conta= ining >>> an element covered in the spec by "allowed" instead of "OPTIONAL", is= the >>> receiver supposed to interoperate or to reject the message? >> >> Well, this is where 2119 advises that we *use* the key words when >> interoperability is at stake. It's fine to be fuzzy when it doesn't >> matter, though even then, I'd argue for more explanation: >> >> Every frobotz MUST contain a valid bleeg. The glorp field in the >> frobotz is an unsigned integer that is normally between 0 and 666, >> inclusive. Values greater than 666 are allowed, but recipients >> using older software might not be able to handle such values. >> ... >> When processing a frobotz that does not meet the requirements in >> section 3.1.4, it is permissible to reject the frobotz outright, or = to >> attempt to process the parts of it that make sense; the choice is >> an implementation decision. However, any frobotz that does not >> contain a valid bleeg MUST be rejected. >> >> That sort of thing. >> >> Barry >> >> On Mon, Mar 28, 2016 at 3:58 PM, Brian E Carpenter >> wrote: >>> There are times when I think RFC2119 was a really bad idea, despite i= t having >>> become probably the most frequently cited RFC (inside and outside the= IETF). >>> It seems to create as much confusion as it avoids. >>> >>> There are four words whose RFC2119 meaning is different from the dict= ionary >>> meaning: should, recommended, may and optional. Having special typogr= aphy >>> for them is useful, because it signals the RFC2119 meanings. But if a= spec >>> uses, for example, a mixture of SHOULD and should, who knows what the= authors >>> intended? To that extent, the proposed clarification is helpful. >>> >>> The other words (must, shall, required, not) mean what they always me= an. >>> The only argument for upper-casing them is aesthetic symmetry. If a s= pec >>> uses alternatives like mandatory, necessary or forbidden, they are ju= st as >>> powerful. >>> >>> So >>>> these definitions are only meaningful if the words are capitalized >>> can be applied to should, recommended, may and optional if we want, >>> but strictly doesn't apply to must, shall, required, not, mandatory, >>> necessary, forbidden, need, or any other such words. >>> >>> Where we can get into real trouble is if a spec contains should, reco= mmended, >>> may and optional *plus* other non-categorical (fuzzy) words like ough= t, >>> encourage, suggest, can, might, allowed, permit (and I did not pull t= hose >>> words out of the air, but out of draft-hansen-nonkeywords-non2119). W= hat do >>> they mean? It can be very unclear. If a node receives a message conta= ining >>> an element covered in the spec by "allowed" instead of "OPTIONAL", is= the >>> receiver supposed to interoperate or to reject the message? >>> >>> If we are issuing guidance, it should probably include a specific war= ning >>> to use any such fuzzy words with extreme care. >>> >>> Brian >>> On 29/03/2016 03:13, Scott O. Bradner wrote: >>>> one minor tweak >>>> >>>>> On Mar 28, 2016, at 10:09 AM, Barry Leiba = wrote: >>>>> >>>>>> The wishy washy descriptive rather than proscriptive language in t= he abstract was because I, >>>>>> the IESG and the community were not of one mind to say that the us= e of such capitalized >>>>>> terms should be mandatory - quite a few people felt that the engli= sh language was at >>>>>> least good enough to convey the writer=E2=80=99s intent without h= aving to aggrandize specific words. >>>>>> Thus the abstract basically was saying: if you want to use capital= ized words here is a standard >>>>>> way to say what they mean >>>>> >>>>> Ah. Then perhaps the clarification needs to go a little further an= d >>>>> make this clear: >>>>> - We're defining specific terms that specifications can use. >>>>> - These terms are always capitalized when these definitions are use= d. >>>> >>>> these definitions are only meaningful if the words are capitalized >>>> >>>>> - You don't have to use them. If you do, they're capitalized and >>>>> their meanings are as specified here. >>>>> - There are similar-looking English words that are not capitalized,= >>>>> and they have their normal English meanings; this document has noth= ing >>>>> to do with them. >>>>> >>>>> ...and I'd like to add one more, because so many people think that >>>>> text isn't normative unless it has 2119 key words in all caps in it= : >>>>> >>>>> - Normative text doesn't require the use of these key words. They'= re >>>>> used for clarity and consistency when you want that, but lots of >>>>> normative text doesn't need to use them, and doesn't use them. >>>>> >>>>> Barry >>>> >>>> >>> >=20 >=20 From nobody Tue Mar 29 16:43:10 2016 Return-Path: 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 947ED12D0E0; Tue, 29 Mar 2016 16:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 DWtthuFbHoey; Tue, 29 Mar 2016 16:43:05 -0700 (PDT) Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFBC112D0C7; Tue, 29 Mar 2016 16:43:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id 13D391A31DDF; Tue, 29 Mar 2016 19:43:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at sobco.com Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yqd6lfzZjgJD; Tue, 29 Mar 2016 19:43:02 -0400 (EDT) Received: from golem.sobco.com (golem.sobco.com [136.248.127.162]) by sobco.sobco.com (Postfix) with ESMTPSA id 647381A31DCF; Tue, 29 Mar 2016 19:43:02 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Scott O. Bradner" In-Reply-To: <56FB121E.6070900@gmail.com> Date: Tue, 29 Mar 2016 19:43:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> <56FB121E.6070900@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Heather Flanagan \(RFC Series Editor\)" , Barry Leiba , "rtcweb@ietf.org" , IETF discussion list , IESG Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 23:43:06 -0000 yup - it is a change, one that might help against the people that say = 2119 MUST be used all the time but it will not address the examples you cite Scott > On Mar 29, 2016, at 7:39 PM, Brian E Carpenter = wrote: >=20 > On 30/03/2016 00:27, Scott Bradner wrote: >> fwiw - seems to me that the basic idea that MUST and must are the = same is wrong >=20 > I disagree, specifically for MUST, SHALL, REQUIRED and NOT. RFC2119 > doesn't change their meanings, because their meanings are categorical > anyway. It's absolutely appropriate that RFC 2119 states their = meanings, > but they aren't ambiguous. >=20 >> and will lead to >> even more confusion >>=20 >> imo - any clarification should (not SHOULD - i.e. the english = language) say >> 1/ some authors capitalize some words for emphasis and clarity >> 2/ there is no requirement to use capitalized words=20 >> 2/ when capitalized words are used RFC 2119 says what the = capitalized words mean >> 3/ non capitalized words are interpreted using normal English=20 >=20 > That is a change, because 2119 does not say point 3/. I'm not saying > it's a bad change, but it really is a change, affecting SHOULD and MAY > in particular. >=20 > Honestly I don't think any of this will change the questions I = sometimes > have for authors, basically > "Should that 'should' be 'SHOULD'?" > "Should that 'may/MAY' be 'might'?" >=20 > Brian >=20 >>=20 >> Scott >>=20 >>> On Mar 28, 2016, at 4:30 PM, Barry Leiba = wrote: >>>=20 >>> Brian, I think your note goes to how important it is to write = clearly >>> and to get a lot of eyes on it before we publish it. Well-written >>> documents, with or without 2119 key words, and with or without >>> lower-case look-alikes, can still be clear. Fuzzily written = documents >>> will be fuzzy. >>>=20 >>> In particular: >>>=20 >>>> they mean? It can be very unclear. If a node receives a message = containing >>>> an element covered in the spec by "allowed" instead of "OPTIONAL", = is the >>>> receiver supposed to interoperate or to reject the message? >>>=20 >>> Well, this is where 2119 advises that we *use* the key words when >>> interoperability is at stake. It's fine to be fuzzy when it doesn't >>> matter, though even then, I'd argue for more explanation: >>>=20 >>> Every frobotz MUST contain a valid bleeg. The glorp field in the >>> frobotz is an unsigned integer that is normally between 0 and 666, >>> inclusive. Values greater than 666 are allowed, but recipients >>> using older software might not be able to handle such values. >>> ... >>> When processing a frobotz that does not meet the requirements in >>> section 3.1.4, it is permissible to reject the frobotz outright, or = to >>> attempt to process the parts of it that make sense; the choice is >>> an implementation decision. However, any frobotz that does not >>> contain a valid bleeg MUST be rejected. >>>=20 >>> That sort of thing. >>>=20 >>> Barry >>>=20 >>> On Mon, Mar 28, 2016 at 3:58 PM, Brian E Carpenter >>> wrote: >>>> There are times when I think RFC2119 was a really bad idea, despite = it having >>>> become probably the most frequently cited RFC (inside and outside = the IETF). >>>> It seems to create as much confusion as it avoids. >>>>=20 >>>> There are four words whose RFC2119 meaning is different from the = dictionary >>>> meaning: should, recommended, may and optional. Having special = typography >>>> for them is useful, because it signals the RFC2119 meanings. But if = a spec >>>> uses, for example, a mixture of SHOULD and should, who knows what = the authors >>>> intended? To that extent, the proposed clarification is helpful. >>>>=20 >>>> The other words (must, shall, required, not) mean what they always = mean. >>>> The only argument for upper-casing them is aesthetic symmetry. If a = spec >>>> uses alternatives like mandatory, necessary or forbidden, they are = just as >>>> powerful. >>>>=20 >>>> So >>>>> these definitions are only meaningful if the words are capitalized >>>> can be applied to should, recommended, may and optional if we want, >>>> but strictly doesn't apply to must, shall, required, not, = mandatory, >>>> necessary, forbidden, need, or any other such words. >>>>=20 >>>> Where we can get into real trouble is if a spec contains should, = recommended, >>>> may and optional *plus* other non-categorical (fuzzy) words like = ought, >>>> encourage, suggest, can, might, allowed, permit (and I did not pull = those >>>> words out of the air, but out of draft-hansen-nonkeywords-non2119). = What do >>>> they mean? It can be very unclear. If a node receives a message = containing >>>> an element covered in the spec by "allowed" instead of "OPTIONAL", = is the >>>> receiver supposed to interoperate or to reject the message? >>>>=20 >>>> If we are issuing guidance, it should probably include a specific = warning >>>> to use any such fuzzy words with extreme care. >>>>=20 >>>> Brian >>>> On 29/03/2016 03:13, Scott O. Bradner wrote: >>>>> one minor tweak >>>>>=20 >>>>>> On Mar 28, 2016, at 10:09 AM, Barry Leiba = wrote: >>>>>>=20 >>>>>>> The wishy washy descriptive rather than proscriptive language in = the abstract was because I, >>>>>>> the IESG and the community were not of one mind to say that the = use of such capitalized >>>>>>> terms should be mandatory - quite a few people felt that the = english language was at >>>>>>> least good enough to convey the writer=E2=80=99s intent without = having to aggrandize specific words. >>>>>>> Thus the abstract basically was saying: if you want to use = capitalized words here is a standard >>>>>>> way to say what they mean >>>>>>=20 >>>>>> Ah. Then perhaps the clarification needs to go a little further = and >>>>>> make this clear: >>>>>> - We're defining specific terms that specifications can use. >>>>>> - These terms are always capitalized when these definitions are = used. >>>>>=20 >>>>> these definitions are only meaningful if the words are capitalized >>>>>=20 >>>>>> - You don't have to use them. If you do, they're capitalized and >>>>>> their meanings are as specified here. >>>>>> - There are similar-looking English words that are not = capitalized, >>>>>> and they have their normal English meanings; this document has = nothing >>>>>> to do with them. >>>>>>=20 >>>>>> ...and I'd like to add one more, because so many people think = that >>>>>> text isn't normative unless it has 2119 key words in all caps in = it: >>>>>>=20 >>>>>> - Normative text doesn't require the use of these key words. = They're >>>>>> used for clarity and consistency when you want that, but lots of >>>>>> normative text doesn't need to use them, and doesn't use them. >>>>>>=20 >>>>>> Barry >>>>>=20 >>>>>=20 >>>>=20 >>=20 >>=20 >=20 From nobody Tue Mar 29 16:52:43 2016 Return-Path: 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 7090012DB67; Tue, 29 Mar 2016 16:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 1UnGqyWIvuRA; Tue, 29 Mar 2016 16:52:41 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0700112DB66; Tue, 29 Mar 2016 16:52:41 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id 4so27047955pfd.0; Tue, 29 Mar 2016 16:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=6AN2jdQRz7Q0HUALiBbaJaDBBYQn9YJxkVX8uZCkg5o=; b=tCQ1D2jekmAHM66kh5hmMvqiL5r6itWKJ/w5juyziosG/edcry4COf84kUXKnNoxoF bxrfQTWqk4zHivDsFm5z27sjWH5kXlsAixssxzqgg/dbflUkIBgkNDLLouNV76BOFNW1 BCKQEMRG3j96dtFyK0K1kAjaJ0vAAYpfPwuugnsnsUjWSTqOPVoJXQLxz6LXISDMcPR7 TU0IMnQX1ttiWcdkYGpZxQDQ8FUlP7AaTKncUnPwioFpdS6Q9+rQ7H/fN2cb8XDkOk2T xQFitl4Vz+JcHamsSGd9Dlpx/qhu6fJmQWI+6vzCsnHCX3pMNYT2OYT1Ch5ggkbmFso2 NUjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=6AN2jdQRz7Q0HUALiBbaJaDBBYQn9YJxkVX8uZCkg5o=; b=FdFEi8QMPQAckjvkq2vEDH9aEOOgiI97Uk+h+uuEWlfoEuWlM9ckH4fbsbzqboeCmI 4x8CLZxRh295dAPTgDl2FSEhlSba2OQm+Ow3VTlSlTSxDSV+tICEYIFosk5KY0pwqNV0 SYC8ngPxxHYbHmMP/CWrXFxkCqF4tgx+8ZiiDFjwFX1QnbII0kQ0MObOd3nw3cEq7j5l dLdCJQM2X5YktCmhAWsnMAnehhHj1bgwiNIwVYorCaXmjd8Itkn+Ec1Uog+1cjxJ41l/ NN3PktUHz4eNggLmUfOnY9nLCZRiXJj2ZndBSew4GC4AqimgHTXCm6t8shs1Qmzac6EW LTBg== X-Gm-Message-State: AD7BkJIDK2BQUcXUfjgcBFuDjpxIy8bajt6tWiGFAwqAn7o2klFpOIS7x53Cz6TGJBAPQA== X-Received: by 10.98.72.29 with SMTP id v29mr7769296pfa.71.1459295560632; Tue, 29 Mar 2016 16:52:40 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id p75sm894224pfi.29.2016.03.29.16.52.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2016 16:52:39 -0700 (PDT) To: Dave Cridland , "HANSEN, TONY L" References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> <82156918-B008-479C-BC6E-7A54930820D8@att.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56FB1547.8030105@gmail.com> Date: Wed, 30 Mar 2016 12:52:39 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IETF discussion list , IESG Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 23:52:42 -0000 On 30/03/2016 05:36, Dave Cridland wrote: > On 29 March 2016 at 16:26, HANSEN, TONY L wrote: > >> I also feel that a modified version of the RFC 2119 statement should be >> defined and specified in a small RFC. >> >> I like Dave's addition, but also think adding the word "only" is worth >> doing: >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL >> NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >> "OPTIONAL" in this document are to be interpreted as described in >> RFC 2119 only when capitalised. >> >> Leaving out the "only" still leaves the statement (slightly) ambiguous; >> it's the same as the difference between "if" and "if and only if". >> >> > I agree that's an improvement. I think it's a significant improvement, despite my other comments. However, we should also insert "NOT RECOMMENDED" (see the erratum #499 on 2119). Brian From nobody Tue Mar 29 16:56:49 2016 Return-Path: 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 A514012DB51; Tue, 29 Mar 2016 16:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 mTEnIENZTRgK; Tue, 29 Mar 2016 16:56:46 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3D9E12D0E6; Tue, 29 Mar 2016 16:46:52 -0700 (PDT) Received: by mail-pa0-x230.google.com with SMTP id td3so25390124pab.2; Tue, 29 Mar 2016 16:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=KkXCqfMdH95vDU4n+XqG5hdIfNAgjL5VDZrcZQAvVZQ=; b=vyejxbiJ+7li4Xcv6NXPCcqnfInMMUXHL2T9ZG69uBSDWaNWc0vUckIIQDgtUG1Hex jUTIgctoJl3TXyuJEYAcHT4W+Jsy22YZmZh67VrdVjIz9lcEl+VJpYgYqsuOANBSZ6Ku mhAmENJfbDbvieu+rKMVtUa5nB9+/PY5zB8heL6or9DgVAdUJN1CBK5whXLg3G2B+XnF q8HhjA5KkuEGxLzQ+W7tH5SUFlW8Xeo4nep+XZ7MZFOOWG4RdANJYHk4shGp4AX2bcii IAWYnW2VvEMEK03WZLYgWrQOlRYZXxVeFCXjPLjJvcW1gdn+z/nzaNNaAVu0j2Yet1/A o+eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=KkXCqfMdH95vDU4n+XqG5hdIfNAgjL5VDZrcZQAvVZQ=; b=OO7GIZkItZJaxuVGGQU2tbRZmUJOtGdvVAhuF0W4tzaJQghPh+kVbrHqxNQfS0wv9H +IROYCPzKS6ia5NK/7prV+w3egkeqA6h31lvA5PaLmAf+/8azm7wDJ6nTuyOUdQGqvxu HE+MSkX123au0Xij1BhtDp5jHLa5EnDdALjp1A+t438t3Gpv/Cn+BQsWjPyUiksmjEY2 k34ldzgkNlsFIk13cDNJXQECysY+D8RDcx9Q1veDyjt8M+CiE2oLiQo6WhQUqETBmmW1 gDFBdPwJ1SOjkX0nIXwIvJ2K/pOATXK3DFJEbXrJDuZWCs1bTM2Js64Sj8tQzuLpmXF/ sQFg== X-Gm-Message-State: AD7BkJIQzfHtPuTs0YvMSaW9naVMLlcYu9Dv0zFDse22Kw46kZjoXxTsvZwQvXW6mA7lig== X-Received: by 10.66.237.173 with SMTP id vd13mr7871695pac.24.1459295212364; Tue, 29 Mar 2016 16:46:52 -0700 (PDT) Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by smtp.gmail.com with ESMTPSA id b11sm898342pfj.4.2016.03.29.16.46.48 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2016 16:46:51 -0700 (PDT) To: John C Klensin , "Scott O. Bradner" , Barry Leiba References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> <53A70D39871BEF8B0AE78195@JcK-HP8200.jck.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56FB13EB.1040809@gmail.com> Date: Wed, 30 Mar 2016 12:46:51 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <53A70D39871BEF8B0AE78195@JcK-HP8200.jck.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Heather Flanagan \(RFC Series Editor\)" , rtcweb@ietf.org, IETF discussion list , IESG Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2016 23:56:47 -0000 On 30/03/2016 05:34, John C Klensin wrote: > > > --On Tuesday, March 29, 2016 08:58 +1300 Brian E Carpenter > wrote: > >> ... >> The other words (must, shall, required, not) mean what they >> always mean. The only argument for upper-casing them is >> aesthetic symmetry. If a spec uses alternatives like >> mandatory, necessary or forbidden, they are just as powerful. >> ... > > Actually, when 2119 is referenced, Section 6 attaches particular > interoperability semantics to MUST, SHALL, etc., that are not > part of the plain-English meaning of those words. Section 6 > seems to be ignored most of the time but cited when it supports > an axe someone wants to grind about use of conformance language. My claim is that even section 6 does *not* change the meanings of the categorical words in a spec. If it says that something must or must not happen, either the statement is redundant or it is essential for interoperability, whether it's written in upper case Courier New or in runes. But it doesn't matter. It's the SHOULDs and MAYs that require precision in their use. Brian From nobody Wed Mar 30 00:25:01 2016 Return-Path: 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 B272E12DD5F for ; Wed, 30 Mar 2016 00:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net 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 VnyJnnazn25t for ; Wed, 30 Mar 2016 00:24:55 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09A112DB9F for ; Wed, 30 Mar 2016 00:24:54 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id 127so85612436wmu.1 for ; Wed, 30 Mar 2016 00:24:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=njPn1MgP4J4iJk4zpojIC3SWIeaAUjnTLlo6iW3qZZU=; b=JLxtnd4yE66Rlb6OQt6Tgx5X7SmyZDFRFe6y0gjko4mLyKeIUNQaPZO9+2dI2Htqfs Ayuj4QbMv1OpJxLZJUxFDY89VIv6Djs57eNf9mLd0xfJqF0XhCl0Qg+iS5FaSrS9Kpvm Z+Gk0zQVunohw3JsMRtV57VdDxlYZTNLMgZ2s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=njPn1MgP4J4iJk4zpojIC3SWIeaAUjnTLlo6iW3qZZU=; b=P8fZM5xWyLyBt/JrCakr/hc0cB7qpYlAAU4brdIJ+3eilVcUiIzX6qBN+RkruKo5FE TsSTGTty+KJQBh5+wDzz8NG1QAx60SC9OXe61Om2fwySPxNVJuzdJjkrue0n7GlNskhJ iBrF6HlY0ftpkSYpXyMeySLgkxb52MowSb4GMEEyl7Wd2k+yEKV954JdZ2R6JdyL8S6Q tCrBnAeFreMYrelcfYo14AFdhSemwloOi0X6C77CYAsHfhCkTWeq5d3/ViJM3qPPS3T+ bvhWEWwZpwxZhIqFMs849HQNnaN/zrdQhIwuCUKCtD47jm4Ib2sX7BhUMdQcZkBsxtzl s9hw== X-Gm-Message-State: AD7BkJIeEhaauuhQHnYmXmXn+Ww1duXCwG/4DYSQhqMiClQLbrHom1Cg8CNOIJ6z2Yg6Xzrn4Zxf6udQgfd2tXIK MIME-Version: 1.0 X-Received: by 10.28.88.15 with SMTP id m15mr20647355wmb.60.1459322693266; Wed, 30 Mar 2016 00:24:53 -0700 (PDT) Received: by 10.28.37.199 with HTTP; Wed, 30 Mar 2016 00:24:53 -0700 (PDT) In-Reply-To: <56FB13EB.1040809@gmail.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> <53A70D39871BEF8B0AE78195@JcK-HP8200.jck.com> <56FB13EB.1040809@gmail.com> Date: Wed, 30 Mar 2016 08:24:53 +0100 Message-ID: From: Dave Cridland To: Brian E Carpenter Content-Type: multipart/alternative; boundary=001a1144294cbec6b4052f3f0a0f Archived-At: Cc: IETF discussion list , "Heather Flanagan \(RFC Series Editor\)" , rtcweb@ietf.org, IESG , John C Klensin , Barry Leiba , "Scott O. Bradner" Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 07:24:57 -0000 --001a1144294cbec6b4052f3f0a0f Content-Type: text/plain; charset=UTF-8 On 30 March 2016 at 00:46, Brian E Carpenter wrote: > On 30/03/2016 05:34, John C Klensin wrote: > > > > > > --On Tuesday, March 29, 2016 08:58 +1300 Brian E Carpenter > > wrote: > > > >> ... > >> The other words (must, shall, required, not) mean what they > >> always mean. The only argument for upper-casing them is > >> aesthetic symmetry. If a spec uses alternatives like > >> mandatory, necessary or forbidden, they are just as powerful. > >> ... > > > > Actually, when 2119 is referenced, Section 6 attaches particular > > interoperability semantics to MUST, SHALL, etc., that are not > > part of the plain-English meaning of those words. Section 6 > > seems to be ignored most of the time but cited when it supports > > an axe someone wants to grind about use of conformance language. > > My claim is that even section 6 does *not* change the meanings > of the categorical words in a spec. If it says that something > must or must not happen, either the statement is redundant or > it is essential for interoperability, whether it's written > in upper case Courier New or in runes. > > I should think you must realise that shall not always be the case. > But it doesn't matter. It's the SHOULDs and MAYs that require > precision in their use. > > Brian > > --001a1144294cbec6b4052f3f0a0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 30 March 2016 at 00:46, Brian E Carpenter <brian.e.carpen= ter@gmail.com> wrote:
On 30/03/2016 05:34, John C Klensin wrote:
>
>
> --On Tuesday, March 29, 2016 08:58 +1300 Brian E Carpenter
> <brian.e.carpenter@g= mail.com> wrote:
>
>> ...
>> The other words (must, shall, required, not) mean what they
>> always mean. The only argument for upper-casing them is
>> aesthetic symmetry. If a spec uses alternatives like
>> mandatory, necessary or forbidden, they are just as powerful.
>> ...
>
> Actually, when 2119 is referenced, Section 6 attaches particular
> interoperability semantics to MUST, SHALL, etc., that are not
> part of the plain-English meaning of those words.=C2=A0 Section 6
> seems to be ignored most of the time but cited when it supports
> an axe someone wants to grind about use of conformance language.

My claim is that even section 6 does *not* change the meanings
of the categorical words in a spec. If it says that something
must or must not happen, either the statement is redundant or
it is essential for interoperability, whether it's written
in upper case Courier New or in runes.


I should think you must realise that s= hall not always be the case.
=C2=A0
But it doesn't matter. It's the SHOULDs and MAYs that require
precision in their use.

=C2=A0 =C2=A0 =C2=A0 Brian


--001a1144294cbec6b4052f3f0a0f-- From nobody Wed Mar 30 07:10:29 2016 Return-Path: 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 6A84012D186; Wed, 30 Mar 2016 07:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 OM9eIO_7vVpa; Wed, 30 Mar 2016 07:10:09 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 760C312D6FF; Wed, 30 Mar 2016 07:10:01 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2UE9tEG046741 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 30 Mar 2016 09:09:56 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Barry Leiba , "Scott O. Bradner" References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> From: Adam Roach Message-ID: <56FBDE33.5000706@nostrum.com> Date: Wed, 30 Mar 2016 09:09:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IETF discussion list , IESG Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 14:10:12 -0000 On 3/28/16 09:09, Barry Leiba wrote: > Ah. Then perhaps the clarification needs to go a little further and > make this clear: > - We're defining specific terms that specifications can use. +1 > - These terms are always capitalized when these definitions are used. +1 > - You don't have to use them. If you do, they're capitalized and > their meanings are as specified here. +1 > - There are similar-looking English words that are not capitalized, > and they have their normal English meanings; this document has nothing > to do with them. Yes. This. This, this, this, a million times, this. If we published a document that said only this, it would be a huge net win for the community. > ...and I'd like to add one more, because so many people think that > text isn't normative unless it has 2119 key words in all caps in it: > > - Normative text doesn't require the use of these key words. They're > used for clarity and consistency when you want that, but lots of > normative text doesn't need to use them, and doesn't use them. +1 If there's anything I can do to help, Barry, please reach out to me. /a From nobody Wed Mar 30 07:34:42 2016 Return-Path: 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 02D2912D19D; Wed, 30 Mar 2016 07:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 aU4ti0lYD17p; Wed, 30 Mar 2016 07:34:35 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A4112D5E4; Wed, 30 Mar 2016 07:34:35 -0700 (PDT) Received: from [192.168.3.172] (74-95-195-173-SFBA.hfc.comcastbusiness.net [74.95.195.173]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u2UEYXK3028343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 30 Mar 2016 07:34:33 -0700 To: Adam Roach , Barry Leiba , "Scott O. Bradner" References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <56FBDE33.5000706@nostrum.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <56FBE3F2.10507@dcrocker.net> Date: Wed, 30 Mar 2016 07:34:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <56FBDE33.5000706@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 30 Mar 2016 07:34:34 -0700 (PDT) Archived-At: Cc: "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IETF discussion list , IESG Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 14:34:39 -0000 On 3/30/2016 7:09 AM, Adam Roach wrote: >> - There are similar-looking English words that are not capitalized, >> and they have their normal English meanings; this document has nothing >> to do with them. > > Yes. This. This, this, this, a million times, this. If we published a > document that said only this, it would be a huge net win for the community. Assuming that merely documenting this explicitly is sufficient, perhaps. That such a rule differs from natural English -- which does not typically alter semantics based on case -- and that most readers of RFCs will not have such detailed knowledge of RFC2119 nor read RFCs with the care such a rule demands, my question BARRY and adam and EveryOne Else, is what makes anyone think that such a rule must (MUST?) ensure proper reading of RFCs so as to distinguish between normative portions and advisory portions? It's worth distinguishing between rules that make the writers more comfortable, from rules that aid the reading efficacy in practical terms. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Mar 30 07:46:47 2016 Return-Path: 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 7976A12D161 for ; Wed, 30 Mar 2016 07:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 uhYKzirWWudJ for ; Wed, 30 Mar 2016 07:46:38 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06ECB12D18C for ; Wed, 30 Mar 2016 07:46:34 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2UEkRmF050504 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 30 Mar 2016 09:46:28 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: dcrocker@bbiw.net, Barry Leiba , "Scott O. Bradner" References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <56FBDE33.5000706@nostrum.com> <56FBE3F2.10507@dcrocker.net> From: Adam Roach Message-ID: <56FBE6C3.6040506@nostrum.com> Date: Wed, 30 Mar 2016 09:46:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56FBE3F2.10507@dcrocker.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IETF discussion list , IESG Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 14:46:40 -0000 On 3/30/16 09:34, Dave Crocker wrote: > It's worth distinguishing between rules that make the writers more > comfortable, from rules that aid the reading efficacy in practical terms. Forcing implementors to read through the linguistic contortions authors make to avoid using perfectly good English words doesn't do them any favors. This odd game of charades -- "one syllable... sounds like... desk? wood?" -- does not aid clarity. Much the opposite. /a From nobody Wed Mar 30 07:53:00 2016 Return-Path: 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 C913212D136; Wed, 30 Mar 2016 07:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 dHWRV_c60G78; Wed, 30 Mar 2016 07:52:51 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0EA12D107; Wed, 30 Mar 2016 07:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3039; q=dns/txt; s=iport; t=1459349571; x=1460559171; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=KViRNqo1yEipDAfPwefUX3ZgHKn+YusRbHENoOzRVLE=; b=W37HycHLVPnRCRmPkzZ7Qu8zeM71vhQ7s5QESK02XhNM6s0fhK5VLDx6 Ag6eWJyOw2a+J5yOxDc2DdhQcX+0gbKxfC0MWqAr3B6URfFqSd99Zi1Qz /RdQNm5Vgk9H8FYThyP+oRFPDr4vUVDIgDVcIBXchivplfUk7ja6avBm8 8=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoBADT5/tW/xbLJq1dwXuGDQKCFQEBA?= =?us-ascii?q?QEBAWUnhEIBAQQjVQEQCxgJFgsCAgkDAgECAUUGAQwIAQGII7AjkG0BAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBDwiKY4E3hgeCVgEEl26DH4FmiQKBZodSI4UyjxBiggQND?= =?us-ascii?q?IFMOohvAQEB?= X-IronPort-AV: E=Sophos;i="5.24,416,1454976000"; d="asc'?scan'208";a="634852468" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Mar 2016 14:52:49 +0000 Received: from [10.61.88.94] (ams3-vpn-dhcp6239.cisco.com [10.61.88.94]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u2UEqmBS012426; Wed, 30 Mar 2016 14:52:48 GMT To: Adam Roach , dcrocker@bbiw.net, Barry Leiba , "Scott O. Bradner" References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <56FBDE33.5000706@nostrum.com> <56FBE3F2.10507@dcrocker.net> <56FBE6C3.6040506@nostrum.com> From: Eliot Lear Message-ID: <56FBE83F.8030609@cisco.com> Date: Wed, 30 Mar 2016 16:52:47 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56FBE6C3.6040506@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mi8EaJKACSISVAXPTqSlRPbR5lH702lpf" Archived-At: Cc: "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IETF discussion list , IESG Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 14:52:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mi8EaJKACSISVAXPTqSlRPbR5lH702lpf Content-Type: multipart/mixed; boundary="e02bQk2o9iCmPScp9ACJtNN6j4U8XGr5F" From: Eliot Lear To: Adam Roach , dcrocker@bbiw.net, Barry Leiba , "Scott O. Bradner" Cc: "Heather Flanagan (RFC Series Editor)" , "rtcweb@ietf.org" , IETF discussion list , IESG Message-ID: <56FBE83F.8030609@cisco.com> Subject: Re: [rtcweb] Uppercase question for RFC2119 words References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <56FBDE33.5000706@nostrum.com> <56FBE3F2.10507@dcrocker.net> <56FBE6C3.6040506@nostrum.com> In-Reply-To: <56FBE6C3.6040506@nostrum.com> --e02bQk2o9iCmPScp9ACJtNN6j4U8XGr5F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/30/16 4:46 PM, Adam Roach wrote: > On 3/30/16 09:34, Dave Crocker wrote: >> It's worth distinguishing between rules that make the writers more >> comfortable, from rules that aid the reading efficacy in practical >> terms.=20 > > Forcing implementors to read through the linguistic contortions > authors make to avoid using perfectly good English words doesn't do > them any favors. This odd game of charades -- "one syllable... sounds > like... desk? wood?" -- does not aid clarity. Much the opposite. Ok. But neither should authors and editors be afraid of 2119. Those definitions are there to help both the reader and the writer, so that intent is clear. Eliot --e02bQk2o9iCmPScp9ACJtNN6j4U8XGr5F-- --mi8EaJKACSISVAXPTqSlRPbR5lH702lpf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJW++hAAAoJEIe2a0bZ0nozekIIAKx9SeMy55lpg+1fFK4YCvsk LxjyBGFZgnSY/5CobDMv0av+IJQx0o9+UCoE8Kr900jizas1VZqOrtGJucywm6HT tpxw41r0PEJz0SyBySJ8Tw/PzPLCWZdG4uIPXOILiZRu42Nzy0c4LkiOqSlvtau5 tSwPUSokt/jnSxbLugmi5JFY+pBMphCEmHfvC+XP/W1PCEeh7cvphPom9p0y+421 R61KVQrrrKi6CAUOV3x7k01m3otbDMhZOfllelbOyKxFpLv94mezH+j9h8GHShm5 +sZlY4HHnEpNZX+3FkvCJYfBe7eDLIZPF6SJHvf/Yg3Hur05tK49Wshy2eyN+tw= =ErmW -----END PGP SIGNATURE----- --mi8EaJKACSISVAXPTqSlRPbR5lH702lpf-- From nobody Wed Mar 30 07:56:04 2016 Return-Path: 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 37DAA12D774; Wed, 30 Mar 2016 07:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Wecx0K17vNUh; Wed, 30 Mar 2016 07:55:57 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4E0212D756; Wed, 30 Mar 2016 07:55:56 -0700 (PDT) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2UEtoXn051890 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Mar 2016 09:55:51 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Adam Roach" Date: Wed, 30 Mar 2016 09:55:50 -0500 Message-ID: In-Reply-To: <56FBE6C3.6040506@nostrum.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <56FBDE33.5000706@nostrum.com> <56FBE3F2.10507@dcrocker.net> <56FBE6C3.6040506@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: IETF discussion list , Heather Flanagan , "rtcweb@ietf.org" , dcrocker@bbiw.net, Barry Leiba , "Scott O. Bradner" , IESG Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 14:55:58 -0000 On 30 Mar 2016, at 9:46, Adam Roach wrote: > On 3/30/16 09:34, Dave Crocker wrote: >> It's worth distinguishing between rules that make the writers more >> comfortable, from rules that aid the reading efficacy in practical >> terms. > > Forcing implementors to read through the linguistic contortions > authors make to avoid using perfectly good English words doesn't do > them any favors. This odd game of charades -- "one syllable... sounds > like... desk? wood?" -- does not aid clarity. Much the opposite. > +1. Especially having grown up in the border between the US south and southwest, where "ought" was a considerably more loaded term than "should" (and was primarily used by grandparents to lecture children). From nobody Wed Mar 30 09:32:19 2016 Return-Path: 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 7CD3B12D192 for ; Wed, 30 Mar 2016 09:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net 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 oOqe-iCiA6ue for ; Wed, 30 Mar 2016 09:32:10 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36D2312D5E7 for ; Wed, 30 Mar 2016 09:32:09 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id 191so96358148wmq.0 for ; Wed, 30 Mar 2016 09:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=1iGJLWfwegCEcxgFM91FCSY2KvWdt+ie7HG0I2S1K7c=; b=aOfJNLJD2V7mJNu5to+4vdoLrTf4A/MxFOBnHsxBrnWzSNaOZS44CfJ1FWT2STq4fG dn7ONaGIfukqn2IN5gYvp8NkhHs8mGNC9u7xW0EwU9ubyQ/604AGzf8fisKHvIt1EXiU 3FPQxQAgF7YnOyReqYLYwdi1b9ESKpbm/V76I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1iGJLWfwegCEcxgFM91FCSY2KvWdt+ie7HG0I2S1K7c=; b=SVRSyyBvk7WvARGOAknkR0BTM3vM+XErYl+EFe49kJ8M9kL9nO9u+2MNzBfMA4NbVp oAP0G4L2TXTJ+Za0psz7Dod1lNiNWHI5VIF53V8WJNs+Gx8B4lZFM3rz70ThLpkuahkG CDdDZmjMJ5FyUZUUXfM/Civ0mq0Q1sQz7vVJzLc7hNMGYU9ReO5cDa9JSflWggFqVqzK QyWVxbJaEHHjCfYn69ZMZc7vSIxY3lKMorf4wlXBNPZ7chDy7GcniU7CF7dCiI4AV+L3 YyVQwmrAfGG8yXtjvKo34wAiexOa2jzfmvr/ijBKHJNFFQ/l1jxyKsAJG3fRYQeY96F6 ELAA== X-Gm-Message-State: AD7BkJIrCyF17i2ayDuCodV8CDVtcCjqeEbNRaNhbGrss6buibpMpi7rc2WiXvIfzXcCmDLAR+lbhB/zoyrRmmy7 MIME-Version: 1.0 X-Received: by 10.28.125.71 with SMTP id y68mr16525433wmc.30.1459355527766; Wed, 30 Mar 2016 09:32:07 -0700 (PDT) Received: by 10.28.37.199 with HTTP; Wed, 30 Mar 2016 09:32:07 -0700 (PDT) In-Reply-To: <56FBE3F2.10507@dcrocker.net> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <56FBDE33.5000706@nostrum.com> <56FBE3F2.10507@dcrocker.net> Date: Wed, 30 Mar 2016 17:32:07 +0100 Message-ID: From: Dave Cridland To: Dave Crocker Content-Type: multipart/alternative; boundary=001a1141e94cd57cb7052f46afd9 Archived-At: Cc: IETF discussion list , "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IESG , Barry Leiba , "Scott O. Bradner" Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 16:32:16 -0000 --001a1141e94cd57cb7052f46afd9 Content-Type: text/plain; charset=UTF-8 On 30 March 2016 at 15:34, Dave Crocker wrote: > On 3/30/2016 7:09 AM, Adam Roach wrote: > >> - There are similar-looking English words that are not capitalized, >>> and they have their normal English meanings; this document has nothing >>> to do with them. >>> >> >> Yes. This. This, this, this, a million times, this. If we published a >> document that said only this, it would be a huge net win for the >> community. >> > > > Assuming that merely documenting this explicitly is sufficient, perhaps. > > That such a rule differs from natural English -- which does not typically > alter semantics based on case -- and that most readers of RFCs will not > have such detailed knowledge of RFC2119 nor read RFCs with the care such a > rule demands, my question BARRY and adam and EveryOne Else, is what makes > anyone think that such a rule must (MUST?) ensure proper reading of RFCs so > as to distinguish between normative portions and advisory portions? > > Sorry, I think that's nonsense. RFC 2119 and its capitalized keywords are well known to anyone reading any specifications, these days. I think we can actually assume a priori knowledge of RFC 2119, for the most part. What I think would be far more surprising is this notion that the keywords, noted and referenced in capitals, also have the same precise meaning and force when written normally. I'd note that in typical technical books, different typefaces are often used to indicate verbatim commands or code, placeholders, etc - the practise of using typographical conventions not normally found in written English in technical literature is not only extremely prevalent, but in this case in particular this is the assumption of the vast majority of those likely to read it. If you don't believe me, go look at a XEP, or a PEP, or a W3C-TR, or any of hundreds of ad-hoc specifications from community efforts to proprietary HTTP APIs - they all use RFC 2119 language, often without even bothering to cite the document. That's not to say that when reviewing a document, a lower-case "must" might not be better as a "MUST" - but I don't see it as any different to a similarly lower case "ought" being phrased better as a "SHOULD" if that's really what was meant. The keywords exist to enhance clarity - but nothing more. A mandatory requirement can be expressed without the "M" word. We can mention that not implementing a feature causes interoperability issues without using the "S" word. Knowing that we may read such text does not make it "OPTIONAL". Finally, I'd note in passing that "bill" and "Bill", "will" and "Will", "heather" and "Heather", all have different semantics based on case - not that this is particular relevant. > It's worth distinguishing between rules that make the writers more > comfortable, from rules that aid the reading efficacy in practical terms. > > d/ > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > --001a1141e94cd57cb7052f46afd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 30 March 2016 at 15:34, Dave Crocker <dhc@dcrocker.net> wrote:
On 3/30/2016 = 7:09 AM, Adam Roach wrote:
- There are similar-looking English words that are not capitalized,
and they have their normal English meanings; this document has nothing
to do with them.

Yes. This. This, this, this, a million times, this. If we published a
document that said only this, it would be a huge net win for the community.=


Assuming that merely documenting this explicitly is sufficient, perhaps.
That such a rule differs from natural English -- which does not typically a= lter semantics based on case -- and that most readers of RFCs will not have= such detailed knowledge of RFC2119 nor read RFCs with the care such a rule= demands, my question BARRY and adam and EveryOne Else, is what makes anyon= e think that such a rule must (MUST?) ensure proper reading of RFCs so as t= o distinguish between normative portions and advisory portions?


Sorry, I think that's nonsense. RF= C 2119 and its capitalized keywords are well known to anyone reading any sp= ecifications, these days. I think we can actually assume a priori knowledge= of RFC 2119, for the most part. What I think would be far more surprising = is this notion that the keywords, noted and referenced in capitals, also ha= ve the same precise meaning and force when written normally.

=
I'd note that in typical technical books, different typeface= s are often used to indicate verbatim commands or code, placeholders, etc -= the practise of using typographical conventions not normally found in writ= ten English in technical literature is not only extremely prevalent, but in= this case in particular this is the assumption of the vast majority of tho= se likely to read it.

If you don't believe me,= go look at a XEP, or a PEP, or a W3C-TR, or any of hundreds of ad-hoc spec= ifications from community efforts to proprietary HTTP APIs - they all use R= FC 2119 language, often without even bothering to cite the document.
<= div>
That's not to say that when reviewing a document, a = lower-case "must" might not be better as a "MUST" - but= I don't see it as any different to a similarly lower case "ought&= quot; being phrased better as a "SHOULD" if that's really wha= t was meant. The keywords exist to enhance clarity - but nothing more. A ma= ndatory requirement can be expressed without the "M" word. We can= mention that not implementing a feature causes interoperability issues wit= hout using the "S" word. Knowing that we may read such text does = not make it "OPTIONAL".

Finally, I'd= note in passing that "bill" and "Bill", "will&quo= t; and "Will", "heather" and "Heather", all h= ave different semantics based on case - not that this is particular relevan= t.
=C2=A0
It's worth distinguishing between rules that make the writers more comf= ortable, from rules that aid the reading efficacy in practical terms.

d/

--

=C2=A0 Dave Crocker
=C2=A0 Brandenburg InternetWorking
=C2=A0 bbi= w.net


--001a1141e94cd57cb7052f46afd9-- From nobody Wed Mar 30 09:52:37 2016 Return-Path: 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 D1A8F12D7E6; Wed, 30 Mar 2016 09:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 tKLnUVq_-0jB; Wed, 30 Mar 2016 09:52:33 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8060A12D142; Wed, 30 Mar 2016 09:52:33 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u2UGqIFP062960 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 30 Mar 2016 11:52:18 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Dave Cridland , Dave Crocker References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <56FBDE33.5000706@nostrum.com> <56FBE3F2.10507@dcrocker.net> From: Adam Roach Message-ID: <56FC0441.5090207@nostrum.com> Date: Wed, 30 Mar 2016 11:52:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF discussion list , "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IESG , Barry Leiba , "Scott O. Bradner" Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 16:52:35 -0000 On 3/30/16 11:32, Dave Cridland wrote: > Finally, I'd note in passing that "bill" and "Bill", "will" and > "Will", "heather" and "Heather", all have different semantics based on > case - not that this is particular relevant. It's actually quite relevant, since it shows that we already have significant cases in which merely changing letter case can alter meaning nontrivially. There's a somewhat bawdy example of this that you can find by typing "capitalization matters" into Google Image Search. (Probably not safe to do in many workplaces). It kind of takes the wind out of arguments that people will miss the difference between letter cases. /a From nobody Wed Mar 30 10:59:45 2016 Return-Path: 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 94F4B12D84E; Wed, 30 Mar 2016 10:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HpeiOlk1R10R; Wed, 30 Mar 2016 10:59:31 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D216912D849; Wed, 30 Mar 2016 10:59:30 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id h65so68099320ywe.0; Wed, 30 Mar 2016 10:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=jyFvXvplKgU7qcoSZUsr2gr/WGNOElarbzTb+KRIiS0=; b=VoMsCirnsRhtCg7NY7SDZYQdCkJFQHPTBcis1Bei7wxN1+d4mLTedwrngDK+lzs0Ln LxitiEY/wDCqTMHil06upULBXX3EfntBgQGriA0v5acnhDLvQ9QQfehIx+h20RnvVtnQ CqRzIJfDu9sqSfag9it9dmVr+iV2iIkSlznV1YStESSzYlOXXE9pPw/bpuJRu+hwsnCL drImV+QV1OUXORC7Dkr26DlNkz/RAb+o887f5bdWqShBwDW1KUDClKAkta2LXliFZSwo zzfsR780IZ42iYnuhqkP7pBddUOa0IByDHVhUssuqpXVHdXolfeexYQAN0oPrwZqOyJz q28w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=jyFvXvplKgU7qcoSZUsr2gr/WGNOElarbzTb+KRIiS0=; b=Pa461u20jyaPrwKvTFzPa31nj/Rphrjug/SB8ICjuKxF04kH4EB25PDUqryEaWyH0q oZTzyhyg67Ex7kCmnUyLCc7fD+5M/uffVrN+GG8BDNxNJgE1YhiK53awA2tdpCzr2b6H VSxX5UlYftbtNKxYqKsxIRaD3hRL/EYC/s2kVXnXkTD8C0ID0nR2/it0E9kak7yongEJ xgzsJPWhwFeUpZfRh0z5GkTxBwYHBytreI03Gtu6deC7MqRBIblvFH03hUcVqM3oN2V5 v+y4TOrTJhP+CxSC66HF7g3EOIkWstEIpSIEzQxaUuyH9B+ih2X0fbiP8UIhGzucKVxi y8GA== X-Gm-Message-State: AD7BkJJghtkMmRDIzoycy/1agRDTyC75wL3dzZmMLNvfLx7aHwc+KVx0+zt0AhtFIoqKnrdN/pEhxKRlv2aY9Q== MIME-Version: 1.0 X-Received: by 10.13.214.81 with SMTP id y78mr4744102ywd.227.1459360770068; Wed, 30 Mar 2016 10:59:30 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.83.28.67 with HTTP; Wed, 30 Mar 2016 10:59:29 -0700 (PDT) In-Reply-To: References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <56FBDE33.5000706@nostrum.com> <56FBE3F2.10507@dcrocker.net> Date: Wed, 30 Mar 2016 13:59:29 -0400 X-Google-Sender-Auth: 01EzBFcKkqDR_9ty4yllqHS6rRQ Message-ID: From: Barry Leiba To: Dave Cridland Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF discussion list , "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IESG , "Scott O. Bradner" , Dave Crocker Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 17:59:32 -0000 >> That such a rule differs from natural English -- which does not typically >> alter semantics based on case -- and that most readers of RFCs will not have >> such detailed knowledge of RFC2119 nor read RFCs with the care such a rule >> demands, my question BARRY and adam and EveryOne Else, is what makes anyone >> think that such a rule must (MUST?) ensure proper reading of RFCs so as to >> distinguish between normative portions and advisory portions? > > Sorry, I think that's nonsense. RFC 2119 and its capitalized keywords are > well known to anyone reading any specifications, these days. I think we can > actually assume a priori knowledge of RFC 2119, for the most part. What I > think would be far more surprising is this notion that the keywords, noted > and referenced in capitals, also have the same precise meaning and force > when written normally. I agree with the first and third sentences of what Dave Cridland said, but I think we have to be a little careful about the second. What I think we can assume is an a priori knowledge of some of what 2119 says: that there are these capitalized key words that have special meanings. But it's quite clear from reviewing a lot of documents (one of the fun things one gets to do as AD) that many writers do not know how 2119 actually defines those. I see significant misunderstandings about "SHOULD" and "MAY" all the time, examples of which I can give you if you like. And one of my favourites is when someone used "RECOMMENDED", I questioned it in a comment, and the response was, "Yes, maybe we should switch that to 'SHOULD'." As a complete side thing, I wonder how this all seems to German-speakers, as German uses initial caps for all nouns. I wonder if anyone even notices if someone fails to do that. I wonder if it becomes puzzling, perhaps in some instances. Barry From nobody Wed Mar 30 11:27:12 2016 Return-Path: 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 AD06D12D5AF; Wed, 30 Mar 2016 10:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 bLD3nE65tENC; Wed, 30 Mar 2016 10:04:01 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E4712D5B8; Wed, 30 Mar 2016 10:04:01 -0700 (PDT) Received: from [192.168.11.230] (c-73-252-132-48.hsd1.ca.comcast.net [73.252.132.48]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u2UH3uve005719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 30 Mar 2016 10:03:57 -0700 To: Adam Roach , Dave Cridland References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <56FBDE33.5000706@nostrum.com> <56FBE3F2.10507@dcrocker.net> <56FC0441.5090207@nostrum.com> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: <56FC06F5.5090100@bbiw.net> Date: Wed, 30 Mar 2016 10:03:49 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <56FC0441.5090207@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 30 Mar 2016 10:03:58 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Wed, 30 Mar 2016 11:27:11 -0700 Cc: IETF discussion list , "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IESG , Barry Leiba , "Scott O. Bradner" Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 17:04:03 -0000 On 3/30/2016 9:52 AM, Adam Roach wrote: > On 3/30/16 11:32, Dave Cridland wrote: >> Finally, I'd note in passing that "bill" and "Bill", "will" and >> "Will", "heather" and "Heather", all have different semantics based on >> case - not that this is particular relevant. > > It's actually quite relevant, since it shows that we already have > significant cases in which merely changing letter case can alter meaning > nontrivially. Except that the assertion that case alters meeting is wrong. The examples given were wrong, adam. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Mar 30 11:27:14 2016 Return-Path: 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 EEA3312D7FA for ; Wed, 30 Mar 2016 10:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 ZXdMk55u3gdL for ; Wed, 30 Mar 2016 10:12:37 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90DBA12D7F3 for ; Wed, 30 Mar 2016 10:12:37 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id g185so82630212ioa.2 for ; Wed, 30 Mar 2016 10:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=iX7Ph5cMdtru6SGA6VNG9811sKXkT8sNFqnlapzfJPc=; b=ADgifoDho5FBmLea69dHtxivhWC7VZWyGwvzxA/ayPBPbOMfk/QOJ4Sod5C1m7XAV3 i2zIJ/GS8c1qgeeROTxL3leGK49YXju39dnVOmlKzxXuzToFdkNN+vr+RZcpLIMxKBT7 lVmVuItcHMqFzrUQrzLgDzyoPdQ1qeAq3YD/8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=iX7Ph5cMdtru6SGA6VNG9811sKXkT8sNFqnlapzfJPc=; b=GP5jyqHB1ftBscsnAXb1wv99hMpWLzvJ7V4ENhgl7G4F1C2MokgwPRCcjd/JUHZDt6 2Sf8UZq9/ucVcDHS5Hlx899KyEyupDCm34KXQWLECkjKnDkwBPWPoBzqXdLtF23UKRRG 2Kr4CFiLN7u0zFkrvewVPAydcKTRRDPfoVLf1XLjn485v9bpnZSn4c7GnXt6ng22LDLZ r1Al09HzBSShOwKxXVVmAzl0XzANphv6KKOn4HX5naOPNFZFesdfO6c9ga93kLef2qRA yCPBAPr3Jsrg2XBW9vBqMeYwtW8zKQVjpfYKaCp8sq6RVQhJaAcVwV4r+iekVks7n/Dg VyCQ== X-Gm-Message-State: AD7BkJJTgpaUyxpqRN3gvdjMbj7b3Wy/pOnrx1dexa9lmRlspDfQDe+V07z/IJ4Hyfl0clRlD9Am+DdD5IFtrMSp MIME-Version: 1.0 X-Received: by 10.107.132.88 with SMTP id g85mr1465691iod.95.1459357956464; Wed, 30 Mar 2016 10:12:36 -0700 (PDT) Received: by 10.36.130.1 with HTTP; Wed, 30 Mar 2016 10:12:36 -0700 (PDT) In-Reply-To: <56FC0441.5090207@nostrum.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <56FBDE33.5000706@nostrum.com> <56FBE3F2.10507@dcrocker.net> <56FC0441.5090207@nostrum.com> Date: Wed, 30 Mar 2016 10:12:36 -0700 Message-ID: From: Pat Thaler To: Adam Roach Content-Type: multipart/alternative; boundary=001a113f323c994804052f47401b Archived-At: X-Mailman-Approved-At: Wed, 30 Mar 2016 11:27:11 -0700 Cc: IETF discussion list , "Heather Flanagan \(RFC Series Editor\)" , Dave Cridland , "rtcweb@ietf.org" , IESG , Barry Leiba , Dave Crocker Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 17:12:50 -0000 --001a113f323c994804052f47401b Content-Type: text/plain; charset=UTF-8 "must" has multiple meanings - it can indicate a requirement but it also can be used to state the inevitable: e.g., "What goes up must come down." Though in general, I'm not a fan of writing in all caps, "MUST" removes the ambiguity indicating that it is to be understood as defined, rather than having its regular English meaning. All caps for the words also helps the requirement statements stand out when scanning through a document. On Wed, Mar 30, 2016 at 9:52 AM, Adam Roach wrote: > On 3/30/16 11:32, Dave Cridland wrote: > >> Finally, I'd note in passing that "bill" and "Bill", "will" and "Will", >> "heather" and "Heather", all have different semantics based on case - not >> that this is particular relevant. >> > > It's actually quite relevant, since it shows that we already have > significant cases in which merely changing letter case can alter meaning > nontrivially. There's a somewhat bawdy example of this that you can find by > typing "capitalization matters" into Google Image Search. (Probably not > safe to do in many workplaces). > > It kind of takes the wind out of arguments that people will miss the > difference between letter cases. > > /a > > --001a113f323c994804052f47401b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"must" has multiple meanings - it can indicate a= requirement but it also can be used to state the inevitable: e.g., "W= hat goes up must come down."

Though in general, I&#= 39;m not a fan of writing in all caps, "MUST" removes the ambigui= ty indicating that it is to be understood as defined, rather than having it= s regular English meaning.=C2=A0

All caps for the = words also helps the requirement statements stand out when scanning through= a document.

On Wed, Mar 30, 2016 at 9:52 AM, Adam Roach <adam@nostrum.com>= ; wrote:
On 3/30/= 16 11:32, Dave Cridland wrote:
Finally, I'd note in passing that "bill" and "Bill"= , "will" and "Will", "heather" and "Heat= her", all have different semantics based on case - not that this is pa= rticular relevant.

 It's actually quite relevant, since it shows that we already have signi= ficant cases in which merely changing letter case can alter meaning nontriv= ially. There's a somewhat bawdy example of this that you can find by ty= ping "capitalization matters" into Google Image Search. (Probably= not safe to do in many workplaces).

It kind of takes the wind out of arguments that people will miss the differ= ence between letter cases.
/a


--001a113f323c994804052f47401b-- From nobody Wed Mar 30 11:27:19 2016 Return-Path: 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 EA96312D6E1; Wed, 30 Mar 2016 10:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 CcRj8Jvz_bJc; Wed, 30 Mar 2016 10:24:55 -0700 (PDT) Received: from mr11p00im-asmtp003.me.com (mr11p00im-asmtp003.me.com [17.110.69.254]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B75812D814; Wed, 30 Mar 2016 10:24:55 -0700 (PDT) Received: from [10.1.10.8] (173-11-110-134-SFBA.hfc.comcastbusiness.net [173.11.110.134]) by mr11p00im-asmtp003.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O4V001YK4DIN510@mr11p00im-asmtp003.me.com>; Wed, 30 Mar 2016 17:24:55 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-03-30_09:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1603300255 Date: Wed, 30 Mar 2016 10:24:53 -0700 (PDT) From: Ole Jacobsen To: Pat Thaler In-reply-to: Message-id: References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <56FBDE33.5000706@nostrum.com> <56FBE3F2.10507@dcrocker.net> <56FC0441.5090207@nostrum.com> User-Agent: Alpine 2.01 (OSX 1266 2009-07-14) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Archived-At: X-Mailman-Approved-At: Wed, 30 Mar 2016 11:27:11 -0700 Cc: IETF discussion list , "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IESG , Barry Leiba , Dave Crocker Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Ole Jacobsen List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 17:24:58 -0000 On Wed, 30 Mar 2016, Pat Thaler wrote: > "must" has multiple meanings - it can indicate a requirement but it also > can be used to state the inevitable: e.g., "What goes up must come down." > > Though in general, I'm not a fan of writing in all caps, "MUST" removes the > ambiguity indicating that it is to be understood as defined, rather than > having its regular English meaning. > > All caps for the words also helps the requirement statements stand out when > scanning through a document. > +1 A few years ago I stayed in a B&B in England. The owner asked me: "Do you require toast in the morning?" This particular use of "require" is not commonly used in the US (at least not on the West Coast) unless toast is some kind of medical substance. All of which goes to show that words have different meaning and also different USAGE, often location-based. Ole From nobody Wed Mar 30 11:47:45 2016 Return-Path: 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 68BB212D12D; Wed, 30 Mar 2016 11:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 kYGhfFw3q10G; Wed, 30 Mar 2016 11:47:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8350612D8AB; Wed, 30 Mar 2016 11:47:40 -0700 (PDT) Received: from BLUPR17MB0275.namprd17.prod.outlook.com (10.162.235.146) by BLUPR17MB0275.namprd17.prod.outlook.com (10.162.235.146) with Microsoft SMTP Server (TLS) id 15.1.443.12; Wed, 30 Mar 2016 18:47:19 +0000 Received: from BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) by BLUPR17MB0275.namprd17.prod.outlook.com ([10.162.235.146]) with mapi id 15.01.0443.017; Wed, 30 Mar 2016 18:47:19 +0000 From: Stephan Wenger To: Barry Leiba , Dave Cridland Thread-Topic: [rtcweb] Uppercase question for RFC2119 words Thread-Index: AQHRiPXV8IECKF0HC0aaG3s550nVL59u4b8AgAADUoCAAySugIAABtoAgAAg4YCAABhpgP//mAMA Date: Wed, 30 Mar 2016 18:47:18 +0000 Message-ID: References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <56FBDE33.5000706@nostrum.com> <56FBE3F2.10507@dcrocker.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: computer.org; dkim=none (message not signed) header.d=none;computer.org; dmarc=none action=none header.from=stewe.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [50.174.30.183] x-ms-office365-filtering-correlation-id: 8edd7271-04c5-4e7e-f52f-08d358cbb8e8 x-microsoft-exchange-diagnostics: 1; BLUPR17MB0275; 5:xSLO3uRUBVoTnA5se/PH4DkC45uAo/R8916aegqPJv9BgpsvltU1GCM0TLsSVKv5A+0SyEzXT7264fxfO29nJRRNpAB5WHtl0GZdqGAidcOUYZ3eIy04NKnIfn6kUSu4lhurLOA1V8BJM6FHY7MMhQ==; 24:+5iX5qPREZv2x2sCUEiEnyOdvZ8Zp12ygN2sC265BHsTfOhBC3lSZg0hJj82Xw3tGAy769eewc1DGF+X1i93058vNB33iDZU5VJIqcD3+AE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR17MB0275; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040046)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041046)(6043046); SRVR:BLUPR17MB0275; BCL:0; PCL:0; RULEID:; SRVR:BLUPR17MB0275; x-forefront-prvs: 08978A8F5C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(92566002)(76176999)(586003)(3846002)(54356999)(102836003)(81166005)(5004730100002)(33656002)(6116002)(5008740100001)(11100500001)(4326007)(87936001)(86362001)(2900100001)(66066001)(2906002)(2950100001)(82746002)(36756003)(3280700002)(50986999)(77096005)(3660700001)(19580405001)(19580395003)(106116001)(93886004)(5001770100001)(122556002)(1096002)(83716003)(1220700001)(5002640100001)(99286002)(189998001)(10400500002)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR17MB0275; H:BLUPR17MB0275.namprd17.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2016 18:47:18.7470 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR17MB0275 Archived-At: Cc: Dave Crocker , "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IETF discussion list , IESG Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 18:47:44 -0000 SGkgQmFycnksDQoNCg0KDQogICANCg0KDQoNCk9uIDMvMzAvMTYsIDEwOjU5LCAiaWV0ZiBvbiBi ZWhhbGYgb2YgQmFycnkgTGVpYmEiIDxpZXRmLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IGJhcnJ5bGVpYmFAY29tcHV0ZXIub3JnPiB3cm90ZToNClsuLi5dDQoNCj4NCj5BcyBhIGNvbXBs ZXRlIHNpZGUgdGhpbmcsIEkgd29uZGVyIGhvdyB0aGlzIGFsbCBzZWVtcyB0bw0KPkdlcm1hbi1z cGVha2VycywgYXMgR2VybWFuIHVzZXMgaW5pdGlhbCBjYXBzIGZvciBhbGwgbm91bnMuICBJIHdv bmRlcg0KPmlmIGFueW9uZSBldmVuIG5vdGljZXMgaWYgc29tZW9uZSBmYWlscyB0byBkbyB0aGF0 LiAgSSB3b25kZXIgaWYgaXQNCj5iZWNvbWVzIHB1enpsaW5nLCBwZXJoYXBzIGluIHNvbWUgaW5z dGFuY2VzLg0KDQpHZXJtYW4gbmF0aXZlIHNwZWFrZXIgaGVyZS4NCg0KSW5kZWVkLCBpbiBHZXJt YW4gdGhlIGZpcnN0IGxldHRlciBvZiBhIG5vdW4gaXMgY2FwaXRhbGl6ZWQsIGFuZCBpbmRlZWQg dGhlcmUgYXJlIGEgdmVyeSBmZXcgZXhhbXBsZXMgd2hlcmUgYSBub3VuIGFuZCBhIChub24tY2Fw aXRhbGl6ZWQgYnV0IG90aGVyd2lzZSBzcGVsbGVkIGlkZW50aWNhbGx5KSBub24tbm91biBoYXZl IG1lYW5pbmdzIHRoYXQgYXJlIG5vdCBpbnR1aXRpdmVseSBkaXN0aW5ndWlzaGFibGUuICBPbmUg ZXhhbXBsZSBpcyB0aGUgcGx1cmFsIG5vdW4g4oCcU3Bpbm5lbuKAnSAoc3BpZGVycyksIGFuZCB0 aGUgdmVyYiDigJxzcGlubmVu4oCdICh0byBzcGluL3lhcm4gYW5kIGFsc28gdG8gYmUgYm9ua2Vy cyA6LSkNCg0KVGhlcmUgbWF5IGV2ZW4gYmUgYSBoYW5kZnVsIG9mIGNhc2VzIChpbiBhbGwgYm9v a3Mgb2YgYSBzaXphYmxlIGxpYnJhcnkpIHdoZXJlIHRoYXQgc2l0dWF0aW9uIGNvdWxkIGxlYWQg dG8gY29uZnVzaW9uIHdoZW4gY29uc2lkZXJpbmcgdGhlIGNvbnRleHQuICBUaGF0IHdvdWxkIHR5 cGljYWxseSBiZSBzbGFuZyBsYW5ndWFnZS4gIEhvd2V2ZXIsIHRoZSBhbW91bnQgb2YgY29uZnVz aW9uIGlzIHByb2JhYmx5IGxlc3MgdGhhbiBpdCB3b3VsZCBiZSBpbiBFbmdsaXNoLCBnaXZlbiB0 aGUgZXhhbXBsZXMgc29tZSBmb2xrcyBwcm92aWRlZCBoZXJlLg0KDQoNCkV4Y2VwdCBmb3IgYWNy b255bXMsIGFsbC1jYXBzIGlzIGEgbm8tbm8gaW4gR2VybWFuLCBldmVuIGZvciB0aGluZ3MgbGlr ZSBsYXN0IG5hbWVzLg0KDQpTdGVwaGFuDQoNCg0K From nobody Wed Mar 30 12:00:58 2016 Return-Path: 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 8F13912D8C8 for ; Wed, 30 Mar 2016 12:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net 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 A449l2zlK4j1 for ; Wed, 30 Mar 2016 12:00:55 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE4612D8F4 for ; Wed, 30 Mar 2016 12:00:39 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id p65so84608181wmp.0 for ; Wed, 30 Mar 2016 12:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=kZcYS2jvq030btDcobazj8a9560xu3xutvn2xB+EMFA=; b=HEJ0BwG+V+8lbNBwRftkAv3R/CVqV5evgFTeZI9camqcaDOFZ+aYjcTgr5zATyBnhe V45EeW1FkyMFc7MRC3vkedSAhWT9TWU32T8ErcQ0bsB5gkw6qmDKqeuaQJWsKGaV4Uvd kvK8KnGwcm8+MEwouy6EeCguitjh/TIc8UdYU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kZcYS2jvq030btDcobazj8a9560xu3xutvn2xB+EMFA=; b=nDEzlIkpuuq6dvOAubIBCUfAEBmmR1b9LkD44cUtCyYE+CLwFs5iClqFxfuOPzLPvA 5STv/Mk1KUtRJK0WMQEgvy6Z+6qAGDwMdUy7MChF3Mjpvr87V/gjWrOrj9wjqYFIR36g jerJNmhA5ykrTN0HdUWHYC4iWjSR5Ks1LMrW5PfBVylO0SqtOiy1tdhaFk4R66INAsvw Kc9S9OEwgZMbQSH2GJSVvZBE0z68IxAyWbbWYr0UrayI5NRC8AFCYUG4Nnu8t2ibT/7k L/8SYmptUAFhck4kLvgP/sZuBc1V+XsBa4NAbtho20oS+EsvZihkNNIngyeyRmR5RQr1 X0Hg== X-Gm-Message-State: AD7BkJKS5ifiapMdAC7V8WOyYQh2NxlaSL5QfIL96v6SWxF09jFSliVA1FZj1zmjm+Z/ZQZwIKhbgwdLq/37Dgkh MIME-Version: 1.0 X-Received: by 10.28.215.16 with SMTP id o16mr11694172wmg.57.1459364438143; Wed, 30 Mar 2016 12:00:38 -0700 (PDT) Received: by 10.28.37.199 with HTTP; Wed, 30 Mar 2016 12:00:37 -0700 (PDT) In-Reply-To: References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <56FBDE33.5000706@nostrum.com> <56FBE3F2.10507@dcrocker.net> Date: Wed, 30 Mar 2016 20:00:37 +0100 Message-ID: From: Dave Cridland To: Barry Leiba Content-Type: multipart/alternative; boundary=001a1145ba2cef0a43052f48c23e Archived-At: Cc: IETF discussion list , "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IESG , "Scott O. Bradner" , Dave Crocker Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 19:00:56 -0000 --001a1145ba2cef0a43052f48c23e Content-Type: text/plain; charset=UTF-8 On 30 March 2016 at 18:59, Barry Leiba wrote: > >> That such a rule differs from natural English -- which does not > typically > >> alter semantics based on case -- and that most readers of RFCs will not > have > >> such detailed knowledge of RFC2119 nor read RFCs with the care such a > rule > >> demands, my question BARRY and adam and EveryOne Else, is what makes > anyone > >> think that such a rule must (MUST?) ensure proper reading of RFCs so as > to > >> distinguish between normative portions and advisory portions? > > > > Sorry, I think that's nonsense. RFC 2119 and its capitalized keywords are > > well known to anyone reading any specifications, these days. I think we > can > > actually assume a priori knowledge of RFC 2119, for the most part. What I > > think would be far more surprising is this notion that the keywords, > noted > > and referenced in capitals, also have the same precise meaning and force > > when written normally. > > I agree with the first and third sentences of what Dave Cridland said, > but I think we have to be a little careful about the second. What I > think we can assume is an a priori knowledge of some of what 2119 > says: that there are these capitalized key words that have special > meanings. But it's quite clear from reviewing a lot of documents (one > of the fun things one gets to do as AD) that many writers do not know > how 2119 actually defines those. I see significant misunderstandings > about "SHOULD" and "MAY" all the time, examples of which I can give > you if you like. And one of my favourites is when someone used > "RECOMMENDED", I questioned it in a comment, and the response was, > "Yes, maybe we should switch that to 'SHOULD'." > > For future reference, I tend not to zero-index my sentences. ;-) I think that MUST/SHOULD/MAY (the former two tempered by NOT) are well-understood, although the strength of SHOULD is usually underestimated. OPTIONAL is probably obvious enough (though its implications may not be), and SHALL/RECOMMENDED are uncommon enough that they're probably not understood nearly as well. > As a complete side thing, I wonder how this all seems to > German-speakers, as German uses initial caps for all nouns. I wonder > if anyone even notices if someone fails to do that. I wonder if it > becomes puzzling, perhaps in some instances. > > Barry > --001a1145ba2cef0a43052f48c23e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 30 March 2016 at 18:59, Barry Leiba <barryleiba@computer.org<= /a>> wrote:
&g= t;> That such a rule differs from natural English -- which does not typi= cally
>> alter semantics based on case -- and that most readers of RFCs wil= l not have
>> such detailed knowledge of RFC2119 nor read RFCs with the care suc= h a rule
>> demands, my question BARRY and adam and EveryOne Else, is what mak= es anyone
>> think that such a rule must (MUST?) ensure proper reading of RFCs = so as to
>> distinguish between normative portions and advisory portions?
>
> Sorry, I think that's nonsense. RFC 2119 and its capitalized keywo= rds are
> well known to anyone reading any specifications, these days. I think w= e can
> actually assume a priori knowledge of RFC 2119, for the most part. Wha= t I
> think would be far more surprising is this notion that the keywords, n= oted
> and referenced in capitals, also have the same precise meaning and for= ce
> when written normally.

I agree with the first and third sentences of what Dave Cridland sai= d,
but I think we have to be a little careful about the second.=C2=A0 What I think we can assume is an a priori knowledge of some of what 2119
says: that there are these capitalized key words that have special
meanings.=C2=A0 But it's quite clear from reviewing a lot of documents = (one
of the fun things one gets to do as AD) that many writers do not know
how 2119 actually defines those.=C2=A0 I see significant misunderstandings<= br> about "SHOULD" and "MAY" all the time, examples of whic= h I can give
you if you like.=C2=A0 And one of my favourites is when someone used
"RECOMMENDED", I questioned it in a comment, and the response was= ,
"Yes, maybe we should switch that to 'SHOULD'."


For future reference, I tend not to ze= ro-index my sentences. ;-)

I think that MUST/SHOUL= D/MAY (the former two tempered by NOT) are well-understood, although the st= rength of SHOULD is usually underestimated. OPTIONAL is probably obvious en= ough (though its implications may not be), and SHALL/RECOMMENDED are uncomm= on enough that they're probably not understood nearly as well.
=C2=A0
As a complete side thing, I wonder how this all seems to
German-speakers, as German uses initial caps for all nouns.=C2=A0 I wonder<= br> if anyone even notices if someone fails to do that.=C2=A0 I wonder if it becomes puzzling, perhaps in some instances.

Barry

--001a1145ba2cef0a43052f48c23e-- From nobody Wed Mar 30 12:28:53 2016 Return-Path: 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 60B8812D8DC; Wed, 30 Mar 2016 12:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 gT84TBMngq_O; Wed, 30 Mar 2016 12:28:47 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89AAF12D8C0; Wed, 30 Mar 2016 12:28:46 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id AE6A5E41A2EDA; Wed, 30 Mar 2016 19:28:40 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2UJSeHg022418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Mar 2016 19:28:40 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u2UJSdXj025878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Mar 2016 21:28:39 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.185]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 30 Mar 2016 21:28:39 +0200 From: "Drage, Keith (Nokia - GB)" To: EXT Dave Cridland , Barry Leiba Thread-Topic: [rtcweb] Uppercase question for RFC2119 words Thread-Index: AQHRirpc9Kg4wBKJA0+WsIoM8QGwTg== Date: Wed, 30 Mar 2016 19:28:39 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEB685F@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <56FBDE33.5000706@nostrum.com> <56FBE3F2.10507@dcrocker.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADEB685FFR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: IETF discussion list , "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , Dave Crocker , "Scott O. Bradner" , IESG Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 19:28:49 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADEB685FFR712WXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBkaXNjdXNzaW9uIHNlZW1zIHRvIGhhdmUgc3RhcnRlZCBiZWNhdXNlIHJ0Y3dlYiBwcm9k dWNlZCBhIGRvY3VtZW50IHdoZXJlIHRoZSBzdGF0dXMgKEJDUCwgaW5mb3JtYXRpdmUgb3Igc3Rh bmRhcmRzIHRyYWNrKSB3YXMgbm90IGNsZWFyIGFuZCBJIGNvdWxkIG5vdCBldmVuIHdvcmsgaXQg b3V0IGZyb20gdGhlIHVzZSBvZiBwc2V1ZG8gbm9ybWF0aXZlIGxhbmd1YWdlLg0KDQpJIHdvdWxk IG5vdGUgdGhhdCB0aGUgbWVhbmluZyBvZiBldmVuIGxvd2VyIGNhc2Ug4oCcbXVzdOKAnSBoYXMg dG8gYmUgY2xlYXIsIGFuZCBpbiBteSB2aWV3IHRoZXJlIGlzIGZyZXF1ZW50bHkgYW4gaW1wb3J0 YW50IGRpc3RpbmN0aW9uIGJldHdlZW4g4oCcaXMgb2JsaWdlZCB0b+KAnSBhbmQg4oCcaXMgZXhw ZWN0ZWQgdG/igJ0sIGFuZCBldmVuIOKAnHNob3VsZCBkb+KAnSwgYWxsIG9mIHdoaWNoIGFwcGVh ciB0byBiZSBhbGxvd2VkIGJ5IHRoZSBXZWJzdGVyIGRlZmluaXRpb24uIEZ1cnRoZXIsIGluIHRo ZSBPeGZvcmQgZGVmaW5pdGlvbiwgb25seSB0aGUgZmlyc3Qgb2YgdGhlc2Ugc2VlbXMgdG8gYmUg bWVhbnQsIHNvIHRoZXJlIGlzIHBvdGVudGlhbGx5IGFuIEF0bGFudGljIGRpdmlkZSBoZXJlLg0K DQpGdXJ0aGVyLCB3aGVuIEkgaGF2ZSBxdWVzdGlvbmVkIGluIHRoZSBwYXN0IHdoYXQgc29tZSBh dXRob3IgaGFzIG1lYW50IGJ5IHVzaW5nIOKAnG11c3TigJ0sIHdlIGZyZXF1ZW50bHkgZW5kIHVw IHVuZGVyc3RhbmRpbmcgdGhhdCBpdCB3YXMgbm90IG1lYW50IGF0IGFsbC4gU29tZXRpbWVzIGl0 IGlzIGhpZGluZyBhIHNvbWV3aGF0IGRpZmZlcmVudGx5IHBocmFzZWQg4oCcTVVTVOKAnSByZXF1 aXJlbWVudC4NCg0KSSBjb3VsZCBtYWtlIHNpbWlsYXIgYXJndW1lbnRzIGZvciBvdGhlciBtb2Rh bCBhdXhpbGlhcnlzLg0KDQpNeSBvdGhlciBhcmd1bWVudHMgZm9yIGF2b2lkaW5nIGxvd2VyIGNh c2UgdmVyc2lvbnMgYXJlIHRoYXQgb3RoZXIgc3RhbmRhcmRzIG9yZ2FuaXphdGlvbnMgKHdpdGgg b25lIGV4Y2VwdGlvbikgZG8gdXNlIGxvd2VyIGNhc2UgdmVyc2lvbnMgdG8gZXhwbGljaXRseSBk ZWZpbmUgcmVxdWlyZW1lbnRzLCBhbmQgdGhlIGRpc3RpbmN0aW9uIG9mIGEgdXNhZ2Ugd2l0aGlu IElFVEYgaXMgbm90IG5lY2Vzc2FyaWx5IHVuZGVyc3Rvb2QsIGFuZCBzZWNvbmRseSB0aGF0IGl0 IGlzIGZhciB0b28gZWFzeSBmb3IgYW4gZWRpdG9yIHdpdGggdGhlIG1pc2FwcGxpY2F0aW9uIG9m IGEgc2luZ2xlIGtleXByZXNzIHRvIGNvbnZlcnQgdGhlIGNhc2Ugb2YgYSB3b3JkLg0KDQpSZWdh cmRzDQoNCktlaXRoDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgRVhUIERhdmUgQ3JpZGxhbmQNClNlbnQ6IDMwIE1hcmNoIDIwMTYg MjA6MDENClRvOiBCYXJyeSBMZWliYQ0KQ2M6IElFVEYgZGlzY3Vzc2lvbiBsaXN0OyBIZWF0aGVy IEZsYW5hZ2FuIChSRkMgU2VyaWVzIEVkaXRvcik7IHJ0Y3dlYkBpZXRmLm9yZzsgSUVTRzsgU2Nv dHQgTy4gQnJhZG5lcjsgRGF2ZSBDcm9ja2VyDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gVXBwZXJj YXNlIHF1ZXN0aW9uIGZvciBSRkMyMTE5IHdvcmRzDQoNCg0KDQpPbiAzMCBNYXJjaCAyMDE2IGF0 IDE4OjU5LCBCYXJyeSBMZWliYSA8YmFycnlsZWliYUBjb21wdXRlci5vcmc8bWFpbHRvOmJhcnJ5 bGVpYmFAY29tcHV0ZXIub3JnPj4gd3JvdGU6DQo+PiBUaGF0IHN1Y2ggYSBydWxlIGRpZmZlcnMg ZnJvbSBuYXR1cmFsIEVuZ2xpc2ggLS0gd2hpY2ggZG9lcyBub3QgdHlwaWNhbGx5DQo+PiBhbHRl ciBzZW1hbnRpY3MgYmFzZWQgb24gY2FzZSAtLSBhbmQgdGhhdCBtb3N0IHJlYWRlcnMgb2YgUkZD cyB3aWxsIG5vdCBoYXZlDQo+PiBzdWNoIGRldGFpbGVkIGtub3dsZWRnZSBvZiBSRkMyMTE5IG5v ciByZWFkIFJGQ3Mgd2l0aCB0aGUgY2FyZSBzdWNoIGEgcnVsZQ0KPj4gZGVtYW5kcywgbXkgcXVl c3Rpb24gQkFSUlkgYW5kIGFkYW0gYW5kIEV2ZXJ5T25lIEVsc2UsIGlzIHdoYXQgbWFrZXMgYW55 b25lDQo+PiB0aGluayB0aGF0IHN1Y2ggYSBydWxlIG11c3QgKE1VU1Q/KSBlbnN1cmUgcHJvcGVy IHJlYWRpbmcgb2YgUkZDcyBzbyBhcyB0bw0KPj4gZGlzdGluZ3Vpc2ggYmV0d2VlbiBub3JtYXRp dmUgcG9ydGlvbnMgYW5kIGFkdmlzb3J5IHBvcnRpb25zPw0KPg0KPiBTb3JyeSwgSSB0aGluayB0 aGF0J3Mgbm9uc2Vuc2UuIFJGQyAyMTE5IGFuZCBpdHMgY2FwaXRhbGl6ZWQga2V5d29yZHMgYXJl DQo+IHdlbGwga25vd24gdG8gYW55b25lIHJlYWRpbmcgYW55IHNwZWNpZmljYXRpb25zLCB0aGVz ZSBkYXlzLiBJIHRoaW5rIHdlIGNhbg0KPiBhY3R1YWxseSBhc3N1bWUgYSBwcmlvcmkga25vd2xl ZGdlIG9mIFJGQyAyMTE5LCBmb3IgdGhlIG1vc3QgcGFydC4gV2hhdCBJDQo+IHRoaW5rIHdvdWxk IGJlIGZhciBtb3JlIHN1cnByaXNpbmcgaXMgdGhpcyBub3Rpb24gdGhhdCB0aGUga2V5d29yZHMs IG5vdGVkDQo+IGFuZCByZWZlcmVuY2VkIGluIGNhcGl0YWxzLCBhbHNvIGhhdmUgdGhlIHNhbWUg cHJlY2lzZSBtZWFuaW5nIGFuZCBmb3JjZQ0KPiB3aGVuIHdyaXR0ZW4gbm9ybWFsbHkuDQoNCkkg YWdyZWUgd2l0aCB0aGUgZmlyc3QgYW5kIHRoaXJkIHNlbnRlbmNlcyBvZiB3aGF0IERhdmUgQ3Jp ZGxhbmQgc2FpZCwNCmJ1dCBJIHRoaW5rIHdlIGhhdmUgdG8gYmUgYSBsaXR0bGUgY2FyZWZ1bCBh Ym91dCB0aGUgc2Vjb25kLiAgV2hhdCBJDQp0aGluayB3ZSBjYW4gYXNzdW1lIGlzIGFuIGEgcHJp b3JpIGtub3dsZWRnZSBvZiBzb21lIG9mIHdoYXQgMjExOQ0Kc2F5czogdGhhdCB0aGVyZSBhcmUg dGhlc2UgY2FwaXRhbGl6ZWQga2V5IHdvcmRzIHRoYXQgaGF2ZSBzcGVjaWFsDQptZWFuaW5ncy4g IEJ1dCBpdCdzIHF1aXRlIGNsZWFyIGZyb20gcmV2aWV3aW5nIGEgbG90IG9mIGRvY3VtZW50cyAo b25lDQpvZiB0aGUgZnVuIHRoaW5ncyBvbmUgZ2V0cyB0byBkbyBhcyBBRCkgdGhhdCBtYW55IHdy aXRlcnMgZG8gbm90IGtub3cNCmhvdyAyMTE5IGFjdHVhbGx5IGRlZmluZXMgdGhvc2UuICBJIHNl ZSBzaWduaWZpY2FudCBtaXN1bmRlcnN0YW5kaW5ncw0KYWJvdXQgIlNIT1VMRCIgYW5kICJNQVki IGFsbCB0aGUgdGltZSwgZXhhbXBsZXMgb2Ygd2hpY2ggSSBjYW4gZ2l2ZQ0KeW91IGlmIHlvdSBs aWtlLiAgQW5kIG9uZSBvZiBteSBmYXZvdXJpdGVzIGlzIHdoZW4gc29tZW9uZSB1c2VkDQoiUkVD T01NRU5ERUQiLCBJIHF1ZXN0aW9uZWQgaXQgaW4gYSBjb21tZW50LCBhbmQgdGhlIHJlc3BvbnNl IHdhcywNCiJZZXMsIG1heWJlIHdlIHNob3VsZCBzd2l0Y2ggdGhhdCB0byAnU0hPVUxEJy4iDQoN CkZvciBmdXR1cmUgcmVmZXJlbmNlLCBJIHRlbmQgbm90IHRvIHplcm8taW5kZXggbXkgc2VudGVu Y2VzLiA7LSkNCg0KSSB0aGluayB0aGF0IE1VU1QvU0hPVUxEL01BWSAodGhlIGZvcm1lciB0d28g dGVtcGVyZWQgYnkgTk9UKSBhcmUgd2VsbC11bmRlcnN0b29kLCBhbHRob3VnaCB0aGUgc3RyZW5n dGggb2YgU0hPVUxEIGlzIHVzdWFsbHkgdW5kZXJlc3RpbWF0ZWQuIE9QVElPTkFMIGlzIHByb2Jh Ymx5IG9idmlvdXMgZW5vdWdoICh0aG91Z2ggaXRzIGltcGxpY2F0aW9ucyBtYXkgbm90IGJlKSwg YW5kIFNIQUxML1JFQ09NTUVOREVEIGFyZSB1bmNvbW1vbiBlbm91Z2ggdGhhdCB0aGV5J3JlIHBy b2JhYmx5IG5vdCB1bmRlcnN0b29kIG5lYXJseSBhcyB3ZWxsLg0KDQpBcyBhIGNvbXBsZXRlIHNp ZGUgdGhpbmcsIEkgd29uZGVyIGhvdyB0aGlzIGFsbCBzZWVtcyB0bw0KR2VybWFuLXNwZWFrZXJz LCBhcyBHZXJtYW4gdXNlcyBpbml0aWFsIGNhcHMgZm9yIGFsbCBub3Vucy4gIEkgd29uZGVyDQpp ZiBhbnlvbmUgZXZlbiBub3RpY2VzIGlmIHNvbWVvbmUgZmFpbHMgdG8gZG8gdGhhdC4gIEkgd29u ZGVyIGlmIGl0DQpiZWNvbWVzIHB1enpsaW5nLCBwZXJoYXBzIGluIHNvbWUgaW5zdGFuY2VzLg0K DQpCYXJyeQ0KDQo= --_000_949EF20990823C4C85C18D59AA11AD8BADEB685FFR712WXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u aG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRoaXMgZGlzY3Vzc2lvbiBzZWVtcyB0byBoYXZlIHN0YXJ0ZWQgYmVjYXVz ZSBydGN3ZWIgcHJvZHVjZWQgYSBkb2N1bWVudCB3aGVyZSB0aGUgc3RhdHVzIChCQ1AsIGluZm9y bWF0aXZlIG9yIHN0YW5kYXJkcyB0cmFjaykgd2FzIG5vdCBjbGVhciBhbmQgSSBjb3VsZCBub3QN CiBldmVuIHdvcmsgaXQgb3V0IGZyb20gdGhlIHVzZSBvZiBwc2V1ZG8gbm9ybWF0aXZlIGxhbmd1 YWdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SSB3b3VsZCBub3RlIHRoYXQgdGhlIG1lYW5pbmcgb2YgZXZlbiBsb3dl ciBjYXNlIOKAnG11c3TigJ0gaGFzIHRvIGJlIGNsZWFyLCBhbmQgaW4gbXkgdmlldyB0aGVyZSBp cyBmcmVxdWVudGx5IGFuIGltcG9ydGFudCBkaXN0aW5jdGlvbiBiZXR3ZWVuIOKAnGlzIG9ibGln ZWQgdG/igJ0NCiBhbmQg4oCcaXMgZXhwZWN0ZWQgdG/igJ0sIGFuZCBldmVuIOKAnHNob3VsZCBk b+KAnSwgYWxsIG9mIHdoaWNoIGFwcGVhciB0byBiZSBhbGxvd2VkIGJ5IHRoZSBXZWJzdGVyIGRl ZmluaXRpb24uIEZ1cnRoZXIsIGluIHRoZSBPeGZvcmQgZGVmaW5pdGlvbiwgb25seSB0aGUgZmly c3Qgb2YgdGhlc2Ugc2VlbXMgdG8gYmUgbWVhbnQsIHNvIHRoZXJlIGlzIHBvdGVudGlhbGx5IGFu IEF0bGFudGljIGRpdmlkZSBoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RnVydGhlciwgd2hlbiBJIGhhdmUgcXVl c3Rpb25lZCBpbiB0aGUgcGFzdCB3aGF0IHNvbWUgYXV0aG9yIGhhcyBtZWFudCBieSB1c2luZyDi gJxtdXN04oCdLCB3ZSBmcmVxdWVudGx5IGVuZCB1cCB1bmRlcnN0YW5kaW5nIHRoYXQgaXQgd2Fz IG5vdCBtZWFudCBhdCBhbGwuIFNvbWV0aW1lcw0KIGl0IGlzIGhpZGluZyBhIHNvbWV3aGF0IGRp ZmZlcmVudGx5IHBocmFzZWQg4oCcTVVTVOKAnSByZXF1aXJlbWVudC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgY291 bGQgbWFrZSBzaW1pbGFyIGFyZ3VtZW50cyBmb3Igb3RoZXIgbW9kYWwgYXV4aWxpYXJ5cy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPk15IG90aGVyIGFyZ3VtZW50cyBmb3IgYXZvaWRpbmcgbG93ZXIgY2FzZSB2ZXJzaW9u cyBhcmUgdGhhdCBvdGhlciBzdGFuZGFyZHMgb3JnYW5pemF0aW9ucyAod2l0aCBvbmUgZXhjZXB0 aW9uKSBkbyB1c2UgbG93ZXIgY2FzZSB2ZXJzaW9ucyB0byBleHBsaWNpdGx5IGRlZmluZQ0KIHJl cXVpcmVtZW50cywgYW5kIHRoZSBkaXN0aW5jdGlvbiBvZiBhIHVzYWdlIHdpdGhpbiBJRVRGIGlz IG5vdCBuZWNlc3NhcmlseSB1bmRlcnN0b29kLCBhbmQgc2Vjb25kbHkgdGhhdCBpdCBpcyBmYXIg dG9vIGVhc3kgZm9yIGFuIGVkaXRvciB3aXRoIHRoZSBtaXNhcHBsaWNhdGlvbiBvZiBhIHNpbmds ZSBrZXlwcmVzcyB0byBjb252ZXJ0IHRoZSBjYXNlIG9mIGEgd29yZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2Fy ZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPktlaXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91 bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RVhUIERhdmUgQ3JpZGxhbmQ8YnI+ DQo8Yj5TZW50OjwvYj4gMzAgTWFyY2ggMjAxNiAyMDowMTxicj4NCjxiPlRvOjwvYj4gQmFycnkg TGVpYmE8YnI+DQo8Yj5DYzo8L2I+IElFVEYgZGlzY3Vzc2lvbiBsaXN0OyBIZWF0aGVyIEZsYW5h Z2FuIChSRkMgU2VyaWVzIEVkaXRvcik7IHJ0Y3dlYkBpZXRmLm9yZzsgSUVTRzsgU2NvdHQgTy4g QnJhZG5lcjsgRGF2ZSBDcm9ja2VyPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBV cHBlcmNhc2UgcXVlc3Rpb24gZm9yIFJGQzIxMTkgd29yZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIDMwIE1hcmNoIDIwMTYgYXQgMTg6NTksIEJhcnJ5IExlaWJhICZsdDs8 YSBocmVmPSJtYWlsdG86YmFycnlsZWliYUBjb21wdXRlci5vcmciIHRhcmdldD0iX2JsYW5rIj5i YXJyeWxlaWJhQGNvbXB1dGVyLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mZ3Q7Jmd0OyBU aGF0IHN1Y2ggYSBydWxlIGRpZmZlcnMgZnJvbSBuYXR1cmFsIEVuZ2xpc2ggLS0gd2hpY2ggZG9l cyBub3QgdHlwaWNhbGx5PGJyPg0KJmd0OyZndDsgYWx0ZXIgc2VtYW50aWNzIGJhc2VkIG9uIGNh c2UgLS0gYW5kIHRoYXQgbW9zdCByZWFkZXJzIG9mIFJGQ3Mgd2lsbCBub3QgaGF2ZTxicj4NCiZn dDsmZ3Q7IHN1Y2ggZGV0YWlsZWQga25vd2xlZGdlIG9mIFJGQzIxMTkgbm9yIHJlYWQgUkZDcyB3 aXRoIHRoZSBjYXJlIHN1Y2ggYSBydWxlPGJyPg0KJmd0OyZndDsgZGVtYW5kcywgbXkgcXVlc3Rp b24gQkFSUlkgYW5kIGFkYW0gYW5kIEV2ZXJ5T25lIEVsc2UsIGlzIHdoYXQgbWFrZXMgYW55b25l PGJyPg0KJmd0OyZndDsgdGhpbmsgdGhhdCBzdWNoIGEgcnVsZSBtdXN0IChNVVNUPykgZW5zdXJl IHByb3BlciByZWFkaW5nIG9mIFJGQ3Mgc28gYXMgdG88YnI+DQomZ3Q7Jmd0OyBkaXN0aW5ndWlz aCBiZXR3ZWVuIG5vcm1hdGl2ZSBwb3J0aW9ucyBhbmQgYWR2aXNvcnkgcG9ydGlvbnM/PGJyPg0K Jmd0Ozxicj4NCiZndDsgU29ycnksIEkgdGhpbmsgdGhhdCdzIG5vbnNlbnNlLiBSRkMgMjExOSBh bmQgaXRzIGNhcGl0YWxpemVkIGtleXdvcmRzIGFyZTxicj4NCiZndDsgd2VsbCBrbm93biB0byBh bnlvbmUgcmVhZGluZyBhbnkgc3BlY2lmaWNhdGlvbnMsIHRoZXNlIGRheXMuIEkgdGhpbmsgd2Ug Y2FuPGJyPg0KJmd0OyBhY3R1YWxseSBhc3N1bWUgYSBwcmlvcmkga25vd2xlZGdlIG9mIFJGQyAy MTE5LCBmb3IgdGhlIG1vc3QgcGFydC4gV2hhdCBJPGJyPg0KJmd0OyB0aGluayB3b3VsZCBiZSBm YXIgbW9yZSBzdXJwcmlzaW5nIGlzIHRoaXMgbm90aW9uIHRoYXQgdGhlIGtleXdvcmRzLCBub3Rl ZDxicj4NCiZndDsgYW5kIHJlZmVyZW5jZWQgaW4gY2FwaXRhbHMsIGFsc28gaGF2ZSB0aGUgc2Ft ZSBwcmVjaXNlIG1lYW5pbmcgYW5kIGZvcmNlPGJyPg0KJmd0OyB3aGVuIHdyaXR0ZW4gbm9ybWFs bHkuPGJyPg0KPGJyPg0KSSBhZ3JlZSB3aXRoIHRoZSBmaXJzdCBhbmQgdGhpcmQgc2VudGVuY2Vz IG9mIHdoYXQgRGF2ZSBDcmlkbGFuZCBzYWlkLDxicj4NCmJ1dCBJIHRoaW5rIHdlIGhhdmUgdG8g YmUgYSBsaXR0bGUgY2FyZWZ1bCBhYm91dCB0aGUgc2Vjb25kLiZuYnNwOyBXaGF0IEk8YnI+DQp0 aGluayB3ZSBjYW4gYXNzdW1lIGlzIGFuIGEgcHJpb3JpIGtub3dsZWRnZSBvZiBzb21lIG9mIHdo YXQgMjExOTxicj4NCnNheXM6IHRoYXQgdGhlcmUgYXJlIHRoZXNlIGNhcGl0YWxpemVkIGtleSB3 b3JkcyB0aGF0IGhhdmUgc3BlY2lhbDxicj4NCm1lYW5pbmdzLiZuYnNwOyBCdXQgaXQncyBxdWl0 ZSBjbGVhciBmcm9tIHJldmlld2luZyBhIGxvdCBvZiBkb2N1bWVudHMgKG9uZTxicj4NCm9mIHRo ZSBmdW4gdGhpbmdzIG9uZSBnZXRzIHRvIGRvIGFzIEFEKSB0aGF0IG1hbnkgd3JpdGVycyBkbyBu b3Qga25vdzxicj4NCmhvdyAyMTE5IGFjdHVhbGx5IGRlZmluZXMgdGhvc2UuJm5ic3A7IEkgc2Vl IHNpZ25pZmljYW50IG1pc3VuZGVyc3RhbmRpbmdzPGJyPg0KYWJvdXQgJnF1b3Q7U0hPVUxEJnF1 b3Q7IGFuZCAmcXVvdDtNQVkmcXVvdDsgYWxsIHRoZSB0aW1lLCBleGFtcGxlcyBvZiB3aGljaCBJ IGNhbiBnaXZlPGJyPg0KeW91IGlmIHlvdSBsaWtlLiZuYnNwOyBBbmQgb25lIG9mIG15IGZhdm91 cml0ZXMgaXMgd2hlbiBzb21lb25lIHVzZWQ8YnI+DQomcXVvdDtSRUNPTU1FTkRFRCZxdW90Oywg SSBxdWVzdGlvbmVkIGl0IGluIGEgY29tbWVudCwgYW5kIHRoZSByZXNwb25zZSB3YXMsPGJyPg0K JnF1b3Q7WWVzLCBtYXliZSB3ZSBzaG91bGQgc3dpdGNoIHRoYXQgdG8gJ1NIT1VMRCcuJnF1b3Q7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgZnV0dXJl IHJlZmVyZW5jZSwgSSB0ZW5kIG5vdCB0byB6ZXJvLWluZGV4IG15IHNlbnRlbmNlcy4gOy0pPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhp bmsgdGhhdCBNVVNUL1NIT1VMRC9NQVkgKHRoZSBmb3JtZXIgdHdvIHRlbXBlcmVkIGJ5IE5PVCkg YXJlIHdlbGwtdW5kZXJzdG9vZCwgYWx0aG91Z2ggdGhlIHN0cmVuZ3RoIG9mIFNIT1VMRCBpcyB1 c3VhbGx5IHVuZGVyZXN0aW1hdGVkLiBPUFRJT05BTCBpcyBwcm9iYWJseSBvYnZpb3VzIGVub3Vn aCAodGhvdWdoIGl0cyBpbXBsaWNhdGlvbnMgbWF5IG5vdCBiZSksIGFuZCBTSEFMTC9SRUNPTU1F TkRFRA0KIGFyZSB1bmNvbW1vbiBlbm91Z2ggdGhhdCB0aGV5J3JlIHByb2JhYmx5IG5vdCB1bmRl cnN0b29kIG5lYXJseSBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBhIGNvbXBsZXRlIHNpZGUgdGhpbmcsIEkgd29u ZGVyIGhvdyB0aGlzIGFsbCBzZWVtcyB0bzxicj4NCkdlcm1hbi1zcGVha2VycywgYXMgR2VybWFu IHVzZXMgaW5pdGlhbCBjYXBzIGZvciBhbGwgbm91bnMuJm5ic3A7IEkgd29uZGVyPGJyPg0KaWYg YW55b25lIGV2ZW4gbm90aWNlcyBpZiBzb21lb25lIGZhaWxzIHRvIGRvIHRoYXQuJm5ic3A7IEkg d29uZGVyIGlmIGl0PGJyPg0KYmVjb21lcyBwdXp6bGluZywgcGVyaGFwcyBpbiBzb21lIGluc3Rh bmNlcy48YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9 ImhvZW56YiI+QmFycnk8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_949EF20990823C4C85C18D59AA11AD8BADEB685FFR712WXCHMBA11z_-- From nobody Wed Mar 30 12:37:40 2016 Return-Path: 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 81E0D12D0AA; Wed, 30 Mar 2016 12:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 Q49aUaJB_ZBj; Wed, 30 Mar 2016 12:37:34 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE28F12D8C0; Wed, 30 Mar 2016 12:37:33 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 35D069E41754B; Wed, 30 Mar 2016 19:37:28 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2UJbVUE001574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Mar 2016 19:37:31 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u2UJbVhm007536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Mar 2016 21:37:31 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.185]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 30 Mar 2016 21:37:31 +0200 From: "Drage, Keith (Nokia - GB)" To: EXT Dave Cridland , Brian E Carpenter Thread-Topic: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] Thread-Index: AQHRiruYIu4rep67h06GX6nL2gUkyA== Date: Wed, 30 Mar 2016 19:37:29 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADEB68B1@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <8975F15F-5C4C-4D02-98CD-BF4FDF104D35@sobco.com> <56F98CD1.10706@gmail.com> <53A70D39871BEF8B0AE78195@JcK-HP8200.jck.com> <56FB13EB.1040809@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8BADEB68B1FR712WXCHMBA11z_" MIME-Version: 1.0 Archived-At: Cc: IETF discussion list , "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IESG , John C Klensin , Barry Leiba , "Scott O. Bradner" Subject: Re: [rtcweb] Fuzzy words [was Uppercase question for RFC2119 words] X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 19:37:36 -0000 --_000_949EF20990823C4C85C18D59AA11AD8BADEB68B1FR712WXCHMBA11z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXJyZXNwZWN0aXZlIG9mIHRoZSByZXN0IG9mIHRoaXMgZGlzY3Vzc2lvbiwgYSByZXZpZXdlciBz aG91bGQgYWx3YXlzIGFkZHJlc3MgZXZlcnkgdXBwZXIgYW5kIGxvd2VyIGNhc2UgdXNhZ2Ugb2Yg c3VjaCB2ZXJicyBhbmQgZW5zdXJlIHRoZXkgYXJlIGFwcHJvcHJpYXRlLCBiZWNhdXNlIHRoYXQg aXMgdGhlIHBsYWNlIG1vc3QgbWlzdGFrZXMgYXJlIG1hZGUgaW4gYmVpbmcgYWJzb2x1dGVseSBw cmVjaXNlIGFzIHRvIG1lYW5pbmcuDQoNCktlaXRoDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0 Y3dlYi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRVhUIERhdmUgQ3JpZGxhbmQNClNl bnQ6IDMwIE1hcmNoIDIwMTYgMDg6MjUNClRvOiBCcmlhbiBFIENhcnBlbnRlcg0KQ2M6IElFVEYg ZGlzY3Vzc2lvbiBsaXN0OyBIZWF0aGVyIEZsYW5hZ2FuIChSRkMgU2VyaWVzIEVkaXRvcik7IHJ0 Y3dlYkBpZXRmLm9yZzsgSUVTRzsgSm9obiBDIEtsZW5zaW47IEJhcnJ5IExlaWJhOyBTY290dCBP LiBCcmFkbmVyDQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0gRnV6enkgd29yZHMgW3dhcyBVcHBlcmNh c2UgcXVlc3Rpb24gZm9yIFJGQzIxMTkgd29yZHNdDQoNCg0KDQpPbiAzMCBNYXJjaCAyMDE2IGF0 IDAwOjQ2LCBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPG1h aWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+PiB3cm90ZToNCk9uIDMwLzAzLzIwMTYg MDU6MzQsIEpvaG4gQyBLbGVuc2luIHdyb3RlOg0KPg0KPg0KPiAtLU9uIFR1ZXNkYXksIE1hcmNo IDI5LCAyMDE2IDA4OjU4ICsxMzAwIEJyaWFuIEUgQ2FycGVudGVyDQo+IDxicmlhbi5lLmNhcnBl bnRlckBnbWFpbC5jb208bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4+IHdyb3Rl Og0KPg0KPj4gLi4uDQo+PiBUaGUgb3RoZXIgd29yZHMgKG11c3QsIHNoYWxsLCByZXF1aXJlZCwg bm90KSBtZWFuIHdoYXQgdGhleQ0KPj4gYWx3YXlzIG1lYW4uIFRoZSBvbmx5IGFyZ3VtZW50IGZv ciB1cHBlci1jYXNpbmcgdGhlbSBpcw0KPj4gYWVzdGhldGljIHN5bW1ldHJ5LiBJZiBhIHNwZWMg dXNlcyBhbHRlcm5hdGl2ZXMgbGlrZQ0KPj4gbWFuZGF0b3J5LCBuZWNlc3Nhcnkgb3IgZm9yYmlk ZGVuLCB0aGV5IGFyZSBqdXN0IGFzIHBvd2VyZnVsLg0KPj4gLi4uDQo+DQo+IEFjdHVhbGx5LCB3 aGVuIDIxMTkgaXMgcmVmZXJlbmNlZCwgU2VjdGlvbiA2IGF0dGFjaGVzIHBhcnRpY3VsYXINCj4g aW50ZXJvcGVyYWJpbGl0eSBzZW1hbnRpY3MgdG8gTVVTVCwgU0hBTEwsIGV0Yy4sIHRoYXQgYXJl IG5vdA0KPiBwYXJ0IG9mIHRoZSBwbGFpbi1FbmdsaXNoIG1lYW5pbmcgb2YgdGhvc2Ugd29yZHMu ICBTZWN0aW9uIDYNCj4gc2VlbXMgdG8gYmUgaWdub3JlZCBtb3N0IG9mIHRoZSB0aW1lIGJ1dCBj aXRlZCB3aGVuIGl0IHN1cHBvcnRzDQo+IGFuIGF4ZSBzb21lb25lIHdhbnRzIHRvIGdyaW5kIGFi b3V0IHVzZSBvZiBjb25mb3JtYW5jZSBsYW5ndWFnZS4NCg0KTXkgY2xhaW0gaXMgdGhhdCBldmVu IHNlY3Rpb24gNiBkb2VzICpub3QqIGNoYW5nZSB0aGUgbWVhbmluZ3MNCm9mIHRoZSBjYXRlZ29y aWNhbCB3b3JkcyBpbiBhIHNwZWMuIElmIGl0IHNheXMgdGhhdCBzb21ldGhpbmcNCm11c3Qgb3Ig bXVzdCBub3QgaGFwcGVuLCBlaXRoZXIgdGhlIHN0YXRlbWVudCBpcyByZWR1bmRhbnQgb3INCml0 IGlzIGVzc2VudGlhbCBmb3IgaW50ZXJvcGVyYWJpbGl0eSwgd2hldGhlciBpdCdzIHdyaXR0ZW4N CmluIHVwcGVyIGNhc2UgQ291cmllciBOZXcgb3IgaW4gcnVuZXMuDQoNCkkgc2hvdWxkIHRoaW5r IHlvdSBtdXN0IHJlYWxpc2UgdGhhdCBzaGFsbCBub3QgYWx3YXlzIGJlIHRoZSBjYXNlLg0KDQpC dXQgaXQgZG9lc24ndCBtYXR0ZXIuIEl0J3MgdGhlIFNIT1VMRHMgYW5kIE1BWXMgdGhhdCByZXF1 aXJlDQpwcmVjaXNpb24gaW4gdGhlaXIgdXNlLg0KDQogICAgICBCcmlhbg0KDQo= --_000_949EF20990823C4C85C18D59AA11AD8BADEB68B1FR712WXCHMBA11z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u aG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPklycmVzcGVjdGl2ZSBvZiB0aGUgcmVzdCBvZiB0aGlzIGRpc2N1c3Npb24s IGEgcmV2aWV3ZXIgc2hvdWxkIGFsd2F5cyBhZGRyZXNzIGV2ZXJ5IHVwcGVyIGFuZCBsb3dlciBj YXNlIHVzYWdlIG9mIHN1Y2ggdmVyYnMgYW5kIGVuc3VyZSB0aGV5IGFyZSBhcHByb3ByaWF0ZSwN CiBiZWNhdXNlIHRoYXQgaXMgdGhlIHBsYWNlIG1vc3QgbWlzdGFrZXMgYXJlIG1hZGUgaW4gYmVp bmcgYWJzb2x1dGVseSBwcmVjaXNlIGFzIHRvIG1lYW5pbmcuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5LZWl0aDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPkVYVCBEYXZlIENyaWRsYW5kPGJyPg0KPGI+U2VudDo8L2I+IDMwIE1hcmNo IDIwMTYgMDg6MjU8YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIEUgQ2FycGVudGVyPGJyPg0KPGI+Q2M6 PC9iPiBJRVRGIGRpc2N1c3Npb24gbGlzdDsgSGVhdGhlciBGbGFuYWdhbiAoUkZDIFNlcmllcyBF ZGl0b3IpOyBydGN3ZWJAaWV0Zi5vcmc7IElFU0c7IEpvaG4gQyBLbGVuc2luOyBCYXJyeSBMZWli YTsgU2NvdHQgTy4gQnJhZG5lcjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gRnV6 enkgd29yZHMgW3dhcyBVcHBlcmNhc2UgcXVlc3Rpb24gZm9yIFJGQzIxMTkgd29yZHNdPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAzMCBNYXJjaCAyMDE2IGF0IDAwOjQ2LCBC cmlhbiBFIENhcnBlbnRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5PbiAzMC8wMy8yMDE2IDA1OjM0LCBKb2huIEMgS2xlbnNpbiB3 cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS1PbiBUdWVzZGF5LCBNYXJjaCAy OSwgMjAxNiAwODo1OCAmIzQzOzEzMDAgQnJpYW4gRSBDYXJwZW50ZXI8YnI+DQomZ3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tIj5icmlhbi5lLmNhcnBl bnRlckBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgLi4u PGJyPg0KJmd0OyZndDsgVGhlIG90aGVyIHdvcmRzIChtdXN0LCBzaGFsbCwgcmVxdWlyZWQsIG5v dCkgbWVhbiB3aGF0IHRoZXk8YnI+DQomZ3Q7Jmd0OyBhbHdheXMgbWVhbi4gVGhlIG9ubHkgYXJn dW1lbnQgZm9yIHVwcGVyLWNhc2luZyB0aGVtIGlzPGJyPg0KJmd0OyZndDsgYWVzdGhldGljIHN5 bW1ldHJ5LiBJZiBhIHNwZWMgdXNlcyBhbHRlcm5hdGl2ZXMgbGlrZTxicj4NCiZndDsmZ3Q7IG1h bmRhdG9yeSwgbmVjZXNzYXJ5IG9yIGZvcmJpZGRlbiwgdGhleSBhcmUganVzdCBhcyBwb3dlcmZ1 bC48YnI+DQomZ3Q7Jmd0OyAuLi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBY3R1YWxseSwgd2hlbiAy MTE5IGlzIHJlZmVyZW5jZWQsIFNlY3Rpb24gNiBhdHRhY2hlcyBwYXJ0aWN1bGFyPGJyPg0KJmd0 OyBpbnRlcm9wZXJhYmlsaXR5IHNlbWFudGljcyB0byBNVVNULCBTSEFMTCwgZXRjLiwgdGhhdCBh cmUgbm90PGJyPg0KJmd0OyBwYXJ0IG9mIHRoZSBwbGFpbi1FbmdsaXNoIG1lYW5pbmcgb2YgdGhv c2Ugd29yZHMuJm5ic3A7IFNlY3Rpb24gNjxicj4NCiZndDsgc2VlbXMgdG8gYmUgaWdub3JlZCBt b3N0IG9mIHRoZSB0aW1lIGJ1dCBjaXRlZCB3aGVuIGl0IHN1cHBvcnRzPGJyPg0KJmd0OyBhbiBh eGUgc29tZW9uZSB3YW50cyB0byBncmluZCBhYm91dCB1c2Ugb2YgY29uZm9ybWFuY2UgbGFuZ3Vh Z2UuPGJyPg0KPGJyPg0KTXkgY2xhaW0gaXMgdGhhdCBldmVuIHNlY3Rpb24gNiBkb2VzICpub3Qq IGNoYW5nZSB0aGUgbWVhbmluZ3M8YnI+DQpvZiB0aGUgY2F0ZWdvcmljYWwgd29yZHMgaW4gYSBz cGVjLiBJZiBpdCBzYXlzIHRoYXQgc29tZXRoaW5nPGJyPg0KbXVzdCBvciBtdXN0IG5vdCBoYXBw ZW4sIGVpdGhlciB0aGUgc3RhdGVtZW50IGlzIHJlZHVuZGFudCBvcjxicj4NCml0IGlzIGVzc2Vu dGlhbCBmb3IgaW50ZXJvcGVyYWJpbGl0eSwgd2hldGhlciBpdCdzIHdyaXR0ZW48YnI+DQppbiB1 cHBlciBjYXNlIENvdXJpZXIgTmV3IG9yIGluIHJ1bmVzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzaG91bGQgdGhpbmsgeW91IG11c3QgcmVhbGlzZSB0 aGF0IHNoYWxsIG5vdCBhbHdheXMgYmUgdGhlIGNhc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+QnV0IGl0IGRvZXNuJ3QgbWF0dGVyLiBJdCdzIHRoZSBTSE9VTERzIGFuZCBNQVlz IHRoYXQgcmVxdWlyZTxicj4NCnByZWNpc2lvbiBpbiB0aGVpciB1c2UuPGJyPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPiZuYnNwOyAmbmJz cDsgJm5ic3A7IEJyaWFuPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_949EF20990823C4C85C18D59AA11AD8BADEB68B1FR712WXCHMBA11z_-- From nobody Wed Mar 30 15:51:58 2016 Return-Path: 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 B6C9412D8DA; Wed, 30 Mar 2016 12:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 TIlXtHtBtdRw; Wed, 30 Mar 2016 12:26:43 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACCC612D8DD; Wed, 30 Mar 2016 12:19:29 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id E2C6E3493BE; Wed, 30 Mar 2016 19:19:27 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D24BB160044; Wed, 30 Mar 2016 19:19:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BB5BC1600A3; Wed, 30 Mar 2016 19:19:27 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id IbPY4y66j2JX; Wed, 30 Mar 2016 19:19:27 +0000 (UTC) Received: from rock.dv.isc.org (host224.200-117-110.telecom.net.ar [200.117.110.224]) by zmx1.isc.org (Postfix) with ESMTPSA id 51E4F160044; Wed, 30 Mar 2016 19:19:27 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 5AEBF45A5010; Thu, 31 Mar 2016 06:19:26 +1100 (EST) To: Ole Jacobsen From: Mark Andrews References: <20160320223116.8946.76840.idtracker@ietfa.amsl.com> <949EF20990823C4C85C18D59AA11AD8BADEAFFC7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8BADEB0D16@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56F79D05.8070004@alvestrand.no> <326E6502-28E5-4D09-BB99-4A5D80625EB0@stewe.org> <56F88E18.2060506@it.aoyama.ac.jp> <20160328104731.GO88304@verdi> <20160328132859.GP88304@verdi> <28975138-9EA1-4A9F-A6C0-BC1416B8EA44@sobco.com> <56FBDE33.5000706@nostrum.com> <56FBE3F2.10507@dcrocker.net> <56FC0441.5090207@nostrum.com> In-reply-to: Your message of "Wed, 30 Mar 2016 10:24:53 -0700." Date: Thu, 31 Mar 2016 06:19:26 +1100 Message-Id: <20160330191926.5AEBF45A5010@rock.dv.isc.org> Archived-At: X-Mailman-Approved-At: Wed, 30 Mar 2016 15:51:57 -0700 Cc: IETF discussion list , "Heather Flanagan \(RFC Series Editor\)" , "rtcweb@ietf.org" , IESG , Barry Leiba , Pat Thaler , Dave Crocker Subject: Re: [rtcweb] Uppercase question for RFC2119 words X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 19:26:44 -0000 In message , Ole Jacobsen writes: > > On Wed, 30 Mar 2016, Pat Thaler wrote: > > > "must" has multiple meanings - it can indicate a requirement but it also > > can be used to state the inevitable: e.g., "What goes up must come down." > > > > Though in general, I'm not a fan of writing in all caps, "MUST" removes the > > ambiguity indicating that it is to be understood as defined, rather than > > having its regular English meaning. > > > > All caps for the words also helps the requirement statements stand out when > > scanning through a document. > > > > +1 > > A few years ago I stayed in a B&B in England. The owner asked me: "Do > you require toast in the morning?" This particular use of "require" > is not commonly used in the US (at least not on the West Coast) unless > toast is some kind of medical substance. > > All of which goes to show that words have different meaning and also > different USAGE, often location-based. "table" can mean "to put aside" or to "make the focus of discussion" or can be the actual physical item. > Ole > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org