From nobody Tue Oct 6 04:32: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 C7DEE1B3F9C for ; Tue, 6 Oct 2015 04:32:46 -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 cTtteVYnBWJr for ; Tue, 6 Oct 2015 04:32:45 -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 B89CD1B3F99 for ; Tue, 6 Oct 2015 04:32:44 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-54-5613b15ab31f Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id AB.3E.29154.A51B3165; Tue, 6 Oct 2015 13:32:43 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.226]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Tue, 6 Oct 2015 13:32:41 +0200 From: Christer Holmberg To: SIPCORE Thread-Topic: 491 for non-INVITE/UPDATE/PRACK Thread-Index: AdEAKqzeRZQgUVr1TzyQ7YYv/MsLDw== Date: Tue, 6 Oct 2015 11:32:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37B1E9F7@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37B1E9F7ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyM+JvjW70RuEwgw+tTBZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRusHpYKHMhU7mtrZGxhXSXYxcnJICJhIbPq+lAXCFpO4cG89 WxcjF4eQwFFGiYtH7zFBOIsZJfrXLQeq4uBgE7CQ6P6nDWKKCMhJzL4RA9IrLKAhMan9Itgc EQFdicPbPrNB2HoSj8/NYQKxWQRUJJpeXAOL8wr4Snw61soIYjMC7f1+ag1YDbOAuMStJ/OZ IO4RkFiy5zwzhC0q8fLxP1YIW0nix4ZLLBD1+RKLFn6FmikocXLmE5YJjEKzkIyahaRsFpIy iLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvopRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMj MB4ObvlttYPx4HPHQ4wCHIxKPLwPPgmFCbEmlhVX5h5ilOZgURLnbWZ6ECokkJ5YkpqdmlqQ WhRfVJqTWnyIkYmDU6qB0ayImynFvmNGsHzU3Ksqq4qm9oTu/XVLULh5dh3znJdhxfdqLjfy /rSdGd76yazX4Ki2RrtrUpDwXIPIcH6ph7t0rvToKhyJPqF8R2qW27Yvy48dz1i17dS056v3 XJumsibLKjL/2/NXh+pXGW7RSOiffEe9ouGbDbfb7ndXBf24K0QbktSYlFiKMxINtZiLihMB rG2zgmgCAAA= Archived-At: Subject: [sipcore] 491 for non-INVITE/UPDATE/PRACK 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: Tue, 06 Oct 2015 11:32:47 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37B1E9F7ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The 491 response code was introduced in RFC 3261 in order to deal with re-I= NVITE race conditions. RFC 3311 extended the usage to UPDATEs and PRACKs ca= rrying SDP offers. My question is: is it allowed to use 491 for other methods and cases, where= the application determines that a request cannot be accepted due to anothe= r outstanding transaction on the same dialog? RFC 3261 does not explicitly = forbid it, as far as I know. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37B1E9F7ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The 491 response code was intro= duced in RFC 3261 in order to deal with re-INVITE race conditions. RFC 3311= extended the usage to UPDATEs and PRACKs carrying SDP offers.

 

My question is: is it allowed t= o use 491 for other methods and cases, where the application determines tha= t a request cannot be accepted due to another outstanding transaction on th= e same dialog? RFC 3261 does not explicitly forbid it, as far as I know.

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B37B1E9F7ESESSMB209erics_-- From nobody Tue Oct 6 07:31:56 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 5B0591B34D7 for ; Tue, 6 Oct 2015 07:31:54 -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 zvUesPa8dCvj for ; Tue, 6 Oct 2015 07:31:53 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8767C1B2B3E for ; Tue, 6 Oct 2015 07:31:53 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-09v.sys.comcast.net with comcast id RqVq1r0062TL4Rh01qXsqG; Tue, 06 Oct 2015 14:31:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-17v.sys.comcast.net with comcast id RqXs1r00D3Ge9ey01qXsRz; Tue, 06 Oct 2015 14:31:52 +0000 To: sipcore@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37B1E9F7@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <5613DB57.3060005@alum.mit.edu> Date: Tue, 6 Oct 2015 10:31:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B1E9F7@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=1444141912; bh=49SVKsD8kWa0Yno+07Hi6zod3hMqGkHkb3myZKa+d8Y=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=KATxUCkFbOYQjjQoe4YzkuafIIuIBC9iGJQqCV55v1/tK62lGIzTHF+UVNUqgjyRM 4Dx+4uOI8DVcT6/JOgrdj9ruYsBgA8jRaw1Km7FttBTagLauEPVBM07SjRvVruZXIp HAElDxKHBLfHgbkWVgYrAQTAbn5/JiJ0IvSYuH4wqOaH3KdQObhA9ZV67pZp2wO30e HGVoGHxBFmj+pgfPxJX0UyKH6J6da0rcSOeD0wjku1MnN1ZDZcY8w8D5rgX6UX+r4p tDyB+AcVsJoFbdloSSNUlcuhldMUrCmFKT+J1Yo7YEnttCxo6jBDdevyNGF2Z7b5wt XnTTWZY1oWN/g== Archived-At: Subject: Re: [sipcore] 491 for non-INVITE/UPDATE/PRACK 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: Tue, 06 Oct 2015 14:31:54 -0000 On 10/6/15 7:32 AM, Christer Holmberg wrote: > Hi, > > The 491 response code was introduced in RFC 3261 in order to deal with > re-INVITE race conditions. RFC 3311 extended the usage to UPDATEs and > PRACKs carrying SDP offers. > > My question is: is it allowed to use 491 for other methods and cases, > where the application determines that a request cannot be accepted due > to another outstanding transaction on the same dialog? RFC 3261 does not > explicitly forbid it, as far as I know. Can you be more specific about the case? I am inclined to say Yes. But I think this probably should be handled on a case by case basis, to ensure that some other code wouldn't make more sense, or that a new code is really needed. Thanks, Paul From nobody Tue Oct 6 13:02: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 28C051B327F for ; Tue, 6 Oct 2015 13:02:12 -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 wRSJmP7uRqa7 for ; Tue, 6 Oct 2015 13:02:10 -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 362A51B327D for ; Tue, 6 Oct 2015 13:02:10 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-5f-561428bf8d74 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B9.E0.29154.FB824165; Tue, 6 Oct 2015 22:02:08 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.226]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Tue, 6 Oct 2015 22:02:07 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] 491 for non-INVITE/UPDATE/PRACK Thread-Index: AdEAKqzeRZQgUVr1TzyQ7YYv/MsLDwACEzyAAA6wa0A= Date: Tue, 6 Oct 2015 20:02:06 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37B24FF4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37B1E9F7@ESESSMB209.ericsson.se> <5613DB57.3060005@alum.mit.edu> In-Reply-To: <5613DB57.3060005@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+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje4BDZEwgwX/GC1WbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjxZMutoL1fBXbn99gamDczt3FyMkhIWAi 8fTpdEYIW0ziwr31bF2MXBxCAkcZJfZ8ec0I4SxmlFj65gyQw8HBJmAh0f1PG6RBRCBQ4uqS CcwgtrCAmcTmvacYIeLmEqsXP2SDsK0kLm6aBtbKIqAiceCMM0iYV8BX4vi9JrBWIYF8ibdP 2lhAbE4BHYnFq4+wg9iMQPd8P7WGCcRmFhCXuPVkPhPEnQISS/acZ4awRSVePv7HCmErSSy6 /RmqXkdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYRYtTi4tz 042M9FKLMpOLi/Pz9PJSSzYxAqPk4JbfVjsYDz53PMQowMGoxMP74JNQmBBrYllxZe4hRmkO FiVx3mamB6FCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGHP/Tj2f8FXR5/x5wedbvC9wVe28 u33ekyqHVM+ZS6Zwdpk57Xor0Cs8MaisqkV54Q7LD3MCdbybsy12B60N95iiVbBX9MTvNbvF 72RWT02U+yR8siXoXFHFzuMH16e+qlZiPHHloeWMp7cC93CLm79fuvf4hOItXJmc5gz3xPd1 fThqyxbzTUKJpTgj0VCLuag4EQCSWUX5cwIAAA== Archived-At: Subject: Re: [sipcore] 491 for non-INVITE/UPDATE/PRACK 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: Tue, 06 Oct 2015 20:02:12 -0000 Hi, >> The 491 response code was introduced in RFC 3261 in order to deal with=20 >> re-INVITE race conditions. RFC 3311 extended the usage to UPDATEs and=20 >> PRACKs carrying SDP offers. >> >> My question is: is it allowed to use 491 for other methods and cases,=20 >> where the application determines that a request cannot be accepted due=20 >> to another outstanding transaction on the same dialog? RFC 3261 does=20 >> not explicitly forbid it, as far as I know. > > Can you be more specific about the case? > > I am inclined to say Yes. But I think this probably should be handled on = a case by case basis, to ensure that some other code wouldn't make more sen= se, or that a new code is really needed. The case is the following (high-level, as I am not aware of the details): 1. An application server sends a re-INVITE, with an updated offer, to a UA 2. When the UA receives the re-INVITE, it sends a SUBSCRIBE for an event pa= ckage (conference, afaik) to the application server. 3. The application server receives the SUBSCRIBE before it receives the res= ponse to the re-INVITE, so it rejects the SUBSCRIBE with 491. It wants to g= et the response to the re-INVITE before it accepts the SUBSCRIBE (exactly w= hy I don't know). The UA seems to be 3265 compliant, as it sends the SUBSCRIBE within the inv= ite dialog. However, that problem would be the same even if the SUBSCRIBE w= as sent on a different dialog. I guess the response code may be different, = because the 3261 text about 491 does talk about pending transactions *withi= n the same dialog*. Now, IF we would allow general usage of 491, then it would be perhaps be go= od to also indicate exactly *which* pending transaction triggered the 491. = Perhaps the transaction-id could be used for this. Regards, Christer =20 From nobody Tue Oct 6 13:39:38 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 BF2501B32FF for ; Tue, 6 Oct 2015 13:39:37 -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 1qLdaxTqk2-i for ; Tue, 6 Oct 2015 13:39:36 -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 80B801B32FE for ; Tue, 6 Oct 2015 13:39:36 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t96KdSZD006193 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 6 Oct 2015 15:39:30 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local To: Christer Holmberg , Paul Kyzivat , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B37B1E9F7@ESESSMB209.ericsson.se> <5613DB57.3060005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37B24FF4@ESESSMB209.ericsson.se> From: Robert Sparks Message-ID: <5614317C.8030006@nostrum.com> Date: Tue, 6 Oct 2015 15:39:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B24FF4@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] 491 for non-INVITE/UPDATE/PRACK 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: Tue, 06 Oct 2015 20:39:37 -0000 On 10/6/15 3:02 PM, Christer Holmberg wrote: > 3. The application server receives the SUBSCRIBE before it receives the response to the re-INVITE, so it rejects the SUBSCRIBE with 491. The semantics here are wrong. 491 in that case does not make sense. This isn't "you have glare, back off and try again", which is where 491 is used so far. It's "I don't have the application state you are looking for (yet). Please try again later" (or at least, that's what I can infer from your description so far)." RjS From nobody Tue Oct 6 13:50:46 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 233DD1B3330 for ; Tue, 6 Oct 2015 13:50:45 -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 K2hIJazUeig0 for ; Tue, 6 Oct 2015 13:50:43 -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 167831B3324 for ; Tue, 6 Oct 2015 13:50:42 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-0b-561434211216 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 78.44.29154.12434165; Tue, 6 Oct 2015 22:50:41 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.226]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0248.002; Tue, 6 Oct 2015 22:50:40 +0200 From: Christer Holmberg To: Robert Sparks , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] 491 for non-INVITE/UPDATE/PRACK Thread-Index: AdEAKqzeRZQgUVr1TzyQ7YYv/MsLDwACEzyAAA6wa0D///EtAP//2+/A Date: Tue, 6 Oct 2015 20:50:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37B261C5@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37B1E9F7@ESESSMB209.ericsson.se> <5613DB57.3060005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37B24FF4@ESESSMB209.ericsson.se> <5614317C.8030006@nostrum.com> In-Reply-To: <5614317C.8030006@nostrum.com> 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+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvja6iiUiYQdN/EYsVGw6wWlyb08hm 8fXHJjYHZo+/7z8weSxZ8pPJY9bOJywBzFFcNimpOZllqUX6dglcGe1/3zIWzGSt+Hv7DmMD 4zfmLkYODgkBE4lnO2K6GDmBTDGJC/fWs3UxcnEICRxllPj19g4jhLOYUeJv0yOwBjYBC4nu f9ogDSIC5RLHrrWzg9jCAmYSm/eeYoSIm0usXvyQDcJ2kzh36iFYDYuAisTbxV+YQGxeAV+J 5l0vWCDmX2GUONZ+mxkkwSmgLTFz9RowmxHoou+n1oA1MAuIS9x6Mp8J4lIBiSV7zjND2KIS Lx//Y4WwlSQW3f4MVa8jsWD3JzYIW1ti2cLXzBCLBSVOznzCMoFRdBaSsbOQtMxC0jILScsC RpZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIGxc3DLb6sdjAefOx5iFOBgVOLhffBJKEyI NbGsuDL3EKM0B4uSOG8z04NQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyKTmvvf5l4Q7Il d+WLknCtiFbFtqPrnnWUtzVMf9TccPO5V/mNtlz20qguAxOWH6JyDHEVmuWflzx22PbfaX1X QIzQLLEjHFuPHZ126Vlb0er4mwXTWTTPvTr0pCxp/jkNnl1P3auSzBfb8v2y1zhlJbryaMHn wNDHqlpvXuU+zONeMe2Y2jolluKMREMt5qLiRABQBuSEfgIAAA== Archived-At: Subject: Re: [sipcore] 491 for non-INVITE/UPDATE/PRACK 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: Tue, 06 Oct 2015 20:50:45 -0000 Hi, >> 3. The application server receives the SUBSCRIBE before it receives the = response to the re-INVITE, so it rejects the SUBSCRIBE with 491. > The semantics here are wrong. 491 in that case does not make sense. > > This isn't "you have glare, back off and try again", which is where 491 i= s used so far. > > It's "I don't have the application state you are looking for (yet).=20 > Please try again later" (or at least, that's what I can infer from your d= escription so far)." So, do we have a response code for that? :) I was looking at 500, 503 etc, but I am not sure that they really fit eithe= r. Regards, Christer From nobody Tue Oct 6 14:01: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 466BC1B3344 for ; Tue, 6 Oct 2015 14:01:33 -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 w_J58vDNsU_u for ; Tue, 6 Oct 2015 14:01:28 -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 742841B3341 for ; Tue, 6 Oct 2015 14:01:28 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t96L1LHP008886 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 6 Oct 2015 16:01:22 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local To: Christer Holmberg , Paul Kyzivat , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B37B1E9F7@ESESSMB209.ericsson.se> <5613DB57.3060005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37B24FF4@ESESSMB209.ericsson.se> <5614317C.8030006@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B261C5@ESESSMB209.ericsson.se> From: Robert Sparks Message-ID: <5614369D.7010108@nostrum.com> Date: Tue, 6 Oct 2015 16:01:17 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B261C5@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] 491 for non-INVITE/UPDATE/PRACK 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: Tue, 06 Oct 2015 21:01:33 -0000 500 is probably the best, in the generic case, but I'm still trying to wrap my head around the scenario as you've described it. Wanting to reject a SUBSCRIBE to the conference event package for the reason given seems like the application is doing something unusual/unexpected with that event package. Can you double-check that it's the conference and not the dialog package? Whichever it is, what's the motivation for not just accepting the SUBSCRIBE and waiting for the right application state to come in to send the relevant NOTIFY? Is it that they can't figure out a reasonable immediate NOTIFY to send? RjS On 10/6/15 3:50 PM, Christer Holmberg wrote: > Hi, > >>> 3. The application server receives the SUBSCRIBE before it receives the response to the re-INVITE, so it rejects the SUBSCRIBE with 491. >> The semantics here are wrong. 491 in that case does not make sense. >> >> This isn't "you have glare, back off and try again", which is where 491 is used so far. >> >> It's "I don't have the application state you are looking for (yet). >> Please try again later" (or at least, that's what I can infer from your description so far)." > So, do we have a response code for that? :) > > I was looking at 500, 503 etc, but I am not sure that they really fit either. > > Regards, > > Christer > > > > > > > From nobody Tue Oct 6 15:03: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 268A81B3451 for ; Tue, 6 Oct 2015 15:03:40 -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 NhAlpgX5UVaF for ; Tue, 6 Oct 2015 15:03:39 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62721AD061 for ; Tue, 6 Oct 2015 15:03:38 -0700 (PDT) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-05v.sys.comcast.net with comcast id Ry3Q1r0042Udklx01y3dhn; Tue, 06 Oct 2015 22:03:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-18v.sys.comcast.net with comcast id Ry3d1r0023Ge9ey01y3dj2; Tue, 06 Oct 2015 22:03:37 +0000 To: Christer Holmberg , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B37B1E9F7@ESESSMB209.ericsson.se> <5613DB57.3060005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37B24FF4@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56144537.6000805@alum.mit.edu> Date: Tue, 6 Oct 2015 18:03:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B24FF4@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=1444169017; bh=yDYi6IN1eY0ksHD0VuuuhaiYChxp2M72g62vDjp4MiI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=A6EVKFG2+FunRbNiaoBqbmhst4kzSVOJZhzgLEZyLg2oxLZVCz0pWhgnH1w6vFSXU U1LSxjz8PDAx7fwV14pYDjzPQTUa8nV3J7m0kDptHq/oerGNzPKFKriB+ImaXID7Xf nId/w22XzmFekuubiZrZyvR/oer1fzNq98Mff9lhF81GEHWaQf1AabVL0QCoXBmwNR NPPUR+SOcKu+8AqmGEc8VGMdmDSuR1FVS9fWSSAWskutfuL6oGHHV/Bvr8pCbouIvu xlj4R56qixOrge84obMzvhX4at+iUommBtnPrmh3TuLt1G4Xw2gE0vvzaA3QDkpqTe bvtzl5PxNF/YA== Archived-At: Subject: Re: [sipcore] 491 for non-INVITE/UPDATE/PRACK 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: Tue, 06 Oct 2015 22:03:40 -0000 On 10/6/15 4:02 PM, Christer Holmberg wrote: > Hi, > >>> The 491 response code was introduced in RFC 3261 in order to deal with >>> re-INVITE race conditions. RFC 3311 extended the usage to UPDATEs and >>> PRACKs carrying SDP offers. >>> >>> My question is: is it allowed to use 491 for other methods and cases, >>> where the application determines that a request cannot be accepted due >>> to another outstanding transaction on the same dialog? RFC 3261 does >>> not explicitly forbid it, as far as I know. >> >> Can you be more specific about the case? >> >> I am inclined to say Yes. But I think this probably should be handled on a case by case basis, to ensure that some other code wouldn't make more sense, or that a new code is really needed. > > The case is the following (high-level, as I am not aware of the details): > > 1. An application server sends a re-INVITE, with an updated offer, to a UA > 2. When the UA receives the re-INVITE, it sends a SUBSCRIBE for an event package (conference, afaik) to the application server. Is this a coincident occurrence of two unrelated events, or is the re-INVITE causing the UA to send the SUBSCRIBE? Also, is this creating a new subscription, or refreshing an existing one? Or is it a polling subscribe? (I don't know if the answers to the above will have any effect on the ultimate answer. I'm just trying to grasp what is going on.) Thanks, Paul > 3. The application server receives the SUBSCRIBE before it receives the response to the re-INVITE, so it rejects the SUBSCRIBE with 491. It wants to get the response to the re-INVITE before it accepts the SUBSCRIBE (exactly why I don't know). > > The UA seems to be 3265 compliant, as it sends the SUBSCRIBE within the invite dialog. However, that problem would be the same even if the SUBSCRIBE was sent on a different dialog. I guess the response code may be different, because the 3261 text about 491 does talk about pending transactions *within the same dialog*. > > Now, IF we would allow general usage of 491, then it would be perhaps be good to also indicate exactly *which* pending transaction triggered the 491. Perhaps the transaction-id could be used for this. > > Regards, > > Christer > > From nobody Thu Oct 8 13:17:32 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 4CDAD1ACD2A for ; Thu, 8 Oct 2015 13:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 vNCjYmiNiHGY for ; Thu, 8 Oct 2015 13:17:26 -0700 (PDT) Received: from smtp117.ord1c.emailsrvr.com (smtp117.ord1c.emailsrvr.com [108.166.43.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB7F1ACD25 for ; Thu, 8 Oct 2015 13:17:26 -0700 (PDT) Received: from smtp7.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id E19773801DA; Thu, 8 Oct 2015 16:17:25 -0400 (EDT) Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 24C4A380306; Thu, 8 Oct 2015 16:17:25 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.222.64] ([UNAVAILABLE]. [128.107.241.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Thu, 08 Oct 2015 20:17:25 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37AE6750@ESESSMB209.ericsson.se> Date: Thu, 8 Oct 2015 12:15:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B37AC0CF1@ESESSMB209.ericsson.se> <3308F2DE-08F1-46A0-BC01-2445627BAD53@iii.ca> <56031836.3080407@nostrum.com> <4E205A3B-F608-48D3-9DA5-D2220A97D953@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37AE6750@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.2104) Archived-At: Cc: DISPATCH list , Ben Campbell , SIPCORE 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: Thu, 08 Oct 2015 20:17:29 -0000 My 2 cents is still more appropriate to fix it with a draft that epodes = it not an Errata. Imagine an SBC or Firewall that is checking the SIP = syntax using the ABNF. The odds of them seeing this change and = implementing it much better with an RFC than an errata. Total work = either way is minimal.=20 > On Sep 30, 2015, at 9:12 AM, Christer Holmberg = wrote: >=20 > Hi, >=20 >> (+sipcore, dispatch) >> (as individual) >>=20 >> I just realized this discussion did not include the sipcore or = dispatch lists, and probably should. >>=20 >> Recap: Christer proposed an errata (4474) to RFC 7315. It proposes = the following change: >>=20 >>> Section 5.4 says: >>>=20 >>> extension-access-info =3D gen-value >>>=20 >>> It should say: >>>=20 >>> extension-access-info =3D generic-param >>=20 >> The generic-param construction allows the NAME =3D VALUE syntax as in = the TS 24.229 extension Jean mentioned below. >>=20 >> Keeping in mind the RFC in question was for 3GPP: Is anyone aware of = implementations of 7315 that would be broken >> by this? =46rom Jean's example, it looks like 3GPP had already = assumed generic-param. >=20 > Correct. >=20 > Also, comparing RFC 3455 and RFC 7315, *all but one* of the new = access-info parameter values that were added in RFC 7315 follow the = generic-param syntax. So, it seems like we in IETF also assumed = generic-param when we did RFC 7315 (and/or we were not concerned about = parser issues), but nobody noticed the ABNF issue. >=20 > And, as I said earlier, I am pretty sure this header is mostly (only?) = used in 3GPP environments, and nobody in 3GPP objected to the change I = am now suggesting. It was discussed in 3GPP, and the outcome was to file = the errata. >=20 > Finally, as Jean indicated, 3GPP has defined a new value, = daylight-saving-time, which also uses the generic-param syntax. >=20 > Regards, >=20 > Christer >=20 >=20 > On 23 Sep 2015, at 16:23, A. Jean Mahoney wrote: >=20 >> FWIW - TS 24.229, which defines the values for access-info, considers=20= >> extension-access-info to be a generic-param, and not a gen-value as=20= >> specified RFC7315. 3GPP has defined one extension so far (7.2A.4): >>=20 >>=20 >> daylight-saving-time =3D "daylight-saving-time" EQUAL quoted-string >>=20 >> TS 124 229 - V12.9.0 - Digital cellular telecommunications system=20 >> (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; = IP=20 >> multimedia call control protocol based on Session Initiation Protocol=20= >> (SIP) and Session Description Protocol (SDP); Stage 3 (3GPP TS 24.229=20= >> version 12.9.0 Release 12) The daylight-saving-time is an instance of=20= >> generic-param from the current extension-access-info component of the=20= >> P- Access-Network-Info header field defined in RFC >> 7315 [52]. >>=20 >>=20 >> Jean >>=20 >>=20 >>=20 >> 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=20 >>> Christer is proposing but I don't see how you can change it now. = This=20 >>> change would break existing parsers that checked this. That does not=20= >>> seem like an errata level thing to me. >>>=20 >>>=20 >>>> On Sep 21, 2015, at 10:30 AM, Ben Campbell wrote: >>>>=20 >>>> sipcore and dispatch chairs: >>>>=20 >>>> Do you have any concerns about accepting Christer's errata? (I note=20= >>>> RFC 7315 was an orphaned sipping draft progressed as AD sponsored.) >>>>=20 >>>> Ben. >>>>=20 >>>> Forwarded message: >>>>=20 >>>>> 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 >>>>>=20 >>>>> Any news on this? >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 >>>>> Christer Holmberg >>>>> Sent: 14. syyskuuta 2015 23:24 >>>>> To: Ben Campbell >>>>> Cc: sipcore@ietf.org >>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474) >>>>>=20 >>>>> Hi Ben, >>>>>=20 >>>>> I am pretty sure generic-param was the original intention. The=20 >>>>> majority of all existing value follow the generic-param syntax, = and=20 >>>>> I can't think of any reason why new values would not follow the=20 >>>>> same syntax. That is how it works for other header fields too. >>>>>=20 >>>>> I think this is due to a mistake, where someone thought that=20 >>>>> extension-access-info represents the actual parameter name, and=20= >>>>> therefor only a value (gen-value) is needed. But,=20 >>>>> extension-access-info represents the whole rule (name AND value),=20= >>>>> why generic-param is needed :) >>>>>=20 >>>>> Regards, >>>>>=20 >>>>> Christer >>>>>=20 >>>>> Sent from my Windows Phone >>>>> ________________________________ >>>>> From: Ben Campbell >>>>> Sent: =E2=80=8E14/=E2=80=8E09/=E2=80=8E2015 21:31 >>>>> To: Christer Holmberg >>>>> Cc: sipcore@ietf.org >>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 (4474)=20= >>>>> Hi Christer, >>>>>=20 >>>>> Is it your understanding that the use of generic-param was the=20 >>>>> actual intention at the time 7315 was published? Or was gen-value=20= >>>>> the original intention, but we now think that it should have been=20= >>>>> generic-param? >>>>>=20 >>>>> Thanks! >>>>>=20 >>>>> Ben. >>>>>=20 >>>>> On 14 Sep 2015, at 6:22, Christer Holmberg wrote: >>>>>=20 >>>>>> FYI, >>>>>>=20 >>>>>> I've now submitted the errata. >>>>>>=20 >>>>>> Regards, >>>>>>=20 >>>>>> Christer >>>>>>=20 >>>>>> -----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) >>>>>>=20 >>>>>> The following errata report has been submitted for RFC7315,=20 >>>>>> "Private Header (P-Header) Extensions to the Session Initiation=20= >>>>>> Protocol >>>>>> (SIP) >>>>>> for the 3GPP". >>>>>>=20 >>>>>> -------------------------------------- >>>>>> You may review the report below and at: >>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D7315&eid=3D4474 >>>>>>=20 >>>>>> -------------------------------------- >>>>>> Type: Technical >>>>>> Reported by: Christer Holmberg >>>>>> = >>>>> com>> >>>>>>=20 >>>>>> Section: 5.4 >>>>>>=20 >>>>>> Original Text >>>>>> ------------- >>>>>> extension-access-info =3D gen-value >>>>>>=20 >>>>>> Corrected Text >>>>>> -------------- >>>>>> extension-access-info =3D generic-param >>>>>>=20 >>>>>> Notes >>>>>> ----- >>>>>> Most of the pre-defined access-info values are following the=20 >>>>>> generic-param syntax. New access-info values (extensions) should=20= >>>>>> also be allowed to follow the generic-param syntax, in order to=20= >>>>>> allow both for a name and value of the extension. >>>>>>=20 >>>>>> Instructions: >>>>>> ------------- >>>>>> This erratum is currently posted as "Reported". If necessary,=20 >>>>>> please use "Reply All" to discuss whether it should be verified = or=20 >>>>>> rejected. >>>>>> When a decision is reached, the verifying party (IESG) can log in=20= >>>>>> 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 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 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> 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 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Oct 8 19:03: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 40F3D1A6F38; Thu, 8 Oct 2015 19:03:17 -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 9ldcGrIygDyO; Thu, 8 Oct 2015 19:03:13 -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 678881A6F2F; Thu, 8 Oct 2015 19:03:11 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-93-5617205d64e3 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CA.15.27359.D5027165; Fri, 9 Oct 2015 04:03:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.226]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Fri, 9 Oct 2015 04:03:09 +0200 From: Christer Holmberg To: Cullen Jennings Thread-Topic: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 (4474) Thread-Index: AQHQ7t97nIYDUJCaWUq0zXVQ2fcq45474U6QgABWdwCAAEDu14AKWWCwgA5pe2uAAAkewIAMprMAgACkLFI= Date: Fri, 9 Oct 2015 02:03:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37B346AB@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> <7594FB04B1934943A5C02806D1A2204B37AE6750@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37B346ABESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGfG3RjdOQTzMYPJKRov5nafZLZZOWsBq 8WH9D0aLrz82sTmweCxZ8pPJ4/L5j4wes3Y+YQlgjuKySUnNySxLLdK3S+DKaPrTwFyw+Thj xYTWi+wNjN9XM3YxcnJICJhIPJ9+iwnCFpO4cG89WxcjF4eQwFFGib5Hy9ghnMWMEl+3z2Hp YuTgYBOwkOj+pw3SICKgLHFux11mEJtZIFni/aGDzCAlwgI+Eh/3iUCU+Eoca9rEDGEnSRzu X8IOYrMIqEjMv/WKEaScF6jm/to0iE0/mCSOfvoHVsMpYCXx4vQpsDsZgW77fmoNE8QqcYmm LytZIW4WkFiy5zwzhC0q8fLxP1aImnyJfZeWgs3hFRCUODnzCcsERpFZSNpnISmbhaQMIm4g 8eX9bShbW2LZwtfMELa+RPf700zI4gsY2VcxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBMbd wS2/DXYwvnzueIhRgINRiYd3oZ1YmBBrYllxZe4hRmkOFiVx3mamB6FCAumJJanZqakFqUXx RaU5qcWHGJk4OKUaGGPm+ShFvTZM652Rsau4WnHP2n7bq32r/4myT++6bPHkQebmmE1XDyw3 1hJq743R+sDW2PkhRN5+8abFE8LenF2Rc1y+0DhBu2nX/m03GN5vWjHX8u7VaeH2jbNCGhXf FO38a/FASUnzveEXF7lXWZH6ZbMSAu68sHH3Oh/s87hboyDmXqdwgBJLcUaioRZzUXEiAMXu nHecAgAA Archived-At: Cc: DISPATCH list , Ben Campbell , SIPCORE 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: Fri, 09 Oct 2015 02:03:17 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37B346ABESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Cullen, So, you are suggesting a SIPCORE draft that updates the ABNF? Regards, Christer Sent from my Windows Phone ________________________________ From: Cullen Jennings Sent: =FD08/=FD10/=FD2015 23:17 To: Christer Holmberg Cc: Ben Campbell; SIPCORE;= DISPATCH list Subject: Re: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 (4474= ) My 2 cents is still more appropriate to fix it with a draft that epodes it= not an Errata. Imagine an SBC or Firewall that is checking the SIP syntax = using the ABNF. The odds of them seeing this change and implementing it muc= h better with an RFC than an errata. Total work either way is minimal. > On Sep 30, 2015, at 9:12 AM, Christer Holmberg wrote: > > Hi, > >> (+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 f= ollowing change: >> >>> Section 5.4 says: >>> >>> extension-access-info =3D gen-value >>> >>> It should say: >>> >>> extension-access-info =3D generic-param >> >> The generic-param construction allows the NAME =3D VALUE syntax as in th= e TS 24.229 extension Jean mentioned below. >> >> Keeping in mind the RFC in question was for 3GPP: Is anyone aware of imp= lementations of 7315 that would be broken >> by this? From Jean's example, it looks like 3GPP had already assumed gen= eric-param. > > Correct. > > Also, comparing RFC 3455 and RFC 7315, *all but one* of the new access-in= fo parameter values that were added in RFC 7315 follow the generic-param sy= ntax. So, it seems like we in IETF also assumed generic-param when we did = RFC 7315 (and/or we were not concerned about parser issues), but nobody not= iced the ABNF issue. > > And, as I said earlier, I am pretty sure this header is mostly (only?) us= ed in 3GPP environments, and nobody in 3GPP objected to the change I am now= suggesting. It was discussed in 3GPP, and the outcome was to file the erra= ta. > > Finally, as Jean indicated, 3GPP has defined a new value, daylight-saving= -time, which also uses the generic-param syntax. > > Regards, > > Christer > > > 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 =3D "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: =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 >>>>>> >>>>> 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 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 > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --_000_7594FB04B1934943A5C02806D1A2204B37B346ABESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Cullen,
So, you are suggesting a SIPCORE draft that updates the ABNF?

