From nobody Wed Sep 9 09:06:18 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 199001B3DAD for ; Wed, 9 Sep 2015 09:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, 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 144h6KHIsRmB for ; Wed, 9 Sep 2015 09:06:14 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.137]) (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 942D41B3DA5 for ; Wed, 9 Sep 2015 09:06:13 -0700 (PDT) Received: from [85.158.136.83] by server-1.bemta-5.messagelabs.com id 99/6F-32615-3F850F55; Wed, 09 Sep 2015 16:06:11 +0000 X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-16.tower-36.messagelabs.com!1441814767!22815595!1 X-Originating-IP: [195.232.244.133] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9938 invoked from network); 9 Sep 2015 16:06:07 -0000 Received: from mailout01.vodafone.com (HELO mailout01.vodafone.com) (195.232.244.133) by server-16.tower-36.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Sep 2015 16:06:07 -0000 Received: from mailint01.vodafone.com (mailint01.vodafone.com [195.232.244.198]) by mailout01.vodafone.com (Postfix) with ESMTP id 3nB7W25Sqyz1yHl; Wed, 9 Sep 2015 18:06:06 +0200 (CEST) Received: from mailint01.vodafone.com (localhost [127.0.0.1]) by mailint01.vodafone.com (Postfix) with ESMTP id 3nB7W23BnHzxPmn; Wed, 9 Sep 2015 18:06:06 +0200 (CEST) Received: from VOEXC06W.internal.vodafone.com (voexc06w.dc-ratingen.de [145.230.101.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint01.vodafone.com (Postfix) with ESMTPS id 3nB7W22pRJzxPNw; Wed, 9 Sep 2015 18:06:06 +0200 (CEST) Received: from VOEXC14W.internal.vodafone.com (145.230.101.16) by VOEXC06W.internal.vodafone.com (145.230.101.26) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 9 Sep 2015 18:06:06 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.43]) by voexc14w.internal.vodafone.com ([145.230.101.16]) with mapi id 14.03.0224.002; Wed, 9 Sep 2015 18:06:05 +0200 From: "Dawes, Peter, Vodafone Group" To: Adam Roach , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-dawes-sipcore-mediasec-parameter-02 Thread-Index: AQHQ1UmgEU/Q7T1CDkyUHDPp32v2TZ40fP9Q Date: Wed, 9 Sep 2015 16:06:04 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C84255C3@VOEXM31W.internal.vodafone.com> References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C83F65FF@VOEXM31W.internal.vodafone.com> <55CBC0D1.5050901@nostrum.com> In-Reply-To: <55CBC0D1.5050901@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C84255C3VOEXM31Winterna_" MIME-Version: 1.0 Archived-At: Cc: "dispatch-chairs@tools.ietf.org" , "art-ads@tools.ietf.org" Subject: Re: [sipcore] draft-dawes-sipcore-mediasec-parameter-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 16:06:17 -0000 --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C84255C3VOEXM31Winterna_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQWRhbSwNClRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHRoZSBjbGVhciBndWlkYW5jZSBhbmQg Y29tbWVudHMgb24gcHJvY2VkdXJlIGFuZCB0ZWNobmljYWwgaXNzdWVzIHdpdGggIGh0dHBzOi8v d3d3LmlldGYub3JnL2lkL2RyYWZ0LWRhd2VzLXNpcGNvcmUtbWVkaWFzZWMtcGFyYW1ldGVyLTAy LnR4dC4gSXQgc2VlbXMgdGhhdCB0aGUgZmlyc3Qgc3RlcCBpcyB0byBmaW5kIHRoZSBjb3JyZWN0 IHdvcmtpbmcgZ3JvdXAgdG8gZGlzY3VzcyB0aGlzIGRyYWZ0LiBJbiBjYXNlIGl0IGluZmx1ZW5j ZXMgd2hpY2ggSUVURiB3b3JraW5nIGdyb3VwIGlzIGFwcHJvcHJpYXRlLCBJIHNob3VsZCBwb2lu dCBvdXQgdGhhdCB0aGUgaGVhZGVyIGZpZWxkIHBhcmFtZXRlciBpbnRyb2R1Y2VkIGJ5IHRoaXMg ZHJhZnQgb3JpZ2luYXRlcyBmcm9tIDNHUFAgc3BlY2lmaWNhdGlvbnMgYW5kIHJlbGF0ZWQgcHJv Y2VkdXJlcyBhbmQgaGVhZGVyIGZpZWxkIHZhbHVlcyBhcmUgYWxzbyBkZXNjcmliZWQgaW4gM0dQ UCBzcGVjaWZpY2F0aW9ucy4gVGhlIHB1cnBvc2Ugb2YgdGhpcyBkcmFmdCBpcyB0byBuYW1lIHRo ZSBoZWFkZXIgZmllbGQgcGFyYW1ldGVyLCBnaXZlIHNldmVyYWwgaWxsdXN0cmF0aXZlIGV4YW1w bGVzIHRvIG1ha2UgaXQgY2xlYXIgaG93IGl0IGlzIHVzZWQsIGFuZCBzZXQgdXAgYW4gSUFOQSBy ZWdpc3RyeSBmb3IgZXhpc3RpbmcgYW5kIGZ1dHVyZSB2YWx1ZXMuIFRoZSBkcmFmdCBkb2VzIG5v dCBwcm9wb3NlIHRoYXQgSUVURiBkZWZpbmVzIGFueSBuZXcgc2VjdXJpdHkgc2V0dXAgcHJvY2Vk dXJlcywgY2lwaGVyaW5nLCBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBldGMuIFNob3VsZCBJIHBvc3Qg YWdhaW4gdG8gdGhlIGRpc3BhdGNoIGxpc3QsIG9yIGlzIGl0IG5vdyBhIHNpcGNvcmUgZGVjaXNp b24gd2hldGhlciB0aGUgZHJhZnQgYmVsb25ncyBpbiBzaXBjb3JlIG9yIHNvbWV3aGVyZSBlbHNl Pw0KSSByZWFsaXNlIHRoYXQgdGhlIG5vbnRyaXZpYWwgaXNzdWVzIHlvdSBpZGVudGlmeSBiZWxv dyBwcm9iYWJseSBuZWVkIHRvIGJlIGV4cGxvcmVkIGFuZCAoaWYgcG9zc2libGUpIHJlc29sdmVk LiBJIGNhbiByZXNwb25kIGhlcmUgb24gdGhlIHNpcGNvcmUgbGlzdCBidXQgSSBndWVzcyB0aGF0 IGRpc2N1c3Npb24gbWlnaHQgaGFwcGVuIGVsc2V3aGVyZS4NCg0KUmVnYXJkcywNClBldGVyDQoN CkZyb206IEFkYW0gUm9hY2ggW21haWx0bzphZGFtQG5vc3RydW0uY29tXQ0KU2VudDogMTIgQXVn dXN0IDIwMTUgMjI6NTUNClRvOiBEYXdlcywgUGV0ZXIsIFZvZGFmb25lIEdyb3VwOyBzaXBjb3Jl QGlldGYub3JnDQpDYzogYXJ0LWFkc0B0b29scy5pZXRmLm9yZzsgZGlzcGF0Y2gtY2hhaXJzQHRv b2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIGRyYWZ0LWRhd2VzLXNpcGNvcmUt bWVkaWFzZWMtcGFyYW1ldGVyLTAyDQoNCk9uIDgvMTAvMTUgMDM6NDYsIERhd2VzLCBQZXRlciwg Vm9kYWZvbmUgR3JvdXAgd3JvdGU6DQpIZWxsbyBBbGwsDQpodHRwczovL3d3dy5pZXRmLm9yZy9p ZC9kcmFmdC1kYXdlcy1zaXBjb3JlLW1lZGlhc2VjLXBhcmFtZXRlci0wMi50eHQgd2FzIGRpc3Bh dGNoLWVkIHRvIHRoZSBzaXBjb3JlIHdvcmtpbmcgZ3JvdXAgb3ZlciBhIHllYXIgYWdvIChzZWUg RnJvbTogQ3VsbGVuIEplbm5pbmdzIDxmbHVmZnkgYXQgaWlpLmNhPiwgVG86ICJkaXNwYXRjaCBh dCBpZXRmLm9yZyBsaXN0IiA8ZGlzcGF0Y2ggYXQgaWV0Zi5vcmc+LCBEYXRlOiBUdWUsIDUgTm92 IDIwMTMgMTY6NDA6MzkgLTA4MDApIGFuZCBJIHdvdWxkIGxpa2UgdG8gdHJ5IHRvIG1vdmUgaXQg dG93YXJkcyBhIGNvbmNsdXNpb24uDQoNClthcyBjaGFpcl0NCg0KUGV0ZXI6DQoNClRoYW5rcyBm b3IgYnJpbmdpbmcgdGhpcyB0byBvdXIgYXR0ZW50aW9uLiBJIGRpZCBtaXNzIHRoZSBvcmlnaW5h bCBESVNQQVRDSCBkZWNpc2lvbiB0byBzZW5kIGl0IHRvIFNJUENPUkU7IHR5cGljYWxseSwgcHJv cG9uZW50cyBvZiBkaXNwYXRjaGVkIHdvcmsgd2lsbCBicmluZyB0aGUgd29yayB0byB0aGUgYXR0 ZW50aW9uIG9mIHRoZSB3b3JraW5nIGdyb3VwIHRoYXQgdGhleSBoYXZlIGJlZW4gc2VudCB0byBp biByZWxhdGl2ZWx5IHNob3J0IG9yZGVyLg0KDQpVbmZvcnR1bmF0ZWx5LCBTSVBDT1JFIGlzIG5v dCB0aGUgY29ycmVjdCB2ZW51ZSBmb3IgdGhpcyB3b3JrIHVubGVzcyB3ZSBlbGVjdCB0byByZWNo YXJ0ZXIuIFRoZSBmdW5kYW1lbnRhbCBzdGF0ZW1lbnQgb2YgU0lQQ09SRSdzIHB1cnBvc2UgaXMg ZGVzY3JpYmVkIGluIGl0cyBjaGFydGVyIGFzOg0KVGhlIFNJUENvcmUgd29ya2luZyBncm91cCB3 aWxsIGNvbmNlbnRyYXRlIG9uIHNwZWNpZmljYXRpb25zIHRoYXQNCnVwZGF0ZSBvciByZXBsYWNl IHRoZSBjb3JlIFNJUCBzcGVjaWZpY2F0aW9ucy4gSW4gdGhpcyBjb250ZXh0LA0KInVwZGF0ZSIg bWVhbnMgcmVwbGFjaW5nIG9yIG1vZGlmeWluZyBwcm90b2NvbCBlbGVtZW50cyBpbiB0aGUgYWJv dmUNCmxpc3RlZCBSRkNzIGluIHdheXMgdGhhdCB3b3VsZCBhZmZlY3QgbW9zdCBvciBhbGwgaW1w bGVtZW50YXRpb25zIG9mDQp0aG9zZSBSRkNzIGFsb25lLiBFeHRlbnNpb25zIHRvIFNJUCB0aGF0 IGFkZCBuZXcgZnVuY3Rpb25hbGl0eSB0aGF0DQp3b3VsZCBub3QgYmUgcmVxdWlyZWQgb2YgYWxs IGltcGxlbWVudGF0aW9ucyB3aWxsIGJlIGRvbmUgb3V0c2lkZSBvZg0KdGhpcyBXRy4NCkFzIG11 Y2ggYXMgSSBoYXRlIHRoaXMga2luZCBvZiByZWRpcmVjdGlvbiwgSSBmZWFyIHRoYXQgdGhpcyB3 b3JrIGlzIGdvaW5nIHRvIG5lZWQgdG8gYmUgcmVkaXNwYXRjaGVkIGVpdGhlciB0byBhIGRpZmZl cmVudCBncm91cCAocGVyaGFwcyBTQUFHPykgb3Igc3BvbnNvcmVkIGJ5IGFuIGFyZWEgZGlyZWN0 b3IuDQoNCkJleW9uZCB0aGUgaXNzdWUgb2YgdmVudWUsIEkgdGhpbmsgdGhlcmUgYXJlIHNvbWUg bm9udHJpdmlhbCBpc3N1ZXMgd2l0aCB0aGUgZG9jdW1lbnQgYXMgaXQgaXMgY3VycmVudGx5IGZv cm11bGF0ZWQuIEFzIHlvdSBjb3JyZWN0bHkgcG9pbnQgb3V0LCBSRkMzMzI5IGRlYWxzIHdpdGgg aXNzdWVzIG9mIHNpZ25hbGluZyAoIm1ldGFkYXRhIiksIHdoaWxlIHRoaXMgcHJvcG9zYWwgZGVh bHMgd2l0aCBtZWRpYSAoYWN0dWFsIHVzZXIgY29udGVudCkuIFRoZXNlIGhhdmUgdmVyeSBkaWZm ZXJlbnQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYXNzb2NpYXRlZCB3aXRoIHRoZW0sIGFuZCBJ IGRvIG5vdCBiZWxpZXZlIHRoYXQgdGhlIFJGQzMzMjkgZnJhbWV3b3JrIHNlY3VyaXR5IGFuYWx5 c2lzIGNvbnRlbXBsYXRlZCBpdHMgZXh0ZW5zaW9uIHRvIHRoZSBtZWRpYSBwbGFuZS4NCg0KSSBh bHNvIG5vdGUgdGhhdCB0aGlzIGRvY3VtZW50IHNlZW1zIHRvIGJlIGF0dGVtcHRpbmcgdG8gc3Vi dmVydCB0aGUgcmVnaXN0cmF0aW9uIHBvbGljeSBkZWZpbmVkIGluIFJGQzMzMjksIHdoaWNoIHJl cXVpcmVzICJtZWNoYW5pc20tbmFtZSIgdmFsdWVzIHRvIGJlIElBTkEgcmVnaXN0ZXJlZCBhY2Nv cmRpbmcgdG8gdGhlIHBvbGljeSBjYWxsZWQgIklFVEYgQ29uc2Vuc3VzLiIgU2VjdGlvbiA5LjEg b2YgZHJhZnQtZGF3ZXMtc2lwY29yZS1tZWRpYXNlYy1wYXJhbWV0ZXItMDIgYXR0ZW1wdHMgdG8g cmVkZWZpbmUgbWVjaGFuaXNtLW5hbWUgcmVnaXN0cmF0aW9ucyB0byBpbnN0ZWFkIHVzZSB0aGUg bXVjaCBtb3JlIGxheCBwb2xpY3kgb2YgIlNwZWNpZmljYXRpb24gUmVxdWlyZWQiIGZvciBzZWN1 cml0eSBtZWNoYW5pc21zIHRoYXQgdXNlIHRoZSAibWVkaWFzZWMiIHBhcmFtZXRlci4gVGhpcyBr aW5kIG9mIHBvbGljeSBjaGFuZ2Ugd291bGQgbWluaW1hbGx5IHJlcXVpcmUgdGhlIGRvY3VtZW50 IHRvIGV4cGxpY2l0bHkgdXBkYXRlIFJGQzMzMjk7IGFuZCwgaW4gb3JkZXIgdG8gZG8gc28sIGl0 IHdvdWxkIG5lZWQgdG8gYmUgU3RhbmRhcmRzIFRyYWNrLg0KDQpBbnkgZG9jdW1lbnQgdGhhdCBj aGFuZ2VzIGFuIElBTkEgcmVnaXN0cmF0aW9uIHBvbGljeSwgYXMgdGhpcyBvbmUgZG9lcywgYWxz byBuZWVkcyBhIGRpc2N1c3Npb24gb2Ygd2h5IHRoZSB0aGUgYW5hbHlzaXMgdGhhdCBsZWFkIHRv IFdHIGNvbnNlbnN1cyBhcm91bmQgdGhlIG9yaWdpbmFsIHJlZ2lzdHJhdGlvbiBwb2xpY3kgd2Fz IGluY29ycmVjdC4NCg0KRmluYWxseSwgb24gYSBwZXJzb25hbCBub3RlLCBJIGJlbGlldmUgdGhh dCB0aGUgb3ZlcmFyY2hpbmcgZ29hbCBvZiBkZWZpbmluZyBuZXcgbWVjaGFuaXNtcyB0byBkZXBs b3kgU0RFUy1TUlRQICh3aGljaCBpcyBjbGVhcmx5IHRoZSBzb2xlIHB1cnBvc2Ugb2YgdGhpcyBk b2N1bWVudCkgcnVucyBjb3VudGVyIHRvIHRoZSBwcmV2YWlsaW5nIHNlY3VyaXR5IHByYWN0aWNl cyBpbiB0aGUgSUVURiwgYXMgZXZpZGVuY2VkIGJ5IChhKSB0aGUgcmVqZWN0aW9uIG9mIFNERVMt U1JUUCBmb3IgdXNlIGluIFJUQ1dFQjsgKGIpIHRoZSBwdWJsaWNhdGlvbiBvZiBSRkMgMjgwNDsg YW5kIChjKSB0aGUgcHVibGljYXRpb24gb2YgUkZDIDcyNTguIEkgc3VzcGVjdCB0aGF0IGEgZnVs bCBkZXByZWNhdGlvbiBvZiBTREVTLVNSVFAgaXMgbGlrZWx5IHRvIGhhcHBlbiBpbiB0aGUgZm9y ZXNlZWFibGUgZnV0dXJlLCBhbmQgY2VydGFpbmx5IHNlZSBubyB2YWx1ZSBpbiBpbnZlc3Rpbmcg bmV3IHdvcmsgaW4gcHJvbW90aW5nIGl0cyB1c2UuDQoNCi9hDQo= --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C84255C3VOEXM31Winterna_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 YmxhY2s7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hp dGUiIGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+SGVsbG8gQWRhbSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzIHZlcnkgbXVjaCBmb3Ig dGhlIGNsZWFyIGd1aWRhbmNlIGFuZCBjb21tZW50cyBvbiBwcm9jZWR1cmUgYW5kIHRlY2huaWNh bCBpc3N1ZXMgd2l0aCAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWRhd2VzLXNpcGNvcmUtbWVkaWFz ZWMtcGFyYW1ldGVyLTAyLnR4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPmh0dHBzOi8v d3d3LmlldGYub3JnL2lkL2RyYWZ0LWRhd2VzLXNpcGNvcmUtbWVkaWFzZWMtcGFyYW1ldGVyLTAy LnR4dDwvc3Bhbj48L2E+Lg0KIEl0IHNlZW1zIHRoYXQgdGhlIGZpcnN0IHN0ZXAgaXMgdG8gZmlu ZCB0aGUgY29ycmVjdCB3b3JraW5nIGdyb3VwIHRvIGRpc2N1c3MgdGhpcyBkcmFmdC4gSW4gY2Fz ZSBpdCBpbmZsdWVuY2VzIHdoaWNoIElFVEYgd29ya2luZyBncm91cCBpcyBhcHByb3ByaWF0ZSwg SSBzaG91bGQgcG9pbnQgb3V0IHRoYXQgdGhlIGhlYWRlciBmaWVsZCBwYXJhbWV0ZXIgaW50cm9k dWNlZCBieSB0aGlzIGRyYWZ0IG9yaWdpbmF0ZXMgZnJvbSAzR1BQIHNwZWNpZmljYXRpb25zDQog YW5kIHJlbGF0ZWQgcHJvY2VkdXJlcyBhbmQgaGVhZGVyIGZpZWxkIHZhbHVlcyBhcmUgYWxzbyBk ZXNjcmliZWQgaW4gM0dQUCBzcGVjaWZpY2F0aW9ucy4gVGhlIHB1cnBvc2Ugb2YgdGhpcyBkcmFm dCBpcyB0byBuYW1lIHRoZSBoZWFkZXIgZmllbGQgcGFyYW1ldGVyLCBnaXZlIHNldmVyYWwgaWxs dXN0cmF0aXZlIGV4YW1wbGVzIHRvIG1ha2UgaXQgY2xlYXIgaG93IGl0IGlzIHVzZWQsIGFuZCBz ZXQgdXAgYW4gSUFOQSByZWdpc3RyeSBmb3IgZXhpc3RpbmcNCiBhbmQgZnV0dXJlIHZhbHVlcy4g VGhlIGRyYWZ0IGRvZXMgbm90IHByb3Bvc2UgdGhhdCBJRVRGIGRlZmluZXMgYW55IG5ldyBzZWN1 cml0eSBzZXR1cCBwcm9jZWR1cmVzLCBjaXBoZXJpbmcsIGludGVncml0eSBwcm90ZWN0aW9uIGV0 Yy4gU2hvdWxkIEkgcG9zdCBhZ2FpbiB0byB0aGUgZGlzcGF0Y2ggbGlzdCwgb3IgaXMgaXQgbm93 IGEgc2lwY29yZSBkZWNpc2lvbiB3aGV0aGVyIHRoZSBkcmFmdCBiZWxvbmdzIGluIHNpcGNvcmUg b3Igc29tZXdoZXJlDQogZWxzZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSByZWFsaXNlIHRoYXQgdGhlIG5v bnRyaXZpYWwgaXNzdWVzIHlvdSBpZGVudGlmeSBiZWxvdyBwcm9iYWJseSBuZWVkIHRvIGJlIGV4 cGxvcmVkIGFuZCAoaWYgcG9zc2libGUpIHJlc29sdmVkLiBJIGNhbiByZXNwb25kIGhlcmUgb24g dGhlIHNpcGNvcmUgbGlzdCBidXQgSSBndWVzcyB0aGF0IGRpc2N1c3Npb24gbWlnaHQgaGFwcGVu IGVsc2V3aGVyZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVnYXJk cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+UGV0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1HQiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj4NCiBB ZGFtIFJvYWNoIFttYWlsdG86YWRhbUBub3N0cnVtLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IDEy IEF1Z3VzdCAyMDE1IDIyOjU1PGJyPg0KPGI+VG86PC9iPiBEYXdlcywgUGV0ZXIsIFZvZGFmb25l IEdyb3VwOyBzaXBjb3JlQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBhcnQtYWRzQHRvb2xzLmll dGYub3JnOyBkaXNwYXRjaC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtzaXBjb3JlXSBkcmFmdC1kYXdlcy1zaXBjb3JlLW1lZGlhc2VjLXBhcmFtZXRlci0w MjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biA4LzEwLzE1IDAzOjQ2LCBEYXdlcywgUGV0ZXIsIFZvZGFmb25lIEdyb3VwIHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvIEFsbCw8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL2lkL2RyYWZ0LWRhd2VzLXNpcGNvcmUtbWVkaWFzZWMtcGFyYW1ldGVyLTAyLnR4dCI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtZGF3ZXMtc2lwY29yZS1tZWRpYXNlYy1wYXJh bWV0ZXItMDIudHh0PC9hPiB3YXMgZGlzcGF0Y2gtZWQgdG8gdGhlIHNpcGNvcmUgd29ya2luZyBn cm91cCBvdmVyIGEgeWVhciBhZ28gKHNlZSBGcm9tOiBDdWxsZW4gSmVubmluZ3MNCiAmbHQ7Zmx1 ZmZ5IGF0IGlpaS5jYSZndDssIFRvOiAmcXVvdDtkaXNwYXRjaCBhdCBpZXRmLm9yZyBsaXN0JnF1 b3Q7ICZsdDtkaXNwYXRjaCBhdCBpZXRmLm9yZyZndDssIERhdGU6IFR1ZSwgNSBOb3YgMjAxMyAx Njo0MDozOSAtMDgwMCkgYW5kIEkgd291bGQgbGlrZSB0byB0cnkgdG8gbW92ZSBpdCB0b3dhcmRz IGEgY29uY2x1c2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCIj48YnI+DQpbYXMgY2hhaXJd PGJyPg0KPGJyPg0KUGV0ZXI6PGJyPg0KPGJyPg0KVGhhbmtzIGZvciBicmluZ2luZyB0aGlzIHRv IG91ciBhdHRlbnRpb24uIEkgZGlkIG1pc3MgdGhlIG9yaWdpbmFsIERJU1BBVENIIGRlY2lzaW9u IHRvIHNlbmQgaXQgdG8gU0lQQ09SRTsgdHlwaWNhbGx5LCBwcm9wb25lbnRzIG9mIGRpc3BhdGNo ZWQgd29yayB3aWxsIGJyaW5nIHRoZSB3b3JrIHRvIHRoZSBhdHRlbnRpb24gb2YgdGhlIHdvcmtp bmcgZ3JvdXAgdGhhdCB0aGV5IGhhdmUgYmVlbiBzZW50IHRvIGluIHJlbGF0aXZlbHkgc2hvcnQg b3JkZXIuPGJyPg0KPGJyPg0KVW5mb3J0dW5hdGVseSwgU0lQQ09SRSBpcyBub3QgdGhlIGNvcnJl Y3QgdmVudWUgZm9yIHRoaXMgd29yayB1bmxlc3Mgd2UgZWxlY3QgdG8gcmVjaGFydGVyLiBUaGUg ZnVuZGFtZW50YWwgc3RhdGVtZW50IG9mIFNJUENPUkUncyBwdXJwb3NlIGlzIGRlc2NyaWJlZCBp biBpdHMgY2hhcnRlciBhczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+VGhlIFNJUENvcmUgd29ya2luZyBn cm91cCB3aWxsIGNvbmNlbnRyYXRlIG9uIHNwZWNpZmljYXRpb25zIHRoYXQ8YnI+DQp1cGRhdGUg b3IgcmVwbGFjZSB0aGUgY29yZSBTSVAgc3BlY2lmaWNhdGlvbnMuIEluIHRoaXMgY29udGV4dCw8 YnI+DQomcXVvdDt1cGRhdGUmcXVvdDsgbWVhbnMgcmVwbGFjaW5nIG9yIG1vZGlmeWluZyBwcm90 b2NvbCBlbGVtZW50cyBpbiB0aGUgYWJvdmU8YnI+DQpsaXN0ZWQgUkZDcyBpbiB3YXlzIHRoYXQg d291bGQgYWZmZWN0IG1vc3Qgb3IgYWxsIGltcGxlbWVudGF0aW9ucyBvZjxicj4NCnRob3NlIFJG Q3MgYWxvbmUuIEV4dGVuc2lvbnMgdG8gU0lQIHRoYXQgYWRkIG5ldyBmdW5jdGlvbmFsaXR5IHRo YXQ8YnI+DQp3b3VsZCBub3QgYmUgcmVxdWlyZWQgb2YgYWxsIGltcGxlbWVudGF0aW9ucyB3aWxs IGJlIGRvbmUgb3V0c2lkZSBvZjxicj4NCnRoaXMgV0cuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLUdCIj5BcyBtdWNoIGFzIEkgaGF0ZSB0aGlzIGtpbmQgb2YgcmVk aXJlY3Rpb24sIEkgZmVhciB0aGF0IHRoaXMgd29yayBpcyBnb2luZyB0byBuZWVkIHRvIGJlIHJl ZGlzcGF0Y2hlZCBlaXRoZXIgdG8gYSBkaWZmZXJlbnQgZ3JvdXAgKHBlcmhhcHMgU0FBRz8pDQog b3Igc3BvbnNvcmVkIGJ5IGFuIGFyZWEgZGlyZWN0b3IuPGJyPg0KPGJyPg0KQmV5b25kIHRoZSBp c3N1ZSBvZiB2ZW51ZSwgSSB0aGluayB0aGVyZSBhcmUgc29tZSBub250cml2aWFsIGlzc3VlcyB3 aXRoIHRoZSBkb2N1bWVudCBhcyBpdCBpcyBjdXJyZW50bHkgZm9ybXVsYXRlZC4gQXMgeW91IGNv cnJlY3RseSBwb2ludCBvdXQsIFJGQzMzMjkgZGVhbHMgd2l0aCBpc3N1ZXMgb2Ygc2lnbmFsaW5n ICgmcXVvdDttZXRhZGF0YSZxdW90OyksIHdoaWxlIHRoaXMgcHJvcG9zYWwgZGVhbHMgd2l0aCBt ZWRpYSAoYWN0dWFsIHVzZXIgY29udGVudCkuDQogVGhlc2UgaGF2ZSB2ZXJ5IGRpZmZlcmVudCBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhc3NvY2lhdGVkIHdpdGggdGhlbSwgYW5kIEkgZG8gbm90 IGJlbGlldmUgdGhhdCB0aGUgUkZDMzMyOSBmcmFtZXdvcmsgc2VjdXJpdHkgYW5hbHlzaXMgY29u dGVtcGxhdGVkIGl0cyBleHRlbnNpb24gdG8gdGhlIG1lZGlhIHBsYW5lLjxicj4NCjxicj4NCkkg YWxzbyBub3RlIHRoYXQgdGhpcyBkb2N1bWVudCBzZWVtcyB0byBiZSBhdHRlbXB0aW5nIHRvIHN1 YnZlcnQgdGhlIHJlZ2lzdHJhdGlvbiBwb2xpY3kgZGVmaW5lZCBpbiBSRkMzMzI5LCB3aGljaCBy ZXF1aXJlcyAmcXVvdDttZWNoYW5pc20tbmFtZSZxdW90OyB2YWx1ZXMgdG8gYmUgSUFOQSByZWdp c3RlcmVkIGFjY29yZGluZyB0byB0aGUgcG9saWN5IGNhbGxlZCAmcXVvdDtJRVRGIENvbnNlbnN1 cy4mcXVvdDsgU2VjdGlvbiA5LjEgb2YgZHJhZnQtZGF3ZXMtc2lwY29yZS1tZWRpYXNlYy1wYXJh bWV0ZXItMDINCiBhdHRlbXB0cyB0byByZWRlZmluZSBtZWNoYW5pc20tbmFtZSByZWdpc3RyYXRp b25zIHRvIGluc3RlYWQgdXNlIHRoZSBtdWNoIG1vcmUgbGF4IHBvbGljeSBvZiAmcXVvdDtTcGVj aWZpY2F0aW9uIFJlcXVpcmVkJnF1b3Q7IGZvciBzZWN1cml0eSBtZWNoYW5pc21zIHRoYXQgdXNl IHRoZSAmcXVvdDttZWRpYXNlYyZxdW90OyBwYXJhbWV0ZXIuIFRoaXMga2luZCBvZiBwb2xpY3kg Y2hhbmdlIHdvdWxkIG1pbmltYWxseSByZXF1aXJlIHRoZSBkb2N1bWVudCB0byBleHBsaWNpdGx5 IHVwZGF0ZQ0KIFJGQzMzMjk7IGFuZCwgaW4gb3JkZXIgdG8gZG8gc28sIGl0IHdvdWxkIG5lZWQg dG8gYmUgU3RhbmRhcmRzIFRyYWNrLjxicj4NCjxicj4NCkFueSBkb2N1bWVudCB0aGF0IGNoYW5n ZXMgYW4gSUFOQSByZWdpc3RyYXRpb24gcG9saWN5LCBhcyB0aGlzIG9uZSBkb2VzLCBhbHNvIG5l ZWRzIGEgZGlzY3Vzc2lvbiBvZiB3aHkgdGhlIHRoZSBhbmFseXNpcyB0aGF0IGxlYWQgdG8gV0cg Y29uc2Vuc3VzIGFyb3VuZCB0aGUgb3JpZ2luYWwgcmVnaXN0cmF0aW9uIHBvbGljeSB3YXMgaW5j b3JyZWN0Ljxicj4NCjxicj4NCkZpbmFsbHksIG9uIGEgcGVyc29uYWwgbm90ZSwgSSBiZWxpZXZl IHRoYXQgdGhlIG92ZXJhcmNoaW5nIGdvYWwgb2YgZGVmaW5pbmcgbmV3IG1lY2hhbmlzbXMgdG8g ZGVwbG95IFNERVMtU1JUUCAod2hpY2ggaXMgY2xlYXJseSB0aGUgc29sZSBwdXJwb3NlIG9mIHRo aXMgZG9jdW1lbnQpIHJ1bnMgY291bnRlciB0byB0aGUgcHJldmFpbGluZyBzZWN1cml0eSBwcmFj dGljZXMgaW4gdGhlIElFVEYsIGFzIGV2aWRlbmNlZCBieSAoYSkgdGhlIHJlamVjdGlvbg0KIG9m IFNERVMtU1JUUCBmb3IgdXNlIGluIFJUQ1dFQjsgKGIpIHRoZSBwdWJsaWNhdGlvbiBvZiBSRkMg MjgwNDsgYW5kIChjKSB0aGUgcHVibGljYXRpb24gb2YgUkZDIDcyNTguIEkgc3VzcGVjdCB0aGF0 IGEgZnVsbCBkZXByZWNhdGlvbiBvZiBTREVTLVNSVFAgaXMgbGlrZWx5IHRvIGhhcHBlbiBpbiB0 aGUgZm9yZXNlZWFibGUgZnV0dXJlLCBhbmQgY2VydGFpbmx5IHNlZSBubyB2YWx1ZSBpbiBpbnZl c3RpbmcgbmV3IHdvcmsgaW4gcHJvbW90aW5nDQogaXRzIHVzZS48YnI+DQo8YnI+DQovYTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C84255C3VOEXM31Winterna_-- From nobody Fri Sep 11 04:08:47 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8F81A8963 for ; Fri, 11 Sep 2015 04:08:45 -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, HTML_MESSAGE=0.001, 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 wGOqvt2kj3HF for ; Fri, 11 Sep 2015 04:08:39 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C9A41B2F7A for ; Fri, 11 Sep 2015 04:08:38 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-40-55f2b6355097 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BD.5D.29154.536B2F55; Fri, 11 Sep 2015 13:08:37 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.81]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Fri, 11 Sep 2015 13:08:36 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: Errata suggestion: RFC 7315 ABNF correction Thread-Index: AdDsgiu7UmSpSAlwSzGJzef76BU8Ag== Date: Fri, 11 Sep 2015 11:08:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37A73B64@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.20] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37A73B64ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+Jvja7ptk+hBo8nSlp8/bGJzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGRM2tjAWnPao2Lu3g72B8ax9FyMHh4SAicSCqSZdjJxAppjE hXvr2boYuTiEBI4ySsybP4kFwlnMKHFy82V2kAY2AQuJ7n/aIA0iApoSy79tBQsLA805sbAK ImwpcffVb0YIW0/i5uo5TCA2i4CqxJHd51hAbF4BX4kZS2exgtiMQHu/n1oDVsMsIC5x68l8 Joh7BCSW7DnPDGGLSrx8/I8VwlaUuDp9OVR9vsT+S/cYIWYKSpyc+YRlAqPQLCSjZiEpm4Wk DCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9iFC1OLS7OTTcy0kstykwuLs7P08tLLdnE CIyHg1t+W+1gPPjc8RCjAAejEg/vAtNPoUKsiWXFlbmHGKU5WJTEeZuZHoQKCaQnlqRmp6YW pBbFF5XmpBYfYmTi4JRqYJR43d8ya34NK8vmZHkPv3tTzs/9vfavx/Knn9oUczft/rhi9u7H wcu6FgotCLxmG5R39ON6WYO1y/hPXfAJ+FfypMxdMqm94cbX7ZPdb1psWFXtyyYwM6NXXE7G 62HSFynFGT/27fr7bWrxg/6KhiNxx6NPmgp7q8/4sTfx0sXnOtPn/5a6e1dWiaU4I9FQi7mo OBEA8DWEDmgCAAA= Archived-At: Subject: [sipcore] Errata suggestion: RFC 7315 ABNF correction X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 11:08:45 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37A73B64ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, At the previous 3GPP CT1 meeting an issue with the ABNF in RFC 7315 was rai= sed. The ABNF says: access-info =3D cgi-3gpp / utran-cell-id-3gp= p / dsl-location / i-= wlan-node-id / ci-3gpp2 / eth-lo= cation / ci-3gpp2-femto / = fiber-location / np / gstn-locatio= n /local-time-zone / dvb-rcs2-node-id = / extension-access-info np =3D "network-provided" extension-access-info =3D gen-value All current access-info values, except for 'np', are according to generic-p= aram, but the ABNF only allows gen-value for new values. We believe that ne= w values should also be according to generic-param. (From RFC 3261: generic-param =3D token [ EQUAL gen-value ]) OLD: extension-access-info =3D gen-value NEW: extension-access-info =3D generic-param My suggestion is to open an errata for this, and fix the ABNF. Comments? Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37A73B64ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

At the previous 3GPP CT1 meetin= g an issue with the ABNF in RFC 7315 was raised.

 

The ABNF says:

 

access-info   &n= bsp;        =3D     =             &nb= sp;   cgi-3gpp / utran-cell-id-3gpp /

     &= nbsp;           &nbs= p;             =             &nb= sp;            =   dsl-location / i-wlan-node-id /

     &= nbsp;           &nbs= p;             =             &nb= sp;            =   ci-3gpp2 / eth-location /

     &= nbsp;           &nbs= p;             =             &nb= sp;            =   ci-3gpp2-femto / fiber-location /

     &= nbsp;           &nbs= p;             =             &nb= sp;            =   np / gstn-location /local-time-zone /

     &= nbsp;           &nbs= p;             =             &nb= sp;            =   dvb-rcs2-node-id / extension-access-info

np     = ;            &n= bsp;   =3D          =             &nb= sp;      "network-provided"

extension-access-info  =3D=         gen-value

 

All current access-info values,= except for ‘np’, are according to generic-param, but the ABNF = only allows gen-value for new values. We believe that new values should als= o be according to generic-param.

 

(From RFC 3261: generic-param&n= bsp; =3D  token [ EQUAL gen-value ])

 

OLD:

 

ex= tension-access-info  =3D         ge= n-value

 

 

NEW:

 

ex= tension-access-info  =3D         ge= neric-param

 

 

My suggestion is to open an err= ata for this, and fix the ABNF.

 

Comments?

 

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B37A73B64ESESSMB209erics_-- From nobody Fri Sep 11 09:09:57 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16321B31FF for ; Fri, 11 Sep 2015 09:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 LmxVXwx-4LHr for ; Fri, 11 Sep 2015 09:09:53 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06B51B2A0A for ; Fri, 11 Sep 2015 09:09:53 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-11v.sys.comcast.net with comcast id Fs9p1r0072Udklx01s9sK5; Fri, 11 Sep 2015 16:09:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-18v.sys.comcast.net with comcast id Fs9s1r0083Ge9ey01s9s1b; Fri, 11 Sep 2015 16:09:52 +0000 To: sipcore@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37A73B64@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <55F2FCCF.5050803@alum.mit.edu> Date: Fri, 11 Sep 2015 12:09:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37A73B64@ESESSMB209.ericsson.se> 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=1441987792; bh=5N/HcplOKftC+/JIx19LpoRb6QglB4ND069+l8nD7Lg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=MpXZUyAI7DCmI6exBQ/8QO3EN19mbuEdgM8L/OUeOao5St5EK1W0npBu6uMvQ0u0J seD9GRTihJk9IkpvHu0r1tsmZUcId1dNgW97sbzEPFzgrp4apk+eH39XH07fcZGXtf qVFrpzMNrwVDWUP3UhcMdKJ2kPm1ax8FJQ+71QTixyzP4OxG0s0W3ISXK5tRs/hcN6 0UcAR7spDTXoM8YO7Q1nPagjMsaDIuewOTJj9aNd/KmLmwZirT61d0EfP9rh5xg4mh PvRgijRdJ4am1xnM4dm5NFrkXQH8CRnluaQq/4dmMKMn2ddE5lj+MfR8Eo5e0yZ9Lh 0XPOdMUr0DptQ== Archived-At: Subject: Re: [sipcore] Errata suggestion: RFC 7315 ABNF correction X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 16:09:55 -0000 What is proposed makes sense - it is in the spirit of most typical header syntax. The only real concern I can see here is with backward compatibility. Because the revision allows syntax that was previously forbidden, an entity that hasn't been updated may reject a request containing such new syntax. Whether that is practical problem depends on deployment. RFC7315 doesn't seem to say anything about how a request containing extension-access-info should be processed. Typically unknown stuff matching an extension point it to be ignored, but nothing is said about it in this draft. Also, there is no mention of when and how extensions may be introduced. Lacking any other statement, I presume it would take an update/revision to this rfc to define a new access-info value. If so, that at least means there would be no backward compatibility concern until there is such a revision. Thanks, Paul On 9/11/15 7:08 AM, Christer Holmberg wrote: > Hi, > > At the previous 3GPP CT1 meeting an issue with the ABNF in RFC 7315 was > raised. > > The ABNF says: > > access-info = cgi-3gpp / utran-cell-id-3gpp / > > dsl-location > / i-wlan-node-id / > > ci-3gpp2 / > eth-location / > > > ci-3gpp2-femto / fiber-location / > > np / > gstn-location /local-time-zone / > > > dvb-rcs2-node-id / extension-access-info > > np = "network-provided" > > extension-access-info = gen-value > > All current access-info values, except for ‘np’, are according to > generic-param, but the ABNF only allows gen-value for new values. We > believe that new values should also be according to generic-param. > > (From RFC 3261: generic-param = token [ EQUAL gen-value ]) > > OLD: > > extension-access-info = gen-value > > NEW: > > extension-access-info = generic-param > > My suggestion is to open an errata for this, and fix the ABNF. > > Comments? > > Regards, > > Christer > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Fri Sep 11 09:51:13 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0701A914D for ; Fri, 11 Sep 2015 09:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.08 X-Spam-Level: X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, 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 PP2vBQDHibwZ for ; Fri, 11 Sep 2015 09:51:08 -0700 (PDT) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 EFF551A914B for ; Fri, 11 Sep 2015 09:51:07 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so69961613wic.1 for ; Fri, 11 Sep 2015 09:51:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=FAbDGiMkFqP93mLw8TSCmLYbL+sKiYLuTFq9pS59njA=; b=fAvlEQqR/r2qQvXmqWYG13xiXcS+pT644+xmTwaTEjGMw/Sqdonibelnk0y/IM/gbO Oj+OmqqpqElqGt/zSYlGeQQDlTf+Cm9y3vTjAsDv+jXUbCQWfcUzqMgyI6GG4HQyyTPr AILZS1YoibgSwEDiWFn7bAriONyeqKgIEkoixLY13fL0za6zqKpZhyV6FrkiRU8JZLgm xonjDJzOwnQCmiSAesrkjGxsBFJw0SJ+fdf4Kh3hzKOcJJpYTGShZ5cu+6S583C1GV/6 47q4WDQtlooyhJwbOPepznQ4UeXNfitVBNGVaygMZEk06W6GGs4RO4vWMl3J/K6qSStR jaGQ== X-Gm-Message-State: ALoCoQkQXZyZaWe8MacgSBQjBkvKrlwh2/EhlxRE8mpaFoivFgm+1tRTWLZPS5lZthDd3cxyrGTf X-Received: by 10.180.35.199 with SMTP id k7mr6509738wij.13.1441990266564; Fri, 11 Sep 2015 09:51:06 -0700 (PDT) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDsserSXLEsXrb8TbCYKv0J3LObUw== Date: Fri, 11 Sep 2015 12:51:05 -0400 Message-ID: <3469371478b94e3366d247ced38636c6@mail.gmail.com> To: sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [sipcore] RFC 7315: P-Charging-Function-Addresses questions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 16:51:11 -0000 Hi, Since I received no reply on sip-implementors, I thought that I'd try sipcore. Is only one P-Charging-Function-Addresses header allowed within a SIP message? I assume yes because of the following snippet. RFC 7315 section 4.5: "When present, only one instance of the header MUST be present in a particular request or response." Can P-Charging-Function-Addresses header contain a third ecf (or ccf) address? Based upon the use of "header field" (instead of "header field value") within the following snippet and 3GPP TS 24.229 V13.2.0 only mentioning primary and secondary, I assume that it would be considered unexpected (unless maybe accommodating RFC 3455 devices). RFC 7315 section 5.5: "The P-Charging-Function-Addresses header field contains one or two addresses of the ECF (ecf and ecf-2) or CCF (ccf and ccf-2)." Thanks, Brett From nobody Fri Sep 11 13:02:02 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF7F1B519D for ; Fri, 11 Sep 2015 13:02:01 -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, 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 V2udEokZw44P for ; Fri, 11 Sep 2015 13:01:59 -0700 (PDT) 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 602431B515B for ; Fri, 11 Sep 2015 13:01:59 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-49-55f333352ac8 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C5.32.05274.53333F55; Fri, 11 Sep 2015 22:01:57 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.81]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Fri, 11 Sep 2015 22:01:57 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Errata suggestion: RFC 7315 ABNF correction Thread-Index: AdDsgiu7UmSpSAlwSzGJzef76BU8AgAGVqCAAAwFLoA= Date: Fri, 11 Sep 2015 20:01:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37A776B9@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37A73B64@ESESSMB209.ericsson.se> <55F2FCCF.5050803@alum.mit.edu> In-Reply-To: <55F2FCCF.5050803@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvja6p8edQgzMn1C1WbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj9OSZbAXfxCsOX7/M0sC4WLCLkZNDQsBE YlnnXBYIW0ziwr31bF2MXBxCAkcZJY6/W8UO4SxmlGg89QIow8HBJmAh0f1PG6RBRCBQ4uqS CcwgtrCAk8STrxdZIOLOEt1tN5ghbCuJ+8v2gcVZBFQldv7cyQhi8wr4SrT3PWMFsYUE8iUO 9c5kArE5BXQk1jf+AetlBDro+6k1YHFmAXGJW0/mM0EcKiCxZM95ZghbVOLl43+sELaSxKLb n6HqdSQW7P7EBmFrSyxb+JoZYq+gxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsopRtDi1OCk3 3chYL7UoM7m4OD9PLy+1ZBMjME4ObvmtuoPx8hvHQ4wCHIxKPLwLTD+FCrEmlhVX5h5ilOZg URLnbWZ6ECokkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB0eqq9t+if3HXjeqkC8IPvjg2W3Xa 9oVFmgkWp94U7TiwNTJLpmRy6bqTf8tfTN5YV1R5zeV31rk9EqovLvmGKjLFrExbG9C+qkrw KFO+p5eI9t2U5zHMmocN5k34NPlNxpw8l4rHM079/zjLRHTbkutRxytd/V7nsGyYkhIw0/xg U+OlmgpuLyWW4oxEQy3mouJEAFxwGWh0AgAA Archived-At: Subject: Re: [sipcore] Errata suggestion: RFC 7315 ABNF correction X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 20:02:01 -0000 Hi, > What is proposed makes sense - it is in the spirit of most typical header= syntax. > > The only real concern I can see here is with backward compatibility.=20 > Because the revision allows syntax that was previously forbidden, an enti= ty that hasn't been updated may reject a > request containing such new syntax. Whether that is practical problem dep= ends on deployment. I am pretty sure 3GPP is the only user of this header field, and 3GPP agree= d to bring the suggested change to IETF. > RFC7315 doesn't seem to say anything about how a request containing exten= sion-access-info should be processed. Typically=20 > unknown stuff matching an extension point it to be ignored, but nothing i= s said about it in this draft. > > Also, there is no mention of when and how extensions may be introduced.=20 > Lacking any other statement, I presume it would take an update/revision t= o this rfc to define a new access-info value. If so, that=20 > at least means there would be no backward compatibility concern until the= re is such a revision. I think an errata would be enough. I really don't see a need for a new RFC = in order to do this fix. Also, 3GPP has already defined at least one new access-info value, using th= e generic-param syntax, so at some point I guess we'll need to discuss what= it takes to get that registered. But, I think that is a separate issue. Regards, Christer On 9/11/15 7:08 AM, Christer Holmberg wrote: > Hi, > > At the previous 3GPP CT1 meeting an issue with the ABNF in RFC 7315=20 > was raised. > > The ABNF says: > > access-info =3D cgi-3gpp / utran-cell-id-3= gpp / > > =20 > dsl-location / i-wlan-node-id / > > ci-3gpp2 /=20 > eth-location / > > > ci-3gpp2-femto / fiber-location / > > np /=20 > gstn-location /local-time-zone / > > > dvb-rcs2-node-id / extension-access-info > > np =3D "network-provided" > > extension-access-info =3D gen-value > > All current access-info values, except for 'np', are according to=20 > generic-param, but the ABNF only allows gen-value for new values. We=20 > believe that new values should also be according to generic-param. > > (From RFC 3261: generic-param =3D token [ EQUAL gen-value ]) > > OLD: > > extension-access-info =3D gen-value > > NEW: > > extension-access-info =3D generic-param > > My suggestion is to open an errata for this, and fix the ABNF. > > Comments? > > Regards, > > Christer > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Sep 11 21:57:36 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DB91AC3F1 for ; Fri, 11 Sep 2015 21:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 NiDBsvLMuZEv for ; Fri, 11 Sep 2015 21:57:32 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3291B4CF1 for ; Fri, 11 Sep 2015 21:57:29 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-08v.sys.comcast.net with comcast id G4xU1r0032GyhjZ014xUNg; Sat, 12 Sep 2015 04:57:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-09v.sys.comcast.net with comcast id G4xU1r0023Ge9ey014xU34; Sat, 12 Sep 2015 04:57:28 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B37A73B64@ESESSMB209.ericsson.se> <55F2FCCF.5050803@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37A776B9@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <55F3B0B7.7030500@alum.mit.edu> Date: Sat, 12 Sep 2015 00:57:27 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37A776B9@ESESSMB209.ericsson.se> 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=1442033848; bh=lR5pvH3qoPp/K6JEzrx7QWWxuM5QsEf18/UuutyCW+k=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=B7+ErzmflF5IIAT6JvmR7THtRRGOEkdJAJRR5OFhrIZCLx0ztXSelZLcW1/XQBWH9 xdeaqvpoxk1mwI3IH1GzszSGe/hRgLUlNc9KujnwNLY2ZhBb13GpLscRJ1uv2I5vKP l28G7q6QPUh0GeLxRDijKAwSJsjXxQY1yBSLps074QUwSHhSOR2l86B8yl78fcorxl bGrwLmUt35eXbHG0GNWQRPa4rKsKMtCkl6yIJVKgvniq+Lee1INfTA8ZJfLCa8I4mN RURhY+h3mieDkqWAAecc56d2wBxQyQnro4dCMjGcX9BudHPfhBzqG/dOE/iwWLbqEl VxS7sRDP3WvJw== Archived-At: Subject: Re: [sipcore] Errata suggestion: RFC 7315 ABNF correction X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2015 04:57:34 -0000 On 9/11/15 4:01 PM, Christer Holmberg wrote: > Hi, > >> What is proposed makes sense - it is in the spirit of most typical header syntax. >> >> The only real concern I can see here is with backward compatibility. >> Because the revision allows syntax that was previously forbidden, an entity that hasn't been updated may reject a >> request containing such new syntax. Whether that is practical problem depends on deployment. > > I am pretty sure 3GPP is the only user of this header field, and 3GPP agreed to bring the suggested change to IETF. > >> RFC7315 doesn't seem to say anything about how a request containing extension-access-info should be processed. Typically >> unknown stuff matching an extension point it to be ignored, but nothing is said about it in this draft. >> >> Also, there is no mention of when and how extensions may be introduced. >> Lacking any other statement, I presume it would take an update/revision to this rfc to define a new access-info value. If so, that >> at least means there would be no backward compatibility concern until there is such a revision. > > I think an errata would be enough. I really don't see a need for a new RFC in order to do this fix. I wasn't suggesting that the *errata* (erratum?) requires an RFC. I was guessing that defining actual new access-info values would require an RFC. That at least would mean that existing implementations would have warning that they need to get ready to see the new syntax. > Also, 3GPP has already defined at least one new access-info value, using the generic-param syntax, so at some point I guess we'll need to discuss what it takes to get that registered. But, I think that is a separate issue. It would have been nice for the document to define *some* mechanism for registering defined values, or otherwise ensuring that there won't be conflicting values. But I'm not especially bothered in this case, since this is pretty much a 3gpp-specific header. Thanks, Paul > Regards, > > Christer > > > > > On 9/11/15 7:08 AM, Christer Holmberg wrote: >> Hi, >> >> At the previous 3GPP CT1 meeting an issue with the ABNF in RFC 7315 >> was raised. >> >> The ABNF says: >> >> access-info = cgi-3gpp / utran-cell-id-3gpp / >> >> >> dsl-location / i-wlan-node-id / >> >> ci-3gpp2 / >> eth-location / >> >> >> ci-3gpp2-femto / fiber-location / >> >> np / >> gstn-location /local-time-zone / >> >> >> dvb-rcs2-node-id / extension-access-info >> >> np = "network-provided" >> >> extension-access-info = gen-value >> >> All current access-info values, except for 'np', are according to >> generic-param, but the ABNF only allows gen-value for new values. We >> believe that new values should also be according to generic-param. >> >> (From RFC 3261: generic-param = token [ EQUAL gen-value ]) >> >> OLD: >> >> extension-access-info = gen-value >> >> NEW: >> >> extension-access-info = generic-param >> >> My suggestion is to open an errata for this, and fix the ABNF. >> >> Comments? >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Sat Sep 12 10:59:37 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5624D1B29EC for ; Sat, 12 Sep 2015 10:59:36 -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, 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 wKTIRIate1BX for ; Sat, 12 Sep 2015 10:59:34 -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 F38C21B29D3 for ; Sat, 12 Sep 2015 10:59:33 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-12-55f4680375a1 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 63.20.27359.30864F55; Sat, 12 Sep 2015 19:59:32 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.81]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Sat, 12 Sep 2015 19:59:31 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Errata suggestion: RFC 7315 ABNF correction Thread-Index: AdDsgiu7UmSpSAlwSzGJzef76BU8AgAGVqCAAAwFLoAADsmzgAAfW9Gw Date: Sat, 12 Sep 2015 17:59:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37A78441@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37A73B64@ESESSMB209.ericsson.se> <55F2FCCF.5050803@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37A776B9@ESESSMB209.ericsson.se> <55F3B0B7.7030500@alum.mit.edu> In-Reply-To: <55F3B0B7.7030500@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+JvjS5LxpdQgyNnmSxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSujrVuq4K1cxcndXA2Mc8W7GDk5JARMJM72 vWCDsMUkLtxbD2RzcQgJHGWUeNX2nAnCWcwosfb1QcYuRg4ONgELie5/2iANIgKBEleXTGAG sYUFnCSefL3IAhF3luhuu8EMYbtJ7Oz8wQ5iswioSizsmwG2jFfAV2LJmiWMEPOvMkqsOLAO LMEpoCPxetkuRhCbEeii76fWMIHYzALiEreezGeCuFRAYsme88wQtqjEy8f/WCFsJYnGJU9Y Iep1JBbs/sQGYWtLLFv4mhlisaDEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyilG0OLU4KTfd yEgvtSgzubg4P08vL7VkEyMwSg5u+W2wg/Hlc8dDjAIcjEo8vArtn0OFWBPLiitzDzFKc7Ao ifM2Mz0IFRJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBY3V4XGfjpI9ulpxNcUh3LNk1e9117 cYjdF7/+RWb1/4X+9ZYVF3RWxJS3CZetMDp9WLjZVWGjyTpHF/ePc+Y0mebuYw5qUnVmkQ0y ctR9r9UT/y5fxWn+188caX1Hb59oWunxo9Bart1/nsQsr9PTp11+yr4t6ElY05JMwy3TOuf4 Ky3dUaXEUpyRaKjFXFScCAACpD5OcwIAAA== Archived-At: Subject: Re: [sipcore] Errata suggestion: RFC 7315 ABNF correction X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2015 17:59:36 -0000 Hi, >>> What is proposed makes sense - it is in the spirit of most typical head= er syntax. >>> >>> The only real concern I can see here is with backward compatibility. >>> Because the revision allows syntax that was previously forbidden, an=20 >>> entity that hasn't been updated may reject a request containing such ne= w syntax. Whether that is practical problem depends on deployment. >> >> I am pretty sure 3GPP is the only user of this header field, and 3GPP ag= reed to bring the suggested change to IETF. >> >>> RFC7315 doesn't seem to say anything about how a request containing=20 >>> extension-access-info should be processed. Typically unknown stuff matc= hing an extension point it to be ignored, but nothing is said about it in t= his draft. >>> >>> Also, there is no mention of when and how extensions may be introduced. >>> Lacking any other statement, I presume it would take an=20 >>> update/revision to this rfc to define a new access-info value. If so, t= hat at least means there would be no backward compatibility concern until t= here is such a revision. >> >> I think an errata would be enough. I really don't see a need for a new R= FC in order to do this fix. > > I wasn't suggesting that the *errata* (erratum?) requires an RFC. Ok. Good :) > I was guessing that defining actual new access-info values would require = an RFC. That at least would mean that=20 > existing implementations would have warning that they need to get ready t= o see the new syntax. > >> Also, 3GPP has already defined at least one new access-info value, using= the generic-param syntax, so at=20 >> some point I guess we'll need to discuss what it takes to get that regis= tered. But, I think that is a separate issue. > > It would have been nice for the document to define *some* mechanism for r= egistering defined values, or=20 > otherwise ensuring that there won't be conflicting values. But I'm not es= pecially bothered in this case, since this is pretty much a 3gpp-specific h= eader. At some point the question will come up regarding how/if the new values sha= ll be registered, and whether an RFC will be required (I believe 3GPP curre= ntly only has one new value). But, for now, are you ok to fix the ABNF as suggested? Regards, Christer > On 9/11/15 7:08 AM, Christer Holmberg wrote: >> Hi, >> >> At the previous 3GPP CT1 meeting an issue with the ABNF in RFC 7315=20 >> was raised. >> >> The ABNF says: >> >> access-info =3D cgi-3gpp / utran-cell-id-= 3gpp / >> >> >> dsl-location / i-wlan-node-id / >> >> ci-3gpp2=20 >> / eth-location / >> >> >> ci-3gpp2-femto / fiber-location / >> >> np /=20 >> gstn-location /local-time-zone / >> >> >> dvb-rcs2-node-id / extension-access-info >> >> np =3D "network-provided= " >> >> extension-access-info =3D gen-value >> >> All current access-info values, except for 'np', are according to=20 >> generic-param, but the ABNF only allows gen-value for new values. We=20 >> believe that new values should also be according to generic-param. >> >> (From RFC 3261: generic-param =3D token [ EQUAL gen-value ]) >> >> OLD: >> >> extension-access-info =3D gen-value >> >> NEW: >> >> extension-access-info =3D generic-param >> >> My suggestion is to open an errata for this, and fix the ABNF. >> >> Comments? >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Sat Sep 12 13:12:49 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958801B4D21 for ; Sat, 12 Sep 2015 13:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 I6u-Z9Qo7vTT for ; Sat, 12 Sep 2015 13:12:44 -0700 (PDT) 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 D4E521B3C79 for ; Sat, 12 Sep 2015 13:12:41 -0700 (PDT) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-03v.sys.comcast.net with comcast id GLBw1r0042AWL2D01LChQD; Sat, 12 Sep 2015 20:12:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-04v.sys.comcast.net with comcast id GLCg1r00F3Ge9ey01LCg3G; Sat, 12 Sep 2015 20:12:41 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B37A73B64@ESESSMB209.ericsson.se> <55F2FCCF.5050803@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37A776B9@ESESSMB209.ericsson.se> <55F3B0B7.7030500@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37A78441@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <55F48737.6060206@alum.mit.edu> Date: Sat, 12 Sep 2015 16:12:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37A78441@ESESSMB209.ericsson.se> 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=1442088761; bh=CczqR2VewHl11OK1Bn4cuiXLtrl9+mmmYh97z36AmNA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=vJiJ88xDkRd2iXL1Bjp/Dz/1/BWtGiVKQny9KmUmTq2lQbr0jx1XWf43JvKHcs/lD NQGh5HzuCagl4R8qvtHvX27cb5VgA2E/Lz3SqphddSEj7tTdDNPBYiweUhpEoEUl2B qmw0Fu7oYmPe2/R+hiKjvHUItVyXUWdXowW/Xga5x9+g1Cyqlnd7sux5HQIy+J4wYb Zjm/nAHofTdmH1v0SnQ02GpVRbpJ7w7IN9RNSGdptlJf5LpJcr68aD7JbaNrpzes91 sZ7yCiMJP+f5hskEb4Izy/gzTDsDdQObM2zigBsUnh/55WojJUbGZyiLDnvjJU7Jht glYuW0XfR5okQ== Archived-At: Subject: Re: [sipcore] Errata suggestion: RFC 7315 ABNF correction X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Sep 2015 20:12:46 -0000 Yes. On 9/12/15 1:59 PM, Christer Holmberg wrote: > Hi, > >>>> What is proposed makes sense - it is in the spirit of most typical header syntax. >>>> >>>> The only real concern I can see here is with backward compatibility. >>>> Because the revision allows syntax that was previously forbidden, an >>>> entity that hasn't been updated may reject a request containing such new syntax. Whether that is practical problem depends on deployment. >>> >>> I am pretty sure 3GPP is the only user of this header field, and 3GPP agreed to bring the suggested change to IETF. >>> >>>> RFC7315 doesn't seem to say anything about how a request containing >>>> extension-access-info should be processed. Typically unknown stuff matching an extension point it to be ignored, but nothing is said about it in this draft. >>>> >>>> Also, there is no mention of when and how extensions may be introduced. >>>> Lacking any other statement, I presume it would take an >>>> update/revision to this rfc to define a new access-info value. If so, that at least means there would be no backward compatibility concern until there is such a revision. >>> >>> I think an errata would be enough. I really don't see a need for a new RFC in order to do this fix. >> >> I wasn't suggesting that the *errata* (erratum?) requires an RFC. > > Ok. Good :) > >> I was guessing that defining actual new access-info values would require an RFC. That at least would mean that >> existing implementations would have warning that they need to get ready to see the new syntax. >> >>> Also, 3GPP has already defined at least one new access-info value, using the generic-param syntax, so at >>> some point I guess we'll need to discuss what it takes to get that registered. But, I think that is a separate issue. >> >> It would have been nice for the document to define *some* mechanism for registering defined values, or >> otherwise ensuring that there won't be conflicting values. But I'm not especially bothered in this case, since this is pretty much a 3gpp-specific header. > > At some point the question will come up regarding how/if the new values shall be registered, and whether an RFC will be required (I believe 3GPP currently only has one new value). > > But, for now, are you ok to fix the ABNF as suggested? > > Regards, > > Christer > > >> On 9/11/15 7:08 AM, Christer Holmberg wrote: >>> Hi, >>> >>> At the previous 3GPP CT1 meeting an issue with the ABNF in RFC 7315 >>> was raised. >>> >>> The ABNF says: >>> >>> access-info = cgi-3gpp / utran-cell-id-3gpp / >>> >>> >>> dsl-location / i-wlan-node-id / >>> >>> ci-3gpp2 >>> / eth-location / >>> >>> >>> ci-3gpp2-femto / fiber-location / >>> >>> np / >>> gstn-location /local-time-zone / >>> >>> >>> dvb-rcs2-node-id / extension-access-info >>> >>> np = "network-provided" >>> >>> extension-access-info = gen-value >>> >>> All current access-info values, except for 'np', are according to >>> generic-param, but the ABNF only allows gen-value for new values. We >>> believe that new values should also be according to generic-param. >>> >>> (From RFC 3261: generic-param = token [ EQUAL gen-value ]) >>> >>> OLD: >>> >>> extension-access-info = gen-value >>> >>> NEW: >>> >>> extension-access-info = generic-param >>> >>> My suggestion is to open an errata for this, and fix the ABNF. >>> >>> Comments? >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > From nobody Mon Sep 14 04:22:16 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6111B4E21 for ; Mon, 14 Sep 2015 04:22:15 -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, 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 CSg9R3Mvufmt for ; Mon, 14 Sep 2015 04:22:13 -0700 (PDT) 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 2337F1B4BD1 for ; Mon, 14 Sep 2015 04:22:12 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-79-55f6ade3d0a2 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F2.9B.17026.3EDA6F55; Mon, 14 Sep 2015 13:22:11 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.81]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0248.002; Mon, 14 Sep 2015 13:22:10 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: [Technical Errata Reported] RFC7315 (4474) Thread-Index: AQHQ7t97nIYDUJCaWUq0zXVQ2fcq45474U6Q Date: Mon, 14 Sep 2015 11:22:10 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37A7B4A3@ESESSMB209.ericsson.se> References: <20150914112053.D26B1180204@rfc-editor.org> In-Reply-To: <20150914112053.D26B1180204@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvje7jtd9CDVoOiVh8/bGJzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGV8uPWcsaBOoeHqgj72B8StPFyMnh4SAicTOj9+ZIGwxiQv3 1rN1MXJxCAkcZZQ43neVCcJZzCjxb9tfoAwHB5uAhUT3P22QBhEBTYnl37ayg9jCAuYSd/es ZwQpEQEqOX/DFaLESKKl6zAziM0ioCox9/U/VpASXgFfiVerHUDCQkCd628dBjuBE6jzeecb RhCbEeic76fWgMWZBcQlbj2ZD3WmgMSSPeeZIWxRiZePIUZKCChKLO+XgyjXkViw+xMbhK0t sWzha7ByXgFBiZMzn7BMYBSdhWTqLCQts5C0zELSsoCRZRWjaHFqcXFuupGxXmpRZnJxcX6e Xl5qySZGYDQc3PJbdwfj6teOhxgFOBiVeHgffPwaKsSaWFZcmXuIUZqDRUmct4XpQaiQQHpi SWp2ampBalF8UWlOavEhRiYOTqkGRvtJOelpByOep4jmmxx98WLzY4UJa2JCI42WZb8qyWA+ 6B38bGrHiokFM6W31FxdGjkt5cJ74QNLrErNmpscLPPZ1vR/P7Rqi6T929W/As1idifm2mTe 0CrfMm2y/rQ7yp0Sb77s3sV0M/KXvEaiRZWo+QWXdYuqOPfleip02nFFasv4av47qMRSnJFo qMVcVJwIAMoL2ldnAgAA Archived-At: Subject: [sipcore] FW: [Technical Errata Reported] RFC7315 (4474) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 11:22:15 -0000 FYI, I've now submitted the errata. Regards, Christer -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20 Sent: 14. syyskuuta 2015 14:21 To: r.jesske@telekom.de; drage@alcatel-lucent.com; Christer Holmberg; iesg@= ietf.org Cc: Christer Holmberg; rfc-editor@rfc-editor.org Subject: [Technical Errata Reported] RFC7315 (4474) The following errata report has been submitted for RFC7315, "Private Header= (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3GP= P". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D7315&eid=3D4474 -------------------------------------- Type: Technical Reported by: Christer Holmberg Section: 5.4 Original Text ------------- extension-access-info =3D gen-value Corrected Text -------------- extension-access-info =3D generic-param Notes ----- Most of the pre-defined access-info values are following the generic-param = syntax. New access-info values (extensions) should also be allowed to follo= w the generic-param syntax, in order to allow both for a name and value of = the extension. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "R= eply All" to discuss whether it should be verified or rejected. When a deci= sion is reached, the verifying party (IESG) can log in to change the status= and edit the report, if necessary.=20 -------------------------------------- RFC7315 (draft-drage-sipping-rfc3455bis-14) -------------------------------------- Title : Private Header (P-Header) Extensions to the Session I= nitiation Protocol (SIP) for the 3GPP Publication Date : July 2014 Author(s) : R. Jesske, K. Drage, C. Holmberg Category : INFORMATIONAL Source : IETF - NON WORKING GROUP Area : N/A Stream : IETF Verifying Party : IESG From nobody Mon Sep 14 04:47:19 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A891A6F88 for ; Mon, 14 Sep 2015 04:47:18 -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, 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 PWkoGifiqaLH for ; Mon, 14 Sep 2015 04:47:16 -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 1D5491A6F2F for ; Mon, 14 Sep 2015 04:47:15 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-81-55f6b3c1c4db Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 86.9C.27359.1C3B6F55; Mon, 14 Sep 2015 13:47:14 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.81]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0248.002; Mon, 14 Sep 2015 13:47:13 +0200 From: Christer Holmberg To: "A. Jean Mahoney" , Ben Campbell , Paul Kyzivat Thread-Topic: [sipcore] RSeq and forking - Errata Thread-Index: AdCjwjb6aIhPA9HcRsaaDgKN4yT4tAG3gD/g///pywD//9iRUIAU+dAA//9WNoCAEf+lAIAADcgAgAAA4oCAASKMAP+ewsGQ Date: Mon, 14 Sep 2015 11:47:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37A7B565@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F33B4@ESESSMB209.ericsson.se> <55843746.1070907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D8F35A0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D908280@ESESSMB209.ericsson.se> <55A44506.3090209@alum.mit.edu> <4327D8C7-211A-439C-A3DE-012FC094B517@nostrum.com> <55A5397E.6050804@nostrum.com> In-Reply-To: <55A5397E.6050804@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM+Jvje6hzd9CDRbtZbaY33ma3aKhcyWr xYoNB1gtvv7YxObA4vH3/QcmjyVLfjJ5zNr5hCWAOYrLJiU1J7MstUjfLoErY1L7I5aCWWoV 9/dvZ21gXCDXxcjJISFgIvHryVMWCFtM4sK99WxdjFwcQgJHGSWmnJzMDuEsZpRonTWDtYuR g4NNwEKi+582SIOIQLHE6ger2UBsZgFNiUc79zKB2MICBhI/vrxggagxlDh5oh3KzpOYsa0T bAyLgKpEwxIeEJNXwFfiz8FYiE1zWSQu/5kMNoZTQFti1e19YK2MQLd9P7WGCWKVuMStJ/OZ IG4WkFiy5zwzhC0q8fLxP7DxEgKKEsv75SDK9SRuTJ0CdaW2xLKFr8HKeQUEJU7OfMIygVFs FpKps5C0zELSMgtJywJGllWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgZF1cMtvgx2ML587 HmIU4GBU4uF98PFrqBBrYllxZe4hRmkOFiVx3mamB6FCAumJJanZqakFqUXxRaU5qcWHGJk4 OKUaGOXqnTgUbW0NhE7G5yyuSnO9xiFq8ODz/V2dxSkF93f+/NvJtb2nqmVDgJyH42ve54xa VybZa01szNL5tXWz3AuRD5M36+bJMs7eYe1f/XHynAdFc5a2cSoWXPo0OTni/Lwf78L/3wp5 KcqYJs72l8c1VLhwyW7GBg4b04OJxwqd+T9+8j/7RYmlOCPRUIu5qDgRALIpLdGNAgAA Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 11:47:18 -0000 Hi, We were going to continue this discussion after Prague, so here we go :) The issue was that currently the text does not make it clear that, when a r= equest is forked, the scope of the RSeq value is per individual fork. As far as I know, there was no objection to the issue as such. However, peo= ple did not think the suggested text was good enough. The original text (Section 4 of RFC 3262) says: "Handling of subsequent reliable provisional responses for the same initial request follows the same rules as above, with the following difference: reliable provisional responses are guaranteed to be in order. As a result, if the UAC receives another reliable provisional response to the same request, and its RSeq value is not one higher than the value of the sequence number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache the response in the hopes of receiving the missing responses." In the previous Errata, the suggested correction text was: =20 "Handling of subsequent reliable provisional responses for the same initial request follows the same rules as above, with the following difference: reliable provisional responses are guaranteed to be in order. As a result, if the UAC receives another reliable provisional response to the same request on a given dialog, and its RSeq value is not one higher than the value of the sequence number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache the response in the hopes of receiving the missing responses. If forking occurs, RSeq values are processed on each early dialog independently." Paul said: "Note that the scope of RSeq values is a single INVITE transaction, not a d= ialog. (So, for a re-INVITE in the same dialog the RSeq value might turn ou= t to be lower than that for the INVITE that established the dialog.) But that value space is owned by the UAS for the INVITE. So, from the persp= ective of the sender of the INVITE (receiver of provisional responses), the= value space must be managed independently for the combination of INVITE tr= ansaction AND dialog id. So the required logic is somewhat different than w= hat is required for CSeq." Comments? Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of A. Jean Mahone= y Sent: 14. hein=E4kuuta 2015 19:32 To: Ben Campbell; Paul Kyzivat Cc: sipcore@ietf.org Subject: Re: [sipcore] RSeq and forking - Errata On 7/13/15 6:12 PM, Ben Campbell wrote: > On 13 Jul 2015, at 18:08, Paul Kyzivat wrote: > >> On 7/13/15 6:19 PM, Ben Campbell wrote: >>> >>> >>> On 3 Jul 2015, at 0:46, Christer Holmberg wrote: >>> >>>> Hi Ben, >>>> >>>> Assuming we have to submit a new errata in order to do the word=20 >>>> smiting, I guess rejecting the current one is the way forward.=20 >>>> Nobody has objected to the correction as such. >>> >>> "word smiting" is a wonderful typo for this. I'm going to use that=20 >>> one :-) >>> >>> Rejecting it is not absolutely necessary to edit the wording, but I=20 >>> think it may be the right thing to do here [see below] >>> >>>> >>>> However, I guess we should then on the list should agree on the=20 >>>> actual text, before submitting a new errata. >>> >>> I agree. But after reading the discussion so far (especially Paul's=20 >>> comment), I'm not sure if this is a simple fix, or if it needs more=20 >>> thought. Therefore I'm going to reject the errata as it currently=20 >>> stands. I'd like to see the working group discuss the correct fix.=20 >>> If that turns out to be an errata, we can submit that one when it's=20 >>> agreed upon. If it turns out to be something else, we can cross that=20 >>> bridge when we come to it. >> >> Do we want to start that discussion *now*? Or wait until after the=20 >> meeting? >> >> While sipcore isn't meeting, most of the sipcore regulars are=20 >> probably concentrating on things that *will* be going on at the=20 >> meeting. So I'm inclined to think it would be better to wait about a=20 >> month before starting the discussion. > > I will leave that to the chairs, but I don't think the world is going=20 > to end if it waits a few weeks. It's OK with the chairs to hold off discussing this topic until after Pragu= e. Jean > > Ben. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Sep 14 11:31:26 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7141B2DD3 for ; Mon, 14 Sep 2015 11:31:25 -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 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 KD0OyBiG_4UH for ; Mon, 14 Sep 2015 11:31:23 -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 009031B2F32 for ; Mon, 14 Sep 2015 11:31:22 -0700 (PDT) Received: from [10.0.1.23] (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 t8EIV8ue046056 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 Sep 2015 13:31:18 -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.23] From: "Ben Campbell" To: "Christer Holmberg" Date: Mon, 14 Sep 2015 13:31:08 -0500 Message-ID: <13F0EA94-60E1-4735-80DA-55B9D5D64B28@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37A7B4A3@ESESSMB209.ericsson.se> References: <20150914112053.D26B1180204@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37A7B4A3@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 18:31:25 -0000 Hi Christer, Is it your understanding that the use of generic-param was the actual intention at the time 7315 was published? Or was gen-value the original intention, but we now think that it should have been generic-param? Thanks! Ben. On 14 Sep 2015, at 6:22, Christer Holmberg wrote: > FYI, > > I've now submitted the errata. > > Regards, > > Christer > > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: 14. syyskuuta 2015 14:21 > To: r.jesske@telekom.de; drage@alcatel-lucent.com; Christer Holmberg; > iesg@ietf.org > Cc: Christer Holmberg; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC7315 (4474) > > The following errata report has been submitted for RFC7315, "Private > Header (P-Header) Extensions to the Session Initiation Protocol (SIP) > for the 3GPP". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7315&eid=4474 > > -------------------------------------- > Type: Technical > Reported by: Christer Holmberg > > Section: 5.4 > > Original Text > ------------- > extension-access-info = gen-value > > Corrected Text > -------------- > extension-access-info = generic-param > > Notes > ----- > Most of the pre-defined access-info values are following the > generic-param syntax. New access-info values (extensions) should also > be allowed to follow the generic-param syntax, in order to allow both > for a name and value of the extension. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or rejected. > When a decision is reached, the verifying party (IESG) can log in to > change the status and edit the report, if necessary. > > -------------------------------------- > RFC7315 (draft-drage-sipping-rfc3455bis-14) > -------------------------------------- > Title : Private Header (P-Header) Extensions to the > Session Initiation Protocol (SIP) for the 3GPP > Publication Date : July 2014 > Author(s) : R. Jesske, K. Drage, C. Holmberg > Category : INFORMATIONAL > Source : IETF - NON WORKING GROUP > Area : N/A > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Sep 14 13:23:39 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713DB1B3E8D for ; Mon, 14 Sep 2015 13:23:38 -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, HTML_MESSAGE=0.001, 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 rYVmbt1Hrria for ; Mon, 14 Sep 2015 13:23:36 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91741B3375 for ; Mon, 14 Sep 2015 13:23:35 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-ff-55f72cc4b6af Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 76.CC.29154.4CC27F55; Mon, 14 Sep 2015 22:23:33 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.81]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Mon, 14 Sep 2015 22:23:32 +0200 From: Christer Holmberg To: Ben Campbell Thread-Topic: [sipcore] [Technical Errata Reported] RFC7315 (4474) Thread-Index: AQHQ7t97nIYDUJCaWUq0zXVQ2fcq45474U6QgABWdwCAAEDu1w== Date: Mon, 14 Sep 2015 20:23:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37A7C011@ESESSMB209.ericsson.se> References: <20150914112053.D26B1180204@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37A7B4A3@ESESSMB209.ericsson.se>, <13F0EA94-60E1-4735-80DA-55B9D5D64B28@nostrum.com> In-Reply-To: <13F0EA94-60E1-4735-80DA-55B9D5D64B28@nostrum.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37A7C011ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM+Jvje5Rne+hBusOCVvM7zzNbvH1xyY2 ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugStj+/VnrAWz/CsOLDzA1sB437mLkZNDQsBE Ytvd86wQtpjEhXvr2boYuTiEBI4ySkybPIMZwlnMKNHeuI29i5GDg03AQqL7nzZIg4iAksTz 5q0sIDazgKbEo517mUBsYQFHifWf17BC1DhJXLv7mh3G/rLhAFg9i4CqxPfrb5hBbF4BX4l9 32YyQuxaxygx6/8GsASngL3E030zwYYyAl33/dQaJohl4hJNX1ZCXS0gsWTPeWYIW1Ti5eN/ rBA1+RK79/5nhVggKHFy5hOWCYwis5C0z0JSNgtJGUTcQOLL+9tQtrbEsoWvmSFsfYnu96eZ kMUXMLKvYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMrINbflvtYDz43PEQowAHoxIP74OP X0OFWBPLiitzDzFKc7AoifM2Mz0IFRJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDYc69u35Hm oqzz7x7OT5hmtm+JvlbAPqsJHN+uJ20T8o2qD/9k23OFyePe7Ai72z1sM1i2Xwme1dPE7ztP 0mHSYYcDP+7fqr4zg0Wf+dAFSZ0a1artQQJvRd/M9I8zDVm1vd3li29HWd81v4ypzIxrDq7X vs9eMefKgcjI5aLf2Xc9Vq54ck5IiaU4I9FQi7moOBEASVEA5o0CAAA= Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 20:23:38 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37A7C011ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Ben, I am pretty sure generic-param was the original intention. The majority of = all existing value follow the generic-param syntax, and I can't think of an= y reason why new values would not follow the same syntax. That is how it wo= rks for other header fields too. I think this is due to a mistake, where someone thought that extension-acce= ss-info represents the actual parameter name, and therefor only a value (g= en-value) is needed. But, extension-access-info represents the whole rule (= name AND value), why generic-param is needed :) Regards, Christer Sent from my Windows Phone ________________________________ From: Ben Campbell Sent: =FD14/=FD09/=FD2015 21:31 To: Christer Holmberg Cc: sipcore@ietf.org Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) Hi Christer, Is it your understanding that the use of generic-param was the actual intention at the time 7315 was published? Or was gen-value the original intention, but we now think that it should have been generic-param? Thanks! Ben. On 14 Sep 2015, at 6:22, Christer Holmberg wrote: > FYI, > > I've now submitted the errata. > > Regards, > > Christer > > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: 14. syyskuuta 2015 14:21 > To: r.jesske@telekom.de; drage@alcatel-lucent.com; Christer Holmberg; > iesg@ietf.org > Cc: Christer Holmberg; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC7315 (4474) > > The following errata report has been submitted for RFC7315, "Private > Header (P-Header) Extensions to the Session Initiation Protocol (SIP) > for the 3GPP". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D7315&eid=3D4474 > > -------------------------------------- > Type: Technical > Reported by: Christer Holmberg > > Section: 5.4 > > Original Text > ------------- > extension-access-info =3D gen-value > > Corrected Text > -------------- > extension-access-info =3D generic-param > > Notes > ----- > Most of the pre-defined access-info values are following the > generic-param syntax. New access-info values (extensions) should also > be allowed to follow the generic-param syntax, in order to allow both > for a name and value of the extension. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or rejected. > When a decision is reached, the verifying party (IESG) can log in to > change the status and edit the report, if necessary. > > -------------------------------------- > RFC7315 (draft-drage-sipping-rfc3455bis-14) > -------------------------------------- > Title : Private Header (P-Header) Extensions to the > Session Initiation Protocol (SIP) for the 3GPP > Publication Date : July 2014 > Author(s) : R. Jesske, K. Drage, C. Holmberg > Category : INFORMATIONAL > Source : IETF - NON WORKING GROUP > Area : N/A > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --_000_7594FB04B1934943A5C02806D1A2204B37A7C011ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Ben,

I am pretty sure generic-param was the original intention. The majority of = all existing value follow the generic-param syntax, and I can't think of an= y reason why new values would not follow the same syntax. That is how it wo= rks for other header fields too.

I think this is due to a mistake, where someone thought that extension-acce= ss-info  represents the actual parameter name, and therefor only a val= ue (gen-value) is needed. But, extension-access-info represents the whole r= ule (name AND value), why generic-param is needed :)

Regards,

Christer

Sent from my Windows Phone
From: Ben Campbell
Sent: =FD14= /=FD09/=FD2015 21:31
To: Christer Holmberg Cc: sipcore@ietf.org
Subject: Re: [= sipcore] [Technical Errata Reported] RFC7315 (4474)

Hi Christer,

Is it your understanding that the use of generic-param was the actual
intention at the time 7315 was published? Or was gen-value the original intention, but we now think that it should have been generic-param?

Thanks!

Ben.

On 14 Sep 2015, at 6:22, Christer Holmberg wrote:

> FYI,
>
> I've now submitted the errata.
>
> Regards,
>
> Christer
>
> -----Original Message-----
> From: RFC Errata System [= mailto:rfc-editor@rfc-editor.org]
> Sent: 14. syyskuuta 2015 14:21
> To: r.jesske@telekom.de; drage@alcatel-lucent.com; Christer Holmberg; =
> iesg@ietf.org
> Cc: Christer Holmberg; rfc-editor@rfc-editor.org
> Subject: [Technical Errata Reported] RFC7315 (4474)
>
> The following errata report has been submitted for RFC7315, "Priv= ate
> Header (P-Header) Extensions to the Session Initiation Protocol (SIP) =
> for the 3GPP".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D7315&eid= =3D4474
>
> --------------------------------------
> Type: Technical
> Reported by: Christer Holmberg <christer.holmberg@ericsson.com><= br> >
> Section: 5.4
>
> Original Text
> -------------
> extension-access-info  =3D gen-value
>
> Corrected Text
> --------------
> extension-access-info  =3D generic-param
>
> Notes
> -----
> Most of the pre-defined access-info values are following the
> generic-param syntax. New access-info values (extensions) should also =
> be allowed to follow the generic-param syntax, in order to allow both =
> for a name and value of the extension.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or = rejected.
> When a decision is reached, the verifying party (IESG) can log in to <= br> > change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC7315 (draft-drage-sipping-rfc3455bis-14)
> --------------------------------------
> Title           = ;    : Private Header (P-Header) Extensions to the
> Session Initiation Protocol (SIP) for the 3GPP
> Publication Date    : July 2014
> Author(s)           = : R. Jesske, K. Drage, C. Holmberg
> Category          &n= bsp; : INFORMATIONAL
> Source          &nbs= p;   : IETF - NON WORKING GROUP
> Area           =      : N/A
> Stream          &nbs= p;   : IETF
> Verifying Party     : IESG
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.= ietf.org/mailman/listinfo/sipcore
 --_000_7594FB04B1934943A5C02806D1A2204B37A7C011ESESSMB209erics_-- From nobody Mon Sep 21 03:26:35 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96ABD1B303D for ; Mon, 21 Sep 2015 03:26:33 -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, HTML_MESSAGE=0.001, 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 0LLS5TaVrpSt for ; Mon, 21 Sep 2015 03:26:31 -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 735821B302E for ; Mon, 21 Sep 2015 03:26:30 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-27-55ffdb5354fb Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 9D.46.27359.35BDFF55; Mon, 21 Sep 2015 12:26:28 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.171]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Mon, 21 Sep 2015 12:26:27 +0200 From: Christer Holmberg To: Ben Campbell Thread-Topic: [sipcore] [Technical Errata Reported] RFC7315 (4474) Thread-Index: AQHQ7t97nIYDUJCaWUq0zXVQ2fcq45474U6QgABWdwCAAEDu14AKWWCw Date: Mon, 21 Sep 2015 10:26:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37AC0CF1@ESESSMB209.ericsson.se> References: <20150914112053.D26B1180204@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37A7B4A3@ESESSMB209.ericsson.se>, <13F0EA94-60E1-4735-80DA-55B9D5D64B28@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37A7C011@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37A7C011@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.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37AC0CF1ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGfG3Rjfk9v9Qg77v3BbzO0+zW3z9sYnN gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4Mr4efUDc0FvScXE8/eZGhh3pnYxcnJICJhI tG2dwghhi0lcuLeerYuRi0NI4CijRGPfDXYIZwmjxKmln5i6GDk42AQsJLr/aYM0iAgoSTxv 3soCYjMLaEo82rmXCcQWFnCUWP95DStEjZPEtbuv2UFaRQTcJE6v5gUJswioSqz5sIENxOYV 8JV48fwnE8Sqr4wSk2ddA+vlFPCTWDD9INhMRqDjvp9awwSxS1zi1pP5TBBHC0gs2XOeGcIW lXj5+B8rhK0o8fHVPkaI+nyJfz0TWSGWCUqcnPmEZQKj6Cwko2YhKZuFpAwibiBxbvtGdghb W2LZwtfMELa+xPbbM1mRxRcwsq9iFC1OLU7KTTcy0kstykwuLs7P08tLLdnECIy3g1t+G+xg fPnc8RCjAAejEg9vgs7/UCHWxLLiytxDjNIcLErivM1MD0KFBNITS1KzU1MLUovii0pzUosP MTJxcEo1MLrVJj6xrbVkELyx80/utU99l346L7UT3jvnfPttK/PHE/J0ftm+0XeJYZwcfnp7 4BXW+a4+rxecXsnCtrX9+IJeoymFBzrObf3RoaLZI1gm9frevmu8SsfLyrvCW5cpRJm9+F0v 9KvOyc9MJbhza0zemRimT8kbL29TEDF7bCXY8qV4vuXjE0osxRmJhlrMRcWJALac5tuYAgAA Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 10:26:33 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37AC0CF1ESESSMB209erics_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Any news on this? Regards, Christer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 14. syyskuuta 2015 23:24 To: Ben Campbell Cc: sipcore@ietf.org Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) Hi Ben, I am pretty sure generic-param was the original intention. The majority of = all existing value follow the generic-param syntax, and I can't think of an= y reason why new values would not follow the same syntax. That is how it wo= rks for other header fields too. I think this is due to a mistake, where someone thought that extension-acce= ss-info represents the actual parameter name, and therefor only a value (g= en-value) is needed. But, extension-access-info represents the whole rule (= name AND value), why generic-param is needed :) Regards, Christer Sent from my Windows Phone ________________________________ From: Ben Campbell Sent: =FD14/=FD09/=FD2015 21:31 To: Christer Holmberg Cc: sipcore@ietf.org Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) Hi Christer, Is it your understanding that the use of generic-param was the actual intention at the time 7315 was published? Or was gen-value the original intention, but we now think that it should have been generic-param? Thanks! Ben. On 14 Sep 2015, at 6:22, Christer Holmberg wrote: > FYI, > > I've now submitted the errata. > > Regards, > > Christer > > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: 14. syyskuuta 2015 14:21 > To: r.jesske@telekom.de; drage@alcatel-lucent= .com; Christer Holmberg; > iesg@ietf.org > Cc: Christer Holmberg; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC7315 (4474) > > The following errata report has been submitted for RFC7315, "Private > Header (P-Header) Extensions to the Session Initiation Protocol (SIP) > for the 3GPP". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D7315&eid=3D4474 > > -------------------------------------- > Type: Technical > Reported by: Christer Holmberg > > > Section: 5.4 > > Original Text > ------------- > extension-access-info =3D gen-value > > Corrected Text > -------------- > extension-access-info =3D generic-param > > Notes > ----- > Most of the pre-defined access-info values are following the > generic-param syntax. New access-info values (extensions) should also > be allowed to follow the generic-param syntax, in order to allow both > for a name and value of the extension. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or rejected. > When a decision is reached, the verifying party (IESG) can log in to > change the status and edit the report, if necessary. > > -------------------------------------- > RFC7315 (draft-drage-sipping-rfc3455bis-14) > -------------------------------------- > Title : Private Header (P-Header) Extensions to the > Session Initiation Protocol (SIP) for the 3GPP > Publication Date : July 2014 > Author(s) : R. Jesske, K. Drage, C. Holmberg > Category : INFORMATIONAL > Source : IETF - NON WORKING GROUP > Area : N/A > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --_000_7594FB04B1934943A5C02806D1A2204B37AC0CF1ESESSMB209erics_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Any news on this?

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 14. syyskuuta 2015 23:24
To: Ben Campbell
Cc: sipcore@ietf.org
Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474)

 

Hi Ben,

I am pretty sure generic-param was the original intention. The majority of = all existing value follow the generic-param syntax, and I can't think of an= y reason why new values would not follow the same syntax. That is how it wo= rks for other header fields too.

I think this is due to a mistake, where someone thought that extension-acce= ss-info  represents the actual parameter name, and therefor only a val= ue (gen-value) is needed. But, extension-access-info represents the whole r= ule (name AND value), why generic-param is needed :)

Regards,

Christer

Sent from my Windows Phone

From: Ben Campbell=
Sent: =FD14/=FD09/=FD2015 21:31
To: Christer Holmberg
Cc: sipcore@ietf.org
Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474)

Hi Christer,

Is it your understanding that the use of generic-param was the actual
intention at the time 7315 was published? Or was gen-value the original intention, but we now think that it should have been generic-param?

Thanks!

Ben.

On 14 Sep 2015, at 6:22, Christer Holmberg wrote:

> FYI,
>
> I've now submitted the errata.
>
> Regards,
>
> Christer
>
> -----Original Message-----
> From: RFC Errata System [= mailto:rfc-editor@rfc-editor.org]
> Sent: 14. syyskuuta 2015 14:21
> To: r.jesske@telekom.de; drage@alcatel-lucent.com; Christer Holmberg;
> iesg@ietf.org
> Cc: Christer Holmberg; rf= c-editor@rfc-editor.org
> Subject: [Technical Errata Reported] RFC7315 (4474)
>
> The following errata report has been submitted for RFC7315, "Priv= ate
> Header (P-Header) Extensions to the Session Initiation Protocol (SIP) =
> for the 3GPP".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D7315&eid= =3D4474
>
> --------------------------------------
> Type: Technical
> Reported by: Christer Holmberg <christer.holmberg@ericsson.com>
>
> Section: 5.4
>
> Original Text
> -------------
> extension-access-info  =3D gen-value
>
> Corrected Text
> --------------
> extension-access-info  =3D generic-param
>
> Notes
> -----
> Most of the pre-defined access-info values are following the
> generic-param syntax. New access-info values (extensions) should also =
> be allowed to follow the generic-param syntax, in order to allow both =
> for a name and value of the extension.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or = rejected.
> When a decision is reached, the verifying party (IESG) can log in to <= br> > change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC7315 (draft-drage-sipping-rfc3455bis-14)
> --------------------------------------
> Title           = ;    : Private Header (P-Header) Extensions to the
> Session Initiation Protocol (SIP) for the 3GPP
> Publication Date    : July 2014
> Author(s)           = : R. Jesske, K. Drage, C. Holmberg
> Category          &n= bsp; : INFORMATIONAL
> Source          &nbs= p;   : IETF - NON WORKING GROUP
> Area           =      : N/A
> Stream          &nbs= p;   : IETF
> Verifying Party     : IESG
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.= ietf.org/mailman/listinfo/sipcore

--_000_7594FB04B1934943A5C02806D1A2204B37AC0CF1ESESSMB209erics_-- From nobody Mon Sep 21 03:27:29 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124EB1B3013 for ; Mon, 21 Sep 2015 03:27:28 -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, 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 HA5aMhyclRj3 for ; Mon, 21 Sep 2015 03:27:26 -0700 (PDT) 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 A254F1B303D for ; Mon, 21 Sep 2015 03:27:25 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-8e-55ffdb8b75ea Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 78.60.05274.B8BDFF55; Mon, 21 Sep 2015 12:27:23 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.171]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Mon, 21 Sep 2015 12:27:23 +0200 From: Christer Holmberg To: "A. Jean Mahoney" , Ben Campbell , Paul Kyzivat Thread-Topic: [sipcore] RSeq and forking - Errata Thread-Index: AdCjwjb6aIhPA9HcRsaaDgKN4yT4tAG3gD/g///pywD//9iRUIAU+dAA//9WNoCAEf+lAIAADcgAgAAA4oCAASKMAP+ewsGQ/zKWcYA= Date: Mon, 21 Sep 2015 10:27:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37AC1D1C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F33B4@ESESSMB209.ericsson.se> <55843746.1070907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D8F35A0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D908280@ESESSMB209.ericsson.se> <55A44506.3090209@alum.mit.edu> <4327D8C7-211A-439C-A3DE-012FC094B517@nostrum.com> <55A5397E.6050804@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37A7B565@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37A7B565@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.18] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM+JvjW737f+hBnsvm1nM7zzNbtHQuZLV YsWGA6wWX39sYnNg8fj7/gOTx5IlP5k8Zu18whLAHMVlk5Kak1mWWqRvl8CVcb/XoWCfVsXi M2tYGhifKnYxcnJICJhIbDizhRHCFpO4cG89WxcjF4eQwFFGiT/X/jCDJIQEljBKTP4h38XI wcEmYCHR/U8bJCwiUCyx+sFqNhCbWUBT4tHOvUwgtrCAgcSPLy9YIGoMJU6eaIeyyySOTbsO Vs8ioCpxeeEtVhCbV8BXYsLJFawQex+ySHT2LGMD2cUp4Cfx604ySA0j0G3fT61hgtglLnHr yXwmiJsFJJbsOc8MYYtKvHz8jxXCVpT4+GofI0S9nsSNqVOg7tSWWLbwNTPEXkGJkzOfsExg FJuFZOwsJC2zkLTMQtKygJFlFaNocWpxUm66kbFealFmcnFxfp5eXmrJJkZgZB3c8lt1B+Pl N46HGAU4GJV4eBN0/ocKsSaWFVfmHmKU5mBREudtZnoQKiSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoFR7n+Q6efvV16UH93qYBizoZx1oepD238XDx2785FLqPrPxQRde9v/Nh9dI9cI89Ua 77mwMSNRP9bhbpjfW44y2Zmrzx57WrVCuO2g0mEZjXezObf3HHK586iL21RbNmqxbFNGyvRT G1u2RH3WML5b87thK7cXy6vTSwK4bCbkn3/1tvxb+JkmJZbijERDLeai4kQAAzJgQI0CAAA= Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 10:27:28 -0000 Any news on this? I would request that those who had issues with the text try to suggest how = it could be improved :) Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 14. syyskuuta 2015 14:47 To: A. Jean Mahoney; Ben Campbell; Paul Kyzivat Cc: sipcore@ietf.org Subject: Re: [sipcore] RSeq and forking - Errata Hi, We were going to continue this discussion after Prague, so here we go :) The issue was that currently the text does not make it clear that, when a r= equest is forked, the scope of the RSeq value is per individual fork. As far as I know, there was no objection to the issue as such. However, peo= ple did not think the suggested text was good enough. The original text (Section 4 of RFC 3262) says: "Handling of subsequent reliable provisional responses for the same initial request follows the same rules as above, with the following difference: reliable provisional responses are guaranteed to be in order. As a result, if the UAC receives another reliable provisional response to the same request, and its RSeq value is not one higher than the value of the sequence number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache the response in the hopes of receiving the missing responses." In the previous Errata, the suggested correction text was: =20 "Handling of subsequent reliable provisional responses for the same initial request follows the same rules as above, with the following difference: reliable provisional responses are guaranteed to be in order. As a result, if the UAC receives another reliable provisional response to the same request on a given dialog, and its RSeq value is not one higher than the value of the sequence number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache the response in the hopes of receiving the missing responses. If forking occurs, RSeq values are processed on each early dialog independently." Paul said: "Note that the scope of RSeq values is a single INVITE transaction, not a d= ialog. (So, for a re-INVITE in the same dialog the RSeq value might turn ou= t to be lower than that for the INVITE that established the dialog.) But that value space is owned by the UAS for the INVITE. So, from the persp= ective of the sender of the INVITE (receiver of provisional responses), the= value space must be managed independently for the combination of INVITE tr= ansaction AND dialog id. So the required logic is somewhat different than w= hat is required for CSeq." Comments? Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of A. Jean Mahone= y Sent: 14. hein=E4kuuta 2015 19:32 To: Ben Campbell; Paul Kyzivat Cc: sipcore@ietf.org Subject: Re: [sipcore] RSeq and forking - Errata On 7/13/15 6:12 PM, Ben Campbell wrote: > On 13 Jul 2015, at 18:08, Paul Kyzivat wrote: > >> On 7/13/15 6:19 PM, Ben Campbell wrote: >>> >>> >>> On 3 Jul 2015, at 0:46, Christer Holmberg wrote: >>> >>>> Hi Ben, >>>> >>>> Assuming we have to submit a new errata in order to do the word=20 >>>> smiting, I guess rejecting the current one is the way forward. >>>> Nobody has objected to the correction as such. >>> >>> "word smiting" is a wonderful typo for this. I'm going to use that=20 >>> one :-) >>> >>> Rejecting it is not absolutely necessary to edit the wording, but I=20 >>> think it may be the right thing to do here [see below] >>> >>>> >>>> However, I guess we should then on the list should agree on the=20 >>>> actual text, before submitting a new errata. >>> >>> I agree. But after reading the discussion so far (especially Paul's=20 >>> comment), I'm not sure if this is a simple fix, or if it needs more=20 >>> thought. Therefore I'm going to reject the errata as it currently=20 >>> stands. I'd like to see the working group discuss the correct fix. >>> If that turns out to be an errata, we can submit that one when it's=20 >>> agreed upon. If it turns out to be something else, we can cross that=20 >>> bridge when we come to it. >> >> Do we want to start that discussion *now*? Or wait until after the=20 >> meeting? >> >> While sipcore isn't meeting, most of the sipcore regulars are=20 >> probably concentrating on things that *will* be going on at the=20 >> meeting. So I'm inclined to think it would be better to wait about a=20 >> month before starting the discussion. > > I will leave that to the chairs, but I don't think the world is going=20 > to end if it waits a few weeks. It's OK with the chairs to hold off discussing this topic until after Pragu= e. Jean > > Ben. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Sep 21 08:43:42 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0727A1B335B for ; Mon, 21 Sep 2015 08:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 po3-NlviKuPy for ; Mon, 21 Sep 2015 08:43:39 -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 E0A251B3354 for ; Mon, 21 Sep 2015 08:43:37 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-04v.sys.comcast.net with comcast id Krho1r0042TL4Rh01rjcjC; Mon, 21 Sep 2015 15:43:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-17v.sys.comcast.net with comcast id Krjb1r00c3Ge9ey01rjcjH; Mon, 21 Sep 2015 15:43:36 +0000 To: Christer Holmberg , "A. Jean Mahoney" , Ben Campbell References: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F33B4@ESESSMB209.ericsson.se> <55843746.1070907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D8F35A0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D908280@ESESSMB209.ericsson.se> <55A44506.3090209@alum.mit.edu> <4327D8C7-211A-439C-A3DE-012FC094B517@nostrum.com> <55A5397E.6050804@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37A7B565@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <560025A7.7060207@alum.mit.edu> Date: Mon, 21 Sep 2015 11:43:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37A7B565@ESESSMB209.ericsson.se> 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=1442850216; bh=KNAnBgiepUqKxP7BfJ0VauSycuy1u8oeH+hIOHZI9ZU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=phwGaWE9clckk47O8cL0ZDcNR7NavRA05V8dA9f1R3A3WvFgElidLjl64zisTgskp YNBHxVK7dIdegZsquGssmpMHEXNvkrtlOhAH0z6iBTtXhKI63Bc/42IfkggIbgLMhN o1Eactm+6PUJOObRWpLJv9hv33LpdtYoTTGuety20QF0xLa0QZ4zx0BxA/+vkeeyEL HgpJI7Jh5blsAhSSau6R1SBaEnsn9eTv/VVtbGJzLh6jy7+xA7eZ+V4s0/MPlU5oMa CFBFkC0FKStVpPl3ROZNMulgJOn1ziRiAmyLGQPxhl1L/LgVx0GvMgruJq50lqGpAC H2edHeBXMM7Ow== Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 15:43:41 -0000 I just went back and reviewed 3262 again. The paragraph in question, and the few preceding it, say they apply to an "initial request". So we should verify exactly what that is intended to mean. (I was thinking it might mean the INVITE that establishes a dialog, but I'm not sure of that.) I searched back, and found the following in section 3: "A UAS MAY send any non-100 provisional response to INVITE reliably, so long as the initial INVITE request (the request whose provisional response is being sent reliably) ..." So I think this in intended to apply to both the dialog-establishing INVITE and any re-INVITEs within the dialog that contains Supported:100rel. So, back to the questionable text in section 4 ... My concern is with the state the the UAC must maintain. The preceding paragraph talks about the state. I propose changing it as follows: OLD: Once a reliable provisional response is received, retransmissions of that response MUST be discarded. A response is a retransmission when its dialog ID, CSeq, and RSeq match the original response. The UAC MUST maintain a sequence number that indicates the most recently received in-order reliable provisional response for the initial request. This sequence number MUST be maintained until a final response is received for the initial request. Its value MUST be initialized to the RSeq header field in the first reliable provisional response received for the initial request. NEW: Once a reliable provisional response is received, retransmissions of that response MUST be discarded. A response is a retransmission when its dialog ID, CSeq, and RSeq match the original response. The UAC MUST maintain<<, independently for each dialog ID,>> a sequence number that indicates the most recently received in-order reliable provisional response for the initial request. This sequence number MUST be maintained until a final response is received for the initial request. Its value MUST be initialized to the RSeq header field in the first reliable provisional response received for the initial request<< in a dialog>>. (I highlighted the changes with << >>.) Then the following paragraph also needs to be adjusted, because it neglected to specify that the state needs to be updated for successful subsequent provisional responses: OLD: Handling of subsequent reliable provisional responses for the same initial request follows the same rules as above, with the following difference: reliable provisional responses are guaranteed to be in order. As a result, if the UAC receives another reliable provisional response to the same request, and its RSeq value is not one higher than the value of the sequence number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache the response in the hopes of receiving the missing responses. NEW: Subsequent reliable provisional responses for the same initial request are guaranteed to be in order. If the UAC receives another reliable provisional response to the same request, and its RSeq value is one higher than the value of the previously received RSeq value in the dialog, then the new RSeq value is saved and the response is handled as described above. If the RSeq value is not one higher than the value of the sequence number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache the response in the hopes of receiving the missing responses. The changes were too extensive to highlight. I think this is clearer about what is intended. Thanks, Paul On 9/14/15 7:47 AM, Christer Holmberg wrote: > Hi, > > We were going to continue this discussion after Prague, so here we go :) > > The issue was that currently the text does not make it clear that, when a request is forked, the scope of the RSeq value is per individual fork. > > As far as I know, there was no objection to the issue as such. However, people did not think the suggested text was good enough. > > The original text (Section 4 of RFC 3262) says: > > "Handling of subsequent reliable provisional responses for the same > initial request follows the same rules as above, with the following > difference: reliable provisional responses are guaranteed to be in > order. As a result, if the UAC receives another reliable provisional > response to the same request, and its RSeq value is not one higher > than the value of the sequence number, that response MUST NOT be > acknowledged with a PRACK, and MUST NOT be processed further by the > UAC. An implementation MAY discard the response, or MAY cache the > response in the hopes of receiving the missing responses." > > > In the previous Errata, the suggested correction text was: > > > "Handling of subsequent reliable provisional responses for the same > initial request follows the same rules as above, with the following > difference: reliable provisional responses are guaranteed to be in > order. As a result, if the UAC receives another reliable provisional > response to the same request on a given dialog, and its RSeq value is > not one higher than the value of the sequence number, that response > MUST NOT be acknowledged with a PRACK, and MUST NOT be processed > further by the UAC. An implementation MAY discard the response, or > MAY cache the response in the hopes of receiving the missing > responses. If forking occurs, RSeq values are processed on each early > dialog independently." > > > Paul said: > > "Note that the scope of RSeq values is a single INVITE transaction, not a dialog. (So, for a re-INVITE in the same dialog the RSeq value might turn out to be lower than that for the INVITE that established the dialog.) > > But that value space is owned by the UAS for the INVITE. So, from the perspective of the sender of the INVITE (receiver of provisional responses), the value space must be managed independently for the combination of INVITE transaction AND dialog id. So the required logic is somewhat different than what is required for CSeq." > > Comments? > > Regards, > > Christer > > > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of A. Jean Mahoney > Sent: 14. heinäkuuta 2015 19:32 > To: Ben Campbell; Paul Kyzivat > Cc: sipcore@ietf.org > Subject: Re: [sipcore] RSeq and forking - Errata > > On 7/13/15 6:12 PM, Ben Campbell wrote: >> On 13 Jul 2015, at 18:08, Paul Kyzivat wrote: >> >>> On 7/13/15 6:19 PM, Ben Campbell wrote: >>>> >>>> >>>> On 3 Jul 2015, at 0:46, Christer Holmberg wrote: >>>> >>>>> Hi Ben, >>>>> >>>>> Assuming we have to submit a new errata in order to do the word >>>>> smiting, I guess rejecting the current one is the way forward. >>>>> Nobody has objected to the correction as such. >>>> >>>> "word smiting" is a wonderful typo for this. I'm going to use that >>>> one :-) >>>> >>>> Rejecting it is not absolutely necessary to edit the wording, but I >>>> think it may be the right thing to do here [see below] >>>> >>>>> >>>>> However, I guess we should then on the list should agree on the >>>>> actual text, before submitting a new errata. >>>> >>>> I agree. But after reading the discussion so far (especially Paul's >>>> comment), I'm not sure if this is a simple fix, or if it needs more >>>> thought. Therefore I'm going to reject the errata as it currently >>>> stands. I'd like to see the working group discuss the correct fix. >>>> If that turns out to be an errata, we can submit that one when it's >>>> agreed upon. If it turns out to be something else, we can cross that >>>> bridge when we come to it. >>> >>> Do we want to start that discussion *now*? Or wait until after the >>> meeting? >>> >>> While sipcore isn't meeting, most of the sipcore regulars are >>> probably concentrating on things that *will* be going on at the >>> meeting. So I'm inclined to think it would be better to wait about a >>> month before starting the discussion. >> >> I will leave that to the chairs, but I don't think the world is going >> to end if it waits a few weeks. > > It's OK with the chairs to hold off discussing this topic until after Prague. > > Jean > >> >> Ben. >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Sep 21 09:16:52 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A1A1A90FA for ; Mon, 21 Sep 2015 09:16:51 -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, 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 ywSDooCF2sMI for ; Mon, 21 Sep 2015 09:16:49 -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 7A5161A90F7 for ; Mon, 21 Sep 2015 09:16:48 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-b9-56002d6e60b9 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B4.4E.27359.E6D20065; Mon, 21 Sep 2015 18:16:46 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.171]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Mon, 21 Sep 2015 18:16:46 +0200 From: Christer Holmberg To: Paul Kyzivat , "A. Jean Mahoney" , Ben Campbell Thread-Topic: [sipcore] RSeq and forking - Errata Thread-Index: AdCjwjb6aIhPA9HcRsaaDgKN4yT4tAG3gD/g///pywD//9iRUIAU+dAA//9WNoCAEf+lAIAADcgAgAAA4oCAASKMAP+ewsGQGbQTAoD//9WhMA== Date: Mon, 21 Sep 2015 16:16:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37AC784A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F33B4@ESESSMB209.ericsson.se> <55843746.1070907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D8F35A0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D908280@ESESSMB209.ericsson.se> <55A44506.3090209@alum.mit.edu> <4327D8C7-211A-439C-A3DE-012FC094B517@nostrum.com> <55A5397E.6050804@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37A7B565@ESESSMB209.ericsson.se> <560025A7.7060207@alum.mit.edu> In-Reply-To: <560025A7.7060207@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+JvjW6eLkOYwfbZhhbzO0+zWzR0rmS1 WLHhAKvF1x+b2BxYPP6+/8DksWTJTyaPWTufsAQwR3HZpKTmZJalFunbJXBlbN6nUXDCu+Lu 1c3MDYwLrLsYOTkkBEwkehZfZ4ewxSQu3FvP1sXIxSEkcJRRYsPjLmYIZwmjxLL200AOBweb gIVE9z9tkAYRgWKJ7f2TGEFsZgFNiUc79zKB2MICBhI/vrxggagxlDh5oh3KrpN4Ne0QK8gY FgFVif89+iBhXgFfiSMrL7NArGpmlXixshdsDqeAjsS1n32sIDYj0HHfT61hgtglLnHryXwm iKMFJJbsOc8MYYtKvHz8jxXCVpJoXPKEFaJeT+LG1ClsELa2xLKFr5khFgtKnJz5hGUCo9gs JGNnIWmZhaRlFpKWBYwsqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjECY+vglt8GOxhfPnc8 xCjAwajEw5ug8z9UiDWxrLgy9xCjNAeLkjhvM9ODUCGB9MSS1OzU1ILUovii0pzU4kOMTByc Ug2MwXtDZbtOWjVF8P2U6+/kV2dtnvvqSlTGl7AdM6et/xg75Vrbjly19j/FPiX1QkVrYibN Mfs/n+clO4vYgiuywSt8BBkmTZM9tdIovWSH6sqL+61zlZ+9uzDda9eJ27VnQzVW/20oz7p9 +7rV97UTvS9Jeu2bNFd55q4PtsvkZjmn/922d7fvTSWW4oxEQy3mouJEALlS5HuOAgAA Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 16:16:51 -0000 Hi Paul, I'll take a closer look at your suggested changes later, but please note th= at the text in section 4 talks about *initial* request. Should we remove 'i= nitial', in order to make it clear that the text also applies to re-INVITEs= ? Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 21 September 2015 18:44 To: Christer Holmberg ; A. Jean Mahoney ; Ben Campbell Cc: sipcore@ietf.org Subject: Re: [sipcore] RSeq and forking - Errata I just went back and reviewed 3262 again. The paragraph in question, and the few preceding it, say they apply to an "= initial request". So we should verify exactly what that is intended to mean= . (I was thinking it might mean the INVITE that establishes a dialog, but I= 'm not sure of that.) I searched back, and found the following in section 3= : "A UAS MAY send any non-100 provisional response to INVITE reliably, so long as the initial INVITE request (the request whose provisional response is being sent reliably) ..." So I think this in intended to apply to both the dialog-establishing INVITE= and any re-INVITEs within the dialog that contains Supported:100rel. So, back to the questionable text in section 4 ... My concern is with the state the the UAC must maintain. The preceding parag= raph talks about the state. I propose changing it as follows: OLD: Once a reliable provisional response is received, retransmissions of that response MUST be discarded. A response is a retransmission when its dialog ID, CSeq, and RSeq match the original response. The UAC MUST maintain a sequence number that indicates the most recently received in-order reliable provisional response for the initial request. This sequence number MUST be maintained until a final response is received for the initial request. Its value MUST be initialized to the RSeq header field in the first reliable provisional response received for the initial request. NEW: Once a reliable provisional response is received, retransmissions of that response MUST be discarded. A response is a retransmission when its dialog ID, CSeq, and RSeq match the original response. The UAC MUST maintain<<, independently for each dialog ID,>> a sequence number that indicates the most recently received in-order reliable provisional response for the initial request. This sequence number MUST be maintained until a final response is received for the initial request. Its value MUST be initialized to the RSeq header field in the first reliable provisional response received for the initial request<< in a dialog>>. (I highlighted the changes with << >>.) Then the following paragraph also needs to be adjusted, because it neglecte= d to specify that the state needs to be updated for successful subsequent p= rovisional responses: OLD: Handling of subsequent reliable provisional responses for the same initial request follows the same rules as above, with the following difference: reliable provisional responses are guaranteed to be in order. As a result, if the UAC receives another reliable provisional response to the same request, and its RSeq value is not one higher than the value of the sequence number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache the response in the hopes of receiving the missing responses. NEW: Subsequent reliable provisional responses for the same initial request are guaranteed to be in order. If the UAC receives another reliable provisional response to the same request, and its RSeq value is one higher than the value of the previously received RSeq value in the dialog, then the new RSeq value is saved and the response is handled as described above. If the RSeq value is not one higher than the value of the sequence number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache the response in the hopes of receiving the missing responses. The changes were too extensive to highlight. I think this is clearer about = what is intended. Thanks, Paul On 9/14/15 7:47 AM, Christer Holmberg wrote: > Hi, > > We were going to continue this discussion after Prague, so here we go=20 > :) > > The issue was that currently the text does not make it clear that, when a= request is forked, the scope of the RSeq value is per individual fork. > > As far as I know, there was no objection to the issue as such. However, p= eople did not think the suggested text was good enough. > > The original text (Section 4 of RFC 3262) says: > > "Handling of subsequent reliable provisional responses for the same > initial request follows the same rules as above, with the following > difference: reliable provisional responses are guaranteed to be in > order. As a result, if the UAC receives another reliable provisional > response to the same request, and its RSeq value is not one higher > than the value of the sequence number, that response MUST NOT be > acknowledged with a PRACK, and MUST NOT be processed further by the > UAC. An implementation MAY discard the response, or MAY cache the > response in the hopes of receiving the missing responses." > > > In the previous Errata, the suggested correction text was: > > > "Handling of subsequent reliable provisional responses for the same > initial request follows the same rules as above, with the following > difference: reliable provisional responses are guaranteed to be in > order. As a result, if the UAC receives another reliable provisional > response to the same request on a given dialog, and its RSeq value is > not one higher than the value of the sequence number, that response > MUST NOT be acknowledged with a PRACK, and MUST NOT be processed > further by the UAC. An implementation MAY discard the response, or > MAY cache the response in the hopes of receiving the missing > responses. If forking occurs, RSeq values are processed on each early > dialog independently." > > > Paul said: > > "Note that the scope of RSeq values is a single INVITE transaction,=20 > not a dialog. (So, for a re-INVITE in the same dialog the RSeq value=20 > might turn out to be lower than that for the INVITE that established=20 > the dialog.) > > But that value space is owned by the UAS for the INVITE. So, from the per= spective of the sender of the INVITE (receiver of provisional responses), t= he value space must be managed independently for the combination of INVITE = transaction AND dialog id. So the required logic is somewhat different than= what is required for CSeq." > > Comments? > > Regards, > > Christer > > > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of A. Jean=20 > Mahoney > Sent: 14. hein=E4kuuta 2015 19:32 > To: Ben Campbell; Paul Kyzivat > Cc: sipcore@ietf.org > Subject: Re: [sipcore] RSeq and forking - Errata > > On 7/13/15 6:12 PM, Ben Campbell wrote: >> On 13 Jul 2015, at 18:08, Paul Kyzivat wrote: >> >>> On 7/13/15 6:19 PM, Ben Campbell wrote: >>>> >>>> >>>> On 3 Jul 2015, at 0:46, Christer Holmberg wrote: >>>> >>>>> Hi Ben, >>>>> >>>>> Assuming we have to submit a new errata in order to do the word=20 >>>>> smiting, I guess rejecting the current one is the way forward. >>>>> Nobody has objected to the correction as such. >>>> >>>> "word smiting" is a wonderful typo for this. I'm going to use that=20 >>>> one :-) >>>> >>>> Rejecting it is not absolutely necessary to edit the wording, but I=20 >>>> think it may be the right thing to do here [see below] >>>> >>>>> >>>>> However, I guess we should then on the list should agree on the=20 >>>>> actual text, before submitting a new errata. >>>> >>>> I agree. But after reading the discussion so far (especially Paul's=20 >>>> comment), I'm not sure if this is a simple fix, or if it needs more=20 >>>> thought. Therefore I'm going to reject the errata as it currently=20 >>>> stands. I'd like to see the working group discuss the correct fix. >>>> If that turns out to be an errata, we can submit that one when it's=20 >>>> agreed upon. If it turns out to be something else, we can cross=20 >>>> that bridge when we come to it. >>> >>> Do we want to start that discussion *now*? Or wait until after the=20 >>> meeting? >>> >>> While sipcore isn't meeting, most of the sipcore regulars are=20 >>> probably concentrating on things that *will* be going on at the=20 >>> meeting. So I'm inclined to think it would be better to wait about a=20 >>> month before starting the discussion. >> >> I will leave that to the chairs, but I don't think the world is going=20 >> to end if it waits a few weeks. > > It's OK with the chairs to hold off discussing this topic until after Pra= gue. > > Jean > >> >> Ben. >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Sep 21 09:24:25 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0A91A9117 for ; Mon, 21 Sep 2015 09:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 TnsfCxpMCTIo for ; Mon, 21 Sep 2015 09:24:21 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A887C1A9114 for ; Mon, 21 Sep 2015 09:24:21 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-07v.sys.comcast.net with comcast id KsQ61r0072PT3Qt01sQLs3; Mon, 21 Sep 2015 16:24:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-14v.sys.comcast.net with comcast id KsQL1r0053Ge9ey01sQLYG; Mon, 21 Sep 2015 16:24:20 +0000 To: Christer Holmberg , "A. Jean Mahoney" , Ben Campbell References: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F33B4@ESESSMB209.ericsson.se> <55843746.1070907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D8F35A0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D908280@ESESSMB209.ericsson.se> <55A44506.3090209@alum.mit.edu> <4327D8C7-211A-439C-A3DE-012FC094B517@nostrum.com> <55A5397E.6050804@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37A7B565@ESESSMB209.ericsson.se> <560025A7.7060207@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37AC784A@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56002F33.8060802@alum.mit.edu> Date: Mon, 21 Sep 2015 12:24:19 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37AC784A@ESESSMB209.ericsson.se> 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=1442852660; bh=i5SE2evS87MzEVPbV6RmanehdYCp42RB+M7p86DzcN8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=hodmYdfnf55drkk+gr1lG7WpoghfT1nMooqYLW9+5tVHaH9zS3l9sDaLODcAt1JuH /xwmEatmf+8uDYAsg2qd5LNmgNafZQBKiiQMvtGwQDHIyncn9Yvd9nMDnP3IPKwJtQ a90bwcpbU4+XSh8mROuT9SCmDzhPZOJ7zaNh8Bp3O8nBQvsXv6RwAlO1sQng/m6UhG q0T7M6/wRYVyQYOKFNecLHB3sL0qEav4isjp4fIJVlG/CicDxOo+QSD3JIRHMEX2gl C6HZr0MxlEvD2I05RLtVhlBhpG1LRGfrH6Msj1r4rxqxeZURmWsSLFP0IFggsguCNx eF7h7iRPrHFyA== Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 16:24:24 -0000 On 9/21/15 12:16 PM, Christer Holmberg wrote: > Hi Paul, > > I'll take a closer look at your suggested changes later, but please note that the text in section 4 talks about *initial* request. Should we remove 'initial', in order to make it clear that the text also applies to re-INVITEs? I think "initial" request was a poor choice with the document was written. But that usage pervades the document. I don't think it makes sense to change it in this one place. If we were to do a bis then I would be inclined to rework it throughout. Thanks, Paul > Regards, > > Christer > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 21 September 2015 18:44 > To: Christer Holmberg ; A. Jean Mahoney ; Ben Campbell > Cc: sipcore@ietf.org > Subject: Re: [sipcore] RSeq and forking - Errata > > I just went back and reviewed 3262 again. > > The paragraph in question, and the few preceding it, say they apply to an "initial request". So we should verify exactly what that is intended to mean. (I was thinking it might mean the INVITE that establishes a dialog, but I'm not sure of that.) I searched back, and found the following in section 3: > > "A UAS MAY send any non-100 provisional response to INVITE reliably, > so long as the initial INVITE request (the request whose provisional > response is being sent reliably) ..." > > So I think this in intended to apply to both the dialog-establishing INVITE and any re-INVITEs within the dialog that contains Supported:100rel. > > So, back to the questionable text in section 4 ... > > My concern is with the state the the UAC must maintain. The preceding paragraph talks about the state. I propose changing it as follows: > > OLD: > > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission when > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain a sequence number that indicates the most recently > received in-order reliable provisional response for the initial > request. This sequence number MUST be maintained until a final > response is received for the initial request. Its value MUST be > initialized to the RSeq header field in the first reliable > provisional response received for the initial request. > > NEW: > > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission when > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain<<, independently for each dialog ID,>> a sequence > number that indicates the most recently received in-order reliable > provisional response for the initial request. This sequence number > MUST be maintained until a final response is received for the initial > request. Its value MUST be initialized to the RSeq header field in > the first reliable provisional response received for the initial > request<< in a dialog>>. > > (I highlighted the changes with << >>.) > > Then the following paragraph also needs to be adjusted, because it neglected to specify that the state needs to be updated for successful subsequent provisional responses: > > OLD: > > Handling of subsequent reliable provisional responses for the same > initial request follows the same rules as above, with the following > difference: reliable provisional responses are guaranteed to be in > order. As a result, if the UAC receives another reliable provisional > response to the same request, and its RSeq value is not one higher > than the value of the sequence number, that response MUST NOT be > acknowledged with a PRACK, and MUST NOT be processed further by the > UAC. An implementation MAY discard the response, or MAY cache the > response in the hopes of receiving the missing responses. > > NEW: > > Subsequent reliable provisional responses for the same initial > request are guaranteed to be in order. If the UAC receives another > reliable provisional response to the same request, and its RSeq > value is one higher than the value of the previously received RSeq > value in the dialog, then the new RSeq value is saved and the > response is handled as described above. If the RSeq value is not one > higher than the value of the sequence number, that response MUST NOT > be acknowledged with a PRACK, and MUST NOT be processed further by > the UAC. An implementation MAY discard the response, or MAY cache > the response in the hopes of receiving the missing responses. > > The changes were too extensive to highlight. I think this is clearer about what is intended. > > Thanks, > Paul > > > On 9/14/15 7:47 AM, Christer Holmberg wrote: >> Hi, >> >> We were going to continue this discussion after Prague, so here we go >> :) >> >> The issue was that currently the text does not make it clear that, when a request is forked, the scope of the RSeq value is per individual fork. >> >> As far as I know, there was no objection to the issue as such. However, people did not think the suggested text was good enough. >> >> The original text (Section 4 of RFC 3262) says: >> >> "Handling of subsequent reliable provisional responses for the same >> initial request follows the same rules as above, with the following >> difference: reliable provisional responses are guaranteed to be in >> order. As a result, if the UAC receives another reliable provisional >> response to the same request, and its RSeq value is not one higher >> than the value of the sequence number, that response MUST NOT be >> acknowledged with a PRACK, and MUST NOT be processed further by the >> UAC. An implementation MAY discard the response, or MAY cache the >> response in the hopes of receiving the missing responses." >> >> >> In the previous Errata, the suggested correction text was: >> >> >> "Handling of subsequent reliable provisional responses for the same >> initial request follows the same rules as above, with the following >> difference: reliable provisional responses are guaranteed to be in >> order. As a result, if the UAC receives another reliable provisional >> response to the same request on a given dialog, and its RSeq value is >> not one higher than the value of the sequence number, that response >> MUST NOT be acknowledged with a PRACK, and MUST NOT be processed >> further by the UAC. An implementation MAY discard the response, or >> MAY cache the response in the hopes of receiving the missing >> responses. If forking occurs, RSeq values are processed on each early >> dialog independently." >> >> >> Paul said: >> >> "Note that the scope of RSeq values is a single INVITE transaction, >> not a dialog. (So, for a re-INVITE in the same dialog the RSeq value >> might turn out to be lower than that for the INVITE that established >> the dialog.) >> >> But that value space is owned by the UAS for the INVITE. So, from the perspective of the sender of the INVITE (receiver of provisional responses), the value space must be managed independently for the combination of INVITE transaction AND dialog id. So the required logic is somewhat different than what is required for CSeq." >> >> Comments? >> >> Regards, >> >> Christer >> >> >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of A. Jean >> Mahoney >> Sent: 14. heinäkuuta 2015 19:32 >> To: Ben Campbell; Paul Kyzivat >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] RSeq and forking - Errata >> >> On 7/13/15 6:12 PM, Ben Campbell wrote: >>> On 13 Jul 2015, at 18:08, Paul Kyzivat wrote: >>> >>>> On 7/13/15 6:19 PM, Ben Campbell wrote: >>>>> >>>>> >>>>> On 3 Jul 2015, at 0:46, Christer Holmberg wrote: >>>>> >>>>>> Hi Ben, >>>>>> >>>>>> Assuming we have to submit a new errata in order to do the word >>>>>> smiting, I guess rejecting the current one is the way forward. >>>>>> Nobody has objected to the correction as such. >>>>> >>>>> "word smiting" is a wonderful typo for this. I'm going to use that >>>>> one :-) >>>>> >>>>> Rejecting it is not absolutely necessary to edit the wording, but I >>>>> think it may be the right thing to do here [see below] >>>>> >>>>>> >>>>>> However, I guess we should then on the list should agree on the >>>>>> actual text, before submitting a new errata. >>>>> >>>>> I agree. But after reading the discussion so far (especially Paul's >>>>> comment), I'm not sure if this is a simple fix, or if it needs more >>>>> thought. Therefore I'm going to reject the errata as it currently >>>>> stands. I'd like to see the working group discuss the correct fix. >>>>> If that turns out to be an errata, we can submit that one when it's >>>>> agreed upon. If it turns out to be something else, we can cross >>>>> that bridge when we come to it. >>>> >>>> Do we want to start that discussion *now*? Or wait until after the >>>> meeting? >>>> >>>> While sipcore isn't meeting, most of the sipcore regulars are >>>> probably concentrating on things that *will* be going on at the >>>> meeting. So I'm inclined to think it would be better to wait about a >>>> month before starting the discussion. >>> >>> I will leave that to the chairs, but I don't think the world is going >>> to end if it waits a few weeks. >> >> It's OK with the chairs to hold off discussing this topic until after Prague. >> >> Jean >> >>> >>> Ben. >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > From nobody Mon Sep 21 09:37:03 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC801A914B for ; Mon, 21 Sep 2015 09:37:01 -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, 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 Q1-0vaBmcMSV for ; Mon, 21 Sep 2015 09:36:59 -0700 (PDT) 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 4B6661A9134 for ; Mon, 21 Sep 2015 09:36:58 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-0c-56003228cc44 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BB.F4.17026.82230065; Mon, 21 Sep 2015 18:36:56 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.171]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Mon, 21 Sep 2015 18:36:55 +0200 From: Christer Holmberg To: Paul Kyzivat , "A. Jean Mahoney" , Ben Campbell Thread-Topic: [sipcore] RSeq and forking - Errata Thread-Index: AdCjwjb6aIhPA9HcRsaaDgKN4yT4tAG3gD/g///pywD//9iRUIAU+dAA//9WNoCAEf+lAIAADcgAgAAA4oCAASKMAP+ewsGQGbQTAoD//9WhMP//yj+A//9vwbA= Date: Mon, 21 Sep 2015 16:36:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37AC7A3F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F33B4@ESESSMB209.ericsson.se> <55843746.1070907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D8F35A0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D908280@ESESSMB209.ericsson.se> <55A44506.3090209@alum.mit.edu> <4327D8C7-211A-439C-A3DE-012FC094B517@nostrum.com> <55A5397E.6050804@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37A7B565@ESESSMB209.ericsson.se> <560025A7.7060207@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37AC784A@ESESSMB209.ericsson.se> <56002F33.8060802@alum.mit.edu> In-Reply-To: <56002F33.8060802@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM+Jvja6GEUOYwa4D8hbzO0+zWzR0rmS1 WLHhAKvF1x+b2BxYPP6+/8DksWTJTyaPWTufsAQwR3HZpKTmZJalFunbJXBl3Fv/h7ngYGDF s3kbWBsY19p3MXJySAiYSFzv38MCYYtJXLi3nq2LkYtDSOAoo8TK47eYIZwljBI/G1cwdjFy cLAJWEh0/9MGaRARKJbY3j+JEcRmFtCUeLRzLxOILSxgIPHjywsWiBpDiZMn2llA5ogIdDFK LF6whhVkDouAqsSbfyogNbwCvhLHNzczQux6ySqx5fpzZpAEp4COxKyj78GGMgJd9/3UGiaI ZeISt57MZ4K4WkBiyZ7zzBC2qMTLx/9YIWwlicYlT1gh6vUkbkydwgZha0ssW/iaGWKxoMTJ mU9YJjCKzUIydhaSlllIWmYhaVnAyLKKUbQ4tbg4N93IWC+1KDO5uDg/Ty8vtWQTIzC+Dm75 rbuDcfVrx0OMAhyMSjy8CTr/Q4VYE8uKK3MPMUpzsCiJ87YwPQgVEkhPLEnNTk0tSC2KLyrN SS0+xMjEwSnVwOirLsw430briY5R5rGMGed+93z56rN4aQWPbTzTAqF7JZwVfFtTnOKFnrQ8 SX1w6FyYypmvx3ab3JJ6s311qtXt23tFklb+KOXQ608LOnp5dtSmE/v48u/kOxUnH13RlfhY bPWks3uC/vjNEnj15+fip1Ky6o/UWMt1vRdPeH+V0/rFBZ27cy8qsRRnJBpqMRcVJwIASDTf R5ACAAA= Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 16:37:01 -0000 Hi, >> I'll take a closer look at your suggested changes later, but please note= that the text in section 4 talks about *initial* request. Should=20 >> we remove 'initial', in order to make it clear that the text also applie= s to re-INVITEs? > > I think "initial" request was a poor choice with the document was written= . But that usage pervades the document. I don't think > it makes sense to change it in this one place. If we were to do a bis the= n I would be inclined to rework it throughout. Some instances of "initial" would stay, because they refer to the initial s= equence number value - not the initial request. Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 21 September 2015 18:44 > To: Christer Holmberg ; A. Jean=20 > Mahoney ; Ben Campbell > Cc: sipcore@ietf.org > Subject: Re: [sipcore] RSeq and forking - Errata > > I just went back and reviewed 3262 again. > > The paragraph in question, and the few preceding it, say they apply to an= "initial request". So we should verify exactly what that is intended to me= an. (I was thinking it might mean the INVITE that establishes a dialog, but= I'm not sure of that.) I searched back, and found the following in section= 3: > > "A UAS MAY send any non-100 provisional response to INVITE reliably, > so long as the initial INVITE request (the request whose provisional > response is being sent reliably) ..." > > So I think this in intended to apply to both the dialog-establishing INVI= TE and any re-INVITEs within the dialog that contains Supported:100rel. > > So, back to the questionable text in section 4 ... > > My concern is with the state the the UAC must maintain. The preceding par= agraph talks about the state. I propose changing it as follows: > > OLD: > > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission whe= n > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain a sequence number that indicates the most recently > received in-order reliable provisional response for the initial > request. This sequence number MUST be maintained until a final > response is received for the initial request. Its value MUST be > initialized to the RSeq header field in the first reliable > provisional response received for the initial request. > > NEW: > > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission whe= n > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain<<, independently for each dialog ID,>> a sequence > number that indicates the most recently received in-order reliable > provisional response for the initial request. This sequence number > MUST be maintained until a final response is received for the initia= l > request. Its value MUST be initialized to the RSeq header field in > the first reliable provisional response received for the initial > request<< in a dialog>>. > > (I highlighted the changes with << >>.) > > Then the following paragraph also needs to be adjusted, because it neglec= ted to specify that the state needs to be updated for successful subsequent= provisional responses: > > OLD: > > Handling of subsequent reliable provisional responses for the same > initial request follows the same rules as above, with the following > difference: reliable provisional responses are guaranteed to be in > order. As a result, if the UAC receives another reliable provisiona= l > response to the same request, and its RSeq value is not one higher > than the value of the sequence number, that response MUST NOT be > acknowledged with a PRACK, and MUST NOT be processed further by the > UAC. An implementation MAY discard the response, or MAY cache the > response in the hopes of receiving the missing responses. > > NEW: > > Subsequent reliable provisional responses for the same initial > request are guaranteed to be in order. If the UAC receives another > reliable provisional response to the same request, and its RSeq > value is one higher than the value of the previously received RSeq > value in the dialog, then the new RSeq value is saved and the > response is handled as described above. If the RSeq value is not one > higher than the value of the sequence number, that response MUST NOT > be acknowledged with a PRACK, and MUST NOT be processed further by > the UAC. An implementation MAY discard the response, or MAY cache > the response in the hopes of receiving the missing responses. > > The changes were too extensive to highlight. I think this is clearer abou= t what is intended. > > Thanks, > Paul > > > On 9/14/15 7:47 AM, Christer Holmberg wrote: >> Hi, >> >> We were going to continue this discussion after Prague, so here we go >> :) >> >> The issue was that currently the text does not make it clear that, when = a request is forked, the scope of the RSeq value is per individual fork. >> >> As far as I know, there was no objection to the issue as such. However, = people did not think the suggested text was good enough. >> >> The original text (Section 4 of RFC 3262) says: >> >> "Handling of subsequent reliable provisional responses for the same >> initial request follows the same rules as above, with the following >> difference: reliable provisional responses are guaranteed to be in >> order. As a result, if the UAC receives another reliable provision= al >> response to the same request, and its RSeq value is not one higher >> than the value of the sequence number, that response MUST NOT be >> acknowledged with a PRACK, and MUST NOT be processed further by the >> UAC. An implementation MAY discard the response, or MAY cache the >> response in the hopes of receiving the missing responses." >> >> >> In the previous Errata, the suggested correction text was: >> >> >> "Handling of subsequent reliable provisional responses for the sam= e >> initial request follows the same rules as above, with the following >> difference: reliable provisional responses are guaranteed to be in >> order. As a result, if the UAC receives another reliable provision= al >> response to the same request on a given dialog, and its RSeq value = is >> not one higher than the value of the sequence number, that response >> MUST NOT be acknowledged with a PRACK, and MUST NOT be processed >> further by the UAC. An implementation MAY discard the response, o= r >> MAY cache the response in the hopes of receiving the missing >> responses. If forking occurs, RSeq values are processed on each ear= ly >> dialog independently." >> >> >> Paul said: >> >> "Note that the scope of RSeq values is a single INVITE transaction,=20 >> not a dialog. (So, for a re-INVITE in the same dialog the RSeq value=20 >> might turn out to be lower than that for the INVITE that established=20 >> the dialog.) >> >> But that value space is owned by the UAS for the INVITE. So, from the pe= rspective of the sender of the INVITE (receiver of provisional responses), = the value space must be managed independently for the combination of INVITE= transaction AND dialog id. So the required logic is somewhat different tha= n what is required for CSeq." >> >> Comments? >> >> Regards, >> >> Christer >> >> >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of A. Jean=20 >> Mahoney >> Sent: 14. hein=E4kuuta 2015 19:32 >> To: Ben Campbell; Paul Kyzivat >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] RSeq and forking - Errata >> >> On 7/13/15 6:12 PM, Ben Campbell wrote: >>> On 13 Jul 2015, at 18:08, Paul Kyzivat wrote: >>> >>>> On 7/13/15 6:19 PM, Ben Campbell wrote: >>>>> >>>>> >>>>> On 3 Jul 2015, at 0:46, Christer Holmberg wrote: >>>>> >>>>>> Hi Ben, >>>>>> >>>>>> Assuming we have to submit a new errata in order to do the word=20 >>>>>> smiting, I guess rejecting the current one is the way forward. >>>>>> Nobody has objected to the correction as such. >>>>> >>>>> "word smiting" is a wonderful typo for this. I'm going to use that=20 >>>>> one :-) >>>>> >>>>> Rejecting it is not absolutely necessary to edit the wording, but=20 >>>>> I think it may be the right thing to do here [see below] >>>>> >>>>>> >>>>>> However, I guess we should then on the list should agree on the=20 >>>>>> actual text, before submitting a new errata. >>>>> >>>>> I agree. But after reading the discussion so far (especially=20 >>>>> Paul's comment), I'm not sure if this is a simple fix, or if it=20 >>>>> needs more thought. Therefore I'm going to reject the errata as it=20 >>>>> currently stands. I'd like to see the working group discuss the corre= ct fix. >>>>> If that turns out to be an errata, we can submit that one when=20 >>>>> it's agreed upon. If it turns out to be something else, we can=20 >>>>> cross that bridge when we come to it. >>>> >>>> Do we want to start that discussion *now*? Or wait until after the=20 >>>> meeting? >>>> >>>> While sipcore isn't meeting, most of the sipcore regulars are=20 >>>> probably concentrating on things that *will* be going on at the=20 >>>> meeting. So I'm inclined to think it would be better to wait about=20 >>>> a month before starting the discussion. >>> >>> I will leave that to the chairs, but I don't think the world is=20 >>> going to end if it waits a few weeks. >> >> It's OK with the chairs to hold off discussing this topic until after Pr= ague. >> >> Jean >> >>> >>> Ben. >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > From nobody Fri Sep 25 14:43:05 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BEF1A885B; Fri, 25 Sep 2015 14:43:03 -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 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 UGPMDjWGmMQL; Fri, 25 Sep 2015 14:43:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 23FDA1A8853; Fri, 25 Sep 2015 14:43:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DF339187E27; Fri, 25 Sep 2015 14:41:59 -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: <20150925214159.DF339187E27@rfc-editor.org> Date: Fri, 25 Sep 2015 14:41:59 -0700 (PDT) Archived-At: Cc: sipcore@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] RFC 7647 on Clarifications for the Use of REFER with RFC 6665 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 21:43:03 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7647 Title: Clarifications for the Use of REFER with RFC 6665 Author: R. Sparks, A.B. Roach Status: Standards Track Stream: IETF Date: September 2015 Mailbox: rjsparks@nostrum.com, adam@nostrum.com Pages: 6 Characters: 12596 Updates: RFC 3515 I-D Tag: draft-ietf-sipcore-refer-clarifications-04.txt URL: https://www.rfc-editor.org/info/rfc7647 DOI: http://dx.doi.org/10.17487/RFC7647 The SIP REFER method relies on the SIP-Specific Event Notification framework. That framework was revised by RFC 6665. This document highlights the implications of the requirement changes in RFC 6665, and updates the definition of the REFER method described in RFC 3515 to clarify and disambiguate the impact of those changes. This document is a product of the Session Initiation Protocol Core 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/rfc.html 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 Wed Sep 30 00:41:55 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251E41A8761 for ; Wed, 30 Sep 2015 00:41:53 -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, HTML_MESSAGE=0.001, 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 ooHRKNu_xRtQ for ; Wed, 30 Sep 2015 00:41:46 -0700 (PDT) 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 C55841A92BB for ; Wed, 30 Sep 2015 00:41:45 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-94-560b9237f4ec Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id EF.27.17026.7329B065; Wed, 30 Sep 2015 09:41:44 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.171]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 09:41:43 +0200 From: Christer Holmberg To: Ben Campbell Thread-Topic: [sipcore] [Technical Errata Reported] RFC7315 (4474) Thread-Index: AQHQ7t97nIYDUJCaWUq0zXVQ2fcq45474U6QgABWdwCAAEDu14AKWWCwgA33CrA= Date: Wed, 30 Sep 2015 07:41:42 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37AE5E96@ESESSMB209.ericsson.se> References: <20150914112053.D26B1180204@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37A7B4A3@ESESSMB209.ericsson.se>, <13F0EA94-60E1-4735-80DA-55B9D5D64B28@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37A7C011@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37AC0CF1@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37AC0CF1@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.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37AE5E96ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGfG3RtdiEneYwb4ONov5nafZLb7+2MTm wOSxZMlPJo9ZO5+wBDBFcdmkpOZklqUW6dslcGV0zrrIVrClkbHiwsw3bA2MVwu7GDk5JARM JLqndbFA2GISF+6tZ+ti5OIQEjjKKHHjyy8WCGcJo8SPfdeYuhg5ONgELCS6/2mDNIgIKEk8 b94K1swsoCnxaOdeJhBbWMBRYv3nNawQNU4S1+6+Zoew/SS+vW4Di7MIqEp82r4arJ5XwFfi 4c5JjBC7djJJ/H7TwgyS4ARq6Di0BqyIEei676cgbGYBcYlbT+YzQVwtILFkz3lmCFtU4uXj f6wgd0oIKEos75eDKM+X2HtzAxvELkGJkzOfsExgFJ2FZNIsJGWzkJRBxA0kzm3fyA5ha0ss W/iaGcLWl9h+eyYrsvgCRvZVjKLFqcXFuelGxnqpRZnJxcX5eXp5qSWbGIERd3DLb90djKtf Ox5iFOBgVOLhVXDiDhNiTSwrrsw9xCjNwaIkztvC9CBUSCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUAyP/XZ4llisY/3xdqGFx/PpP7sflaj0bTU/+nliw/WjVhvDq2w3hH47fCn0W0iSeuVI5 4v/aaa3bYxVEthrLKG5z+t+T9Lr47fN9BlmT83YeDDDYdqHfJLFd3/2aeLxz71QhlkmBzR3H Ip8bztx2xZbXgPlJ1lJOm/2ZbT6td7fPbD5zvcDx+HclluKMREMt5qLiRAAvDVDimQIAAA== Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 07:41:53 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37AE5E96ESESSMB209erics_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable PING. From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 21. syyskuuta 2015 13:26 To: Ben Campbell Cc: sipcore@ietf.org Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) Any news on this? Regards, Christer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 14. syyskuuta 2015 23:24 To: Ben Campbell Cc: sipcore@ietf.org Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) Hi Ben, I am pretty sure generic-param was the original intention. The majority of = all existing value follow the generic-param syntax, and I can't think of an= y reason why new values would not follow the same syntax. That is how it wo= rks for other header fields too. I think this is due to a mistake, where someone thought that extension-acce= ss-info represents the actual parameter name, and therefor only a value (g= en-value) is needed. But, extension-access-info represents the whole rule (= name AND value), why generic-param is needed :) Regards, Christer Sent from my Windows Phone ________________________________ From: Ben Campbell Sent: =FD14/=FD09/=FD2015 21:31 To: Christer Holmberg Cc: sipcore@ietf.org Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) Hi Christer, Is it your understanding that the use of generic-param was the actual intention at the time 7315 was published? Or was gen-value the original intention, but we now think that it should have been generic-param? Thanks! Ben. On 14 Sep 2015, at 6:22, Christer Holmberg wrote: > FYI, > > I've now submitted the errata. > > Regards, > > Christer > > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: 14. syyskuuta 2015 14:21 > To: r.jesske@telekom.de; drage@alcatel-lucent= .com; Christer Holmberg; > iesg@ietf.org > Cc: Christer Holmberg; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC7315 (4474) > > The following errata report has been submitted for RFC7315, "Private > Header (P-Header) Extensions to the Session Initiation Protocol (SIP) > for the 3GPP". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D7315&eid=3D4474 > > -------------------------------------- > Type: Technical > Reported by: Christer Holmberg > > > Section: 5.4 > > Original Text > ------------- > extension-access-info =3D gen-value > > Corrected Text > -------------- > extension-access-info =3D generic-param > > Notes > ----- > Most of the pre-defined access-info values are following the > generic-param syntax. New access-info values (extensions) should also > be allowed to follow the generic-param syntax, in order to allow both > for a name and value of the extension. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or rejected. > When a decision is reached, the verifying party (IESG) can log in to > change the status and edit the report, if necessary. > > -------------------------------------- > RFC7315 (draft-drage-sipping-rfc3455bis-14) > -------------------------------------- > Title : Private Header (P-Header) Extensions to the > Session Initiation Protocol (SIP) for the 3GPP > Publication Date : July 2014 > Author(s) : R. Jesske, K. Drage, C. Holmberg > Category : INFORMATIONAL > Source : IETF - NON WORKING GROUP > Area : N/A > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --_000_7594FB04B1934943A5C02806D1A2204B37AE5E96ESESSMB209erics_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

PING.

 <= /p>

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 21. syyskuuta 2015 13:26
To: Ben Campbell
Cc: sipcore@ietf.org
Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474)

 

Any news on this?<= o:p>

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: sipcore [= mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 14. syyskuuta 2015 23:24
To: Ben Campbell
Cc: sipcore@ietf.org
Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474)

 

Hi Ben,

I am pretty sure generic-param was the original intention. The majority of = all existing value follow the generic-param syntax, and I can't think of an= y reason why new values would not follow the same syntax. That is how it wo= rks for other header fields too.

I think this is due to a mistake, where someone thought that extension-acce= ss-info  represents the actual parameter name, and therefor only a val= ue (gen-value) is needed. But, extension-access-info represents the whole r= ule (name AND value), why generic-param is needed :)

Regards,

Christer

Sent from my Windows Phone

From: Ben Campbell=
Sent: =FD14/=FD09/=FD2015 21:31
To: Christer Holmberg
Cc: sipcore@ietf.org
Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474)

Hi Christer,

Is it your understanding that the use of generic-param was the actual
intention at the time 7315 was published? Or was gen-value the original intention, but we now think that it should have been generic-param?

Thanks!

Ben.

On 14 Sep 2015, at 6:22, Christer Holmberg wrote:

> FYI,
>
> I've now submitted the errata.
>
> Regards,
>
> Christer
>
> -----Original Message-----
> From: RFC Errata System [= mailto:rfc-editor@rfc-editor.org]
> Sent: 14. syyskuuta 2015 14:21
> To: r.jesske@telekom.de; drage@alcatel-lucent.com; Christer Holmberg;
> iesg@ietf.org
> Cc: Christer Holmberg; rf= c-editor@rfc-editor.org
> Subject: [Technical Errata Reported] RFC7315 (4474)
>
> The following errata report has been submitted for RFC7315, "Priv= ate
> Header (P-Header) Extensions to the Session Initiation Protocol (SIP) =
> for the 3GPP".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D7315&eid= =3D4474
>
> --------------------------------------
> Type: Technical
> Reported by: Christer Holmberg <christer.holmberg@ericsson.com>
>
> Section: 5.4
>
> Original Text
> -------------
> extension-access-info  =3D gen-value
>
> Corrected Text
> --------------
> extension-access-info  =3D generic-param
>
> Notes
> -----
> Most of the pre-defined access-info values are following the
> generic-param syntax. New access-info values (extensions) should also =
> be allowed to follow the generic-param syntax, in order to allow both =
> for a name and value of the extension.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or = rejected.
> When a decision is reached, the verifying party (IESG) can log in to <= br> > change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC7315 (draft-drage-sipping-rfc3455bis-14)
> --------------------------------------
> Title           = ;    : Private Header (P-Header) Extensions to the
> Session Initiation Protocol (SIP) for the 3GPP
> Publication Date    : July 2014
> Author(s)           = : R. Jesske, K. Drage, C. Holmberg
> Category          &n= bsp; : INFORMATIONAL
> Source          &nbs= p;   : IETF - NON WORKING GROUP
> Area           =      : N/A
> Stream          &nbs= p;   : IETF
> Verifying Party     : IESG
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.= ietf.org/mailman/listinfo/sipcore

--_000_7594FB04B1934943A5C02806D1A2204B37AE5E96ESESSMB209erics_-- From nobody Wed Sep 30 07:17:26 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53EA1A8784 for ; Wed, 30 Sep 2015 07:17:23 -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 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 hLNWXX8fA3mg for ; Wed, 30 Sep 2015 07:17:17 -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 B136E1A8757 for ; Wed, 30 Sep 2015 07:17:17 -0700 (PDT) Received: from [10.0.1.23] (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 t8UEHCTs061174 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Sep 2015 09:17:13 -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.23] From: "Ben Campbell" To: "Christer Holmberg" Date: Wed, 30 Sep 2015 09:17:14 -0500 Message-ID: <291D384C-5156-43B3-9760-0E854865FE89@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37AE5E96@ESESSMB209.ericsson.se> References: <20150914112053.D26B1180204@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37A7B4A3@ESESSMB209.ericsson.se> <13F0EA94-60E1-4735-80DA-55B9D5D64B28@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37A7C011@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37AC0CF1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37AE5E96@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 14:17:24 -0000 No one seems to have objected, so I will approve it. Ben. On 30 Sep 2015, at 2:41, Christer Holmberg wrote: > PING. > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer > Holmberg > Sent: 21. syyskuuta 2015 13:26 > To: Ben Campbell > Cc: sipcore@ietf.org > Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) > > Any news on this? > > Regards, > > Christer > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer > Holmberg > Sent: 14. syyskuuta 2015 23:24 > To: Ben Campbell > Cc: sipcore@ietf.org > Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) > > Hi Ben, > > I am pretty sure generic-param was the original intention. The > majority of all existing value follow the generic-param syntax, and I > can't think of any reason why new values would not follow the same > syntax. That is how it works for other header fields too. > > I think this is due to a mistake, where someone thought that > extension-access-info represents the actual parameter name, and > therefor only a value (gen-value) is needed. But, > extension-access-info represents the whole rule (name AND value), why > generic-param is needed :) > > Regards, > > Christer > > Sent from my Windows Phone > ________________________________ > From: Ben Campbell > Sent: ‎14/‎09/‎2015 21:31 > To: Christer Holmberg > Cc: sipcore@ietf.org > Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) > Hi Christer, > > Is it your understanding that the use of generic-param was the actual > intention at the time 7315 was published? Or was gen-value the > original > intention, but we now think that it should have been generic-param? > > Thanks! > > Ben. > > On 14 Sep 2015, at 6:22, Christer Holmberg wrote: > >> FYI, >> >> I've now submitted the errata. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: 14. syyskuuta 2015 14:21 >> To: r.jesske@telekom.de; >> drage@alcatel-lucent.com; Christer >> Holmberg; >> iesg@ietf.org >> Cc: Christer Holmberg; >> rfc-editor@rfc-editor.org >> Subject: [Technical Errata Reported] RFC7315 (4474) >> >> The following errata report has been submitted for RFC7315, "Private >> Header (P-Header) Extensions to the Session Initiation Protocol (SIP) >> for the 3GPP". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=7315&eid=4474 >> >> -------------------------------------- >> Type: Technical >> Reported by: Christer Holmberg >> > >> >> Section: 5.4 >> >> Original Text >> ------------- >> extension-access-info = gen-value >> >> Corrected Text >> -------------- >> extension-access-info = generic-param >> >> Notes >> ----- >> Most of the pre-defined access-info values are following the >> generic-param syntax. New access-info values (extensions) should also >> be allowed to follow the generic-param syntax, in order to allow both >> for a name and value of the extension. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or rejected. >> When a decision is reached, the verifying party (IESG) can log in to >> change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC7315 (draft-drage-sipping-rfc3455bis-14) >> -------------------------------------- >> Title : Private Header (P-Header) Extensions to the >> Session Initiation Protocol (SIP) for the 3GPP >> Publication Date : July 2014 >> Author(s) : R. Jesske, K. Drage, C. Holmberg >> Category : INFORMATIONAL >> Source : IETF - NON WORKING GROUP >> Area : N/A >> Stream : IETF >> Verifying Party : IESG >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Sep 30 07:20:48 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F4D1A8791 for ; Wed, 30 Sep 2015 07:20:46 -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 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 B5J-lS66BC8e for ; Wed, 30 Sep 2015 07:20:45 -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 127101A8767 for ; Wed, 30 Sep 2015 07:20:45 -0700 (PDT) Received: from [10.0.1.23] (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 t8UEKfD9061502 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Sep 2015 09:20:41 -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.23] From: "Ben Campbell" To: "Christer Holmberg" Date: Wed, 30 Sep 2015 09:20:42 -0500 Message-ID: <846BA154-64C3-4238-9915-DD7627BF000C@nostrum.com> In-Reply-To: <291D384C-5156-43B3-9760-0E854865FE89@nostrum.com> References: <20150914112053.D26B1180204@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37A7B4A3@ESESSMB209.ericsson.se> <13F0EA94-60E1-4735-80DA-55B9D5D64B28@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37A7C011@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37AC0CF1@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37AE5E96@ESESSMB209.ericsson.se> <291D384C-5156-43B3-9760-0E854865FE89@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 14:20:46 -0000 Oops, I spoke too soon. Cullen did object. I will comment in that thread. Ben. Christer, do you have any thoughts On 30 Sep 2015, at 9:17, Ben Campbell wrote: > No one seems to have objected, so I will approve it. > > Ben. > > On 30 Sep 2015, at 2:41, Christer Holmberg wrote: > >> PING. >> >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer >> Holmberg >> Sent: 21. syyskuuta 2015 13:26 >> To: Ben Campbell >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) >> >> Any news on this? >> >> Regards, >> >> Christer >> >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer >> Holmberg >> Sent: 14. syyskuuta 2015 23:24 >> To: Ben Campbell >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) >> >> Hi Ben, >> >> I am pretty sure generic-param was the original intention. The >> majority of all existing value follow the generic-param syntax, and I >> can't think of any reason why new values would not follow the same >> syntax. That is how it works for other header fields too. >> >> I think this is due to a mistake, where someone thought that >> extension-access-info represents the actual parameter name, and >> therefor only a value (gen-value) is needed. But, >> extension-access-info represents the whole rule (name AND value), why >> generic-param is needed :) >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> ________________________________ >> From: Ben Campbell >> Sent: ‎14/‎09/‎2015 21:31 >> To: Christer Holmberg >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) >> Hi Christer, >> >> Is it your understanding that the use of generic-param was the actual >> intention at the time 7315 was published? Or was gen-value the >> original >> intention, but we now think that it should have been generic-param? >> >> Thanks! >> >> Ben. >> >> On 14 Sep 2015, at 6:22, Christer Holmberg wrote: >> >>> FYI, >>> >>> I've now submitted the errata. >>> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>> Sent: 14. syyskuuta 2015 14:21 >>> To: r.jesske@telekom.de; >>> drage@alcatel-lucent.com; Christer >>> Holmberg; >>> iesg@ietf.org >>> Cc: Christer Holmberg; >>> rfc-editor@rfc-editor.org >>> Subject: [Technical Errata Reported] RFC7315 (4474) >>> >>> The following errata report has been submitted for RFC7315, "Private >>> Header (P-Header) Extensions to the Session Initiation Protocol >>> (SIP) >>> for the 3GPP". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=7315&eid=4474 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Christer Holmberg >>> > >>> >>> Section: 5.4 >>> >>> Original Text >>> ------------- >>> extension-access-info = gen-value >>> >>> Corrected Text >>> -------------- >>> extension-access-info = generic-param >>> >>> Notes >>> ----- >>> Most of the pre-defined access-info values are following the >>> generic-param syntax. New access-info values (extensions) should >>> also >>> be allowed to follow the generic-param syntax, in order to allow >>> both >>> for a name and value of the extension. >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. >>> When a decision is reached, the verifying party (IESG) can log in to >>> change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC7315 (draft-drage-sipping-rfc3455bis-14) >>> -------------------------------------- >>> Title : Private Header (P-Header) Extensions to the >>> Session Initiation Protocol (SIP) for the 3GPP >>> Publication Date : July 2014 >>> Author(s) : R. Jesske, K. Drage, C. Holmberg >>> Category : INFORMATIONAL >>> Source : IETF - NON WORKING GROUP >>> Area : N/A >>> Stream : IETF >>> Verifying Party : IESG >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Sep 30 07:31:08 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AEF1A8784; Wed, 30 Sep 2015 07:31:06 -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 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 56_YWPIVxlRK; Wed, 30 Sep 2015 07:31:04 -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 3AF481A8789; Wed, 30 Sep 2015 07:31:04 -0700 (PDT) Received: from [10.0.1.23] (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 t8UEUx17062426 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Sep 2015 09:30:59 -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.23] From: "Ben Campbell" To: SIPCORE , "DISPATCH list" Date: Wed, 30 Sep 2015 09:31:00 -0500 Message-ID: <4E205A3B-F608-48D3-9DA5-D2220A97D953@nostrum.com> In-Reply-To: <56031836.3080407@nostrum.com> References: <7594FB04B1934943A5C02806D1A2204B37AC0CF1@ESESSMB209.ericsson.se> <3308F2DE-08F1-46A0-BC01-2445627BAD53@iii.ca> <56031836.3080407@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: Cullen Jennings Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 14:31:06 -0000 (+sipcore, dispatch) (as individual) I just realized this discussion did not include the sipcore or dispatch lists, and probably should. Recap: Christer proposed an errata (4474) to RFC 7315. It proposes the following change: > Section 5.4 says: > > extension-access-info = gen-value > > It should say: > > extension-access-info = generic-param The generic-param construction allows the NAME = VALUE syntax as in the TS 24.229 extension Jean mentioned below. Keeping in mind the RFC in question was for 3GPP: Is anyone aware of implementations of 7315 that would be broken by this? From Jean's example, it looks like 3GPP had already assumed generic-param. Ben. On 23 Sep 2015, at 16:23, A. Jean Mahoney wrote: > FWIW - TS 24.229, which defines the values for access-info, considers > extension-access-info to be a generic-param, and not a gen-value as > specified RFC7315. 3GPP has defined one extension so far (7.2A.4): > > > daylight-saving-time = "daylight-saving-time" EQUAL quoted-string > > TS 124 229 - V12.9.0 - Digital cellular telecommunications system > (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; > IP multimedia call control protocol based on Session Initiation > Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (3GPP > TS 24.229 version 12.9.0 Release 12) The daylight-saving-time is an > instance of generic-param from the current extension-access-info > component of the P- Access-Network-Info header field defined in RFC > 7315 [52]. > > > Jean > > > > On 9/23/15 3:47 PM, Cullen Jennings wrote: >> I can see that it might have been better if it had been done this way >> Christer is proposing but I don't see how you can change it now. This >> change would break existing parsers that checked this. That does not >> seem like an errata level thing to me. >> >> >>> On Sep 21, 2015, at 10:30 AM, Ben Campbell wrote: >>> >>> sipcore and dispatch chairs: >>> >>> Do you have any concerns about accepting Christer's errata? (I note >>> RFC 7315 was an orphaned sipping draft progressed as AD sponsored.) >>> >>> Ben. >>> >>> Forwarded message: >>> >>>> From: Christer Holmberg >>>> To: Ben Campbell >>>> Cc: sipcore@ietf.org >>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) >>>> Date: Mon, 21 Sep 2015 10:26:26 +0000 >>>> >>>> Any news on this? >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of >>>> Christer Holmberg >>>> Sent: 14. syyskuuta 2015 23:24 >>>> To: Ben Campbell >>>> Cc: sipcore@ietf.org >>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) >>>> >>>> Hi Ben, >>>> >>>> I am pretty sure generic-param was the original intention. The >>>> majority of all existing value follow the generic-param syntax, and >>>> I can't think of any reason why new values would not follow the >>>> same syntax. That is how it works for other header fields too. >>>> >>>> I think this is due to a mistake, where someone thought that >>>> extension-access-info represents the actual parameter name, and >>>> therefor only a value (gen-value) is needed. But, >>>> extension-access-info represents the whole rule (name AND value), >>>> why generic-param is needed :) >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> Sent from my Windows Phone >>>> ________________________________ >>>> From: Ben Campbell >>>> Sent: ‎14/‎09/‎2015 21:31 >>>> To: Christer Holmberg >>>> Cc: sipcore@ietf.org >>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) >>>> Hi Christer, >>>> >>>> Is it your understanding that the use of generic-param was the >>>> actual >>>> intention at the time 7315 was published? Or was gen-value the >>>> original >>>> intention, but we now think that it should have been generic-param? >>>> >>>> Thanks! >>>> >>>> Ben. >>>> >>>> On 14 Sep 2015, at 6:22, Christer Holmberg wrote: >>>> >>>>> FYI, >>>>> >>>>> I've now submitted the errata. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> -----Original Message----- >>>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>>> Sent: 14. syyskuuta 2015 14:21 >>>>> To: r.jesske@telekom.de; >>>>> drage@alcatel-lucent.com; >>>>> Christer Holmberg; >>>>> iesg@ietf.org >>>>> Cc: Christer Holmberg; >>>>> rfc-editor@rfc-editor.org >>>>> Subject: [Technical Errata Reported] RFC7315 (4474) >>>>> >>>>> The following errata report has been submitted for RFC7315, >>>>> "Private >>>>> Header (P-Header) Extensions to the Session Initiation Protocol >>>>> (SIP) >>>>> for the 3GPP". >>>>> >>>>> -------------------------------------- >>>>> You may review the report below and at: >>>>> http://www.rfc-editor.org/errata_search.php?rfc=7315&eid=4474 >>>>> >>>>> -------------------------------------- >>>>> Type: Technical >>>>> Reported by: Christer Holmberg >>>>> > >>>>> >>>>> Section: 5.4 >>>>> >>>>> Original Text >>>>> ------------- >>>>> extension-access-info = gen-value >>>>> >>>>> Corrected Text >>>>> -------------- >>>>> extension-access-info = generic-param >>>>> >>>>> Notes >>>>> ----- >>>>> Most of the pre-defined access-info values are following the >>>>> generic-param syntax. New access-info values (extensions) should >>>>> also >>>>> be allowed to follow the generic-param syntax, in order to allow >>>>> both >>>>> for a name and value of the extension. >>>>> >>>>> Instructions: >>>>> ------------- >>>>> This erratum is currently posted as "Reported". If necessary, >>>>> please >>>>> use "Reply All" to discuss whether it should be verified or >>>>> rejected. >>>>> When a decision is reached, the verifying party (IESG) can log in >>>>> to >>>>> change the status and edit the report, if necessary. >>>>> >>>>> -------------------------------------- >>>>> RFC7315 (draft-drage-sipping-rfc3455bis-14) >>>>> -------------------------------------- >>>>> Title : Private Header (P-Header) Extensions to the >>>>> Session Initiation Protocol (SIP) for the 3GPP >>>>> Publication Date : July 2014 >>>>> Author(s) : R. Jesske, K. Drage, C. Holmberg >>>>> Category : INFORMATIONAL >>>>> Source : IETF - NON WORKING GROUP >>>>> Area : N/A >>>>> Stream : IETF >>>>> Verifying Party : IESG >>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Sep 30 08:13:09 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5771B5E82; Wed, 30 Sep 2015 08:13:01 -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, 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 K2bxHEoGT00b; Wed, 30 Sep 2015 08:12:58 -0700 (PDT) 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 0CA921B5E72; Wed, 30 Sep 2015 08:12:56 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-ac-560bfbf67f23 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id DA.65.05274.6FBFB065; Wed, 30 Sep 2015 17:12:55 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.171]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Wed, 30 Sep 2015 17:12:54 +0200 From: Christer Holmberg To: Ben Campbell , SIPCORE , DISPATCH list Thread-Topic: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 (4474) Thread-Index: AQHQ7t97nIYDUJCaWUq0zXVQ2fcq45474U6QgABWdwCAAEDu14AKWWCwgA5pe2uAAAkewA== Date: Wed, 30 Sep 2015 15:12:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37AE6750@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37AC0CF1@ESESSMB209.ericsson.se> <3308F2DE-08F1-46A0-BC01-2445627BAD53@iii.ca> <56031836.3080407@nostrum.com> <4E205A3B-F608-48D3-9DA5-D2220A97D953@nostrum.com> In-Reply-To: <4E205A3B-F608-48D3-9DA5-D2220A97D953@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvje7339xhBv+/clnM7zzNbrF00gJW iw/rfzBafP2xic2BxWPJkp9MHpfPf2T0mLXzCUsAcxSXTUpqTmZZapG+XQJXxouWP0wFz0Ir Vly5xN7AeCa4i5GTQ0LARKLjxzQmCFtM4sK99WxdjFwcQgJHGSUW7+xignCWMEpsutzM2MXI wcEmYCHR/U8bpEFEIFliZvdUZhCbWUBZorv1DCtIibCAj8THfSIQJb4Sx5o2MYOERQTCJF6f dwUJswioSmy49oMNxOYFKnn2op0dYlMbk8SnH/9YQBKcAvYSH+7cAytiBLrt+6k1TBCrxCVu PZkPdbOAxJI955khbFGJl4//sULYShKNS56AncMsoCmxfpc+RKuixJTuh+wQewUlTs58wjKB UWwWkqmzEDpmIemYhaRjASPLKkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzAuDq45bfqDsbL bxwPMQpwMCrx8Co4cYcJsSaWFVfmHmKU5mBREudtZnoQKiSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoFR/MhvySC5UPWf7/86nkmq8p0ycUP2ii3zN2WePLp0Ue/rL5pTUxNfav87N0fJcI6a W0KxfPgZtoqCWV2L3KY/Kp3+QumMwJY4hUIOqx9Pvqk9maWuxLqgS3HH8apbyfe+GPGkLk1S +674wOPrv3Vxbw9a+qUWaE3blCsxN23hDcm5xR5C2brvlFiKMxINtZiLihMB7Zat/owCAAA= Archived-At: Cc: Cullen Jennings Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 (4474) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2015 15:13:01 -0000 SGksDQoNCj4oK3NpcGNvcmUsIGRpc3BhdGNoKQ0KPihhcyBpbmRpdmlkdWFsKQ0KPg0KPkkganVz dCByZWFsaXplZCB0aGlzIGRpc2N1c3Npb24gZGlkIG5vdCBpbmNsdWRlIHRoZSBzaXBjb3JlIG9y IGRpc3BhdGNoIGxpc3RzLCBhbmQgcHJvYmFibHkgc2hvdWxkLg0KPg0KPlJlY2FwOiBDaHJpc3Rl ciBwcm9wb3NlZCBhbiBlcnJhdGEgKDQ0NzQpIHRvIFJGQyA3MzE1LiBJdCBwcm9wb3NlcyB0aGUg Zm9sbG93aW5nIGNoYW5nZToNCj4NCj4+IFNlY3Rpb24gNS40IHNheXM6DQo+Pg0KPj4gZXh0ZW5z aW9uLWFjY2Vzcy1pbmZvICA9IGdlbi12YWx1ZQ0KPj4NCj4+IEl0IHNob3VsZCBzYXk6DQo+Pg0K Pj4gZXh0ZW5zaW9uLWFjY2Vzcy1pbmZvICA9IGdlbmVyaWMtcGFyYW0NCj4NCj4gVGhlIGdlbmVy aWMtcGFyYW0gY29uc3RydWN0aW9uIGFsbG93cyB0aGUgTkFNRSA9IFZBTFVFIHN5bnRheCBhcyBp biB0aGUgVFMgMjQuMjI5IGV4dGVuc2lvbiBKZWFuIG1lbnRpb25lZCBiZWxvdy4NCj4NCj4gS2Vl cGluZyBpbiBtaW5kIHRoZSBSRkMgaW4gcXVlc3Rpb24gd2FzIGZvciAzR1BQOiBJcyBhbnlvbmUg YXdhcmUgb2YgaW1wbGVtZW50YXRpb25zIG9mIDczMTUgdGhhdCB3b3VsZCBiZSBicm9rZW4NCj4g YnkgdGhpcz8gRnJvbSBKZWFuJ3MgZXhhbXBsZSwgaXQgbG9va3MgbGlrZSAzR1BQIGhhZCBhbHJl YWR5IGFzc3VtZWQgZ2VuZXJpYy1wYXJhbS4NCg0KQ29ycmVjdC4NCg0KQWxzbywgY29tcGFyaW5n IFJGQyAzNDU1IGFuZCBSRkMgNzMxNSwgKmFsbCBidXQgb25lKiBvZiB0aGUgbmV3IGFjY2Vzcy1p bmZvIHBhcmFtZXRlciB2YWx1ZXMgdGhhdCB3ZXJlIGFkZGVkIGluIFJGQyA3MzE1IGZvbGxvdyB0 aGUgZ2VuZXJpYy1wYXJhbSBzeW50YXguICBTbywgaXQgc2VlbXMgbGlrZSB3ZSBpbiBJRVRGIGFs c28gYXNzdW1lZCBnZW5lcmljLXBhcmFtIHdoZW4gd2UgZGlkIFJGQyA3MzE1IChhbmQvb3Igd2Ug d2VyZSBub3QgY29uY2VybmVkIGFib3V0IHBhcnNlciBpc3N1ZXMpLCBidXQgbm9ib2R5IG5vdGlj ZWQgdGhlIEFCTkYgaXNzdWUuDQoNCkFuZCwgYXMgSSBzYWlkIGVhcmxpZXIsIEkgYW0gcHJldHR5 IHN1cmUgdGhpcyBoZWFkZXIgaXMgbW9zdGx5IChvbmx5PykgdXNlZCBpbiAzR1BQIGVudmlyb25t ZW50cywgYW5kIG5vYm9keSBpbiAzR1BQIG9iamVjdGVkIHRvIHRoZSBjaGFuZ2UgSSBhbSBub3cg c3VnZ2VzdGluZy4gSXQgd2FzIGRpc2N1c3NlZCBpbiAzR1BQLCBhbmQgdGhlIG91dGNvbWUgd2Fz IHRvIGZpbGUgdGhlIGVycmF0YS4NCg0KRmluYWxseSwgYXMgSmVhbiBpbmRpY2F0ZWQsIDNHUFAg aGFzIGRlZmluZWQgYSBuZXcgdmFsdWUsIGRheWxpZ2h0LXNhdmluZy10aW1lLCB3aGljaCBhbHNv IHVzZXMgdGhlIGdlbmVyaWMtcGFyYW0gc3ludGF4Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K DQoNCk9uIDIzIFNlcCAyMDE1LCBhdCAxNjoyMywgQS4gSmVhbiBNYWhvbmV5IHdyb3RlOg0KDQo+ IEZXSVcgLSBUUyAyNC4yMjksIHdoaWNoIGRlZmluZXMgdGhlIHZhbHVlcyBmb3IgYWNjZXNzLWlu Zm8sIGNvbnNpZGVycyANCj4gZXh0ZW5zaW9uLWFjY2Vzcy1pbmZvIHRvIGJlIGEgZ2VuZXJpYy1w YXJhbSwgYW5kIG5vdCBhIGdlbi12YWx1ZSBhcyANCj4gc3BlY2lmaWVkIFJGQzczMTUuIDNHUFAg aGFzIGRlZmluZWQgb25lIGV4dGVuc2lvbiBzbyBmYXIgKDcuMkEuNCk6DQo+DQo+DQo+IGRheWxp Z2h0LXNhdmluZy10aW1lID0gImRheWxpZ2h0LXNhdmluZy10aW1lIiBFUVVBTCBxdW90ZWQtc3Ry aW5nDQo+DQo+IFRTIDEyNCAyMjkgLSBWMTIuOS4wIC0gRGlnaXRhbCBjZWxsdWxhciB0ZWxlY29t bXVuaWNhdGlvbnMgc3lzdGVtIA0KPiAoUGhhc2UgMispOyBVbml2ZXJzYWwgTW9iaWxlIFRlbGVj b21tdW5pY2F0aW9ucyBTeXN0ZW0gKFVNVFMpOyBMVEU7IElQIA0KPiBtdWx0aW1lZGlhIGNhbGwg Y29udHJvbCBwcm90b2NvbCBiYXNlZCBvbiBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgDQo+ IChTSVApIGFuZCBTZXNzaW9uIERlc2NyaXB0aW9uIFByb3RvY29sIChTRFApOyBTdGFnZSAzICgz R1BQIFRTIDI0LjIyOSANCj4gdmVyc2lvbiAxMi45LjAgUmVsZWFzZSAxMikgVGhlIGRheWxpZ2h0 LXNhdmluZy10aW1lIGlzIGFuIGluc3RhbmNlIG9mIA0KPiBnZW5lcmljLXBhcmFtIGZyb20gdGhl IGN1cnJlbnQgZXh0ZW5zaW9uLWFjY2Vzcy1pbmZvIGNvbXBvbmVudCBvZiB0aGUgDQo+IFAtIEFj Y2Vzcy1OZXR3b3JrLUluZm8gaGVhZGVyIGZpZWxkIGRlZmluZWQgaW4gUkZDDQo+IDczMTUgWzUy XS4NCj4NCj4NCj4gSmVhbg0KPg0KPg0KPg0KPiBPbiA5LzIzLzE1IDM6NDcgUE0sIEN1bGxlbiBK ZW5uaW5ncyB3cm90ZToNCj4+IEkgY2FuIHNlZSB0aGF0IGl0IG1pZ2h0IGhhdmUgYmVlbiBiZXR0 ZXIgaWYgaXQgaGFkIGJlZW4gZG9uZSB0aGlzIHdheSANCj4+IENocmlzdGVyIGlzIHByb3Bvc2lu ZyBidXQgSSBkb24ndCBzZWUgaG93IHlvdSBjYW4gY2hhbmdlIGl0IG5vdy4gVGhpcyANCj4+IGNo YW5nZSB3b3VsZCBicmVhayBleGlzdGluZyBwYXJzZXJzIHRoYXQgY2hlY2tlZCB0aGlzLiBUaGF0 IGRvZXMgbm90IA0KPj4gc2VlbSBsaWtlIGFuIGVycmF0YSBsZXZlbCB0aGluZyB0byBtZS4NCj4+ DQo+Pg0KPj4+IE9uIFNlcCAyMSwgMjAxNSwgYXQgMTA6MzAgQU0sIEJlbiBDYW1wYmVsbCA8YmVu QG5vc3RydW0uY29tPiB3cm90ZToNCj4+Pg0KPj4+IHNpcGNvcmUgYW5kIGRpc3BhdGNoIGNoYWly czoNCj4+Pg0KPj4+IERvIHlvdSBoYXZlIGFueSBjb25jZXJucyBhYm91dCBhY2NlcHRpbmcgQ2hy aXN0ZXIncyBlcnJhdGE/IChJIG5vdGUgDQo+Pj4gUkZDIDczMTUgd2FzIGFuIG9ycGhhbmVkIHNp cHBpbmcgZHJhZnQgcHJvZ3Jlc3NlZCBhcyBBRCBzcG9uc29yZWQuKQ0KPj4+DQo+Pj4gQmVuLg0K Pj4+DQo+Pj4gRm9yd2FyZGVkIG1lc3NhZ2U6DQo+Pj4NCj4+Pj4gRnJvbTogQ2hyaXN0ZXIgSG9s bWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4+Pj4gVG86IEJlbiBDYW1w YmVsbCA8YmVuQG5vc3RydW0uY29tPg0KPj4+PiBDYzogc2lwY29yZUBpZXRmLm9yZyA8c2lwY29y ZUBpZXRmLm9yZz4NCj4+Pj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBbVGVjaG5pY2FsIEVycmF0 YSBSZXBvcnRlZF0gUkZDNzMxNSAoNDQ3NCkNCj4+Pj4gRGF0ZTogTW9uLCAyMSBTZXAgMjAxNSAx MDoyNjoyNiArMDAwMA0KPj4+Pg0KPj4+PiBBbnkgbmV3cyBvbiB0aGlzPw0KPj4+Pg0KPj4+PiBS ZWdhcmRzLA0KPj4+Pg0KPj4+PiBDaHJpc3Rlcg0KPj4+Pg0KPj4+PiBGcm9tOiBzaXBjb3JlIFtt YWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQo+Pj4+IENocmlz dGVyIEhvbG1iZXJnDQo+Pj4+IFNlbnQ6IDE0LiBzeXlza3V1dGEgMjAxNSAyMzoyNA0KPj4+PiBU bzogQmVuIENhbXBiZWxsDQo+Pj4+IENjOiBzaXBjb3JlQGlldGYub3JnDQo+Pj4+IFN1YmplY3Q6 IFJlOiBbc2lwY29yZV0gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzczMTUgKDQ0NzQp DQo+Pj4+DQo+Pj4+IEhpIEJlbiwNCj4+Pj4NCj4+Pj4gSSBhbSBwcmV0dHkgc3VyZSBnZW5lcmlj LXBhcmFtIHdhcyB0aGUgb3JpZ2luYWwgaW50ZW50aW9uLiBUaGUgDQo+Pj4+IG1ham9yaXR5IG9m IGFsbCBleGlzdGluZyB2YWx1ZSBmb2xsb3cgdGhlIGdlbmVyaWMtcGFyYW0gc3ludGF4LCBhbmQg DQo+Pj4+IEkgY2FuJ3QgdGhpbmsgb2YgYW55IHJlYXNvbiB3aHkgbmV3IHZhbHVlcyB3b3VsZCBu b3QgZm9sbG93IHRoZSANCj4+Pj4gc2FtZSBzeW50YXguIFRoYXQgaXMgaG93IGl0IHdvcmtzIGZv ciBvdGhlciBoZWFkZXIgZmllbGRzIHRvby4NCj4+Pj4NCj4+Pj4gSSB0aGluayB0aGlzIGlzIGR1 ZSB0byBhIG1pc3Rha2UsIHdoZXJlIHNvbWVvbmUgdGhvdWdodCB0aGF0IA0KPj4+PiBleHRlbnNp b24tYWNjZXNzLWluZm8gIHJlcHJlc2VudHMgdGhlIGFjdHVhbCBwYXJhbWV0ZXIgbmFtZSwgYW5k IA0KPj4+PiB0aGVyZWZvciBvbmx5IGEgdmFsdWUgKGdlbi12YWx1ZSkgaXMgbmVlZGVkLiBCdXQs IA0KPj4+PiBleHRlbnNpb24tYWNjZXNzLWluZm8gcmVwcmVzZW50cyB0aGUgd2hvbGUgcnVsZSAo bmFtZSBBTkQgdmFsdWUpLCANCj4+Pj4gd2h5IGdlbmVyaWMtcGFyYW0gaXMgbmVlZGVkIDopDQo+ Pj4+DQo+Pj4+IFJlZ2FyZHMsDQo+Pj4+DQo+Pj4+IENocmlzdGVyDQo+Pj4+DQo+Pj4+IFNlbnQg ZnJvbSBteSBXaW5kb3dzIFBob25lDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+IEZyb206IEJlbiBDYW1wYmVsbDxtYWlsdG86YmVuQG5vc3RydW0uY29tPg0KPj4+ PiBTZW50OiDigI4xNC/igI4wOS/igI4yMDE1IDIxOjMxDQo+Pj4+IFRvOiBDaHJpc3RlciBIb2xt YmVyZzxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4+PiBDYzogc2lw Y29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NCj4+Pj4gU3ViamVjdDogUmU6 IFtzaXBjb3JlXSBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDNzMxNSAoNDQ3NCkgDQo+ Pj4+IEhpIENocmlzdGVyLA0KPj4+Pg0KPj4+PiBJcyBpdCB5b3VyIHVuZGVyc3RhbmRpbmcgdGhh dCB0aGUgdXNlIG9mIGdlbmVyaWMtcGFyYW0gd2FzIHRoZSANCj4+Pj4gYWN0dWFsIGludGVudGlv biBhdCB0aGUgdGltZSA3MzE1IHdhcyBwdWJsaXNoZWQ/IE9yIHdhcyBnZW4tdmFsdWUgDQo+Pj4+ IHRoZSBvcmlnaW5hbCBpbnRlbnRpb24sIGJ1dCB3ZSBub3cgdGhpbmsgdGhhdCBpdCBzaG91bGQg aGF2ZSBiZWVuIA0KPj4+PiBnZW5lcmljLXBhcmFtPw0KPj4+Pg0KPj4+PiBUaGFua3MhDQo+Pj4+ DQo+Pj4+IEJlbi4NCj4+Pj4NCj4+Pj4gT24gMTQgU2VwIDIwMTUsIGF0IDY6MjIsIENocmlzdGVy IEhvbG1iZXJnIHdyb3RlOg0KPj4+Pg0KPj4+Pj4gRllJLA0KPj4+Pj4NCj4+Pj4+IEkndmUgbm93 IHN1Ym1pdHRlZCB0aGUgZXJyYXRhLg0KPj4+Pj4NCj4+Pj4+IFJlZ2FyZHMsDQo+Pj4+Pg0KPj4+ Pj4gQ2hyaXN0ZXINCj4+Pj4+DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ Pj4gRnJvbTogUkZDIEVycmF0YSBTeXN0ZW0gW21haWx0bzpyZmMtZWRpdG9yQHJmYy1lZGl0b3Iu b3JnXQ0KPj4+Pj4gU2VudDogMTQuIHN5eXNrdXV0YSAyMDE1IDE0OjIxDQo+Pj4+PiBUbzogci5q ZXNza2VAdGVsZWtvbS5kZTxtYWlsdG86ci5qZXNza2VAdGVsZWtvbS5kZT47DQo+Pj4+PiBkcmFn ZUBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbT47DQo+ Pj4+PiBDaHJpc3RlciBIb2xtYmVyZzsNCj4+Pj4+IGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dA aWV0Zi5vcmc+DQo+Pj4+PiBDYzogQ2hyaXN0ZXIgSG9sbWJlcmc7DQo+Pj4+PiByZmMtZWRpdG9y QHJmYy1lZGl0b3Iub3JnPG1haWx0bzpyZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPg0KPj4+Pj4g U3ViamVjdDogW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzczMTUgKDQ0NzQpDQo+Pj4+ Pg0KPj4+Pj4gVGhlIGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBm b3IgUkZDNzMxNSwgDQo+Pj4+PiAiUHJpdmF0ZSBIZWFkZXIgKFAtSGVhZGVyKSBFeHRlbnNpb25z IHRvIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gDQo+Pj4+PiBQcm90b2NvbA0KPj4+Pj4gKFNJUCkN Cj4+Pj4+IGZvciB0aGUgM0dQUCIuDQo+Pj4+Pg0KPj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+IFlvdSBtYXkgcmV2aWV3IHRoZSByZXBvcnQgYmVsb3cg YW5kIGF0Og0KPj4+Pj4gaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGFfc2VhcmNoLnBo cD9yZmM9NzMxNSZlaWQ9NDQ3NA0KPj4+Pj4NCj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+Pj4+PiBUeXBlOiBUZWNobmljYWwNCj4+Pj4+IFJlcG9ydGVkIGJ5 OiBDaHJpc3RlciBIb2xtYmVyZw0KPj4+Pj4gPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uDQo+Pj4+PiBjb20+Pg0KPj4+Pj4N Cj4+Pj4+IFNlY3Rpb246IDUuNA0KPj4+Pj4NCj4+Pj4+IE9yaWdpbmFsIFRleHQNCj4+Pj4+IC0t LS0tLS0tLS0tLS0NCj4+Pj4+IGV4dGVuc2lvbi1hY2Nlc3MtaW5mbyAgPSBnZW4tdmFsdWUNCj4+ Pj4+DQo+Pj4+PiBDb3JyZWN0ZWQgVGV4dA0KPj4+Pj4gLS0tLS0tLS0tLS0tLS0NCj4+Pj4+IGV4 dGVuc2lvbi1hY2Nlc3MtaW5mbyAgPSBnZW5lcmljLXBhcmFtDQo+Pj4+Pg0KPj4+Pj4gTm90ZXMN Cj4+Pj4+IC0tLS0tDQo+Pj4+PiBNb3N0IG9mIHRoZSBwcmUtZGVmaW5lZCBhY2Nlc3MtaW5mbyB2 YWx1ZXMgYXJlIGZvbGxvd2luZyB0aGUgDQo+Pj4+PiBnZW5lcmljLXBhcmFtIHN5bnRheC4gTmV3 IGFjY2Vzcy1pbmZvIHZhbHVlcyAoZXh0ZW5zaW9ucykgc2hvdWxkIA0KPj4+Pj4gYWxzbyBiZSBh bGxvd2VkIHRvIGZvbGxvdyB0aGUgZ2VuZXJpYy1wYXJhbSBzeW50YXgsIGluIG9yZGVyIHRvIA0K Pj4+Pj4gYWxsb3cgYm90aCBmb3IgYSBuYW1lIGFuZCB2YWx1ZSBvZiB0aGUgZXh0ZW5zaW9uLg0K Pj4+Pj4NCj4+Pj4+IEluc3RydWN0aW9uczoNCj4+Pj4+IC0tLS0tLS0tLS0tLS0NCj4+Pj4+IFRo aXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICJSZXBvcnRlZCIuIElmIG5lY2Vzc2Fy eSwgDQo+Pj4+PiBwbGVhc2UgdXNlICJSZXBseSBBbGwiIHRvIGRpc2N1c3Mgd2hldGhlciBpdCBz aG91bGQgYmUgdmVyaWZpZWQgb3IgDQo+Pj4+PiByZWplY3RlZC4NCj4+Pj4+IFdoZW4gYSBkZWNp c2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5IChJRVNHKSBjYW4gbG9nIGluIA0K Pj4+Pj4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNz YXJ5Lg0KPj4+Pj4NCj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+Pj4+PiBSRkM3MzE1IChkcmFmdC1kcmFnZS1zaXBwaW5nLXJmYzM0NTViaXMtMTQpDQo+Pj4+ PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4gVGl0bGUgICAg ICAgICAgICAgICA6IFByaXZhdGUgSGVhZGVyIChQLUhlYWRlcikgRXh0ZW5zaW9ucyB0byB0aGUN Cj4+Pj4+IFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCAoU0lQKSBmb3IgdGhlIDNHUFANCj4+ Pj4+IFB1YmxpY2F0aW9uIERhdGUgICAgOiBKdWx5IDIwMTQNCj4+Pj4+IEF1dGhvcihzKSAgICAg ICAgICAgOiBSLiBKZXNza2UsIEsuIERyYWdlLCBDLiBIb2xtYmVyZw0KPj4+Pj4gQ2F0ZWdvcnkg ICAgICAgICAgICA6IElORk9STUFUSU9OQUwNCj4+Pj4+IFNvdXJjZSAgICAgICAgICAgICAgOiBJ RVRGIC0gTk9OIFdPUktJTkcgR1JPVVANCj4+Pj4+IEFyZWEgICAgICAgICAgICAgICAgOiBOL0EN Cj4+Pj4+IFN0cmVhbSAgICAgICAgICAgICAgOiBJRVRGDQo+Pj4+PiBWZXJpZnlpbmcgUGFydHkg ICAgIDogSUVTRw0KPj4+Pj4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPj4+Pj4gc2lwY29y ZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NCj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0K Pj4+PiBzaXBjb3JlQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lwY29yZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQpkaXNwYXRjaEBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0K