Regards,

Christer

Sent from my Windows Phone
From: Cullen Jennings
Sent: =FD08= /=FD10/=FD2015 23:17
To: Christer Holmberg Cc: Ben Campbell; SIPCORE; DISPATCH list
Subject: Re: [= dispatch] [sipcore] [Technical Errata Reported] RFC7315 (4474)


My 2 cents is still more appropriate to fix it with a draft that epodes&nbs= p; it not an Errata. Imagine an SBC or Firewall that is checking the SIP sy= ntax using the ABNF. The odds of them seeing this change and implementing i= t much better with an RFC than an errata. Total work either way is minimal.


> On Sep 30, 2015, at 9:12 AM, Christer Holmberg <christer.holmberg@e= ricsson.com> wrote:
>
> Hi,
>
>> (+sipcore, dispatch)
>> (as individual)
>>
>> I just realized this discussion did not include the sipcore or dis= patch 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  =3D gen-value
>>>
>>> It should say:
>>>
>>> extension-access-info  =3D generic-param
>>
>> The generic-param construction allows the NAME =3D 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 assum= ed generic-param.
>
> Correct.
>
> Also, comparing RFC 3455 and RFC 7315, *all but one* of the new access= -info parameter values that were added in RFC 7315 follow the generic-param= syntax.  So, it seems like we in IETF also assumed generic-param when= we did RFC 7315 (and/or we were not concerned about parser issues), but nobody noticed the ABNF issue.
>
> And, as I said earlier, I am pretty sure this header is mostly (only?)= used in 3GPP environments, and nobody in 3GPP objected to the change I am = now suggesting. It was discussed in 3GPP, and the outcome was to file the e= rrata.
>
> Finally, as Jean indicated, 3GPP has defined a new value, daylight-sav= ing-time, which also uses the generic-param syntax.
>
> Regards,
>
> Christer
>
>
> On 23 Sep 2015, at 16:23, A. Jean Mahoney wrote:
>
>> FWIW - TS 24.229, which defines the values for access-info, consid= ers
>> extension-access-info to be a generic-param, and not a gen-value a= s
>> specified RFC7315. 3GPP has defined one extension so far (7.2A.4):=
>>
>>
>> daylight-saving-time =3D "daylight-saving-time" EQUAL qu= oted-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 Proto= col
>> (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 t= his way
>>> Christer is proposing but I don't see how you can change it no= w. This
>>> change would break existing parsers that checked this. That do= es not
>>> seem like an errata level thing to me.
>>>
>>>
>>>> On Sep 21, 2015, at 10:30 AM, Ben Campbell <ben@nostrum= .com> 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 sp= onsored.)
>>>>
>>>> Ben.
>>>>
>>>> Forwarded message:
>>>>
>>>>> From: Christer Holmberg <christer.holmberg@ericsson= .com>
>>>>> To: Ben Campbell <ben@nostrum.com>
>>>>> Cc: sipcore@ietf.org <sipcore@ietf.org>
>>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC= 7315 (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] RFC= 7315 (4474)
>>>>>
>>>>> Hi Ben,
>>>>>
>>>>> I am pretty sure generic-param was the original intent= ion. The
>>>>> majority of all existing value follow the generic-para= m syntax, and
>>>>> I can't think of any reason why new values would not f= ollow the
>>>>> same syntax. That is how it works for other header fie= lds too.
>>>>>
>>>>> I think this is due to a mistake, where someone though= t that
>>>>> extension-access-info  represents the actual para= meter 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<mailto:ben@nostrum.com>
>>>>> Sent: =FD14/=FD09/=FD2015 21:31
>>>>> To: Christer Holmberg<mailto:christer.holmberg@ericsson.com>
>>>>> Cc: sipcore@ietf.org<mailto:sipcore@ietf.org>
>>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC= 7315 (4474)
>>>>> Hi Christer,
>>>>>
>>>>> Is it your understanding that the use of generic-param= was the
>>>>> actual intention at the time 7315 was published? Or wa= s gen-value
>>>>> the original intention, but we now think that it shoul= d 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<mailto:r.jesske@telekom.de>;
>>>>>> drage@alcatel-lucent.com<mailto:drage@alcatel-l= ucent.com>;
>>>>>> Christer Holmberg;
>>>>>> iesg@ietf.org<= mailto:iesg@ietf.org>
>>>>>> Cc: Christer Holmberg;
>>>>>> rfc-editor@rfc-editor.org<mailto: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
>>>>>> <christer.holmberg@ericsson.com<mailto:chris= ter.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 fol= lowing the
>>>>>> generic-param syntax. New access-info values (exte= nsions) should
>>>>>> also be allowed to follow the generic-param syntax= , in order to
>>>>>> allow both for a name and value of the extension.<= br> >>>>>>
>>>>>> Instructions:
>>>>>> -------------
>>>>>> This erratum is currently posted as "Reported= ". If necessary,
>>>>>> please use "Reply All" to discuss whethe= r it should be verified or
>>>>>> rejected.
>>>>>> When a decision is reached, the verifying party (I= ESG) can log in
>>>>>> to change the status and edit the report, if neces= sary.
>>>>>>
>>>>>> --------------------------------------
>>>>>> RFC7315 (draft-drage-sipping-rfc3455bis-14)
>>>>>> --------------------------------------
>>>>>> Title       &nb= sp;       : Private Header (P-Header) Extensi= ons to the
>>>>>> Session Initiation Protocol (SIP) for the 3GPP
>>>>>> Publication Date    : July 2014
>>>>>> Author(s)       = ;    : R. Jesske, K. Drage, C. Holmberg
>>>>>> Category       =      : INFORMATIONAL
>>>>>> Source       &n= bsp;      : IETF - NON WORKING GROUP
>>>>>> Area       &nbs= p;        : N/A
>>>>>> Stream       &n= bsp;      : IETF
>>>>>> Verifying Party     : IESG
>>>>>>
>>>>>> _______________________________________________ >>>>>> sipcore mailing list
>>>>>> sipcore@ietf.org<mailto:sipcore@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>> _______________________________________________
>>>>> sipcore mailing list
>>>>> sipcore@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www= .ietf.org/mailman/listinfo/dispatch

 --_000_7594FB04B1934943A5C02806D1A2204B37B346ABESESSMB209erics_-- From nobody Wed Oct 14 07:21:07 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 AC5941A212D; Wed, 14 Oct 2015 07:21:04 -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 lOji1xrZrUbc; Wed, 14 Oct 2015 07:21:02 -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 B2B151A00A7; Wed, 14 Oct 2015 07:21:02 -0700 (PDT) Received: from [10.0.1.9] (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 t9EEKua9062938 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 14 Oct 2015 09:20:57 -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.9] From: "Ben Campbell" To: "Christer Holmberg" Date: Wed, 14 Oct 2015 09:20:56 -0500 Message-ID: <80DA0B29-EDE9-4DDE-948B-463A364A2E0F@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B346AB@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> <7594FB04B1934943A5C02806D1A2204B37AE6750@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B346AB@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: DISPATCH list , SIPCORE , 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, 14 Oct 2015 14:21:04 -0000 On 8 Oct 2015, at 21:03, Christer Holmberg wrote: > Hi Cullen, > > So, you are suggesting a SIPCORE draft that updates the ABNF? This is where the chairs will point out that special-purpose extensions are generally not in scope for sipcore :-) If so, this might could also be done as AD sponsored. Ben. From nobody Thu Oct 15 00:19:45 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 59E4E1A007C for ; Thu, 15 Oct 2015 00:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_SE=0.35, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx6sACrzljAl for ; Thu, 15 Oct 2015 00:19:41 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id B53A91A004E for ; Thu, 15 Oct 2015 00:19:41 -0700 (PDT) Received: from [192.168.40.34] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id B585693DEBC; Thu, 15 Oct 2015 07:19:15 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Oct 2015 09:19:24 +0200 Message-Id: <78DBB096-A268-4AFB-B261-6057412FEE8E@edvina.net> To: SIPCORE Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Olle E Johansson Subject: [sipcore] DANE and SIP 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: Thu, 15 Oct 2015 07:19:43 -0000 Hi! Yesterday RFC 7673 - "using DNS-based authentication of named entities = (DANE) TLSA records with SRV records=E2=80=9D was published.=20 Section 5 clearly states that the SIP protocol in order to use DANE = needs to have our own guidelines. I let my draft expire, had too much to do and was waiting for this = document to be published. Now there should not be any discussion about = IF we need to publish a document, more about what type of document we = need to write - if there=E2=80=99s any interest at all in supporting = DANE in the SIP protocol. I=E2=80=99ve seen at least one implementation of my draft, so there=E2=80=99= s some interest out there. My question is whether I should spend time on refreshing my draft - I = guess there are some references to update and some text made redundant = by RFC 7673 that did not exist at the time I wrote my draft. Anyone interested in working on this? /O= From nobody Sun Oct 18 00:52:30 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 5A0091B2DFE; Sun, 18 Oct 2015 00:52:29 -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 VAYD_Y5Kh7_I; Sun, 18 Oct 2015 00:52:28 -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 684251A8A20; Sun, 18 Oct 2015 00:52:27 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-b7-56234fb99de2 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 63.02.29154.9BF43265; Sun, 18 Oct 2015 09:52:25 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0248.002; Sun, 18 Oct 2015 09:52:24 +0200 From: Christer Holmberg To: Ben Campbell Thread-Topic: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 (4474) Thread-Index: AQHRAjatMgpPsiF4akOaFmByCBAVyZ5q8SAAgAX+TUk= Date: Sun, 18 Oct 2015 07:52:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37B5BC73@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> <7594FB04B1934943A5C02806D1A2204B37AE6750@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B346AB@ESESSMB209.ericsson.se>, <80DA0B29-EDE9-4DDE-948B-463A364A2E0F@nostrum.com> In-Reply-To: <80DA0B29-EDE9-4DDE-948B-463A364A2E0F@nostrum.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37B5BC73ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGfG3Rnenv3KYwcrt0hbzO0+zWyydtIDV 4sP6H4wWX39sYnNg8Viy5CeTx+XzHxk9Zu18whLAHMVlk5Kak1mWWqRvl8CVsW19acFmmYrP Z3ayNDC+lehi5OSQEDCROLrpMTuELSZx4d56NhBbSOAoo8TiBqUuRi4gezGjxJVL14GKODjY BCwkuv9pg9SICChJPG/eygJiMwukSHROW8YEYgsL+Ej8ObeHEaLGV2L3jX42CNtK4ubp2WBj WARUJVb98gcJ8wKVfNk2hwli1UdmiZ9Nt8DqOQXsJTbtOcsKYjMC3fb91BomiF3iEk1fVrJC 3CwgsWTPeWYIW1Ti5eN/rBA1+RLT9/SzQCwQlDg58wnLBEaRWUjaZyEpm4WkDCJuIPHl/W0o W1ti2cLXzBC2vkT3+9NMyOILGNlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgRG3MEtv612 MB587niIUYCDUYmH98ERpTAh1sSy4srcQ4zSHCxK4rzNTA9ChQTSE0tSs1NTC1KL4otKc1KL DzEycXBKNTAG1C93eOR9eAfLmo+hK95J93Bo3Z29UqLg8BJ7lWNX/rTdf+17ozg3U/eXkV5J s0vhzKI1vCklFzoTxVKPiza0BL6t3cCx62vI6X8tN83EwzbYJG+SZc2dUmuvdocxYa9OR7Hb 8yPqaXNZVmz5VvDwfGnRwlnSE7wnXYrMXOL2yciumf/iaT4lluKMREMt5qLiRAA11kpKmQIA AA== Archived-At: Cc: DISPATCH list , SIPCORE , 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: Sun, 18 Oct 2015 07:52:29 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37B5BC73ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi, So, shall I address the draft to some WG, or? draft-holmberg-dispatch ? Regards, Christer Sent from my Windows Phone ________________________________ From: Ben Campbell Sent: =FD14/=FD10/=FD2015 17:21 To: Christer Holmberg Cc: Cullen Jennings; DISPATCH list; SIPCORE Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 (4474= ) On 8 Oct 2015, at 21:03, Christer Holmberg wrote: > Hi Cullen, > > So, you are suggesting a SIPCORE draft that updates the ABNF? This is where the chairs will point out that special-purpose extensions are generally not in scope for sipcore :-) If so, this might could also be done as AD sponsored. Ben. --_000_7594FB04B1934943A5C02806D1A2204B37B5BC73ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi,

So, shall I address the draft to some WG, or?

draft-holmberg-dispatch ?

Regards,

Christer

Sent from my Windows Phone
From: Ben Campbell
Sent: =FD14= /=FD10/=FD2015 17:21
To: Christer Holmberg Cc: Cullen Jennings; DISPATCH list; SIPCORE
Subject: Re: [= sipcore] [dispatch] [Technical Errata Reported] RFC7315 (4474)

On 8 Oct 2015, at 21:03, Christer Holmberg wrote:<= br>
> Hi Cullen,
>
> So, you are suggesting a SIPCORE draft that updates the ABNF?

This is where the chairs will point out that special-purpose extensions are generally not in scope for sipcore :-) If so, this might could also be done as AD sponsored.

Ben.

 --_000_7594FB04B1934943A5C02806D1A2204B37B5BC73ESESSMB209erics_-- From nobody Sun Oct 18 04:49:30 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 D423F1A1A9D; Sun, 18 Oct 2015 04:49:27 -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 CDJVU87NM925; Sun, 18 Oct 2015 04:49:26 -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 F3BDE1A1A98; Sun, 18 Oct 2015 04:49:24 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-36-56238742a455 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B9.C0.17026.24783265; Sun, 18 Oct 2015 13:49:22 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Sun, 18 Oct 2015 13:49:22 +0200 From: Christer Holmberg To: Ben Campbell , DISPATCH list , SIPCORE Thread-Topic: Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 (4474)] Thread-Index: AdEJmu30RT4yoyGuQwycw+O/R8vMMg== Date: Sun, 18 Oct 2015 11:49:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37B62FC0@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.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37B62FC0ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvja5Tu3KYwdlmc4v5nafZLZZOWsBq 8fXHJjYHZo8lS34yecza+YQlgCmKyyYlNSezLLVI3y6BK6NvfW3B64yKnz86GRsYj8d2MXJy SAiYSOxsnMsGYYtJXLi3Hsjm4hASOMoo0T79AROEs5hR4v+le6xdjBwcbAIWEt3/tEEaRASS JR7Ous8OUiMs0MgosXzmQRaIRBujxOJ7dSD1IgJ6EjuupoKYLAKqEr/3moCYvAK+Ere2eoIU MwKt/X5qDROIzSwgLnHryXwmiHMEJJbsOc8MYYtKvHz8jxXCVpJYe3g7C0R9vkR7WwdYDa+A oMTJmU9YJjAKzUIyahaSsllIyiDiBhLntm9kh7C1JZYtfM0MYetLbL89kxVZfAEj+ypG0eLU 4uLcdCNjvdSizOTi4vw8vbzUkk2MwFg5uOW37g7G1a8dDzEKcDAq8fA+OKIUJsSaWFZcmXuI UZqDRUmct4XpQaiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxuAtE4M78+Xn+BsUlh6ICK47 KuXmo3Ob0/OO3f3Yk8Iy0lfrLr4M9/z4xf2LtF8jp9SaOVt2vfUpq8i6/uvyZtHCLjnONOVp EZMVjjAsqZrqKC3dcz8vo/bp1bNK/oe5TlxrXim58FFCQc8TJgOhcy9fPKp5tXzpa4MZOq5T nrMGz69LNxORU2Ipzkg01GIuKk4EAI7UgWV2AgAA Archived-At: Subject: [sipcore] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [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: Sun, 18 Oct 2015 11:49:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37B62FC0ESESSMB209erics_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, Based on Ben=92s guidance, I=92ve submitted a draft which makes the ABNF up= date. NOTE: As RFC 7315 is an Informational RFC, I had to add the RFC as an Infor= mative reference in the draft, in order to pass the Idnits check. A new version of I-D, draft-holmberg-dispatch-pani-abnf-00.txt has been successfully submitted by Christer Holmberg and posted to the IETF= repository. Name: draft-holmberg-dispatch-pani-abnf Revision: 00 Title: P-Access-Network-Info ABNF Update Document date: 2015-10-18 Group: Individual Submission Pages: 4 URL: https://www.ietf.org/internet-drafts/draft-holmberg-dispatc= h-pani-abnf-00.txt Status: https://datatracker.ietf.org/doc/draft-holmberg-dispatch-pa= ni-abnf/ Htmlized: https://tools.ietf.org/html/draft-holmberg-dispatch-pani-ab= nf-00 Abstract: This document updates RFC 7315, by modifying the extension-access- info part of the P-Access-Network-Info header field Augmented Backus- Naur Form (ABNF). Regards, Christer From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 18 October 2015 10:52 To: Ben Campbell Cc: DISPATCH list ; SIPCORE ; Cullen J= ennings Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 (4474= ) Hi, So, shall I address the draft to some WG, or? draft-holmberg-dispatch ? Regards, Christer Sent from my Windows Phone ________________________________ From: Ben Campbell Sent: =FD14/=FD10/=FD2015 17:21 To: Christer Holmberg Cc: Cullen Jennings; DISPATCH list; SIPCORE Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 (4474= ) On 8 Oct 2015, at 21:03, Christer Holmberg wrote: > Hi Cullen, > > So, you are suggesting a SIPCORE draft that updates the ABNF? This is where the chairs will point out that special-purpose extensions are generally not in scope for sipcore :-) If so, this might could also be done as AD sponsored. Ben. --_000_7594FB04B1934943A5C02806D1A2204B37B62FC0ESESSMB209erics_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

Based on B= en=92s guidance, I=92ve submitted a draft which makes the ABNF update.=

 = ;

NOTE: As R= FC 7315 is an Informational RFC, I had to add the RFC as an Informative ref= erence in the draft, in order to pass the Idnits check.

 = ;

A new version of I-D, draft-holmberg-dispatch-pan= i-abnf-00.txt

has been successfully submitted by Christer Holmb= erg and posted to the IETF repository.

 

Name:       &n= bsp;         draft-holmberg-dispatc= h-pani-abnf

Revision:      &nbs= p;     00

Title:       &= nbsp;            P-A= ccess-Network-Info ABNF Update

Document date:      = ;        2015-10-18

Group:       &= nbsp;        Individual Submission<= /o:p>

Pages:       &= nbsp;         4

URL:       &nb= sp;    https://www.ietf.org/internet-drafts/draft-holmberg-dispatch-pani-abnf-00.t= xt

Status:       =   https://datatracker.ietf.org/doc/draft-holmberg-dispatch-pani-abnf/

Htmlized:       https://tools.ietf.org/html/draft-holmberg-dispatch-pani-abnf-00

 

 

Abstract:

   This document updates RFC 7315, by m= odifying the extension-access-

   info part of the P-Access-Network-In= fo header field Augmented Backus-

   Naur Form (ABNF).

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;

Regards,

 = ;

Christer

 

 = ;

 

From: = sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 18 October 2015 10:52
To: Ben Campbell <ben@nostrum.com>
Cc: DISPATCH list <dispatch@ietf.org>; SIPCORE <sipcore@iet= f.org>; Cullen Jennings <fluffy@iii.ca>
Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC731= 5 (4474)

 

Hi,

So, shall I address the draft to some WG, or?

draft-holmberg-dispatch ?

Regards,

Christer

Sent from my Windows Phone

From: Ben Campbell
Sent: =FD14/=FD10/=FD2015 17:21
To: Chris= ter Holmberg
Cc: Cullen Jennings; DISPATCH list; SIPCORE
Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 (4474)

On 8 Oct 2015, at 21:03, Christer Holmberg wrote:

> Hi Cullen,
>
> So, you are suggesting a SIPCORE draft that updates the ABNF?

This is where the chairs will point out that special-purpose extensions are generally not in scope for sipcore :-) If so, this might could also be done as AD sponsored.

Ben.

--_000_7594FB04B1934943A5C02806D1A2204B37B62FC0ESESSMB209erics_-- From nobody Sun Oct 18 11:27: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 57C881ACD0E; Sun, 18 Oct 2015 11:27:10 -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 FKJZZORhFYqF; Sun, 18 Oct 2015 11:27:08 -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 C89651ACD0C; Sun, 18 Oct 2015 11:27:08 -0700 (PDT) Received: from [10.0.1.9] (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 t9IIR3pC098379 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 18 Oct 2015 13:27:04 -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.9] From: "Ben Campbell" To: "Christer Holmberg" Date: Sun, 18 Oct 2015 13:27:03 -0500 Message-ID: <90429FC5-4199-4386-8CEE-F7F9E45420CE@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B62FC0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37B62FC0@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: DISPATCH list , SIPCORE Subject: Re: [sipcore] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [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: Sun, 18 Oct 2015 18:27:10 -0000 If 7315 is informational, why does the update need to be standards track? Ben. On 18 Oct 2015, at 6:49, Christer Holmberg wrote: > Hi, > > Based on Ben’s guidance, I’ve submitted a draft which makes the > ABNF update. > > NOTE: As RFC 7315 is an Informational RFC, I had to add the RFC as an > Informative reference in the draft, in order to pass the Idnits check. > > > A new version of I-D, draft-holmberg-dispatch-pani-abnf-00.txt > > has been successfully submitted by Christer Holmberg and posted to the > IETF repository. > > > > Name: draft-holmberg-dispatch-pani-abnf > > Revision: 00 > > Title: P-Access-Network-Info ABNF Update > > Document date: 2015-10-18 > > Group: Individual Submission > > Pages: 4 > > URL: > https://www.ietf.org/internet-drafts/draft-holmberg-dispatch-pani-abnf-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-holmberg-dispatch-pani-abnf/ > > Htmlized: > https://tools.ietf.org/html/draft-holmberg-dispatch-pani-abnf-00 > > > > > > Abstract: > > This document updates RFC 7315, by modifying the extension-access- > > info part of the P-Access-Network-Info header field Augmented Backus- > > Naur Form (ABNF). > > > Regards, > > Christer > > > > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer > Holmberg > Sent: 18 October 2015 10:52 > To: Ben Campbell > Cc: DISPATCH list ; SIPCORE ; > Cullen Jennings > Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 > (4474) > > Hi, > > So, shall I address the draft to some WG, or? > > draft-holmberg-dispatch ? > > Regards, > > Christer > > Sent from my Windows Phone > ________________________________ > From: Ben Campbell > Sent: ‎14/‎10/‎2015 17:21 > To: Christer Holmberg > Cc: Cullen Jennings; DISPATCH > list; SIPCORE > Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 > (4474) > On 8 Oct 2015, at 21:03, Christer Holmberg wrote: > >> Hi Cullen, >> >> So, you are suggesting a SIPCORE draft that updates the ABNF? > > This is where the chairs will point out that special-purpose > extensions > are generally not in scope for sipcore :-) If so, this might could > also > be done as AD sponsored. > > Ben. From nobody Sun Oct 18 11:27:51 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 C7A901ACD14; Sun, 18 Oct 2015 11:27:48 -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 8LCwJ12j3Iad; Sun, 18 Oct 2015 11:27:48 -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 D536D1ACD0C; Sun, 18 Oct 2015 11:27:47 -0700 (PDT) Received: from [10.0.1.9] (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 t9IIRhPm098418 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 18 Oct 2015 13:27:44 -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.9] From: "Ben Campbell" To: "Christer Holmberg" Date: Sun, 18 Oct 2015 13:27:43 -0500 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B5BC73@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> <7594FB04B1934943A5C02806D1A2204B37AE6750@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B346AB@ESESSMB209.ericsson.se> <80DA0B29-EDE9-4DDE-948B-463A364A2E0F@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B5BC73@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: DISPATCH list , SIPCORE , 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: Sun, 18 Oct 2015 18:27:48 -0000 dispatch is the place to start. Thanks! Ben. On 18 Oct 2015, at 2:52, Christer Holmberg wrote: > Hi, > > So, shall I address the draft to some WG, or? > > draft-holmberg-dispatch ? > > Regards, > > Christer > > Sent from my Windows Phone > ________________________________ > From: Ben Campbell > Sent: ‎14/‎10/‎2015 17:21 > To: Christer Holmberg > Cc: Cullen Jennings; DISPATCH > list; SIPCORE > Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 > (4474) > > On 8 Oct 2015, at 21:03, Christer Holmberg wrote: > >> Hi Cullen, >> >> So, you are suggesting a SIPCORE draft that updates the ABNF? > > This is where the chairs will point out that special-purpose > extensions > are generally not in scope for sipcore :-) If so, this might could > also > be done as AD sponsored. > > Ben. From nobody Sun Oct 18 11:59:17 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 802C61ACDF0; Sun, 18 Oct 2015 11:59:14 -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 M2U-zj7N9MRL; Sun, 18 Oct 2015 11:59: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 7340D1ACDEC; Sun, 18 Oct 2015 11:59:12 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-98-5623ebfef875 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 07.29.17026.EFBE3265; Sun, 18 Oct 2015 20:59:10 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Sun, 18 Oct 2015 20:59:09 +0200 From: Christer Holmberg To: Ben Campbell Thread-Topic: Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 (4474)] Thread-Index: AQHRCdKZNAGVRpZ6AEOpwBwyzxjoeZ5xml1Q Date: Sun, 18 Oct 2015 18:59:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37B6907F@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37B62FC0@ESESSMB209.ericsson.se> <90429FC5-4199-4386-8CEE-F7F9E45420CE@nostrum.com> In-Reply-To: <90429FC5-4199-4386-8CEE-F7F9E45420CE@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+Jvje6/18phBp3XpSzmd55mt1g6aQGr xdcfm9gcmD2WLPnJ5DFr5xOWAKYoLpuU1JzMstQifbsEroxj0+8wFtyQqdjU+4SxgfGHdBcj J4eEgIlE67s57BC2mMSFe+vZuhi5OIQEjjJKvNp/nR3CWcwo8bu1Hcjh4GATsJDo/qcN0iAi oCTxvHkrC0iYWcBRYtqabJByYYFWRok1L1rZIGraGCUW36uDsI0kbh/ZyghiswioSmx4uBBs Ma+Ar8ScOcugFjcxSszb+4MZJMEpYC9x9dAzFhCbEei676fWMIHYzALiEreezGeCuFpAYsme 88wQtqjEy8f/WCFsJYkV2y8xQhynKbF+lz5Eq6LElO6HUHsFJU7OfMIygVFsFpKpsxA6ZiHp mIWkYwEjyypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwDg6uOW37g7G1a8dDzEKcDAq8fA+ OKIUJsSaWFZcmXuIUZqDRUmct4XpQaiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRiMfZw4f 46f+fT+sjp05PO/1pq0VpjYlF8w2mDvc3sq2cemru8G+cfu+eqpVnvvWlXVP7aCYauJc10Pr K2+2/17GN4F12a865cggSwXXKZvdHoVw53q9tFCY+2zSceZroiVJi3NDFyU/nLynPK5puqLX MbUas3CnRa7CvUaznv3O7r63vubJZiWW4oxEQy3mouJEAKNWtZOEAgAA Archived-At: Cc: DISPATCH list , SIPCORE Subject: Re: [sipcore] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [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: Sun, 18 Oct 2015 18:59:14 -0000 SGksDQoNCj5JZiA3MzE1IGlzIGluZm9ybWF0aW9uYWwsIHdoeSBkb2VzIHRoZSB1cGRhdGUgbmVl ZCB0byBiZSBzdGFuZGFyZHMgdHJhY2s/DQoNCkdvb2QgcG9pbnQgLSBJIGd1ZXNzIGl0IGRvZXNu J3QgaGF2ZSB0byA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCk9uIDE4IE9jdCAyMDE1 LCBhdCA2OjQ5LCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCg0KPiBIaSwNCj4NCj4gQmFzZWQg b24gQmVu4oCZcyBndWlkYW5jZSwgSeKAmXZlIHN1Ym1pdHRlZCBhIGRyYWZ0IHdoaWNoIG1ha2Vz IHRoZSBBQk5GIA0KPiB1cGRhdGUuDQo+DQo+IE5PVEU6IEFzIFJGQyA3MzE1IGlzIGFuIEluZm9y bWF0aW9uYWwgUkZDLCBJIGhhZCB0byBhZGQgdGhlIFJGQyBhcyBhbiANCj4gSW5mb3JtYXRpdmUg cmVmZXJlbmNlIGluIHRoZSBkcmFmdCwgaW4gb3JkZXIgdG8gcGFzcyB0aGUgSWRuaXRzIGNoZWNr Lg0KPg0KPg0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gt cGFuaS1hYm5mLTAwLnR4dA0KPg0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IENocmlzdGVyIEhvbG1iZXJnIGFuZCBwb3N0ZWQgdG8gdGhlIA0KPiBJRVRGIHJlcG9zaXRvcnku DQo+DQo+DQo+DQo+IE5hbWU6ICAgICAgICAgICAgICAgICBkcmFmdC1ob2xtYmVyZy1kaXNwYXRj aC1wYW5pLWFibmYNCj4NCj4gUmV2aXNpb246ICAgICAgICAgICAgMDANCj4NCj4gVGl0bGU6ICAg ICAgICAgICAgICAgICAgICBQLUFjY2Vzcy1OZXR3b3JrLUluZm8gQUJORiBVcGRhdGUNCj4NCj4g RG9jdW1lbnQgZGF0ZTogICAgICAgICAgICAgIDIwMTUtMTAtMTgNCj4NCj4gR3JvdXA6ICAgICAg ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPg0KPiBQYWdlczogICAgICAgICAgICAg ICAgIDQNCj4NCj4gVVJMOiAgICAgICAgICAgIA0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcGFuaS1hYm5mDQo+IC0wMC50eHQN Cj4NCj4gU3RhdHVzOiAgICAgICAgIA0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1wYW5pLWFibmYvDQo+DQo+IEh0bWxpemVkOiAgICAg ICANCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhvbG1iZXJnLWRpc3BhdGNo LXBhbmktYWJuZi0wMA0KPg0KPg0KPg0KPg0KPg0KPiBBYnN0cmFjdDoNCj4NCj4gVGhpcyBkb2N1 bWVudCB1cGRhdGVzIFJGQyA3MzE1LCBieSBtb2RpZnlpbmcgdGhlIGV4dGVuc2lvbi1hY2Nlc3Mt DQo+DQo+IGluZm8gcGFydCBvZiB0aGUgUC1BY2Nlc3MtTmV0d29yay1JbmZvIGhlYWRlciBmaWVs ZCBBdWdtZW50ZWQgQmFja3VzLQ0KPg0KPiBOYXVyIEZvcm0gKEFCTkYpLg0KPg0KPg0KPiBSZWdh cmRzLA0KPg0KPiBDaHJpc3Rlcg0KPg0KPg0KPg0KPg0KPiBGcm9tOiBzaXBjb3JlIFttYWlsdG86 c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgDQo+IEhvbG1i ZXJnDQo+IFNlbnQ6IDE4IE9jdG9iZXIgMjAxNSAxMDo1Mg0KPiBUbzogQmVuIENhbXBiZWxsIDxi ZW5Abm9zdHJ1bS5jb20+DQo+IENjOiBESVNQQVRDSCBsaXN0IDxkaXNwYXRjaEBpZXRmLm9yZz47 IFNJUENPUkUgPHNpcGNvcmVAaWV0Zi5vcmc+OyANCj4gQ3VsbGVuIEplbm5pbmdzIDxmbHVmZnlA aWlpLmNhPg0KPiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFtkaXNwYXRjaF0gW1RlY2huaWNhbCBF cnJhdGEgUmVwb3J0ZWRdIFJGQzczMTUNCj4gKDQ0NzQpDQo+DQo+IEhpLA0KPg0KPiBTbywgc2hh bGwgSSBhZGRyZXNzIHRoZSBkcmFmdCB0byBzb21lIFdHLCBvcj8NCj4NCj4gZHJhZnQtaG9sbWJl cmctZGlzcGF0Y2ggPw0KPg0KPiBSZWdhcmRzLA0KPg0KPiBDaHJpc3Rlcg0KPg0KPiBTZW50IGZy b20gbXkgV2luZG93cyBQaG9uZQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBGcm9tOiBCZW4gQ2FtcGJlbGw8bWFpbHRvOmJlbkBub3N0cnVtLmNvbT4NCj4gU2VudDog4oCO MTQv4oCOMTAv4oCOMjAxNSAxNzoyMQ0KPiBUbzogQ2hyaXN0ZXIgSG9sbWJlcmc8bWFpbHRvOmNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCj4gQ2M6IEN1bGxlbiBKZW5uaW5nczxtYWls dG86Zmx1ZmZ5QGlpaS5jYT47IERJU1BBVENIIA0KPiBsaXN0PG1haWx0bzpkaXNwYXRjaEBpZXRm Lm9yZz47IFNJUENPUkU8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBb c2lwY29yZV0gW2Rpc3BhdGNoXSBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDNzMxNQ0K PiAoNDQ3NCkNCj4gT24gOCBPY3QgMjAxNSwgYXQgMjE6MDMsIENocmlzdGVyIEhvbG1iZXJnIHdy b3RlOg0KPg0KPj4gSGkgQ3VsbGVuLA0KPj4NCj4+IFNvLCB5b3UgYXJlIHN1Z2dlc3RpbmcgYSBT SVBDT1JFIGRyYWZ0IHRoYXQgdXBkYXRlcyB0aGUgQUJORj8NCj4NCj4gVGhpcyBpcyB3aGVyZSB0 aGUgY2hhaXJzIHdpbGwgcG9pbnQgb3V0IHRoYXQgc3BlY2lhbC1wdXJwb3NlIA0KPiBleHRlbnNp b25zIGFyZSBnZW5lcmFsbHkgbm90IGluIHNjb3BlIGZvciBzaXBjb3JlIDotKSBJZiBzbywgdGhp cyANCj4gbWlnaHQgY291bGQgYWxzbyBiZSBkb25lIGFzIEFEIHNwb25zb3JlZC4NCj4NCj4gQmVu Lg0K From nobody Sun Oct 18 12:10:28 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 171A01ACE32; Sun, 18 Oct 2015 12:10:26 -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 tF_oo8tiV_RJ; Sun, 18 Oct 2015 12:10:24 -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 8E0A91ACE01; Sun, 18 Oct 2015 12:10:23 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-ce-5623ee9d0ec3 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3D.CA.27359.D9EE3265; Sun, 18 Oct 2015 21:10:21 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0248.002; Sun, 18 Oct 2015 21:10:21 +0200 From: Christer Holmberg To: Ben Campbell Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata Reported] RFC7315 (4474)] Thread-Index: AQHRCdcYpH++Me34ZEiyqo0HYkD7qJ5xnW2Q Date: Sun, 18 Oct 2015 19:10:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37B691E1@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37B62FC0@ESESSMB209.ericsson.se> <90429FC5-4199-4386-8CEE-F7F9E45420CE@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B6907F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B6907F@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.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM+Jvje7cd8phBk27dCzmd55mt1g6aQGr xdcfm9gcmD2WLPnJ5DFr5xOWAKYoLpuU1JzMstQifbsEroyr644xFuxTrlj5YSFzA+MJpS5G Tg4JAROJPZ2fmCFsMYkL99azdTFycQgJHGWU+LOknx0kISSwmFHiyXrpLkYODjYBC4nuf9og YREBJYnnzVtZQMLMAo4S09Zkg7QKC7QySjTv3sUO4ogItDFKbJg1gRGiwUji6tW3TCA2i4Cq xMm/79lAbF4BX4kNU1+zQCw+xihxftt5sIs4Bfwk9u9eA3YEI9B130+tAWtmFhCXuPVkPhPE 1QISS/ach/pAVOLl43+sELaSxIrtlxghrtOUWL9LH6JVUWJK90N2iL2CEidnPmGZwCg2C8nU WQgds5B0zELSsYCRZRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYBwd3PLbYAfjy+eOhxgF OBiVeHgfHFEKE2JNLCuuzD3EKM3BoiTO28z0IFRIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD o0Lruv3LZwpfZRN2P7fo+KEkHzmRysNbA33j+p3vLxC9ZuBZNKt7ri5PttUD57yjvpoOy2av UpCduuh659PFryPn3/vw+5lrxd0/c+/H3nzgJdby5EzZIj39F/8CdF/8U2oy/LewO+eRvcz7 y4rrT5XLqmh+Cv2SkNx3aNPs1I6jDrNfnVG4lKHEUpyRaKjFXFScCADxxN7uhAIAAA== Archived-At: Cc: DISPATCH list , SIPCORE Subject: Re: [sipcore] [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [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: Sun, 18 Oct 2015 19:10:26 -0000 SGksDQoNCkkndmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24sIC0wMSwgd2hlcmUgdGhlIGNhdGVn b3J5IGlzIGNoYW5nZWQgdG8gJ0luZm9ybWF0aW9uYWwnLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogZGlzcGF0Y2ggW21haWx0bzpk aXNwYXRjaC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcN ClNlbnQ6IDE4IE9jdG9iZXIgMjAxNSAyMTo1OQ0KVG86IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3Ry dW0uY29tPg0KQ2M6IERJU1BBVENIIGxpc3QgPGRpc3BhdGNoQGlldGYub3JnPjsgU0lQQ09SRSA8 c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIERyYWZ0IG5ldzogZHJh ZnQtaG9sbWJlcmctZGlzcGF0Y2gtcGFuaS1hYm5mLTAwIFt3YXM6IFtzaXBjb3JlXSBbVGVjaG5p Y2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDNzMxNSAoNDQ3NCldDQoNCkhpLA0KDQo+SWYgNzMxNSBp cyBpbmZvcm1hdGlvbmFsLCB3aHkgZG9lcyB0aGUgdXBkYXRlIG5lZWQgdG8gYmUgc3RhbmRhcmRz IHRyYWNrPw0KDQpHb29kIHBvaW50IC0gSSBndWVzcyBpdCBkb2Vzbid0IGhhdmUgdG8gOikNCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpPbiAxOCBPY3QgMjAxNSwgYXQgNjo0OSwgQ2hyaXN0 ZXIgSG9sbWJlcmcgd3JvdGU6DQoNCj4gSGksDQo+DQo+IEJhc2VkIG9uIEJlbuKAmXMgZ3VpZGFu Y2UsIEnigJl2ZSBzdWJtaXR0ZWQgYSBkcmFmdCB3aGljaCBtYWtlcyB0aGUgQUJORiANCj4gdXBk YXRlLg0KPg0KPiBOT1RFOiBBcyBSRkMgNzMxNSBpcyBhbiBJbmZvcm1hdGlvbmFsIFJGQywgSSBo YWQgdG8gYWRkIHRoZSBSRkMgYXMgYW4gDQo+IEluZm9ybWF0aXZlIHJlZmVyZW5jZSBpbiB0aGUg ZHJhZnQsIGluIG9yZGVyIHRvIHBhc3MgdGhlIElkbml0cyBjaGVjay4NCj4NCj4NCj4gQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWhvbG1iZXJnLWRpc3BhdGNoLXBhbmktYWJuZi0wMC50eHQN Cj4NCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBDaHJpc3RlciBIb2xtYmVy ZyBhbmQgcG9zdGVkIHRvIHRoZSANCj4gSUVURiByZXBvc2l0b3J5Lg0KPg0KPg0KPg0KPiBOYW1l OiAgICAgICAgICAgICAgICAgZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcGFuaS1hYm5mDQo+DQo+ IFJldmlzaW9uOiAgICAgICAgICAgIDAwDQo+DQo+IFRpdGxlOiAgICAgICAgICAgICAgICAgICAg UC1BY2Nlc3MtTmV0d29yay1JbmZvIEFCTkYgVXBkYXRlDQo+DQo+IERvY3VtZW50IGRhdGU6ICAg ICAgICAgICAgICAyMDE1LTEwLTE4DQo+DQo+IEdyb3VwOiAgICAgICAgICAgICAgICBJbmRpdmlk dWFsIFN1Ym1pc3Npb24NCj4NCj4gUGFnZXM6ICAgICAgICAgICAgICAgICA0DQo+DQo+IFVSTDog ICAgICAgICAgICANCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWhvbG1iZXJnLWRpc3BhdGNoLXBhbmktYWJuZg0KPiAtMDAudHh0DQo+DQo+IFN0YXR1czogICAg ICAgICANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaG9sbWJlcmct ZGlzcGF0Y2gtcGFuaS1hYm5mLw0KPg0KPiBIdG1saXplZDogICAgICAgDQo+IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1wYW5pLWFibmYtMDANCj4N Cj4NCj4NCj4NCj4NCj4gQWJzdHJhY3Q6DQo+DQo+IFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkMg NzMxNSwgYnkgbW9kaWZ5aW5nIHRoZSBleHRlbnNpb24tYWNjZXNzLQ0KPg0KPiBpbmZvIHBhcnQg b2YgdGhlIFAtQWNjZXNzLU5ldHdvcmstSW5mbyBoZWFkZXIgZmllbGQgQXVnbWVudGVkIEJhY2t1 cy0NCj4NCj4gTmF1ciBGb3JtIChBQk5GKS4NCj4NCj4NCj4gUmVnYXJkcywNCj4NCj4gQ2hyaXN0 ZXINCj4NCj4NCj4NCj4NCj4gRnJvbTogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGVyIA0KPiBIb2xtYmVyZw0KPiBTZW50OiAxOCBP Y3RvYmVyIDIwMTUgMTA6NTINCj4gVG86IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPg0K PiBDYzogRElTUEFUQ0ggbGlzdCA8ZGlzcGF0Y2hAaWV0Zi5vcmc+OyBTSVBDT1JFIDxzaXBjb3Jl QGlldGYub3JnPjsgDQo+IEN1bGxlbiBKZW5uaW5ncyA8Zmx1ZmZ5QGlpaS5jYT4NCj4gU3ViamVj dDogUmU6IFtzaXBjb3JlXSBbZGlzcGF0Y2hdIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBS RkM3MzE1DQo+ICg0NDc0KQ0KPg0KPiBIaSwNCj4NCj4gU28sIHNoYWxsIEkgYWRkcmVzcyB0aGUg ZHJhZnQgdG8gc29tZSBXRywgb3I/DQo+DQo+IGRyYWZ0LWhvbG1iZXJnLWRpc3BhdGNoID8NCj4N Cj4gUmVnYXJkcywNCj4NCj4gQ2hyaXN0ZXINCj4NCj4gU2VudCBmcm9tIG15IFdpbmRvd3MgUGhv bmUNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gRnJvbTogQmVuIENhbXBi ZWxsPG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+DQo+IFNlbnQ6IOKAjjE0L+KAjjEwL+KAjjIwMTUg MTc6MjENCj4gVG86IENocmlzdGVyIEhvbG1iZXJnPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20+DQo+IENjOiBDdWxsZW4gSmVubmluZ3M8bWFpbHRvOmZsdWZmeUBpaWkuY2E+ OyBESVNQQVRDSCANCj4gbGlzdDxtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmc+OyBTSVBDT1JFPG1h aWx0bzpzaXBjb3JlQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFtkaXNwYXRj aF0gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzczMTUNCj4gKDQ0NzQpDQo+IE9uIDgg T2N0IDIwMTUsIGF0IDIxOjAzLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4NCj4+IEhpIEN1 bGxlbiwNCj4+DQo+PiBTbywgeW91IGFyZSBzdWdnZXN0aW5nIGEgU0lQQ09SRSBkcmFmdCB0aGF0 IHVwZGF0ZXMgdGhlIEFCTkY/DQo+DQo+IFRoaXMgaXMgd2hlcmUgdGhlIGNoYWlycyB3aWxsIHBv aW50IG91dCB0aGF0IHNwZWNpYWwtcHVycG9zZSANCj4gZXh0ZW5zaW9ucyBhcmUgZ2VuZXJhbGx5 IG5vdCBpbiBzY29wZSBmb3Igc2lwY29yZSA6LSkgSWYgc28sIHRoaXMgDQo+IG1pZ2h0IGNvdWxk IGFsc28gYmUgZG9uZSBhcyBBRCBzcG9uc29yZWQuDQo+DQo+IEJlbi4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkaXNwYXRjaCBtYWlsaW5nIGxpc3QN CmRpc3BhdGNoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Rpc3BhdGNoDQo= From nobody Mon Oct 19 07:36:04 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 A3AB71A9120 for ; Mon, 19 Oct 2015 07:36:02 -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, T_FILL_THIS_FORM_SHORT=0.01, 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 1xVmUHEObQNO for ; Mon, 19 Oct 2015 07:36:00 -0700 (PDT) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id DF1BF1A914D for ; Mon, 19 Oct 2015 07:35:49 -0700 (PDT) X-AuditID: 12074413-f79bd6d000007ac2-72-5624ffc5de90 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id AC.18.31426.5CFF4265; Mon, 19 Oct 2015 10:35:49 -0400 (EDT) Received: from Paul-Kyzivats-MacBook-Pro.local (c-50-138-229-151.hsd1.ma.comcast.net [50.138.229.151]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id t9JEZlaE021531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 19 Oct 2015 10:35:49 -0400 From: Paul Kyzivat To: SIPCORE Message-ID: <5624FFC2.1030708@alum.mit.edu> Date: Mon, 19 Oct 2015 10:35:46 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------080005030706080803010007" X-Brightmail-Tracker: H4sIAAAAAAAAA2VTa0wTWRTOnU7bARlzKUiP1WCoqAmmsqjR/WEMPmLMrlF8YNwNggMd22I7 kE5rZPeHGMFEYnwlu0IRg6ZGRXZBFK1gorZqUiAVFyXERHattcYawyNLVILg3E55JP77zvnO d745585hFJp7ah1jERy8XeCselU8rVFvTDM8nkjf/cO1XvbHkc8tqmy02e3+QuWgX2etKeQc B3daTELm2n2zzB+Ct9SlV3IO+cZuK8vR8IYqFMcAXgmjJ0IqGadAd3+ThOMZDe5BUHHyAS0H 4xS89LYqSZUKZ8B57wRNcBJeD57/JxRViGGScSrU9uWRNIuXwj8dtxQE03gRlNcNUATPwfvB 1zuolGsSwV8TirZR4BxovFpNnUYJrhmUawYl41Vw4eZrhYwXwNHW2hheDZWBsPL7/Fo41v+H yiV9HWAtjFZsckXH3AcdXreKYA3WQ78vJEnJlPcRDAzcRXLwN4J75xooObiKoKX+o1qWJ0LX 8zo1IQAPU3Cs9riaWCBcDEF/rix4j2DoRTvliq34ZrgzKkZ4ObQHIjG/pxSMdE8o5KAZQWDs g3oq6B0dpF2xZX5qGotiskx3cyA63eQ7uKKLNULYLdtNb4+8STqcHIouJglvB0/dUMzsDAL3 +zfRPnF4HUR8YXrmhuvRwgaUylmdNoONs1hFvsggFnGCwNsNq5fZLI5lvNHZguS/L8mD2vyp XoQZpE9g+w6n79YouYNimc2L5jKUfg57eVxKzS4sMZaZOdFcYHdaedGL0iWzYPP1bqSjhRKB 1yezPX1SHWvkyn7j7SWTZfMYWq9lF7uXbNVgE+fgD/B8KW+fZOczjB7YMmKQaOdN/KH9Fqtj mqaYOC8CJl6XLPKCkbdzToe5gJxEgSjdBKESJN+jRM6KpZxNysrSDpSm07IFhMCEMDuFqbaT RxdBWmniJDZLuj1NgnSSU+qI1JiSGgcjaaSxg5umdOVoMdX15dSAf6T49/yKVz9teb6w/s/h wKNLxeGU1v5gqCZTkdHwJD/vxs5NK2qe3dFlVz/8y/PLfx9z5x0++6DOZzBcyu64v+vt1yP+ 5e+0V6o7u/ZeHNzTdqKxKf7rv/zKImabx/Tz+NM7S86VVpp2PM4u3KsNjW0PP6osaU/JywpV +Vt69LRo5rIyFHaR+wa+j0teTwQAAA== Archived-At: Subject: [sipcore] Requesting assist with expert review of media feature tag 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, 19 Oct 2015 14:36:02 -0000 This is a multi-part message in MIME format. --------------080005030706080803010007 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I'm the designated expert reviewer for IANA registration of new media feature tag values. (Often for use as sip caller capabilities.) I have a recent request that concerns me. I am inclined to reject it, but the decision is subjective, so I would like to have some discussion on it first. The request comes from 3gpp - it has had no action in ietf. It is for the media feature tag g.3gpp.nw-init-ussi, with semantics defined in 3GPP TS 24.390 ("Unstructured Supplementary Service Data (USSD) using IP Multimedia (IM) Core Network (CN) subsystem IMS; Stage 3”) It is the details of how this service is signaled in SIP that troubles me. I wrote this up in my initial response. A copy of that message is attached. (Including details of the request.) My key concerns from that are: - it establishes a media-less INVITE dialog, for the purpose of exchanging messages in the signaling, primarily using INFO. IMO this is inappropriate, for the same reason session-mode messaging via MESSAGE was rejected, in favor of MSRP. As I understand the service being provided, it is a specialized application of session mode instant messaging. - a new mechanism is introduced for passing alert indications, rather than reusing the defined mechanism of Alert-Info. (RFC3261 and RFC7462) My feeling is that these conflict with ietf standards and so the registration should be rejected. I would like to hear other thoughts on this, and in general on the appropriateness of the proposed mechanism as a SIP usage. Thanks, Paul --------------080005030706080803010007 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename="Attached Message" X-Account-Key: account2 X-Mozilla-Keys: $label5 Return-Path: pkyzivat@alum.mit.edu Received: from reszmta-po-07v.sys.comcast.net (LHLO reszmta-po-07v.sys.comcast.net) (96.114.154.199) by resmail-ch2-746v.sys.comcast.net with LMTP; Tue, 11 Aug 2015 18:49:12 +0000 (UTC) Received: from resimta-po-09v.sys.comcast.net ([96.114.154.137]) by reszmta-po-07v.sys.comcast.net with comcast id 3WUk1r0Cr2y7xtc01WpClF; Tue, 11 Aug 2015 18:49:12 +0000 Received: from alum-mailsec-relay-9.mit.edu ([18.7.68.29]) by resimta-po-09v.sys.comcast.net with comcast id 3WpC1r00n0dt8C201WpCC4; Tue, 11 Aug 2015 18:49:12 +0000 X-CAA-SPAM: 00000 X-Authority-Analysis: v=2.1 cv=V5iAqrTi c=1 sm=1 tr=0 a=MRj2BPNAhLswQ1TjTjGTrQ==:117 a=7QL2FU7yiJK4SgXnFvHnVg==:17 a=C_IRinGWAAAA:8 a=GGcpBh7Jt_oA:10 a=tHvJy1wsfNMA:10 a=IkcTkHD0fZMA:10 a=uRRa74qj2VoA:10 a=ajNGGDAxAAAA:8 a=-O5YPv7yAAAA:8 a=IbTIlpOe9FQTtO_szJEA:9 a=trRp6dBg4Et_V9g6:21 a=Xb9AXgB_Cb8U6XTZ:21 a=QEXdDO2ut3YA:10 a=BzzrXjz2il4A:10 a=SKcoPRk-sngA:10 Authentication-Results: resimta-po-09v.sys.comcast.net; dkim=pass header.d=comcast.net header.b=pFMOGl2x Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu [18.7.68.20]) by alum-mailsec-relay-9.mit.edu (8.14.7/8.12.8) with ESMTP id t7BIn9if018407 for ; Tue, 11 Aug 2015 14:49:11 -0400 X-AuditID: 12074414-f794f6d000007852-6b-55ca43a735ca Authentication-Results: symauth.service.identifier Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [69.252.207.34]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id E1.65.30802.7A34AC55; Tue, 11 Aug 2015 14:49:11 -0400 (EDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-02v.sys.comcast.net with comcast id 3WoW1r0022N9P4d01WpBNP; Tue, 11 Aug 2015 18:49:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-13v.sys.comcast.net with comcast id 3WpA1r00K3Ge9ey01WpAQF; Tue, 11 Aug 2015 18:49:11 +0000 Message-ID: <55CA43A5.7000002@alum.mit.edu> Date: Tue, 11 Aug 2015 14:49:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: iana-prot-param-comment@iana.org Subject: Re: [IANA #838391] Registration of media feature tag g.3gpp.nw-init-ussi References: <1f680cb2f1654ff1955f631ee466b432@xMail.etsihq.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1439318951; bh=alTIsd7R+uZKOWGKDAHT8g2fb2lUQmW9zTGipDEnfzs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pFMOGl2xOgZMFMGnHflRFIFFxW27EMODR3aYHoeWQUy7jBMkH3A1L/hfNE85MM8c9 Hh6NA7xKHQVFKLxCvwSeEYTk3ti7I0zRNvu/Vg40Nu4pTgxIWMUA6oxs6Ex7Gzdx0K ezonK+iGzJW/4u1Nr8wRaz1mIMv//mQ7Uf2Vo9R8bOya/+wMury0KinqDNCsys7RMa 75J9lU4J3h/AcSrM/e+NH/lLhMxb5NWuFOOnBOh5X95j1vjcHdAz7sA1Rb29dfQLiv fiAcqlQNyJ5WenS/gxQSXl0qjJhMwe+WxfnNvlKaMuvNkNUonfV+rviukvA2Oq45dx bT/fpxBavEDFQ== X-Brightmail-Tracker: H4sIAAAAAAAAA1VSfUhTURT3vve2XdeeXJ/abiuNVhE4ZqYlalGpKQkSCgkVST636zb3oby3 iZMioUAQCvujIG1RaCSBOZPANMiWUFNSMwiJEK0wNUENLRLL3ra09c/lnPM7vw8OF9LcW5kG khonERy8TStXMrmrw1r9/ZyB4uRmvy69zdsnOwqO/5pfoArBGeUhI7FZqomw93Cp0jzW2qmo uh5fM3ivnakDjeoGEAkx2o+7pgYVgRqgFNw7NCsLzTfjkfEOeQNQQg4NU3h5ZI0ONV6Ah1a/ KjaadysLTIDCIh3+0bEarBm0G7d6h+hALUeJ+JZvLTiPQ0Y81dpLhfajsf/mZ2kOYSzaha8u Bp1jUBHu9iz+NbsGcOvMp6BOJMrCsy+mgjo0SsO3uybpUL0dX3rcHCQw6D2De+qu0I2Aawrz aArjNIVx7gD6AUjgbS673s5bbCIx6EUD73AQQZ+eZLc4k4jR9QhIV+YUx2K7Qb8/wQcQBFoV i/L9xZyMrxbddh/YAiltHFt6cKCYiyqrNLrNvGg+J7hsRPQBDGltLDuWKWGskXfXEqFyHdoK Ga2a/d6y5wSHTLyTWAmpIsI6SkGFD2yDUIvZvGyJHS0QE6kpt9ic4TuRgUcZsFFJNqcCi6xY xdtFiym0NAAy4EPPWDsFVzo/SO/vJ5PtFMc4Kh1Eo2ZPBggoQDC7HBvC6/9qFMRrYlgQERHB qaRk0kH+xz+CaDij4ORKijhQhiYoOgvU0oFi2PksSVllcTg3ksxKISkppCkhGNLJ/4M0dSDP uqnEc+D8aG29k+won7N+UT6dM0ZRsvbxilz3cqEujzDmnmlLdrPpeXL3SGpjqe/shZY38G6B reL0RFtOVebakkLuNYxPLzUMFmQudJX0pRkMunrwOrVM/jP/oirj27wX0ikl6aNTr/Qv857d KLYe6fc079QnyycuF6V3aBnRzO9LpAWR/wMb8mXxZgMAAA== I have some concerns about this registration. I would like to hear from the submitter about these: The overall mechanism is to establish a media-less dialog, and use it as a signalng channel, using bodies in INVITE and BYE as well as INFO messages. This is dubious usage. Back when instant messaging was being defined for SIP there was a decision not to allow establishing a dialog where an IM session is conducted using SIP signaling messages. Instead, MSRP was defined to carry session-oriented messages. The MESSAGE method was still allowed, but only for "page mode" messaging. RFC 6086, defining INFO, doesn't consider the use of media-less dialogs established solely for exchanging INFO messages. But similar thinking would imply the inadvisability of doing so. What was the rationale for choosing this approach rather than say using MSRP? Then, in addition to using INFO, data is also being exchanged in the body of INVITE and BYE. What is the rationale for that, rather than simply using INFO? (I guess this is an optimization. Is it "worth it"?) Finally, I note that the message bodys can contain an element carrying an unsigned byte identifying the pattern, and that this is intended to determine how the receiving UE alerts the user. This seems to be a bypass of Alert-Info as the way of indicating alerting behavior. It is generally inappropriate to define a new proprietary mechanism when a standard mechanism can provide the same functionality. Notably RFC7462 provides a way to request a particular well known alert type, and it is extensible to any sort of special alert that 3GPP might have in mind. I'd like to hear back on these things before deciding whether this registration is valid. Thanks, Paul Kyzivat On 8/6/15 6:16 PM, Amanda Baber via RT wrote: > Hi Paul, > > This is the last of five requests from Frederic Firmin. We didn't receive a corresponding global feature-capability indicator request. > > thanks, > > Amanda Baber > IANA Senior Specialist > ICANN > > ===== > > Hi Amanda, > > Last one for today > > BR// Frederic > > > Media feature tag name: g.3gpp.nw-init-ussi > > ASN.1 identifier associated with feature tag: > > New assignment by IANA > > Summary of the media feature indicated by this feature tag: > > This feature-tag indicates support of user equipment procedures for the network initiated USSD over IMS. > > Values appropriate for use with this feature tag: > > > [X] 1. The feature tag is Boolean and may have values of > > TRUE or FALSE. A value of TRUE indicates an available > > capability. A value of FALSE indicates the capability > > is not available. > > > The feature tag is intended primarily for use in the following > > applications, protocols, services, or negotiation mechanisms: > > This feature-tag is most useful in a communications application, for describing the capabilities of a device, such as a phone or PDA > > Examples of typical use: > > Indicating that a mobile phone supports the network initiated USSD over IMS. > > Related standards or documents: > > 3GPP TS 24.390: "Unstructured Supplementary Service Data (USSD) using IP Multimedia (IM) Core Network (CN) subsystem IMS; Stage 3” V12.2.0 http://www.3gpp.org/dynareport/24390.htm > > Security considerations: > > Security considerations for this media feature-tag are discussed in subclause 12.1 of IETF RFC 3840 > > Name(s) & email address(es) of person(s) to contact for > > further information: Frederic Firmin frederic.firmin@etsi.org > > Intended usage: COMMON > > Author/Change controller: Frederic Firmin > --------------080005030706080803010007-- From nobody Mon Oct 19 22:54: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 BCA071A0A85 for ; Mon, 19 Oct 2015 22:54:46 -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 SC4zk1-juPEL for ; Mon, 19 Oct 2015 22:54:44 -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 014331A070E for ; Mon, 19 Oct 2015 22:54:43 -0700 (PDT) X-AuditID: c1b4fb3a-f79136d0000071e2-d9-5625d721f7f8 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 84.DA.29154.127D5265; Tue, 20 Oct 2015 07:54:42 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.87]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0248.002; Tue, 20 Oct 2015 07:54:41 +0200 From: Ivo Sedlacek To: Paul Kyzivat , SIPCORE Thread-Topic: [sipcore] Requesting assist with expert review of media feature tag Thread-Index: AQHRCnt+raJaHQDZt0yeY/gj3woXT55z4YTQ Date: Tue, 20 Oct 2015 05:54:41 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112A6319C@ESESSMB301.ericsson.se> References: <5624FFC2.1030708@alum.mit.edu> In-Reply-To: <5624FFC2.1030708@alum.mit.edu> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvja7SddUwg/uN/BYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJVxZml1wRy5inN3V7M1MO6Q7WLk5JAQMJFY sP8EC4QtJnHh3nq2LkYuDiGBo4wSq/Y0M0M4ixklHsyeyQRSxSagJzFxyxFWEFtEwEViSfcR ZhBbWCBIYvX0fVDxYIn1v7eyQ9hGElvXvAGLswioSvRs/soIYvMK+Eq8bjkD1iskoC3x49xX MJtTQEfi85YzYLsYBWQlrv7pBatnFhCXuPVkPhPEpQISS/acZ4awRSVePv7HCmErSlydvhyo hgOoXlNi/S59iFZFiSndD9kh1gpKnJz5hGUCo+gsJFNnIXTMQtIxC0nHAkaWVYyixanFxbnp RkZ6qUWZycXF+Xl6eaklmxiBMXJwy2+rHYwHnzseYhTgYFTi4X2QrhomxJpYVlyZe4hRmoNF SZy3melBqJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGXcd9QuIHAzc1NYe/DPueIve7QDnO oX12UwTH8lf8LAdipJ6vZXkf2jtrU9zTJQfF5m0UyDnmcq5iSVf09rdPdVhudWTt1tweGP5X 6fAlc5kUHZ6/OoveLuJzPnrLOT3m5f1d8e4G73L+CfrOm3hsQ+L05Rbb7kyYdGfbmbzgfsnp uobndd9tU2Ipzkg01GIuKk4EAKGD+/dyAgAA Archived-At: Subject: Re: [sipcore] Requesting assist with expert review of media feature tag 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: Tue, 20 Oct 2015 05:54:46 -0000 SGVsbG8gUGF1bCwNCg0KPiAtIGl0IGVzdGFibGlzaGVzIGEgbWVkaWEtbGVzcyBJTlZJVEUgZGlh bG9nLCBmb3IgdGhlIHB1cnBvc2Ugb2YgZXhjaGFuZ2luZyBtZXNzYWdlcyBpbiB0aGUgc2lnbmFs aW5nLCBwcmltYXJpbHkgdXNpbmcgSU5GTy4gSU1PIHRoaXMgaXMgaW5hcHByb3ByaWF0ZSwgZm9y IHRoZSBzYW1lIHJlYXNvbiBzZXNzaW9uLW1vZGUgDQo+IG1lc3NhZ2luZyB2aWEgTUVTU0FHRSB3 YXMgcmVqZWN0ZWQsIGluIGZhdm9yIG9mIE1TUlAuIEFzIEkgdW5kZXJzdGFuZCB0aGUgc2Vydmlj ZSBiZWluZyBwcm92aWRlZCwgaXQgaXMgYSBzcGVjaWFsaXplZCBhcHBsaWNhdGlvbiBvZiBzZXNz aW9uIG1vZGUgaW5zdGFudCBtZXNzYWdpbmcuDQoNCnRoZSBJTkZPIHBhY2thZ2UgaGFzIGFscmVh ZHkgYmVlbiByZWdpc3RlcmVkIGJ5IElBTkEgc28gSSB3b25kZXIgaG93IHdoeSB0aGF0IGlzIHF1 ZXN0aW9uZWQgbm93LiBJdCBoYXMgbm90aGluZyB0byBkbyB3aXRoIHRoZSBtZWRpYSBmZWF0dXJl IHRhZy4NCg0KPiAtIGEgbmV3IG1lY2hhbmlzbSBpcyBpbnRyb2R1Y2VkIGZvciBwYXNzaW5nIGFs ZXJ0IGluZGljYXRpb25zLCByYXRoZXIgdGhhbiByZXVzaW5nIHRoZSBkZWZpbmVkIG1lY2hhbmlz bSBvZiBBbGVydC1JbmZvLiAoUkZDMzI2MSBhbmQgUkZDNzQ2MikNCg0KVGhlIGFsZXJ0aW5nUGF0 dGVybiBpcyBhbiBhcHBsaWNhdGlvbiBsZXZlbCBpbmRpY2F0aW9uLg0KDQpUaGUgYWxlcnRpbmdQ YXR0ZXJuIGNhbiBwb3RlbnRpYWxseSBiZSBpbmNsdWRlZCBpbiBhbnkgVVNTSSBtZXNzYWdlLCBp bmNsdWRpbmcgdGhvc2Ugc2VudCBpbiBJTkZPIG1lc3NhZ2VzIHdoaWxlIEFsZXJ0LUluZm8gY2Fu bm90IGJlIGluIElORk8gcmVxdWVzdC4NCg0KS2luZCByZWdhcmRzDQoNCkl2byBTZWRsYWNlaw0K DQpUaGlzIENvbW11bmljYXRpb24gaXMgQ29uZmlkZW50aWFsLiBXZSBvbmx5IHNlbmQgYW5kIHJl Y2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0IHd3dy5lcmlj c3Nvbi5jb20vZW1haWxfZGlzY2xhaW1lcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIFBhdWwgS3l6aXZhdA0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDE5LCAyMDE1IDQ6MzYgUE0N ClRvOiBTSVBDT1JFDQpTdWJqZWN0OiBbc2lwY29yZV0gUmVxdWVzdGluZyBhc3Npc3Qgd2l0aCBl eHBlcnQgcmV2aWV3IG9mIG1lZGlhIGZlYXR1cmUgdGFnDQoNCkknbSB0aGUgZGVzaWduYXRlZCBl eHBlcnQgcmV2aWV3ZXIgZm9yIElBTkEgcmVnaXN0cmF0aW9uIG9mIG5ldyBtZWRpYSBmZWF0dXJl IHRhZyB2YWx1ZXMuIChPZnRlbiBmb3IgdXNlIGFzIHNpcCBjYWxsZXIgY2FwYWJpbGl0aWVzLikN Cg0KSSBoYXZlIGEgcmVjZW50IHJlcXVlc3QgdGhhdCBjb25jZXJucyBtZS4gSSBhbSBpbmNsaW5l ZCB0byByZWplY3QgaXQsIGJ1dCB0aGUgZGVjaXNpb24gaXMgc3ViamVjdGl2ZSwgc28gSSB3b3Vs ZCBsaWtlIHRvIGhhdmUgc29tZSBkaXNjdXNzaW9uIG9uIGl0IGZpcnN0Lg0KDQpUaGUgcmVxdWVz dCBjb21lcyBmcm9tIDNncHAgLSBpdCBoYXMgaGFkIG5vIGFjdGlvbiBpbiBpZXRmLiBJdCBpcyBm b3IgdGhlIG1lZGlhIGZlYXR1cmUgdGFnIGcuM2dwcC5udy1pbml0LXVzc2ksIHdpdGggc2VtYW50 aWNzIGRlZmluZWQgaW4gM0dQUCBUUyAyNC4zOTAgKCJVbnN0cnVjdHVyZWQgU3VwcGxlbWVudGFy eSBTZXJ2aWNlIERhdGEgKFVTU0QpIHVzaW5nIElQIE11bHRpbWVkaWEgKElNKSBDb3JlIE5ldHdv cmsgKENOKSBzdWJzeXN0ZW0gSU1TOyBTdGFnZSAz4oCdKQ0KDQpJdCBpcyB0aGUgZGV0YWlscyBv ZiBob3cgdGhpcyBzZXJ2aWNlIGlzIHNpZ25hbGVkIGluIFNJUCB0aGF0IHRyb3VibGVzIG1lLiBJ IHdyb3RlIHRoaXMgdXAgaW4gbXkgaW5pdGlhbCByZXNwb25zZS4gQSBjb3B5IG9mIHRoYXQgbWVz c2FnZSBpcyBhdHRhY2hlZC4gKEluY2x1ZGluZyBkZXRhaWxzIG9mIHRoZSByZXF1ZXN0LikgTXkg a2V5IGNvbmNlcm5zIGZyb20gdGhhdCBhcmU6DQoNCi0gaXQgZXN0YWJsaXNoZXMgYSBtZWRpYS1s ZXNzIElOVklURSBkaWFsb2csIGZvciB0aGUgcHVycG9zZSBvZiBleGNoYW5naW5nIG1lc3NhZ2Vz IGluIHRoZSBzaWduYWxpbmcsIHByaW1hcmlseSB1c2luZyBJTkZPLiBJTU8gdGhpcyBpcyBpbmFw cHJvcHJpYXRlLCBmb3IgdGhlIHNhbWUgcmVhc29uIHNlc3Npb24tbW9kZSBtZXNzYWdpbmcgdmlh IE1FU1NBR0Ugd2FzIHJlamVjdGVkLCBpbiBmYXZvciBvZiBNU1JQLiBBcyBJIHVuZGVyc3RhbmQg dGhlIHNlcnZpY2UgYmVpbmcgcHJvdmlkZWQsIGl0IGlzIGEgc3BlY2lhbGl6ZWQgYXBwbGljYXRp b24gb2Ygc2Vzc2lvbiBtb2RlIGluc3RhbnQgbWVzc2FnaW5nLg0KDQotIGEgbmV3IG1lY2hhbmlz bSBpcyBpbnRyb2R1Y2VkIGZvciBwYXNzaW5nIGFsZXJ0IGluZGljYXRpb25zLCByYXRoZXIgdGhh biByZXVzaW5nIHRoZSBkZWZpbmVkIG1lY2hhbmlzbSBvZiBBbGVydC1JbmZvLiAoUkZDMzI2MSBh bmQgUkZDNzQ2MikNCg0KTXkgZmVlbGluZyBpcyB0aGF0IHRoZXNlIGNvbmZsaWN0IHdpdGggaWV0 ZiBzdGFuZGFyZHMgYW5kIHNvIHRoZSByZWdpc3RyYXRpb24gc2hvdWxkIGJlIHJlamVjdGVkLiBJ IHdvdWxkIGxpa2UgdG8gaGVhciBvdGhlciB0aG91Z2h0cyBvbiB0aGlzLCBhbmQgaW4gZ2VuZXJh bCBvbiB0aGUgYXBwcm9wcmlhdGVuZXNzIG9mIHRoZSBwcm9wb3NlZCBtZWNoYW5pc20gYXMgYSBT SVAgdXNhZ2UuDQoNCglUaGFua3MsDQoJUGF1bA0KDQo= From nobody Tue Oct 20 08:48: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 74DD01A6EE4 for ; Tue, 20 Oct 2015 08:48:47 -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 9rMiw69OThuW for ; Tue, 20 Oct 2015 08:48:44 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21CA91A9100 for ; Tue, 20 Oct 2015 08:48:44 -0700 (PDT) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-09v.sys.comcast.net with comcast id XTns1r0042Fh1PH01TojUL; Tue, 20 Oct 2015 15:48:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-08v.sys.comcast.net with comcast id XToi1r00J3Ge9ey01Toi0m; Tue, 20 Oct 2015 15:48:43 +0000 To: Ivo Sedlacek , SIPCORE References: <5624FFC2.1030708@alum.mit.edu> <39B5E4D390E9BD4890E2B3107900610112A6319C@ESESSMB301.ericsson.se> From: Paul Kyzivat Message-ID: <56266259.2080504@alum.mit.edu> Date: Tue, 20 Oct 2015 11:48:41 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112A6319C@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445356123; bh=MTWtYUDDoIrOvFQKaa9NHUUUl468ihdbyJDM0EFjPE0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=hEReHwT5zIanSTiHsl84k4SkhBCFHuU22DXafhcJu/rwr29p8FN+LMd6fbqMXVPCE N/LEGNGV1D+Gt1gmrPuFk8XZPqShg9xOr4D3jEwRbxz4XH93yl/mkAzLCXI6NSnYjV p6k2A1ksf6uu1mhtYxahfMJEt2sQ7Ljb9btSLnindJLFQ89AbN3ucFb5+dK6llIwz3 WUnBodebedTSt3jbxqaDhCRB7OHIVTCUPdlyktKc7HpNjnrSPJfc/AZ9EamomUelNZ yvXkfwv1AAh/LcuuF70XEkTg9d01R9Fj9Vd/KeZ9wwOvM2WYETbKkXEcLGSWT4NFLf HKzwHJTHVEGUA== Archived-At: Subject: Re: [sipcore] Requesting assist with expert review of media feature tag 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: Tue, 20 Oct 2015 15:48:47 -0000 On 10/20/15 1:54 AM, Ivo Sedlacek wrote: > Hello Paul, > >> - it establishes a media-less INVITE dialog, for the purpose of exchanging messages in the signaling, primarily using INFO. IMO this is inappropriate, for the same reason session-mode >> messaging via MESSAGE was rejected, in favor of MSRP. As I understand the service being provided, it is a specialized application of session mode instant messaging. > > the INFO package has already been registered by IANA so I wonder how why that is questioned now. It has nothing to do with the media feature tag. I"m not questioning the general use of info packages. I'm questioning establishing an invite dialog usage with no intent to include media, with the sole intent of exchanging INFO messages as a form of session mode messaging. Way back during the time of SIMPLE, we decided that it was bad to establish a messaging *session* over the sip signaling channel. At the time that alternative was via MESSAGE, but using INFO doesn't change the argument. It is still bad. >> - a new mechanism is introduced for passing alert indications, rather than reusing the defined mechanism of Alert-Info. (RFC3261 and RFC7462) > > The alertingPattern is an application level indication. > > The alertingPattern can potentially be included in any USSI message, including those sent in INFO messages while Alert-Info cannot be in INFO request. I still don't understand. Is this alerting, in concept, any different from that which Alert-Info is intended for? Is it that you want to alert for individual messages within a messaging session? Thanks, Paul > Kind regards > > Ivo Sedlacek > > This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, October 19, 2015 4:36 PM > To: SIPCORE > Subject: [sipcore] Requesting assist with expert review of media feature tag > > I'm the designated expert reviewer for IANA registration of new media feature tag values. (Often for use as sip caller capabilities.) > > I have a recent request that concerns me. I am inclined to reject it, but the decision is subjective, so I would like to have some discussion on it first. > > The request comes from 3gpp - it has had no action in ietf. It is for the media feature tag g.3gpp.nw-init-ussi, with semantics defined in 3GPP TS 24.390 ("Unstructured Supplementary Service Data (USSD) using IP Multimedia (IM) Core Network (CN) subsystem IMS; Stage 3”) > > It is the details of how this service is signaled in SIP that troubles me. I wrote this up in my initial response. A copy of that message is attached. (Including details of the request.) My key concerns from that are: > > - it establishes a media-less INVITE dialog, for the purpose of exchanging messages in the signaling, primarily using INFO. IMO this is inappropriate, for the same reason session-mode messaging via MESSAGE was rejected, in favor of MSRP. As I understand the service being provided, it is a specialized application of session mode instant messaging. > > - a new mechanism is introduced for passing alert indications, rather than reusing the defined mechanism of Alert-Info. (RFC3261 and RFC7462) > > My feeling is that these conflict with ietf standards and so the registration should be rejected. I would like to hear other thoughts on this, and in general on the appropriateness of the proposed mechanism as a SIP usage. > > Thanks, > Paul > From nobody Tue Oct 20 11:17: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 0B29A1A8AE4 for ; Tue, 20 Oct 2015 11:17:35 -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 eXCdE9Bq3jmA for ; Tue, 20 Oct 2015 11:17:33 -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 415D11A90F4 for ; Tue, 20 Oct 2015 11:16:55 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-ff-56268515b3aa Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0B.F1.05274.51586265; Tue, 20 Oct 2015 20:16:53 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Tue, 20 Oct 2015 20:16:53 +0200 From: Christer Holmberg To: Paul Kyzivat , Ivo Sedlacek , SIPCORE Thread-Topic: [sipcore] Requesting assist with expert review of media feature tag Thread-Index: AQHRCnt+3thu4ZdorkqaFfJUCEck7p5zwSGAgACl9oCAAEeAYA== Date: Tue, 20 Oct 2015 18:16:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37B7D9A9@ESESSMB209.ericsson.se> References: <5624FFC2.1030708@alum.mit.edu> <39B5E4D390E9BD4890E2B3107900610112A6319C@ESESSMB301.ericsson.se> <56266259.2080504@alum.mit.edu> In-Reply-To: <56266259.2080504@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.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvja5oq1qYQetrJYsVGw6wWnz9sYnN gcnj7/sPTB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp433WXrWCTXsX6/2fZGhhn6HYxcnJICJhI 3N92hw3CFpO4cG89kM3FISRwlFFi49Z3TBDOYkaJoxPuMHcxcnCwCVhIdP/TBmkQESiQ2NS0 jQnEFhYIklg9fR8rRDxYYv3vrewQtpPE7V9HwGpYBFQlTm09xAYyhlfAV2LGRH6QsJDAREaJ JS/NQGxOAR2JuXPbwFoZge75fmoNWCuzgLjErSfzmSDuFJBYsuc8M4QtKvHy8T9WCFtJYu3h 7Swg45kFNCXW79KHaFWUmNL9EGwkr4CgxMmZT1gmMIrOQjJ1FkLHLCQds5B0LGBkWcUoWpxa nJSbbmSsl1qUmVxcnJ+nl5dasokRGCEHt/xW3cF4+Y3jIUYBDkYlHt4H6aphQqyJZcWVuYcY pTlYlMR5m5kehAoJpCeWpGanphakFsUXleakFh9iZOLglGpgdLHnmmEusStpwbPAUxulJ76Q 3Zz60XrDTcMnQqr3bfdeWH6iYUpjaQFXcG2OqWxen8aPy/7eTxR4g9iUvqVWffVcdfyMZuOE D1XXjv64nzijh2OG5M2z3w4+ljFXiObM3V5wxGRG+KQZK0W/5m4wNnt0weGU5OvijqU+gqoX NiUsSHPubeubosRSnJFoqMVcVJwIACdJpkNxAgAA Archived-At: Subject: Re: [sipcore] Requesting assist with expert review of media feature tag 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: Tue, 20 Oct 2015 18:17:35 -0000 SGksDQoNCj4+PiAtIGl0IGVzdGFibGlzaGVzIGEgbWVkaWEtbGVzcyBJTlZJVEUgZGlhbG9nLCBm b3IgdGhlIHB1cnBvc2Ugb2YgDQo+Pj4gZXhjaGFuZ2luZyBtZXNzYWdlcyBpbiB0aGUgc2lnbmFs aW5nLCBwcmltYXJpbHkgdXNpbmcgSU5GTy4gSU1PIHRoaXMgaXMgaW5hcHByb3ByaWF0ZSwgZm9y IHRoZSBzYW1lIHJlYXNvbiANCj4+PiBzZXNzaW9uLW1vZGUgbWVzc2FnaW5nIHZpYSBNRVNTQUdF IHdhcyByZWplY3RlZCwgaW4gZmF2b3Igb2YgTVNSUC4gQXMgSSB1bmRlcnN0YW5kIHRoZSBzZXJ2 aWNlIGJlaW5nIHByb3ZpZGVkLCBpdCBpcyBhIHNwZWNpYWxpemVkIGFwcGxpY2F0aW9uIG9mIHNl c3Npb24gbW9kZSBpbnN0YW50IG1lc3NhZ2luZy4NCj4+DQo+PiB0aGUgSU5GTyBwYWNrYWdlIGhh cyBhbHJlYWR5IGJlZW4gcmVnaXN0ZXJlZCBieSBJQU5BIHNvIEkgd29uZGVyIGhvdyB3aHkgdGhh dCBpcyBxdWVzdGlvbmVkIG5vdy4gSXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGUgbWVkaWEg ZmVhdHVyZSB0YWcuDQo+DQo+IEkibSBub3QgcXVlc3Rpb25pbmcgdGhlIGdlbmVyYWwgdXNlIG9m IGluZm8gcGFja2FnZXMuIEknbSBxdWVzdGlvbmluZyBlc3RhYmxpc2hpbmcgYW4gaW52aXRlIGRp YWxvZyB1c2FnZSB3aXRoIG5vIGludGVudCB0byBpbmNsdWRlDQo+IG1lZGlhLCB3aXRoIHRoZSBz b2xlIGludGVudCBvZiBleGNoYW5naW5nIElORk8gbWVzc2FnZXMgYXMgYSBmb3JtIG9mIHNlc3Np b24gbW9kZSBtZXNzYWdpbmcuIFdheSBiYWNrIGR1cmluZyB0aGUgdGltZSBvZiBTSU1QTEUsIHdl IA0KPiBkZWNpZGVkIHRoYXQgaXQgd2FzIGJhZCB0byBlc3RhYmxpc2ggYSBtZXNzYWdpbmcgKnNl c3Npb24qIG92ZXIgdGhlIHNpcCBzaWduYWxpbmcgY2hhbm5lbC4gQXQgdGhlIHRpbWUgdGhhdCBh bHRlcm5hdGl2ZSB3YXMgdmlhIE1FU1NBR0UsIGJ1dCANCj4gdXNpbmcgSU5GTyBkb2Vzbid0IGNo YW5nZSB0aGUgYXJndW1lbnQuIEl0IGlzIHN0aWxsIGJhZC4NCg0KSSB0aGluayB0aGlzIGlzc3Vl IHNob3VsZCBoYXZlIGJlZW4gcmFpc2VkIHdoZW4gdGhlIEluZm8gcGFja2FnZSB3YXMgcmVnaXN0 ZXJlZC4gVGhhdCdzIHdoZW4gb25lIHNob3VsZCBsb29rIGF0IGhvdyB0aGUgSW5mbyBQYWNrYWdl IGlzIGdvaW5nIHRvIGJlIHVzZWQgZXRjLiBJIGRvbid0IHRoaW5rIGl0J3MgZmFpciB0byByZWpl Y3QgdGhlIG1lZGlhIGZlYXR1cmUgdGFnIHJlZ2lzdHJhdGlvbiBvbiBzdWNoIGdyb3VuZHMgYXQg dGhpcyBwb2ludC4NCg0KSW4gbXkgb3BpbmlvbiBpdCdzIGFib3V0IHdoZXRoZXIgdGhlIG1lZGlh IGZlYXR1cmUgdGFnIHNlbWFudGljcyBpcyBhbGlnbmVkIHdpdGggdGhlIHJ1bGVzIGZvciBhIG1l ZGlhIGZlYXR1cmUgdGFnLiBJbiBteSBvcGluaW9uIGl0IGlzLCBhcyBpdCBvbmx5IGluZGljYXRl cyBzdXBwb3J0IG9mIGEgZmVhdHVyZS4gSXQgZG9lcyBOT1QgaW5kaWNhdGUgZG8td2hhdC1JLW1l YW4sIGl0IGRvZXMgTk9UIGFzc3VtZSBhbnl0aGluZyBmcm9tIHRoZSByZW1vdGUgcGFydHkgZXRj Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoNCj4+IC0gYSBuZXcgbWVjaGFuaXNt IGlzIGludHJvZHVjZWQgZm9yIHBhc3NpbmcgYWxlcnQgaW5kaWNhdGlvbnMsIHJhdGhlciANCj4+ IHRoYW4gcmV1c2luZyB0aGUgZGVmaW5lZCBtZWNoYW5pc20gb2YgQWxlcnQtSW5mby4gKFJGQzMy NjEgYW5kIA0KPj4gUkZDNzQ2MikNCj4NCj4gVGhlIGFsZXJ0aW5nUGF0dGVybiBpcyBhbiBhcHBs aWNhdGlvbiBsZXZlbCBpbmRpY2F0aW9uLg0KPg0KPiBUaGUgYWxlcnRpbmdQYXR0ZXJuIGNhbiBw b3RlbnRpYWxseSBiZSBpbmNsdWRlZCBpbiBhbnkgVVNTSSBtZXNzYWdlLCBpbmNsdWRpbmcgdGhv c2Ugc2VudCBpbiBJTkZPIG1lc3NhZ2VzIHdoaWxlIEFsZXJ0LUluZm8gY2Fubm90IGJlIGluIElO Rk8gcmVxdWVzdC4NCg0KSSBzdGlsbCBkb24ndCB1bmRlcnN0YW5kLiBJcyB0aGlzIGFsZXJ0aW5n LCBpbiBjb25jZXB0LCBhbnkgZGlmZmVyZW50IGZyb20gdGhhdCB3aGljaCBBbGVydC1JbmZvIGlz IGludGVuZGVkIGZvcj8NCg0KSXMgaXQgdGhhdCB5b3Ugd2FudCB0byBhbGVydCBmb3IgaW5kaXZp ZHVhbCBtZXNzYWdlcyB3aXRoaW4gYSBtZXNzYWdpbmcgc2Vzc2lvbj8NCg0KCVRoYW5rcywNCglQ YXVsDQoNCj4gS2luZCByZWdhcmRzDQo+DQo+IEl2byBTZWRsYWNlaw0KPg0KPiBUaGlzIENvbW11 bmljYXRpb24gaXMgQ29uZmlkZW50aWFsLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwg b24gDQo+IHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdCB3d3cuZXJpY3Nzb24uY29t L2VtYWlsX2Rpc2NsYWltZXINCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFBhdWwgDQo+IEt5eml2YXQNCj4gU2VudDogTW9uZGF5LCBPY3RvYmVyIDE5LCAyMDE1IDQ6MzYg UE0NCj4gVG86IFNJUENPUkUNCj4gU3ViamVjdDogW3NpcGNvcmVdIFJlcXVlc3RpbmcgYXNzaXN0 IHdpdGggZXhwZXJ0IHJldmlldyBvZiBtZWRpYSANCj4gZmVhdHVyZSB0YWcNCj4NCj4gSSdtIHRo ZSBkZXNpZ25hdGVkIGV4cGVydCByZXZpZXdlciBmb3IgSUFOQSByZWdpc3RyYXRpb24gb2YgbmV3 IG1lZGlhIA0KPiBmZWF0dXJlIHRhZyB2YWx1ZXMuIChPZnRlbiBmb3IgdXNlIGFzIHNpcCBjYWxs ZXIgY2FwYWJpbGl0aWVzLikNCj4NCj4gSSBoYXZlIGEgcmVjZW50IHJlcXVlc3QgdGhhdCBjb25j ZXJucyBtZS4gSSBhbSBpbmNsaW5lZCB0byByZWplY3QgaXQsIGJ1dCB0aGUgZGVjaXNpb24gaXMg c3ViamVjdGl2ZSwgc28gSSB3b3VsZCBsaWtlIHRvIGhhdmUgc29tZSBkaXNjdXNzaW9uIG9uIGl0 IGZpcnN0Lg0KPg0KPiBUaGUgcmVxdWVzdCBjb21lcyBmcm9tIDNncHAgLSBpdCBoYXMgaGFkIG5v IGFjdGlvbiBpbiBpZXRmLiBJdCBpcyBmb3IgDQo+IHRoZSBtZWRpYSBmZWF0dXJlIHRhZyBnLjNn cHAubnctaW5pdC11c3NpLCB3aXRoIHNlbWFudGljcyBkZWZpbmVkIGluIA0KPiAzR1BQIFRTIDI0 LjM5MCAoIlVuc3RydWN0dXJlZCBTdXBwbGVtZW50YXJ5IFNlcnZpY2UgRGF0YSAoVVNTRCkgdXNp bmcgDQo+IElQIE11bHRpbWVkaWEgKElNKSBDb3JlIE5ldHdvcmsgKENOKSBzdWJzeXN0ZW0gSU1T OyBTdGFnZSAz4oCdKQ0KPg0KPiBJdCBpcyB0aGUgZGV0YWlscyBvZiBob3cgdGhpcyBzZXJ2aWNl IGlzIHNpZ25hbGVkIGluIFNJUCB0aGF0IHRyb3VibGVzIG1lLiBJIHdyb3RlIHRoaXMgdXAgaW4g bXkgaW5pdGlhbCByZXNwb25zZS4gQSBjb3B5IG9mIHRoYXQgbWVzc2FnZSBpcyBhdHRhY2hlZC4g KEluY2x1ZGluZyBkZXRhaWxzIG9mIHRoZSByZXF1ZXN0LikgTXkga2V5IGNvbmNlcm5zIGZyb20g dGhhdCBhcmU6DQo+DQo+IC0gaXQgZXN0YWJsaXNoZXMgYSBtZWRpYS1sZXNzIElOVklURSBkaWFs b2csIGZvciB0aGUgcHVycG9zZSBvZiBleGNoYW5naW5nIG1lc3NhZ2VzIGluIHRoZSBzaWduYWxp bmcsIHByaW1hcmlseSB1c2luZyBJTkZPLiBJTU8gdGhpcyBpcyBpbmFwcHJvcHJpYXRlLCBmb3Ig dGhlIHNhbWUgcmVhc29uIHNlc3Npb24tbW9kZSBtZXNzYWdpbmcgdmlhIE1FU1NBR0Ugd2FzIHJl amVjdGVkLCBpbiBmYXZvciBvZiBNU1JQLiBBcyBJIHVuZGVyc3RhbmQgdGhlIHNlcnZpY2UgYmVp bmcgcHJvdmlkZWQsIGl0IGlzIGEgc3BlY2lhbGl6ZWQgYXBwbGljYXRpb24gb2Ygc2Vzc2lvbiBt b2RlIGluc3RhbnQgbWVzc2FnaW5nLg0KPg0KPiAtIGEgbmV3IG1lY2hhbmlzbSBpcyBpbnRyb2R1 Y2VkIGZvciBwYXNzaW5nIGFsZXJ0IGluZGljYXRpb25zLCByYXRoZXIgDQo+IHRoYW4gcmV1c2lu ZyB0aGUgZGVmaW5lZCBtZWNoYW5pc20gb2YgQWxlcnQtSW5mby4gKFJGQzMyNjEgYW5kIA0KPiBS RkM3NDYyKQ0KPg0KPiBNeSBmZWVsaW5nIGlzIHRoYXQgdGhlc2UgY29uZmxpY3Qgd2l0aCBpZXRm IHN0YW5kYXJkcyBhbmQgc28gdGhlIHJlZ2lzdHJhdGlvbiBzaG91bGQgYmUgcmVqZWN0ZWQuIEkg d291bGQgbGlrZSB0byBoZWFyIG90aGVyIHRob3VnaHRzIG9uIHRoaXMsIGFuZCBpbiBnZW5lcmFs IG9uIHRoZSBhcHByb3ByaWF0ZW5lc3Mgb2YgdGhlIHByb3Bvc2VkIG1lY2hhbmlzbSBhcyBhIFNJ UCB1c2FnZS4NCj4NCj4gCVRoYW5rcywNCj4gCVBhdWwNCj4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBj b3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNv cmUNCg== From nobody Tue Oct 20 17:27:30 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 4FE231ACE7A for ; Tue, 20 Oct 2015 17:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 caaqHIyv1F-g for ; Tue, 20 Oct 2015 17:27:25 -0700 (PDT) Received: from smtp117.ord1c.emailsrvr.com (smtp117.ord1c.emailsrvr.com [108.166.43.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F00121ACE71 for ; Tue, 20 Oct 2015 17:27:24 -0700 (PDT) Received: from smtp15.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp15.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 4CF6F3801D7; Tue, 20 Oct 2015 20:27:24 -0400 (EDT) Received: by smtp15.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 9CE89380207; Tue, 20 Oct 2015 20:27:23 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.119.195] ([UNAVAILABLE]. [128.107.241.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.4.2); Wed, 21 Oct 2015 00:27:24 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_AD143B75-ABB3-4DBB-950B-BB105E1540B4" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B346AB@ESESSMB209.ericsson.se> Date: Tue, 20 Oct 2015 17:06:58 -0700 Message-Id: References: <7594FB04B1934943A5C02806D1A2204B37AC0CF1@ESESSMB209.ericsson.se> <3308F2DE-08F1-46A0-BC01-2445627BAD53@iii.ca> <56031836.3080407@nostrum.com> <4E205A3B-F608-48D3-9DA5-D2220A97D953@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37AE6750@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B346AB@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.2104) Archived-At: Cc: DISPATCH list , Ben Campbell , SIPCORE 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, 21 Oct 2015 00:27:29 -0000 --Apple-Mail=_AD143B75-ABB3-4DBB-950B-BB105E1540B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I had not really thought about where it should be done but seem like a = trivial draft that updates would be better than an errata for this. But = when in doubt, Dispatch seems like a fine place to send it to start.=20 > On Oct 8, 2015, at 7:03 PM, Christer Holmberg = wrote: >=20 > Hi Cullen, >=20 > So, you are suggesting a SIPCORE draft that updates the ABNF? >=20 > Regards, >=20 > Christer=20 >=20 > Sent from my Windows Phone > From: Cullen Jennings > Sent: =E2=80=8E08/=E2=80=8E10/=E2=80=8E2015 23:17 > To: Christer Holmberg > Cc: Ben Campbell ; SIPCORE = ; DISPATCH list > Subject: Re: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 = (4474) >=20 >=20 > My 2 cents is still more appropriate to fix it with a draft that = epodes it not an Errata. Imagine an SBC or Firewall that is checking = the SIP syntax using the ABNF. The odds of them seeing this change and = implementing it much better with an RFC than an errata. Total work = either way is minimal.=20 >=20 >=20 > > On Sep 30, 2015, at 9:12 AM, Christer Holmberg = > = wrote: > >=20 > > Hi, > >=20 > >> (+sipcore, dispatch) > >> (as individual) > >>=20 > >> I just realized this discussion did not include the sipcore or = dispatch lists, and probably should. > >>=20 > >> Recap: Christer proposed an errata (4474) to RFC 7315. It proposes = the following change: > >>=20 > >>> Section 5.4 says: > >>>=20 > >>> extension-access-info =3D gen-value > >>>=20 > >>> It should say: > >>>=20 > >>> extension-access-info =3D generic-param > >>=20 > >> The generic-param construction allows the NAME =3D VALUE syntax as = in the TS 24.229 extension Jean mentioned below. > >>=20 > >> Keeping in mind the RFC in question was for 3GPP: Is anyone aware = of implementations of 7315 that would be broken > >> by this? =46rom Jean's example, it looks like 3GPP had already = assumed generic-param. > >=20 > > Correct. > >=20 > > Also, comparing RFC 3455 and RFC 7315, *all but one* of the new = access-info parameter values that were added in RFC 7315 follow the = generic-param syntax. So, it seems like we in IETF also assumed = generic-param when we did RFC 7315 (and/or we were not concerned about = parser issues), but nobody noticed the ABNF issue. > >=20 > > And, as I said earlier, I am pretty sure this header is mostly = (only?) used in 3GPP environments, and nobody in 3GPP objected to the = change I am now suggesting. It was discussed in 3GPP, and the outcome = was to file the errata. > >=20 > > Finally, as Jean indicated, 3GPP has defined a new value, = daylight-saving-time, which also uses the generic-param syntax. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > On 23 Sep 2015, at 16:23, A. Jean Mahoney wrote: > >=20 > >> FWIW - TS 24.229, which defines the values for access-info, = considers=20 > >> extension-access-info to be a generic-param, and not a gen-value as=20= > >> specified RFC7315. 3GPP has defined one extension so far (7.2A.4): > >>=20 > >>=20 > >> daylight-saving-time =3D "daylight-saving-time" EQUAL quoted-string > >>=20 > >> TS 124 229 - V12.9.0 - Digital cellular telecommunications system=20= > >> (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; = IP=20 > >> multimedia call control protocol based on Session Initiation = Protocol=20 > >> (SIP) and Session Description Protocol (SDP); Stage 3 (3GPP TS = 24.229=20 > >> version 12.9.0 Release 12) The daylight-saving-time is an instance = of=20 > >> generic-param from the current extension-access-info component of = the=20 > >> P- Access-Network-Info header field defined in RFC > >> 7315 [52]. > >>=20 > >>=20 > >> Jean > >>=20 > >>=20 > >>=20 > >> 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=20 > >>> Christer is proposing but I don't see how you can change it now. = This=20 > >>> change would break existing parsers that checked this. That does = not=20 > >>> seem like an errata level thing to me. > >>>=20 > >>>=20 > >>>> On Sep 21, 2015, at 10:30 AM, Ben Campbell > wrote: > >>>>=20 > >>>> sipcore and dispatch chairs: > >>>>=20 > >>>> Do you have any concerns about accepting Christer's errata? (I = note=20 > >>>> RFC 7315 was an orphaned sipping draft progressed as AD = sponsored.) > >>>>=20 > >>>> Ben. > >>>>=20 > >>>> Forwarded message: > >>>>=20 > >>>>> 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 > >>>>>=20 > >>>>> Any news on this? > >>>>>=20 > >>>>> Regards, > >>>>>=20 > >>>>> Christer > >>>>>=20 > >>>>> From: sipcore [mailto:sipcore-bounces@ietf.org = ] On Behalf Of=20 > >>>>> Christer Holmberg > >>>>> Sent: 14. syyskuuta 2015 23:24 > >>>>> To: Ben Campbell > >>>>> Cc: sipcore@ietf.org > >>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 = (4474) > >>>>>=20 > >>>>> Hi Ben, > >>>>>=20 > >>>>> I am pretty sure generic-param was the original intention. The=20= > >>>>> majority of all existing value follow the generic-param syntax, = and=20 > >>>>> I can't think of any reason why new values would not follow the=20= > >>>>> same syntax. That is how it works for other header fields too. > >>>>>=20 > >>>>> I think this is due to a mistake, where someone thought that=20 > >>>>> extension-access-info represents the actual parameter name, and=20= > >>>>> therefor only a value (gen-value) is needed. But,=20 > >>>>> extension-access-info represents the whole rule (name AND = value),=20 > >>>>> why generic-param is needed :) > >>>>>=20 > >>>>> Regards, > >>>>>=20 > >>>>> Christer > >>>>>=20 > >>>>> Sent from my Windows Phone > >>>>> ________________________________ > >>>>> From: Ben Campbell> > >>>>> Sent: =E2=80=8E14/=E2=80=8E09/=E2=80=8E2015 21:31 > >>>>> To: Christer Holmberg> > >>>>> Cc: sipcore@ietf.org = > > >>>>> Subject: Re: [sipcore] [Technical Errata Reported] RFC7315 = (4474)=20 > >>>>> Hi Christer, > >>>>>=20 > >>>>> Is it your understanding that the use of generic-param was the=20= > >>>>> actual intention at the time 7315 was published? Or was = gen-value=20 > >>>>> the original intention, but we now think that it should have = been=20 > >>>>> generic-param? > >>>>>=20 > >>>>> Thanks! > >>>>>=20 > >>>>> Ben. > >>>>>=20 > >>>>> On 14 Sep 2015, at 6:22, Christer Holmberg wrote: > >>>>>=20 > >>>>>> FYI, > >>>>>>=20 > >>>>>> I've now submitted the errata. > >>>>>>=20 > >>>>>> Regards, > >>>>>>=20 > >>>>>> Christer > >>>>>>=20 > >>>>>> -----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) > >>>>>>=20 > >>>>>> The following errata report has been submitted for RFC7315,=20 > >>>>>> "Private Header (P-Header) Extensions to the Session Initiation=20= > >>>>>> Protocol > >>>>>> (SIP) > >>>>>> for the 3GPP". > >>>>>>=20 > >>>>>> -------------------------------------- > >>>>>> You may review the report below and at: > >>>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D7315&eid=3D4474= > >>>>>>=20 > >>>>>> -------------------------------------- > >>>>>> Type: Technical > >>>>>> Reported by: Christer Holmberg > >>>>>> >>>>>> com>> > >>>>>>=20 > >>>>>> Section: 5.4 > >>>>>>=20 > >>>>>> Original Text > >>>>>> ------------- > >>>>>> extension-access-info =3D gen-value > >>>>>>=20 > >>>>>> Corrected Text > >>>>>> -------------- > >>>>>> extension-access-info =3D generic-param > >>>>>>=20 > >>>>>> Notes > >>>>>> ----- > >>>>>> Most of the pre-defined access-info values are following the=20 > >>>>>> generic-param syntax. New access-info values (extensions) = should=20 > >>>>>> also be allowed to follow the generic-param syntax, in order to=20= > >>>>>> allow both for a name and value of the extension. > >>>>>>=20 > >>>>>> Instructions: > >>>>>> ------------- > >>>>>> This erratum is currently posted as "Reported". If necessary,=20= > >>>>>> please use "Reply All" to discuss whether it should be verified = or=20 > >>>>>> rejected. > >>>>>> When a decision is reached, the verifying party (IESG) can log = in=20 > >>>>>> 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 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 > >>>>>>=20 > >>>>>> _______________________________________________ > >>>>>> 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 = > >=20 > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch = --Apple-Mail=_AD143B75-ABB3-4DBB-950B-BB105E1540B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

I had not really thought = about where it should be done but seem like a trivial draft that updates = would be better than an errata for this.  But when in doubt, = Dispatch seems like a fine place to send it to start. 

On Oct 8, 2015, at 7:03 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi= Cullen,

So, you are suggesting a SIPCORE = draft that updates the ABNF?

Regards,

Christer 

Sent from my Windows Phone
From: Cullen Jennings
Sent: =E2=80=8E08/=E2=80=8E10/=E2=80=8E2015 23:17
To: Christer = Holmberg
Cc: Ben Campbell; SIPCORE; DISPATCH list
Subject: Re: [dispatch] [sipcore] [Technical Errata Reported] RFC7315 = (4474)


My 2 cents is still more appropriate = to fix it with a draft that epodes  it not an Errata. Imagine an = SBC or Firewall that is checking the SIP syntax using the ABNF. The odds = of them seeing this change and implementing it much better with an RFC = than an errata. Total work either way is minimal. 


> On Sep 30, 2015, at 9:12 AM, Christer = Holmberg <christer.holmberg@ericsson.com> wrote:
> 
> Hi,
> 
>> (+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  =3D gen-value
>>> 
>>> It should = say:
>>> 
>>> = extension-access-info  =3D generic-param
>> 
>> The generic-param = construction allows the NAME =3D 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? =46rom Jean's example, it looks like 3GPP = had already assumed generic-param.
> 
> Correct.
> 
> = Also, comparing RFC 3455 and RFC 7315, *all but one* of the new = access-info parameter values that were added in RFC 7315 follow the = generic-param syntax.  So, it seems like we in IETF also assumed = generic-param when we did RFC 7315 (and/or we were not concerned about = parser issues), but nobody noticed the ABNF issue.
> 
> And, as I said earlier, I am = pretty sure this header is mostly (only?) used in 3GPP environments, and = nobody in 3GPP objected to the change I am now suggesting. It was = discussed in 3GPP, and the outcome was to file the errata.
> 
> Finally, as Jean indicated, = 3GPP has defined a new value, daylight-saving-time, which also uses the = generic-param syntax.
> 
> = Regards,
> 
> Christer
> 
> 
> 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 =3D = "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 = <ben@nostrum.com> = 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 <christer.holmberg@ericsson.com>
>>>>> To: Ben Campbell <ben@nostrum.com>
>>>>> Cc: sipcore@ietf.org <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<mailto:ben@nostrum.com>
>>>>> Sent: =E2=80=8E14/=E2=80=8E09/=E2=80=8E201= 5 21:31
>>>>> To: Christer Holmberg<mailto:christer.holmberg@ericsson.com>
>>>>> Cc: sipcore@ietf.org<mailto: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<mailto:r.jesske@telekom.de>;
>>>>>> drage@alcatel-lucent.com<mailto:drage@alcatel-lucent.com>;
>>>>>> Christer Holmberg;
>>>>>> iesg@ietf.org<mailto:iesg@ietf.org>
>>>>>> Cc: Christer Holmberg;
>>>>>> rfc-editor@rfc-editor.org<mailto: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=3D= 4474
>>>>>> 
>>>>>> = --------------------------------------
>>>>>> Type: Technical
>>>>>> Reported by: Christer Holmberg
>>>>>> <christer.holmberg@ericsson.com<mailto: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 change the status and edit the = report, if necessary.
>>>>>> 
>>>>>> = --------------------------------------
>>>>>> RFC7315 = (draft-drage-sipping-rfc3455bis-14)
>>>>>>= --------------------------------------
>>>>>> = Title           &nb= sp;   : 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           &n= bsp;  : IETF - NON WORKING GROUP
>>>>>> = Area           &nbs= p;    : N/A
>>>>>> = Stream           &n= bsp;  : IETF
>>>>>> Verifying = Party     : IESG
>>>>>> 
>>>>>> = _______________________________________________
>>>>>> sipcore mailing list
>>>>>> sipcore@ietf.org<mailto:sipcore@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>> = _______________________________________________
>>>>> sipcore mailing list
>>>>> sipcore@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/sipcore
> 
> = _______________________________________________
> = dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_AD143B75-ABB3-4DBB-950B-BB105E1540B4-- From nobody Tue Oct 20 17:52:04 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 D4A3C1B2A96 for ; Tue, 20 Oct 2015 17:52:02 -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 BEW3aUiJFN5n for ; Tue, 20 Oct 2015 17:51:59 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39ACC1B2A82 for ; Tue, 20 Oct 2015 17:51:58 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-09v.sys.comcast.net with comcast id Xcrn1r0022D5gil01cryjf; Wed, 21 Oct 2015 00:51:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-06v.sys.comcast.net with comcast id Xcrx1r00S3Ge9ey01crxo2; Wed, 21 Oct 2015 00:51:58 +0000 To: Christer Holmberg , Ivo Sedlacek , SIPCORE References: <5624FFC2.1030708@alum.mit.edu> <39B5E4D390E9BD4890E2B3107900610112A6319C@ESESSMB301.ericsson.se> <56266259.2080504@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37B7D9A9@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <5626E1AD.5050909@alum.mit.edu> Date: Tue, 20 Oct 2015 20:51:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B7D9A9@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445388718; bh=BEcjmB+B7Y/5xPfeQZ1WADjZO/zjmM00kd4BA9CWRM4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=aaUzPIuK2mCoFugNy7lHYQJsUyBSHiF6QTDerinCV94hA+/PFWwPdp5P+Ss7/yg9B OwHbUUZrS1X75ZV4Xcjf8QByyMY2l/w+HJtYLs2exQ+YFDKGGtLkuSQSWj7JGxJ0w5 5W+v/A/nkP2yhsJ1uvHLtWslkLIsluBBnauyoQMUProlK4i6lSjOozLln1LCnm0NfH 5uMHh4K9/Hr3jbZwnvqkdBnA4HaVVXc1VZcElb1BMHC48jo79OKqQzC6D9mq8YlyjR 9hqaD1OeHZULyrfAjLmN4/aZDlTYrpUyyzcK5NX9OdGgGSmZeuaX0fO0PTGDxqpH4r fCZ6yG1ycvWXg== Archived-At: Subject: Re: [sipcore] Requesting assist with expert review of media feature tag 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, 21 Oct 2015 00:52:03 -0000 On 10/20/15 2:16 PM, Christer Holmberg wrote: > Hi, > >>>> - it establishes a media-less INVITE dialog, for the purpose of >>>> exchanging messages in the signaling, primarily using INFO. IMO this is inappropriate, for the same reason >>>> session-mode messaging via MESSAGE was rejected, in favor of MSRP. As I understand the service being provided, it is a specialized application of session mode instant messaging. >>> >>> the INFO package has already been registered by IANA so I wonder how why that is questioned now. It has nothing to do with the media feature tag. >> >> I"m not questioning the general use of info packages. I'm questioning establishing an invite dialog usage with no intent to include >> media, with the sole intent of exchanging INFO messages as a form of session mode messaging. Way back during the time of SIMPLE, we >> decided that it was bad to establish a messaging *session* over the sip signaling channel. At the time that alternative was via MESSAGE, but >> using INFO doesn't change the argument. It is still bad. > > I think this issue should have been raised when the Info package was registered. That's when one should look at how the Info Package is going to be used etc. I don't think it's fair to reject the media feature tag registration on such grounds at this point. Well, the info package registry is only "specification required". I just looked and found that the package in question was registered by reference to a 3gpp specification. There is no expert reviewer for it. So I at least wasn't aware that it happened in order to raise an objection. In any case, I doubt one can tell from the definition of the package that it will be used in sessions set up exclusively for its use. > In my opinion it's about whether the media feature tag semantics is aligned with the rules for a media feature tag. In my opinion it is, as it only indicates support of a feature. It does NOT indicate do-what-I-mean, it does NOT assume anything from the remote party etc. The guidance to the expert is minimal. That is why I'm bringing it up here. Thanks, Paul > Regards, > > Christer > > > > > >>> - a new mechanism is introduced for passing alert indications, rather >>> than reusing the defined mechanism of Alert-Info. (RFC3261 and >>> RFC7462) >> >> The alertingPattern is an application level indication. >> >> The alertingPattern can potentially be included in any USSI message, including those sent in INFO messages while Alert-Info cannot be in INFO request. > > I still don't understand. Is this alerting, in concept, any different from that which Alert-Info is intended for? > > Is it that you want to alert for individual messages within a messaging session? > > Thanks, > Paul > >> Kind regards >> >> Ivo Sedlacek >> >> This Communication is Confidential. We only send and receive email on >> the basis of the terms set out at www.ericsson.com/email_disclaimer >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul >> Kyzivat >> Sent: Monday, October 19, 2015 4:36 PM >> To: SIPCORE >> Subject: [sipcore] Requesting assist with expert review of media >> feature tag >> >> I'm the designated expert reviewer for IANA registration of new media >> feature tag values. (Often for use as sip caller capabilities.) >> >> I have a recent request that concerns me. I am inclined to reject it, but the decision is subjective, so I would like to have some discussion on it first. >> >> The request comes from 3gpp - it has had no action in ietf. It is for >> the media feature tag g.3gpp.nw-init-ussi, with semantics defined in >> 3GPP TS 24.390 ("Unstructured Supplementary Service Data (USSD) using >> IP Multimedia (IM) Core Network (CN) subsystem IMS; Stage 3”) >> >> It is the details of how this service is signaled in SIP that troubles me. I wrote this up in my initial response. A copy of that message is attached. (Including details of the request.) My key concerns from that are: >> >> - it establishes a media-less INVITE dialog, for the purpose of exchanging messages in the signaling, primarily using INFO. IMO this is inappropriate, for the same reason session-mode messaging via MESSAGE was rejected, in favor of MSRP. As I understand the service being provided, it is a specialized application of session mode instant messaging. >> >> - a new mechanism is introduced for passing alert indications, rather >> than reusing the defined mechanism of Alert-Info. (RFC3261 and >> RFC7462) >> >> My feeling is that these conflict with ietf standards and so the registration should be rejected. I would like to hear other thoughts on this, and in general on the appropriateness of the proposed mechanism as a SIP usage. >> >> Thanks, >> Paul >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Wed Oct 21 00:02:38 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 61B321B35E6 for ; Wed, 21 Oct 2015 00:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 U7OxjKBDhpWO for ; Wed, 21 Oct 2015 00:02: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 29C631A9051 for ; Wed, 21 Oct 2015 00:02:31 -0700 (PDT) X-AuditID: c1b4fb30-f79626d000006adf-b7-562738840ffd Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 73.21.27359.48837265; Wed, 21 Oct 2015 09:02:29 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.87]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Wed, 21 Oct 2015 09:02:28 +0200 From: Ivo Sedlacek To: Paul Kyzivat , SIPCORE Thread-Topic: [sipcore] Requesting assist with expert review of media feature tag Thread-Index: AQHRCnt+raJaHQDZt0yeY/gj3woXT55z4YTQgACFk4CAAR+qsA== Date: Wed, 21 Oct 2015 07:02:27 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112A65519@ESESSMB301.ericsson.se> References: <5624FFC2.1030708@alum.mit.edu> <39B5E4D390E9BD4890E2B3107900610112A6319C@ESESSMB301.ericsson.se> <56266259.2080504@alum.mit.edu> In-Reply-To: <56266259.2080504@alum.mit.edu> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+JvjW6rhXqYwZOZfBYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXRcHUnY8Ej5ordB9cxNzBeYe5i5OCQEDCR uDRTtIuRE8gUk7hwbz1bFyMXh5DAUUaJtxdvMkM4ixklDq2dwQhSxSagJzFxyxFWEFtEwEVi SfcRZhBbWCBIYvX0fVDxYIn1v7eyQ9hOEvN+/mEDsVkEVCX+PVjKCrKYV8BXomV1DkhYSGAi o8SSl2YgNqeAjsTcuW1grYwCshJX//SCrWUWEJe49WQ+E8ShAhJL9pxnhrBFJV4+/scKYStK fHy1jxFkPLOApsT6XfoQrYoSU7ofgo3kFRCUODnzCcsERtFZSKbOQuiYhaRjFpKOBYwsqxhF i1OLk3LTjYz0Uosyk4uL8/P08lJLNjECI+Tglt8GOxhfPnc8xCjAwajEw5uwUy1MiDWxrLgy 9xCjNAeLkjhvM9ODUCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2Ms9aslNtzqO95c1Jz6Seu LxzS3aG7J/O6Bjxb8/rxypf/np1ZoF09/UBdzdPMzfsElJZcfTDpWsX+tY/z5hmoyHAVOkve LNxzVPTTByWje3cELmzatpzrPYer4qoSkXupPzhbOVl0gu+beW04eqCo9wiD1Z6i+39u/dJ3 7rh2kPP7E90s5bY8DSWW4oxEQy3mouJEANuqUFFxAgAA Archived-At: Subject: Re: [sipcore] Requesting assist with expert review of media feature tag 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, 21 Oct 2015 07:02:37 -0000 PiBJcyBpdCB0aGF0IHlvdSB3YW50IHRvIGFsZXJ0IGZvciBpbmRpdmlkdWFsIG1lc3NhZ2VzIHdp dGhpbiBhIG1lc3NhZ2luZyBzZXNzaW9uPw0KDQpZZXMsIGFsZXJ0aW5nIGZvciBpbmRpdmlkdWFs IFVTU0kgbWVzc2FnZXMgd2l0aGluIGEgVVNTSSAobWVzc2FnaW5nKSBzZXNzaW9uIGlzIHBvc3Np YmxlLg0KDQpVU1NJIChVU1NEIG92ZXIgSU1TKSBlbXVsYXRlcyB0aGUgZXhpc3RpbmcgVVNTRCBv dmVyIGNpcmN1aXQgc3dpdGNoZWQgZG9tYWluIG9mIDNHUFAgbmV0d29ya3MgYW5kIG5lZWRzIHRv IHByb3ZpZGUgdGhlIHNhbWUgZmVhdHVyZSBzZXQuDQoNCktpbmQgcmVnYXJkcw0KDQpJdm8gU2Vk bGFjZWsNCg== From nobody Wed Oct 21 05:36:24 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 A92C31A21B0 for ; Wed, 21 Oct 2015 05:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 TIVLdVA2S7Ld for ; Wed, 21 Oct 2015 05:36:20 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0081A21AF for ; Wed, 21 Oct 2015 05:36:20 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id B40BE7DB38CAC; Wed, 21 Oct 2015 12:36:15 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t9LCaE0t017567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 21 Oct 2015 14:36:17 +0200 Received: from FR712WXCHMBA10.zeu.alcatel-lucent.com ([169.254.6.161]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 21 Oct 2015 14:36:17 +0200 From: "DRAGE, Keith (Keith)" To: Ivo Sedlacek , Paul Kyzivat , SIPCORE Thread-Topic: [sipcore] Requesting assist with expert review of media feature tag Thread-Index: AQHRCnt+ZJRBKxULakmU4zfLr5ZPyZ5zwSGAgAIIFfA= Date: Wed, 21 Oct 2015 12:36:16 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADDF44B3@FR712WXCHMBA10.zeu.alcatel-lucent.com> References: <5624FFC2.1030708@alum.mit.edu> <39B5E4D390E9BD4890E2B3107900610112A6319C@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112A6319C@ESESSMB301.ericsson.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Requesting assist with expert review of media feature tag 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, 21 Oct 2015 12:36:22 -0000 SSdkIGxpa2UgdG8gYWRkIHRvIHdoYXQgSXZvIGhhcyBzYWlkLg0KDQpJbiBnZW5lcmFsIGluIDNH UFAgd2UgaGF2ZSB0cmllZCB0byBzZXBhcmF0ZSB0aGUgZ2VuZXJhbCB1c2Ugb2YgdGhlIGFkZGl0 aW9uYWwgcGFyYW1ldGVyLCBhbmQgcHV0IHRoYXQgaW4gb3IgYXJvdW5kIGEgc2VjdGlvbiBlbnRp dGxlZCBJQU5BIHJlZ2lzdHJhdGlvbiwgZnJvbSB0aGUgbWF0ZXJpYWwgd2hlcmUgaXQgaXMgdXNl ZCBzcGVjaWZpY2FsbHkgaW4gc3VwcG9ydCBvZiBhIHBhcnRpY3VsYXIgM0dQUCBhcHBsaWNhdGlv bi4NCg0KU28gZ2VuZXJhbGx5LCB0aGlzIGlzIGEgbWVkaWEgZmVhdHVyZSB0YWcuIEl0IGlzIGRl ZmluZWQgYXMgYSBtZWRpYWwgZmVhdHVyZSB0YWcgaW4gdGhlIElBTkEgcmVnaXN0cmF0aW9uIGNs YXVzZSBvZiB0aGUgdW5kZXJseWluZyAzR1BQIHNwZWNpZmljYXRpb24sIGFuZCBvcGVyYXRlcyBh cywgYW5kIGNhbiBiZSB1c2VkIGFzLCBhIG1lZGlhIGZlYXR1cmUgdGFnIGluIGZ1bGwgY29tcGxp YW5jZSB3aXRoIHRoZSBJRVRGIFJGQ3MgY292ZXJpbmcgbWVkaWEgZmVhdHVyZSB0YWdzLg0KDQoz R1BQIFRTIDI0LjM5MCBvYnZpb3VzbHkgdXNlcyB0aGlzIGZlYXR1cmUgdGFnIGluIHN1cHBvcnQg b2YgYSBzZXJ2aWNlIG9yIGNhcGFiaWxpdHkgdXNpbmcgdGhlIElORk8gcGFja2FnZS4gTm93IHdo ZXRoZXIgdGhhdCBpcyBjb3JyZWN0IG9yIG5vdCBpcyBub3RoaW5nIHRvIGRvIHdpdGggdGhlIHVz ZSBvZiB0aGUgbWVkaWEgZmVhdHVyZSB0YWcuIEZ1cnRoZXIgdGhlIGFsZXJ0aW5nIGRlZmluaXRp b24gaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGUgc2VtYW50aWNzIG9mIHRoZSBtZWRpYSBmZWF0 dXJlIHRhZy4NCg0KU28gdGhlIHJlcXVlc3QgZnJvbSAzR1BQIHdhcyBmb3IgdGhpcyBtZWRpYSBm ZWF0dXJlIHRhZyB0byBiZSByZWdpc3RlcmVkLg0KDQpUaGUgcmVxdWVzdCB0byByZWdpc3RlciB0 aGUgbWVkaWEgZmVhdHVyZSB0YWcgaGFzIGFwcGFyZW50bHkgYmVlbiByZWplY3RlZCBmb3IgcmVh c29ucyB0aGF0IGFyZSBub3RoaW5nIHRvIGRvIHdpdGggdGhlIG1lZGlhIGZlYXR1cmUgdGFnIGRl ZmluaXRpb24uDQoNClJlZ2FyZHMNCg0KS2VpdGgNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBJdm8gU2VkbGFjZWsNClNlbnQ6IDIwIE9jdG9iZXIgMjAxNSAwNjo1NQ0KVG86IFBh dWwgS3l6aXZhdDsgU0lQQ09SRQ0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBSZXF1ZXN0aW5nIGFz c2lzdCB3aXRoIGV4cGVydCByZXZpZXcgb2YgbWVkaWEgZmVhdHVyZSB0YWcNCg0KSGVsbG8gUGF1 bCwNCg0KPiAtIGl0IGVzdGFibGlzaGVzIGEgbWVkaWEtbGVzcyBJTlZJVEUgZGlhbG9nLCBmb3Ig dGhlIHB1cnBvc2Ugb2YgDQo+IGV4Y2hhbmdpbmcgbWVzc2FnZXMgaW4gdGhlIHNpZ25hbGluZywg cHJpbWFyaWx5IHVzaW5nIElORk8uIElNTyB0aGlzIGlzIGluYXBwcm9wcmlhdGUsIGZvciB0aGUg c2FtZSByZWFzb24gc2Vzc2lvbi1tb2RlIG1lc3NhZ2luZyB2aWEgTUVTU0FHRSB3YXMgcmVqZWN0 ZWQsIGluIGZhdm9yIG9mIE1TUlAuIEFzIEkgdW5kZXJzdGFuZCB0aGUgc2VydmljZSBiZWluZyBw cm92aWRlZCwgaXQgaXMgYSBzcGVjaWFsaXplZCBhcHBsaWNhdGlvbiBvZiBzZXNzaW9uIG1vZGUg aW5zdGFudCBtZXNzYWdpbmcuDQoNCnRoZSBJTkZPIHBhY2thZ2UgaGFzIGFscmVhZHkgYmVlbiBy ZWdpc3RlcmVkIGJ5IElBTkEgc28gSSB3b25kZXIgaG93IHdoeSB0aGF0IGlzIHF1ZXN0aW9uZWQg bm93LiBJdCBoYXMgbm90aGluZyB0byBkbyB3aXRoIHRoZSBtZWRpYSBmZWF0dXJlIHRhZy4NCg0K PiAtIGEgbmV3IG1lY2hhbmlzbSBpcyBpbnRyb2R1Y2VkIGZvciBwYXNzaW5nIGFsZXJ0IGluZGlj YXRpb25zLCByYXRoZXIgDQo+IHRoYW4gcmV1c2luZyB0aGUgZGVmaW5lZCBtZWNoYW5pc20gb2Yg QWxlcnQtSW5mby4gKFJGQzMyNjEgYW5kIA0KPiBSRkM3NDYyKQ0KDQpUaGUgYWxlcnRpbmdQYXR0 ZXJuIGlzIGFuIGFwcGxpY2F0aW9uIGxldmVsIGluZGljYXRpb24uDQoNClRoZSBhbGVydGluZ1Bh dHRlcm4gY2FuIHBvdGVudGlhbGx5IGJlIGluY2x1ZGVkIGluIGFueSBVU1NJIG1lc3NhZ2UsIGlu Y2x1ZGluZyB0aG9zZSBzZW50IGluIElORk8gbWVzc2FnZXMgd2hpbGUgQWxlcnQtSW5mbyBjYW5u b3QgYmUgaW4gSU5GTyByZXF1ZXN0Lg0KDQpLaW5kIHJlZ2FyZHMNCg0KSXZvIFNlZGxhY2VrDQoN ClRoaXMgQ29tbXVuaWNhdGlvbiBpcyBDb25maWRlbnRpYWwuIFdlIG9ubHkgc2VuZCBhbmQgcmVj ZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQgd3d3LmVyaWNz c29uLmNvbS9lbWFpbF9kaXNjbGFpbWVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgUGF1bCBLeXppdmF0DQpTZW50OiBNb25kYXksIE9jdG9iZXIgMTksIDIwMTUgNDozNiBQTQ0K VG86IFNJUENPUkUNClN1YmplY3Q6IFtzaXBjb3JlXSBSZXF1ZXN0aW5nIGFzc2lzdCB3aXRoIGV4 cGVydCByZXZpZXcgb2YgbWVkaWEgZmVhdHVyZSB0YWcNCg0KSSdtIHRoZSBkZXNpZ25hdGVkIGV4 cGVydCByZXZpZXdlciBmb3IgSUFOQSByZWdpc3RyYXRpb24gb2YgbmV3IG1lZGlhIGZlYXR1cmUg dGFnIHZhbHVlcy4gKE9mdGVuIGZvciB1c2UgYXMgc2lwIGNhbGxlciBjYXBhYmlsaXRpZXMuKQ0K DQpJIGhhdmUgYSByZWNlbnQgcmVxdWVzdCB0aGF0IGNvbmNlcm5zIG1lLiBJIGFtIGluY2xpbmVk IHRvIHJlamVjdCBpdCwgYnV0IHRoZSBkZWNpc2lvbiBpcyBzdWJqZWN0aXZlLCBzbyBJIHdvdWxk IGxpa2UgdG8gaGF2ZSBzb21lIGRpc2N1c3Npb24gb24gaXQgZmlyc3QuDQoNClRoZSByZXF1ZXN0 IGNvbWVzIGZyb20gM2dwcCAtIGl0IGhhcyBoYWQgbm8gYWN0aW9uIGluIGlldGYuIEl0IGlzIGZv ciB0aGUgbWVkaWEgZmVhdHVyZSB0YWcgZy4zZ3BwLm53LWluaXQtdXNzaSwgd2l0aCBzZW1hbnRp Y3MgZGVmaW5lZCBpbiAzR1BQIFRTIDI0LjM5MCAoIlVuc3RydWN0dXJlZCBTdXBwbGVtZW50YXJ5 IFNlcnZpY2UgRGF0YSAoVVNTRCkgdXNpbmcgSVAgTXVsdGltZWRpYSAoSU0pIENvcmUgTmV0d29y ayAoQ04pIHN1YnN5c3RlbSBJTVM7IFN0YWdlIDPigJ0pDQoNCkl0IGlzIHRoZSBkZXRhaWxzIG9m IGhvdyB0aGlzIHNlcnZpY2UgaXMgc2lnbmFsZWQgaW4gU0lQIHRoYXQgdHJvdWJsZXMgbWUuIEkg d3JvdGUgdGhpcyB1cCBpbiBteSBpbml0aWFsIHJlc3BvbnNlLiBBIGNvcHkgb2YgdGhhdCBtZXNz YWdlIGlzIGF0dGFjaGVkLiAoSW5jbHVkaW5nIGRldGFpbHMgb2YgdGhlIHJlcXVlc3QuKSBNeSBr ZXkgY29uY2VybnMgZnJvbSB0aGF0IGFyZToNCg0KLSBpdCBlc3RhYmxpc2hlcyBhIG1lZGlhLWxl c3MgSU5WSVRFIGRpYWxvZywgZm9yIHRoZSBwdXJwb3NlIG9mIGV4Y2hhbmdpbmcgbWVzc2FnZXMg aW4gdGhlIHNpZ25hbGluZywgcHJpbWFyaWx5IHVzaW5nIElORk8uIElNTyB0aGlzIGlzIGluYXBw cm9wcmlhdGUsIGZvciB0aGUgc2FtZSByZWFzb24gc2Vzc2lvbi1tb2RlIG1lc3NhZ2luZyB2aWEg TUVTU0FHRSB3YXMgcmVqZWN0ZWQsIGluIGZhdm9yIG9mIE1TUlAuIEFzIEkgdW5kZXJzdGFuZCB0 aGUgc2VydmljZSBiZWluZyBwcm92aWRlZCwgaXQgaXMgYSBzcGVjaWFsaXplZCBhcHBsaWNhdGlv biBvZiBzZXNzaW9uIG1vZGUgaW5zdGFudCBtZXNzYWdpbmcuDQoNCi0gYSBuZXcgbWVjaGFuaXNt IGlzIGludHJvZHVjZWQgZm9yIHBhc3NpbmcgYWxlcnQgaW5kaWNhdGlvbnMsIHJhdGhlciB0aGFu IHJldXNpbmcgdGhlIGRlZmluZWQgbWVjaGFuaXNtIG9mIEFsZXJ0LUluZm8uIChSRkMzMjYxIGFu ZCBSRkM3NDYyKQ0KDQpNeSBmZWVsaW5nIGlzIHRoYXQgdGhlc2UgY29uZmxpY3Qgd2l0aCBpZXRm IHN0YW5kYXJkcyBhbmQgc28gdGhlIHJlZ2lzdHJhdGlvbiBzaG91bGQgYmUgcmVqZWN0ZWQuIEkg d291bGQgbGlrZSB0byBoZWFyIG90aGVyIHRob3VnaHRzIG9uIHRoaXMsIGFuZCBpbiBnZW5lcmFs IG9uIHRoZSBhcHByb3ByaWF0ZW5lc3Mgb2YgdGhlIHByb3Bvc2VkIG1lY2hhbmlzbSBhcyBhIFNJ UCB1c2FnZS4NCg0KCVRoYW5rcywNCglQYXVsDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo= From nobody Wed Oct 21 06:41: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 8440C1A87A7 for ; Wed, 21 Oct 2015 06:41:47 -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 g3iSy3varIiV for ; Wed, 21 Oct 2015 06:41:45 -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 E11601A8799 for ; Wed, 21 Oct 2015 06:41:43 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-11v.sys.comcast.net with comcast id XphP1r00526dK1R01phj8V; Wed, 21 Oct 2015 13:41:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-01v.sys.comcast.net with comcast id Xphi1r0073Ge9ey01phiQG; Wed, 21 Oct 2015 13:41:42 +0000 To: "DRAGE, Keith (Keith)" , Ivo Sedlacek , SIPCORE References: <5624FFC2.1030708@alum.mit.edu> <39B5E4D390E9BD4890E2B3107900610112A6319C@ESESSMB301.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADDF44B3@FR712WXCHMBA10.zeu.alcatel-lucent.com> From: Paul Kyzivat Message-ID: <56279614.8000401@alum.mit.edu> Date: Wed, 21 Oct 2015 09:41:40 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADDF44B3@FR712WXCHMBA10.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445434903; bh=ZUo78O8nAopq5/PZP0Mbb8NcqMFYEzcZXa4mf/EyYnI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=rEZoxpmnqsHRWXQgFxh1bsqlmzuwepNgJJUCnbqdJ2yyraim1imB4VmhyLa7IpEI5 7flI4O3ktPs6TSgJHpECsnd48LK37GVPbe4n5hQQjUVYss9nRjO5XQbeKIjs28J12J abbI2ofEsR/hyf3Hu9Ky5sih7A+WHTrOuFetcEFsMsyH6oDqGGOUFR5BBqewpTss6X dMJ7CEXWztvGRXM1L7MywdIDtPTObe+bhNDtFbF21dTYD07W5eYLWAx4NkQ1cBtJIX mLL8VYqDuk63GVCIfStjps2I1WyPDHhyMNkdlYgvogA3MEjzsIncTVEQKoclzYddc2 WP85OHQdwAkJQ== Archived-At: Subject: Re: [sipcore] Requesting assist with expert review of media feature tag 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, 21 Oct 2015 13:41:47 -0000 I acknowledge that the fundamental question here is what the criteria should be for the expert to approve a media feature tag request. I indeed am taking the position that if the tag is used to enable a feature, then the consistency of that feature with SIP is a valid criterion. I recognize that not everyone agrees with that position. I take that position because it is the leverage that we have. It would be better if the guidance to the expert were clearer. It may be that the right answer is to take some action to clarify that. Absent that, I *think* I am free to ask for advice from a pertinent wg, and then take that as I see fit. And the iesg is free to assign a new expert if they wish. Thanks, Paul On 10/21/15 8:36 AM, DRAGE, Keith (Keith) wrote: > I'd like to add to what Ivo has said. > > In general in 3GPP we have tried to separate the general use of the additional parameter, and put that in or around a section entitled IANA registration, from the material where it is used specifically in support of a particular 3GPP application. > > So generally, this is a media feature tag. It is defined as a medial feature tag in the IANA registration clause of the underlying 3GPP specification, and operates as, and can be used as, a media feature tag in full compliance with the IETF RFCs covering media feature tags. > > 3GPP TS 24.390 obviously uses this feature tag in support of a service or capability using the INFO package. Now whether that is correct or not is nothing to do with the use of the media feature tag. Further the alerting definition has nothing to do with the semantics of the media feature tag. > > So the request from 3GPP was for this media feature tag to be registered. > > The request to register the media feature tag has apparently been rejected for reasons that are nothing to do with the media feature tag definition. > > Regards > > Keith > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek > Sent: 20 October 2015 06:55 > To: Paul Kyzivat; SIPCORE > Subject: Re: [sipcore] Requesting assist with expert review of media feature tag > > Hello Paul, > >> - it establishes a media-less INVITE dialog, for the purpose of >> exchanging messages in the signaling, primarily using INFO. IMO this is inappropriate, for the same reason session-mode messaging via MESSAGE was rejected, in favor of MSRP. As I understand the service being provided, it is a specialized application of session mode instant messaging. > > the INFO package has already been registered by IANA so I wonder how why that is questioned now. It has nothing to do with the media feature tag. > >> - a new mechanism is introduced for passing alert indications, rather >> than reusing the defined mechanism of Alert-Info. (RFC3261 and >> RFC7462) > > The alertingPattern is an application level indication. > > The alertingPattern can potentially be included in any USSI message, including those sent in INFO messages while Alert-Info cannot be in INFO request. > > Kind regards > > Ivo Sedlacek > > This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, October 19, 2015 4:36 PM > To: SIPCORE > Subject: [sipcore] Requesting assist with expert review of media feature tag > > I'm the designated expert reviewer for IANA registration of new media feature tag values. (Often for use as sip caller capabilities.) > > I have a recent request that concerns me. I am inclined to reject it, but the decision is subjective, so I would like to have some discussion on it first. > > The request comes from 3gpp - it has had no action in ietf. It is for the media feature tag g.3gpp.nw-init-ussi, with semantics defined in 3GPP TS 24.390 ("Unstructured Supplementary Service Data (USSD) using IP Multimedia (IM) Core Network (CN) subsystem IMS; Stage 3”) > > It is the details of how this service is signaled in SIP that troubles me. I wrote this up in my initial response. A copy of that message is attached. (Including details of the request.) My key concerns from that are: > > - it establishes a media-less INVITE dialog, for the purpose of exchanging messages in the signaling, primarily using INFO. IMO this is inappropriate, for the same reason session-mode messaging via MESSAGE was rejected, in favor of MSRP. As I understand the service being provided, it is a specialized application of session mode instant messaging. > > - a new mechanism is introduced for passing alert indications, rather than reusing the defined mechanism of Alert-Info. (RFC3261 and RFC7462) > > My feeling is that these conflict with ietf standards and so the registration should be rejected. I would like to hear other thoughts on this, and in general on the appropriateness of the proposed mechanism as a SIP usage. > > Thanks, > Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Oct 22 17:03: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 2295A1ACEA7 for ; Thu, 22 Oct 2015 17:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 3N1US7qiGo2e for ; Thu, 22 Oct 2015 17:03:15 -0700 (PDT) Received: from smtp69.ord1c.emailsrvr.com (smtp69.ord1c.emailsrvr.com [108.166.43.69]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8D561ACE33 for ; Thu, 22 Oct 2015 17:03:15 -0700 (PDT) Received: from smtp25.relay.ord1c.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp25.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 02AB31801D2; Thu, 22 Oct 2015 20:03:15 -0400 (EDT) Received: by smtp25.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id BF6B11801D4; Thu, 22 Oct 2015 20:03:13 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Fri, 23 Oct 2015 00:03:14 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Cullen Jennings In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B691E1@ESESSMB209.ericsson.se> Date: Thu, 22 Oct 2015 18:03:10 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B37B62FC0@ESESSMB209.ericsson.se> <90429FC5-4199-4386-8CEE-F7F9E45420CE@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B6907F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B691E1@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Ben Campbell , DISPATCH list , SIPCORE Subject: Re: [sipcore] [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [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: Fri, 23 Oct 2015 00:03:18 -0000 I read the draft and looks pretty simple to me. Hope we can move this = quickly.=20 > On Oct 18, 2015, at 1:10 PM, Christer Holmberg = wrote: >=20 > Hi, >=20 > I've submitted a new version, -01, where the category is changed to = 'Informational'. >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of = Christer Holmberg > Sent: 18 October 2015 21:59 > To: Ben Campbell > Cc: DISPATCH list ; SIPCORE > Subject: Re: [dispatch] Draft new: = draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata = Reported] RFC7315 (4474)] >=20 > Hi, >=20 >> If 7315 is informational, why does the update need to be standards = track? >=20 > Good point - I guess it doesn't have to :) >=20 > Regards, >=20 > Christer >=20 >=20 > On 18 Oct 2015, at 6:49, Christer Holmberg wrote: >=20 >> Hi, >>=20 >> Based on Ben=E2=80=99s guidance, I=E2=80=99ve submitted a draft which = makes the ABNF=20 >> update. >>=20 >> NOTE: As RFC 7315 is an Informational RFC, I had to add the RFC as an=20= >> Informative reference in the draft, in order to pass the Idnits = check. >>=20 >>=20 >> A new version of I-D, draft-holmberg-dispatch-pani-abnf-00.txt >>=20 >> has been successfully submitted by Christer Holmberg and posted to = the=20 >> IETF repository. >>=20 >>=20 >>=20 >> Name: draft-holmberg-dispatch-pani-abnf >>=20 >> Revision: 00 >>=20 >> Title: P-Access-Network-Info ABNF Update >>=20 >> Document date: 2015-10-18 >>=20 >> Group: Individual Submission >>=20 >> Pages: 4 >>=20 >> URL: =20 >> = https://www.ietf.org/internet-drafts/draft-holmberg-dispatch-pani-abnf >> -00.txt >>=20 >> Status: =20 >> https://datatracker.ietf.org/doc/draft-holmberg-dispatch-pani-abnf/ >>=20 >> Htmlized: =20 >> https://tools.ietf.org/html/draft-holmberg-dispatch-pani-abnf-00 >>=20 >>=20 >>=20 >>=20 >>=20 >> Abstract: >>=20 >> This document updates RFC 7315, by modifying the extension-access- >>=20 >> info part of the P-Access-Network-Info header field Augmented Backus- >>=20 >> Naur Form (ABNF). >>=20 >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer=20= >> Holmberg >> Sent: 18 October 2015 10:52 >> To: Ben Campbell >> Cc: DISPATCH list ; SIPCORE ;=20 >> Cullen Jennings >> Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 >> (4474) >>=20 >> Hi, >>=20 >> So, shall I address the draft to some WG, or? >>=20 >> draft-holmberg-dispatch ? >>=20 >> Regards, >>=20 >> Christer >>=20 >> Sent from my Windows Phone >> ________________________________ >> From: Ben Campbell >> Sent: =E2=80=8E14/=E2=80=8E10/=E2=80=8E2015 17:21 >> To: Christer Holmberg >> Cc: Cullen Jennings; DISPATCH=20 >> list; SIPCORE >> Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 >> (4474) >> On 8 Oct 2015, at 21:03, Christer Holmberg wrote: >>=20 >>> Hi Cullen, >>>=20 >>> So, you are suggesting a SIPCORE draft that updates the ABNF? >>=20 >> This is where the chairs will point out that special-purpose=20 >> extensions are generally not in scope for sipcore :-) If so, this=20 >> might could also be done as AD sponsored. >>=20 >> Ben. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Oct 27 14:46: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 71FB71B29B8; Tue, 27 Oct 2015 14:46: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 svA9M930cxTc; Tue, 27 Oct 2015 14:46: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 70C7B1B29B7; Tue, 27 Oct 2015 14:46:04 -0700 (PDT) Received: from mutabilis-2.local (pool-71-164-199-31.dllstx.fios.verizon.net [71.164.199.31]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9RLjxDC084862 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 27 Oct 2015 16:46:00 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-164-199-31.dllstx.fios.verizon.net [71.164.199.31] claimed to be mutabilis-2.local To: Christer Holmberg , Ben Campbell References: <7594FB04B1934943A5C02806D1A2204B37B62FC0@ESESSMB209.ericsson.se> <90429FC5-4199-4386-8CEE-F7F9E45420CE@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B6907F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B691E1@ESESSMB209.ericsson.se> From: "A. Jean Mahoney" Message-ID: <562FF092.3090605@nostrum.com> Date: Tue, 27 Oct 2015 16:45:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B691E1@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: DISPATCH list , SIPCORE Subject: Re: [sipcore] [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [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: Tue, 27 Oct 2015 21:46:06 -0000 Hi Christer, The draft looks good to me. Just a few nits: 1. Introduction 2nd paragraph: "requires new values are required" => "requires new values". 4th paragraph: "have been followed" => "have been defined" You may also consider adding a reference to TS 24.229, which defines values for access-info, to the 4th paragraph. Thanks! Jean On 10/18/15 2:10 PM, Christer Holmberg wrote: > Hi, > > I've submitted a new version, -01, where the category is changed to 'Informational'. > > Regards, > > Christer > > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 18 October 2015 21:59 > To: Ben Campbell > Cc: DISPATCH list ; SIPCORE > Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata Reported] RFC7315 (4474)] > > Hi, > >> If 7315 is informational, why does the update need to be standards track? > > Good point - I guess it doesn't have to :) > > Regards, > > Christer > > > On 18 Oct 2015, at 6:49, Christer Holmberg wrote: > >> Hi, >> >> Based on Ben’s guidance, I’ve submitted a draft which makes the ABNF >> update. >> >> NOTE: As RFC 7315 is an Informational RFC, I had to add the RFC as an >> Informative reference in the draft, in order to pass the Idnits check. >> >> >> A new version of I-D, draft-holmberg-dispatch-pani-abnf-00.txt >> >> has been successfully submitted by Christer Holmberg and posted to the >> IETF repository. >> >> >> >> Name: draft-holmberg-dispatch-pani-abnf >> >> Revision: 00 >> >> Title: P-Access-Network-Info ABNF Update >> >> Document date: 2015-10-18 >> >> Group: Individual Submission >> >> Pages: 4 >> >> URL: >> https://www.ietf.org/internet-drafts/draft-holmberg-dispatch-pani-abnf >> -00.txt >> >> Status: >> https://datatracker.ietf.org/doc/draft-holmberg-dispatch-pani-abnf/ >> >> Htmlized: >> https://tools.ietf.org/html/draft-holmberg-dispatch-pani-abnf-00 >> >> >> >> >> >> Abstract: >> >> This document updates RFC 7315, by modifying the extension-access- >> >> info part of the P-Access-Network-Info header field Augmented Backus- >> >> Naur Form (ABNF). >> >> >> Regards, >> >> Christer >> >> >> >> >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer >> Holmberg >> Sent: 18 October 2015 10:52 >> To: Ben Campbell >> Cc: DISPATCH list ; SIPCORE ; >> Cullen Jennings >> Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 >> (4474) >> >> Hi, >> >> So, shall I address the draft to some WG, or? >> >> draft-holmberg-dispatch ? >> >> Regards, >> >> Christer >> >> Sent from my Windows Phone >> ________________________________ >> From: Ben Campbell >> Sent: ‎14/‎10/‎2015 17:21 >> To: Christer Holmberg >> Cc: Cullen Jennings; DISPATCH >> list; SIPCORE >> Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 >> (4474) >> On 8 Oct 2015, at 21:03, Christer Holmberg wrote: >> >>> Hi Cullen, >>> >>> So, you are suggesting a SIPCORE draft that updates the ABNF? >> >> This is where the chairs will point out that special-purpose >> extensions are generally not in scope for sipcore :-) If so, this >> might could also be done as AD sponsored. >> >> Ben. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Tue Oct 27 15:02: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 6CD141B29DC; Tue, 27 Oct 2015 15:02:41 -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 pEb0LI_3jB1y; Tue, 27 Oct 2015 15:02:39 -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 B9A761B29DA; Tue, 27 Oct 2015 15:02:38 -0700 (PDT) X-AuditID: c1b4fb25-f79a26d00000149a-26-562ff47bfb9e Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D0.E0.05274.B74FF265; Tue, 27 Oct 2015 23:02:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Tue, 27 Oct 2015 23:02:35 +0100 From: Christer Holmberg To: "A. Jean Mahoney" , Ben Campbell Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata Reported] RFC7315 (4474)] Thread-Index: AQHRCdioJHiLHvuz1060lsfM8JgPcp5/3UAAgAAVMzA= Date: Tue, 27 Oct 2015 22:02:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37B94F9B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37B62FC0@ESESSMB209.ericsson.se> <90429FC5-4199-4386-8CEE-F7F9E45420CE@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B6907F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B691E1@ESESSMB209.ericsson.se> <562FF092.3090605@nostrum.com> In-Reply-To: <562FF092.3090605@nostrum.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM+JvrW7NF/0wg/cb2Czmd55mt1g6aQGr RUPnSlaLrz82sTmweCxZ8pPJY9bOJywBTFFcNimpOZllqUX6dglcGROaZ7AWHDGoWHPzBnsD 4xL9LkZODgkBE4lfHe1MELaYxIV769m6GLk4hASOMEo0brrDBOEsZpRYP/MwYxcjBwebgIVE 9z9tkAYRAW+Jk9uvsYKEmQUcJaatyQYpFxZoZZRo3r2LHcQREWhjlNgwawIjRIOVxPQ1T8Dm sAioShyaZQsS5hXwlXi25w8LxK7VTBILzxxiAUlwCmhLnPi8nx3EZgS67vupNWCXMguIS9x6 Mh/qagGJJXvOM0PYohIvH/9jhbCVJBbd/swEcZymxPpd+hCtihJTuh+yQ+wVlDg58wnLBEax WUimzkLomIWkYxaSjgWMLKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAiPq4JbfqjsYL79x PMQowMGoxMNrUKEXJsSaWFZcmXuIUYKDWUmEtydbP0yINyWxsiq1KD++qDQntfgQozQHi5I4 bzPTg1AhgfTEktTs1NSC1CKYLBMHp1QDIzf/p13S/p+XTSzinr7snq7L0ikC6dermP6wh7U0 9C1ccED8GFPy2+7aC3k/DCK/FE73jjzDseZ0kM3kU4//7z58yWjdhxu11S/WV/tbPLh7MJW9 ibf+6sO4Ounp8gc7pz3Zs8dTenp13sH4a9qSa8yWR4WpNzdVz73Ju2eL7+nAiB1rgna++6rE UpyRaKjFXFScCACTKOQ2pAIAAA== Archived-At: Cc: DISPATCH list , SIPCORE Subject: Re: [sipcore] [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [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: Tue, 27 Oct 2015 22:02:41 -0000 SGkgSmVhbiwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzISBJIHdpbGwgdXBkYXRlIHRoZSBk cmFmdCBhY2NvcmRpbmcgdG8geW91ciBzdWdnZXN0aW9ucy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEEuIEplYW4gTWFob25leSBb bWFpbHRvOm1haG9uZXlAbm9zdHJ1bS5jb21dIA0KU2VudDogMjcgT2N0b2JlciAyMDE1IDIzOjQ2 DQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT47 IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPg0KQ2M6IERJU1BBVENIIGxpc3QgPGRpc3Bh dGNoQGlldGYub3JnPjsgU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb ZGlzcGF0Y2hdIERyYWZ0IG5ldzogZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcGFuaS1hYm5mLTAw IFt3YXM6IFtzaXBjb3JlXSBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDNzMxNSAoNDQ3 NCldDQoNCkhpIENocmlzdGVyLA0KDQpUaGUgZHJhZnQgbG9va3MgZ29vZCB0byBtZS4gSnVzdCBh IGZldyBuaXRzOg0KDQoxLiBJbnRyb2R1Y3Rpb24NCg0KMm5kIHBhcmFncmFwaDogInJlcXVpcmVz IG5ldyB2YWx1ZXMgYXJlIHJlcXVpcmVkIiA9PiAicmVxdWlyZXMgbmV3IHZhbHVlcyIuDQoNCjR0 aCBwYXJhZ3JhcGg6ICJoYXZlIGJlZW4gZm9sbG93ZWQiID0+ICJoYXZlIGJlZW4gZGVmaW5lZCIN Cg0KWW91IG1heSBhbHNvIGNvbnNpZGVyIGFkZGluZyBhIHJlZmVyZW5jZSB0byBUUyAyNC4yMjks IHdoaWNoIGRlZmluZXMgdmFsdWVzIGZvciBhY2Nlc3MtaW5mbywgdG8gdGhlIDR0aCBwYXJhZ3Jh cGguDQoNClRoYW5rcyENCg0KSmVhbg0KDQoNCk9uIDEwLzE4LzE1IDI6MTAgUE0sIENocmlzdGVy IEhvbG1iZXJnIHdyb3RlOg0KPiBIaSwNCj4NCj4gSSd2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lv biwgLTAxLCB3aGVyZSB0aGUgY2F0ZWdvcnkgaXMgY2hhbmdlZCB0byAnSW5mb3JtYXRpb25hbCcu DQo+DQo+IFJlZ2FyZHMsDQo+DQo+IENocmlzdGVyDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IGRpc3BhdGNoIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIA0KPiBDaHJpc3RlciBIb2xtYmVyZw0KPiBTZW50OiAxOCBPY3RvYmVy IDIwMTUgMjE6NTkNCj4gVG86IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPg0KPiBDYzog RElTUEFUQ0ggbGlzdCA8ZGlzcGF0Y2hAaWV0Zi5vcmc+OyBTSVBDT1JFIDxzaXBjb3JlQGlldGYu b3JnPg0KPiBTdWJqZWN0OiBSZTogW2Rpc3BhdGNoXSBEcmFmdCBuZXc6IA0KPiBkcmFmdC1ob2xt YmVyZy1kaXNwYXRjaC1wYW5pLWFibmYtMDAgW3dhczogW3NpcGNvcmVdIFtUZWNobmljYWwgRXJy YXRhIA0KPiBSZXBvcnRlZF0gUkZDNzMxNSAoNDQ3NCldDQo+DQo+IEhpLA0KPg0KPj4gSWYgNzMx NSBpcyBpbmZvcm1hdGlvbmFsLCB3aHkgZG9lcyB0aGUgdXBkYXRlIG5lZWQgdG8gYmUgc3RhbmRh cmRzIHRyYWNrPw0KPg0KPiBHb29kIHBvaW50IC0gSSBndWVzcyBpdCBkb2Vzbid0IGhhdmUgdG8g OikNCj4NCj4gUmVnYXJkcywNCj4NCj4gQ2hyaXN0ZXINCj4NCj4NCj4gT24gMTggT2N0IDIwMTUs IGF0IDY6NDksIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KPg0KPj4gSGksDQo+Pg0KPj4gQmFz ZWQgb24gQmVu4oCZcyBndWlkYW5jZSwgSeKAmXZlIHN1Ym1pdHRlZCBhIGRyYWZ0IHdoaWNoIG1h a2VzIHRoZSBBQk5GIA0KPj4gdXBkYXRlLg0KPj4NCj4+IE5PVEU6IEFzIFJGQyA3MzE1IGlzIGFu IEluZm9ybWF0aW9uYWwgUkZDLCBJIGhhZCB0byBhZGQgdGhlIFJGQyBhcyBhbiANCj4+IEluZm9y bWF0aXZlIHJlZmVyZW5jZSBpbiB0aGUgZHJhZnQsIGluIG9yZGVyIHRvIHBhc3MgdGhlIElkbml0 cyBjaGVjay4NCj4+DQo+Pg0KPj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWhvbG1iZXJn LWRpc3BhdGNoLXBhbmktYWJuZi0wMC50eHQNCj4+DQo+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkg c3VibWl0dGVkIGJ5IENocmlzdGVyIEhvbG1iZXJnIGFuZCBwb3N0ZWQgdG8gDQo+PiB0aGUgSUVU RiByZXBvc2l0b3J5Lg0KPj4NCj4+DQo+Pg0KPj4gTmFtZTogICAgICAgICAgICAgICAgIGRyYWZ0 LWhvbG1iZXJnLWRpc3BhdGNoLXBhbmktYWJuZg0KPj4NCj4+IFJldmlzaW9uOiAgICAgICAgICAg IDAwDQo+Pg0KPj4gVGl0bGU6ICAgICAgICAgICAgICAgICAgICBQLUFjY2Vzcy1OZXR3b3JrLUlu Zm8gQUJORiBVcGRhdGUNCj4+DQo+PiBEb2N1bWVudCBkYXRlOiAgICAgICAgICAgICAgMjAxNS0x MC0xOA0KPj4NCj4+IEdyb3VwOiAgICAgICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24N Cj4+DQo+PiBQYWdlczogICAgICAgICAgICAgICAgIDQNCj4+DQo+PiBVUkw6DQo+PiBodHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcGFu aS1hYm4NCj4+IGYNCj4+IC0wMC50eHQNCj4+DQo+PiBTdGF0dXM6DQo+PiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1wYW5pLWFibmYvDQo+ Pg0KPj4gSHRtbGl6ZWQ6DQo+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaG9s bWJlcmctZGlzcGF0Y2gtcGFuaS1hYm5mLTAwDQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+IEFic3Ry YWN0Og0KPj4NCj4+IFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkMgNzMxNSwgYnkgbW9kaWZ5aW5n IHRoZSBleHRlbnNpb24tYWNjZXNzLQ0KPj4NCj4+IGluZm8gcGFydCBvZiB0aGUgUC1BY2Nlc3Mt TmV0d29yay1JbmZvIGhlYWRlciBmaWVsZCBBdWdtZW50ZWQgQmFja3VzLQ0KPj4NCj4+IE5hdXIg Rm9ybSAoQUJORikuDQo+Pg0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gQ2hyaXN0ZXINCj4+DQo+ Pg0KPj4NCj4+DQo+PiBGcm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgDQo+PiBIb2xtYmVyZw0KPj4gU2VudDogMTggT2N0 b2JlciAyMDE1IDEwOjUyDQo+PiBUbzogQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+DQo+ PiBDYzogRElTUEFUQ0ggbGlzdCA8ZGlzcGF0Y2hAaWV0Zi5vcmc+OyBTSVBDT1JFIDxzaXBjb3Jl QGlldGYub3JnPjsgDQo+PiBDdWxsZW4gSmVubmluZ3MgPGZsdWZmeUBpaWkuY2E+DQo+PiBTdWJq ZWN0OiBSZTogW3NpcGNvcmVdIFtkaXNwYXRjaF0gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRd IFJGQzczMTUNCj4+ICg0NDc0KQ0KPj4NCj4+IEhpLA0KPj4NCj4+IFNvLCBzaGFsbCBJIGFkZHJl c3MgdGhlIGRyYWZ0IHRvIHNvbWUgV0csIG9yPw0KPj4NCj4+IGRyYWZ0LWhvbG1iZXJnLWRpc3Bh dGNoID8NCj4+DQo+PiBSZWdhcmRzLA0KPj4NCj4+IENocmlzdGVyDQo+Pg0KPj4gU2VudCBmcm9t IG15IFdpbmRvd3MgUGhvbmUNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiBGcm9tOiBCZW4gQ2FtcGJlbGw8bWFpbHRvOmJlbkBub3N0cnVtLmNvbT4NCj4+IFNlbnQ6IOKA jjE0L+KAjjEwL+KAjjIwMTUgMTc6MjENCj4+IFRvOiBDaHJpc3RlciBIb2xtYmVyZzxtYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPj4gQ2M6IEN1bGxlbiBKZW5uaW5nczxt YWlsdG86Zmx1ZmZ5QGlpaS5jYT47IERJU1BBVENIIA0KPj4gbGlzdDxtYWlsdG86ZGlzcGF0Y2hA aWV0Zi5vcmc+OyBTSVBDT1JFPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KPj4gU3ViamVjdDog UmU6IFtzaXBjb3JlXSBbZGlzcGF0Y2hdIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM3 MzE1DQo+PiAoNDQ3NCkNCj4+IE9uIDggT2N0IDIwMTUsIGF0IDIxOjAzLCBDaHJpc3RlciBIb2xt YmVyZyB3cm90ZToNCj4+DQo+Pj4gSGkgQ3VsbGVuLA0KPj4+DQo+Pj4gU28sIHlvdSBhcmUgc3Vn Z2VzdGluZyBhIFNJUENPUkUgZHJhZnQgdGhhdCB1cGRhdGVzIHRoZSBBQk5GPw0KPj4NCj4+IFRo aXMgaXMgd2hlcmUgdGhlIGNoYWlycyB3aWxsIHBvaW50IG91dCB0aGF0IHNwZWNpYWwtcHVycG9z ZSANCj4+IGV4dGVuc2lvbnMgYXJlIGdlbmVyYWxseSBub3QgaW4gc2NvcGUgZm9yIHNpcGNvcmUg Oi0pIElmIHNvLCB0aGlzIA0KPj4gbWlnaHQgY291bGQgYWxzbyBiZSBkb25lIGFzIEFEIHNwb25z b3JlZC4NCj4+DQo+PiBCZW4uDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IGRpc3BhdGNoIG1haWxpbmcgbGlzdA0KPiBkaXNwYXRjaEBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRpc3BhdGNo IG1haWxpbmcgbGlzdA0KPiBkaXNwYXRjaEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo+DQoNCg== From nobody Tue Oct 27 15:15:51 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 6FE151B29D0; Tue, 27 Oct 2015 15:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 xMl__eQAH37N; Tue, 27 Oct 2015 15:15:48 -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 CBC741AD376; Tue, 27 Oct 2015 15:15:47 -0700 (PDT) X-AuditID: c1b4fb2d-f79626d000004282-9b-562ff7914343 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C3.43.17026.197FF265; Tue, 27 Oct 2015 23:15:46 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0248.002; Tue, 27 Oct 2015 23:15:45 +0100 From: Christer Holmberg To: Christer Holmberg , "A. Jean Mahoney" , Ben Campbell Thread-Topic: [sipcore] [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [Technical Errata Reported] RFC7315 (4474)] Thread-Index: AQHREQM1QjJqAdDgkUaWrjRCEz8rFJ5/594A Date: Tue, 27 Oct 2015 22:15:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37B9501A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37B62FC0@ESESSMB209.ericsson.se> <90429FC5-4199-4386-8CEE-F7F9E45420CE@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B6907F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B691E1@ESESSMB209.ericsson.se> <562FF092.3090605@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B94F9B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B94F9B@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.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM+Jvre6k7/phBg8mslrM7zzNbrF00gJW i4bOlawWX39sYnNg8Viy5CeTx6ydT1gCmKK4bFJSczLLUov07RK4Mhaf2stY0GdR0b9wO0sD 4xWzLkZODgkBE4lHuw4yQ9hiEhfurWfrYuTiEBI4wijx9d8JZghnMaNER+9/1i5GDg42AQuJ 7n/aIHERgUZGiUl9u9hB4swCjhLT1mSDDBIWaGeUeLAoG6Kmg1HiYcd3FpAaEQEjicVN0SA1 LAKqElcvrGIHsXkFfCX6LnawgdhCAu+ZJF7+4QSxOQX8JLpfHwGLMwId9/3UGiYQm1lAXOLW k/lMEEcLSCzZcx7qAVGJl4//sULYShKLbn9mgjhNU2L9Ln2IVkWJKd0PodYKSpyc+YRlAqPY LCRTZyF0zELSMQtJxwJGllWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgfF0cMtv3R2Mq187 HmIU4GBU4uE1qNALE2JNLCuuzD3EKMHBrCTC25OtHybEm5JYWZValB9fVJqTWnyIUZqDRUmc t4XpQaiQQHpiSWp2ampBahFMlomDU6qBcb6Yauc7wdcnDx0K4JffnT+18aj8A4EFu5Oy//+7 MqPg4oylhT+jNxX5iF9Qm3dle8Z80Zf/22crSesu3bNuMXeLS+7nznOiXuziqp895NhO6Yg5 +53cf5FlrUF34F4hRd3eSYZLg8tnzdkQ3aD71lcx3W3xDn1zP9ugUycuzZpb27eydLmSqBJL cUaioRZzUXEiAGJruHKjAgAA Archived-At: Cc: DISPATCH list , SIPCORE Subject: Re: [sipcore] [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [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: Tue, 27 Oct 2015 22:15:50 -0000 SGksDQoNClRoZSBuZXcgdmVyc2lvbiBjYW4gYmUgc2VlbiBhdDogaHR0cHM6Ly9naXRodWIuY29t L2NkaDR1L2RyYWZ0LXBhbmktYWJuZg0KDQpJJ2xsIHN1Ym1pdCBpdCB3aGVuIHRoZSBzdWJtaXNz aW9uIHdpbmRvdyBvcGVucy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KU2VudDogMjggT2N0b2JlciAy MDE1IDAwOjAzDQpUbzogQS4gSmVhbiBNYWhvbmV5IDxtYWhvbmV5QG5vc3RydW0uY29tPjsgQmVu IENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+DQpDYzogRElTUEFUQ0ggbGlzdCA8ZGlzcGF0Y2hA aWV0Zi5vcmc+OyBTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzaXBj b3JlXSBbZGlzcGF0Y2hdIERyYWZ0IG5ldzogZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcGFuaS1h Ym5mLTAwIFt3YXM6IFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM3MzE1ICg0NDc0KV0N Cg0KSGkgSmVhbiwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzISBJIHdpbGwgdXBkYXRlIHRo ZSBkcmFmdCBhY2NvcmRpbmcgdG8geW91ciBzdWdnZXN0aW9ucy4NCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEEuIEplYW4gTWFob25l eSBbbWFpbHRvOm1haG9uZXlAbm9zdHJ1bS5jb21dDQpTZW50OiAyNyBPY3RvYmVyIDIwMTUgMjM6 NDYNClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t PjsgQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+DQpDYzogRElTUEFUQ0ggbGlzdCA8ZGlz cGF0Y2hAaWV0Zi5vcmc+OyBTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtkaXNwYXRjaF0gRHJhZnQgbmV3OiBkcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1wYW5pLWFibmYt MDAgW3dhczogW3NpcGNvcmVdIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM3MzE1ICg0 NDc0KV0NCg0KSGkgQ2hyaXN0ZXIsDQoNClRoZSBkcmFmdCBsb29rcyBnb29kIHRvIG1lLiBKdXN0 IGEgZmV3IG5pdHM6DQoNCjEuIEludHJvZHVjdGlvbg0KDQoybmQgcGFyYWdyYXBoOiAicmVxdWly ZXMgbmV3IHZhbHVlcyBhcmUgcmVxdWlyZWQiID0+ICJyZXF1aXJlcyBuZXcgdmFsdWVzIi4NCg0K NHRoIHBhcmFncmFwaDogImhhdmUgYmVlbiBmb2xsb3dlZCIgPT4gImhhdmUgYmVlbiBkZWZpbmVk Ig0KDQpZb3UgbWF5IGFsc28gY29uc2lkZXIgYWRkaW5nIGEgcmVmZXJlbmNlIHRvIFRTIDI0LjIy OSwgd2hpY2ggZGVmaW5lcyB2YWx1ZXMgZm9yIGFjY2Vzcy1pbmZvLCB0byB0aGUgNHRoIHBhcmFn cmFwaC4NCg0KVGhhbmtzIQ0KDQpKZWFuDQoNCg0KT24gMTAvMTgvMTUgMjoxMCBQTSwgQ2hyaXN0 ZXIgSG9sbWJlcmcgd3JvdGU6DQo+IEhpLA0KPg0KPiBJJ3ZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJz aW9uLCAtMDEsIHdoZXJlIHRoZSBjYXRlZ29yeSBpcyBjaGFuZ2VkIHRvICdJbmZvcm1hdGlvbmFs Jy4NCj4NCj4gUmVnYXJkcywNCj4NCj4gQ2hyaXN0ZXINCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogZGlzcGF0Y2ggW21haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgDQo+IENocmlzdGVyIEhvbG1iZXJnDQo+IFNlbnQ6IDE4IE9jdG9i ZXIgMjAxNSAyMTo1OQ0KPiBUbzogQmVuIENhbXBiZWxsIDxiZW5Abm9zdHJ1bS5jb20+DQo+IENj OiBESVNQQVRDSCBsaXN0IDxkaXNwYXRjaEBpZXRmLm9yZz47IFNJUENPUkUgPHNpcGNvcmVAaWV0 Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIERyYWZ0IG5ldzogDQo+IGRyYWZ0LWhv bG1iZXJnLWRpc3BhdGNoLXBhbmktYWJuZi0wMCBbd2FzOiBbc2lwY29yZV0gW1RlY2huaWNhbCBF cnJhdGEgDQo+IFJlcG9ydGVkXSBSRkM3MzE1ICg0NDc0KV0NCj4NCj4gSGksDQo+DQo+PiBJZiA3 MzE1IGlzIGluZm9ybWF0aW9uYWwsIHdoeSBkb2VzIHRoZSB1cGRhdGUgbmVlZCB0byBiZSBzdGFu ZGFyZHMgdHJhY2s/DQo+DQo+IEdvb2QgcG9pbnQgLSBJIGd1ZXNzIGl0IGRvZXNuJ3QgaGF2ZSB0 byA6KQ0KPg0KPiBSZWdhcmRzLA0KPg0KPiBDaHJpc3Rlcg0KPg0KPg0KPiBPbiAxOCBPY3QgMjAx NSwgYXQgNjo0OSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+DQo+PiBIaSwNCj4+DQo+PiBC YXNlZCBvbiBCZW7igJlzIGd1aWRhbmNlLCBJ4oCZdmUgc3VibWl0dGVkIGEgZHJhZnQgd2hpY2gg bWFrZXMgdGhlIEFCTkYgDQo+PiB1cGRhdGUuDQo+Pg0KPj4gTk9URTogQXMgUkZDIDczMTUgaXMg YW4gSW5mb3JtYXRpb25hbCBSRkMsIEkgaGFkIHRvIGFkZCB0aGUgUkZDIGFzIGFuIA0KPj4gSW5m b3JtYXRpdmUgcmVmZXJlbmNlIGluIHRoZSBkcmFmdCwgaW4gb3JkZXIgdG8gcGFzcyB0aGUgSWRu aXRzIGNoZWNrLg0KPj4NCj4+DQo+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaG9sbWJl cmctZGlzcGF0Y2gtcGFuaS1hYm5mLTAwLnR4dA0KPj4NCj4+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgQ2hyaXN0ZXIgSG9sbWJlcmcgYW5kIHBvc3RlZCB0byANCj4+IHRoZSBJ RVRGIHJlcG9zaXRvcnkuDQo+Pg0KPj4NCj4+DQo+PiBOYW1lOiAgICAgICAgICAgICAgICAgZHJh ZnQtaG9sbWJlcmctZGlzcGF0Y2gtcGFuaS1hYm5mDQo+Pg0KPj4gUmV2aXNpb246ICAgICAgICAg ICAgMDANCj4+DQo+PiBUaXRsZTogICAgICAgICAgICAgICAgICAgIFAtQWNjZXNzLU5ldHdvcmst SW5mbyBBQk5GIFVwZGF0ZQ0KPj4NCj4+IERvY3VtZW50IGRhdGU6ICAgICAgICAgICAgICAyMDE1 LTEwLTE4DQo+Pg0KPj4gR3JvdXA6ICAgICAgICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lv bg0KPj4NCj4+IFBhZ2VzOiAgICAgICAgICAgICAgICAgNA0KPj4NCj4+IFVSTDoNCj4+IGh0dHBz Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1w YW5pLWFibg0KPj4gZg0KPj4gLTAwLnR4dA0KPj4NCj4+IFN0YXR1czoNCj4+IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhvbG1iZXJnLWRpc3BhdGNoLXBhbmktYWJuZi8N Cj4+DQo+PiBIdG1saXplZDoNCj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1o b2xtYmVyZy1kaXNwYXRjaC1wYW5pLWFibmYtMDANCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gQWJz dHJhY3Q6DQo+Pg0KPj4gVGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQyA3MzE1LCBieSBtb2RpZnlp bmcgdGhlIGV4dGVuc2lvbi1hY2Nlc3MtDQo+Pg0KPj4gaW5mbyBwYXJ0IG9mIHRoZSBQLUFjY2Vz cy1OZXR3b3JrLUluZm8gaGVhZGVyIGZpZWxkIEF1Z21lbnRlZCBCYWNrdXMtDQo+Pg0KPj4gTmF1 ciBGb3JtIChBQk5GKS4NCj4+DQo+Pg0KPj4gUmVnYXJkcywNCj4+DQo+PiBDaHJpc3Rlcg0KPj4N Cj4+DQo+Pg0KPj4NCj4+IEZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RlciANCj4+IEhvbG1iZXJnDQo+PiBTZW50OiAxOCBP Y3RvYmVyIDIwMTUgMTA6NTINCj4+IFRvOiBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbT4N Cj4+IENjOiBESVNQQVRDSCBsaXN0IDxkaXNwYXRjaEBpZXRmLm9yZz47IFNJUENPUkUgPHNpcGNv cmVAaWV0Zi5vcmc+OyANCj4+IEN1bGxlbiBKZW5uaW5ncyA8Zmx1ZmZ5QGlpaS5jYT4NCj4+IFN1 YmplY3Q6IFJlOiBbc2lwY29yZV0gW2Rpc3BhdGNoXSBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRl ZF0gUkZDNzMxNQ0KPj4gKDQ0NzQpDQo+Pg0KPj4gSGksDQo+Pg0KPj4gU28sIHNoYWxsIEkgYWRk cmVzcyB0aGUgZHJhZnQgdG8gc29tZSBXRywgb3I/DQo+Pg0KPj4gZHJhZnQtaG9sbWJlcmctZGlz cGF0Y2ggPw0KPj4NCj4+IFJlZ2FyZHMsDQo+Pg0KPj4gQ2hyaXN0ZXINCj4+DQo+PiBTZW50IGZy b20gbXkgV2luZG93cyBQaG9uZQ0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+IEZyb206IEJlbiBDYW1wYmVsbDxtYWlsdG86YmVuQG5vc3RydW0uY29tPg0KPj4gU2VudDog 4oCOMTQv4oCOMTAv4oCOMjAxNSAxNzoyMQ0KPj4gVG86IENocmlzdGVyIEhvbG1iZXJnPG1haWx0 bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQo+PiBDYzogQ3VsbGVuIEplbm5pbmdz PG1haWx0bzpmbHVmZnlAaWlpLmNhPjsgRElTUEFUQ0ggDQo+PiBsaXN0PG1haWx0bzpkaXNwYXRj aEBpZXRmLm9yZz47IFNJUENPUkU8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0 OiBSZTogW3NpcGNvcmVdIFtkaXNwYXRjaF0gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJG QzczMTUNCj4+ICg0NDc0KQ0KPj4gT24gOCBPY3QgMjAxNSwgYXQgMjE6MDMsIENocmlzdGVyIEhv bG1iZXJnIHdyb3RlOg0KPj4NCj4+PiBIaSBDdWxsZW4sDQo+Pj4NCj4+PiBTbywgeW91IGFyZSBz dWdnZXN0aW5nIGEgU0lQQ09SRSBkcmFmdCB0aGF0IHVwZGF0ZXMgdGhlIEFCTkY/DQo+Pg0KPj4g VGhpcyBpcyB3aGVyZSB0aGUgY2hhaXJzIHdpbGwgcG9pbnQgb3V0IHRoYXQgc3BlY2lhbC1wdXJw b3NlIA0KPj4gZXh0ZW5zaW9ucyBhcmUgZ2VuZXJhbGx5IG5vdCBpbiBzY29wZSBmb3Igc2lwY29y ZSA6LSkgSWYgc28sIHRoaXMgDQo+PiBtaWdodCBjb3VsZCBhbHNvIGJlIGRvbmUgYXMgQUQgc3Bv bnNvcmVkLg0KPj4NCj4+IEJlbi4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQo+IGRpc3BhdGNoQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZGlzcGF0 Y2ggbWFpbGluZyBsaXN0DQo+IGRpc3BhdGNoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCj4NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3Jl QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUN Cg== From nobody Tue Oct 27 15:18:58 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 E56A11B29F7; Tue, 27 Oct 2015 15:18:56 -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 Xlhb7UQ8FJaX; Tue, 27 Oct 2015 15:18:55 -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 093201B29D8; Tue, 27 Oct 2015 15:18:54 -0700 (PDT) Received: from mutabilis-2.local (pool-71-164-199-31.dllstx.fios.verizon.net [71.164.199.31]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9RMIok4088109 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 27 Oct 2015 17:18:51 -0500 (CDT) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-164-199-31.dllstx.fios.verizon.net [71.164.199.31] claimed to be mutabilis-2.local To: Christer Holmberg , Ben Campbell References: <7594FB04B1934943A5C02806D1A2204B37B62FC0@ESESSMB209.ericsson.se> <90429FC5-4199-4386-8CEE-F7F9E45420CE@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B6907F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B691E1@ESESSMB209.ericsson.se> <562FF092.3090605@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37B94F9B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37B9501A@ESESSMB209.ericsson.se> From: "A. Jean Mahoney" Message-ID: <562FF845.4000404@nostrum.com> Date: Tue, 27 Oct 2015 17:18:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37B9501A@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: DISPATCH list , SIPCORE Subject: Re: [sipcore] [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [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: Tue, 27 Oct 2015 22:18:57 -0000 Thanks for the quick update! Looks good. Jean On 10/27/15 5:15 PM, Christer Holmberg wrote: > Hi, > > The new version can be seen at: https://github.com/cdh4u/draft-pani-abnf > > I'll submit it when the submission window opens. > > Regards, > > Christer > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 28 October 2015 00:03 > To: A. Jean Mahoney ; Ben Campbell > Cc: DISPATCH list ; SIPCORE > Subject: Re: [sipcore] [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [Technical Errata Reported] RFC7315 (4474)] > > Hi Jean, > > Thanks for your comments! I will update the draft according to your suggestions. > > Regards, > > Christer > > -----Original Message----- > From: A. Jean Mahoney [mailto:mahoney@nostrum.com] > Sent: 27 October 2015 23:46 > To: Christer Holmberg ; Ben Campbell > Cc: DISPATCH list ; SIPCORE > Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata Reported] RFC7315 (4474)] > > Hi Christer, > > The draft looks good to me. Just a few nits: > > 1. Introduction > > 2nd paragraph: "requires new values are required" => "requires new values". > > 4th paragraph: "have been followed" => "have been defined" > > You may also consider adding a reference to TS 24.229, which defines values for access-info, to the 4th paragraph. > > Thanks! > > Jean > > > On 10/18/15 2:10 PM, Christer Holmberg wrote: >> Hi, >> >> I've submitted a new version, -01, where the category is changed to 'Informational'. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of >> Christer Holmberg >> Sent: 18 October 2015 21:59 >> To: Ben Campbell >> Cc: DISPATCH list ; SIPCORE >> Subject: Re: [dispatch] Draft new: >> draft-holmberg-dispatch-pani-abnf-00 [was: [sipcore] [Technical Errata >> Reported] RFC7315 (4474)] >> >> Hi, >> >>> If 7315 is informational, why does the update need to be standards track? >> >> Good point - I guess it doesn't have to :) >> >> Regards, >> >> Christer >> >> >> On 18 Oct 2015, at 6:49, Christer Holmberg wrote: >> >>> Hi, >>> >>> Based on Ben’s guidance, I’ve submitted a draft which makes the ABNF >>> update. >>> >>> NOTE: As RFC 7315 is an Informational RFC, I had to add the RFC as an >>> Informative reference in the draft, in order to pass the Idnits check. >>> >>> >>> A new version of I-D, draft-holmberg-dispatch-pani-abnf-00.txt >>> >>> has been successfully submitted by Christer Holmberg and posted to >>> the IETF repository. >>> >>> >>> >>> Name: draft-holmberg-dispatch-pani-abnf >>> >>> Revision: 00 >>> >>> Title: P-Access-Network-Info ABNF Update >>> >>> Document date: 2015-10-18 >>> >>> Group: Individual Submission >>> >>> Pages: 4 >>> >>> URL: >>> https://www.ietf.org/internet-drafts/draft-holmberg-dispatch-pani-abn >>> f >>> -00.txt >>> >>> Status: >>> https://datatracker.ietf.org/doc/draft-holmberg-dispatch-pani-abnf/ >>> >>> Htmlized: >>> https://tools.ietf.org/html/draft-holmberg-dispatch-pani-abnf-00 >>> >>> >>> >>> >>> >>> Abstract: >>> >>> This document updates RFC 7315, by modifying the extension-access- >>> >>> info part of the P-Access-Network-Info header field Augmented Backus- >>> >>> Naur Form (ABNF). >>> >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer >>> Holmberg >>> Sent: 18 October 2015 10:52 >>> To: Ben Campbell >>> Cc: DISPATCH list ; SIPCORE ; >>> Cullen Jennings >>> Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 >>> (4474) >>> >>> Hi, >>> >>> So, shall I address the draft to some WG, or? >>> >>> draft-holmberg-dispatch ? >>> >>> Regards, >>> >>> Christer >>> >>> Sent from my Windows Phone >>> ________________________________ >>> From: Ben Campbell >>> Sent: ‎14/‎10/‎2015 17:21 >>> To: Christer Holmberg >>> Cc: Cullen Jennings; DISPATCH >>> list; SIPCORE >>> Subject: Re: [sipcore] [dispatch] [Technical Errata Reported] RFC7315 >>> (4474) >>> On 8 Oct 2015, at 21:03, Christer Holmberg wrote: >>> >>>> Hi Cullen, >>>> >>>> So, you are suggesting a SIPCORE draft that updates the ABNF? >>> >>> This is where the chairs will point out that special-purpose >>> extensions are generally not in scope for sipcore :-) If so, this >>> might could also be done as AD sponsored. >>> >>> Ben. >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Sat Oct 31 20:09:11 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 6C2351B4BD2; Sat, 31 Oct 2015 18:18:41 -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 YEmSBazXqsRg; Sat, 31 Oct 2015 18:18:40 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 138951B4BCF; Sat, 31 Oct 2015 18:18:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1CA60180006; Sat, 31 Oct 2015 18:17:51 -0700 (PDT) To: ietf.hanserik@gmail.com, mary.ietf.barnes@gmail.com, francois.audet@skype.net, shida@ntt-at.com, ietf.hanserik@gmail.com, christer.holmberg@ericsson.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151101011751.1CA60180006@rfc-editor.org> Date: Sat, 31 Oct 2015 18:17:50 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Sat, 31 Oct 2015 20:09:10 -0700 Cc: sipcore@ietf.org, alissa@cooperw.in, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] [Errata Rejected] RFC7044 (4181) 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: Sun, 01 Nov 2015 01:18:41 -0000 The following errata report has been rejected for RFC7044, "An Extension to the Session Initiation Protocol (SIP) for Request History Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7044&eid=4181 -------------------------------------- Status: Rejected Type: Editorial Reported by: Hans Erik van Elburg Date Reported: 2014-11-14 Rejected by: Alissa Cooper (IESG) Section: 9.3 Original Text ------------- 9.3. Receiving a Response with History-Info or Request Timeouts Corrected Text -------------- 9.3. Receiving a Response or Request times out Notes ----- The title of section 9.3 is misleading in the sense that it suggests that it only applies to responses that contain the History-Info header. This is not correct, it applies to all responses when the RFC7044 applies. --VERIFIER NOTES-- This errata indicates an editorial preference rather than an error. -------------------------------------- RFC7044 (draft-ietf-sipcore-rfc4244bis-12) -------------------------------------- Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Publication Date : February 2014 Author(s) : M. Barnes, F. Audet, S. Schubert, J. van Elburg, C. Holmberg Category : PROPOSED STANDARD Source : Session Initiation Protocol Core RAI Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG