From nobody Tue Dec 1 06:35: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 C718D1A8F3E for ; Tue, 1 Dec 2015 06:35:08 -0800 (PST) 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 px5UCckyOvXM for ; Tue, 1 Dec 2015 06:35:07 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2241A0127 for ; Tue, 1 Dec 2015 06:35:07 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-08v.sys.comcast.net with comcast id oEb51r0022XD5SV01Eb6PM; Tue, 01 Dec 2015 14:35:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-20v.sys.comcast.net with comcast id oEb51r00U3KdFy101Eb6aG; Tue, 01 Dec 2015 14:35:06 +0000 To: sipcore@ietf.org References: <39B5E4D390E9BD4890E2B3107900610112AEC437@ESESSMB301.ericsson.se> From: Paul Kyzivat Message-ID: <565DB018.3000900@alum.mit.edu> Date: Tue, 1 Dec 2015 09:35:04 -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: <39B5E4D390E9BD4890E2B3107900610112AEC437@ESESSMB301.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=1448980506; bh=qbT1YgkicXYK+BydM5md9aY/6d7oKAbLTlsZ96spYj8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=wDi3W5Y9kXYmTeREEmK22T8m4JbyjJuFbE6HzaPir5UdbW4dKhdRlFcRxGVu7olD3 xpGdfCQUukgHu6h6z6Nu4NwFddDrVsvy66vzy8VB1Cy+Ikhci4ZTwBHmr0QIGP0608 0RrC/HHCSnpaSyGSzcXoexCrmdqqyTzuxKAB0oO7G0jwNsSQxKGJbNgxnwN9gP5Qn+ EQ5Lheetlqpr85ZYOlM4F04FiWGx0ZqkzQS1HrIz/cYbRtjkvaLRwKpK9LJzQXSPrI 38gnWjXmS7JUXdMviMwi2jnZNo5WtBpT5c+1nDPeNeB432trQn+Z2j4LGlDVz81X/7 kzA/x5He8R3dQ== Archived-At: Subject: Re: [sipcore] A new SIP header fields with "P-" name 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, 01 Dec 2015 14:35:09 -0000 On 12/1/15 2:00 AM, Ivo Sedlacek wrote: > Hello, > > in the last 3GPP CT1 WG meeting, 3GPP CT1 WG was unable to conclude > whether it is possible to define and to use a new "P-"header field. > > Some believed that IANA registration of a new "P-" header field is not > possible any more due to RFC5727. Others believed that IANA registration > of a new "P-" header field is possible as long as someone already > implemented and deployed such header field (even if it was done recently). My understanding of 5727 is that when it refers to "existing", it means those existing prior to the publication of 5727. Anybody starting to use a new P- header after that time should have known they were doing something wrong. Thanks, Paul > Can you please provide guidance whether IANA registration of a new "P-" > header field is likely? Thanks. > > RFC5727 states: > > --------------------------- > > New > > proposals to document SIP header fields of an experimental or private > > nature, however, shall not use the "P-" prefix (unless existing > > deployments or standards use the prefix already, in which case they > > may be admitted as grandfathered cases at the discretion of the > > Designated Expert). > > --------------------------- > > Kind regards > > Ivo Sedlacek > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Tue Dec 1 06:41:22 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 63BAD1A914E for ; Tue, 1 Dec 2015 06:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 piRpVYOpFNYG for ; Tue, 1 Dec 2015 06:41:20 -0800 (PST) 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 00F751A914A for ; Tue, 1 Dec 2015 06:41:19 -0800 (PST) Received: from [192.168.1.85] (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tB1EfGfD084954 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 1 Dec 2015 08:41:16 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be [192.168.1.85] To: Paul Kyzivat , sipcore@ietf.org References: <39B5E4D390E9BD4890E2B3107900610112AEC437@ESESSMB301.ericsson.se> <565DB018.3000900@alum.mit.edu> From: Adam Roach Message-ID: <565DB18D.2080003@nostrum.com> Date: Tue, 1 Dec 2015 08:41:17 -0600 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: <565DB018.3000900@alum.mit.edu> Content-Type: multipart/alternative; boundary="------------050309040609030500080406" Archived-At: Subject: Re: [sipcore] A new SIP header fields with "P-" name 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, 01 Dec 2015 14:41:21 -0000 This is a multi-part message in MIME format. --------------050309040609030500080406 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit [as participant] On 12/1/15 8:35 AM, Paul Kyzivat wrote: > On 12/1/15 2:00 AM, Ivo Sedlacek wrote: >> Hello, >> >> in the last 3GPP CT1 WG meeting, 3GPP CT1 WG was unable to conclude >> whether it is possible to define and to use a new "P-"header field. >> >> Some believed that IANA registration of a new "P-" header field is not >> possible any more due to RFC5727. Others believed that IANA registration >> of a new "P-" header field is possible as long as someone already >> implemented and deployed such header field (even if it was done >> recently). > > My understanding of 5727 is that when it refers to "existing", it > means those existing prior to the publication of 5727. Anybody > starting to use a new P- header after that time should have known they > were doing something wrong. That matches my understanding as well. The timeframe for "already" in the sentence "existingdeployments or standards use the prefix already" is March of 2010. Any other interpretation of this clause is pretty meaningless. /a --------------050309040609030500080406 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
[as participant]

On 12/1/15 8:35 AM, Paul Kyzivat wrote:
On 12/1/15 2:00 AM, Ivo Sedlacek wrote:
Hello,

in the last 3GPP CT1 WG meeting, 3GPP CT1 WG was unable to conclude
whether it is possible to define and to use a new "P-"header field.

Some believed that IANA registration of a new "P-" header field is not
possible any more due to RFC5727. Others believed that IANA registration
of a new "P-" header field is possible as long as someone already
implemented and deployed such header field  (even if it was done recently).

My understanding of 5727 is that when it refers to "existing", it means those existing prior to the publication of 5727. Anybody starting to use a new P- header after that time should have known they were doing something wrong.

That matches my understanding as well. The timeframe for "already" in the sentence "existing deployments or standards use the prefix already" is March of 2010. Any other interpretation of this clause is pretty meaningless.

/a
--------------050309040609030500080406-- From nobody Tue Dec 1 11:01:16 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEECF1B2F24 for ; Tue, 1 Dec 2015 11:01:14 -0800 (PST) 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 IiPXPxwBWVEi for ; Tue, 1 Dec 2015 11:01:13 -0800 (PST) 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 658B61B2F22 for ; Tue, 1 Dec 2015 11:01:13 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tB1J192H010166 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 1 Dec 2015 13:01:09 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Ivo Sedlacek" Date: Tue, 01 Dec 2015 13:01:09 -0600 Message-ID: <7699C626-BCC4-4B8F-AB14-0C81D7BE62D7@nostrum.com> In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112AEC437@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B3107900610112AEC437@ESESSMB301.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A new SIP header fields with "P-" name 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, 01 Dec 2015 19:01:15 -0000 Hi, Can you offer context around the question? That is, why would someone be contemplating a new header starting with "P-"? Or is this something old? Thanks! Ben. On 1 Dec 2015, at 1:00, Ivo Sedlacek wrote: > Hello, > > > > in the last 3GPP CT1 WG meeting, 3GPP CT1 WG was unable to conclude > whether it is possible to define and to use a new "P-"header field. > > > > Some believed that IANA registration of a new "P-" header field is not > possible any more due to RFC5727. Others believed that IANA > registration of a new "P-" header field is possible as long as someone > already implemented and deployed such header field (even if it was > done recently). > > > > Can you please provide guidance whether IANA registration of a new > "P-" header field is likely? Thanks. > > > > RFC5727 states: > > --------------------------- > > New > > proposals to document SIP header fields of an experimental or private > > nature, however, shall not use the "P-" prefix (unless existing > > deployments or standards use the prefix already, in which case they > > may be admitted as grandfathered cases at the discretion of the > > Designated Expert). > > --------------------------- > > > > Kind regards > > > > Ivo Sedlacek > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Dec 2 00:18:52 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5A81B3444 for ; Wed, 2 Dec 2015 00:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 3_HZJkUS3tXu for ; Wed, 2 Dec 2015 00:18:49 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 469841ACE10 for ; Wed, 2 Dec 2015 00:18:49 -0800 (PST) X-AuditID: c1b4fb25-f79876d0000011ee-a8-565ea966acd8 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 4F.A4.04590.669AE565; Wed, 2 Dec 2015 09:18:47 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0248.002; Wed, 2 Dec 2015 09:18:06 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] A new SIP header fields with "P-" name Thread-Index: AdErb0NStzAvzI7DQoGlsVH1re72CwAzdJsAACc2CJA= Date: Wed, 2 Dec 2015 08:18:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C797CE@ESESSMB209.ericsson.se> References: <39B5E4D390E9BD4890E2B3107900610112AEC437@ESESSMB301.ericsson.se> <565DB018.3000900@alum.mit.edu> In-Reply-To: <565DB018.3000900@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.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM2J7uG76yrgwg6sTuS1WbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjxP3z7AXr+Svmzp7F1sA4j6eLkYNDQsBE Yv7dxC5GTiBTTOLCvfVsXYxcHEIChxklfk57zgLhLGaUWPzvEBtIA5uAhUT3P22QBhGBQImr SyYwg9jCArYSr25cYYOI20ncOfOHHcK2kphz/R9YDYuAikTTlH6wOK+Ar8ThI4vA4kIC+RLr tk1iAbE5BXQkNrxcCxZnBDro+6k1TCA2s4C4xK0n85kgDhWQWLLnPDOELSrx8vE/VghbSeLH hkssEPU6Egt2f2KDsLUlli18zQyxV1Di5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxShanFqc lJtuZKyXWpSZXFycn6eXl1qyiREYJQe3/FbdwXj5jeMhRgEORiUe3gK1uDAh1sSy4srcQ4wS HMxKIrxeMkAh3pTEyqrUovz4otKc1OJDjNIcLErivM1MD0KFBNITS1KzU1MLUotgskwcnFIN jI0f2/7pcxzMSsq6sE5eeNXrpzW/Hn1dU9N7VPydpktpwobGnAuT8yJY3qeutlb+v+b6wROa hwOeL/vy49/m97m/nEpt99jom5UF65xv9v1SFz+3xeX4fu5P6/VaHr3xPsx1+bzckdqDJXnT BMJ9mtdFp/0uFPiX4i2x5FzT+cUiSzYqHhMyeKvEUpyRaKjFXFScCABplqQJjgIAAA== Archived-At: Subject: Re: [sipcore] A new SIP header fields with "P-" name 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, 02 Dec 2015 08:18:51 -0000 Hi, I have the same understanding as Adam and Paul. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 1. joulukuuta 2015 16:35 To: sipcore@ietf.org Subject: Re: [sipcore] A new SIP header fields with "P-" name On 12/1/15 2:00 AM, Ivo Sedlacek wrote: > Hello, > > in the last 3GPP CT1 WG meeting, 3GPP CT1 WG was unable to conclude=20 > whether it is possible to define and to use a new "P-"header field. > > Some believed that IANA registration of a new "P-" header field is not=20 > possible any more due to RFC5727. Others believed that IANA=20 > registration of a new "P-" header field is possible as long as someone=20 > already implemented and deployed such header field (even if it was done = recently). My understanding of 5727 is that when it refers to "existing", it means tho= se existing prior to the publication of 5727. Anybody starting to use a new= P- header after that time should have known they were doing something wron= g. Thanks, Paul > Can you please provide guidance whether IANA registration of a new "P-" > header field is likely? Thanks. > > RFC5727 states: > > --------------------------- > > New > > proposals to document SIP header fields of an experimental or=20 > private > > nature, however, shall not use the "P-" prefix (unless existing > > deployments or standards use the prefix already, in which case=20 > they > > may be admitted as grandfathered cases at the discretion of the > > Designated Expert). > > --------------------------- > > Kind regards > > Ivo Sedlacek > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Dec 2 00:36: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 B0AD31B3461 for ; Wed, 2 Dec 2015 00:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRMKqsBwzsYN for ; Wed, 2 Dec 2015 00:36:40 -0800 (PST) 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 AAEE91ACF03 for ; Wed, 2 Dec 2015 00:36:39 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-b3-565ead95cdf9 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 0D.3E.05149.59DAE565; Wed, 2 Dec 2015 09:36:37 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.31]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Wed, 2 Dec 2015 09:36:37 +0100 From: Ivo Sedlacek To: Ben Campbell Thread-Topic: [sipcore] A new SIP header fields with "P-" name Thread-Index: AdErb0NStzAvzI7DQoGlsVH1re72CwA8v5OAAB6EnKA= Date: Wed, 2 Dec 2015 08:36:36 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112AEE460@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B3107900610112AEC437@ESESSMB301.ericsson.se> <7699C626-BCC4-4B8F-AB14-0C81D7BE62D7@nostrum.com> In-Reply-To: <7699C626-BCC4-4B8F-AB14-0C81D7BE62D7@nostrum.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B3107900610112AEE460ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2K7nO7UtXFhBsfXmVrM7zzNbvH1xyY2 ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugSvjYv8/loLX6hU/vr5mamDcpNTFyMkhIWAi 0fGkgw3CFpO4cG89kM3FISRwmFFi6eo5TBDOIkaJr63XmUGq2AT0JCZuOcIKYosIKEk8b97K AmIzC2hKPNq5lwnEFhawlXh14wobRI2dxJ0zf9i7GDmAbCuJOxMdQMIsAioSUxs2gZXwCvhK tDU+gtrVxCgxc/dSRpAEp4C9RNfSWWB7GQVkJa7+6WWE2CUucevJfCaIqwUkluw5zwxhi0q8 fPyPFWSXBNBt07amQZTnS3xp6meC2CUocXLmE5YJjKKzkEyahaRsFpIyiLiOxILdn9ggbG2J ZQtfM8PYZw48ZkIWX8DIvopRtDi1OCk33chIL7UoM7m4OD9PLy+1ZBMjMN4ObvltsIPx5XPH Q4wCHIxKPLwFanFhQqyJZcWVuYcYJTiYlUR4vWSAQrwpiZVVqUX58UWlOanFhxilOViUxHmb mR6ECgmkJ5akZqemFqQWwWSZODilGhhV2+KvCl2R0N3TpiQlcZHvufDfxuQpiZ+dv/mdf/zq QcbspIVzwy+KfZkwwSZvUdurZVsWzWBlcWyzEuQxb9jqz7Nr7oljcYkx6/a57pLbsS7KOGtz 24sVTwz27X0Y8rqm9sthu91O9ek/MsP712XGVPWdYVjOZHr1VJacx9HdCyacFPEwzJ6oxFKc kWioxVxUnAgA7wolYbMCAAA= Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A new SIP header fields with "P-" name 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, 02 Dec 2015 08:36:41 -0000 --_000_39B5E4D390E9BD4890E2B3107900610112AEE460ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, > Can you offer context around the question? That is, why would someone be = contemplating a new header starting with "P-"? Or is this something old? 3GPP has a requirement to transport parameters of the last recently seen 3G= PP radio network cell (and how old this information is) when sending a SIP = request over wireless LAN. This gives coarse location of the wireless LAN a= ccess point. This 3GPP requirement was agreed in September 2015. One proposed solution is to define and use P-Cellular-Network-Info header f= ield. I do not represent company providing this proposal. I do not know whether P-Cellular-Network-Info header field has been deploye= d yet and if so, when. In any case, the 3GPP requirement was agreed long af= ter RFC5727 was published. The purpose of my mail was to verify whether the proposal above is feasible= or not, so that this is clear in future CT1 discussions. Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B3107900610112AEE460ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

> Can you offer context around the question? T= hat is, why would someone be contemplating a new header starting with "= ;P-"? Or is this something old?

 

3GPP has a requirement to transport parameters of= the last recently seen 3GPP radio network cell (and how old this informati= on is) when sending a SIP request over wireless LAN. This gives coarse loca= tion of the wireless LAN access point. This 3GPP requirement was agreed in September 2015.

 

One proposed solution is to define and use P-Cell= ular-Network-Info header field.

 

I do not represent company providing this proposa= l.

 

I do not know whether P-Cellular-Network-Info hea= der field has been deployed yet and if so, when. In any case, the 3GPP requ= irement was agreed long after RFC5727 was published.

 

The purpose of my mail was to verify whether the = proposal above is feasible or not, so that this is clear in future CT1 disc= ussions.

 

Kind regards

 

Ivo Sedlacek

 

--_000_39B5E4D390E9BD4890E2B3107900610112AEE460ESESSMB301erics_-- From nobody Thu Dec 3 02:22:29 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EA91B3030 for ; Thu, 3 Dec 2015 02:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 WlkGV1VPCLAT for ; Thu, 3 Dec 2015 02:22:25 -0800 (PST) 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 BC3841A6FA0 for ; Thu, 3 Dec 2015 02:22:24 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-e6-566017dd2782 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id AC.B9.05041.DD710665; Thu, 3 Dec 2015 11:22:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Thu, 3 Dec 2015 11:22:20 +0100 From: Christer Holmberg To: SIPCORE Thread-Topic: Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Thread-Index: AdEttCY/6pwG9PPZQjGda7vzjTcvpg== Date: Thu, 3 Dec 2015 10:22:20 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C7C70D@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37C7C70DESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2K7ru498YQwg7/t7BZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxooTLgWTiiu6Fv9gb2DsTOli5OSQEDCRmHvsDhOELSZx4d56 ti5GLg4hgcOMEmunrmOFcBYzSkxqbgdyODjYBCwkuv9pg5giAnISs2/EgPQKC1RJdN15xQZi iwjUS2z6DlEtIqAncfiIHkiYRUBFovnWNUYQm1fAV6Jj3n8wmxFo7fdTa8BOYBYQl7j1ZD7U OQISS/acZ4awRSVePv4HNlJCQFFieb8cRHm+RP+lL1AjBSVOznzCMoFRaBaSSbOQlM1CUgYR 15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZsYgTG wsEtv612MB587niIUYCDUYmH90N5fJgQa2JZcWXuIUYJDmYlEd5va4FCvCmJlVWpRfnxRaU5 qcWHGKU5WJTEeZuZHoQKCaQnlqRmp6YWpBbBZJk4OKUaGDtm2v5xO3dw9x3e5CSj7Mlrj864 d1Kol2uS7bkvmYv6fAXyji3fNWHRwoO77FvuB9x467h8xe6NbItec1/q4J0g2nahcOYqZr3+ ZU3buH8JLjrouEGQTfe5pf0rGWtx7YmbLP/2aGryxd+w4rxiVjN7vuZakU6zVYrHVj7XCPtc ahfBpbl4hrASS3FGoqEWc1FxIgAP9AbZgQIAAA== Archived-At: Subject: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info 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, 03 Dec 2015 10:22:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37C7C70DESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, 3GPP has been studying possible misalignments between the P- header definit= ions in RFC 3455, RFC 7315 and 3GPP TS 24.229. Rather than posting all the issues in a single e-mail, I will send e-mails = per header field. This e-mail is about P-Access-Network-Info, where two iss= ues were identified. Issue 1) 3GPP TS 24.229 allows PANI in ACK requests Back in 2012, CT1 agreed on a case, related to network provided location in= formation, where PANI is needed in ACK. Now, this should have been introduced in RFC7315 (which wasn't published un= til 2014), but unfortunately the authors (myself included) missed that part= . I assume this cannot be fixed with an errata - it would require an update t= o RFC7315 (probably not a bis, but a draft that updates the affected part(s= ) of RFC7315). Issue 2) RFC 7315 is inconsistent on whether PANI is allowed i= n SIP responses RFC 3455, and 3GPP TS 24.229, allow usage of the PANI header field in SIP r= esponses. However, RFC 7315 is inconsistent. Chapter 4.4 says: "When a UA generates a SIP request or response that it know= s is going to be securely sent to its SIP proxy that is providing servi= ces, the UA inserts a P-Access-Network-Info header field into field t= he SIP message." ... which DOES imply that PANI is allowed in SIP responses. Chapter 4.4.2.1 implies the same thing: "A UA that supports this extension and is willing to disclo= se the related parameters MAY insert the P-Access-Network-Info head= er field in any SIP request or response." However, chapter 5.7. says: 5.7. New Headers "The P-Associated-URI header field can appear in SIP REGISTE= R method and 2xx resonses. The P-Called-Party-ID header field can ap= pear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods= and all responses. The P-Visited-Network-ID header field can appear= in all SIP methods except ACK, BYE, and CANCEL and all responses. = The P-Access-Network-Info header field can appear in all SIP met= hods except ACK and CANCEL. The P-Charging-Vector header field c= an appear in all SIP methods except CANCEL. The P-Charging-Function-A= ddresses header field can appear in all SIP methods except ACK and CA= NCEL." ...where responses, unlike in the case of other header fields, are not expl= icitly mentioned for PANI. I assume this is just a bug in section 5.7, which could be fixed with an er= rata: OLD TEXT: "The P-Access-Network-Info header field can appear in all S= IP methods except ACK and CANCEL." NEW TEXT: "The P-Access-Network-Info header field can appear in all S= IP methods except ACK and CANCEL and all responses." Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37C7C70DESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

3GPP has been studying possible= misalignments between the P- header definitions in RFC 3455, RFC 7315 and = 3GPP TS 24.229.

 

Rather than posting all the iss= ues in a single e-mail, I will send e-mails per header field. This e-mail i= s about P-Access-Network-Info, where two issues were identified.=

 

 

Issue 1)   &n= bsp;         3GPP TS 24.229 allows = PANI in ACK requests

 

Back in 2012, CT1 agreed on a c= ase, related to network provided location information, where PANI is needed= in ACK.

 

Now, this should have been intr= oduced in RFC7315 (which wasn’t published until 2014), but unfortunat= ely the authors (myself included) missed that part.

 

I assume this cannot be fixed w= ith an errata – it would require an update to RFC7315 (probably not a= bis, but a draft that updates the affected part(s) of RFC7315).=

 

 

 

Issue 2)   &n= bsp;         RFC 7315 is inconsiste= nt on whether PANI is allowed  in SIP responses<= /p>

 

RFC 3455, and 3GPP TS 24.229, a= llow usage of the PANI header field in SIP responses. However, RFC 7315 is = inconsistent.

Chapter 4.4 says:=

 

     &= nbsp;          “When a U= A generates a SIP request or response that it knows is going

     &= nbsp;         to be securely sent t= o its SIP proxy that is providing services, the

     &= nbsp;         UA inserts a P-Access= -Network-Info header field into field the SIP

     &= nbsp;         message.”<= /o:p>

 

… which DOES imply that P= ANI is allowed in SIP responses.

 

Chapter 4.4.2.1 implies the same thing:

 

     &= nbsp;          “A UA tha= t supports this extension and is willing to disclose the<= /p>

     &= nbsp;         related parameters MA= Y insert the P-Access-Network-Info header field

     &= nbsp;         in any SIP request or= response.”

 

 

However, chapter 5.7. sa= ys:

 

5.7.  New Headers

 

     &= nbsp;         “The P-Associat= ed-URI header field can appear in SIP REGISTER method

     &= nbsp;         and 2xx resonses.&nbs= p; The P-Called-Party-ID header field can appear in

     &= nbsp;         SIP INVITE, OPTIONS, = PUBLISH, SUBSCRIBE, and MESSAGE methods and all

     &= nbsp;         responses.  The = P-Visited-Network-ID header field can appear in all

     &= nbsp;         SIP methods except AC= K, BYE, and CANCEL and all responses.  The

     &= nbsp;         P-Access-Network-Info= header field can appear in all SIP methods

     &= nbsp;         except ACK and CANCEL= .  The P-Charging-Vector header field can appear

     &= nbsp;         in all SIP methods ex= cept CANCEL.  The P-Charging-Function-Addresses

     &= nbsp;         header field can appe= ar in all SIP methods except ACK and CANCEL.”

 

…where responses, unlike = in the case of other header fields, are not explicitly mentioned for PANI.

 

I assume this is just a bug in = section 5.7, which could be fixed with an errata:

 

OLD TEXT:

 

     &= nbsp;          “The P-Ac= cess-Network-Info header field can appear in all SIP methods

      =          except ACK and CANCEL= .”

 

 

NEW TEXT:

 

     &= nbsp;          “The P-Ac= cess-Network-Info header field can appear in all SIP methods

     &= nbsp;         except ACK and CANCEL= <new>and all responses</new>.”

 

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37C7C70DESESSMB209erics_-- From nobody Thu Dec 3 03:39: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 86CE11B33DA for ; Thu, 3 Dec 2015 03:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 1xid6FXVrz3R for ; Thu, 3 Dec 2015 03:39:48 -0800 (PST) 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 3AF6B1B33C5 for ; Thu, 3 Dec 2015 03:39:48 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-e5-56602a016b57 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 41.BA.05041.10A20665; Thu, 3 Dec 2015 12:39:45 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Thu, 3 Dec 2015 12:39:45 +0100 From: Christer Holmberg To: SIPCORE Thread-Topic: Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Associated-URI Thread-Index: AdEttRZkqbUVjLDNSUCsMAMe9rbSFgACf98w Date: Thu, 3 Dec 2015 11:39:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C7CCCB@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37C7CCCBESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2K7jS6jVkKYwdZdlhZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsqFegWTLCsOnLrJ3sC41KiLkZNDQsBE4s2vh2wQtpjEhXvr gWwuDiGBw4wSV67vZoVwFjNKPPsynaWLkYODTcBCovufNogpIiAnMftGDEivsECpROOf5+wg tohAlcTio9tYIGwjie6jS5hAylkEVCR2vgkGCfMK+EpcXvKbFcRmBFr7/dQaJhCbWUBc4taT +UwQ5whILNlznhnCFpV4+fgfK8gYCQFFieX9chDl+RKPT81gghgpKHFy5hOWCYxCs5BMmoWk bBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUbQ4tbg4N93ISC+1KDO5uDg/Ty8v tWQTIzAWDm75bbWD8eBzx0OMAhyMSjy8H8rjw4RYE8uKK3MPMUpwMCuJ8H5bCxTiTUmsrEot yo8vKs1JLT7EKM3BoiTO28z0IFRIID2xJDU7NbUgtQgmy8TBKdXAyMQjrdxk6Jhg8qLk74Hb 3SuMxR7fcTc5PNtv+eZ3F73/zTict2TmX+b6Ty7x/JpfbisYPWz2Pfi6nSFMaZNL6VLZG4Uu vB9qV3saaV8M/89Z6qHdWPO46Kl6w5Rub2ZvDftWGe/T1somvk+znwR+VHrRu97w6M8N8+bL HP6y7WAfY8juzSJySizFGYmGWsxFxYkASI5Fz4ECAAA= Archived-At: Subject: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Associated-URI 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, 03 Dec 2015 11:39:50 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37C7CCCBESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, 3GPP has been studying possible misalignments between the P- header definit= ions in RFC 3455, RFC 7315 and 3GPP TS 24.229. Rather than posting all the issues in a single e-mail, I will send e-mails = per header field. This e-mail is about P-Associated-URI, where one issue wa= s identified. Issue 1) RFC 7315 allows PUI in requests and responses. RFC 3455 and 3GPP TS 24.229 only allows PUI in responses. However, RFC 7315= seems to allow PUI also in requests. Chapters 4.1, 4.1.2 , 4.1.2.1 and 4.1.2.2 of RFC 7315 imply that PUI is onl= y allowed in responses: However, chapter 5.7 says: "The P-Associated-URI header field can appear in SIP REGISTE= R method and 2xx responses." I assume this is just a bug in section 5.7, which could be fixed with an er= rata: OLD TEXT: "The P-Associated-URI header field can appear in SIP REGISTE= R method and 2xx responses." NEW TEXT: "The P-Associated-URI header field can appear in SIP REGISTE= R 2xx responses." Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37C7CCCBESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

3GPP has been studying possible= misalignments between the P- header definitions in RFC 3455, RFC 7315 and = 3GPP TS 24.229.

 

Rather than posting all the iss= ues in a single e-mail, I will send e-mails per header field. This e-mail i= s about P-Associated-URI, where one issue was identified.=

 

Issue 1)   &n= bsp;         RFC 7315 allows PUI in= requests and responses.

 

RFC 3455 and 3GPP TS 24.229 onl= y allows PUI in responses. However, RFC 7315 seems to allow PUI also in req= uests.

 

Chapters 4.1, 4.1.2 , 4.1.2.1 and 4.1.2.2 of RFC 7= 315 imply that PUI is only allowed in = responses:

 

However, chapter 5.7 say= s:

 

     &= nbsp;         “The P-Ass= ociated-URI header field can appear in SIP REGISTER method

     &= nbsp;         and 2xx response= s.”

 

 

I assume this is just a bug in = section 5.7, which could be fixed with an errata:

 

OLD TEXT:

 

     &= nbsp;         “The P-Ass= ociated-URI header field can appear in SIP REGISTER method

     &= nbsp;         and 2xx response= s.”

 

 

NEW TEXT:

 

     &= nbsp;         “The P-Ass= ociated-URI header field can appear in SIP REGISTER 2xx responses.”

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37C7CCCBESESSMB209erics_-- From nobody Thu Dec 3 03:40: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 DE4391B33E7 for ; Thu, 3 Dec 2015 03:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Kr5-h-1yJGPL for ; Thu, 3 Dec 2015 03:40:39 -0800 (PST) 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 99D3B1B33DA for ; Thu, 3 Dec 2015 03:40:38 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-7b-56602a341d69 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 17.5D.05149.43A20665; Thu, 3 Dec 2015 12:40:36 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Thu, 3 Dec 2015 12:40:36 +0100 From: Christer Holmberg To: SIPCORE Thread-Topic: Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Called-Party-ID Thread-Index: AdEtuB4NYIfmeijGSxiGtk6VESTmVAABzZBA Date: Thu, 3 Dec 2015 11:40:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C7CD0F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37C7CD0FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2K7sa6JVkKYwdWr4hZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxs7tGxgLOuwq5t1oYG5gPGLWxcjBISFgIvH2hF0XIyeQKSZx 4d56ti5GLg4hgcOMEr9nTWGCcBYzSpydN5MJpIFNwEKi+582iCkiICcx+0YMSK+wQJnEx11d zCC2iEC1xPzds9kgbCOJzsfbmEHKWQRUJHqvyIKEeQV8Jc4tu84EYjMCrf1+ag2YzSwgLnHr yXwmiHMEJJbsOc8MYYtKvHz8jxXiYkWJ5f1yEOX5EldPLWGCGCkocXLmE5YJjEKzkEyahaRs FpIyiLiOxILdn9ggbG2JZQtfM8PYZw48ZkIWX8DIvopRtDi1OCk33chIL7UoM7m4OD9PLy+1 ZBMjMBYObvltsIPx5XPHQ4wCHIxKPLwfyuPDhFgTy4orcw8xSnAwK4nwflsLFOJNSaysSi3K jy8qzUktPsQozcGiJM7bzPQgVEggPbEkNTs1tSC1CCbLxMEp1cDYMXGN3COLbKUX6dL6j9l0 AsQ9Q1aULZy2feLptl1tPB7JO5wl5141PnNSf+dbdf58nRVFPbzOCS9Olv1ozNpWGvhLZXq3 dZrhHFX16HcfDh6a/Ci0uTmwZvKuHcbRHvM8v399pGZ8lV/u7qbn/+cv+KOykD11wj6+d5sc jDRiNtTcNta0PDVRiaU4I9FQi7moOBEAFI9wGYECAAA= Archived-At: Subject: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Called-Party-ID 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, 03 Dec 2015 11:40:45 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37C7CD0FESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, 3GPP has been studying possible misalignments between the P- header definit= ions in RFC 3455, RFC 7315 and 3GPP TS 24.229. Rather than posting all the issues in a single e-mail, I will send e-mails = per header field. This e-mail is about P-Called-Party-ID (PCPI), where one = issue was identified. Issue 1) RFC 7315 allows PCPI in requests and responses. RFC 3455 and 3GPP TS 24.229 only allows PCPI in requests. However, RFC 7315= seems to allow PCPI also in responses. Chapters 4.2.1, 4.2.2 and 4.2.2.2 imply that the PCIP is only used in reque= sts. However, chapter 5.7 says: "The P-Called-Party-ID header field can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods= and all responses." I assume this is just a bug in section 5.7, which could be fixed with an er= rata: OLD TEXT: "The P-Called-Party-ID header field can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods= and all responses." NEW TEXT: "The P-Called-Party-ID header field can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods= ." Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37C7CD0FESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

3GPP has been studying possible= misalignments between the P- header definitions in RFC 3455, RFC 7315 and = 3GPP TS 24.229.

 

Rather than posting all the iss= ues in a single e-mail, I will send e-mails per header field. This e-mail i= s about P-Called-Party-ID (PCPI), where one issue was identified.

 

Issue 1)   &n= bsp;         RFC 7315 allows PCPI i= n requests and responses.

 

RFC 3455 and 3GPP TS 24.229 onl= y allows PCPI in requests. However, RFC 7315 seems to allow PCPI also in re= sponses.

 

Chapters 4.2.1, 4.2.2 and 4.2.2= .2 imply that the PCIP is only used in requests.

 

However, chapter 5.7 say= s:

 

     &= nbsp;          “The P-Ca= lled-Party-ID header field can appear in

     &= nbsp;         SIP INVITE, OPTI= ONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and all

     &= nbsp;         responses.”= ;

 

I assume this is just a bug in = section 5.7, which could be fixed with an errata:

 

OLD TEXT:

 

     &= nbsp;          “The P-Ca= lled-Party-ID header field can appear in

     &= nbsp;         SIP INVITE, OPTI= ONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and all

     &= nbsp;         responses.”= ;

 

 

NEW TEXT:

 

     &= nbsp;          “The P-Ca= lled-Party-ID header field can appear in

     &= nbsp;         SIP INVITE, OPTI= ONS, PUBLISH, SUBSCRIBE, and MESSAGE methods.”

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37C7CD0FESESSMB209erics_-- From nobody Thu Dec 3 03:41:27 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 601BC1B33EB for ; Thu, 3 Dec 2015 03:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBWBXcwzDOk1 for ; Thu, 3 Dec 2015 03:41:24 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71B01B33F2 for ; Thu, 3 Dec 2015 03:41:22 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-04-56602a60cd0d Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D5.37.04914.06A20665; Thu, 3 Dec 2015 12:41:21 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Thu, 3 Dec 2015 12:41:20 +0100 From: Christer Holmberg To: SIPCORE Thread-Topic: Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Charging-Function-Addresses Thread-Index: AdEtuISRX7QR5a0OQFiQiqH3GudpjQABuqtQ Date: Thu, 3 Dec 2015 11:41:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C7CD71@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37C7CD71ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2K7mW6iVkKYwfLlTBZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxv5V21kLfthUHH94n72B8bhpFyMnh4SAicSdP2+YIGwxiQv3 1rN1MXJxCAkcZpR4vXsFI4SzmFHi1vHrrF2MHBxsAhYS3f+0QUwRATmJ2TdiQEqEBZoYJdqu z2MBcUQE2hklri7qB5sqImAk8e76OzYQm0VARWLPzJuMIDavgK/E8SsfwOKMQJu/n1oDVs8s IC5x68l8qIsEJJbsOc8MYYtKvHz8D+wGCQFFieX9chDl+RLvvjSwQYwUlDg58wnLBEahWUgm zUJSNgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FKFqcWlycm25krJdalJlcXJyf p5eXWrKJERgTB7f81t3BuPq14yFGAQ5GJR7eD+XxYUKsiWXFlbmHGCU4mJVEeL+tBQrxpiRW VqUW5ccXleakFh9ilOZgURLnbWF6ECokkJ5YkpqdmlqQWgSTZeLglGpglH8csk2Jd5d6Xv9p dqt3Fds/KVj8ufvj2Ewh/iPXC7IuPGn4d4e/48WWY7mON871H2DoqSiMfbpVbkNiMsM0E7XS PdIv9DLmHGVovGlpWHUnKdcxL5tn0Wrm789rPwie8hRJ2Xzy0PYsAUG+aUtP+j373vWsM6OM c4KdwJXwonVeds6B0xsllFiKMxINtZiLihMBXFeIB4UCAAA= Archived-At: Subject: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Charging-Function-Addresses 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, 03 Dec 2015 11:41:26 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37C7CD71ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, 3GPP has been studying possible misalignments between the P- header definit= ions in RFC 3455, RFC 7315 and 3GPP TS 24.229. Rather than posting all the issues in a single e-mail, I will send e-mails = per header field. This e-mail is about P-Charging-Function-Addresses (PCFA= ), where one issue was identified. Issue 1) RFC 7315 allows PCFA in responses. RFC 3455 and 3GPP TS 24.229 allow PCFA in both requests and responses. Howe= ver, RFC 7315 is incositent. Chapters 4.5, 4.5.2.1 and 4.5.2.2 imply that the PCFA can be used in both r= equests and responses. However, chapter 5.7 says: "The P-Charging-Function-Addresses header field can appear in all SIP methods except ACK and CA= NCEL." I assume this is just a bug in section 5.7, which could be fixed with an er= rata: OLD TEXT: "The P-Charging-Function-Addresses header field can appear in all SIP methods except ACK and CA= NCEL." NEW TEXT: "The P-Charging-Function-Addresses header field can appear in all SIP methods except ACK and CA= NCEL and in all responses." Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37C7CD71ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

3GPP has been studying possible= misalignments between the P- header definitions in RFC 3455, RFC 7315 and = 3GPP TS 24.229.

 

Rather than posting all the iss= ues in a single e-mail, I will send e-mails per header field. This e-mail i= s about P-Charging-Function-Addresses  (PCFA), where one issue was ide= ntified.

 

Issue 1)   &n= bsp;         RFC 7315 allows PCFA i= n responses.

 

RFC 3455 and 3GPP TS 24.229 all= ow PCFA in both requests and responses. However, RFC 7315 is incositent.

 

Chapters 4.5, 4.5.2.1 and 4.5.2= .2 imply that the PCFA can be used in both requests and responses.

 

However, chapter 5.7 say= s:

 

     &= nbsp;          “The P-Ch= arging-Function-Addresses

     &= nbsp;         header field can= appear in all SIP methods except ACK and CANCEL.”<= /p>

 

I assume this is just a bug in = section 5.7, which could be fixed with an errata:

 

OLD TEXT:

 

     &= nbsp;          “The P-Ch= arging-Function-Addresses

     &= nbsp;         header field can= appear in all SIP methods except ACK and CANCEL.”<= /p>

 

 

NEW TEXT:

 

     &= nbsp;          “The P-Ch= arging-Function-Addresses

     &= nbsp;         header field can= appear in all SIP methods except ACK and CANCEL

     &= nbsp;         and in all respo= nses.”

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37C7CD71ESESSMB209erics_-- From nobody Thu Dec 3 03:42:15 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 84A261B33F5 for ; Thu, 3 Dec 2015 03:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4glKSSNLzG5F for ; Thu, 3 Dec 2015 03:42:11 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928F31B33EB for ; Thu, 3 Dec 2015 03:42:10 -0800 (PST) X-AuditID: c1b4fb25-f79876d0000011ee-a4-56602a90ad64 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 55.68.04590.09A20665; Thu, 3 Dec 2015 12:42:08 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0248.002; Thu, 3 Dec 2015 12:42:08 +0100 From: Christer Holmberg To: SIPCORE Thread-Topic: Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Charging-Vector Thread-Index: AdEtuUHpNv/3/S7eQeGtqkjJ8mhf8AABkjZg Date: Thu, 3 Dec 2015 11:42:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C7CD9F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37C7CD9FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2K7je4ErYQwg8df1S2+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujNX7GxgLflhXTDkyk62B8Z5JFyMnh4SAicS/Y5PYIGwxiQv3 1gPZXBxCAocZJdbN38IIkhASWMwo8bDVrIuRg4NNwEKi+582iCkiICcx+0YMiCksUCax8kYU SLGIQLXEn68zmSFsI4mN3fPYQWwWARWJzXs7wOK8Ar4SK79cAYszAm39fmoNE4jNLCAucevJ fCaIawQkluw5zwxhi0q8fPyPFWSVhICixPJ+OYjyfIl9U+ZDjRSUODnzCcsERqFZSCbNQlI2 C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8UoWpxanJSbbmSsl1qUmVxcnJ+nl5da sokRGAsHt/xW3cF4+Y3jIUYBDkYlHt4P5fFhQqyJZcWVuYcYJTiYlUR4v60FCvGmJFZWpRbl xxeV5qQWH2KU5mBREudtZnoQKiSQnliSmp2aWpBaBJNl4uCUamBMF1BdvfzspYwZEe8D377y upt/PeBx0t4r99fvP/622Hq/8tFPwU95l7zTTJoXwshUVax0Y87quEolma+lAVp/j4q3vFf5 FfTNRtbajul0htz5Xy9++mp1OTlIznAPvLZvU+cOrxl8pWZ2N7wLHqzg3s2xs1nESjMjePqT q0WfbwdfOeu97NlrJZbijERDLeai4kQA1ZyFgIECAAA= Archived-At: Subject: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Charging-Vector 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, 03 Dec 2015 11:42:13 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37C7CD9FESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, 3GPP has been studying possible misalignments between the P- header definit= ions in RFC 3455, RFC 7315 and 3GPP TS 24.229. Rather than posting all the issues in a single e-mail, I will send e-mails = per header field. This e-mail is about P-Charging-Vector (PCV), where one= issue was identified. Issue 1) RFC 7315 allows PCV in responses. RFC 3455 and 3GPP TS 24.229 allow PCV in both requests and responses. Howev= er, RFC 7315 is incositent. Chapters 4.6, 4.6.2.1, 4.6.2.2, 4.6.3 and 4.6.4.1 imply that the PCV can be= used in both requests and responses. However, chapter 5.7 says: "The P-Charging-Vector header field can appear in all SIP methods except CANCEL." I assume this is just a bug in section 5.7, which could be fixed with an er= rata: OLD TEXT: "The P-Charging-Vector header field can appear in all SIP methods except CANCEL." NEW TEXT: "The P-Charging-Vector header field can appear in all SIP methods except CANCEL and in all responses." Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37C7CD9FESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi,

 

3GPP has been studying possible= misalignments between the P- header definitions in RFC 3455, RFC 7315 and = 3GPP TS 24.229.

 

Rather than posting all the iss= ues in a single e-mail, I will send e-mails per header field. This e-mail i= s about P-Charging-Vector   (PCV), where one issue was identified= .

 

Issue 1)   &n= bsp;         RFC 7315 allows PCV in= responses.

 

RFC 3455 and 3GPP TS 24.229 all= ow PCV in both requests and responses. However, RFC 7315 is incositent.

 

Chapters 4.6, 4.6.2.1, 4.6.2.2,= 4.6.3 and 4.6.4.1 imply that the PCV can be used in both requests and resp= onses.

 

However, chapter 5.7 say= s:

 

     &= nbsp;          “The P-Ch= arging-Vector header field can appear

     &= nbsp;         in all SIP metho= ds except CANCEL.”

 

I assume this is just a bug in = section 5.7, which could be fixed with an errata:

 

OLD TEXT:

 

     &= nbsp;          “The P-Ch= arging-Vector header field can appear

     &= nbsp;         in all SIP metho= ds except CANCEL.”

 

 

NEW TEXT:

 

     &= nbsp;          “The P-Ch= arging-Vector header field can appear

     &= nbsp;         in all SIP metho= ds except CANCEL and in all responses.”

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37C7CD9FESESSMB209erics_-- From nobody Thu Dec 3 03:43:26 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCA51B33F6 for ; Thu, 3 Dec 2015 03:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 3ewTLxug5swC for ; Thu, 3 Dec 2015 03:43:23 -0800 (PST) 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 99BD71B33F4 for ; Thu, 3 Dec 2015 03:43:22 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-a8-56602ad8a188 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E7.6B.05041.8DA20665; Thu, 3 Dec 2015 12:43:20 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Thu, 3 Dec 2015 12:43:19 +0100 From: Christer Holmberg To: SIPCORE Thread-Topic: Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Visited-Network-ID Thread-Index: AdEtvjAFN3DP+SmxT12yXvf2PtW+sAAAXi7A Date: Thu, 3 Dec 2015 11:43:19 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C7CDC8@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37C7CDC8ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2J7lO4NrYQwg869ZhZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRuvujawFm2wrLh/ay9rA2GjWxcjJISFgInFu3m5GCFtM4sK9 9WxdjFwcQgKHGSUmH37DBOEsZpRYsfMScxcjBwebgIVE9z9tEFNEQE5i9o0YkF5hgUqJPXM/ soHYIgJ1Eq/W7WSHsI0k9r/7ChZnEVCR2NZ3E8zmFfCVmDD5PwuIzQi09/upNUwgNrOAuMSt J/OZIO4RkFiy5zwzhC0q8fLxP1aQtRICihLL++VATGaBfInGgwIQEwUlTs58wjKBUWgWkkGz EKpmIamCKNGRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzGKFqcWF+emGxnppRZlJhcX5+fp 5aWWbGIExsLBLb+tdjAefO54iFGAg1GJh/dDeXyYEGtiWXFl7iFGCQ5mJRHeb2uBQrwpiZVV qUX58UWlOanFhxilOViUxHmbmR6ECgmkJ5akZqemFqQWwWSZODilGhgzDyVUPZvN6Ln2SJTf kne9PKndH+e3/TidOem1kM75FJW9eq/7p02se8yr9YD592H+b55mxl19B034Mxf6efG4n19g Upy5rf3KxB27PX/JH1v1/JyTkP29i90eLG3lGZXrq2S5w9Yctu14Jt9RcFn1kFG+QT277bfd U/iOrVCxEzQ+vGeG3XQlluKMREMt5qLiRABRfL/WgQIAAA== Archived-At: Subject: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Visited-Network-ID 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, 03 Dec 2015 11:43:25 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37C7CDC8ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, 3GPP has been studying possible misalignments between the P- header definit= ions in RFC 3455, RFC 7315 and 3GPP TS 24.229. Rather than posting all the issues in a single e-mail, I will send e-mails = per header field. This e-mail is about P-Visited-Network-ID (PCNI), wher= e one issue was identified. Issue 1) RFC 7315 allows PCNI in requests and responses. RFC 3455 and 3GPP TS 24.229 allow PCNI in requests only. However, RFC 7315 = allows PCNI in both requests and responses.. Chapters 4.3.2, 4.3.2.1 and 4.3.2.2 only talks about PCNI in requests. However, chapter 5.7 says: "The P-Visited-Network-ID header field can appear in all SIP methods except ACK, BYE, and CANCEL and all responses." I assume this is just a bug in section 5.7, which could be fixed with an er= rata: OLD TEXT: "The P-Visited-Network-ID header field can appear in all SIP methods except ACK, BYE, and CANCEL and all responses." NEW TEXT: "The P-Visited-Network-ID header field can appear in all SIP methods except ACK, BYE, and CANCEL." Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B37C7CDC8ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

3GPP has been studying possible= misalignments between the P- header definitions in RFC 3455, RFC 7315 and = 3GPP TS 24.229.

 

Rather than posting all the iss= ues in a single e-mail, I will send e-mails per header field. This e-mail i= s about P-Visited-Network-ID    (PCNI), where one issue was = identified.

 

Issue 1)   &n= bsp;         RFC 7315 allows PCNI in requests and responses.<= /span>

 

RFC 3455 and 3GPP TS 24.229 all= ow PCNI in requests only. However, RFC 7315 allows PCNI in both requests an= d responses..

 

Chapters 4.3.2, 4.3.2.1 and 4.3= .2.2 only talks about PCNI in requests.

 

However, chapter 5.7 say= s:

 

     &= nbsp;          “The P-Vi= sited-Network-ID header field can appear in all

     &= nbsp;         SIP methods exce= pt ACK, BYE, and CANCEL and all responses.”

 

I assume this is just a bug in = section 5.7, which could be fixed with an errata:

 

OLD TEXT:

 

     &= nbsp;          “The P-Vi= sited-Network-ID header field can appear in all

     &= nbsp;         SIP methods exce= pt ACK, BYE, and CANCEL and all responses.”

 

 

NEW TEXT:

 

     &= nbsp;          “The P-Vi= sited-Network-ID header field can appear in all

     &= nbsp;         SIP methods exce= pt ACK, BYE, and CANCEL.”

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B37C7CDC8ESESSMB209erics_-- From nobody Thu Dec 3 04:22:10 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 F10121B347B for ; Thu, 3 Dec 2015 04:22:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DbVXz-2f3LZ for ; Thu, 3 Dec 2015 04:22:08 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95BE71B347A for ; Thu, 3 Dec 2015 04:22:07 -0800 (PST) X-AuditID: c1b4fb25-f79876d0000011ee-70-566033edab50 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CC.A0.04590.DE330665; Thu, 3 Dec 2015 13:22:05 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Thu, 3 Dec 2015 13:22:05 +0100 From: Christer Holmberg To: "sipcore@ietf.org" , "pkyzivat@alum.mit.edu" Thread-Topic: [sipcore] Content-Disposition questions - errata suggestion Thread-Index: AdEtxSaDXqEaqwAtQvODlzCb6Ml4TA== Date: Thu, 3 Dec 2015 12:22:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C7D140@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM2K7ge5b44Qwg68vjCxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj25aYgif6FbdfbWJvYFyj2sXIySEhYCLx se89G4QtJnHh3nogm4tDSOAwo8Ti5X+YIZzFjBIHP69i7GLk4GATsJDo/qcN0iAiECNx+9MX FhBbWMBDYsm2VhaIuKfE0ePbmCFsPYnbrw+zgtgsAioSjStvMYHYvAK+Es9vnQSrZwRa/P3U GrA4s4C4xK0n85kgDhKQWLLnPDOELSrx8vE/VpATJAQUJZb3y0GUG0ic276RHcLWlli28DUz xHhBiZMzn7BMYBSehWTqLCQts5C0zELSsoCRZRWjaHFqcVJuupGxXmpRZnJxcX6eXl5qySZG YMgf3PJbdQfj5TeOhxgFOBiVeHg/lMeHCbEmlhVX5h5ilOBgVhLh/bYWKMSbklhZlVqUH19U mpNafIhRmoNFSZy3melBqJBAemJJanZqakFqEUyWiYNTqoGx6+SGmnOLoh9d3pOuudbrg1vz dpvDwpd2SG1Sn+Rb3udt4hXBIno+aaPcox/CR2wvJVxwDWQr13duOFjBfS7kqPn0Lq/Ov+qB G7a8T5OuXtppyJyuWfbj4aYCgT9rPyrw3vx65B1DXL4rK1fHhvRPuqdyb7G03HzLfvbe2eyz r/Zf23GUNV1UiaU4I9FQi7moOBEAnCMGV3UCAAA= Archived-At: Subject: Re: [sipcore] Content-Disposition questions - errata suggestion 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, 03 Dec 2015 12:22:10 -0000 Hi, Coming back to this, because it is causing issues in deployments. There were two issues: Issue 1) Is the default handling value "required" also if the C-D header fi= eld is not present? Issue 2) Different MIME types seem to assume different default disposition = types values. In this e-mail I focus on issue 1). My suggestion is to create an errata, which explicitly says that, in case t= he C-D header field is not present, the default handling value of "required= " must be assumed.. OLD TEXT: "The handling parameter, handling-param, describes how the UA= S should react if it receives a message body whose content type or dis= position type it does not understand. The parameter has defined value= s of "optional" and "required". If the handling parameter is miss= ing, the value "required" SHOULD be assumed. The handling parameter i= s described in RFC 3204 [19]." NEW TEXT: "The handling parameter, handling-param, describes how the UA= S should react if it receives a message body whose content type or dis= position type it does not understand. The parameter has defined value= s of "optional" and "required". If the handling parameter is miss= ing, or if the Content-Disposition header field is missing, the value "= required"=20 MUST be assumed. The handling parameter is described in RFC= 3204 [19]." Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 13. maaliskuuta 2015 13:18 To: Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] Content-Disposition questions Hi, Related to this, I see that Content-Disposition is not mentioned in RFC 644= 2 (Location Conveyance for the Session Initiation Protocol).=20 (This was also mentioned in ECRIT at one point: http://www.ietf.org/mail-ar= chive/web/ecrit/current/msg08517.html). So, that basically means that the default disposition type for the XML body= is "render", which I don't think fits very well. In addition, assuming the default handling value is "required", it also mea= ns that endpoints must support the XML body. But, perhaps that's ok. Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: 10. maaliskuuta 2015 18:04 To: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] Content-Disposition questions On 3/10/15 11:27 AM, Christer Holmberg wrote: > Hi Paul, > > It is not the default handling value that is different for the=20 > qsig/isup bodies - it is the default type value ("signal", rather than "r= ender"). I know they define the default disposition type for those mime types. But I thought Thomas was also saying that they change the default handling = to "optional", and I was commenting on the relevance of that part. If you i= nclude a qsig mime body, and don't include a C-D with handling=3D"optional"= then a recipient that doesn't know the mime type should treat it as "requi= red" and reject the request, regardless of what defaults are defined for th= at mime type. > I am not sure I agree with Thomas that a SIP client must support the=20 > qsig/isup bodies. Yes, 3261 does reference the CR, but mostly for=20 > information regarding the C-D header field itself. I agree with you. Classifying a reference as normative doesn't mean that ev= ery aspect of that draft is required. And the only body reference in 3261 is wrt the definition of the handling parameter. And 3204 goes out of = its way to say: The Content-Disposition header [5] may be included to describe how the encapsulated ISUP is to be processed, and in particular what the handling should be if the received Content-Type is not recognized. That would make no sense if all SIP UA were required to recognize ISUP. Thanks, Paul > Regards, > > Christer > > Sent from my Windows Phone > ---------------------------------------------------------------------- > -- > From: Paul Kyzivat > Sent: =FD10/=FD03/=FD2015 16:58 > To: sipcore@ietf.org > Subject: Re: [sipcore] Content-Disposition questions > > On 3/10/15 5:45 AM, Stach, Thomas wrote: > >>> QUESTION_2: If, for a specific message body, the "render" default=20 >>> type can be overwritten, shouldn't that be mentioned in 3261? >> >> I think this is already written down. The last sentence in section 20.11= reads >> " If this header field is missing, the MIME type determines the defaul= t >> content disposition. If there is none, "render" is assumed." >> >> So, if the MIME type is understood, the default disposition from the=20 >> corresponding MIME definition applies. Of course, this default=20 >> disposition can be overwritten by sending a corresponding C-D header fie= ld, as e.g. ECMA-355 does for "qsig". >> "render" kicks in, only if the MIME type is not understood and if C-D is= omitted. >> Does this make sense? > > That has a problem. It makes no sense to define a default handling=20 > parameter value for a specific mime type that applies when the C-D=20 > isn't present. Suppose you define a mime type where the default=20 > handling is "optional". > > Then a receiver that does understand the mime type will treat the=20 > handling as optional, but that is irrelevant because this only applies=20 > if the mime type is not understood. > > A receiver that does not understand the mime type will use the global=20 > default handling value "required". > > Thanks, > Paul > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Dec 3 06: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 5D2991A88F5 for ; Thu, 3 Dec 2015 06:36:03 -0800 (PST) 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 f7V04laqzEDh for ; Thu, 3 Dec 2015 06:36:02 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35C181A88F3 for ; Thu, 3 Dec 2015 06:36:02 -0800 (PST) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-08v.sys.comcast.net with comcast id p2as1r0042N9P4d012c1QM; Thu, 03 Dec 2015 14:36:01 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-13v.sys.comcast.net with comcast id p2c01r00Q1nMCLR012c1K2; Thu, 03 Dec 2015 14:36:01 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id tB3Ea08T031372; Thu, 3 Dec 2015 09:36:00 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id tB3Ea0vJ031369; Thu, 3 Dec 2015 09:36:00 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C7D140@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 03 Dec 2015 09:36:00 -0500 Message-ID: <87wpsvwqen.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1449153361; bh=m9eNZ34AigR/KmKclwwfKgEpsHBkOxiFro2T4rFzLpc=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=UtLBJSEbzARF3fGwR74vrYrPQt46lXYr+nwl1QL9V3V+rnO7ErYTHrn715lzDwhMB t2OfXLABFIvVFA9KcTjmlRR/yHhmq959xe8uXbrfHN0raX3CghFMLxn6x7z2ixYknl NOTee5o6iqMQdk5kOm4f/8mykGZgZ1bhFsI4Q0zeTwaix7KtUrtGI9Yk7PygtJ8UT1 VysjiPwXFD41+KDkp5pD27lno+0sl73kcxVGsper9Btn8ong2ThiSghNo9BGPpWxZy d85JdCiJZ8CBHF4ZxNjAdommV+H+k8sSkc/ZrilnRPgXB0fcxFgdJW9GSntUj5GlRZ r3CocikR9AdHg== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Content-Disposition questions - errata suggestion 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, 03 Dec 2015 14:36:03 -0000 Christer Holmberg writes: > There were two issues: > > Issue 1) Is the default handling value "required" also if the C-D header field is not present? > Issue 2) Different MIME types seem to assume different default disposition types values. > > In this e-mail I focus on issue 1). > [...] > NEW TEXT: > "The handling parameter, handling-param, describes how the UAS should > react if it receives a message body whose content type or disposition > type it does not understand. The parameter has defined values of > "optional" and "required". If the handling parameter is missing, or if > the Content-Disposition header field is missing, the value "required" > MUST be assumed. The handling parameter is described in RFC 3204 [19]." That erratum makes sense to me. It seems to document what the original intention was. The biggest change is changing SHOULD to MUST, but I don't see a problem with that. In regard to issue 2, I don't see a problem. Either the UA "understands" the particular MIME type or not. If it does, the UA checks for Content-Disposition. If Content-Disposition is present, the disp-type determines the handling. If Content-Disposition is not present, UA uses the default handling for the MIME type. If it does not, the UA checks whether handling=optional is present. If it is present, the UA ignores the body part. If it is not present, the UA rejects the request. However, I am assuming that the "default content disposition" is purely a disp-type (i.e., render, session, etc.), and does not include a handling-param. Dale From nobody Thu Dec 3 06:54:54 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 3F02F1A8967 for ; Thu, 3 Dec 2015 06:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekxdaFBk1huX for ; Thu, 3 Dec 2015 06:54:51 -0800 (PST) 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 501F11A8956 for ; Thu, 3 Dec 2015 06:54:51 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-a2-566057b99e64 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B6.F3.05149.9B750665; Thu, 3 Dec 2015 15:54:49 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Thu, 3 Dec 2015 15:54:48 +0100 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [sipcore] Content-Disposition questions - errata suggestion Thread-Index: AQHRLdftXqEaqwAtQvODlzCb6Ml4TJ65WWy/ Date: Thu, 3 Dec 2015 14:54:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C7D8F0@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37C7D140@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com),<87wpsvwqen.fsf@hobgoblin.ariadne.com> In-Reply-To: <87wpsvwqen.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37C7D8F0ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7ou7O8IQwg8N90hYrNhxgtfj6YxOb xcsTZQ7MHn/ff2DymLz/K7PHkiU/mQKYo7hsUlJzMstSi/TtErgyJi17yFzw3rpi+o1tzA2M r4y6GDk5JARMJNZP+s8KYYtJXLi3ng3EFhI4zChxq826i5ELyF7MKPFv3lb2LkYODjYBC4nu f9ogpoiApkTHghyQcmaBGIljp6azgNjCAh4SS7a1gtkiAp4SR49vY4awjSSWHL8JNp5FQEVi xepZTCA2r4CvxPGzh9kgVk1nlHg0az7YPZwCxhLfzj8GsxmBbvt+ag0TxDJxiaYvK6FuFpBY suc8M4QtKvHy8T9WiJp8iY1LNzNCLBCUODnzCcsERpFZSNpnISmbhaQMIm4g8eX9bShbW2LZ wtfMELa+RPf700zI4gsY2VcxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBMbZwS2/DXYwvnzu eIhRgINRiYf3Q3l8mBBrYllxZe4hRgkOZiUR3ii3hDAh3pTEyqrUovz4otKc1OJDjNIcLEri vM1MD0KFBNITS1KzU1MLUotgskwcnFINjBNPT9O8KRUUIjXlf9i1OuNW2fNL11sKtH/fU9fl NmXOh6ggV8FpOw8f0X9/dkuSzY01ZmGt0ucbMg89vcSv9yI4Vs3l60+JPoE7Uo6/D8xy7d7P c+Aow/yGFsvVt58nqkqUJh7Rf1o+eUfSt/iCvXMmr/Nbt1H55eJdOedifnEKpWgaVx43jFFi Kc5INNRiLipOBACFt85irwIAAA== Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Content-Disposition questions - errata suggestion 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, 03 Dec 2015 14:54:53 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37C7D8F0ESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Dale, Regarding issue 2, the problem is that all MIME types do not define a defau= lt disposition type value. Regards, Christer Sent from my Windows Phone ________________________________ From: Dale R. Worley Sent: =FD03/=FD12/=FD2015 16:36 To: Christer Holmberg Cc: sipcore@ietf.org; pkyzivat@alum.mit.edu Subject: Re: [sipcore] Content-Disposition questions - errata suggestion Christer Holmberg writes: > There were two issues: > > Issue 1) Is the default handling value "required" also if the C-D he= ader field is not present? > Issue 2) Different MIME types seem to assume different default dispo= sition types values. > > In this e-mail I focus on issue 1). > [...] > NEW TEXT: > "The handling parameter, handling-param, describes how the = UAS should > react if it receives a message body whose content type or d= isposition > type it does not understand. The parameter has defined val= ues of > "optional" and "required". If the handling parameter is mi= ssing, or if > the Content-Disposition header field is missing, the value= "required" > MUST be assumed. The handling parameter is described in R= FC 3204 [19]." That erratum makes sense to me. It seems to document what the original intention was. The biggest change is changing SHOULD to MUST, but I don't see a problem with that. In regard to issue 2, I don't see a problem. Either the UA "understands" the particular MIME type or not. If it does, the UA checks for Content-Disposition. If Content-Disposition is present, the disp-type determines the handling. If Content-Disposition is not present, UA uses the default handling= for the MIME type. If it does not, the UA checks whether handling=3Doptional is present. If it is present, the UA ignores the body part. If it is not present, the UA rejects the request. However, I am assuming that the "default content disposition" is purely a disp-type (i.e., render, session, etc.), and does not include a handling-param. Dale --_000_7594FB04B1934943A5C02806D1A2204B37C7D8F0ESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Dale,

Regarding issue 2, the problem is that all MIME types do not define a defau= lt disposition type value.

Regards,

Christer

Sent from my Windows Phone
From: Dale R. Worley
Sent: =FD03= /=FD12/=FD2015 16:36
To: Christer Holmberg Cc: sipcore@ietf.org; pkyzivat@alum.mit.edu Subject: Re: [= sipcore] Content-Disposition questions - errata suggestion

Christer Holmberg <christer.holmberg@ericsson.c= om> writes:
> There were two issues:
>
> Issue 1)      Is the default handling value &= quot;required" also if the C-D header field is not present?
> Issue 2)      Different MIME types seem to as= sume different default disposition types values.
>
> In this e-mail I focus on issue 1).
> [...]
> NEW TEXT:
>            = ;   "The handling parameter, handling-param, describes how t= he UAS should
>            = ;   react if it receives a message body whose content type or dis= position
>            = ;   type it does not understand.  The parameter has defined = values of
>            = ;   "optional" and "required".  If the h= andling parameter is missing, or if
>            = ;    the Content-Disposition header field is missing, the va= lue "required"
>            = ;    MUST be assumed.  The handling parameter is descri= bed in RFC 3204 [19]."

That erratum makes sense to me.  It seems to document what the origina= l
intention was.  The biggest change is changing SHOULD to MUST, but I don't see a problem with that.

In regard to issue 2, I don't see a problem.

Either the UA "understands" the particular MIME type or not.
    If it does, the UA checks for Content-Disposition.
        If Content-Disposition is presen= t, the disp-type determines the
            handling= .
        If Content-Disposition is not pr= esent, UA uses the default handling for
            the MIME= type.
    If it does not, the UA checks whether handling=3Doptiona= l is present.
        If it is present, the UA ignores= the body part.
        If it is not present, the UA rej= ects the request.

However, I am assuming that the "default content disposition" is = purely
a disp-type (i.e., render, session, etc.), and does not include a
handling-param.

Dale
 --_000_7594FB04B1934943A5C02806D1A2204B37C7D8F0ESESSMB209erics_-- From nobody Thu Dec 3 07:34:23 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 172041A8AB5 for ; Thu, 3 Dec 2015 07:34:23 -0800 (PST) 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 pi0uS9iJKGSJ for ; Thu, 3 Dec 2015 07:34:21 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37251A8A96 for ; Thu, 3 Dec 2015 07:34:21 -0800 (PST) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-10v.sys.comcast.net with comcast id p3Yl1r0042N9P4d013aLjM; Thu, 03 Dec 2015 15:34:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-13v.sys.comcast.net with comcast id p3aK1r00c3KdFy1013aL8K; Thu, 03 Dec 2015 15:34:20 +0000 To: "Dale R. Worley" , Christer Holmberg References: <87wpsvwqen.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <566060FB.9080508@alum.mit.edu> Date: Thu, 3 Dec 2015 10:34:19 -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: <87wpsvwqen.fsf@hobgoblin.ariadne.com> 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=1449156860; bh=L/sxU8UCXjMLnHyQ+NcwM+M//+ktRjJbxG+CvKJYdSY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=mJia/H9ydlD9FI0lyDNuFPwSO8AUcudhcj+OlkeHRSPjQW60xmTb/I8gAtQxIGYj0 +qZygRMpctbULLPSyOM+hzRAL7/SXnAEH448zg6JG938sZKk6FaVT+eYY2iHkWPCSb LLzKCtyBuHMh3tKrTFlQAvCRSxN6S0i0g7auTFlffLTE/r6SG/p4dcJjGRgHozZjPK p3YSAfHNSSyUfSztxUedSOVPsXqXyEmGaCpI6qrDHbyWhXbOR9KUW5FJNa6+i4/3mP uAVTIrVbZ7rKIinYKAP427YrWvHjtIJBnwkid3ORZiRXq3R+P/qMziArxxC3ocbOuk vHtnCcoYmQivA== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Content-Disposition questions - errata suggestion 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, 03 Dec 2015 15:34:23 -0000 On 12/3/15 9:36 AM, Dale R. Worley wrote: > Christer Holmberg writes: >> There were two issues: >> >> Issue 1) Is the default handling value "required" also if the C-D header field is not present? >> Issue 2) Different MIME types seem to assume different default disposition types values. >> >> In this e-mail I focus on issue 1). >> [...] >> NEW TEXT: >> "The handling parameter, handling-param, describes how the UAS should >> react if it receives a message body whose content type or disposition >> type it does not understand. The parameter has defined values of >> "optional" and "required". If the handling parameter is missing, or if >> the Content-Disposition header field is missing, the value "required" >> MUST be assumed. The handling parameter is described in RFC 3204 [19]." > > That erratum makes sense to me. It seems to document what the original > intention was. Agree, except see below. > The biggest change is changing SHOULD to MUST, but I > don't see a problem with that. I'm undecided on that, and would like to discuss. Right now, if C-D is present, but 'handling' is missing then "required" *SHOULD* be assumed. That of course begs the question of when it would be appropriate to ignore the SHOULD. If there are any valid reasons, then ISTM that they would probably also apply when the C-D is missing. So the real question is what, if any, conditions justify violating the SHOULD? > In regard to issue 2, I don't see a problem. > > Either the UA "understands" the particular MIME type or not. > If it does, the UA checks for Content-Disposition. > If Content-Disposition is present, the disp-type determines the > handling. > If Content-Disposition is not present, UA uses the default handling for > the MIME type. > If it does not, the UA checks whether handling=optional is present. > If it is present, the UA ignores the body part. > If it is not present, the UA rejects the request. > > However, I am assuming that the "default content disposition" is purely > a disp-type (i.e., render, session, etc.), and does not include a > handling-param. I think I agree. The alternative would be that the default disposition for a mime type includes a default for the handling value. (That might be a reason for SHOULD rather than MUST above.) But that is nonsense. To know the default disposition for a mime type you must understand the mime type. And if you understand it, then the handling parameter is irrelevant to you. We may need to investigate the history of this parameter to understand the intent. I was thinking it went back to MIME. But after cursory searching, the earliest reference I have found is in RFC3204. That predates 3261. It doesn't say SHOULD. Rather, it says: If the handling parameter is missing, the value "required" is to be assumed. That isn't normative, but it sounds like MUST. Thanks, Paul From nobody Thu Dec 3 08:10:00 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 59CD81A8A68 for ; Thu, 3 Dec 2015 08:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 1g2HV6vMTyJ4 for ; Thu, 3 Dec 2015 08:09:54 -0800 (PST) Received: from ore.jhcloos.com (ore.jhcloos.com [198.147.22.87]) (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 B7D251A8F4F for ; Thu, 3 Dec 2015 08:09:47 -0800 (PST) Received: by ore.jhcloos.com (Postfix, from userid 10) id 359781ED87; Thu, 3 Dec 2015 16:09:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore14; t=1449158987; bh=LEwS/BEnwrosfT0EV3kKdgOgyXkwMf+xUy3MpmQqcLM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hMPIopOjfwb7iVq19ZvtxxvSJkj478EP8LTLnVbk8AONAFNz0rB9+OviFQXb5haIo NvNmBnj0IKYs4lVz/hrjbb9o6+YPqMjIjLdGXhUhE4G3sx/lfUJl9K7RKphNiUSnqp HUQVV2TvkwC3rf/x0pCWTJOw5c0wmuG1Xgfa8xmw= Received: by carbon.jhcloos.org (Postfix, from userid 500) id 6FD8E100CD541; Thu, 3 Dec 2015 16:07:56 +0000 (UTC) From: James Cloos To: Ivo Sedlacek In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112AEE460@ESESSMB301.ericsson.se> (Ivo Sedlacek's message of "Wed, 2 Dec 2015 08:36:36 +0000") References: <39B5E4D390E9BD4890E2B3107900610112AEC437@ESESSMB301.ericsson.se> <7699C626-BCC4-4B8F-AB14-0C81D7BE62D7@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112AEE460@ESESSMB301.ericsson.se> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC Copyright: Copyright 2015 James Cloos OpenPGP: 0x997A9F17ED7DAEA6; url=https://jhcloos.com/public_key/0x997A9F17ED7DAEA6.asc OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 Date: Thu, 03 Dec 2015 11:07:56 -0500 Message-ID: Lines: 13 MIME-Version: 1.0 Content-Type: text/plain X-Hashcash: 1:28:151203:ivo.sedlacek@ericsson.com::GI+ZUqSMeu96uPyg:00000000000000000000000000000000000CP8PT X-Hashcash: 1:28:151203:ben@nostrum.com::LqvahOFUA1T8Qpen:03OmEy X-Hashcash: 1:28:151203:"sipcore\@ietf.org"::n/dnKk2ePZyAW0yV:00000000000000000000000000000000000000000O5HV0 X-Hashcash: 1:28:151203:sipcore@ietf.org::9xyR3MyVRzc0rmD4:1ThR9 Archived-At: Cc: Ben Campbell , "sipcore@ietf.org" Subject: Re: [sipcore] A new SIP header fields with "P-" name 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, 03 Dec 2015 16:09:58 -0000 >>>>> "IS" == Ivo Sedlacek writes: IS> One proposed solution is to define and use P-Cellular-Network-Info IS> header field. The proper solution is to drop the 'P-' from the proposed header name; call it Cellular-Network-Info instead of P-Cellular-Network-Info. All 5727 says wrt P- is don't bother with a P- prefix on new headers. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From nobody Thu Dec 3 08:39:05 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378761A90A3 for ; Thu, 3 Dec 2015 08:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 mNzEr4cFHMIF for ; Thu, 3 Dec 2015 08:39:01 -0800 (PST) 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 AB54E1A9098 for ; Thu, 3 Dec 2015 08:39:00 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-c8-566070227cf5 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B4.55.05149.22070665; Thu, 3 Dec 2015 17:38:58 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0248.002; Thu, 3 Dec 2015 17:38:58 +0100 From: Christer Holmberg To: Paul Kyzivat , "Dale R. Worley" Thread-Topic: [sipcore] Content-Disposition questions - errata suggestion Thread-Index: AQHRLdftXqEaqwAtQvODlzCb6Ml4TJ65U7OAgAAi0ys= Date: Thu, 3 Dec 2015 16:38:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C7DAF7@ESESSMB209.ericsson.se> References: <87wpsvwqen.fsf@hobgoblin.ariadne.com>, <566060FB.9080508@alum.mit.edu> In-Reply-To: <566060FB.9080508@alum.mit.edu> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B37C7DAF7ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2K7tK5SQUKYwcoGC4sVGw6wWnz9sYnN 4uWJMgdmj7/vPzB5TN7/ldljyZKfTAHMUVw2Kak5mWWpRfp2CVwZv//fZSuYUFjRe/oGcwNj R14XIyeHhICJxOeNW5khbDGJC/fWs4HYQgKHGSVO/VTqYuQCshczSuy9v5Spi5GDg03AQqL7 nzZIjYhAoETXzmNMIDazgKbEo517wWxhAQ+JJdtaWSBqPCWOHt/GDNIqImAl8XVlGEiYRUBF 4k3TQrBVvAK+EjdffmOGWBskcfN5A5jNKaAj0fNmIlgNI9Bp30+tgVolLtH0ZSUrxMkCEkv2 nIc6X1Ti5eN/rBA1+RJdx5tYIeYLSpyc+YRlAqPILCTts5CUzUJSNgvoUpBv1u/ShyhRlJjS /ZAdwtaQaJ0zlx1ZfAEj+ypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwBg7uOW3wQ7Gl88d DzEKcDAq8fB+KI8PE2JNLCuuzD3EKMHBrCTCG+WWECbEm5JYWZValB9fVJqTWnyIUZqDRUmc t5npQaiQQHpiSWp2ampBahFMlomDU6qB0TjjecPx8p0sto/N2CMuHBc4+yjy7rGT/Q8e7Vg/ n4fxQMATK3+nVQXVq7oF03VPH37hJJblqF8ufHvvmvVJRwS6/7ALfZY7yMcc3FRY3rwxU+vW WpffH36Wu0z34HzBW6GdvDBI8MK3vWon1/h15bZ4TyuzifpZ8nT1/Rmbb1YnMx9+P3+RhBJL cUaioRZzUXEiALZQQ92tAgAA Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Content-Disposition questions - errata suggestion 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, 03 Dec 2015 16:39:03 -0000 --_000_7594FB04B1934943A5C02806D1A2204B37C7DAF7ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGF1bCwNCg0KTcO2dGUgdGhhdCBpc3N1ZSAyKSBpcyBub3QgYWJvdXQgdGhlIGhhbmRsaW5n IHBhcmFtZXRlciwgYnV0IHRoZSBjb250ZW50IGRpc3Bvc2l0aW9uIHR5cGUgKGUuZy4gc2Vzc2lv biwgcmVuZGVyIGV0YykuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNClNlbnQgZnJvbSBteSBX aW5kb3dzIFBob25lDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogUGF1 bCBLeXppdmF0PG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+DQpTZW50OiDigI4wMy/igI4x Mi/igI4yMDE1IDE3OjM0DQpUbzogRGFsZSBSLiBXb3JsZXk8bWFpbHRvOndvcmxleUBhcmlhZG5l LmNvbT47IENocmlzdGVyIEhvbG1iZXJnPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb20+DQpDYzogc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbc2lwY29yZV0gQ29udGVudC1EaXNwb3NpdGlvbiBxdWVzdGlvbnMgLSBlcnJh dGEgc3VnZ2VzdGlvbg0KDQpPbiAxMi8zLzE1IDk6MzYgQU0sIERhbGUgUi4gV29ybGV5IHdyb3Rl Og0KPiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiB3 cml0ZXM6DQo+PiBUaGVyZSB3ZXJlIHR3byBpc3N1ZXM6DQo+Pg0KPj4gSXNzdWUgMSkgICAgIElz IHRoZSBkZWZhdWx0IGhhbmRsaW5nIHZhbHVlICJyZXF1aXJlZCIgYWxzbyBpZiB0aGUgQy1EIGhl YWRlciBmaWVsZCBpcyBub3QgcHJlc2VudD8NCj4+IElzc3VlIDIpICAgICBEaWZmZXJlbnQgTUlN RSB0eXBlcyBzZWVtIHRvIGFzc3VtZSBkaWZmZXJlbnQgZGVmYXVsdCBkaXNwb3NpdGlvbiB0eXBl cyB2YWx1ZXMuDQo+Pg0KPj4gSW4gdGhpcyBlLW1haWwgSSBmb2N1cyBvbiBpc3N1ZSAxKS4NCj4+ IFsuLi5dDQo+PiBORVcgVEVYVDoNCj4+ICAgICAgICAgICAgICAgICJUaGUgaGFuZGxpbmcgcGFy YW1ldGVyLCBoYW5kbGluZy1wYXJhbSwgZGVzY3JpYmVzIGhvdyB0aGUgVUFTIHNob3VsZA0KPj4g ICAgICAgICAgICAgICAgcmVhY3QgaWYgaXQgcmVjZWl2ZXMgYSBtZXNzYWdlIGJvZHkgd2hvc2Ug Y29udGVudCB0eXBlIG9yIGRpc3Bvc2l0aW9uDQo+PiAgICAgICAgICAgICAgICB0eXBlIGl0IGRv ZXMgbm90IHVuZGVyc3RhbmQuICBUaGUgcGFyYW1ldGVyIGhhcyBkZWZpbmVkIHZhbHVlcyBvZg0K Pj4gICAgICAgICAgICAgICAgIm9wdGlvbmFsIiBhbmQgInJlcXVpcmVkIi4gIElmIHRoZSBoYW5k bGluZyBwYXJhbWV0ZXIgaXMgbWlzc2luZywgb3IgaWYNCj4+ICAgICAgICAgICAgICAgICB0aGUg Q29udGVudC1EaXNwb3NpdGlvbiBoZWFkZXIgZmllbGQgaXMgbWlzc2luZywgdGhlIHZhbHVlICJy ZXF1aXJlZCINCj4+ICAgICAgICAgICAgICAgICBNVVNUIGJlIGFzc3VtZWQuICBUaGUgaGFuZGxp bmcgcGFyYW1ldGVyIGlzIGRlc2NyaWJlZCBpbiBSRkMgMzIwNCBbMTldLiINCj4NCj4gVGhhdCBl cnJhdHVtIG1ha2VzIHNlbnNlIHRvIG1lLiAgSXQgc2VlbXMgdG8gZG9jdW1lbnQgd2hhdCB0aGUg b3JpZ2luYWwNCj4gaW50ZW50aW9uIHdhcy4NCg0KQWdyZWUsIGV4Y2VwdCBzZWUgYmVsb3cuDQoN Cj4gVGhlIGJpZ2dlc3QgY2hhbmdlIGlzIGNoYW5naW5nIFNIT1VMRCB0byBNVVNULCBidXQgSQ0K PiBkb24ndCBzZWUgYSBwcm9ibGVtIHdpdGggdGhhdC4NCg0KSSdtIHVuZGVjaWRlZCBvbiB0aGF0 LCBhbmQgd291bGQgbGlrZSB0byBkaXNjdXNzLg0KDQpSaWdodCBub3csIGlmIEMtRCBpcyBwcmVz ZW50LCBidXQgJ2hhbmRsaW5nJyBpcyBtaXNzaW5nIHRoZW4gInJlcXVpcmVkIg0KKlNIT1VMRCog YmUgYXNzdW1lZC4gVGhhdCBvZiBjb3Vyc2UgYmVncyB0aGUgcXVlc3Rpb24gb2Ygd2hlbiBpdCB3 b3VsZA0KYmUgYXBwcm9wcmlhdGUgdG8gaWdub3JlIHRoZSBTSE9VTEQuDQoNCklmIHRoZXJlIGFy ZSBhbnkgdmFsaWQgcmVhc29ucywgdGhlbiBJU1RNIHRoYXQgdGhleSB3b3VsZCBwcm9iYWJseSBh bHNvDQphcHBseSB3aGVuIHRoZSBDLUQgaXMgbWlzc2luZy4NCg0KU28gdGhlIHJlYWwgcXVlc3Rp b24gaXMgd2hhdCwgaWYgYW55LCBjb25kaXRpb25zIGp1c3RpZnkgdmlvbGF0aW5nIHRoZQ0KU0hP VUxEPw0KDQo+IEluIHJlZ2FyZCB0byBpc3N1ZSAyLCBJIGRvbid0IHNlZSBhIHByb2JsZW0uDQo+ DQo+IEVpdGhlciB0aGUgVUEgInVuZGVyc3RhbmRzIiB0aGUgcGFydGljdWxhciBNSU1FIHR5cGUg b3Igbm90Lg0KPiAgICAgIElmIGl0IGRvZXMsIHRoZSBVQSBjaGVja3MgZm9yIENvbnRlbnQtRGlz cG9zaXRpb24uDQo+ICAgICAgICAgIElmIENvbnRlbnQtRGlzcG9zaXRpb24gaXMgcHJlc2VudCwg dGhlIGRpc3AtdHlwZSBkZXRlcm1pbmVzIHRoZQ0KPiAgICAgICAgICAgICAgaGFuZGxpbmcuDQo+ ICAgICAgICAgIElmIENvbnRlbnQtRGlzcG9zaXRpb24gaXMgbm90IHByZXNlbnQsIFVBIHVzZXMg dGhlIGRlZmF1bHQgaGFuZGxpbmcgZm9yDQo+ICAgICAgICAgICAgICB0aGUgTUlNRSB0eXBlLg0K PiAgICAgIElmIGl0IGRvZXMgbm90LCB0aGUgVUEgY2hlY2tzIHdoZXRoZXIgaGFuZGxpbmc9b3B0 aW9uYWwgaXMgcHJlc2VudC4NCj4gICAgICAgICAgSWYgaXQgaXMgcHJlc2VudCwgdGhlIFVBIGln bm9yZXMgdGhlIGJvZHkgcGFydC4NCj4gICAgICAgICAgSWYgaXQgaXMgbm90IHByZXNlbnQsIHRo ZSBVQSByZWplY3RzIHRoZSByZXF1ZXN0Lg0KPg0KPiBIb3dldmVyLCBJIGFtIGFzc3VtaW5nIHRo YXQgdGhlICJkZWZhdWx0IGNvbnRlbnQgZGlzcG9zaXRpb24iIGlzIHB1cmVseQ0KPiBhIGRpc3At dHlwZSAoaS5lLiwgcmVuZGVyLCBzZXNzaW9uLCBldGMuKSwgYW5kIGRvZXMgbm90IGluY2x1ZGUg YQ0KPiBoYW5kbGluZy1wYXJhbS4NCg0KSSB0aGluayBJIGFncmVlLiBUaGUgYWx0ZXJuYXRpdmUg d291bGQgYmUgdGhhdCB0aGUgZGVmYXVsdCBkaXNwb3NpdGlvbg0KZm9yIGEgbWltZSB0eXBlIGlu Y2x1ZGVzIGEgZGVmYXVsdCBmb3IgdGhlIGhhbmRsaW5nIHZhbHVlLiAoVGhhdCBtaWdodA0KYmUg YSByZWFzb24gZm9yIFNIT1VMRCByYXRoZXIgdGhhbiBNVVNUIGFib3ZlLikNCg0KQnV0IHRoYXQg aXMgbm9uc2Vuc2UuIFRvIGtub3cgdGhlIGRlZmF1bHQgZGlzcG9zaXRpb24gZm9yIGEgbWltZSB0 eXBlDQp5b3UgbXVzdCB1bmRlcnN0YW5kIHRoZSBtaW1lIHR5cGUuIEFuZCBpZiB5b3UgdW5kZXJz dGFuZCBpdCwgdGhlbiB0aGUNCmhhbmRsaW5nIHBhcmFtZXRlciBpcyBpcnJlbGV2YW50IHRvIHlv dS4NCg0KV2UgbWF5IG5lZWQgdG8gaW52ZXN0aWdhdGUgdGhlIGhpc3Rvcnkgb2YgdGhpcyBwYXJh bWV0ZXIgdG8gdW5kZXJzdGFuZA0KdGhlIGludGVudC4gSSB3YXMgdGhpbmtpbmcgaXQgd2VudCBi YWNrIHRvIE1JTUUuIEJ1dCBhZnRlciBjdXJzb3J5DQpzZWFyY2hpbmcsIHRoZSBlYXJsaWVzdCBy ZWZlcmVuY2UgSSBoYXZlIGZvdW5kIGlzIGluIFJGQzMyMDQuIFRoYXQNCnByZWRhdGVzIDMyNjEu IEl0IGRvZXNuJ3Qgc2F5IFNIT1VMRC4gUmF0aGVyLCBpdCBzYXlzOg0KDQogICAgSWYgdGhlIGhh bmRsaW5nIHBhcmFtZXRlciBpcyBtaXNzaW5nLCB0aGUgdmFsdWUgInJlcXVpcmVkIiBpcyB0byBi ZQ0KICAgIGFzc3VtZWQuDQoNClRoYXQgaXNuJ3Qgbm9ybWF0aXZlLCBidXQgaXQgc291bmRzIGxp a2UgTVVTVC4NCg0KICAgICAgICBUaGFua3MsDQogICAgICAgIFBhdWwNCg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B37C7DAF7ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+SGkgUGF1bCw8YnI+DQo8YnI+DQpNw7Z0 ZSB0aGF0IGlzc3VlIDIpIGlzIG5vdCBhYm91dCB0aGUgaGFuZGxpbmcgcGFyYW1ldGVyLCBidXQg dGhlIGNvbnRlbnQgZGlzcG9zaXRpb24gdHlwZSAoZS5nLiBzZXNzaW9uLCByZW5kZXIgZXRjKS48 YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KU2VudCBm cm9tIG15IFdpbmRvd3MgUGhvbmU8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8aHI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6 MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbToNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0ibWFpbHRv OnBreXppdmF0QGFsdW0ubWl0LmVkdSI+UGF1bCBLeXppdmF0PC9hPjwvc3Bhbj48YnI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsg Zm9udC13ZWlnaHQ6Ym9sZCI+U2VudDoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+4oCOMDMv4oCOMTIv4oCOMjAxNSAx NzozNDwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNl cmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+VG86DQo8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPjxh IGhyZWY9Im1haWx0bzp3b3JsZXlAYXJpYWRuZS5jb20iPkRhbGUgUi4gV29ybGV5PC9hPjsNCjxh IGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iPkNocmlzdGVyIEhv bG1iZXJnPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxz YW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6DQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjEx cHQiPjxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj5zaXBjb3JlQGlldGYub3JnPC9h Pjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlm OyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDoNCjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+ UmU6IFtzaXBjb3JlXSBDb250ZW50LURpc3Bvc2l0aW9uIHF1ZXN0aW9ucyAtIGVycmF0YSBzdWdn ZXN0aW9uPC9zcGFuPjxicj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8Zm9udCBzaXplPSIyIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+T24g MTIvMy8xNSA5OjM2IEFNLCBEYWxlIFIuIFdvcmxleSB3cm90ZTo8YnI+DQomZ3Q7IENocmlzdGVy IEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7IHdyaXRlczo8 YnI+DQomZ3Q7Jmd0OyBUaGVyZSB3ZXJlIHR3byBpc3N1ZXM6PGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyBJc3N1ZSAxKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJcyB0aGUgZGVmYXVsdCBo YW5kbGluZyB2YWx1ZSAmcXVvdDtyZXF1aXJlZCZxdW90OyBhbHNvIGlmIHRoZSBDLUQgaGVhZGVy IGZpZWxkIGlzIG5vdCBwcmVzZW50Pzxicj4NCiZndDsmZ3Q7IElzc3VlIDIpJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IERpZmZlcmVudCBNSU1FIHR5cGVzIHNlZW0gdG8gYXNzdW1lIGRpZmZlcmVu dCBkZWZhdWx0IGRpc3Bvc2l0aW9uIHR5cGVzIHZhbHVlcy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IEluIHRoaXMgZS1tYWlsIEkgZm9jdXMgb24gaXNzdWUgMSkuPGJyPg0KJmd0OyZndDsg Wy4uLl08YnI+DQomZ3Q7Jmd0OyBORVcgVEVYVDo8YnI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtUaGUgaGFuZGxpbmcgcGFyYW1ldGVyLCBoYW5kbGlu Zy1wYXJhbSwgZGVzY3JpYmVzIGhvdyB0aGUgVUFTIHNob3VsZDxicj4NCiZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlYWN0IGlmIGl0IHJlY2VpdmVzIGEgbWVzc2Fn ZSBib2R5IHdob3NlIGNvbnRlbnQgdHlwZSBvciBkaXNwb3NpdGlvbjxicj4NCiZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgaXQgZG9lcyBub3QgdW5kZXJzdGFu ZC4mbmJzcDsgVGhlIHBhcmFtZXRlciBoYXMgZGVmaW5lZCB2YWx1ZXMgb2Y8YnI+DQomZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtvcHRpb25hbCZxdW90OyBh bmQgJnF1b3Q7cmVxdWlyZWQmcXVvdDsuJm5ic3A7IElmIHRoZSBoYW5kbGluZyBwYXJhbWV0ZXIg aXMgbWlzc2luZywgb3IgaWY8YnI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB0aGUgQ29udGVudC1EaXNwb3NpdGlvbiBoZWFkZXIgZmllbGQgaXMgbWlz c2luZywgdGhlIHZhbHVlICZxdW90O3JlcXVpcmVkJnF1b3Q7PGJyPg0KJmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTVVTVCBiZSBhc3N1bWVkLiZuYnNwOyBU aGUgaGFuZGxpbmcgcGFyYW1ldGVyIGlzIGRlc2NyaWJlZCBpbiBSRkMgMzIwNCBbMTldLiZxdW90 Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYXQgZXJyYXR1bSBtYWtlcyBzZW5zZSB0byBtZS4mbmJz cDsgSXQgc2VlbXMgdG8gZG9jdW1lbnQgd2hhdCB0aGUgb3JpZ2luYWw8YnI+DQomZ3Q7IGludGVu dGlvbiB3YXMuPGJyPg0KPGJyPg0KQWdyZWUsIGV4Y2VwdCBzZWUgYmVsb3cuPGJyPg0KPGJyPg0K Jmd0OyBUaGUgYmlnZ2VzdCBjaGFuZ2UgaXMgY2hhbmdpbmcgU0hPVUxEIHRvIE1VU1QsIGJ1dCBJ PGJyPg0KJmd0OyBkb24ndCBzZWUgYSBwcm9ibGVtIHdpdGggdGhhdC48YnI+DQo8YnI+DQpJJ20g dW5kZWNpZGVkIG9uIHRoYXQsIGFuZCB3b3VsZCBsaWtlIHRvIGRpc2N1c3MuPGJyPg0KPGJyPg0K UmlnaHQgbm93LCBpZiBDLUQgaXMgcHJlc2VudCwgYnV0ICdoYW5kbGluZycgaXMgbWlzc2luZyB0 aGVuICZxdW90O3JlcXVpcmVkJnF1b3Q7IDxicj4NCipTSE9VTEQqIGJlIGFzc3VtZWQuIFRoYXQg b2YgY291cnNlIGJlZ3MgdGhlIHF1ZXN0aW9uIG9mIHdoZW4gaXQgd291bGQgPGJyPg0KYmUgYXBw cm9wcmlhdGUgdG8gaWdub3JlIHRoZSBTSE9VTEQuPGJyPg0KPGJyPg0KSWYgdGhlcmUgYXJlIGFu eSB2YWxpZCByZWFzb25zLCB0aGVuIElTVE0gdGhhdCB0aGV5IHdvdWxkIHByb2JhYmx5IGFsc28g PGJyPg0KYXBwbHkgd2hlbiB0aGUgQy1EIGlzIG1pc3NpbmcuPGJyPg0KPGJyPg0KU28gdGhlIHJl YWwgcXVlc3Rpb24gaXMgd2hhdCwgaWYgYW55LCBjb25kaXRpb25zIGp1c3RpZnkgdmlvbGF0aW5n IHRoZSA8YnI+DQpTSE9VTEQ/PGJyPg0KPGJyPg0KJmd0OyBJbiByZWdhcmQgdG8gaXNzdWUgMiwg SSBkb24ndCBzZWUgYSBwcm9ibGVtLjxicj4NCiZndDs8YnI+DQomZ3Q7IEVpdGhlciB0aGUgVUEg JnF1b3Q7dW5kZXJzdGFuZHMmcXVvdDsgdGhlIHBhcnRpY3VsYXIgTUlNRSB0eXBlIG9yIG5vdC48 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIGl0IGRvZXMsIHRoZSBV QSBjaGVja3MgZm9yIENvbnRlbnQtRGlzcG9zaXRpb24uPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJZiBDb250ZW50LURpc3Bv c2l0aW9uIGlzIHByZXNlbnQsIHRoZSBkaXNwLXR5cGUgZGV0ZXJtaW5lcyB0aGU8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhhbmRsaW5nLjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSWYgQ29udGVudC1EaXNwb3Np dGlvbiBpcyBub3QgcHJlc2VudCwgVUEgdXNlcyB0aGUgZGVmYXVsdCBoYW5kbGluZyBmb3I8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBNSU1FIHR5cGUuPGJyPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJZiBpdCBkb2VzIG5vdCwgdGhlIFVBIGNoZWNrcyB3 aGV0aGVyIGhhbmRsaW5nPW9wdGlvbmFsIGlzIHByZXNlbnQuPGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJZiBpdCBpcyBwcmVz ZW50LCB0aGUgVUEgaWdub3JlcyB0aGUgYm9keSBwYXJ0Ljxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSWYgaXQgaXMgbm90IHBy ZXNlbnQsIHRoZSBVQSByZWplY3RzIHRoZSByZXF1ZXN0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEhv d2V2ZXIsIEkgYW0gYXNzdW1pbmcgdGhhdCB0aGUgJnF1b3Q7ZGVmYXVsdCBjb250ZW50IGRpc3Bv c2l0aW9uJnF1b3Q7IGlzIHB1cmVseTxicj4NCiZndDsgYSBkaXNwLXR5cGUgKGkuZS4sIHJlbmRl ciwgc2Vzc2lvbiwgZXRjLiksIGFuZCBkb2VzIG5vdCBpbmNsdWRlIGE8YnI+DQomZ3Q7IGhhbmRs aW5nLXBhcmFtLjxicj4NCjxicj4NCkkgdGhpbmsgSSBhZ3JlZS4gVGhlIGFsdGVybmF0aXZlIHdv dWxkIGJlIHRoYXQgdGhlIGRlZmF1bHQgZGlzcG9zaXRpb24gPGJyPg0KZm9yIGEgbWltZSB0eXBl IGluY2x1ZGVzIGEgZGVmYXVsdCBmb3IgdGhlIGhhbmRsaW5nIHZhbHVlLiAoVGhhdCBtaWdodCA8 YnI+DQpiZSBhIHJlYXNvbiBmb3IgU0hPVUxEIHJhdGhlciB0aGFuIE1VU1QgYWJvdmUuKTxicj4N Cjxicj4NCkJ1dCB0aGF0IGlzIG5vbnNlbnNlLiBUbyBrbm93IHRoZSBkZWZhdWx0IGRpc3Bvc2l0 aW9uIGZvciBhIG1pbWUgdHlwZSA8YnI+DQp5b3UgbXVzdCB1bmRlcnN0YW5kIHRoZSBtaW1lIHR5 cGUuIEFuZCBpZiB5b3UgdW5kZXJzdGFuZCBpdCwgdGhlbiB0aGUgPGJyPg0KaGFuZGxpbmcgcGFy YW1ldGVyIGlzIGlycmVsZXZhbnQgdG8geW91Ljxicj4NCjxicj4NCldlIG1heSBuZWVkIHRvIGlu dmVzdGlnYXRlIHRoZSBoaXN0b3J5IG9mIHRoaXMgcGFyYW1ldGVyIHRvIHVuZGVyc3RhbmQgPGJy Pg0KdGhlIGludGVudC4gSSB3YXMgdGhpbmtpbmcgaXQgd2VudCBiYWNrIHRvIE1JTUUuIEJ1dCBh ZnRlciBjdXJzb3J5IDxicj4NCnNlYXJjaGluZywgdGhlIGVhcmxpZXN0IHJlZmVyZW5jZSBJIGhh dmUgZm91bmQgaXMgaW4gUkZDMzIwNC4gVGhhdCA8YnI+DQpwcmVkYXRlcyAzMjYxLiBJdCBkb2Vz bid0IHNheSBTSE9VTEQuIFJhdGhlciwgaXQgc2F5czo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsm bmJzcDsgSWYgdGhlIGhhbmRsaW5nIHBhcmFtZXRlciBpcyBtaXNzaW5nLCB0aGUgdmFsdWUgJnF1 b3Q7cmVxdWlyZWQmcXVvdDsgaXMgdG8gYmU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgYXNzdW1l ZC48YnI+DQo8YnI+DQpUaGF0IGlzbid0IG5vcm1hdGl2ZSwgYnV0IGl0IHNvdW5kcyBsaWtlIE1V U1QuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFRoYW5rcyw8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg UGF1bDxicj4NCjxicj4NCjxicj4NCjwvZGl2Pg0KPC9zcGFuPjwvZm9udD4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B37C7DAF7ESESSMB209erics_-- From nobody Thu Dec 3 09:47:57 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51561B2C57 for ; Thu, 3 Dec 2015 09:47:55 -0800 (PST) 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 NQn5xObRV3a2 for ; Thu, 3 Dec 2015 09:47:55 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A771A8A6A for ; Thu, 3 Dec 2015 09:47:54 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-12v.sys.comcast.net with comcast id p5mv1r0022S2Q5R015nt6w; Thu, 03 Dec 2015 17:47:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-16v.sys.comcast.net with comcast id p5nt1r00J3KdFy1015ntB4; Thu, 03 Dec 2015 17:47:53 +0000 To: sipcore@ietf.org References: <39B5E4D390E9BD4890E2B3107900610112AEC437@ESESSMB301.ericsson.se> <7699C626-BCC4-4B8F-AB14-0C81D7BE62D7@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112AEE460@ESESSMB301.ericsson.se> From: Paul Kyzivat Message-ID: <56608048.2030700@alum.mit.edu> Date: Thu, 3 Dec 2015 12:47:52 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1449164873; bh=iq44x/tWLfgSNV6me55zifm+BBYvFHwleSucuF+Dn2w=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=MyVDZv2Wy1Ybfo4UE034IBDAyw9jDPejLG4gtriK3RCp708mVABhT1vRnt/zOcBl6 QBWYO0U5UN2WjemITo9AWSzDuqVpKEAXGUtkT9PKmqNorD3AC3QPGMA6T13/FxnXFQ Xl5T8lJyit2kPk8F/NELNhIlrRwWfcYbtApQnxNnneOWLd3MBOsTwa3cLPxTLSm+ry JcYz6l1i005HWjgHE1tXMvGtTSgQBC7fw/C75WPBhPAJdQGVexilOD6FnlMPAHpRri +vCLXnwBQ3b1bhev2a2OvrNmruo4Y8BAh32ILhU++XiISsTtFf8QDJs23flRfIFN39 UhcHNPF83CsEw== Archived-At: Subject: Re: [sipcore] A new SIP header fields with "P-" name 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, 03 Dec 2015 17:47:56 -0000 On 12/3/15 11:07 AM, James Cloos wrote: >>>>>> "IS" == Ivo Sedlacek writes: > > IS> One proposed solution is to define and use P-Cellular-Network-Info > IS> header field. > > The proper solution is to drop the 'P-' from the proposed header name; > call it Cellular-Network-Info instead of P-Cellular-Network-Info. > > All 5727 says wrt P- is don't bother with a P- prefix on new headers. Yes. I *think* that this header field would qualify as "informational". (Pending review of its specification.) In that case the criterion for registration is expert review. (I don't know who the expert is for this.) Thanks, Paul From nobody Thu Dec 3 09:49:41 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 9A5FB1A00A5 for ; Thu, 3 Dec 2015 09:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 l-TMFQx6QrVT for ; Thu, 3 Dec 2015 09:49:39 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC9091B2D46 for ; Thu, 3 Dec 2015 09:42:18 -0800 (PST) Received: by ykba77 with SMTP id a77so94326613ykb.2 for ; Thu, 03 Dec 2015 09:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BJpnJ3ICSXTlQ2ACHfCIPIh404O32kqGjn18N35khcE=; b=s1KGfgABC5Jm2ROqY5z+1hGjcCVdAYXTklEwlLLLl/CdlxpyO9M7aKefGG1VTprQ0z X0+KIlQCD2sZm1r+ojtCFe59ccbvB9NV5SHmenfpSy2feezaz2jBfM4JLbANgYYZY+K/ UQv/44+feoQrzKB+jPf0X5/dA/GBIbUT4YCHxIZSNCfqzJATLptwrDJu4QLv8XZaGpRI CxLIfwzJ8cTpWqlWEjyu0nxhPwegXxDaBCe8Hmk3PbwGfMSQDGKbruHIOJU8A2406sVt yDuCffr1lHq4q9xbz+rCPSZ1KzNiEowP7Zp0iWtyYFIM7kiE9BYI5AYFoXt6PmPa8TPJ BedA== MIME-Version: 1.0 X-Received: by 10.129.87.69 with SMTP id l66mr8459097ywb.251.1449164537950; Thu, 03 Dec 2015 09:42:17 -0800 (PST) Received: by 10.37.90.65 with HTTP; Thu, 3 Dec 2015 09:42:17 -0800 (PST) In-Reply-To: References: <39B5E4D390E9BD4890E2B3107900610112AEC437@ESESSMB301.ericsson.se> <7699C626-BCC4-4B8F-AB14-0C81D7BE62D7@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112AEE460@ESESSMB301.ericsson.se> Date: Thu, 3 Dec 2015 11:42:17 -0600 Message-ID: From: Mary Barnes To: James Cloos Content-Type: multipart/alternative; boundary=001a113b7d1c817c9b052601e9c3 Archived-At: Cc: Ben Campbell , "sipcore@ietf.org" , Ivo Sedlacek Subject: Re: [sipcore] A new SIP header fields with "P-" name 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, 03 Dec 2015 17:49:40 -0000 --001a113b7d1c817c9b052601e9c3 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 3, 2015 at 10:07 AM, James Cloos wrote:>>>>> "IS" == Ivo Sedlacek writes: > > > IS> One proposed solution is to define and use P-Cellular-Network-Info > IS> header field. > > The proper solution is to drop the 'P-' from the proposed header name; > call it Cellular-Network-Info instead of P-Cellular-Network-Info. > [MB] And, the proper standard's process is to bring the problem that is being solved to the DISPATCH WG for discussion and determination as to whether a new header is the best option to solve that problem or whether existing headers, extensions thereof, header field parameters, etc. are workable options. [/MB] > > All 5727 says wrt P- is don't bother with a P- prefix on new headers. [MB] Related to my comment above, folks might want to read RFC 5727 in its entirety.[/MB] > > -JimC > -- > James Cloos OpenPGP: 0x997A9F17ED7DAEA6 > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a113b7d1c817c9b052601e9c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 3, 2015 at 10:07 AM, James Cloos <cloos@jhcloos.com>= wrote:>>>>> "IS" =3D=3D Ivo Sedlacek <ivo.sedlacek@ericss= on.com> writes:

IS> One proposed solution is to define and use P-Cellular-Network-Info IS> header field.

The proper solution is to drop the 'P-' from the proposed header na= me;
call it Cellular-Network-Info instead of P-Cellular-Network-Info.
=C2=A0
[MB] And, the proper standard's process is= to bring the problem that is being solved to the DISPATCH WG for discussio= n and determination as to whether a new header is the best option to solve = that problem or whether existing headers, extensions thereof, header field = parameters, etc. are workable options.=C2=A0
=C2=A0[/MB]=C2=A0

All 5727 says wrt P- is don't bother with a P- prefix on new headers.
[MB] Related to my comment above, folks might want to read = RFC 5727 in its entirety.[/MB]
=C2=A0
=C2=A0

-JimC
--
James Cloos <cloo= s@jhcloos.com>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OpenPGP: 0x997A9F17E= D7DAEA6

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--001a113b7d1c817c9b052601e9c3-- From nobody Thu Dec 3 14:04:08 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1A01ACE60 for ; Thu, 3 Dec 2015 14:04:07 -0800 (PST) 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 xH_yLDdV-Gby for ; Thu, 3 Dec 2015 14:04:05 -0800 (PST) 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 ED0851ACE5F for ; Thu, 3 Dec 2015 14:04:04 -0800 (PST) Received: from mutabilis-2.local (pool-173-57-210-37.dllstx.fios.verizon.net [173.57.210.37]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tB3M40re023432 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 3 Dec 2015 16:04:01 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-210-37.dllstx.fios.verizon.net [173.57.210.37] claimed to be mutabilis-2.local To: Christer Holmberg , SIPCORE References: <7594FB04B1934943A5C02806D1A2204B37C7C70D@ESESSMB209.ericsson.se> From: "A. Jean Mahoney" Message-ID: <5660BC4A.2030908@nostrum.com> Date: Thu, 3 Dec 2015 16:03:54 -0600 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: <7594FB04B1934943A5C02806D1A2204B37C7C70D@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info 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, 03 Dec 2015 22:04:07 -0000 Hi Christer, On 12/3/15 4:22 AM, Christer Holmberg wrote: > Hi, > > 3GPP has been studying possible misalignments between the P- header > definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229. > > Rather than posting all the issues in a single e-mail, I will send > e-mails per header field. This e-mail is about P-Access-Network-Info, > where two issues were identified. > > *Issue 1) 3GPP TS 24.229 allows PANI in ACK requests* > > Back in 2012, CT1 agreed on a case, related to network provided location > information, where PANI is needed in ACK. > > Now, this should have been introduced in RFC7315 (which wasn’t published > until 2014), but unfortunately the authors (myself included) missed that > part. > > I assume this cannot be fixed with an errata – it would require an > update to RFC7315 (probably not a bis, but a draft that updates the > affected part(s) of RFC7315). This change would be more than can be handled by an erratum, and I think that an update to RFC 7315 makes sense, with some text on what the use case is. I tried to find the scenario in 24.229, but the TS didn't yield that info easily. However, I did find inconsistencies in 24.229 on using PANI in ACK requests. For instance: 5.1.6.8.2: "...the UE shall include in the P-Access-Network-Info header field in any request for a dialog, any subsequent request (except ACK requests and CANCEL requests) or response (except CANCEL responses) within a dialog or any request." 5.1.6.10 Note 3: "The UE will populate the P-Access-Network-Info header field in any request (except ACK requests and CANCEL requests) or response (except CANCEL responses) within a dialog with the current point of attachment to the IP-CAN.... 5.7.1.3: "The AS may also receive information about the served user access network in other requests (excluding ACK requests and CANCEL requests and responses). This information can be obtained from the P-Access-Network-Info header field." But in other places, using PANI in ACK is implied/allowed: 5.1.2A.2: "If available to the UE ..., the UE shall insert a P-Access Network-Info header field into any response to a request for a dialog, any subsequent request (except CANCEL requests) or response (except CANCEL responses) within a dialog or any response to a standalone method..." TS 24.229 5.2.1: "When the P-CSCF receives any request or response from the UE, the P-CSCF: ... 4) may insert a P-Access-Network-Info header field where: ..." TS 24.229 8.1.1 "If in normal operation the UE generates requests or responses containing a P-Access-Network-Info header field which included a value of ..." Table A.165/A.7: Supported header fields within the ACK request > > *Issue 2) RFC 7315 is inconsistent on whether PANI is > allowed in SIP responses* > > RFC 3455, and 3GPP TS 24.229, allow usage of the PANI header field in > SIP responses. However, RFC 7315 is inconsistent. > > *Chapter 4.4 says:* > > “When a UA generates a SIP request or response that it > knows is going > > to be securely sent to its SIP proxy that is providing > services, the > > UA inserts a P-Access-Network-Info header field into > field the SIP > > message.” > > … which DOES imply that PANI is allowed in SIP responses. Both RFC 3455 and RFC 7315 have the same text here. So far so good. > > *Chapter 4.4.2.1*implies the same thing: > > “A UA that supports this extension and is willing to > disclose the > > related parameters MAY insert the P-Access-Network-Info > header field > > in any SIP request or response.” > Both RFC 3455 and RFC 7315 have the same text here. So far so good. > However, *chapter 5.7*. says: > > 5.7. New Headers > > “The P-Associated-URI header field can appear in SIP > REGISTER method > > and 2xx resonses. The P-Called-Party-ID header field > can appear in > > SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE > methods and all > > responses. The P-Visited-Network-ID header field can > appear in all > > SIP methods except ACK, BYE, and CANCEL and all > responses. The > > P-Access-Network-Info header field can appear in all SIP > methods > > except ACK and CANCEL. The P-Charging-Vector header > field can appear > > in all SIP methods except CANCEL. The > P-Charging-Function-Addresses > > header field can appear in all SIP methods except ACK > and CANCEL.” > > …where responses, unlike in the case of other header fields, are not > explicitly mentioned for PANI. And here is where it goes wrong - RFC 7315 attempted to capture in prose the content of Table 1 in RFC 3455, but did not cover that PANI was allowed in responses, which is clear in the RFC 3455 table. Nothing in RFC 7315 Appendix A indicates that this change was intentional. > > I assume this is just a bug in section 5.7, which could be fixed with an > errata: This does appear to be a bug. > > OLD TEXT: > > “The P-Access-Network-Info header field can appear in > all SIP methods > > except ACK and CANCEL.” > > NEW TEXT: > > “The P-Access-Network-Info header field can appear in > all SIP methods > > except ACK and CANCEL and all responses.” How about this NEW TEXT? "The P-Access-Network-Info header field can appear in any request except for the CANCEL request and the ACK request. The P-Access-Network-Info header field can appear in any response, except in responses to CANCEL." But since we're trying to clarify - what about 100 Trying (specifically 100, not 1xx) responses? Does PANI make sense there? Thanks, Jean > > Regards, > > Christer > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Dec 3 14:07: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 4685B1ACE76 for ; Thu, 3 Dec 2015 14:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 IB01FYdLPGmi for ; Thu, 3 Dec 2015 14:07:05 -0800 (PST) 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 44A281ACE72 for ; Thu, 3 Dec 2015 14:07:05 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tB3M72KW023698 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 3 Dec 2015 16:07:03 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Paul Kyzivat , sipcore@ietf.org References: <39B5E4D390E9BD4890E2B3107900610112AEC437@ESESSMB301.ericsson.se> <7699C626-BCC4-4B8F-AB14-0C81D7BE62D7@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112AEE460@ESESSMB301.ericsson.se> <56608048.2030700@alum.mit.edu> From: Adam Roach Message-ID: <5660BD06.6010701@nostrum.com> Date: Thu, 3 Dec 2015 16:07:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <56608048.2030700@alum.mit.edu> Content-Type: multipart/alternative; boundary="------------030209040205030807070200" Archived-At: Subject: Re: [sipcore] A new SIP header fields with "P-" name 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, 03 Dec 2015 22:07:06 -0000 This is a multi-part message in MIME format. --------------030209040205030807070200 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 12/3/15 11:47, Paul Kyzivat wrote: > Yes. I *think* that this header field would qualify as > "informational". (Pending review of its specification.) In that case > the criterion for registration is expert review. (I don't know who the > expert is for this.) That'd be me. /a --------------030209040205030807070200 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 12/3/15 11:47, Paul Kyzivat wrote:
Yes. I *think* that this header field would qualify as "informational".  (Pending review of its specification.) In that case the criterion for registration is expert review. (I don't know who the expert is for this.)

That'd be me.

/a
--------------030209040205030807070200-- From nobody Fri Dec 4 01:13:21 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 A346F1A01A9 for ; Fri, 4 Dec 2015 01:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzGPK_UosXNe for ; Fri, 4 Dec 2015 01:13:18 -0800 (PST) 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 523B31A0187 for ; Fri, 4 Dec 2015 01:13:18 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-84-5661592cb89e Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id DA.9F.05041.C2951665; Fri, 4 Dec 2015 10:13:16 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.31]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0248.002; Fri, 4 Dec 2015 10:13:15 +0100 From: Ivo Sedlacek To: "sipcore@ietf.org" Thread-Topic: [sipcore] A new SIP header fields with "P-" name Thread-Index: AQHRLeTFtzAvzI7DQoGlsVH1re72C566iqdw Date: Fri, 4 Dec 2015 09:13:14 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112AF324A@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B3107900610112AEC437@ESESSMB301.ericsson.se> <7699C626-BCC4-4B8F-AB14-0C81D7BE62D7@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112AEE460@ESESSMB301.ericsson.se> In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2J7iK5OZGKYwfH3ghZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxub2vcwFN5gqnt75ztbAOI2pi5GTQ0LAROLRiU0sELaYxIV7 69m6GLk4hAQOM0rMmvuVGSQhJLCIUaJrhQ+IzSagJzFxyxFWEFtEQFNi+bet7CC2sICtxKsb V9gg4nYSd878YYewjSR+nt0JtoxFQEXiUesPsF5eAV+J7c/mskMse8MoMW/aUaAiDg5OAQOJ Bb90QWoYBWQlrv7pZQSxmQXEJW49mQ91tIDEkj3nmSFsUYmXj/+xgrRKCChJTNuaBlGuI7Fg 9yc2CFtbYtnC18wQawUlTs58wjKBUXQWkqmzkLTMQtIyC0nLAkaWVYyixanFxbnpRkZ6qUWZ ycXF+Xl6eaklmxiBEXFwy2+rHYwHnzseYhTgYFTi4S04mRAmxJpYVlyZe4hRgoNZSYSXWSYx TIg3JbGyKrUoP76oNCe1+BCjNAeLkjhvM9ODUCGB9MSS1OzU1ILUIpgsEwenVAOj+e0DxQcv HP0dZ3lSeC7L6bj5rFy3HnYsXyF0OaZr6baMuY5hnd8OrV5+eqEhazHf4qRZza+T7+04aK93 0EejTVlsxqzKNX0KhZPPJcsbe83c0HpZK5NzkugJjVURYXv+7l21xyli32PlPUr578Nn/jdc JxH6+chtTfbouZpejZayfgwGGceNlFiKMxINtZiLihMBENhGb4QCAAA= Archived-At: Subject: Re: [sipcore] A new SIP header fields with "P-" name 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, 04 Dec 2015 09:13:19 -0000 Just to give you the complete picture - the other alternative discussed in = 3GPP was to extend P-Access-Network-Info header field with a new parameter = with value containing the information on the last recently seen 3GPP radio = network cell and another parameter indicating how old this information is. Kind regards Ivo Sedlacek From nobody Fri Dec 4 03:20:55 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9421B302E for ; Fri, 4 Dec 2015 03:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0GZ44D4enAX for ; Fri, 4 Dec 2015 03:20:52 -0800 (PST) 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 51E241B3033 for ; Fri, 4 Dec 2015 03:20:51 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-45-5661771105f1 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 73.5D.05041.11771665; Fri, 4 Dec 2015 12:20:49 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Fri, 4 Dec 2015 12:20:48 +0100 From: Christer Holmberg To: "A. Jean Mahoney" , SIPCORE Thread-Topic: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Thread-Index: AdEttCY/6pwG9PPZQjGda7vzjTcvpgAWffcAAB2BxGA= Date: Fri, 4 Dec 2015 11:20:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C7FC93@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37C7C70D@ESESSMB209.ericsson.se> <5660BC4A.2030908@nostrum.com> In-Reply-To: <5660BC4A.2030908@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7h65geWKYwfVVQhYNnStZLb7+2MTm wOSxZMlPJo9ZO5+wBDBFcdmkpOZklqUW6dslcGUs+HuSteCpUcWc71+YGhgPqHUxcnJICJhI /Pj/nRnCFpO4cG89WxcjF4eQwGFGicYvOxkhnMWMEnN2bQeq4uBgE7CQ6P6nDdIgIuAu8bv5 JliNsEAHo8S3vj1g3SICnYwSr6d1s0JUWUl8XLmLBcRmEVCR6Jn/ESzOK+Ar8frSc7C4kECe xJb7/WA2p4C2xO+Jz8FOYgQ66fupNUwgNrOAuMStJ/OZIE4VkFiy5zzU2aISLx//Y4WwFSU+ vtrHCFGvI7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYyixanF xbnpRkZ6qUWZycXF+Xl6eaklmxiBsXJwy2+rHYwHnzseYhTgYFTi4S04mRAmxJpYVlyZe4hR goNZSYSXWSYxTIg3JbGyKrUoP76oNCe1+BCjNAeLkjhvM9ODUCGB9MSS1OzU1ILUIpgsEwen VAOjekX3gviXUdm2J03fRX6qThFQd9qwqOqJT1jYl88NTpeaNzD1GR/t2N1c2brlpZ5bxlLh iGtGjc2Hqw6U+y89lb1QOEv8Qj+PrFZdXe2OjV28GrKbswLbfz7PZP34dIHwq2YT55ffdfoi U7lyCzYffrIicRYbR4HgdMawqOaKb9mHO/SYOZVYijMSDbWYi4oTARz/vOqRAgAA Archived-At: Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info 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, 04 Dec 2015 11:20:54 -0000 Hi Jean, >> 3GPP has been studying possible misalignments between the P- header=20 >> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229. >> >> Rather than posting all the issues in a single e-mail, I will send=20 >> e-mails per header field. This e-mail is about P-Access-Network-Info,=20 >> where two issues were identified. >> >> *Issue 1) 3GPP TS 24.229 allows PANI in ACK requests* >> >> Back in 2012, CT1 agreed on a case, related to network provided=20 >> location information, where PANI is needed in ACK. >> >> Now, this should have been introduced in RFC7315 (which wasn't=20 >> published until 2014), but unfortunately the authors (myself included)=20 >> missed that part. >> >> I assume this cannot be fixed with an errata - it would require an=20 >> update to RFC7315 (probably not a bis, but a draft that updates the=20 >> affected part(s) of RFC7315). > > > This change would be more than can be handled by an erratum, and I think = that an update to RFC 7315 makes sense, with some text on what the use=20 > case is. I tried to find the scenario in 24.229, but the TS didn't yield = that info easily.=20 Correct, and the CR which added support of PANI for ACK didn't give much in= formation either. It said: "RFC3455 currently does not allow the usage of the P-Acces= s-Network-Info header field in the SIP ACK request. =20 However, in order to implement all scenarios defined for n= etwork provided location information, in order to avoid having to=20 implement B2BUA functionality in the P-CSCF, the P-CSCF ne= eds to be able to insert the P-Access-Network-Info header field in=20 that requests." Now, I actually wrote that CR myself, but as it was back in 2012 I can't re= member the details from my head. So, I'd have to look into that :) > However, I did find inconsistencies in 24.229 on using PANI in ACK reques= ts. For instance: > > 5.1.6.8.2: "...the UE shall include in the P-Access-Network-Info header f= ield in any request for a dialog, any subsequent request (except ACK reques= ts=20 > and CANCEL requests) or response (except CANCEL responses) within a dialo= g or any request." > > 5.1.6.10 Note 3: "The UE will populate the P-Access-Network-Info header f= ield in any request (except ACK requests and CANCEL requests) or response=20 > (except CANCEL responses) within a dialog with the current point of attac= hment to the IP-CAN.... > > 5.7.1.3: "The AS may also receive information about the served user acces= s network in other requests (excluding ACK requests and CANCEL requests and= =20 > responses). This information can be obtained from the P-Access-Network-In= fo header field." > > But in other places, using PANI in ACK is implied/allowed: > > 5.1.2A.2: "If available to the UE ..., the UE shall insert a P-Access Net= work-Info header field into any response to a request for a dialog, any sub= sequent request=20 >(except CANCEL requests) or response (except CANCEL responses) within a di= alog or any response to a standalone method..." > > TS 24.229 5.2.1: "When the P-CSCF receives any request or response from t= he UE, the P-CSCF: ... 4) may insert a P-Access-Network-Info header field w= here: ..." > > TS 24.229 8.1.1 "If in normal operation the UE generates requests or resp= onses containing a P-Access-Network-Info header field which included a valu= e of ..." > > Table A.165/A.7: Supported header fields within the ACK request Correct. 24.229 is inconsistent, and needs to be fixed. ------------------- >> *Issue 2) RFC 7315 is inconsistent on whether PANI is >> allowed in SIP responses* >> >> RFC 3455, and 3GPP TS 24.229, allow usage of the PANI header field in=20 >> SIP responses. However, RFC 7315 is inconsistent. ... >> However, *chapter 5.7*. says: >> >> 5.7. New Headers >> >> "The P-Associated-URI header field can appear in SIP=20 >> REGISTER method and 2xx resonses. The P-Called-Party-ID= header field=20 >> can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, a= nd MESSAGE=20 >> methods and all responses. The P-Visited-Network-ID hea= der field can=20 >> appear in all SIP methods except ACK, BYE, and CANCEL an= d all=20 >> responses. The P-Access-Network-Info header field can a= ppear in all=20 >> SIP methods except ACK and CANCEL. The P-Charging-Vecto= r header=20 >> field can appear in all SIP methods except CANCEL. The= =20 >> P-Charging-Function-Addresses header field can appear in= all SIP methods except ACK=20 >> and CANCEL." >> >> ...where responses, unlike in the case of other header fields, are not=20 >> explicitly mentioned for PANI. > > > And here is where it goes wrong - RFC 7315 attempted to capture in prose = the content of Table 1 in RFC 3455, but did not cover that PANI was allowed= in responses, which is clear in the RFC 3455 table. > >Nothing in RFC 7315 Appendix A indicates that this change was intentional. > >> I assume this is just a bug in section 5.7, which could be fixed with an= errata: > > >This does appear to be a bug. > > >> OLD TEXT: >> >> "The P-Access-Network-Info header field can appear in=20 >> all SIP methods except ACK and CANCEL." >> >> NEW TEXT: >> >> "The P-Access-Network-Info header field can appear in=20 >> all SIP methods except ACK and CANCEL and all res= ponses." > > > How about this NEW TEXT? > > "The P-Access-Network-Info header field can appear in any request except = for the CANCEL request and the ACK request. The P-Access-Network-Info heade= r field can appear in any response, except in responses to CANCEL." > > But since we're trying to clarify - what about 100 Trying (specifically 1= 00, not 1xx) responses? Does PANI make sense there? I'd have to look at the details. Now, in my e-mails regarding the other P- header fields, all of them requir= e a fix in section 5.7. So, I assume a SINGLE errata would be better, rather than creating separate= erratas for each header field? That way we can look at the whole paragraph= in one go, instead of working on individual sentencens. Regards, Christer From nobody Fri Dec 4 06:09:06 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 414191B317E for ; Fri, 4 Dec 2015 06:09:05 -0800 (PST) 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 lbEkyQBXY0ol for ; Fri, 4 Dec 2015 06:09:03 -0800 (PST) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAACA1A870B for ; Fri, 4 Dec 2015 06:09:03 -0800 (PST) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-07v.sys.comcast.net with comcast id pS5z1r0082Fh1PH01S92MX; Fri, 04 Dec 2015 14:09:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-08v.sys.comcast.net with comcast id pS921r00B3KdFy101S92f0; Fri, 04 Dec 2015 14:09:02 +0000 To: sipcore@ietf.org References: <7594FB04B1934943A5C02806D1A2204B37C7C70D@ESESSMB209.ericsson.se> <5660BC4A.2030908@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C7FC93@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56619E7C.5090706@alum.mit.edu> Date: Fri, 4 Dec 2015 09:09:00 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C7FC93@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=1449238142; bh=WEi7Dkz1oE8sbIL3LI5WrysafpZLN6nHXGcxgYAUVvA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=m1frGbBVi7sVpiMhmbgjO0KIPPOBu30maMl6Ox9FSKEgVEZN9+5JOMORLytaRMTx/ Kyo8XQ1do8W3PjXzIeefMPQwIjAraCKJpuG4q2JT9pJ4r2GwaaKe2LF8FdHC0FnZ7P 9Y6oZV7Lx4ht1LK+aldOF0mAN6zzfVYA6peIaISXZWPq8rbnuvV6QDacnO54dLMMQf JQFJjXvGd5wx7mSq1avIg/PphO/WuscCNJ9FYJagu5NcAm/RpFyvox3h5LmguGD9SG ZZlT0V1Efl3tdIN2NnKcC5q0uzkJjLv+qU+06llgx+69DBfpxWbRzpkr1DTmt2ngzr Ftff/snRSE2dw== Archived-At: Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info 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, 04 Dec 2015 14:09:05 -0000 On 12/4/15 6:20 AM, Christer Holmberg wrote: > Now, in my e-mails regarding the other P- header fields, all of them require a fix in section 5.7. > > So, I assume a SINGLE errata would be better, rather than creating separate erratas for each header field? That way we can look at the whole paragraph in one go, instead of working on individual sentencens. Yes, I think so. I found the separate emails for each issue a little hard to follow since they were all affecting the same stuff. It is easier to follow the big picture when they are all put together. Thanks, Paul From nobody Fri Dec 4 06:12:59 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 741101B31E5 for ; Fri, 4 Dec 2015 06:12:58 -0800 (PST) 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 DRhi9PmgQtGc for ; Fri, 4 Dec 2015 06:12:57 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B13FC1B31E4 for ; Fri, 4 Dec 2015 06:12:57 -0800 (PST) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-06v.sys.comcast.net with comcast id pSAy1r0022N9P4d01SCx5z; Fri, 04 Dec 2015 14:12:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-13v.sys.comcast.net with comcast id pSCw1r00G3KdFy101SCwHQ; Fri, 04 Dec 2015 14:12:57 +0000 To: sipcore@ietf.org References: <39B5E4D390E9BD4890E2B3107900610112AEC437@ESESSMB301.ericsson.se> <7699C626-BCC4-4B8F-AB14-0C81D7BE62D7@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112AEE460@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112AF324A@ESESSMB301.ericsson.se> From: Paul Kyzivat Message-ID: <56619F67.3050400@alum.mit.edu> Date: Fri, 4 Dec 2015 09:12:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112AF324A@ESESSMB301.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=1449238377; bh=rfyxNg2AnXGXJSQVwAPeSNAcxROFrJaArPb2M0VKL34=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=jqqwLSWPmoSWWBBr3VeceFgcVcQmnc68ww1+awhVsvMIGV9KewzmEm3MxJ7IlvRcP oplpBiKVZv4jWkdpQb8pZDKL9ZLHFz6RT1Yn49Lhbg7eqlUdJStVs/UMJ677flmafe El7bPUXv/Lou04V3Ia1Jg4NX6dkqRIWfxSx0y6sYCktP0Di80fuvxb8PQTVaXbHrrw S8uoFsCdzOXBTLFxOmYTENUcFmicQkfPKE3LEbWLzsrsezkIN7VdiIQfUDQ1x9SDFJ dG+gJedKPy+WV4JVwvYrWyvUc+mlJupNj9oVNFwBoHyk8q0nIawGaOkdU6N+c5MNEY sXJjHsFGb/ypA== Archived-At: Subject: Re: [sipcore] A new SIP header fields with "P-" name 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, 04 Dec 2015 14:12:58 -0000 On 12/4/15 4:13 AM, Ivo Sedlacek wrote: > Just to give you the complete picture - the other alternative discussed in 3GPP was to extend P-Access-Network-Info header field with a new parameter with value containing the information on the last recently seen 3GPP radio network cell and another parameter indicating how old this information is. That seems fine if this new information is really access network info. Generally I would recommend doing whichever is "cleanest". Obviously the semantics are the same either way. Thanks, Paul From nobody Fri Dec 4 06:35:16 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2981A6FFC for ; Fri, 4 Dec 2015 06:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6_mBbujoaS1 for ; Fri, 4 Dec 2015 06:35:10 -0800 (PST) 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 67E3D1A7004 for ; Fri, 4 Dec 2015 06:35:10 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-fb-5661a49cf838 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 83.C5.05041.C94A1665; Fri, 4 Dec 2015 15:35:08 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0248.002; Fri, 4 Dec 2015 15:34:56 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Thread-Index: AdEttCY/6pwG9PPZQjGda7vzjTcvpgAWffcAAB2BxGAABDLmAAACYMQA Date: Fri, 4 Dec 2015 14:34:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C8094B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37C7C70D@ESESSMB209.ericsson.se> <5660BC4A.2030908@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C7FC93@ESESSMB209.ericsson.se> <56619E7C.5090706@alum.mit.edu> In-Reply-To: <56619E7C.5090706@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.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2J7oO6cJYlhBnfapSxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj39zLjAXvRSs2fNzP2MC4UbCLkYNDQsBE 4tdM7S5GTiBTTOLCvfVsXYxcHEIChxklVjz+xArhLGaUWPBnPQtIA5uAhUT3P7AGEYFAiatL JjCD1AgLdDBKfOvbA9YtItDJKPF6WjcrSIOIgJvEz8lBIA0sAioSX5f/YwKxeQV8JS4fnMwM seAKo8T+g98YQRKcAjoSu6dMZAexGYFO+n5qDVgDs4C4xK0n85kgThWQWLLnPDOELSrx8vE/ VghbUeLjq32MEPU6Egt2f2KDsLUlli18zQyxWFDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZ xShanFpcnJtuZKSXWpSZXFycn6eXl1qyiREYKQe3/LbawXjwueMhRgEORiUe3oKTCWFCrIll xZW5hxglOJiVRHiZZRLDhHhTEiurUovy44tKc1KLDzFKc7AoifM2Mz0IFRJITyxJzU5NLUgt gskycXBKNTCGfKlL/+U0K+LKpYWhKs9kuSYscKiqM3zsbx+6I2aR6F7xKZUt4im8vDt/XX0d pHHJ2XrTNP+VXs/43/9ZHiGtOuXySW4BpvtTHlzi1cjWnHTU+kRw3cFfzREFs1nVQ5td2XPj XpWEu9+Td569XSAi7m54KMvWlcwuXR9/Pr59QvjiNJaCblElluKMREMt5qLiRABAy7kjkAIA AA== Archived-At: Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info 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, 04 Dec 2015 14:35:15 -0000 Hi, So, based on my chapter 5.7 fix suggestions for each individual header fiel= d, below is a "compiled" fix suggestion for the whole chapter. Note that I've done some minor editorial changes, based e.g. on Jean's comm= ents. OLD TEXT: 5.7. New Headers The P-Associated-URI header field can appear in SIP REGISTER method and 2xx resonses. The P-Called-Party-ID header field can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods. The P-Visited-Network-ID header field can appear in all SIP methods except ACK, BYE, and CANCEL and all responses. The P-Access-Network-Info header field can appear in all SIP methods except ACK and CANCEL and all responses. The P-Charging-Vector header f= ield can appear in all SIP methods except CANCEL. The P-Charging-Function-Addresses header field can appear in all SIP methods except ACK and CANCEL. NEW TEXT: 5.7. New Headers The P-Associated-URI header field can appear in SIP REGISTER 2xx responses. The P-Called-Party-ID header field can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and in all responses associated with those methods. The P-Visited-Network-ID heade= r field can appear in all SIP methods except ACK, BYE, and CANCEL. The P-Access-Network-Info header field can appear in all SIP methods and responses, except in ACK and CANCEL methods and CANCEL responses. T= he P-Charging-Vector header field can appear in all SIP methods and responses, except in CANCEL methods and CANCEL re= sponses. The P-Charging-Function-Addresses header field can appear in all SIP methods and responses except ACK and = CANCEL. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 4. joulukuuta 2015 16:09 To: sipcore@ietf.org Subject: Re: [sipcore] Misalignments between the P- header definitions in R= FC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info On 12/4/15 6:20 AM, Christer Holmberg wrote: > Now, in my e-mails regarding the other P- header fields, all of them requ= ire a fix in section 5.7. > > So, I assume a SINGLE errata would be better, rather than creating separa= te erratas for each header field? That way we can look at the whole paragra= ph in one go, instead of working on individual sentencens. Yes, I think so. I found the separate emails for each issue a little hard to follow since th= ey were all affecting the same stuff. It is easier to follow the big pictur= e when they are all put together. Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Dec 4 07:52: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 4FE7F1A88B1 for ; Fri, 4 Dec 2015 07:52:50 -0800 (PST) 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 ryIbqZZeiwXT for ; Fri, 4 Dec 2015 07:52:49 -0800 (PST) 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 628AA1A88AD for ; Fri, 4 Dec 2015 07:52:49 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tB4FqkGd053410 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 4 Dec 2015 09:52:47 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Paul Kyzivat" Date: Fri, 04 Dec 2015 09:52:46 -0600 Message-ID: <940D58F4-B3C4-477C-AB89-05C2704FD974@nostrum.com> In-Reply-To: <56619F67.3050400@alum.mit.edu> References: <39B5E4D390E9BD4890E2B3107900610112AEC437@ESESSMB301.ericsson.se> <7699C626-BCC4-4B8F-AB14-0C81D7BE62D7@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112AEE460@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112AF324A@ESESSMB301.ericsson.se> <56619F67.3050400@alum.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] A new SIP header fields with "P-" name 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, 04 Dec 2015 15:52:50 -0000 (as individual) On 4 Dec 2015, at 8:12, Paul Kyzivat wrote: > On 12/4/15 4:13 AM, Ivo Sedlacek wrote: >> Just to give you the complete picture - the other alternative >> discussed in 3GPP was to extend P-Access-Network-Info header field >> with a new parameter with value containing the information on the >> last recently seen 3GPP radio network cell and another parameter >> indicating how old this information is. > > That seems fine if this new information is really access network info. > Generally I would recommend doing whichever is "cleanest". Obviously > the semantics are the same either way. Are there privacy considerations here? It seems like the information as described can (and maybe is intended to) imply geolocation. Ben. From nobody Fri Dec 4 10:04: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 87FA81A90EB for ; Fri, 4 Dec 2015 10:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 bBe3PeQvaOY1 for ; Fri, 4 Dec 2015 10:04:33 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3EA41A90A7 for ; Fri, 4 Dec 2015 10:04:33 -0800 (PST) Received: by ykdv3 with SMTP id v3so133085937ykd.0 for ; Fri, 04 Dec 2015 10:04:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mmWET+QU/8qIe22bS2Z6TrAY94EAfdp7ZulVgzarb0k=; b=zgQRvWOIN+153jQlN4zDhMFobKIxIk6IWED05w5E8/1LMyhQRRGnY3cXyKCLNBLv8S UeaEpYhv9iHg/EaEmSfJRZzAguXY1jLUcT5pi7yqh6PRZOr6WENbroue6Ydnc1kAGb+K GE8m++3z8V5U9gAgVu9kqrxoxxUHYe8LzbuZBnc7nXPtZTYZ/BZwanF/zZdELXJ2MDkY ei2wWfxaHtUcybdOHjmMEXwJtbwymNr0/szAmt7X8GzcUZDRMVHcKuPtUR0YCb8dXIrU HRvp5KrdpSrdfBHjrw2WJu9CR/LySsk+MzMOQDouroF/gIeakprjZmFcGzbUDVNO2Ibr yS9w== MIME-Version: 1.0 X-Received: by 10.129.87.69 with SMTP id l66mr13745268ywb.251.1449252272944; Fri, 04 Dec 2015 10:04:32 -0800 (PST) Received: by 10.37.90.65 with HTTP; Fri, 4 Dec 2015 10:04:32 -0800 (PST) In-Reply-To: <56619F67.3050400@alum.mit.edu> References: <39B5E4D390E9BD4890E2B3107900610112AEC437@ESESSMB301.ericsson.se> <7699C626-BCC4-4B8F-AB14-0C81D7BE62D7@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112AEE460@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112AF324A@ESESSMB301.ericsson.se> <56619F67.3050400@alum.mit.edu> Date: Fri, 4 Dec 2015 12:04:32 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a113b7d1ceb3a2b0526165613 Archived-At: Cc: SIPCORE Subject: Re: [sipcore] A new SIP header fields with "P-" name 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, 04 Dec 2015 18:04:35 -0000 --001a113b7d1ceb3a2b0526165613 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 4, 2015 at 8:12 AM, Paul Kyzivat wrote: > On 12/4/15 4:13 AM, Ivo Sedlacek wrote: > >> Just to give you the complete picture - the other alternative discussed >> in 3GPP was to extend P-Access-Network-Info header field with a new >> parameter with value containing the information on the last recently seen >> 3GPP radio network cell and another parameter indicating how old this >> information is. >> > > That seems fine if this new information is really access network info. > Generally I would recommend doing whichever is "cleanest". Obviously the > semantics are the same either way. > [MB] My personal opinion is that an extension is a better option. We do that all the time for other information that we need to transport rather than define new SIP headers. And, back to my previous process point, we ought first start with a clear problem description, which is probably pretty close in this case, barring Ben's point about privacy (which needs to be addressed independent of the solution chosen). [/MB] > > Thanks, > Paul > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001a113b7d1ceb3a2b0526165613 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Dec 4, 2015 at 8:12 AM, Paul Kyzivat <pkyzivat@alum.mit.edu>= ; wrote:
On 12/4/= 15 4:13 AM, Ivo Sedlacek wrote:
Just to give you the complete picture - the other alternative discussed in = 3GPP was to extend P-Access-Network-Info header field with a new parameter = with value containing the information on the last recently seen 3GPP radio = network cell and another parameter indicating how old this information is.<= br>

That seems fine if this new information is really access network info. Gene= rally I would recommend doing whichever is "cleanest". Obviously = the semantics are the same either way.
[MB] My persona= l opinion is that an extension is a better option.=C2=A0 We do that all the= time for other information that we need to transport rather than define ne= w SIP headers. =C2=A0 =C2=A0And, back to my previous process point, we ough= t first start with a clear problem description, which is probably pretty cl= ose in this case, barring Ben's point about privacy (which needs to be = addressed independent of the solution chosen). =C2=A0 [/MB]=C2=A0

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

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--001a113b7d1ceb3a2b0526165613-- From nobody Fri Dec 4 10:58: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 25ECB1B3259 for ; Fri, 4 Dec 2015 10:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 hjF5j55ESKqO for ; Fri, 4 Dec 2015 10:58:47 -0800 (PST) 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 D9D201B324C for ; Fri, 4 Dec 2015 10:58:46 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-69-5661e264ebd1 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 5E.3A.05041.462E1665; Fri, 4 Dec 2015 19:58:45 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0248.002; Fri, 4 Dec 2015 19:58:44 +0100 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Thread-Index: AdEttCY/6pwG9PPZQjGda7vzjTcvpgAWffcAAB2BxGAABDLmAAACYMQAAAnTz2A= Date: Fri, 4 Dec 2015 18:58:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C80EE3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37C7C70D@ESESSMB209.ericsson.se> <5660BC4A.2030908@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C7FC93@ESESSMB209.ericsson.se> <56619E7C.5090706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37C8094B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C8094B@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM2J7iG7qo8Qwgx3n2S1WbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuj/550Qat0xe7fz1kbGB+KdjFyckgImEic WjyVHcIWk7hwbz1bFyMXh5DAYUaJDecvsEI4ixklfu6YwdzFyMHBJmAh0f1PGyQuItDKKLFl w11GEEdYoINR4lvfHjaITCejxOtp3awgc0UE/CTWbZrMDGKzCKhI7P8xlxHE5hXwlej99ZIF YsUMJonNL36xgSQ4gRra33xhAbEZgY76fmoNE4jNLCAucevJfCaIYwUkluw5zwxhi0q8fPyP FcJWklh0+zNUvY7Egt2f2CBsbYllC18zQywWlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYx ihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBEbLwS2/rXYwHnzueIhRgINRiYe34GRCmBBrYllx Ze4hRgkOZiURXmaZxDAh3pTEyqrUovz4otKc1OJDjNIcLErivM1MD0KFBNITS1KzU1MLUotg skwcnFINjAvLupcf/6S0unL7vB93jvQcK1ht8kW069hORzOz8rSlfaeuTElTmCCSu3D2Kq+O CfqLS3dMlT2qveWPejLrBZcwyYnm/5ceEPRxFVQXebnG/zLL+dXL10a9fWcjbnNfK01IKumc w/r9K1bUaPpHqUkGng7eorVIS6+7J6PZZV3lZpFvAQtd7iixFGckGmoxFxUnAgCTcrZakgIA AA== Archived-At: Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info 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, 04 Dec 2015 18:58:49 -0000 Hi, I guess we could also consider changing "method" to "request". The "method"= terminology doesn't seem to be used anywhere else in the document... Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 04 December 2015 16:35 To: Paul Kyzivat ; sipcore@ietf.org Subject: Re: [sipcore] Misalignments between the P- header definitions in R= FC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Hi, So, based on my chapter 5.7 fix suggestions for each individual header fiel= d, below is a "compiled" fix suggestion for the whole chapter. Note that I've done some minor editorial changes, based e.g. on Jean's comm= ents. OLD TEXT: 5.7. New Headers The P-Associated-URI header field can appear in SIP REGISTER method and 2xx resonses. The P-Called-Party-ID header field can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods. The P-Visited-Network-ID header field can appear in all SIP methods except ACK, BYE, and CANCEL and all responses. The P-Access-Network-Info header field can appear in all SIP methods except ACK and CANCEL and all responses. The P-Charging-Vector header f= ield can appear in all SIP methods except CANCEL. The P-Charging-Function-Addresses header field can appear in all SIP methods except ACK and CANCEL. NEW TEXT: 5.7. New Headers The P-Associated-URI header field can appear in SIP REGISTER 2xx responses. The P-Called-Party-ID header field can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and in all responses associated with those methods. The P-Visited-Network-ID heade= r field can appear in all SIP methods except ACK, BYE, and CANCEL. The P-Access-Network-Info header field can appear in all SIP methods and responses, except in ACK and CANCEL methods and CANCEL responses. T= he P-Charging-Vector header field can appear in all SIP methods and responses, except in CANCEL methods and CANCEL re= sponses. The P-Charging-Function-Addresses header field can appear in all SIP methods and responses except ACK and = CANCEL. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 4. joulukuuta 2015 16:09 To: sipcore@ietf.org Subject: Re: [sipcore] Misalignments between the P- header definitions in R= FC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info On 12/4/15 6:20 AM, Christer Holmberg wrote: > Now, in my e-mails regarding the other P- header fields, all of them requ= ire a fix in section 5.7. > > So, I assume a SINGLE errata would be better, rather than creating separa= te erratas for each header field? That way we can look at the whole paragra= ph in one go, instead of working on individual sentencens. Yes, I think so. I found the separate emails for each issue a little hard to follow since th= ey were all affecting the same stuff. It is easier to follow the big pictur= e when they are all put together. Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Dec 4 12:15:44 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 3EDEB1A00ED for ; Fri, 4 Dec 2015 12:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssFr4i0cNoU3 for ; Fri, 4 Dec 2015 12:15:40 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 912BE1A00E8 for ; Fri, 4 Dec 2015 12:15:39 -0800 (PST) X-AuditID: c1b4fb25-f79876d0000011ee-c3-5661f4699682 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9E.C8.04590.964F1665; Fri, 4 Dec 2015 21:15:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Fri, 4 Dec 2015 21:15:37 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Thread-Index: AdEttCY/6pwG9PPZQjGda7vzjTcvpgAWffcAAB2BxGAABDLmAAACYMQAAAnTz2AAApSIcA== Date: Fri, 4 Dec 2015 20:15:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C811D4@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37C7C70D@ESESSMB209.ericsson.se> <5660BC4A.2030908@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C7FC93@ESESSMB209.ericsson.se> <56619E7C.5090706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37C8094B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C80EE3@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C80EE3@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7sW7ml8Qwg+/fDCxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj5doFTAVrFSoOzFzM2sDYJdXFyMkhIWAi MX3LFyYIW0ziwr31bCC2kMBhRonJx4u6GLmA7MWMEt9/XmLuYuTgYBOwkOj+pw1SIyIQKHF1 yQRmkBphgQ5GiW99e9hAHBGBTkaJ19O6WSGqwiSmH7/CCGKzCKhIdLf9ZQEZxCvgK/F/SjHE gjtMElfWT2EHqeEU8JOY+uAU2BWMQBd9P7UG7DpmAXGJW0/mQ10qILFkz3lmCFtU4uXjf6wQ tpLEotufoep1JBbs/sQGYWtLLFv4GqyeV0BQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcUo WpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGCkHt/xW3cF4+Y3jIUYBDkYlHt4NjxLDhFgTy4or cw8xSnAwK4nwMssAhXhTEiurUovy44tKc1KLDzFKc7AoifM2Mz0IFRJITyxJzU5NLUgtgsky cXBKNTByPXIqPCHlFbtghqe8fZiWQ0NHYwTHyfl7U2LiUoXErIQZX3UsTdWtd3/8dOK0x/l7 atevaXQXc7Ha6NT3WC8v4Wt5f///skJx5/f3PA6adE3gMLxn+i8y5/ya6eKLk/1i2wU1znzd JPja7dVr6QfyexbnbLgduOtwuWGbSMK185ei9iknblZiKc5INNRiLipOBAAOKG2lkAIAAA== Archived-At: Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info 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, 04 Dec 2015 20:15:42 -0000 Hi, Also, assuming we will update RFC 7315 in order to allow the PANI header fi= eld in ACK requests, section 5.7 would be modified. So, should we first finalize the errata, and then write an update draft bas= ed on the next text? I don't think the draft should be based on the old sec= tion 5.7 text. Regards, Christer -----Original Message----- From: Christer Holmberg=20 Sent: 04 December 2015 20:59 To: Christer Holmberg ; Paul Kyzivat ; sipcore@ietf.org Subject: RE: [sipcore] Misalignments between the P- header definitions in R= FC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Hi, I guess we could also consider changing "method" to "request". The "method"= terminology doesn't seem to be used anywhere else in the document... Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 04 December 2015 16:35 To: Paul Kyzivat ; sipcore@ietf.org Subject: Re: [sipcore] Misalignments between the P- header definitions in R= FC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Hi, So, based on my chapter 5.7 fix suggestions for each individual header fiel= d, below is a "compiled" fix suggestion for the whole chapter. Note that I've done some minor editorial changes, based e.g. on Jean's comm= ents. OLD TEXT: 5.7. New Headers The P-Associated-URI header field can appear in SIP REGISTER method and 2xx resonses. The P-Called-Party-ID header field can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods. The P-Visited-Network-ID header field can appear in all SIP methods except ACK, BYE, and CANCEL and all responses. The P-Access-Network-Info header field can appear in all SIP methods except ACK and CANCEL and all responses. The P-Charging-Vector header f= ield can appear in all SIP methods except CANCEL. The P-Charging-Function-Addresses header field can appear in all SIP methods except ACK and CANCEL. NEW TEXT: 5.7. New Headers The P-Associated-URI header field can appear in SIP REGISTER 2xx responses. The P-Called-Party-ID header field can appear in SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and in all responses associated with those methods. The P-Visited-Network-ID heade= r field can appear in all SIP methods except ACK, BYE, and CANCEL. The P-Access-Network-Info header field can appear in all SIP methods and responses, except in ACK and CANCEL methods and CANCEL responses. T= he P-Charging-Vector header field can appear in all SIP methods and responses, except in CANCEL methods and CANCEL re= sponses. The P-Charging-Function-Addresses header field can appear in all SIP methods and responses except ACK and = CANCEL. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 4. joulukuuta 2015 16:09 To: sipcore@ietf.org Subject: Re: [sipcore] Misalignments between the P- header definitions in R= FC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info On 12/4/15 6:20 AM, Christer Holmberg wrote: > Now, in my e-mails regarding the other P- header fields, all of them requ= ire a fix in section 5.7. > > So, I assume a SINGLE errata would be better, rather than creating separa= te erratas for each header field? That way we can look at the whole paragra= ph in one go, instead of working on individual sentencens. Yes, I think so. I found the separate emails for each issue a little hard to follow since th= ey were all affecting the same stuff. It is easier to follow the big pictur= e when they are all put together. Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Dec 4 14:12:44 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 C21691AC3C1 for ; Fri, 4 Dec 2015 14:12:43 -0800 (PST) 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 7tljNCX0Nffl for ; Fri, 4 Dec 2015 14:12:42 -0800 (PST) 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 EB40E1AC3BB for ; Fri, 4 Dec 2015 14:12:41 -0800 (PST) Received: from mutabilis-2.local (pool-173-57-210-37.dllstx.fios.verizon.net [173.57.210.37]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tB4MCZ7H010725 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 4 Dec 2015 16:12:36 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-210-37.dllstx.fios.verizon.net [173.57.210.37] claimed to be mutabilis-2.local To: Christer Holmberg , Paul Kyzivat , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B37C7C70D@ESESSMB209.ericsson.se> <5660BC4A.2030908@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C7FC93@ESESSMB209.ericsson.se> <56619E7C.5090706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37C8094B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C80EE3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C811D4@ESESSMB209.ericsson.se> From: "A. Jean Mahoney" Message-ID: <56620FCE.6070904@nostrum.com> Date: Fri, 4 Dec 2015 16:12:30 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C811D4@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info 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, 04 Dec 2015 22:12:43 -0000 Hi Christer, I think finalizing the errata, and then writing an update draft are the correct steps. Jean On 12/4/15 2:15 PM, Christer Holmberg wrote: > Hi, > > Also, assuming we will update RFC 7315 in order to allow the PANI header field in ACK requests, section 5.7 would be modified. > > So, should we first finalize the errata, and then write an update draft based on the next text? I don't think the draft should be based on the old section 5.7 text. > > Regards, > > Christer > > -----Original Message----- > From: Christer Holmberg > Sent: 04 December 2015 20:59 > To: Christer Holmberg ; Paul Kyzivat ; sipcore@ietf.org > Subject: RE: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info > > Hi, > > I guess we could also consider changing "method" to "request". The "method" terminology doesn't seem to be used anywhere else in the document... > > Regards, > > Christer > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 04 December 2015 16:35 > To: Paul Kyzivat ; sipcore@ietf.org > Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info > > Hi, > > So, based on my chapter 5.7 fix suggestions for each individual header field, below is a "compiled" fix suggestion for the whole chapter. > > Note that I've done some minor editorial changes, based e.g. on Jean's comments. > > > OLD TEXT: > > 5.7. New Headers > > The P-Associated-URI header field can appear in SIP REGISTER method > and 2xx resonses. The P-Called-Party-ID header field can appear in > SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods. > The P-Visited-Network-ID header field can appear in all > SIP methods except ACK, BYE, and CANCEL and all responses. The > P-Access-Network-Info header field can appear in all SIP methods > except ACK and CANCEL and all responses. The P-Charging-Vector header field can appear > in all SIP methods except CANCEL. The P-Charging-Function-Addresses > header field can appear in all SIP methods except ACK and CANCEL. > > > NEW TEXT: > > 5.7. New Headers > > The P-Associated-URI header field can appear in SIP REGISTER > 2xx responses. The P-Called-Party-ID header field can appear in > SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and in all > responses associated with those methods. The P-Visited-Network-ID header field can appear in all > SIP methods except ACK, BYE, and CANCEL. The > P-Access-Network-Info header field can appear in all SIP methods > and responses, except in ACK and CANCEL methods and CANCEL responses. The P-Charging-Vector header field can appear > in all SIP methods and responses, except in CANCEL methods and CANCEL responses. The P-Charging-Function-Addresses > header field can appear in all SIP methods and responses except ACK and CANCEL. > > > Regards, > > Christer > > > > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 4. joulukuuta 2015 16:09 > To: sipcore@ietf.org > Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info > > On 12/4/15 6:20 AM, Christer Holmberg wrote: > >> Now, in my e-mails regarding the other P- header fields, all of them require a fix in section 5.7. >> >> So, I assume a SINGLE errata would be better, rather than creating separate erratas for each header field? That way we can look at the whole paragraph in one go, instead of working on individual sentencens. > > Yes, I think so. > > I found the separate emails for each issue a little hard to follow since they were all affecting the same stuff. It is easier to follow the big picture when they are all put together. > > Thanks, > Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Fri Dec 4 14:45: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 0A4B31ACD30 for ; Fri, 4 Dec 2015 14:45:03 -0800 (PST) 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 VdrWJIxx-x-5 for ; Fri, 4 Dec 2015 14:45:01 -0800 (PST) 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 471D41ACD23 for ; Fri, 4 Dec 2015 14:45:01 -0800 (PST) Received: from mutabilis-2.local (pool-173-57-210-37.dllstx.fios.verizon.net [173.57.210.37]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tB4Mit4w013313 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 4 Dec 2015 16:44:55 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-210-37.dllstx.fios.verizon.net [173.57.210.37] claimed to be mutabilis-2.local To: Christer Holmberg , Paul Kyzivat , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B37C7C70D@ESESSMB209.ericsson.se> <5660BC4A.2030908@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C7FC93@ESESSMB209.ericsson.se> <56619E7C.5090706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37C8094B@ESESSMB209.ericsson.se> From: "A. Jean Mahoney" Message-ID: <56621761.4080001@nostrum.com> Date: Fri, 4 Dec 2015 16:44:49 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C8094B@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info 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, 04 Dec 2015 22:45:03 -0000 Hi Christer, When analyzing the text of RFC 7315 section 5.7, I made the assumptions that the information in Table 1 of RFC 3455 section 5.7 was correct and complete, and that RFC 7315 did not intentionally modify the information given in RFC 3455 section 5.7. Based on that, I've added feedback below - On 12/4/15 8:34 AM, Christer Holmberg wrote: > Hi, > > So, based on my chapter 5.7 fix suggestions for each individual header field, below is a "compiled" fix suggestion for the whole chapter. > > Note that I've done some minor editorial changes, based e.g. on Jean's comments. > > > OLD TEXT: > > 5.7. New Headers > > The P-Associated-URI header field can appear in SIP REGISTER method > and 2xx resonses. The P-Called-Party-ID header field can appear in > SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods. > The P-Visited-Network-ID header field can appear in all > SIP methods except ACK, BYE, and CANCEL and all responses. The > P-Access-Network-Info header field can appear in all SIP methods > except ACK and CANCEL and all responses. The P-Charging-Vector header field can appear > in all SIP methods except CANCEL. The P-Charging-Function-Addresses > header field can appear in all SIP methods except ACK and CANCEL. > > > NEW TEXT: > > 5.7. New Headers > > The P-Associated-URI header field can appear in SIP REGISTER > 2xx responses. I agree with the wording above. > The P-Called-Party-ID header field can appear in > SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and in all > responses associated with those methods. For P-Called-Party-ID, Table 1 in RFC 3455 didn't list PUBLISH but did list REFER, which is not included in the the text above. > The P-Visited-Network-ID header field can appear in all > SIP methods except ACK, BYE, and CANCEL. P-Visited-Network-ID is also not applicable to NOTIFY, PRACK, INFO, UPDATE according to Table 1 in RFC 3455. > The > P-Access-Network-Info header field can appear in all SIP methods > and responses, except in ACK and CANCEL methods and CANCEL responses. The P-Charging-Vector header field can appear > in all SIP methods and responses, except in CANCEL methods and CANCEL responses. Table 1 in RFC 3455 says that P-Charging-Vector is also not applicable to ACK. > The P-Charging-Function-Addresses > header field can appear in all SIP methods and responses except ACK and CANCEL. The sentence above should read like the PANI sentence. Thanks, Jean > > > Regards, > > Christer > > > > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 4. joulukuuta 2015 16:09 > To: sipcore@ietf.org > Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info > > On 12/4/15 6:20 AM, Christer Holmberg wrote: > >> Now, in my e-mails regarding the other P- header fields, all of them require a fix in section 5.7. >> >> So, I assume a SINGLE errata would be better, rather than creating separate erratas for each header field? That way we can look at the whole paragraph in one go, instead of working on individual sentencens. > > Yes, I think so. > > I found the separate emails for each issue a little hard to follow since they were all affecting the same stuff. It is easier to follow the big picture when they are all put together. > > Thanks, > Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Sat Dec 5 07:37:31 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 A82631B2AF8 for ; Sat, 5 Dec 2015 07:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 wie3pcPs8NvB for ; Sat, 5 Dec 2015 07:37:28 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12DB1B2B07 for ; Sat, 5 Dec 2015 07:37:27 -0800 (PST) X-AuditID: c1b4fb25-f79876d0000011ee-97-566304b5a162 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D2.17.04590.5B403665; Sat, 5 Dec 2015 16:37:25 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Sat, 5 Dec 2015 16:37:25 +0100 From: Christer Holmberg To: "A. Jean Mahoney" , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Thread-Index: AdEttCY/6pwG9PPZQjGda7vzjTcvpgAWffcAAB2BxGAABDLmAAACYMQAAA+i/4AAJKsOwA== Date: Sat, 5 Dec 2015 15:37:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C836CC@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37C7C70D@ESESSMB209.ericsson.se> <5660BC4A.2030908@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C7FC93@ESESSMB209.ericsson.se> <56619E7C.5090706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37C8094B@ESESSMB209.ericsson.se> <56621761.4080001@nostrum.com> In-Reply-To: <56621761.4080001@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbFdQncrS3KYwdXj8hYNnStZLVZsOMBq 8fXHJjYHZo+/7z8weSxZ8pPJY9bOJywBzFFcNimpOZllqUX6dglcGYe/rWIv+CdVseNIM2MD 4zeRLkZODgkBE4n10zazQthiEhfurWfrYuTiEBI4zCjRtW8mE4SzmFFi0eSd7F2MHBxsAhYS 3f+0QRpEBKokXr36wghSIyzQwSjxrW8PWLeIQCejxOtp3awQVWESczZfYgKxWQRUJE6c/s0I YvMK+Eqcn3GQHWLDTiaJbZO/s4AkOAW0JVr6QSZxcjAC3fT91BqwZmYBcYlbT+YzQdwqILFk z3lmCFtU4uXjf1A/KEms2H6JEaJeR2LB7k9sELa2xLKFr5khFgtKnJz5hGUCo+gsJGNnIWmZ haRlFpKWBYwsqxhFi1OLk3LTjYz1Uosyk4uL8/P08lJLNjECI+jglt+qOxgvv3E8xCjAwajE w7vhUWKYEGtiWXFl7iFGCQ5mJRFe9V1JYUK8KYmVValF+fFFpTmpxYcYpTlYlMR5m5kehAoJ pCeWpGanphakFsFkmTg4pRoYVZ6k3usQdUiu6o6u/qhbz71p066IjGP/al8u/fV72Zy7eiE3 5nFWSTxdz6W16EC5+lvZmxOZl/gvao37/PR+6xwp/SUq12Q0YhbPauxy65vAnnSoVivwXv2n Z//my73WuvZhk2+/d/Q0+82rX66u3VvxX7ysifO2VofFLhmdZ7MZMxkm117/rMRSnJFoqMVc VJwIAH80m1ucAgAA Archived-At: Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 15:37:29 -0000 Hi Jean, > When analyzing the text of RFC 7315 section 5.7, I made the assumptions t= hat the information in Table 1 of RFC 3455 section 5.7 was=20 > correct and complete, and that RFC 7315 did not intentionally modify the = information given in RFC 3455 section 5.7. Based on that, I've added feedba= ck below - > >> OLD TEXT: >> >> 5.7. New Headers >> >> The P-Associated-URI header field can appear in SIP REGISTER method >> and 2xx resonses. The P-Called-Party-ID header field can appear in >> SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods. >> The P-Visited-Network-ID header field can appear in all >> SIP methods except ACK, BYE, and CANCEL and all responses. The >> P-Access-Network-Info header field can appear in all SIP methods >> except ACK and CANCEL and all responses. The P-Charging-Vector head= er field can appear >> in all SIP methods except CANCEL. The P-Charging-Function-Addresses >> header field can appear in all SIP methods except ACK and CANCEL. >> >> >> NEW TEXT: >> >> 5.7. New Headers >> >> The P-Associated-URI header field can appear in SIP REGISTER >> 2xx responses. > > I agree with the wording above. Ok. --------------- >> The P-Called-Party-ID header field can appear in >> SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and in = all >> responses associated with those methods. > > For P-Called-Party-ID, Table 1 in RFC 3455 didn't list PUBLISH but did li= st REFER, which is not included in the the text above. That is true, I missed that part. Allowing it in REFER is also a requiremen= t from 3GPP, so I guess that would have to be part of the 7315 update draft= . --------------- >> The P-Visited-Network-ID header field can appear in all >> SIP methods except ACK, BYE, and CANCEL. > > P-Visited-Network-ID is also not applicable to NOTIFY, PRACK, INFO,=20 > UPDATE according to Table 1 in RFC 3455. True. I don't think that causes any issues in 3GPP, though, because afaik (needs = to be verified) 3GPP only defines usage of PVNI in: INVITE-, MESSAGE-, OPTI= ONS-, PUBLISH-, REFER-, REGISTER- and SUBSCRIBE- requests, which seems to b= e aligned with *both* the current text and new text that would exclude NOTI= FY, PRACK, INFO and UPDATE. --------------- >> The >> P-Access-Network-Info header field can appear in all SIP methods >> and responses, except in ACK and CANCEL methods and CANCEL responses= . The P-Charging-Vector header field can appear >> in all SIP methods and responses, except in CANCEL methods and CANCE= L responses. > > Table 1 in RFC 3455 says that P-Charging-Vector is also not applicable=20 > to ACK. True.=20 However, RFC 7315, and 24.229, currently allows it in ACK requests. Now, assuming that 7315 was not to do any changes to the 3455 Table 1, I gu= ess the errata would need to remove ACK from 7315, and then the 7315 update= draft would have to put it back :) --------------- >> The P-Charging-Function-Addresses >> header field can appear in all SIP methods and responses except ACK = and CANCEL. > > The sentence above should read like the PANI sentence. True. "The P-Charging-Function-Addresses header field can appear in all SIP meth= ods and responses, except in ACK and CANCEL methods and CANCEL responses." Regards, Christer From nobody Sat Dec 5 13:05: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 828AD1A86F5 for ; Sat, 5 Dec 2015 13:05:31 -0800 (PST) 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 evQqGBV_zmxt for ; Sat, 5 Dec 2015 13:05:29 -0800 (PST) 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 C163F1A86EE for ; Sat, 5 Dec 2015 13:05:29 -0800 (PST) Received: from mutabilis-2.local (pool-173-57-210-37.dllstx.fios.verizon.net [173.57.210.37]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tB5L5HEI056298 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 5 Dec 2015 15:05:24 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-210-37.dllstx.fios.verizon.net [173.57.210.37] claimed to be mutabilis-2.local To: Christer Holmberg , "sipcore-chairs@tools.ietf.org" , SIPCORE , Ben Campbell References: <20151204140645.77D7B180004@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37C8372C@ESESSMB209.ericsson.se> From: "A. Jean Mahoney" Message-ID: <56635188.40009@nostrum.com> Date: Sat, 5 Dec 2015 15:05:12 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C8372C@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] FW: [Technical Errata Reported] RFC3261 (4553) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2015 21:05:31 -0000 Hi Christer, +Ben and +sipcore since errata aren't sent automatically to the list. The AD pulls the levers on submitted errata. Thanks, Jean On 12/5/15 9:42 AM, Christer Holmberg wrote: > Hi chairs, > > I hope that we can move ahead with this errata asap. It may seem like a minor issue, but it is actually causing headaches in deployments, and within the test specification community. > > People supported the suggestion on the list, and nobody objected, so I assume it should not cause any problems. > > Regards, > > Christer > > > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: 04 December 2015 16:07 > To: jdrosen@dynamicsoft.com; schulzrinne@cs.columbia.edu; Gonzalo Camarillo ; alan.johnston@wcom.com; jon.peterson@neustar.com; rsparks@dynamicsoft.com; mjh@icir.org; schooler@research.att.com; ben@nostrum.com; alissa@cooperw.in; dean.willis@softarmor.com; drage@alcatel-lucent.com > Cc: Christer Holmberg ; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC3261 (4553) > > The following errata report has been submitted for RFC3261, > "SIP: Session Initiation Protocol". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3261&eid=4553 > > -------------------------------------- > Type: Technical > Reported by: Christer Holmberg > > Section: 20.11 > > Original Text > ------------- > The handling parameter, handling-param, describes how the UAS should react if it receives a message body whose content type or disposition type it does not understand. The parameter has defined values of \\"optional\\" and \\"required\\". If the handling parameter is missing, the value \\"required\\" SHOULD be assumed. The handling parameter is described in RFC 3204 [19]. > > > Corrected Text > -------------- > The handling parameter, handling-param, describes how the UAS should react if it receives a message body whose content type or disposition type it does not understand. The parameter has defined values of \\"optional\\" and \\"required\\". If the handling parameter is missing, or if the Content-Disposition header field is missing, the value \\"required\\" > MUST be assumed. The handling parameter is described in RFC 3204 [19]. > > > Notes > ----- > SIPCORE discussion: https://mailarchive.ietf.org/arch/msg/sipcore/bn-pRgDyGL2FP_M7eYpyT35zNp4 > > 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. > > -------------------------------------- > RFC3261 (draft-ietf-sip-rfc2543bis-09) > -------------------------------------- > Title : SIP: Session Initiation Protocol > Publication Date : June 2002 > Author(s) : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler > Category : PROPOSED STANDARD > Source : Session Initiation Protocol > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > From nobody Sun Dec 6 00:46: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 D4F4E1AC3FC for ; Sun, 6 Dec 2015 00:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_NabCjlv60P for ; Sun, 6 Dec 2015 00:46:08 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2EA01AC3F3 for ; Sun, 6 Dec 2015 00:46:07 -0800 (PST) X-AuditID: c1b4fb25-f79876d0000011ee-1f-5663f5cd783b Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A2.20.04590.DC5F3665; Sun, 6 Dec 2015 09:46:05 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0248.002; Sun, 6 Dec 2015 09:46:05 +0100 From: Christer Holmberg To: "A. Jean Mahoney" , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Thread-Index: AdEttCY/6pwG9PPZQjGda7vzjTcvpgAWffcAAB2BxGAABDLmAAACYMQAAAnTz2AAApSIcAACGbkAAEp35hA= Date: Sun, 6 Dec 2015 08:46:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C842FD@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37C7C70D@ESESSMB209.ericsson.se> <5660BC4A.2030908@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C7FC93@ESESSMB209.ericsson.se> <56619E7C.5090706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37C8094B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C80EE3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C811D4@ESESSMB209.ericsson.se> <56620FCE.6070904@nostrum.com> In-Reply-To: <56620FCE.6070904@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbFdS/fs1+Qwg+9n9SwaOleyWqzYcIDV 4uuPTWwOzB5/339g8liy5CeTx6ydT1gCmKO4bFJSczLLUov07RK4MjZtWsFWsF+tYkn/I8YG xlNyXYycHBICJhIb7q1ggbDFJC7cW8/WxcjFISRwmFHi0ZRHUM5iRokLr9qYuhg5ONgELCS6 /2mDNIgIVEm8evWFEaRGWKCDUeJb3x6wBhGBTkaJ19O6WSGqkiQ+LL7ABmKzCKhIfF77gRHE 5hXwldg3eycjxIaDzBJ3914Fa+AU0JbYsvUFWBEj0E3fT61hArGZBcQlbj2ZzwRxq4DEkj3n mSFsUYmXj/+xQthKEo1LnrBC1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUnYVk7CwkLbOQ tMxC0rKAkWUVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmAEHdzyW3UH4+U3jocYBTgYlXh4 C3KSw4RYE8uKK3MPMUpwMCuJ8Bq9AQrxpiRWVqUW5ccXleakFh9ilOZgURLnbWZ6ECokkJ5Y kpqdmlqQWgSTZeLglGpgLPzyNKrK1d39tlygu6/42jMbP1ao9G4XP9j78nkC57H8BRNSZvB2 HbXf76a31Gr7gWTXl3rfflR/8A7a8KpePc+RqecO3yOljUuOTC91//qAQdZj22P1hGzmtfcF 5neq55ppGx0RZtklfoorUK4qUbayoOIx6222W2dZ7nnGb1vm5WfNqWyvxFKckWioxVxUnAgA A9AqxpwCAAA= Archived-At: Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info 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, 06 Dec 2015 08:46:13 -0000 Hi, >I think finalizing the errata, and then writing an update draft are the co= rrect steps. I agree. However, if doing so, we must still more or less agree on the content of th= e update draft. Because, if we agree the errata, and then don't agree on the content of the= draft, we will cause an even greater misalignment with 3GPP. Regards, Christer On 12/4/15 2:15 PM, Christer Holmberg wrote: > Hi, > > Also, assuming we will update RFC 7315 in order to allow the PANI header = field in ACK requests, section 5.7 would be modified. > > So, should we first finalize the errata, and then write an update draft b= ased on the next text? I don't think the draft should be based on the old s= ection 5.7 text. > > Regards, > > Christer > > -----Original Message----- > From: Christer Holmberg > Sent: 04 December 2015 20:59 > To: Christer Holmberg ; Paul Kyzivat=20 > ; sipcore@ietf.org > Subject: RE: [sipcore] Misalignments between the P- header definitions=20 > in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info > > Hi, > > I guess we could also consider changing "method" to "request". The "metho= d" terminology doesn't seem to be used anywhere else in the document... > > Regards, > > Christer > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer=20 > Holmberg > Sent: 04 December 2015 16:35 > To: Paul Kyzivat ; sipcore@ietf.org > Subject: Re: [sipcore] Misalignments between the P- header definitions=20 > in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info > > Hi, > > So, based on my chapter 5.7 fix suggestions for each individual header fi= eld, below is a "compiled" fix suggestion for the whole chapter. > > Note that I've done some minor editorial changes, based e.g. on Jean's co= mments. > > > OLD TEXT: > > 5.7. New Headers > > The P-Associated-URI header field can appear in SIP REGISTER method > and 2xx resonses. The P-Called-Party-ID header field can appear in > SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods. > The P-Visited-Network-ID header field can appear in all > SIP methods except ACK, BYE, and CANCEL and all responses. The > P-Access-Network-Info header field can appear in all SIP methods > except ACK and CANCEL and all responses. The P-Charging-Vector heade= r field can appear > in all SIP methods except CANCEL. The P-Charging-Function-Addresses > header field can appear in all SIP methods except ACK and CANCEL. > > > NEW TEXT: > > 5.7. New Headers > > The P-Associated-URI header field can appear in SIP REGISTER > 2xx responses. The P-Called-Party-ID header field can appear in > SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and in a= ll > responses associated with those methods. The P-Visited-Network-ID he= ader field can appear in all > SIP methods except ACK, BYE, and CANCEL. The > P-Access-Network-Info header field can appear in all SIP methods > and responses, except in ACK and CANCEL methods and CANCEL responses.= The P-Charging-Vector header field can appear > in all SIP methods and responses, except in CANCEL methods and CANCEL= responses. The P-Charging-Function-Addresses > header field can appear in all SIP methods and responses except ACK a= nd CANCEL. > > > Regards, > > Christer > > > > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul=20 > Kyzivat > Sent: 4. joulukuuta 2015 16:09 > To: sipcore@ietf.org > Subject: Re: [sipcore] Misalignments between the P- header definitions=20 > in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info > > On 12/4/15 6:20 AM, Christer Holmberg wrote: > >> Now, in my e-mails regarding the other P- header fields, all of them req= uire a fix in section 5.7. >> >> So, I assume a SINGLE errata would be better, rather than creating separ= ate erratas for each header field? That way we can look at the whole paragr= aph in one go, instead of working on individual sentencens. > > Yes, I think so. > > I found the separate emails for each issue a little hard to follow since = they were all affecting the same stuff. It is easier to follow the big pict= ure when they are all put together. > > Thanks, > Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Sun Dec 6 08:17: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 396051AD0BA for ; Sun, 6 Dec 2015 08:17:44 -0800 (PST) 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 WknH4wuhqL8f for ; Sun, 6 Dec 2015 08:17:42 -0800 (PST) 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 7E6D21AD0AE for ; Sun, 6 Dec 2015 08:17:42 -0800 (PST) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-09v.sys.comcast.net with comcast id qGGv1r0042LrikM01GHhMr; Sun, 06 Dec 2015 16:17:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-12v.sys.comcast.net with comcast id qGHh1r0053KdFy101GHh5Z; Sun, 06 Dec 2015 16:17:41 +0000 To: Christer Holmberg , "A. Jean Mahoney" , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B37C7C70D@ESESSMB209.ericsson.se> <5660BC4A.2030908@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C7FC93@ESESSMB209.ericsson.se> <56619E7C.5090706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37C8094B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C80EE3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C811D4@ESESSMB209.ericsson.se> <56620FCE.6070904@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C842FD@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <56645FA4.6090702@alum.mit.edu> Date: Sun, 6 Dec 2015 11:17:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C842FD@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=1449418661; bh=NmgF6GgGNtpa04qvEd8FUDvkA2Vs/zlFzUESFAReGeU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=mQ8ziFb+/8JlBJX7altAp3rWLO0ls4EGZhQuGgNR2YDlOOkQh7qQXTAuSHzjDe/pJ cxg42YywQLKaohn//N9jUiM/sWI8fOaJj9Hxo4Rvv1Cj15lgZZ0HwVNOku4a941Neq 5iohWLPiE5Gu7IQDWvy7dEG4We6ZfZungLNdepis2JCE6X9XvEztWHGiDXKqripEGL b8o7xGFqRkLrFi3UiTAHsVSYZEg1/Wj2jc6bXNWsX+TSbjKKbKMeG+MKCv6AqjWPUF qgXYDfgpyh0MGlAeaUzR2+2yH6Y9UHBO6fejnPlQ7GDLQB7Cy7qGOXNftHgcJPrbYE FS4SdpSHFSgpQ== Archived-At: Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info 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, 06 Dec 2015 16:17:44 -0000 On 12/6/15 3:46 AM, Christer Holmberg wrote: > Hi, > >> I think finalizing the errata, and then writing an update draft are the correct steps. > > I agree. > > However, if doing so, we must still more or less agree on the content of the update draft. > > Because, if we agree the errata, and then don't agree on the content of the draft, we will cause an even greater misalignment with 3GPP. While there are (procedural) reasons to split the work this way, doing so obfuscates what is being done. At the least I think it would be good settle on the overall set of changes required, and *then* partition them into errata and a draft. And IMO it would be a good thing to restate the errata in the draft. (In a non-normative way.) Thanks, Paul > On 12/4/15 2:15 PM, Christer Holmberg wrote: >> Hi, >> >> Also, assuming we will update RFC 7315 in order to allow the PANI header field in ACK requests, section 5.7 would be modified. >> >> So, should we first finalize the errata, and then write an update draft based on the next text? I don't think the draft should be based on the old section 5.7 text. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: Christer Holmberg >> Sent: 04 December 2015 20:59 >> To: Christer Holmberg ; Paul Kyzivat >> ; sipcore@ietf.org >> Subject: RE: [sipcore] Misalignments between the P- header definitions >> in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info >> >> Hi, >> >> I guess we could also consider changing "method" to "request". The "method" terminology doesn't seem to be used anywhere else in the document... >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer >> Holmberg >> Sent: 04 December 2015 16:35 >> To: Paul Kyzivat ; sipcore@ietf.org >> Subject: Re: [sipcore] Misalignments between the P- header definitions >> in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info >> >> Hi, >> >> So, based on my chapter 5.7 fix suggestions for each individual header field, below is a "compiled" fix suggestion for the whole chapter. >> >> Note that I've done some minor editorial changes, based e.g. on Jean's comments. >> >> >> OLD TEXT: >> >> 5.7. New Headers >> >> The P-Associated-URI header field can appear in SIP REGISTER method >> and 2xx resonses. The P-Called-Party-ID header field can appear in >> SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods. >> The P-Visited-Network-ID header field can appear in all >> SIP methods except ACK, BYE, and CANCEL and all responses. The >> P-Access-Network-Info header field can appear in all SIP methods >> except ACK and CANCEL and all responses. The P-Charging-Vector header field can appear >> in all SIP methods except CANCEL. The P-Charging-Function-Addresses >> header field can appear in all SIP methods except ACK and CANCEL. >> >> >> NEW TEXT: >> >> 5.7. New Headers >> >> The P-Associated-URI header field can appear in SIP REGISTER >> 2xx responses. The P-Called-Party-ID header field can appear in >> SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and in all >> responses associated with those methods. The P-Visited-Network-ID header field can appear in all >> SIP methods except ACK, BYE, and CANCEL. The >> P-Access-Network-Info header field can appear in all SIP methods >> and responses, except in ACK and CANCEL methods and CANCEL responses. The P-Charging-Vector header field can appear >> in all SIP methods and responses, except in CANCEL methods and CANCEL responses. The P-Charging-Function-Addresses >> header field can appear in all SIP methods and responses except ACK and CANCEL. >> >> >> Regards, >> >> Christer >> >> >> >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul >> Kyzivat >> Sent: 4. joulukuuta 2015 16:09 >> To: sipcore@ietf.org >> Subject: Re: [sipcore] Misalignments between the P- header definitions >> in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info >> >> On 12/4/15 6:20 AM, Christer Holmberg wrote: >> >>> Now, in my e-mails regarding the other P- header fields, all of them require a fix in section 5.7. >>> >>> So, I assume a SINGLE errata would be better, rather than creating separate erratas for each header field? That way we can look at the whole paragraph in one go, instead of working on individual sentencens. >> >> Yes, I think so. >> >> I found the separate emails for each issue a little hard to follow since they were all affecting the same stuff. It is easier to follow the big picture when they are all put together. >> >> Thanks, >> Paul >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > From nobody Sun Dec 6 10:30:39 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965981B2A07 for ; Sun, 6 Dec 2015 10:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQi30tSq0Pkz for ; Sun, 6 Dec 2015 10:30:35 -0800 (PST) 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 3978B1B2A01 for ; Sun, 6 Dec 2015 10:30:34 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-59-56647ec8e958 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id AC.DA.05041.8CE74665; Sun, 6 Dec 2015 19:30:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0248.002; Sun, 6 Dec 2015 19:30:32 +0100 From: Christer Holmberg To: Paul Kyzivat , "A. Jean Mahoney" , "sipcore@ietf.org" Thread-Topic: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Thread-Index: AdEttCY/6pwG9PPZQjGda7vzjTcvpgAWffcAAB2BxGAABDLmAAACYMQAAAnTz2AAApSIcAACGbkAAEp35hAADbjaAAAGrTag Date: Sun, 6 Dec 2015 18:30:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C8531A@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37C7C70D@ESESSMB209.ericsson.se> <5660BC4A.2030908@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C7FC93@ESESSMB209.ericsson.se> <56619E7C.5090706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37C8094B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C80EE3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C811D4@ESESSMB209.ericsson.se> <56620FCE.6070904@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C842FD@ESESSMB209.ericsson.se> <56645FA4.6090702@alum.mit.edu> In-Reply-To: <56645FA4.6090702@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+NgFupkkeLIzCtJLcpLzFFi42KZGbFdXfdEXUqYQecMfYuGzpWsFis2HGC1 +PpjE5sDs8ff9x+YPJYs+cnkMWvnE5YA5igum5TUnMyy1CJ9uwSujHPXZrMWbNGpmL5zPlMD 4zLlLkZODgkBE4nTr3ayQthiEhfurWfrYuTiEBI4zCjR+fQplLOYUeLQuhVAVRwcbAIWEt3/ tEEaRASqJO4tOckIUiMs0MEo8a1vD1iDiEAno8Trad2sEFV5Enf/fAazWQRUJNb1dLCB2LwC vhInr09nh9iwnEVi4eN/jCAJTgEdiWVnJoAVMQLd9P3UGiYQm1lAXOLWk/lMELcKSCzZc54Z whaVePn4H9QPShKLbn+GqteRWLD7ExuErS2xbOFrZojFghInZz5hmcAoOgvJ2FlIWmYhaZmF pGUBI8sqRtHi1OLi3HQjI73Uoszk4uL8PL281JJNjMAIOrjlt9UOxoPPHQ8xCnAwKvHwFuQk hwmxJpYVV+YeYpTgYFYS4RWOSwkT4k1JrKxKLcqPLyrNSS0+xCjNwaIkztvM9CBUSCA9sSQ1 OzW1ILUIJsvEwSnVwKj07onIrPx6vT/K+pWSYQ+urOdK5E+LKBaQ/nb1rCdLc1JIQrPnGcGa 5qVsofqsbIt2msUe3bPxeOT2bUxyfpILHpsUxEvY9jcvX3341XL1e9NsOfJ55Cc++mI3Z9vN qEUS9eqq1cYu2wpf6vzPl9V9d/zoxv/3V1683aX4qY8lXHem0EqNciWW4oxEQy3mouJEAOeQ ncqcAgAA Archived-At: Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info 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, 06 Dec 2015 18:30:37 -0000 Hi, >>> I think finalizing the errata, and then writing an update draft are the= correct steps. >> >> I agree. >> >> However, if doing so, we must still more or less agree on the content of= the update draft. >> >> Because, if we agree the errata, and then don't agree on the content of = the draft, we will cause an even greater misalignment with 3GPP. > > While there are (procedural) reasons to split the work this way, doing so= obfuscates what is being done. > > At the least I think it would be good settle on the overall set of change= s required, and *then* partition them into errata=20 > and a draft. And IMO it would be a good thing to restate the errata in th= e draft. (In a non-normative way.) Ok. I started putting a draft together, so I'll put everything there. As 7315 updates will have to go to DISPATCH, it will be a draft-holmberg-di= spatch draft, but I guess that doesn't matter. Same people... Regards, Christer > On 12/4/15 2:15 PM, Christer Holmberg wrote: >> Hi, >> >> Also, assuming we will update RFC 7315 in order to allow the PANI header= field in ACK requests, section 5.7 would be modified. >> >> So, should we first finalize the errata, and then write an update draft = based on the next text? I don't think the draft should be based on the old = section 5.7 text. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: Christer Holmberg >> Sent: 04 December 2015 20:59 >> To: Christer Holmberg ; Paul Kyzivat=20 >> ; sipcore@ietf.org >> Subject: RE: [sipcore] Misalignments between the P- header=20 >> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229:=20 >> P-Access-Network-Info >> >> Hi, >> >> I guess we could also consider changing "method" to "request". The "meth= od" terminology doesn't seem to be used anywhere else in the document... >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer=20 >> Holmberg >> Sent: 04 December 2015 16:35 >> To: Paul Kyzivat ; sipcore@ietf.org >> Subject: Re: [sipcore] Misalignments between the P- header=20 >> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229:=20 >> P-Access-Network-Info >> >> Hi, >> >> So, based on my chapter 5.7 fix suggestions for each individual header f= ield, below is a "compiled" fix suggestion for the whole chapter. >> >> Note that I've done some minor editorial changes, based e.g. on Jean's c= omments. >> >> >> OLD TEXT: >> >> 5.7. New Headers >> >> The P-Associated-URI header field can appear in SIP REGISTER method >> and 2xx resonses. The P-Called-Party-ID header field can appear in >> SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods. >> The P-Visited-Network-ID header field can appear in all >> SIP methods except ACK, BYE, and CANCEL and all responses. The >> P-Access-Network-Info header field can appear in all SIP methods >> except ACK and CANCEL and all responses. The P-Charging-Vector hea= der field can appear >> in all SIP methods except CANCEL. The P-Charging-Function-Addresse= s >> header field can appear in all SIP methods except ACK and CANCEL. >> >> >> NEW TEXT: >> >> 5.7. New Headers >> >> The P-Associated-URI header field can appear in SIP REGISTER >> 2xx responses. The P-Called-Party-ID header field can appear in >> SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and in= all >> responses associated with those methods. The P-Visited-Network-ID = header field can appear in all >> SIP methods except ACK, BYE, and CANCEL. The >> P-Access-Network-Info header field can appear in all SIP methods >> and responses, except in ACK and CANCEL methods and CANCEL response= s. The P-Charging-Vector header field can appear >> in all SIP methods and responses, except in CANCEL methods and CANC= EL responses. The P-Charging-Function-Addresses >> header field can appear in all SIP methods and responses except ACK= and CANCEL. >> >> >> Regards, >> >> Christer >> >> >> >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul=20 >> Kyzivat >> Sent: 4. joulukuuta 2015 16:09 >> To: sipcore@ietf.org >> Subject: Re: [sipcore] Misalignments between the P- header=20 >> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229:=20 >> P-Access-Network-Info >> >> On 12/4/15 6:20 AM, Christer Holmberg wrote: >> >>> Now, in my e-mails regarding the other P- header fields, all of them re= quire a fix in section 5.7. >>> >>> So, I assume a SINGLE errata would be better, rather than creating sepa= rate erratas for each header field? That way we can look at the whole parag= raph in one go, instead of working on individual sentencens. >> >> Yes, I think so. >> >> I found the separate emails for each issue a little hard to follow since= they were all affecting the same stuff. It is easier to follow the big pic= ture when they are all put together. >> >> Thanks, >> Paul >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > From nobody Sun Dec 6 11:43:42 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD67D1A88F0 for ; Sun, 6 Dec 2015 11:43:41 -0800 (PST) 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 xlKtDSW8NqR8 for ; Sun, 6 Dec 2015 11:43:39 -0800 (PST) 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 D3AE11A88EF for ; Sun, 6 Dec 2015 11:43:38 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 02B17DA01C448; Sun, 6 Dec 2015 19:43:33 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id tB6JhZVM006453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 6 Dec 2015 20:43:35 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.213]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Sun, 6 Dec 2015 20:43:35 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Paul Kyzivat , "A. Jean Mahoney" , "sipcore@ietf.org" Thread-Topic: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Thread-Index: AdEttCY/6pwG9PPZQjGda7vzjTcvpgAWffcAAB2BxGAABDLmAAACYMQAAAnTz2AAApSIcAACGbkAAEp35hAADbjaAAAGrTagAAELE8A= Date: Sun, 6 Dec 2015 19:43:35 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADE1EFEF@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B37C7C70D@ESESSMB209.ericsson.se> <5660BC4A.2030908@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C7FC93@ESESSMB209.ericsson.se> <56619E7C.5090706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37C8094B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C80EE3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C811D4@ESESSMB209.ericsson.se> <56620FCE.6070904@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C842FD@ESESSMB209.ericsson.se> <56645FA4.6090702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37C8531A@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C8531A@ESESSMB209.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.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info 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, 06 Dec 2015 19:43:41 -0000 A few comments. First of all, in response to an earlier comment by Jean, at some period in = time we decided that the tables were not a good representation of the way t= o go, and that a series of normative statements would be better. However part of the problem with the tables is that they also fell rapidly = out of date as we added new methods, and therefore the new text suffers fro= m the same problem in places. It would be better to refer to types of metho= ds, and then give examples, e.g. "dialog creating requests", "requests that= can appear within a dialog" and so on. Obviously CANCEL requests and responses are an exception of any appearance,= part of the reason being that these headers are used for information trans= fer and there is no guarantee with CANCEL as to what any information genera= ted will be received from or sent to, as CANCEL is essentially directly at = intermediate points in the interests at dialog cleanup, rather than a real = endpoint, and responses to CANCEL are in any case sent on each hop as it is= reached. I am happy that CANCEL is still excluded from all of these header= fields. In regard to the ACK request, I'd note that for those header fields where i= t is now added, it is only added where it is set as a result of 200 (OK) re= sponses (to INVITE). ACK requests to 3xx - 6xx responses have the same prob= lems as CANCEL. I think it would be worth capturing this distinction in the= text. Regards Keith -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 06 December 2015 18:31 To: Paul Kyzivat; A. Jean Mahoney; sipcore@ietf.org Subject: Re: [sipcore] Misalignments between the P- header definitions in R= FC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Hi, >>> I think finalizing the errata, and then writing an update draft are the= correct steps. >> >> I agree. >> >> However, if doing so, we must still more or less agree on the content of= the update draft. >> >> Because, if we agree the errata, and then don't agree on the content of = the draft, we will cause an even greater misalignment with 3GPP. > > While there are (procedural) reasons to split the work this way, doing so= obfuscates what is being done. > > At the least I think it would be good settle on the overall set of=20 > changes required, and *then* partition them into errata and a draft.=20 > And IMO it would be a good thing to restate the errata in the draft.=20 > (In a non-normative way.) Ok. I started putting a draft together, so I'll put everything there. As 7315 updates will have to go to DISPATCH, it will be a draft-holmberg-di= spatch draft, but I guess that doesn't matter. Same people... Regards, Christer > On 12/4/15 2:15 PM, Christer Holmberg wrote: >> Hi, >> >> Also, assuming we will update RFC 7315 in order to allow the PANI header= field in ACK requests, section 5.7 would be modified. >> >> So, should we first finalize the errata, and then write an update draft = based on the next text? I don't think the draft should be based on the old = section 5.7 text. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: Christer Holmberg >> Sent: 04 December 2015 20:59 >> To: Christer Holmberg ; Paul Kyzivat=20 >> ; sipcore@ietf.org >> Subject: RE: [sipcore] Misalignments between the P- header=20 >> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: >> P-Access-Network-Info >> >> Hi, >> >> I guess we could also consider changing "method" to "request". The "meth= od" terminology doesn't seem to be used anywhere else in the document... >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer=20 >> Holmberg >> Sent: 04 December 2015 16:35 >> To: Paul Kyzivat ; sipcore@ietf.org >> Subject: Re: [sipcore] Misalignments between the P- header=20 >> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: >> P-Access-Network-Info >> >> Hi, >> >> So, based on my chapter 5.7 fix suggestions for each individual header f= ield, below is a "compiled" fix suggestion for the whole chapter. >> >> Note that I've done some minor editorial changes, based e.g. on Jean's c= omments. >> >> >> OLD TEXT: >> >> 5.7. New Headers >> >> The P-Associated-URI header field can appear in SIP REGISTER method >> and 2xx resonses. The P-Called-Party-ID header field can appear in >> SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods. >> The P-Visited-Network-ID header field can appear in all >> SIP methods except ACK, BYE, and CANCEL and all responses. The >> P-Access-Network-Info header field can appear in all SIP methods >> except ACK and CANCEL and all responses. The P-Charging-Vector hea= der field can appear >> in all SIP methods except CANCEL. The P-Charging-Function-Addresse= s >> header field can appear in all SIP methods except ACK and CANCEL. >> >> >> NEW TEXT: >> >> 5.7. New Headers >> >> The P-Associated-URI header field can appear in SIP REGISTER >> 2xx responses. The P-Called-Party-ID header field can appear in >> SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and in= all >> responses associated with those methods. The P-Visited-Network-ID = header field can appear in all >> SIP methods except ACK, BYE, and CANCEL. The >> P-Access-Network-Info header field can appear in all SIP methods >> and responses, except in ACK and CANCEL methods and CANCEL response= s. The P-Charging-Vector header field can appear >> in all SIP methods and responses, except in CANCEL methods and CANC= EL responses. The P-Charging-Function-Addresses >> header field can appear in all SIP methods and responses except ACK= and CANCEL. >> >> >> Regards, >> >> Christer >> >> >> >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul=20 >> Kyzivat >> Sent: 4. joulukuuta 2015 16:09 >> To: sipcore@ietf.org >> Subject: Re: [sipcore] Misalignments between the P- header=20 >> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: >> P-Access-Network-Info >> >> On 12/4/15 6:20 AM, Christer Holmberg wrote: >> >>> Now, in my e-mails regarding the other P- header fields, all of them re= quire a fix in section 5.7. >>> >>> So, I assume a SINGLE errata would be better, rather than creating sepa= rate erratas for each header field? That way we can look at the whole parag= raph in one go, instead of working on individual sentencens. >> >> Yes, I think so. >> >> I found the separate emails for each issue a little hard to follow since= they were all affecting the same stuff. It is easier to follow the big pic= ture when they are all put together. >> >> Thanks, >> Paul >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Sun Dec 6 21:47:05 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8966C1B2EEB for ; Sun, 6 Dec 2015 21:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsRVqVaHyssc for ; Sun, 6 Dec 2015 21:47:02 -0800 (PST) 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 E9C031B2EEA for ; Sun, 6 Dec 2015 21:47:01 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-12-56651d4eb5da Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 24.77.05149.E4D15665; Mon, 7 Dec 2015 06:46:54 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Mon, 7 Dec 2015 06:46:54 +0100 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , Paul Kyzivat , "A. Jean Mahoney" , "sipcore@ietf.org" Thread-Topic: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Thread-Index: AdEttCY/6pwG9PPZQjGda7vzjTcvpgAWffcAAB2BxGAABDLmAAACYMQAAAnTz2AAApSIcAACGbkAAEp35hAADbjaAAAGrTagAAELE8AAFpd8sA== Date: Mon, 7 Dec 2015 05:46:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C872F3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37C7C70D@ESESSMB209.ericsson.se> <5660BC4A.2030908@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C7FC93@ESESSMB209.ericsson.se> <56619E7C.5090706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37C8094B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C80EE3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C811D4@ESESSMB209.ericsson.se> <56620FCE.6070904@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C842FD@ESESSMB209.ericsson.se> <56645FA4.6090702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37C8531A@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADE1EFEF@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADE1EFEF@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEIsWRmVeSWpSXmKPExsUyM2K7vW6wbGqYQd8qdYunjWcZLRo6V7Ja rNhwgNXi649NbA4sHq3P9rJ6/H3/gcljyZKfTB6zdj5hCWCJ4rJJSc3JLEst0rdL4Mo4fnwi S0GjScXObz/YGhgPaXYxcnBICJhIXL0o2sXICWSKSVy4t56ti5GLQ0jgMKPEu7P9LBDOYkaJ 5a8uMoM0sAlYSHT/0waJiwhsZZS4eK0drEhYoINR4lvfHjaITCejxOtp3awgc0UE6iTOH2hn B+lmEVCR+LhGHSTMK+Ar8WPNflaIDftYJXZtvsAEkuAUiJXovzgFrJcR6Kbvp9aAxZkFxCVu PZnPBHGrgMSSPeeZIWxRiZeP/7FC2EoSjUuesELU60gs2P2JDcLWlli28DUzxGJBiZMzn7BM YBSdhWTsLCQts5C0zELSsoCRZRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYEwd3PLbYAfj y+eOhxgFOBiVeHg3tKaECbEmlhVX5h5ilOBgVhLhFY4DCvGmJFZWpRblxxeV5qQWH2KU5mBR EudtZnoQKiSQnliSmp2aWpBaBJNl4uCUamAs2niu2ODi17CtSbW73OU+HTwRqCm0s/Jkcsq0 1kim60HLTR98ivLeJ71yefKULaYygWJf2FJf/+h2CpOR5Zl0UqxxXlC1S7rr5PMpspcm8r5R 5folK3h20/4Hu16xrY6vYlTRZHm8YPdV48bjklcfvGvPNk3nTF9i+2u+muJvnZpYUxs9+0gl luKMREMt5qLiRADP/897pQIAAA== Archived-At: Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info 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, 07 Dec 2015 05:47:04 -0000 Hi, ... >In regard to the ACK request, I'd note that for those header fields where = it is now added, it is only added where it is >set as a result of 200 (OK) responses (to INVITE). ACK requests to 3xx - 6= xx responses have the same problems as CANCEL. I think it would be worth ca= pturing this distinction in the text. I don't think such details should be in chapter 5.7. It should be clarified= in the chapters describing the usage of individual header fields. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 06 December 2015 18:31 To: Paul Kyzivat; A. Jean Mahoney; sipcore@ietf.org Subject: Re: [sipcore] Misalignments between the P- header definitions in R= FC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Hi, >>> I think finalizing the errata, and then writing an update draft are the= correct steps. >> >> I agree. >> >> However, if doing so, we must still more or less agree on the content of= the update draft. >> >> Because, if we agree the errata, and then don't agree on the content of = the draft, we will cause an even greater misalignment with 3GPP. > > While there are (procedural) reasons to split the work this way, doing so= obfuscates what is being done. > > At the least I think it would be good settle on the overall set of=20 > changes required, and *then* partition them into errata and a draft. > And IMO it would be a good thing to restate the errata in the draft.=20 > (In a non-normative way.) Ok. I started putting a draft together, so I'll put everything there. As 7315 updates will have to go to DISPATCH, it will be a draft-holmberg-di= spatch draft, but I guess that doesn't matter. Same people... Regards, Christer > On 12/4/15 2:15 PM, Christer Holmberg wrote: >> Hi, >> >> Also, assuming we will update RFC 7315 in order to allow the PANI header= field in ACK requests, section 5.7 would be modified. >> >> So, should we first finalize the errata, and then write an update draft = based on the next text? I don't think the draft should be based on the old = section 5.7 text. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: Christer Holmberg >> Sent: 04 December 2015 20:59 >> To: Christer Holmberg ; Paul Kyzivat=20 >> ; sipcore@ietf.org >> Subject: RE: [sipcore] Misalignments between the P- header=20 >> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: >> P-Access-Network-Info >> >> Hi, >> >> I guess we could also consider changing "method" to "request". The "meth= od" terminology doesn't seem to be used anywhere else in the document... >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer=20 >> Holmberg >> Sent: 04 December 2015 16:35 >> To: Paul Kyzivat ; sipcore@ietf.org >> Subject: Re: [sipcore] Misalignments between the P- header=20 >> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: >> P-Access-Network-Info >> >> Hi, >> >> So, based on my chapter 5.7 fix suggestions for each individual header f= ield, below is a "compiled" fix suggestion for the whole chapter. >> >> Note that I've done some minor editorial changes, based e.g. on Jean's c= omments. >> >> >> OLD TEXT: >> >> 5.7. New Headers >> >> The P-Associated-URI header field can appear in SIP REGISTER method >> and 2xx resonses. The P-Called-Party-ID header field can appear in >> SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods. >> The P-Visited-Network-ID header field can appear in all >> SIP methods except ACK, BYE, and CANCEL and all responses. The >> P-Access-Network-Info header field can appear in all SIP methods >> except ACK and CANCEL and all responses. The P-Charging-Vector hea= der field can appear >> in all SIP methods except CANCEL. The P-Charging-Function-Addresse= s >> header field can appear in all SIP methods except ACK and CANCEL. >> >> >> NEW TEXT: >> >> 5.7. New Headers >> >> The P-Associated-URI header field can appear in SIP REGISTER >> 2xx responses. The P-Called-Party-ID header field can appear in >> SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and in= all >> responses associated with those methods. The P-Visited-Network-ID = header field can appear in all >> SIP methods except ACK, BYE, and CANCEL. The >> P-Access-Network-Info header field can appear in all SIP methods >> and responses, except in ACK and CANCEL methods and CANCEL response= s. The P-Charging-Vector header field can appear >> in all SIP methods and responses, except in CANCEL methods and CANC= EL responses. The P-Charging-Function-Addresses >> header field can appear in all SIP methods and responses except ACK= and CANCEL. >> >> >> Regards, >> >> Christer >> >> >> >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul=20 >> Kyzivat >> Sent: 4. joulukuuta 2015 16:09 >> To: sipcore@ietf.org >> Subject: Re: [sipcore] Misalignments between the P- header=20 >> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: >> P-Access-Network-Info >> >> On 12/4/15 6:20 AM, Christer Holmberg wrote: >> >>> Now, in my e-mails regarding the other P- header fields, all of them re= quire a fix in section 5.7. >>> >>> So, I assume a SINGLE errata would be better, rather than creating sepa= rate erratas for each header field? That way we can look at the whole parag= raph in one go, instead of working on individual sentencens. >> >> Yes, I think so. >> >> I found the separate emails for each issue a little hard to follow since= they were all affecting the same stuff. It is easier to follow the big pic= ture when they are all put together. >> >> Thanks, >> Paul >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Dec 7 03:42: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 A1B101AC436 for ; Mon, 7 Dec 2015 03:42:41 -0800 (PST) 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 yJUyk8NT2pcr for ; Mon, 7 Dec 2015 03:42:39 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 110C41AC42D for ; Mon, 7 Dec 2015 03:42:38 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id A99D0A28070D3; Mon, 7 Dec 2015 11:42:34 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id tB7BgZOX008520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Dec 2015 12:42:35 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.213]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 7 Dec 2015 12:42:35 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Paul Kyzivat , "A. Jean Mahoney" , "sipcore@ietf.org" Thread-Topic: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Thread-Index: AdEttCY/6pwG9PPZQjGda7vzjTcvpgAWffcAAB2BxGAABDLmAAACYMQAAAnTz2AAApSIcAACGbkAAEp35hAADbjaAAAGrTagAAELE8AAFpd8sAAMShfw Date: Mon, 7 Dec 2015 11:42:34 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADE1F3B9@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <7594FB04B1934943A5C02806D1A2204B37C7C70D@ESESSMB209.ericsson.se> <5660BC4A.2030908@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C7FC93@ESESSMB209.ericsson.se> <56619E7C.5090706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37C8094B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C80EE3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C811D4@ESESSMB209.ericsson.se> <56620FCE.6070904@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C842FD@ESESSMB209.ericsson.se> <56645FA4.6090702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37C8531A@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADE1EFEF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37C872F3@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C872F3@ESESSMB209.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.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info 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, 07 Dec 2015 11:42:41 -0000 But now it is added to ACK, it does need to be clarified. Keith -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: 07 December 2015 05:47 To: DRAGE, Keith (Keith); Paul Kyzivat; A. Jean Mahoney; sipcore@ietf.org Subject: RE: [sipcore] Misalignments between the P- header definitions in R= FC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Hi, ... >In regard to the ACK request, I'd note that for those header fields=20 >where it is now added, it is only added where it is set as a result of 200= (OK) responses (to INVITE). ACK requests to 3xx - 6xx responses have the s= ame problems as CANCEL. I think it would be worth capturing this distinctio= n in the text. I don't think such details should be in chapter 5.7. It should be clarified= in the chapters describing the usage of individual header fields. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 06 December 2015 18:31 To: Paul Kyzivat; A. Jean Mahoney; sipcore@ietf.org Subject: Re: [sipcore] Misalignments between the P- header definitions in R= FC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Hi, >>> I think finalizing the errata, and then writing an update draft are the= correct steps. >> >> I agree. >> >> However, if doing so, we must still more or less agree on the content of= the update draft. >> >> Because, if we agree the errata, and then don't agree on the content of = the draft, we will cause an even greater misalignment with 3GPP. > > While there are (procedural) reasons to split the work this way, doing so= obfuscates what is being done. > > At the least I think it would be good settle on the overall set of=20 > changes required, and *then* partition them into errata and a draft. > And IMO it would be a good thing to restate the errata in the draft.=20 > (In a non-normative way.) Ok. I started putting a draft together, so I'll put everything there. As 7315 updates will have to go to DISPATCH, it will be a draft-holmberg-di= spatch draft, but I guess that doesn't matter. Same people... Regards, Christer > On 12/4/15 2:15 PM, Christer Holmberg wrote: >> Hi, >> >> Also, assuming we will update RFC 7315 in order to allow the PANI header= field in ACK requests, section 5.7 would be modified. >> >> So, should we first finalize the errata, and then write an update draft = based on the next text? I don't think the draft should be based on the old = section 5.7 text. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: Christer Holmberg >> Sent: 04 December 2015 20:59 >> To: Christer Holmberg ; Paul Kyzivat=20 >> ; sipcore@ietf.org >> Subject: RE: [sipcore] Misalignments between the P- header=20 >> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: >> P-Access-Network-Info >> >> Hi, >> >> I guess we could also consider changing "method" to "request". The "meth= od" terminology doesn't seem to be used anywhere else in the document... >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer=20 >> Holmberg >> Sent: 04 December 2015 16:35 >> To: Paul Kyzivat ; sipcore@ietf.org >> Subject: Re: [sipcore] Misalignments between the P- header=20 >> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: >> P-Access-Network-Info >> >> Hi, >> >> So, based on my chapter 5.7 fix suggestions for each individual header f= ield, below is a "compiled" fix suggestion for the whole chapter. >> >> Note that I've done some minor editorial changes, based e.g. on Jean's c= omments. >> >> >> OLD TEXT: >> >> 5.7. New Headers >> >> The P-Associated-URI header field can appear in SIP REGISTER method >> and 2xx resonses. The P-Called-Party-ID header field can appear in >> SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods. >> The P-Visited-Network-ID header field can appear in all >> SIP methods except ACK, BYE, and CANCEL and all responses. The >> P-Access-Network-Info header field can appear in all SIP methods >> except ACK and CANCEL and all responses. The P-Charging-Vector hea= der field can appear >> in all SIP methods except CANCEL. The P-Charging-Function-Addresse= s >> header field can appear in all SIP methods except ACK and CANCEL. >> >> >> NEW TEXT: >> >> 5.7. New Headers >> >> The P-Associated-URI header field can appear in SIP REGISTER >> 2xx responses. The P-Called-Party-ID header field can appear in >> SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and in= all >> responses associated with those methods. The P-Visited-Network-ID = header field can appear in all >> SIP methods except ACK, BYE, and CANCEL. The >> P-Access-Network-Info header field can appear in all SIP methods >> and responses, except in ACK and CANCEL methods and CANCEL response= s. The P-Charging-Vector header field can appear >> in all SIP methods and responses, except in CANCEL methods and CANC= EL responses. The P-Charging-Function-Addresses >> header field can appear in all SIP methods and responses except ACK= and CANCEL. >> >> >> Regards, >> >> Christer >> >> >> >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul=20 >> Kyzivat >> Sent: 4. joulukuuta 2015 16:09 >> To: sipcore@ietf.org >> Subject: Re: [sipcore] Misalignments between the P- header=20 >> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: >> P-Access-Network-Info >> >> On 12/4/15 6:20 AM, Christer Holmberg wrote: >> >>> Now, in my e-mails regarding the other P- header fields, all of them re= quire a fix in section 5.7. >>> >>> So, I assume a SINGLE errata would be better, rather than creating sepa= rate erratas for each header field? That way we can look at the whole parag= raph in one go, instead of working on individual sentencens. >> >> Yes, I think so. >> >> I found the separate emails for each issue a little hard to follow since= they were all affecting the same stuff. It is easier to follow the big pic= ture when they are all put together. >> >> Thanks, >> Paul >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Dec 7 04:02:02 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4E61ACD3B for ; Mon, 7 Dec 2015 04:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XXk-15wgKVf for ; Mon, 7 Dec 2015 04:01:58 -0800 (PST) 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 D37B11ACD4C for ; Mon, 7 Dec 2015 04:01:57 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-fd-56657533686c Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 79.74.05041.33575665; Mon, 7 Dec 2015 13:01:55 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0248.002; Mon, 7 Dec 2015 13:01:55 +0100 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , Paul Kyzivat , "A. Jean Mahoney" , "sipcore@ietf.org" Thread-Topic: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Thread-Index: AdEttCY/6pwG9PPZQjGda7vzjTcvpgAWffcAAB2BxGAABDLmAAACYMQAAAnTz2AAApSIcAACGbkAAEp35hAADbjaAAAGrTagAAELE8AAFpd8sAAMShfwAADODnA= Date: Mon, 7 Dec 2015 12:01:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C88AC3@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37C7C70D@ESESSMB209.ericsson.se> <5660BC4A.2030908@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C7FC93@ESESSMB209.ericsson.se> <56619E7C.5090706@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37C8094B@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C80EE3@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C811D4@ESESSMB209.ericsson.se> <56620FCE.6070904@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C842FD@ESESSMB209.ericsson.se> <56645FA4.6090702@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37C8531A@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADE1EFEF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B37C872F3@ESESSMB209.ericsson.se> <949EF20990823C4C85C18D59AA11AD8BADE1F3B9@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADE1F3B9@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7hK5xaWqYwacVxhZPG88yWjR0rmS1 WLHhAKvF1x+b2BxYPFqf7WX1+Pv+A5PHkiU/mTxm7XzCEsASxWWTkpqTWZZapG+XwJXxbsJ7 1oJ5lhXPzz5naWB8rNvFyMEhIWAisfIokMkJZIpJXLi3nq2LkYtDSOAwo8T9zvksEM5iRomL h04wgzSwCVhIdP/TBomLCGwFil9rBysSFuhglPjWt4cNItPJKPF6WjcrhNPFKPHudj8ryBIW ARWJn0sesoPYvAK+Ev+nfGOF2HGVTeJB/zsmkB2cArESZyeA1TACHfX91BomEJtZQFzi1pP5 TBDHCkgs2XOeGcIWlXj5+B8rhK0o0f60gRGiXkdiwe5PbBC2tsSyha+ZIfYKSpyc+YRlAqPo LCRjZyFpmYWkZRaSlgWMLKsYRYtTi4tz042M9FKLMpOLi/Pz9PJSSzYxAqPq4JbfVjsYDz53 PMQowMGoxMO7oTUlTIg1say4MvcQowQHs5IIr2xmapgQb0piZVVqUX58UWlOavEhRmkOFiVx 3mamB6FCAumJJanZqakFqUUwWSYOTqkGRn3ntRaLohi6/Ms/z7K9/tZ7lbTlGmtx590Xle6z T1gqJCAyzTr6qUdJxYST2XMOBNlJX/Ra8spjf3b+VP7ONSnf2xomTeSOft6gFTC9ibnueO98 jukKfyoTmf57zdb+5iK/Ov/57d+RrVIXa142NIVE/mAIYFghxV/7oHPB7g2Rs7WKtx26qcRS nJFoqMVcVJwIAFiRuJamAgAA Archived-At: Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info 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, 07 Dec 2015 12:02:00 -0000 >But now it is added to ACK, it does need to be clarified. Yes, but not in chapter 5.7 (in my opinion). It is similar to the case where a header field is only allowed in responses= associated with specific response code(s). I don't think we'd list all tho= se response codes in section 5.7. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: 07 December 2015 05:47 To: DRAGE, Keith (Keith); Paul Kyzivat; A. Jean Mahoney; sipcore@ietf.org Subject: RE: [sipcore] Misalignments between the P- header definitions in R= FC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Hi, ... >In regard to the ACK request, I'd note that for those header fields=20 >where it is now added, it is only added where it is set as a result of 200= (OK) responses (to INVITE). ACK requests to 3xx - 6xx responses have the s= ame problems as CANCEL. I think it would be worth capturing this distinctio= n in the text. I don't think such details should be in chapter 5.7. It should be clarified= in the chapters describing the usage of individual header fields. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 06 December 2015 18:31 To: Paul Kyzivat; A. Jean Mahoney; sipcore@ietf.org Subject: Re: [sipcore] Misalignments between the P- header definitions in R= FC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info Hi, >>> I think finalizing the errata, and then writing an update draft are the= correct steps. >> >> I agree. >> >> However, if doing so, we must still more or less agree on the content of= the update draft. >> >> Because, if we agree the errata, and then don't agree on the content of = the draft, we will cause an even greater misalignment with 3GPP. > > While there are (procedural) reasons to split the work this way, doing so= obfuscates what is being done. > > At the least I think it would be good settle on the overall set of=20 > changes required, and *then* partition them into errata and a draft. > And IMO it would be a good thing to restate the errata in the draft.=20 > (In a non-normative way.) Ok. I started putting a draft together, so I'll put everything there. As 7315 updates will have to go to DISPATCH, it will be a draft-holmberg-di= spatch draft, but I guess that doesn't matter. Same people... Regards, Christer > On 12/4/15 2:15 PM, Christer Holmberg wrote: >> Hi, >> >> Also, assuming we will update RFC 7315 in order to allow the PANI header= field in ACK requests, section 5.7 would be modified. >> >> So, should we first finalize the errata, and then write an update draft = based on the next text? I don't think the draft should be based on the old = section 5.7 text. >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: Christer Holmberg >> Sent: 04 December 2015 20:59 >> To: Christer Holmberg ; Paul Kyzivat=20 >> ; sipcore@ietf.org >> Subject: RE: [sipcore] Misalignments between the P- header=20 >> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: >> P-Access-Network-Info >> >> Hi, >> >> I guess we could also consider changing "method" to "request". The "meth= od" terminology doesn't seem to be used anywhere else in the document... >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer=20 >> Holmberg >> Sent: 04 December 2015 16:35 >> To: Paul Kyzivat ; sipcore@ietf.org >> Subject: Re: [sipcore] Misalignments between the P- header=20 >> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: >> P-Access-Network-Info >> >> Hi, >> >> So, based on my chapter 5.7 fix suggestions for each individual header f= ield, below is a "compiled" fix suggestion for the whole chapter. >> >> Note that I've done some minor editorial changes, based e.g. on Jean's c= omments. >> >> >> OLD TEXT: >> >> 5.7. New Headers >> >> The P-Associated-URI header field can appear in SIP REGISTER method >> and 2xx resonses. The P-Called-Party-ID header field can appear in >> SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods. >> The P-Visited-Network-ID header field can appear in all >> SIP methods except ACK, BYE, and CANCEL and all responses. The >> P-Access-Network-Info header field can appear in all SIP methods >> except ACK and CANCEL and all responses. The P-Charging-Vector hea= der field can appear >> in all SIP methods except CANCEL. The P-Charging-Function-Addresse= s >> header field can appear in all SIP methods except ACK and CANCEL. >> >> >> NEW TEXT: >> >> 5.7. New Headers >> >> The P-Associated-URI header field can appear in SIP REGISTER >> 2xx responses. The P-Called-Party-ID header field can appear in >> SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAGE methods and in= all >> responses associated with those methods. The P-Visited-Network-ID = header field can appear in all >> SIP methods except ACK, BYE, and CANCEL. The >> P-Access-Network-Info header field can appear in all SIP methods >> and responses, except in ACK and CANCEL methods and CANCEL response= s. The P-Charging-Vector header field can appear >> in all SIP methods and responses, except in CANCEL methods and CANC= EL responses. The P-Charging-Function-Addresses >> header field can appear in all SIP methods and responses except ACK= and CANCEL. >> >> >> Regards, >> >> Christer >> >> >> >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul=20 >> Kyzivat >> Sent: 4. joulukuuta 2015 16:09 >> To: sipcore@ietf.org >> Subject: Re: [sipcore] Misalignments between the P- header=20 >> definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: >> P-Access-Network-Info >> >> On 12/4/15 6:20 AM, Christer Holmberg wrote: >> >>> Now, in my e-mails regarding the other P- header fields, all of them re= quire a fix in section 5.7. >>> >>> So, I assume a SINGLE errata would be better, rather than creating sepa= rate erratas for each header field? That way we can look at the whole parag= raph in one go, instead of working on individual sentencens. >> >> Yes, I think so. >> >> I found the separate emails for each issue a little hard to follow since= they were all affecting the same stuff. It is easier to follow the big pic= ture when they are all put together. >> >> Thanks, >> Paul >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Dec 7 04:32: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 CC71A1A882D for ; Mon, 7 Dec 2015 04:32:56 -0800 (PST) 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 S-yr86HjrAKU for ; Mon, 7 Dec 2015 04:32:55 -0800 (PST) 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 E6AA01A6FED for ; Mon, 7 Dec 2015 04:32:54 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id CE3B6BE1EAB3A; Mon, 7 Dec 2015 12:32:49 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id tB7CWgeJ004046 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Dec 2015 13:32:52 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.213]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 7 Dec 2015 13:32:37 +0100 From: "DRAGE, Keith (Keith)" To: Ben Campbell , Paul Kyzivat Thread-Topic: [sipcore] A new SIP header fields with "P-" name Thread-Index: AdErb0NStzAvzI7DQoGlsVH1re72C566iqdw4UvBzICAABvlAP/7cNmA Date: Mon, 7 Dec 2015 12:32:36 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADE1F496@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <39B5E4D390E9BD4890E2B3107900610112AEC437@ESESSMB301.ericsson.se> <7699C626-BCC4-4B8F-AB14-0C81D7BE62D7@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112AEE460@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112AF324A@ESESSMB301.ericsson.se> <56619F67.3050400@alum.mit.edu> <940D58F4-B3C4-477C-AB89-05C2704FD974@nostrum.com> In-Reply-To: <940D58F4-B3C4-477C-AB89-05C2704FD974@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A new SIP header fields with "P-" name 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, 07 Dec 2015 12:32:57 -0000 At the moment I think there are privacy concerns over and above the existin= g content of the P-Access-Network-Info.=20 I am still investigating how we should deal with this, but currently my vie= w is that a different "trust" domain will need to operate to meet data prot= ection requirements in many countries (i.e. some screening entities will ne= ed to screen out this historical information but allow current information = to pass through), and therefore these need to be in a different header fiel= d. Keith -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ben Campbell Sent: 04 December 2015 15:53 To: Paul Kyzivat Cc: sipcore@ietf.org Subject: Re: [sipcore] A new SIP header fields with "P-" name (as individual) On 4 Dec 2015, at 8:12, Paul Kyzivat wrote: > On 12/4/15 4:13 AM, Ivo Sedlacek wrote: >> Just to give you the complete picture - the other alternative=20 >> discussed in 3GPP was to extend P-Access-Network-Info header field=20 >> with a new parameter with value containing the information on the=20 >> last recently seen 3GPP radio network cell and another parameter=20 >> indicating how old this information is. > > That seems fine if this new information is really access network info.=20 > Generally I would recommend doing whichever is "cleanest". Obviously=20 > the semantics are the same either way. Are there privacy considerations here? It seems like the information as des= cribed can (and maybe is intended to) imply geolocation. Ben. _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Dec 7 05:47:22 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 8A60A1B32E1 for ; Mon, 7 Dec 2015 05:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWSzgTpIq45L for ; Mon, 7 Dec 2015 05:47:18 -0800 (PST) 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 1AA8C1B32DB for ; Mon, 7 Dec 2015 05:47:17 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-da-56658de3e68f Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 64.F2.05149.3ED85665; Mon, 7 Dec 2015 14:47:15 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.31]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0248.002; Mon, 7 Dec 2015 14:47:15 +0100 From: Ivo Sedlacek To: "DRAGE, Keith (Keith)" , Ben Campbell , Paul Kyzivat Thread-Topic: [sipcore] A new SIP header fields with "P-" name Thread-Index: AQHRLeTFtzAvzI7DQoGlsVH1re72C566iqdwgABEiYCAABvlAIAEfxIAgAAj2mA= Date: Mon, 7 Dec 2015 13:47:14 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112AF45CA@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B3107900610112AEC437@ESESSMB301.ericsson.se> <7699C626-BCC4-4B8F-AB14-0C81D7BE62D7@nostrum.com> <39B5E4D390E9BD4890E2B3107900610112AEE460@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B3107900610112AF324A@ESESSMB301.ericsson.se> <56619F67.3050400@alum.mit.edu> <940D58F4-B3C4-477C-AB89-05C2704FD974@nostrum.com> <949EF20990823C4C85C18D59AA11AD8BADE1F496@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADE1F496@FR712WXCHMBA11.zeu.alcatel-lucent.com> 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7qO7j3tQwgyu95hbzO0+zWzxtPMto sWLDAVaLrz82sTmweLQ+28vq8ff9ByaPJUt+MnnM2vmEJYAlissmJTUnsyy1SN8ugSvjRsd5 1oJtwhXXuntYGhj/8ncxcnJICJhInNz+gQnCFpO4cG89WxcjF4eQwGFGiTmHZ4MlhAQWMUrM mlgCYrMJ6ElM3HKEFaRIRKCZUeLs9YssIAlmAU2JRzv3gjUIC9hKvLpxhQ3EFhGwk7hz5g87 hO0nce/UCrA4i4CKxM0nHcwgNq+Ar8TPvmVMEJtvMUt83TcZrIhTIFZix4NvYM2MArISV//0 MkIsE5e49WQ+1NkCEkv2nGeGsEUlXj7+xwphK0p8fLUPql5HYsHuT2wQtrbEsoWvoRYLSpyc +YRlAqPYLCRjZyFpmYWkZRaSlgWMLKsYRYtTi5Ny042M9FKLMpOLi/Pz9PJSSzYxAmPt4Jbf BjsYXz53PMQowMGoxMO7oTUlTIg1say4MvcQowQHs5IIr2xmapgQb0piZVVqUX58UWlOavEh RmkOFiVx3mamB6FCAumJJanZqakFqUUwWSYOTqkGxi02du7s+sUW69tavC5OCnjzPu6Ivl2Z YmupRNWrM6YC9gm7pixqnPM19pJVmKb40vUTuK4u1jirrv7Eut2mULTAo0DD88PrdFPT3l8+ stcW+piWb743yzZkq+UkjvageXbv2JfOkLaN8e8/NolLqvOc5d91HqrVzxYtW2K147Fc2q57 yYW/lFiKMxINtZiLihMBHTYCuLECAAA= Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] A new SIP header fields with "P-" name 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, 07 Dec 2015 13:47:20 -0000 I agree that the information is sensitive and a trust domain is needed. IMO, the trust domain includes the sending UA, the home domain of the sendi= ng UA, networks between sending UA and the home domain, PSAP, networks betw= een sending UA and the PSAP.=20 This is the same as the trust domain for the P-Access-Network-Info header f= ield. Kind regards Ivo Sedlacek -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, Keith (= Keith) Sent: Monday, December 07, 2015 1:33 PM To: Ben Campbell; Paul Kyzivat Cc: sipcore@ietf.org Subject: Re: [sipcore] A new SIP header fields with "P-" name At the moment I think there are privacy concerns over and above the existin= g content of the P-Access-Network-Info.=20 I am still investigating how we should deal with this, but currently my vie= w is that a different "trust" domain will need to operate to meet data prot= ection requirements in many countries (i.e. some screening entities will ne= ed to screen out this historical information but allow current information = to pass through), and therefore these need to be in a different header fiel= d. Keith -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ben Campbell Sent: 04 December 2015 15:53 To: Paul Kyzivat Cc: sipcore@ietf.org Subject: Re: [sipcore] A new SIP header fields with "P-" name (as individual) On 4 Dec 2015, at 8:12, Paul Kyzivat wrote: > On 12/4/15 4:13 AM, Ivo Sedlacek wrote: >> Just to give you the complete picture - the other alternative=20 >> discussed in 3GPP was to extend P-Access-Network-Info header field=20 >> with a new parameter with value containing the information on the=20 >> last recently seen 3GPP radio network cell and another parameter=20 >> indicating how old this information is. > > That seems fine if this new information is really access network info.=20 > Generally I would recommend doing whichever is "cleanest". Obviously=20 > the semantics are the same either way. Are there privacy considerations here? It seems like the information as des= cribed can (and maybe is intended to) imply geolocation. Ben. _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Dec 7 13:38:14 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 E23D71AD352 for ; Mon, 7 Dec 2015 13:38:13 -0800 (PST) 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 eokcBX-MzVem for ; Mon, 7 Dec 2015 13:38:11 -0800 (PST) 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 D9D251ACDBB for ; Mon, 7 Dec 2015 13:38:11 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tB7Lc7nm003483 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 7 Dec 2015 15:38:08 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Christer Holmberg" Date: Mon, 07 Dec 2015 15:38:07 -0600 Message-ID: <6CF3A5B1-90E7-4F50-8424-0315287BB712@nostrum.com> In-Reply-To: <56635188.40009@nostrum.com> References: <20151204140645.77D7B180004@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37C8372C@ESESSMB209.ericsson.se> <56635188.40009@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: SIPCORE , "sipcore-chairs@tools.ietf.org" Subject: Re: [sipcore] [Technical Errata Reported] RFC3261 (4553) 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, 07 Dec 2015 21:38:14 -0000 Hi, I am inclined to mark this, as submitted, as "hold for update", which I suspect is not what Christer wants to hear. There are two parts to this: Adding "or if the Content-Disposition header field is missing" seems reasonable. I have trouble imagining that the original intent was not exactly that. But I would like to see a bit more discussion about whether this is likely to cause unnecessary transaction failure. Would we expect the UAS to reject any request that had a a body with an unknown MIME type and no content-disposition? The change from SHOULD to MUST second guesses the original intent. I don't think we have a reason to think people really meant to write MUST. Rather, I think this is more a (potentially reasonable) change in expectations between then and now. Also, list discussion on that point did not seem conclusive. It seem to me that if people want to make that change, it needs to be in the form of an update. Christer, you mentioned that this is causing deployment problems. Can you elaborate on the nature of those problems? Thanks! Ben. On 5 Dec 2015, at 15:05, A. Jean Mahoney wrote: > Hi Christer, > > +Ben and +sipcore since errata aren't sent automatically to the list. > The AD pulls the levers on submitted errata. > > Thanks, > > Jean > > > On 12/5/15 9:42 AM, Christer Holmberg wrote: >> Hi chairs, >> >> I hope that we can move ahead with this errata asap. It may seem like >> a minor issue, but it is actually causing headaches in deployments, >> and within the test specification community. >> >> People supported the suggestion on the list, and nobody objected, so >> I assume it should not cause any problems. >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: 04 December 2015 16:07 >> To: jdrosen@dynamicsoft.com; schulzrinne@cs.columbia.edu; Gonzalo >> Camarillo ; alan.johnston@wcom.com; >> jon.peterson@neustar.com; rsparks@dynamicsoft.com; mjh@icir.org; >> schooler@research.att.com; ben@nostrum.com; alissa@cooperw.in; >> dean.willis@softarmor.com; drage@alcatel-lucent.com >> Cc: Christer Holmberg ; >> rfc-editor@rfc-editor.org >> Subject: [Technical Errata Reported] RFC3261 (4553) >> >> The following errata report has been submitted for RFC3261, >> "SIP: Session Initiation Protocol". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3261&eid=4553 >> >> -------------------------------------- >> Type: Technical >> Reported by: Christer Holmberg >> >> Section: 20.11 >> >> Original Text >> ------------- >> The handling parameter, handling-param, describes how the UAS should >> react if it receives a message body whose content type or disposition >> type it does not understand. The parameter has defined values of >> \\"optional\\" and \\"required\\". If the handling parameter is >> missing, the value \\"required\\" SHOULD be assumed. The handling >> parameter is described in RFC 3204 [19]. >> >> >> Corrected Text >> -------------- >> The handling parameter, handling-param, describes how the UAS should >> react if it receives a message body whose content type or disposition >> type it does not understand. The parameter has defined values of >> \\"optional\\" and \\"required\\". If the handling parameter is >> missing, or if the Content-Disposition header field is missing, the >> value \\"required\\" >> MUST be assumed. The handling parameter is described in RFC 3204 >> [19]. >> >> >> Notes >> ----- >> SIPCORE discussion: >> https://mailarchive.ietf.org/arch/msg/sipcore/bn-pRgDyGL2FP_M7eYpyT35zNp4 >> >> 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. >> >> -------------------------------------- >> RFC3261 (draft-ietf-sip-rfc2543bis-09) >> -------------------------------------- >> Title : SIP: Session Initiation Protocol >> Publication Date : June 2002 >> Author(s) : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. >> Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler >> Category : PROPOSED STANDARD >> Source : Session Initiation Protocol >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> From nobody Mon Dec 7 23:33:59 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 CF8061B3438 for ; Mon, 7 Dec 2015 23:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBjNPvNRA1HT for ; Mon, 7 Dec 2015 23:33:55 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 365C31B343E for ; Mon, 7 Dec 2015 23:33:55 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-86-566687e1ada8 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BD.11.04914.1E786665; Tue, 8 Dec 2015 08:33:53 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0248.002; Tue, 8 Dec 2015 08:33:52 +0100 From: Christer Holmberg To: Ben Campbell Thread-Topic: [Technical Errata Reported] RFC3261 (4553) Thread-Index: AQHRMTeSIo2kj1TwkUCTfZn6k/6AuJ7ArrtA Date: Tue, 8 Dec 2015 07:33:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C8B0E1@ESESSMB209.ericsson.se> References: <20151204140645.77D7B180004@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37C8372C@ESESSMB209.ericsson.se> <56635188.40009@nostrum.com> <6CF3A5B1-90E7-4F50-8424-0315287BB712@nostrum.com> In-Reply-To: <6CF3A5B1-90E7-4F50-8424-0315287BB712@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7n+7D9rQwgwOdkhbzO0+zWzR0rmS1 OPXqNLPF1x+b2BxYPJYs+cnkMWvnExaPL5c/swUwR3HZpKTmZJalFunbJXBl3Fp1mangqFHF v2fL2RoYX2h0MXJySAiYSBy9sI0FwhaTuHBvPVsXIxeHkMBhRonvS6YzQziLGSXaO/ezdjFy cLAJWEh0/9MGaRARUJJ43ryVBaSGWaCLUaJr5TE2kBphAXOJj8edIGosJObdvc0KYRtJLPl0 EcxmEVCR+HxwNxOIzSvgKzF1wQ4WiF3nGSV6+q+AFXEK2Es0nDsAZjMCXff91BqwBmYBcYlb T+YzQVwtILFkz3lmCFtU4uXjf6wQtpLEjw2XWCDqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gm MIrNQjJ2FpKWWUhaZiFpWcDIsopRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjML4Obvmtu4Nx 9WvHQ4wCHIxKPLwG11PDhFgTy4orcw8xSnAwK4nwtuqmhQnxpiRWVqUW5ccXleakFh9ilOZg URLnbWF6ECokkJ5YkpqdmlqQWgSTZeLglGpg9Nr4xvTg9/PZ+iWnS11vTDpyrDr0ntn/cmX7 +9f3xFh+rZl5SERUV6d/AY9Q3nXJ89fP17l7fpnw7Ptuqzvz997JCzvFtz3mhmrrW3/d7NLr /wWubmXQ67nY+EizOPLwpJoYmdk7jMKOpPPcvd4zn+/hqpNzD/qsjsk+ufOozoeE+ZLJWvW3 ziuxFGckGmoxFxUnAgAchxRTqwIAAA== Archived-At: Cc: SIPCORE , "sipcore-chairs@tools.ietf.org" Subject: Re: [sipcore] [Technical Errata Reported] RFC3261 (4553) 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, 08 Dec 2015 07:33:58 -0000 Hi, >I am inclined to mark this, as submitted, as "hold for update", which I su= spect is not what Christer wants to hear.=20 Correct :) > There are two parts to this: > > Adding "or if the Content-Disposition header field is missing" seems reas= onable. I have trouble imagining that the original intent was not exactly t= hat. But I would like to=20 >see a bit more discussion about whether this is likely to cause unnecessar= y transaction failure. Would we expect the UAS to reject any request that h= ad a a body with an=20 >unknown MIME type and no content-disposition? The alternative is having cases where different people make different assum= ptions, so that the same transaction is sometimes rejected, and sometimes n= ot, depending on what UAS the request reaches. That is not good, and makes = it impossible to write specifications etc. > The change from SHOULD to MUST second guesses the original intent. I don'= t think we have a reason to think people really meant to write MUST.=20 > Rather, I think this is more a (potentially reasonable) change in expecta= tions between then and now. Also, list discussion on that point did not see= m conclusive. It seem to me that if people want to make that change, it nee= ds to be in the form of an update. I am ok to leave the "SHOULD->MUST" part outside the errata, and handle tha= t in an update. > Christer, you mentioned that this is causing deployment problems. Can you= elaborate on the nature of those problems? Yes. Unfortunately I can't give any company names, so I'll call them compan= y X and company Y. - Company X UA sends a SIP request with a message body (I don't remember th= e MIME type, but it doesn't really matter - it is not SDP), *WITHOUT* a C-D= header field. - Company Y UA does NOT support the MIME type, and assumes that the absence= of C-D means handling=3D"required". So, company Y rejects the request. - Company X claims that it is wrong behavior to reject the request, because= since there is no C-D header field one should not assume handling=3D"requi= red". Instead, the company Y UA should simply discard the message body. - Company Y claims that the absence of C-D means handling=3D"required", and= that rejecting the request is correct behavior. This is causing a serious amount of call failures in existing deployments, = and has been escalated up the ladders. Sure, company X and Y could perhaps agree on some fix to handle this. But, = later the same issue may later pop up somewhere else. The spec needs to be = clear on this, since we are talking about a case that can cause a SIP INVIT= E request to be rejected. Regards, Christer On 5 Dec 2015, at 15:05, A. Jean Mahoney wrote: > Hi Christer, > > +Ben and +sipcore since errata aren't sent automatically to the list.=20 > The AD pulls the levers on submitted errata. > > Thanks, > > Jean > > > On 12/5/15 9:42 AM, Christer Holmberg wrote: >> Hi chairs, >> >> I hope that we can move ahead with this errata asap. It may seem like=20 >> a minor issue, but it is actually causing headaches in deployments,=20 >> and within the test specification community. >> >> People supported the suggestion on the list, and nobody objected, so=20 >> I assume it should not cause any problems. >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: 04 December 2015 16:07 >> To: jdrosen@dynamicsoft.com; schulzrinne@cs.columbia.edu; Gonzalo=20 >> Camarillo ; alan.johnston@wcom.com;=20 >> jon.peterson@neustar.com; rsparks@dynamicsoft.com; mjh@icir.org;=20 >> schooler@research.att.com; ben@nostrum.com; alissa@cooperw.in;=20 >> dean.willis@softarmor.com; drage@alcatel-lucent.com >> Cc: Christer Holmberg ;=20 >> rfc-editor@rfc-editor.org >> Subject: [Technical Errata Reported] RFC3261 (4553) >> >> The following errata report has been submitted for RFC3261, >> "SIP: Session Initiation Protocol". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D3261&eid=3D4553 >> >> -------------------------------------- >> Type: Technical >> Reported by: Christer Holmberg >> >> Section: 20.11 >> >> Original Text >> ------------- >> The handling parameter, handling-param, describes how the UAS should=20 >> react if it receives a message body whose content type or disposition=20 >> type it does not understand. The parameter has defined values of=20 >> \\"optional\\" and \\"required\\". If the handling parameter is=20 >> missing, the value \\"required\\" SHOULD be assumed. The handling=20 >> parameter is described in RFC 3204 [19]. >> >> >> Corrected Text >> -------------- >> The handling parameter, handling-param, describes how the UAS should=20 >> react if it receives a message body whose content type or disposition=20 >> type it does not understand. The parameter has defined values of=20 >> \\"optional\\" and \\"required\\". If the handling parameter is=20 >> missing, or if the Content-Disposition header field is missing, the=20 >> value \\"required\\" >> MUST be assumed. The handling parameter is described in RFC 3204=20 >> [19]. >> >> >> Notes >> ----- >> SIPCORE discussion:=20 >> https://mailarchive.ietf.org/arch/msg/sipcore/bn-pRgDyGL2FP_M7eYpyT35 >> zNp4 >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please=20 >> 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=20 >> change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC3261 (draft-ietf-sip-rfc2543bis-09) >> -------------------------------------- >> Title : SIP: Session Initiation Protocol >> Publication Date : June 2002 >> Author(s) : J. Rosenberg, H. Schulzrinne, G. Camarillo, A.=20 >> Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler >> Category : PROPOSED STANDARD >> Source : Session Initiation Protocol >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> From nobody Tue Dec 8 02:35:26 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D90E1ACD53 for ; Tue, 8 Dec 2015 02:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 G3-5XA3VSZNb for ; Tue, 8 Dec 2015 02:35:24 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08681ACD78 for ; Tue, 8 Dec 2015 02:35:17 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-bc-5666b263b78c Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id DB.A8.04914.362B6665; Tue, 8 Dec 2015 11:35:15 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Tue, 8 Dec 2015 11:35:15 +0100 From: Christer Holmberg To: "A. Jean Mahoney" , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info - changes done in 7315 on purpose Thread-Index: AdExo3hbTZqIKKB9RYG5stCx1nuO1w== Date: Tue, 8 Dec 2015 10:35:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C8B806@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7q27yprQwgycP9C0aOleyWqzYcIDV 4uuPTWwOzB5/339g8liy5CeTx6ydT1gCmKO4bFJSczLLUov07RK4Mn7t+spa8J29YtmWw8wN jAdZuxg5OSQETCReXZnJCGGLSVy4t56ti5GLQ0jgMKPEtkWtUM5iRonji2+xdzFycLAJWEh0 /9MGaRARqJJ49eoLI0iNsMAaoIYnzewgjojAWkaJ3ldNrCANIgJ6EtM/+oA0sAioSJy9thxs G6+Ar0RD9yMwmxFo8/dTa5hAbGYBcYlbT+YzQVwkILFkz3lmCFtU4uXjf1BXK0n82HCJBaJe R2LB7k9sELa2xLKFr5kh5gtKnJz5hGUCo/AsJGNnIWmZhaRlFpKWBYwsqxhFi1OLi3PTjYz1 Uosyk4uL8/P08lJLNjECo+Hglt+6OxhXv3Y8xCjAwajEw2twPTVMiDWxrLgy9xCjBAezkggv 76y0MCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8LUwPQoUE0hNLUrNTUwtSi2CyTBycUg2Mdgaf np/dfTOuYrFXR5WjsMKsed9z6vN1357s3nX/IWfpKSbtI7++m397FOom++Tx23U8bH/nb6xU 14noXZNYwpOQG7Byws5j3NrGSt+7llmc7lsUkrOcy2HJrIXN514ezjzMGG0X7NJdc3bttujW PoaLC4P+m3PO5VAtDSrb8X5/B0/l/6diSizFGYmGWsxFxYkAEd3t3IICAAA= Archived-At: Subject: Re: [sipcore] Misalignments between the P- header definitions in RFC 3455, RFC 7315 and 3GPP TS 24.229: P-Access-Network-Info - changes done in 7315 on purpose 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, 08 Dec 2015 10:35:25 -0000 Hi, ... >> The P-Called-Party-ID header field can appear in >> SIP INVITE, OPTIONS, PUBLISH, SUBSCRIBE, and MESSAG= E methods and in all >> responses associated with those methods. > > For P-Called-Party-ID, Table 1 in RFC 3455 didn't list PUBLISH but did li= st REFER, which is not included in the the text above. Regarding PUBLISH, I found the following in Appendix A of 7315: "9. In Section 5.7, it was added that the P-Called-= Party-ID can appear in the PUBLISH method." So, based on that, it seems like 7315 was not intended to be aligned with 3= 455 - additions were allowed. So, while the errata still would add REFER, it would NOT remove PUBLISH. I did not find text in Appendix A regarding the other misalignments between= 7315 and 3455, so the question is whether we'll still treat them as mistak= es and fix them in the errata. Regards, Christer From nobody Tue Dec 8 04:44: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 D1EF01B2D36 for ; Tue, 8 Dec 2015 04:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRWbexIZBzkn for ; Tue, 8 Dec 2015 04:44:17 -0800 (PST) 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 9FEC51B2D3B for ; Tue, 8 Dec 2015 04:44:16 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-a0-5666d09db042 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 16.3B.05149.D90D6665; Tue, 8 Dec 2015 13:44:14 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Tue, 8 Dec 2015 13:44:10 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: New Version Notification for draft-holmberg-dispatch-rfc7315-updates-01.txt Thread-Index: AQHRMbWhJDSBUV2GtE26u3/22nFsXZ7BB+sw Date: Tue, 8 Dec 2015 12:44:09 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C8BB2F@ESESSMB209.ericsson.se> References: <20151208124031.27917.1368.idtracker@ietfa.amsl.com> In-Reply-To: <20151208124031.27917.1368.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPLMWRmVeSWpSXmKPExsUyM2K7ge68C2lhBhd28Vp8/bGJzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGXdfn2Us6JCs+P1+BXMD4xaJLkZODgkBE4nd/RfZIWwxiQv3 1rOB2EIChxklLpxX7mLkArIXM0rsXnmRsYuRg4NNwEKi+582SI2IgKbE8m9bwXqFBaIknn+c zwYRj5ZYcfwME4RtJLHp+CtWEJtFQEXi1Pt/YDW8Ar4S964/Z4TY5SCxdNpbsBpOAUeJi38u s4DYjED3fD+1BmwOs4C4xK0n85kg7hSQWLLnPDOELSrx8vE/VghbSeLHhkssIGcyA922fpc+ RKuixJTuh+wQawUlTs58wjKBUXQWkqmzEDpmIemYhaRjASPLKkbR4tTipNx0IyO91KLM5OLi /Dy9vNSSTYzAaDi45bfBDsaXzx0PMQpwMCrx8BpcTw0TYk0sK67MPcQowcGsJMK78HxamBBv SmJlVWpRfnxRaU5q8SFGaQ4WJXHeZqYHoUIC6YklqdmpqQWpRTBZJg5OqQbGuXzsDs+vLFNe vEDi66plk2adthWSWzPjlOW2/XuOG+8R2S5ZyBP0cCZngdSOmRffqz39FJM0J7fkkf8qwb++ Rx7Ib7bJf/t71WL74kkSwhmuu/fzppitufrwzFTBnbvmhy/IypAXer5/815BVoHQq7dXdh3n YlN+8SfUNKQ10blP66Pt3BV3liixFGckGmoxFxUnAgBApOkSggIAAA== Archived-At: Subject: [sipcore] FW: New Version Notification for draft-holmberg-dispatch-rfc7315-updates-01.txt 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, 08 Dec 2015 12:44:19 -0000 RllJLA0KDQpJJ3ZlIHN1Ym1pdHRlZCBhIGRyYWZ0IChOT1RFOiB2ZXJzaW9uIC0wMCBjb250YWlu ZWQgdGhlIHdyb25nIHRpdGxlLCBzbyBwbGVhc2UgcmVhZCB2ZXJzaW9uIDAxKSwgd2hpY2ggY29u dGFpbnMgYm90aCB0aGUgc3VnZ2VzdGVkIGVycmF0YSwgYW5kIHRoZSBzdWdnZXN0ZWQgdXBkYXRl LCB0byBSRkMgNzMxNS4NCg0KVGhlIGNvbnRlbnQgaXMgYmFzZWQgb24gdGhlIGUtbWFpbCBkaXNj dXNzaW9ucyAod2hpY2ggd2VyZSB0cmlnZ2VyZWQgYnkgdGhlIG1pc2FsaWdubWVudCBzdHVkeSBk b25lIGluIDNHUFApLg0KDQpUaGUgZHJhZnQgY2FuIGFsc28gYmUgZm91bmQgb24gZ2l0aHViOiBo dHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtNzMxNS11cGRhdGVzDQoNCihOT1RFOiBUaGlz IGlzIGEgcGVyc29uYWwgR2l0aHViIHJlcG8pDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcg W21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogOC4gam91bHVrdXV0YSAy MDE1IDE0OjQxDQpUbzogR29uemFsbyBTYWxndWVpcm87IENocmlzdGVyIEhvbG1iZXJnOyBOZXZl bmthIEJpb25kaWMNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt aG9sbWJlcmctZGlzcGF0Y2gtcmZjNzMxNS11cGRhdGVzLTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNp b24gb2YgSS1ELCBkcmFmdC1ob2xtYmVyZy1kaXNwYXRjaC1yZmM3MzE1LXVwZGF0ZXMtMDEudHh0 DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IENocmlzdGVyIEhvbG1iZXJnIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWhvbG1iZXJn LWRpc3BhdGNoLXJmYzczMTUtdXBkYXRlcw0KUmV2aXNpb246CTAxDQpUaXRsZToJCVJGQyA3MzE1 IFVwZGF0ZXMNCkRvY3VtZW50IGRhdGU6CTIwMTUtMTItMDgNCkdyb3VwOgkJSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQpQYWdlczoJCTcNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcmZjNzMxNS11cGRhdGVz LTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWhvbG1iZXJnLWRpc3BhdGNoLXJmYzczMTUtdXBkYXRlcy8NCkh0bWxpemVkOiAgICAg ICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaG9sbWJlcmctZGlzcGF0Y2gtcmZj NzMxNS11cGRhdGVzLTAxDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWhvbG1iZXJnLWRpc3BhdGNoLXJmYzczMTUtdXBkYXRlcy0wMQ0KDQpB YnN0cmFjdDoNCiAgIFRoZSAzcmQtR2VuZXJhdGlvbiBQYXJ0bmVyc2hpcCBQcm9qZWN0IDNHUFAg aGFzIGlkZW50aWZpZWQgY2FzZXMNCiAgIHdoZXJlIGRpZmZlcmVudCBTSVAgcHJpdmF0ZSBoZWFk ZXIgZXh0ZW5zaW9ucyByZWZlcnJlZCB0byBhcyBQLQ0KICAgaGVhZGVyIGZpZWxkcywgZGVmaW5l ZCBpbiBSRkMgNzMxNSwgbmVlZCB0byBiZSBpbmNsdWRlZCBpbiBTSVANCiAgIHJlcXVlc3RzIGFu ZCByZXNwb25zZXMgY3VycmVudGx5IG5vdCBhbGxvd2VkIGFjY29yZGluZyB0byBSRkMgNzMxNS4N CiAgIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkMgNzMxNSwgaW4gb3JkZXIgdG8gYWxsb3cgaW5j bHVzaW9uIG9mIHRoZQ0KICAgYWZmZWN0ZWQgUC0gaGVhZGVyIGZpZWxkcyBpbiBzdWNoIHJlcXVl c3RzIGFuZCByZXNwb25zZXMuDQoNCiAgIEluIG9yZGVyIHRvIGdldCBhIGNvbXBsZXRlIHBpY3R1 cmUsIHRoaXMgZG9jdW1lbnQgYWxzbyBjb250YWlucyBhIHNldA0KICAgb2YgZXJyYXRhIHRoYXQg YXJlIHRvIGJlIGZpbGVkIGFnYWluc3QgUkZDIDczMTUsIGluIG9yZGVyIHRvIGZpeA0KICAgbWlz YWxpZ25tZW50cyB0aGF0IG9jY3VycmVkIHdoZW4gUkZDIDM0NTUgd2FzIHVwZGF0ZWQgYW5kIG9i c29sZXRlZA0KICAgYnkgUkZDIDczMTUuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQoNCg== From nobody Tue Dec 8 06:12:10 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 241E81B2E61 for ; Tue, 8 Dec 2015 06:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 dRnR0ZrSrnUc for ; Tue, 8 Dec 2015 06:12:06 -0800 (PST) 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 0C0231B2E6D for ; Tue, 8 Dec 2015 06:11:57 -0800 (PST) Received: from [10.0.1.50] (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 tB8EBpLF012174 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 8 Dec 2015 08:11:52 -0600 (CST) (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.50] From: "Ben Campbell" To: "Christer Holmberg" Date: Tue, 08 Dec 2015 08:11:51 -0600 Message-ID: <9FFEF072-6575-4FB8-8C80-E850F43F9BD6@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C8B0E1@ESESSMB209.ericsson.se> References: <20151204140645.77D7B180004@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37C8372C@ESESSMB209.ericsson.se> <56635188.40009@nostrum.com> <6CF3A5B1-90E7-4F50-8424-0315287BB712@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C8B0E1@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: SIPCORE , "sipcore-chairs@tools.ietf.org" Subject: Re: [sipcore] [Technical Errata Reported] RFC3261 (4553) 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, 08 Dec 2015 14:12:08 -0000 On 8 Dec 2015, at 1:33, Christer Holmberg wrote: > Hi, > >> I am inclined to mark this, as submitted, as "hold for update", which >> I suspect is not what Christer wants to hear. > > Correct :) > >> There are two parts to this: >> >> Adding "or if the Content-Disposition header field is missing" seems >> reasonable. I have trouble imagining that the original intent was not >> exactly that. But I would like to >> see a bit more discussion about whether this is likely to cause >> unnecessary transaction failure. Would we expect the UAS to reject >> any request that had a a body with an >> unknown MIME type and no content-disposition? > > The alternative is having cases where different people make different > assumptions, so that the same transaction is sometimes rejected, and > sometimes not, depending on what UAS the request reaches. That is not > good, and makes it impossible to write specifications etc. Sure--but is that what we want it to do? It almost seems to me that if the sender wants the body part to be "required", it can say so. Is there a reasonable "success friendly" option here? If the answer to that requires thought or discussion, then maybe this should go in a draft, not an eratta. > >> The change from SHOULD to MUST second guesses the original intent. I >> don't think we have a reason to think people really meant to write >> MUST. >> Rather, I think this is more a (potentially reasonable) change in >> expectations between then and now. Also, list discussion on that >> point did not seem conclusive. It seem to me that if people want to >> make that change, it needs to be in the form of an update. > > I am ok to leave the "SHOULD->MUST" part outside the errata, and > handle that in an update. > >> Christer, you mentioned that this is causing deployment problems. Can >> you elaborate on the nature of those problems? > > Yes. Unfortunately I can't give any company names, so I'll call them > company X and company Y. > > - Company X UA sends a SIP request with a message body (I don't > remember the MIME type, but it doesn't really matter - it is not SDP), > *WITHOUT* a C-D header field. > - Company Y UA does NOT support the MIME type, and assumes that the > absence of C-D means handling="required". So, company Y rejects the > request. > - Company X claims that it is wrong behavior to reject the request, > because since there is no C-D header field one should not assume > handling="required". Instead, the company Y UA should simply discard > the message body. > - Company Y claims that the absence of C-D means handling="required", > and that rejecting the request is correct behavior. > > This is causing a serious amount of call failures in existing > deployments, and has been escalated up the ladders. Sounds like a default to "required" will cause even more call failures. I guess you might could use that as a lever to force Company X to insert C-D. Is that the preferred outcome? > > Sure, company X and Y could perhaps agree on some fix to handle this. > But, later the same issue may later pop up somewhere else. The spec > needs to be clear on this, since we are talking about a case that can > cause a SIP INVITE request to be rejected. > > Regards, > > Christer > > > From nobody Tue Dec 8 06:31:43 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 797A91A6EFE for ; Tue, 8 Dec 2015 06:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OygKk-bzlLMI for ; Tue, 8 Dec 2015 06:31:40 -0800 (PST) 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 82A4B1A6F0E for ; Tue, 8 Dec 2015 06:31:39 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-59-5666e9c9a565 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id F6.CD.05149.9C9E6665; Tue, 8 Dec 2015 15:31:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Tue, 8 Dec 2015 15:31:37 +0100 From: Christer Holmberg To: Ben Campbell Thread-Topic: [Technical Errata Reported] RFC3261 (4553) Thread-Index: AQHRMTeSIo2kj1TwkUCTfZn6k/6AuJ7ArrtAgABi1oCAABJ2IA== Date: Tue, 8 Dec 2015 14:31:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C8C06C@ESESSMB209.ericsson.se> References: <20151204140645.77D7B180004@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37C8372C@ESESSMB209.ericsson.se> <56635188.40009@nostrum.com> <6CF3A5B1-90E7-4F50-8424-0315287BB712@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C8B0E1@ESESSMB209.ericsson.se> <9FFEF072-6575-4FB8-8C80-E850F43F9BD6@nostrum.com> In-Reply-To: <9FFEF072-6575-4FB8-8C80-E850F43F9BD6@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM2K7ge7Jl2lhBtf69S3md55mt2joXMlq cerVaWaLrz82sTmweCxZ8pPJY9bOJyweXy5/ZgtgjuKySUnNySxLLdK3S+DKeHppMnvBMZmK 3inn2BoYX4h1MXJySAiYSLx9tZ8VwhaTuHBvPVsXIxeHkMBhRolL9z+xQziLGSVmvbkFVMXB wSZgIdH9TxukQURASeJ581YWkBpmgS5Gia6Vx9hAaoQFzCU+HneCqLGQmHf3NiuE7STx9Mta RhCbRUBF4szWRWA2r4CvxM3O30wgtpDACSaJi43VIDangL3E3e1vwHoZgY77fmoNWA2zgLjE rSfzmSCOFpBYsuc8M4QtKvHy8T+oZ5Qkfmy4xAJRryOxYPcnNghbW2LZwtfMEHsFJU7OfMIy gVFsFpKxs5C0zELSMgtJywJGllWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgdF1cMtvgx2M L587HmIU4GBU4uE1uJ4aJsSaWFZcmXuIUYKDWUmEt/V5WpgQb0piZVVqUX58UWlOavEhRmkO FiVx3mamB6FCAumJJanZqakFqUUwWSYOTqkGRlGjJSw1JzR/r3wv2eZXKZFxWDC8U5Jph8LO +/Xud05wRjPOj/5995iYb9KT20v6f+7Mjol3Zirq3pnxtN67fv1W0YVruaerLZjxcKFvqgNv p8eyzAevBDP1rnPp6Yj5S321Wfv7/J7EE0peQvl1q58oPxNaFZB05LXm4/yO+u3x08N3//n1 TYmlOCPRUIu5qDgRALWya2eqAgAA Archived-At: Cc: SIPCORE , "sipcore-chairs@tools.ietf.org" Subject: Re: [sipcore] [Technical Errata Reported] RFC3261 (4553) 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, 08 Dec 2015 14:31:41 -0000 Hi, >>>> I am inclined to mark this, as submitted, as "hold for update", which= =20 >>>> I suspect is not what Christer wants to hear. >>> >>> Correct :) >>> >>>> There are two parts to this: >>>> >>>> Adding "or if the Content-Disposition header field is missing" seems=20 >>>> reasonable. I have trouble imagining that the original intent was not= =20 >>>> exactly that. But I would like to see a bit more discussion about=20 >>>> whether this is likely to cause unnecessary transaction failure.=20 >>>> Would we expect the UAS to reject any request that had a a body with=20 >>>> an unknown MIME type and no content-disposition? >>> >>> The alternative is having cases where different people make different=20 >>> assumptions, so that the same transaction is sometimes rejected, and=20 >>> sometimes not, depending on what UAS the request reaches. That is not=20 >>> good, and makes it impossible to write specifications etc. >> >>Sure--but is that what we want it to do? It almost seems to me that if th= e sender wants the body part to be "required", it can say so. Is there a re= asonable "success friendly" option here? >> >If the answer to that requires thought or discussion, then maybe this shou= ld go in a draft, not an eratta. I can put everything in a draft, if that's what people prefer. >>>> The change from SHOULD to MUST second guesses the original intent. I=20 >>>> don't think we have a reason to think people really meant to write=20 >>>> MUST. >>>> Rather, I think this is more a (potentially reasonable) change in=20 >>>> expectations between then and now. Also, list discussion on that=20 >>>> point did not seem conclusive. It seem to me that if people want to=20 >>>> make that change, it needs to be in the form of an update. >>> >>> I am ok to leave the "SHOULD->MUST" part outside the errata, and=20 >>> handle that in an update. >>> >>>> Christer, you mentioned that this is causing deployment problems. Can= =20 >>>> you elaborate on the nature of those problems? >>> >>> Yes. Unfortunately I can't give any company names, so I'll call them=20 >>> company X and company Y. >>> >>> - Company X UA sends a SIP request with a message body (I don't=20 >>> remember the MIME type, but it doesn't really matter - it is not SDP), >>> *WITHOUT* a C-D header field. >>> - Company Y UA does NOT support the MIME type, and assumes that the=20 >>> absence of C-D means handling=3D"required". So, company Y rejects the=20 >>> request. >>> - Company X claims that it is wrong behavior to reject the request,=20 >>> because since there is no C-D header field one should not assume=20 >>> handling=3D"required". Instead, the company Y UA should simply discard= =20 >>> the message body. >>> - Company Y claims that the absence of C-D means handling=3D"required",= =20 >>> and that rejecting the request is correct behavior. >>> >>> This is causing a serious amount of call failures in existing=20 >>> deployments, and has been escalated up the ladders. >> >> Sounds like a default to "required" will cause even more call failures.= =20 Whoever company is "proven wrong" is expected to fix their deployments, as = they can no longer put the blame on the other. The problem is that it is cu= rrently not possible to agree on who is wrong (read: who will have to spend= resources on fixing their equipment :). > I guess you might could use that as a lever to force Company X to insert = C-D. Is that the preferred outcome? It doesn't work like that. Company X (and Y) will only fix their equipment = if they are proven wrong :) Regards, Christer From nobody Tue Dec 8 06:35:53 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 F27771B2E95 for ; Tue, 8 Dec 2015 06:35:51 -0800 (PST) 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 x-GbF_P7AgsY for ; Tue, 8 Dec 2015 06:35:50 -0800 (PST) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EAEF1B2E91 for ; Tue, 8 Dec 2015 06:35:50 -0800 (PST) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-01v.sys.comcast.net with comcast id r2bH1r0022Qkjl9012bpxG; Tue, 08 Dec 2015 14:35:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-15v.sys.comcast.net with comcast id r2bp1r00D3KdFy1012bpQW; Tue, 08 Dec 2015 14:35:49 +0000 To: sipcore@ietf.org References: <20151204140645.77D7B180004@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37C8372C@ESESSMB209.ericsson.se> <56635188.40009@nostrum.com> <6CF3A5B1-90E7-4F50-8424-0315287BB712@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C8B0E1@ESESSMB209.ericsson.se> <9FFEF072-6575-4FB8-8C80-E850F43F9BD6@nostrum.com> From: Paul Kyzivat Message-ID: <5666EAC4.1040601@alum.mit.edu> Date: Tue, 8 Dec 2015 09:35:48 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <9FFEF072-6575-4FB8-8C80-E850F43F9BD6@nostrum.com> 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=1449585349; bh=13ISiQwFcpNPcniHyjZdRd4FT8zms1CqxqS8rp4WnOg=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=aep6kCDOakiWr/sfCMmM5Z0ylF6NN0A1OpmcYL0kc3v8G0zAAyk3nFennE9OQvNdo VHoCFU4RhR1aFFQY2Uf/LLrmB1gqnDm6zsMG6cgGf6wXpH5My+jr9hTWlE8wNxqTi9 Zk8pcaTMoVZJvZ8HEImSMjPNSg1bn1NIbGiOklv95VSLDfYSp37Y13LolREesEvtCq izmmFNe4ObIIxDvPPV9rijMnj7t2uCvROhW+0F6gsce9HaDEvI7rNM/FiZPMmqBC2g Za2TOgriVhAlFHsPPaO+SzPAlEAksGpA+CdN5UOGQfYTiwYHPAelDTwFFrYyKj+WLm eNSUr3PwtSixw== Archived-At: Subject: Re: [sipcore] [Technical Errata Reported] RFC3261 (4553) 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, 08 Dec 2015 14:35:52 -0000 I guess Ben's argument here is that there is a straightforward work-around (insert a C-D rather than depending on the default) that is entirely compliant to the standards and will fix the interop problem. That still leaves an issue that ought to be resolved, but it reduces the urgency of addressing it. Thanks, Paul On 12/8/15 9:11 AM, Ben Campbell wrote: > > > On 8 Dec 2015, at 1:33, Christer Holmberg wrote: > >> Hi, >> >>> I am inclined to mark this, as submitted, as "hold for update", which >>> I suspect is not what Christer wants to hear. >> >> Correct :) >> >>> There are two parts to this: >>> >>> Adding "or if the Content-Disposition header field is missing" seems >>> reasonable. I have trouble imagining that the original intent was not >>> exactly that. But I would like to >>> see a bit more discussion about whether this is likely to cause >>> unnecessary transaction failure. Would we expect the UAS to reject >>> any request that had a a body with an >>> unknown MIME type and no content-disposition? >> >> The alternative is having cases where different people make different >> assumptions, so that the same transaction is sometimes rejected, and >> sometimes not, depending on what UAS the request reaches. That is not >> good, and makes it impossible to write specifications etc. > > Sure--but is that what we want it to do? It almost seems to me that if > the sender wants the body part to be "required", it can say so. Is there > a reasonable "success friendly" option here? > > If the answer to that requires thought or discussion, then maybe this > should go in a draft, not an eratta. > >> >>> The change from SHOULD to MUST second guesses the original intent. I >>> don't think we have a reason to think people really meant to write MUST. >>> Rather, I think this is more a (potentially reasonable) change in >>> expectations between then and now. Also, list discussion on that >>> point did not seem conclusive. It seem to me that if people want to >>> make that change, it needs to be in the form of an update. >> >> I am ok to leave the "SHOULD->MUST" part outside the errata, and >> handle that in an update. >> >>> Christer, you mentioned that this is causing deployment problems. Can >>> you elaborate on the nature of those problems? >> >> Yes. Unfortunately I can't give any company names, so I'll call them >> company X and company Y. >> >> - Company X UA sends a SIP request with a message body (I don't >> remember the MIME type, but it doesn't really matter - it is not SDP), >> *WITHOUT* a C-D header field. >> - Company Y UA does NOT support the MIME type, and assumes that the >> absence of C-D means handling="required". So, company Y rejects the >> request. >> - Company X claims that it is wrong behavior to reject the request, >> because since there is no C-D header field one should not assume >> handling="required". Instead, the company Y UA should simply discard >> the message body. >> - Company Y claims that the absence of C-D means handling="required", >> and that rejecting the request is correct behavior. >> >> This is causing a serious amount of call failures in existing >> deployments, and has been escalated up the ladders. > > Sounds like a default to "required" will cause even more call failures. > I guess you might could use that as a lever to force Company X to insert > C-D. Is that the preferred outcome? > >> >> Sure, company X and Y could perhaps agree on some fix to handle this. >> But, later the same issue may later pop up somewhere else. The spec >> needs to be clear on this, since we are talking about a case that can >> cause a SIP INVITE request to be rejected. >> >> Regards, >> >> Christer >> >> >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Dec 10 02:47: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 3B2771A8A87 for ; Thu, 10 Dec 2015 02:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11gMwA5Ld7dq for ; Thu, 10 Dec 2015 02:47:43 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7BD61A8A77 for ; Thu, 10 Dec 2015 02:47:42 -0800 (PST) X-AuditID: c1b4fb25-f79876d0000011ee-ff-5669584cafa5 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E9.02.04590.C4859665; Thu, 10 Dec 2015 11:47:41 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0248.002; Thu, 10 Dec 2015 11:47:40 +0100 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "A. Jean Mahoney" , "Ben Campbell" Thread-Topic: [sipcore] RSeq and forking - Errata Thread-Index: AdCjwjb6aIhPA9HcRsaaDgKN4yT4tAG3gD/g///pywD//9iRUIAU+dAA//9WNoCAEf+lAIAADcgAgAAA4oCAASKMAP+ewsGQGbQTAoD//9WhMP//yj+A//9vwbD/gYZk8A== Date: Thu, 10 Dec 2015 10:47:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C935B7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F33B4@ESESSMB209.ericsson.se> <55843746.1070907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D8F35A0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D908280@ESESSMB209.ericsson.se> <55A44506.3090209@alum.mit.edu> <4327D8C7-211A-439C-A3DE-012FC094B517@nostrum.com> <55A5397E.6050804@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37A7B565@ESESSMB209.ericsson.se> <560025A7.7060207@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37AC784A@ESESSMB209.ericsson.se> <56002F33.8060802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37AC7A3F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37AC7A3F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7nK5vRGaYwb0ZTBbzO0+zWzR0rmS1 WLHhAKvF1x+b2BxYPP6+/8DksWTJTyaPWTufsAQwR3HZpKTmZJalFunbJXBl/Oz8x1xwPbSi /8gV9gbGD05djJwcEgImEh1L9jNB2GISF+6tZ+ti5OIQEjjMKNH9/xgLhLOEUeLursmMXYwc HGwCFhLd/7RB4iICqxklzk06xgrSzSygKfFo516wScICBhI/vrxgAbFFBAwlTp5oZ4FomMQo sf7iTUaQBIuAqsSx28eZQWxeAV+J5ccms0JsW8smcWTlJXaQBKeAn8S9pX/ZQGxGoPu+n1rD BLFNXOLWk/lQdwtILNlznhnCFpV4+fgfK8ilEgKKEsv75SDK9SRuTJ3CBmFrSyxb+Bpqr6DE yZlPWCYwis1CMnUWkpZZSFpmIWlZwMiyilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMwwg5u +a26g/HyG8dDjAIcjEo8vB+UMsOEWBPLiitzDzFKcDArifCucQMK8aYkVlalFuXHF5XmpBYf YpTmYFES521mehAqJJCeWJKanZpakFoEk2Xi4JRqYHTf8mztMbmNs6u0oioPXCwPVz1/NqZm 167YZc9r2VcaPhSof5/A7SNy6njiREtplqOWz1Kbk7Kvvo/ZXcXS5zBHfM7HuIA3n3Si1hot 0ux9OXeh1cnn68/+unSlxlF4KuscS+ctyX3m3DPb7tkelpnuEs7h61ZxX3+ymVu15MIw6b+y FXeebFBiKc5INNRiLipOBAB+mVh/rAIAAA== Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 10:47:46 -0000 Any comments on this? I'd like to move this forward, because it is also cau= sing deployment issues. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 21. syyskuuta 2015 19:37 To: Paul Kyzivat; A. Jean Mahoney; Ben Campbell Cc: sipcore@ietf.org Subject: Re: [sipcore] RSeq and forking - Errata Hi, >> I'll take a closer look at your suggested changes later, but please=20 >> note that the text in section 4 talks about *initial* request. Should we= remove 'initial', in order to make it clear that the text also applies to = re-INVITEs? > > I think "initial" request was a poor choice with the document was=20 > written. But that usage pervades the document. I don't think it makes sen= se to change it in this one place. If we were to do a bis then I would be i= nclined to rework it throughout. Some instances of "initial" would stay, because they refer to the initial s= equence number value - not the initial request. Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 21 September 2015 18:44 > To: Christer Holmberg ; A. Jean=20 > Mahoney ; Ben Campbell > Cc: sipcore@ietf.org > Subject: Re: [sipcore] RSeq and forking - Errata > > I just went back and reviewed 3262 again. > > The paragraph in question, and the few preceding it, say they apply to an= "initial request". So we should verify exactly what that is intended to me= an. (I was thinking it might mean the INVITE that establishes a dialog, but= I'm not sure of that.) I searched back, and found the following in section= 3: > > "A UAS MAY send any non-100 provisional response to INVITE reliably, > so long as the initial INVITE request (the request whose provisional > response is being sent reliably) ..." > > So I think this in intended to apply to both the dialog-establishing INVI= TE and any re-INVITEs within the dialog that contains Supported:100rel. > > So, back to the questionable text in section 4 ... > > My concern is with the state the the UAC must maintain. The preceding par= agraph talks about the state. I propose changing it as follows: > > OLD: > > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission whe= n > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain a sequence number that indicates the most recently > received in-order reliable provisional response for the initial > request. This sequence number MUST be maintained until a final > response is received for the initial request. Its value MUST be > initialized to the RSeq header field in the first reliable > provisional response received for the initial request. > > NEW: > > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission whe= n > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain<<, independently for each dialog ID,>> a sequence > number that indicates the most recently received in-order reliable > provisional response for the initial request. This sequence number > MUST be maintained until a final response is received for the initia= l > request. Its value MUST be initialized to the RSeq header field in > the first reliable provisional response received for the initial > request<< in a dialog>>. > > (I highlighted the changes with << >>.) > > Then the following paragraph also needs to be adjusted, because it neglec= ted to specify that the state needs to be updated for successful subsequent= provisional responses: > > OLD: > > Handling of subsequent reliable provisional responses for the same > initial request follows the same rules as above, with the following > difference: reliable provisional responses are guaranteed to be in > order. As a result, if the UAC receives another reliable provisiona= l > response to the same request, and its RSeq value is not one higher > than the value of the sequence number, that response MUST NOT be > acknowledged with a PRACK, and MUST NOT be processed further by the > UAC. An implementation MAY discard the response, or MAY cache the > response in the hopes of receiving the missing responses. > > NEW: > > Subsequent reliable provisional responses for the same initial > request are guaranteed to be in order. If the UAC receives another > reliable provisional response to the same request, and its RSeq > value is one higher than the value of the previously received RSeq > value in the dialog, then the new RSeq value is saved and the > response is handled as described above. If the RSeq value is not one > higher than the value of the sequence number, that response MUST NOT > be acknowledged with a PRACK, and MUST NOT be processed further by > the UAC. An implementation MAY discard the response, or MAY cache > the response in the hopes of receiving the missing responses. > > The changes were too extensive to highlight. I think this is clearer abou= t what is intended. > > Thanks, > Paul > > > On 9/14/15 7:47 AM, Christer Holmberg wrote: >> Hi, >> >> We were going to continue this discussion after Prague, so here we go >> :) >> >> The issue was that currently the text does not make it clear that, when = a request is forked, the scope of the RSeq value is per individual fork. >> >> As far as I know, there was no objection to the issue as such. However, = people did not think the suggested text was good enough. >> >> The original text (Section 4 of RFC 3262) says: >> >> "Handling of subsequent reliable provisional responses for the same >> initial request follows the same rules as above, with the following >> difference: reliable provisional responses are guaranteed to be in >> order. As a result, if the UAC receives another reliable provision= al >> response to the same request, and its RSeq value is not one higher >> than the value of the sequence number, that response MUST NOT be >> acknowledged with a PRACK, and MUST NOT be processed further by the >> UAC. An implementation MAY discard the response, or MAY cache the >> response in the hopes of receiving the missing responses." >> >> >> In the previous Errata, the suggested correction text was: >> >> >> "Handling of subsequent reliable provisional responses for the sam= e >> initial request follows the same rules as above, with the following >> difference: reliable provisional responses are guaranteed to be in >> order. As a result, if the UAC receives another reliable provision= al >> response to the same request on a given dialog, and its RSeq value = is >> not one higher than the value of the sequence number, that response >> MUST NOT be acknowledged with a PRACK, and MUST NOT be processed >> further by the UAC. An implementation MAY discard the response, o= r >> MAY cache the response in the hopes of receiving the missing >> responses. If forking occurs, RSeq values are processed on each ear= ly >> dialog independently." >> >> >> Paul said: >> >> "Note that the scope of RSeq values is a single INVITE transaction,=20 >> not a dialog. (So, for a re-INVITE in the same dialog the RSeq value=20 >> might turn out to be lower than that for the INVITE that established=20 >> the dialog.) >> >> But that value space is owned by the UAS for the INVITE. So, from the pe= rspective of the sender of the INVITE (receiver of provisional responses), = the value space must be managed independently for the combination of INVITE= transaction AND dialog id. So the required logic is somewhat different tha= n what is required for CSeq." >> >> Comments? >> >> Regards, >> >> Christer >> >> >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of A. Jean=20 >> Mahoney >> Sent: 14. hein=E4kuuta 2015 19:32 >> To: Ben Campbell; Paul Kyzivat >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] RSeq and forking - Errata >> >> On 7/13/15 6:12 PM, Ben Campbell wrote: >>> On 13 Jul 2015, at 18:08, Paul Kyzivat wrote: >>> >>>> On 7/13/15 6:19 PM, Ben Campbell wrote: >>>>> >>>>> >>>>> On 3 Jul 2015, at 0:46, Christer Holmberg wrote: >>>>> >>>>>> Hi Ben, >>>>>> >>>>>> Assuming we have to submit a new errata in order to do the word=20 >>>>>> smiting, I guess rejecting the current one is the way forward. >>>>>> Nobody has objected to the correction as such. >>>>> >>>>> "word smiting" is a wonderful typo for this. I'm going to use that=20 >>>>> one :-) >>>>> >>>>> Rejecting it is not absolutely necessary to edit the wording, but=20 >>>>> I think it may be the right thing to do here [see below] >>>>> >>>>>> >>>>>> However, I guess we should then on the list should agree on the=20 >>>>>> actual text, before submitting a new errata. >>>>> >>>>> I agree. But after reading the discussion so far (especially=20 >>>>> Paul's comment), I'm not sure if this is a simple fix, or if it=20 >>>>> needs more thought. Therefore I'm going to reject the errata as it=20 >>>>> currently stands. I'd like to see the working group discuss the corre= ct fix. >>>>> If that turns out to be an errata, we can submit that one when=20 >>>>> it's agreed upon. If it turns out to be something else, we can=20 >>>>> cross that bridge when we come to it. >>>> >>>> Do we want to start that discussion *now*? Or wait until after the=20 >>>> meeting? >>>> >>>> While sipcore isn't meeting, most of the sipcore regulars are=20 >>>> probably concentrating on things that *will* be going on at the=20 >>>> meeting. So I'm inclined to think it would be better to wait about=20 >>>> a month before starting the discussion. >>> >>> I will leave that to the chairs, but I don't think the world is=20 >>> going to end if it waits a few weeks. >> >> It's OK with the chairs to hold off discussing this topic until after Pr= ague. >> >> Jean >> >>> >>> Ben. >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Dec 10 07:37:02 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257551A0047 for ; Thu, 10 Dec 2015 07:37:02 -0800 (PST) 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 16NEdIWPrvLJ for ; Thu, 10 Dec 2015 07:36:59 -0800 (PST) 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 B94A41A0089 for ; Thu, 10 Dec 2015 07:36:57 -0800 (PST) Received: from mutabilis-2.local (pool-173-57-210-37.dllstx.fios.verizon.net [173.57.210.37]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBAFaqNE070712 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 10 Dec 2015 09:36:52 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-210-37.dllstx.fios.verizon.net [173.57.210.37] claimed to be mutabilis-2.local To: Christer Holmberg , Paul Kyzivat , Ben Campbell References: <7594FB04B1934943A5C02806D1A2204B1D8B8CA2@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D8F33B4@ESESSMB209.ericsson.se> <55843746.1070907@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D8F35A0@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D908280@ESESSMB209.ericsson.se> <55A44506.3090209@alum.mit.edu> <4327D8C7-211A-439C-A3DE-012FC094B517@nostrum.com> <55A5397E.6050804@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37A7B565@ESESSMB209.ericsson.se> <560025A7.7060207@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37AC784A@ESESSMB209.ericsson.se> <56002F33.8060802@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37AC7A3F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37C935B7@ESESSMB209.ericsson.se> From: "A. Jean Mahoney" Message-ID: <56699C0E.4070800@nostrum.com> Date: Thu, 10 Dec 2015 09:36:46 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C935B7@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 15:37:02 -0000 Hi Christer, On 12/10/15 4:47 AM, Christer Holmberg wrote: > Any comments on this? I'd like to move this forward, because it is > also causing deployment issues. > > Regards, > > Christer > > -----Original Message----- From: sipcore > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 21. syyskuuta 2015 19:37 To: Paul Kyzivat; A. Jean Mahoney; Ben > Campbell Cc: sipcore@ietf.org Subject: Re: [sipcore] RSeq and forking > - Errata > > Hi, > >>> I'll take a closer look at your suggested changes later, but Were you ok with Paul's proposed text? Your response above indicated that you might have had additional feedback after you looked at it some more. Thanks, Jean >>> please note that the text in section 4 talks about *initial* >>> request. Should we remove 'initial', in order to make it clear >>> that the text also applies to re-INVITEs? >> >> I think "initial" request was a poor choice with the document was >> written. But that usage pervades the document. I don't think it >> makes sense to change it in this one place. If we were to do a bis >> then I would be inclined to rework it throughout. > > Some instances of "initial" would stay, because they refer to the > initial sequence number value - not the initial request. > > Regards, > > Christer > > > >> -----Original Message----- From: Paul Kyzivat >> [mailto:pkyzivat@alum.mit.edu] Sent: 21 September 2015 18:44 To: >> Christer Holmberg ; A. Jean Mahoney >> ; Ben Campbell Cc: >> sipcore@ietf.org Subject: Re: [sipcore] RSeq and forking - Errata >> >> I just went back and reviewed 3262 again. >> >> The paragraph in question, and the few preceding it, say they apply >> to an "initial request". So we should verify exactly what that is >> intended to mean. (I was thinking it might mean the INVITE that >> establishes a dialog, but I'm not sure of that.) I searched back, >> and found the following in section 3: >> >> "A UAS MAY send any non-100 provisional response to INVITE >> reliably, so long as the initial INVITE request (the request whose >> provisional response is being sent reliably) ..." >> >> So I think this in intended to apply to both the >> dialog-establishing INVITE and any re-INVITEs within the dialog >> that contains Supported:100rel. >> >> So, back to the questionable text in section 4 ... >> >> My concern is with the state the the UAC must maintain. The >> preceding paragraph talks about the state. I propose changing it as >> follows: >> >> OLD: >> >> Once a reliable provisional response is received, retransmissions >> of that response MUST be discarded. A response is a retransmission >> when its dialog ID, CSeq, and RSeq match the original response. >> The UAC MUST maintain a sequence number that indicates the most >> recently received in-order reliable provisional response for the >> initial request. This sequence number MUST be maintained until a >> final response is received for the initial request. Its value MUST >> be initialized to the RSeq header field in the first reliable >> provisional response received for the initial request. >> >> NEW: >> >> Once a reliable provisional response is received, retransmissions >> of that response MUST be discarded. A response is a retransmission >> when its dialog ID, CSeq, and RSeq match the original response. >> The UAC MUST maintain<<, independently for each dialog ID,>> a >> sequence number that indicates the most recently received in-order >> reliable provisional response for the initial request. This >> sequence number MUST be maintained until a final response is >> received for the initial request. Its value MUST be initialized to >> the RSeq header field in the first reliable provisional response >> received for the initial request<< in a dialog>>. >> >> (I highlighted the changes with << >>.) >> >> Then the following paragraph also needs to be adjusted, because it >> neglected to specify that the state needs to be updated for >> successful subsequent provisional responses: >> >> OLD: >> >> Handling of subsequent reliable provisional responses for the same >> initial request follows the same rules as above, with the >> following difference: reliable provisional responses are guaranteed >> to be in order. As a result, if the UAC receives another reliable >> provisional response to the same request, and its RSeq value is not >> one higher than the value of the sequence number, that response >> MUST NOT be acknowledged with a PRACK, and MUST NOT be processed >> further by the UAC. An implementation MAY discard the response, or >> MAY cache the response in the hopes of receiving the missing >> responses. >> >> NEW: >> >> Subsequent reliable provisional responses for the same initial >> request are guaranteed to be in order. If the UAC receives >> another reliable provisional response to the same request, and its >> RSeq value is one higher than the value of the previously received >> RSeq value in the dialog, then the new RSeq value is saved and the >> response is handled as described above. If the RSeq value is not >> one higher than the value of the sequence number, that response >> MUST NOT be acknowledged with a PRACK, and MUST NOT be processed >> further by the UAC. An implementation MAY discard the response, or >> MAY cache the response in the hopes of receiving the missing >> responses. >> >> The changes were too extensive to highlight. I think this is >> clearer about what is intended. >> >> Thanks, Paul >> >> >> On 9/14/15 7:47 AM, Christer Holmberg wrote: >>> Hi, >>> >>> We were going to continue this discussion after Prague, so here >>> we go :) >>> >>> The issue was that currently the text does not make it clear >>> that, when a request is forked, the scope of the RSeq value is >>> per individual fork. >>> >>> As far as I know, there was no objection to the issue as such. >>> However, people did not think the suggested text was good >>> enough. >>> >>> The original text (Section 4 of RFC 3262) says: >>> >>> "Handling of subsequent reliable provisional responses for the >>> same initial request follows the same rules as above, with the >>> following difference: reliable provisional responses are >>> guaranteed to be in order. As a result, if the UAC receives >>> another reliable provisional response to the same request, and >>> its RSeq value is not one higher than the value of the sequence >>> number, that response MUST NOT be acknowledged with a PRACK, and >>> MUST NOT be processed further by the UAC. An implementation MAY >>> discard the response, or MAY cache the response in the hopes of >>> receiving the missing responses." >>> >>> >>> In the previous Errata, the suggested correction text was: >>> >>> >>> "Handling of subsequent reliable provisional responses for the >>> same initial request follows the same rules as above, with the >>> following difference: reliable provisional responses are >>> guaranteed to be in order. As a result, if the UAC receives >>> another reliable provisional response to the same request on a >>> given dialog, and its RSeq value is not one higher than the value >>> of the sequence number, that response MUST NOT be acknowledged >>> with a PRACK, and MUST NOT be processed further by the UAC. An >>> implementation MAY discard the response, or MAY cache the >>> response in the hopes of receiving the missing responses. If >>> forking occurs, RSeq values are processed on each early dialog >>> independently." >>> >>> >>> Paul said: >>> >>> "Note that the scope of RSeq values is a single INVITE >>> transaction, not a dialog. (So, for a re-INVITE in the same >>> dialog the RSeq value might turn out to be lower than that for >>> the INVITE that established the dialog.) >>> >>> But that value space is owned by the UAS for the INVITE. So, from >>> the perspective of the sender of the INVITE (receiver of >>> provisional responses), the value space must be managed >>> independently for the combination of INVITE transaction AND >>> dialog id. So the required logic is somewhat different than what >>> is required for CSeq." >>> >>> Comments? >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> -----Original Message----- From: sipcore >>> [mailto:sipcore-bounces@ietf.org] On Behalf Of A. Jean Mahoney >>> Sent: 14. heinäkuuta 2015 19:32 To: Ben Campbell; Paul Kyzivat >>> Cc: sipcore@ietf.org Subject: Re: [sipcore] RSeq and forking - >>> Errata >>> >>> On 7/13/15 6:12 PM, Ben Campbell wrote: >>>> On 13 Jul 2015, at 18:08, Paul Kyzivat wrote: >>>> >>>>> On 7/13/15 6:19 PM, Ben Campbell wrote: >>>>>> >>>>>> >>>>>> On 3 Jul 2015, at 0:46, Christer Holmberg wrote: >>>>>> >>>>>>> Hi Ben, >>>>>>> >>>>>>> Assuming we have to submit a new errata in order to do >>>>>>> the word smiting, I guess rejecting the current one is >>>>>>> the way forward. Nobody has objected to the correction as >>>>>>> such. >>>>>> >>>>>> "word smiting" is a wonderful typo for this. I'm going to >>>>>> use that one :-) >>>>>> >>>>>> Rejecting it is not absolutely necessary to edit the >>>>>> wording, but I think it may be the right thing to do here >>>>>> [see below] >>>>>> >>>>>>> >>>>>>> However, I guess we should then on the list should agree >>>>>>> on the actual text, before submitting a new errata. >>>>>> >>>>>> I agree. But after reading the discussion so far >>>>>> (especially Paul's comment), I'm not sure if this is a >>>>>> simple fix, or if it needs more thought. Therefore I'm >>>>>> going to reject the errata as it currently stands. I'd like >>>>>> to see the working group discuss the correct fix. If that >>>>>> turns out to be an errata, we can submit that one when it's >>>>>> agreed upon. If it turns out to be something else, we can >>>>>> cross that bridge when we come to it. >>>>> >>>>> Do we want to start that discussion *now*? Or wait until >>>>> after the meeting? >>>>> >>>>> While sipcore isn't meeting, most of the sipcore regulars >>>>> are probably concentrating on things that *will* be going on >>>>> at the meeting. So I'm inclined to think it would be better >>>>> to wait about a month before starting the discussion. >>>> >>>> I will leave that to the chairs, but I don't think the world >>>> is going to end if it waits a few weeks. >>> >>> It's OK with the chairs to hold off discussing this topic until >>> after Prague. >>> >>> Jean >>> >>>> >>>> Ben. >>>> >>>> _______________________________________________ sipcore mailing >>>> list sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> _______________________________________________ sipcore mailing >>> list sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> >> > > _______________________________________________ sipcore mailing list > sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Dec 10 11:43:42 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D631B29D1 for ; Thu, 10 Dec 2015 11:43:40 -0800 (PST) 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 DAzyHFkHiimO for ; Thu, 10 Dec 2015 11:43:38 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AF7A1B29D7 for ; Thu, 10 Dec 2015 11:43:24 -0800 (PST) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-05v.sys.comcast.net with comcast id rvix1r0042Udklx01vjPtx; Thu, 10 Dec 2015 19:43:23 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-18v.sys.comcast.net with comcast id rvjN1r00B1nMCLR01vjNMs; Thu, 10 Dec 2015 19:43:23 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id tBAJhL15026200; Thu, 10 Dec 2015 14:43:21 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id tBAJhLuV026197; Thu, 10 Dec 2015 14:43:21 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg , pkyzivat@alum.mit.edu, mahoney@nostrum.com, ben@nostrum.com, sipcore@ietf.org In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C935B7@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 10 Dec 2015 14:43:20 -0500 Message-ID: <87egeu6qef.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1449776603; bh=3pamnUDfSspMPqWMs0PDdvJBFv/ms8mg+CgSphoIMvg=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=qbQr8jHMfaosozJOCeSW457Fv1xyNucmxSB3SzngrPZzt/Dd2c5SMfIyahcdm4X2K TeeI7aOO+znXy/K2Tm+OxgZ78u/dzS6Jc/uDgWwSHql+1kCoIl1OUShjgpcBcWb9Hq TDMbXyN+Ebbv6nF+EhbN1f933uyxVHsqrBDhXd/n6HQDaSKd362Cp+t/+ZtgIWXPm3 vW3Cu5KgG+GdLO74GVrViS4sVNcaRp63jmMxMJb58OBbAQU/qPxcaJmCV2IFHbLOOW lpGomsYj04RgNHEBfreERy/QgQZ3yQmRDWatIiBlEK7Z0gtJUEE0QsaTC7OyV8CvDR yNV1hSCBNU2kw== Archived-At: Subject: Re: [sipcore] RSeq and forking - Errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 19:43:40 -0000 1. Responses to issues others have raised > The paragraph in question, and the few preceding it, say they apply > to an "initial request". So we should verify exactly what that is > intended to mean. (I was thinking it might mean the INVITE that > establishes a dialog, but I'm not sure of that.) I searched back, > and found the following in section 3: > > "A UAS MAY send any non-100 provisional response to INVITE reliably, > so long as the initial INVITE request (the request whose provisional > response is being sent reliably) ..." > > So I think this in intended to apply to both the dialog-establishing > INVITE and any re-INVITEs within the dialog that contains > Supported:100rel. That is my reading, that sentence defines "initial request" to mean the request that starts the transaction within which PRACK is used, and it need not be the first request of the dialog. "Initial" isn't a particularly good word choice there; presumably it refers to the first transmission of the request as opposed to any retransmissions. Note that the UAS may send non-100 provisional responses if the request contains "Require: 100rel" even if it doesn't contain "Supported: 100rel"; "Require" implies "Supported". > The issue was that currently the text does not make it clear that, > when a request is forked, the scope of the RSeq value is per > individual fork. IMO, the text does require that the RSeq value is per-fork: RSeq numbering space is within a single transaction. This means that provisional responses for different requests MAY use the same values for the RSeq number. and A response is a retransmission when its dialog ID, CSeq, and RSeq match the original response. where "dialog ID" is defined in RFC 3261, "A dialog is identified at each UA with a dialog ID, which consists of a Call-ID value, a local tag and a remote tag." It's well-known, though not well-documented, that each fork of a request is a separate transaction. E.g., the UAC transaction state machine must be cloned for every distinct to-tag seen in a response. However, there is benefit from making the text clearer on this point. 2. Additional wording issues There are a few places in section 4 where the wording is confusing. This section is written from the point of view of the UAC, but some of the wording seems to be written from the point of view of the UAS. If a provisional response is received for an initial request, and that response contains a Require header field containing the option tag 100rel, the response is to be sent reliably. which means "... the response was sent by the UAS reliably". Assuming the response is to be transmitted reliably, the UAC MUST create a new request with method PRACK. which means "Assuming the response was transmitted reliably by the UAS ...". Handling of subsequent reliable provisional responses for the same initial request follows the same rules as above, with the following difference: reliable provisional responses are guaranteed to be in order. which means "reliable provisional responses are guaranteed to have been generated by the UAS in the order of their RSeq values and must be acknowledged in that order". An implementation MAY discard the response, or MAY cache the response in the hopes of receiving the missing responses. which should add "... cache the response and acknowledge it after the responses with the intermediate RSeq values are received". 3. Some proposed changes Let me propose these changes, which include Paul's proposal of 21 Sep: (I've highlighted changes with << >>.) Section 3: OLD: The provisional response to be sent reliably is constructed by the UAS core according to the procedures of Section 8.2.6 of RFC 3261. In addition, it MUST contain a Require header field containing the option tag 100rel, and MUST include an RSeq header field. The value of the header field for the first reliable provisional response in a transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that it be chosen uniformly in this range. The RSeq numbering space is within a single transaction. This means that provisional responses for different requests MAY use the same values for the RSeq number. NEW: The provisional response to be sent reliably is constructed by the UAS core according to the procedures of Section 8.2.6 of RFC 3261. In addition, it MUST contain a Require header field containing the option tag 100rel, and MUST include an RSeq header field. The value of the header field for the first reliable provisional response in a transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that it be chosen uniformly in this range. The RSeq numbering space is within a single transaction <>. This means that provisional responses for different requests<<, and forks of a request within different dialogs,>> MAY use the same values for the RSeq number. Section 4: OLD: If a provisional response is received for an initial request, and that response contains a Require header field containing the option tag 100rel, the response is to be sent reliably. If the response is a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be ignored, and the procedures below MUST NOT be used. NEW: If a provisional response is received for an initial request, and that response contains a Require header field containing the option tag 100rel, the response <>. If the response is a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be ignored, and the procedures below MUST NOT be used. OLD: Assuming the response is to be transmitted reliably, the UAC MUST create a new request with method PRACK. This request is sent within the dialog associated with the provisional response (indeed, the provisional response may have created the dialog). PRACK requests MAY contain bodies, which are interpreted according to their type and disposition. NEW: Assuming the response <>, the UAC MUST create a new request with method PRACK. This request is sent within the dialog associated with the provisional response (indeed, the provisional response may have created the dialog). PRACK requests MAY contain bodies, which are interpreted according to their type and disposition. This change is from Paul's e-mail: OLD: Once a reliable provisional response is received, retransmissions of that response MUST be discarded. A response is a retransmission when its dialog ID, CSeq, and RSeq match the original response. The UAC MUST maintain a sequence number that indicates the most recently received in-order reliable provisional response for the initial request. This sequence number MUST be maintained until a final response is received for the initial request. Its value MUST be initialized to the RSeq header field in the first reliable provisional response received for the initial request. NEW: Once a reliable provisional response is received, retransmissions of that response MUST be discarded. A response is a retransmission when its dialog ID, CSeq, and RSeq match the original response. The UAC MUST maintain<<, independently for each dialog ID,>> a sequence number that indicates the most recently received in-order reliable provisional response for the initial request. This sequence number MUST be maintained until a final response is received for the initial request. Its value MUST be initialized to the RSeq header field in the first reliable provisional response received for the initial request<< in a dialog>>. This includes the changes in Paul's e-mail, with my additional changes marked with << >>: OLD: Handling of subsequent reliable provisional responses for the same initial request follows the same rules as above, with the following difference: reliable provisional responses are guaranteed to be in order. As a result, if the UAC receives another reliable provisional response to the same request, and its RSeq value is not one higher than the value of the sequence number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache the response in the hopes of receiving the missing responses. NEW: Subsequent reliable provisional responses for the same initial request are guaranteed <>. As a result, if the UAC receives another reliable provisional response to the same request, and its RSeq value is one higher than the value of the previously received RSeq value in the dialog, then the new RSeq value is saved and the response is handled as described above. If the RSeq value is not one higher than the value of the sequence number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache the response <> after receiving the missing responses. Dale From nobody Thu Dec 10 14:18:14 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 032C01ACE2D for ; Thu, 10 Dec 2015 14:18:12 -0800 (PST) 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 u6cGv34dZlFZ for ; Thu, 10 Dec 2015 14:18:09 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252571A6F51 for ; Thu, 10 Dec 2015 14:18:09 -0800 (PST) Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-05v.sys.comcast.net with comcast id ryHt1r0022AWL2D01yJ8eY; Thu, 10 Dec 2015 22:18:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-04v.sys.comcast.net with comcast id ryJ61r0073KdFy101yJ7yl; Thu, 10 Dec 2015 22:18:08 +0000 To: "Dale R. Worley" , Christer Holmberg , mahoney@nostrum.com, ben@nostrum.com, sipcore@ietf.org References: <87egeu6qef.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <5669FA1D.6060109@alum.mit.edu> Date: Thu, 10 Dec 2015 17:18:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <87egeu6qef.fsf@hobgoblin.ariadne.com> 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=1449785888; bh=NwcXFyoOqqGw15ZU+gm5L1N0CRCfDHIkpDOoiDIHgn4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=BMTMKd55dxju6jf251Ht0OrsqClIHW8tc2Aull4kDMAOgQNAvwolKuGkRG3vBelLj ojWlzcltEWpWI9+MZSAuQL/21vjrDbXDRm4Y7cvcjJRnbS8FPbEVHKRsaTxOPCw66L 8piQfcb+kkI9skZ87yqL00+sWuI/RCJXtxmnblXfX1jfboDhf8PcW45o67ly16ZC1N 8WX2STHPgzvxkb9vzI4OD/b4KUlR9N2SpU+37zbnofi8ePMcoyaW6AhVCDbi804flx t+rVbXl3GincsjtWzH2+ebFejsz0CJNHTnzUhiv7Gt28Rmj1Z+cU1+58Dn07An88nh L/7d5iaSX7KWQ== Archived-At: Subject: Re: [sipcore] RSeq and forking - Errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 22:18:12 -0000 WFM On 12/10/15 2:43 PM, Dale R. Worley wrote: > 1. Responses to issues others have raised > >> The paragraph in question, and the few preceding it, say they apply >> to an "initial request". So we should verify exactly what that is >> intended to mean. (I was thinking it might mean the INVITE that >> establishes a dialog, but I'm not sure of that.) I searched back, >> and found the following in section 3: >> >> "A UAS MAY send any non-100 provisional response to INVITE reliably, >> so long as the initial INVITE request (the request whose provisional >> response is being sent reliably) ..." >> >> So I think this in intended to apply to both the dialog-establishing >> INVITE and any re-INVITEs within the dialog that contains >> Supported:100rel. > > That is my reading, that sentence defines "initial request" to mean > the request that starts the transaction within which PRACK is used, > and it need not be the first request of the dialog. "Initial" isn't a > particularly good word choice there; presumably it refers to the first > transmission of the request as opposed to any retransmissions. > > Note that the UAS may send non-100 provisional responses if the > request contains "Require: 100rel" even if it doesn't contain > "Supported: 100rel"; "Require" implies "Supported". > >> The issue was that currently the text does not make it clear that, >> when a request is forked, the scope of the RSeq value is per >> individual fork. > > IMO, the text does require that the RSeq value is per-fork: > > RSeq numbering space is within a single transaction. This means > that provisional responses for different requests MAY use the same > values for the RSeq number. > > and > > A response is a retransmission when its dialog ID, CSeq, and RSeq > match the original response. > > where "dialog ID" is defined in RFC 3261, "A dialog is identified at > each UA with a dialog ID, which consists of a Call-ID value, a > local tag and a remote tag." > > It's well-known, though not well-documented, that each fork of a request > is a separate transaction. E.g., the UAC transaction state machine must > be cloned for every distinct to-tag seen in a response. However, there > is benefit from making the text clearer on this point. > > 2. Additional wording issues > > There are a few places in section 4 where the wording is confusing. > This section is written from the point of view of the UAC, but some of > the wording seems to be written from the point of view of the UAS. > > If a provisional response is received for an initial request, and > that response contains a Require header field containing the option > tag 100rel, the response is to be sent reliably. > > which means "... the response was sent by the UAS reliably". > > Assuming the response is to be transmitted reliably, the UAC MUST > create a new request with method PRACK. > > which means "Assuming the response was transmitted reliably by the > UAS ...". > > Handling of subsequent reliable provisional responses for the same > initial request follows the same rules as above, with the following > difference: reliable provisional responses are guaranteed to be in > order. > > which means "reliable provisional responses are guaranteed to have > been generated by the UAS in the order of their RSeq values and must > be acknowledged in that order". > > An implementation MAY discard the response, or MAY cache the > response in the hopes of receiving the missing responses. > > which should add "... cache the response and acknowledge it after the > responses with the intermediate RSeq values are received". > > 3. Some proposed changes > > Let me propose these changes, which include Paul's proposal of 21 Sep: > > (I've highlighted changes with << >>.) > > Section 3: > OLD: > The provisional response to be sent reliably is constructed by the > UAS core according to the procedures of Section 8.2.6 of RFC 3261. > In addition, it MUST contain a Require header field containing the > option tag 100rel, and MUST include an RSeq header field. The value > of the header field for the first reliable provisional response in a > transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that > it be chosen uniformly in this range. The RSeq numbering space is > within a single transaction. This means that provisional responses > for different requests MAY use the same values for the RSeq number. > > NEW: > The provisional response to be sent reliably is constructed by the > UAS core according to the procedures of Section 8.2.6 of RFC 3261. > In addition, it MUST contain a Require header field containing the > option tag 100rel, and MUST include an RSeq header field. The > value of the header field for the first reliable provisional > response in a transaction MUST be between 1 and 2**31 - 1. It is > RECOMMENDED that it be chosen uniformly in this range. The RSeq > numbering space is within a single transaction < dialog>>. This means that provisional responses for different > requests<<, and forks of a request within different dialogs,>> MAY > use the same values for the RSeq number. > > Section 4: > OLD: > If a provisional response is received for an initial request, and > that response contains a Require header field containing the option > tag 100rel, the response is to be sent reliably. If the response is > a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be > ignored, and the procedures below MUST NOT be used. > > NEW: > If a provisional response is received for an initial request, and > that response contains a Require header field containing the option > tag 100rel, the response <>. If the > response is a 100 (Trying) (as opposed to 101 to 199), this option > tag MUST be ignored, and the procedures below MUST NOT be used. > > OLD: > Assuming the response is to be transmitted reliably, the UAC MUST > create a new request with method PRACK. This request is sent within > the dialog associated with the provisional response (indeed, the > provisional response may have created the dialog). PRACK requests > MAY contain bodies, which are interpreted according to their type and > disposition. > > NEW: > Assuming the response <>, the UAC MUST > create a new request with method PRACK. This request is sent within > the dialog associated with the provisional response (indeed, the > provisional response may have created the dialog). PRACK requests > MAY contain bodies, which are interpreted according to their type and > disposition. > > This change is from Paul's e-mail: > OLD: > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission when > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain a sequence number that indicates the most recently > received in-order reliable provisional response for the initial > request. This sequence number MUST be maintained until a final > response is received for the initial request. Its value MUST be > initialized to the RSeq header field in the first reliable > provisional response received for the initial request. > > NEW: > > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission when > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain<<, independently for each dialog ID,>> a sequence > number that indicates the most recently received in-order reliable > provisional response for the initial request. This sequence number > MUST be maintained until a final response is received for the initial > request. Its value MUST be initialized to the RSeq header field in > the first reliable provisional response received for the initial > request<< in a dialog>>. > > This includes the changes in Paul's e-mail, with my additional changes > marked with << >>: > OLD: > Handling of subsequent reliable provisional responses for the same > initial request follows the same rules as above, with the following > difference: reliable provisional responses are guaranteed to be in > order. As a result, if the UAC receives another reliable provisional > response to the same request, and its RSeq value is not one higher > than the value of the sequence number, that response MUST NOT be > acknowledged with a PRACK, and MUST NOT be processed further by the > UAC. An implementation MAY discard the response, or MAY cache the > response in the hopes of receiving the missing responses. > > NEW: > Subsequent reliable provisional responses for the same initial > request are guaranteed < order of their RSeq values and must be acknowledged in that order>>. > As a result, if the UAC receives another > reliable provisional response to the same request, and its RSeq > value is one higher than the value of the previously received RSeq > value in the dialog, then the new RSeq value is saved and the > response is handled as described above. If the RSeq value is not one > higher than the value of the sequence number, that response MUST NOT > be acknowledged with a PRACK, and MUST NOT be processed further by > the UAC. An implementation MAY discard the response, or MAY cache > the response <> after receiving > the missing responses. > > Dale > From nobody Fri Dec 11 00:49: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 8CF141ACDCE for ; Fri, 11 Dec 2015 00:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 3DAToQvrbQ5r for ; Fri, 11 Dec 2015 00:49:15 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 146151A86FE for ; Fri, 11 Dec 2015 00:49:14 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-cc-566a8e0840df Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 2C.8A.04914.80E8A665; Fri, 11 Dec 2015 09:49:12 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0248.002; Fri, 11 Dec 2015 09:49:12 +0100 From: Christer Holmberg To: "Dale R. Worley" , "pkyzivat@alum.mit.edu" , "mahoney@nostrum.com" , "ben@nostrum.com" , "sipcore@ietf.org" Thread-Topic: [sipcore] RSeq and forking - Errata Thread-Index: AQHRM4MFaIhPA9HcRsaaDgKN4yT4tJ7FdEWw Date: Fri, 11 Dec 2015 08:49:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C966CE@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37C935B7@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) <87egeu6qef.fsf@hobgoblin.ariadne.com> In-Reply-To: <87egeu6qef.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7li5HX1aYwb4pBhbzO0+zWzR0rmS1 WLHhAKvF1x+b2CxenihzYPX4+/4Dk8fk/V+ZPZYs+cnkMWvnE5YAligum5TUnMyy1CJ9uwSu jPmfrrMU3LWu2Dh7L1MD4029LkZODgkBE4nmqz+YIWwxiQv31rN1MXJxCAkcZpTYtf4TM4Sz hFFiyoFJrF2MHBxsAhYS3f+0QeIiAtcZJXb3vWAB6RYWMJD48QXCFhEwlDh5oh3KNpJoffSb GaSXRUBV4t81RZAwr4CvxJqXO6DmTweaM+8xWD2ngLHE9J+X2UBsRqCLvp9awwRiMwuIS9x6 Mp8J4lIBiSV7zkNdLSrx8vE/sNskBJQkpm1NgyjXkViw+xMbhK0tsWzha2aIvYISJ2c+YZnA KDoLydRZSFpmIWmZhaRlASPLKkbR4tTi4tx0I2O91KLM5OLi/Dy9vNSSTYzAuDq45bfuDsbV rx0PMQpwMCrx8BrYZIUJsSaWFVfmHmKU4GBWEuHlTwUK8aYkVlalFuXHF5XmpBYfYpTmYFES 521hehAqJJCeWJKanZpakFoEk2Xi4JRqYKxc9of1mmXtlS8zrgbJFvKeq9rpunNL7+uJOpxV Uo+DGMuO8zBOcpJd8XBfYOT9g0sfpG4q2G0Z/i9Z6u3dUOOJ/ncnrNuyRfbv3/NnE/3zv73V mrpY36yzuFLkelhnQWilj/rhvSFbPyziW3GU9ZRNQsS0l6GqR9+ZhJTfKlRwzVK7Ivb64z0l luKMREMt5qLiRABSMrFEpwIAAA== Archived-At: Subject: Re: [sipcore] RSeq and forking - Errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 08:49:17 -0000 Hi Dale,=20 Thanks for your excellent work. I do have a few comments on some of your te= xt change suggestions, though. ... >3. Some proposed changes > >Let me propose these changes, which include Paul's proposal of 21 Sep: > >(I've highlighted changes with << >>.) > >Section 3: >OLD: > The provisional response to be sent reliably is constructed by the > UAS core according to the procedures of Section 8.2.6 of RFC 3261. > In addition, it MUST contain a Require header field containing the > option tag 100rel, and MUST include an RSeq header field. The value > of the header field for the first reliable provisional response in a > transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that > it be chosen uniformly in this range. The RSeq numbering space is > within a single transaction. This means that provisional responses > for different requests MAY use the same values for the RSeq number. > >NEW: > The provisional response to be sent reliably is constructed by the > UAS core according to the procedures of Section 8.2.6 of RFC 3261. > In addition, it MUST contain a Require header field containing the > option tag 100rel, and MUST include an RSeq header field. The > value of the header field for the first reliable provisional > response in a transaction MUST be between 1 and 2**31 - 1. It is > RECOMMENDED that it be chosen uniformly in this range. The RSeq > numbering space is within a single transaction < dialog>>. This means that provisional responses for different > requests<<, and forks of a request within different dialogs,>> MAY > use the same values for the RSeq number. Question: why do we need to say "within different dialogs"? Why not simply = say ",and forks of a given request"? It IS true that each fork creates a new (early) dialog, but I just think th= e text suggestion sounds a little confusing. Or, if we want to mention dialog, perhaps: ",and forks of a given request (each fork is associated with a different ea= rly dialog)"? ------------ >Section 4: >OLD: > If a provisional response is received for an initial request, and > that response contains a Require header field containing the option > tag 100rel, the response is to be sent reliably. If the response is > a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be > ignored, and the procedures below MUST NOT be used. > >NEW: > If a provisional response is received for an initial request, and > that response contains a Require header field containing the option > tag 100rel, the response <>. If the > response is a 100 (Trying) (as opposed to 101 to 199), this option > tag MUST be ignored, and the procedures below MUST NOT be used. WFM. ------------ >OLD: > Assuming the response is to be transmitted reliably, the UAC MUST > create a new request with method PRACK. This request is sent within > the dialog associated with the provisional response (indeed, the > provisional response may have created the dialog). PRACK requests > MAY contain bodies, which are interpreted according to their type and > disposition. > >NEW: > Assuming the response <>, the UAC = MUST > create a new request with method PRACK. This request is sent within > the dialog associated with the provisional response (indeed, the > provisional response may have created the dialog). PRACK requests > MAY contain bodies, which are interpreted according to their type and > disposition. WFM. ------------ >This change is from Paul's e-mail: >OLD: > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission when > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain a sequence number that indicates the most recently > received in-order reliable provisional response for the initial > request. This sequence number MUST be maintained until a final > response is received for the initial request. Its value MUST be > initialized to the RSeq header field in the first reliable > provisional response received for the initial request. > >NEW: > > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission when > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain<<, independently for each dialog ID,>> a sequence > number that indicates the most recently received in-order reliable > provisional response for the initial request. This sequence number > MUST be maintained until a final response is received for the initial > request. Its value MUST be initialized to the RSeq header field in > the first reliable provisional response received for the initial > request<< in a dialog>>. I am ok with the first change. However, the second change "initial request in a dialog" sounds a little co= nfusing. The dialog is created when the response of a previous request is r= eceived. Perhaps: > "Its value MUST<<, for each dialog (or early dialog),>> be initialized = to the RSeq header field in > the first reliable provisional response<<, associated with the dialog,>= > received for the initial > request. ------------ >This includes the changes in Paul's e-mail, with my additional changes mar= ked with << >>: >OLD: > Handling of subsequent reliable provisional responses for the same > initial request follows the same rules as above, with the following > difference: reliable provisional responses are guaranteed to be in > order. As a result, if the UAC receives another reliable provisional > response to the same request, and its RSeq value is not one higher > than the value of the sequence number, that response MUST NOT be > acknowledged with a PRACK, and MUST NOT be processed further by the > UAC. An implementation MAY discard the response, or MAY cache the > response in the hopes of receiving the missing responses. > >NEW: > Subsequent reliable provisional responses for the same initial > request are guaranteed < order of their RSeq values and must be acknowledged in that order>>. > As a result, if the UAC receives another > reliable provisional response to the same request, and its RSeq > value is one higher than the value of the previously received RSeq > value in the dialog, then the new RSeq value is saved and the > response is handled as described above. If the RSeq value is not one > higher than the value of the sequence number, that response MUST NOT > be acknowledged with a PRACK, and MUST NOT be processed further by > the UAC. An implementation MAY discard the response, or MAY cache > the response <> after receiving > the missing responses. I am ok with the text change. But, perhaps we also here could change: "of the previously received RSeq value in the dialog," to: "of the previously received RSeq value in the dialog (or early dialog)," The problems mostly occur with forking, when there are multiple early dialo= gs, so I think it's good to explicitly mention them. Otherwise someone MAY = think that "different dialogs" mean "different sessions", which of course i= s not true in case of forking. Regards, Christer From nobody Fri Dec 11 08:06: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 188A71B2AC4 for ; Fri, 11 Dec 2015 08:06:50 -0800 (PST) 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 h13kajr66XME for ; Fri, 11 Dec 2015 08:06:48 -0800 (PST) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6445D1A0049 for ; Fri, 11 Dec 2015 08:06:48 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-07v.sys.comcast.net with comcast id sG6f1r00426dK1R01G6n8h; Fri, 11 Dec 2015 16:06:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-01v.sys.comcast.net with comcast id sG6m1r00C3KdFy101G6mkB; Fri, 11 Dec 2015 16:06:47 +0000 To: Christer Holmberg , "Dale R. Worley" , "mahoney@nostrum.com" , "ben@nostrum.com" , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B37C935B7@ESESSMB209.ericsson.se> <87egeu6qef.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B37C966CE@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <566AF495.3000400@alum.mit.edu> Date: Fri, 11 Dec 2015 11:06:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C966CE@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=1449850007; bh=biCzx8ilFeyJooe760NHycKGQWUhU3GR5cc89q8GqwQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=DsruiNBubn5WX8cgzgsp5GfVGPsDCmOL1pxBYNR6O7cSl1nH2PgGTL+ArgOTf+W/H 3Dmzw1otoUlz6TG1p4/tz1fmaRERRa5Oo/PDGen8VqH6BkF8RsgOR7mr4OPgvLszLD BACcbDGgEa4fSTdtP+AzzHfrbehG13povs2/eUbSlGlQR1PxPzQFaRm9bwz5IiWOL6 Sx1TDk0Ulhvscz+AuYmFho6lDb4n6KMQRysbSA/KVbqLsz5Qrf9f/zNJ4KFPUomeot 1M5jndsoiFcrz6ySHyhtmQEM1qSPqrtpkylUeeiU9eB8oMeGAipchBq1r/2XGAfpyG /6gwfis589lzw== Archived-At: Subject: Re: [sipcore] RSeq and forking - Errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 16:06:50 -0000 Christer - I like all your proposals. Thanks, Paul On 12/11/15 3:49 AM, Christer Holmberg wrote: > Hi Dale, > > Thanks for your excellent work. I do have a few comments on some of your text change suggestions, though. > > ... > >> 3. Some proposed changes >> >> Let me propose these changes, which include Paul's proposal of 21 Sep: >> >> (I've highlighted changes with << >>.) >> >> Section 3: >> OLD: >> The provisional response to be sent reliably is constructed by the >> UAS core according to the procedures of Section 8.2.6 of RFC 3261. >> In addition, it MUST contain a Require header field containing the >> option tag 100rel, and MUST include an RSeq header field. The value >> of the header field for the first reliable provisional response in a >> transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that >> it be chosen uniformly in this range. The RSeq numbering space is >> within a single transaction. This means that provisional responses >> for different requests MAY use the same values for the RSeq number. >> >> NEW: >> The provisional response to be sent reliably is constructed by the >> UAS core according to the procedures of Section 8.2.6 of RFC 3261. >> In addition, it MUST contain a Require header field containing the >> option tag 100rel, and MUST include an RSeq header field. The >> value of the header field for the first reliable provisional >> response in a transaction MUST be between 1 and 2**31 - 1. It is >> RECOMMENDED that it be chosen uniformly in this range. The RSeq >> numbering space is within a single transaction <> dialog>>. This means that provisional responses for different >> requests<<, and forks of a request within different dialogs,>> MAY >> use the same values for the RSeq number. > > Question: why do we need to say "within different dialogs"? Why not simply say ",and forks of a given request"? > > It IS true that each fork creates a new (early) dialog, but I just think the text suggestion sounds a little confusing. > > Or, if we want to mention dialog, perhaps: > > ",and forks of a given request (each fork is associated with a different early dialog)"? > > ------------ > >> Section 4: >> OLD: >> If a provisional response is received for an initial request, and >> that response contains a Require header field containing the option >> tag 100rel, the response is to be sent reliably. If the response is >> a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be >> ignored, and the procedures below MUST NOT be used. >> >> NEW: >> If a provisional response is received for an initial request, and >> that response contains a Require header field containing the option >> tag 100rel, the response <>. If the >> response is a 100 (Trying) (as opposed to 101 to 199), this option >> tag MUST be ignored, and the procedures below MUST NOT be used. > > WFM. > > ------------ > >> OLD: >> Assuming the response is to be transmitted reliably, the UAC MUST >> create a new request with method PRACK. This request is sent within >> the dialog associated with the provisional response (indeed, the >> provisional response may have created the dialog). PRACK requests >> MAY contain bodies, which are interpreted according to their type and >> disposition. >> >> NEW: >> Assuming the response <>, the UAC MUST >> create a new request with method PRACK. This request is sent within >> the dialog associated with the provisional response (indeed, the >> provisional response may have created the dialog). PRACK requests >> MAY contain bodies, which are interpreted according to their type and >> disposition. > > WFM. > > ------------ > >> This change is from Paul's e-mail: >> OLD: >> Once a reliable provisional response is received, retransmissions of >> that response MUST be discarded. A response is a retransmission when >> its dialog ID, CSeq, and RSeq match the original response. The UAC >> MUST maintain a sequence number that indicates the most recently >> received in-order reliable provisional response for the initial >> request. This sequence number MUST be maintained until a final >> response is received for the initial request. Its value MUST be >> initialized to the RSeq header field in the first reliable >> provisional response received for the initial request. >> >> NEW: >> >> Once a reliable provisional response is received, retransmissions of >> that response MUST be discarded. A response is a retransmission when >> its dialog ID, CSeq, and RSeq match the original response. The UAC >> MUST maintain<<, independently for each dialog ID,>> a sequence >> number that indicates the most recently received in-order reliable >> provisional response for the initial request. This sequence number >> MUST be maintained until a final response is received for the initial >> request. Its value MUST be initialized to the RSeq header field in >> the first reliable provisional response received for the initial >> request<< in a dialog>>. > > I am ok with the first change. > > However, the second change "initial request in a dialog" sounds a little confusing. The dialog is created when the response of a previous request is received. > > Perhaps: > >> "Its value MUST<<, for each dialog (or early dialog),>> be initialized to the RSeq header field in >> the first reliable provisional response<<, associated with the dialog,>> received for the initial >> request. > > ------------ > >> This includes the changes in Paul's e-mail, with my additional changes marked with << >>: >> OLD: >> Handling of subsequent reliable provisional responses for the same >> initial request follows the same rules as above, with the following >> difference: reliable provisional responses are guaranteed to be in >> order. As a result, if the UAC receives another reliable provisional >> response to the same request, and its RSeq value is not one higher >> than the value of the sequence number, that response MUST NOT be >> acknowledged with a PRACK, and MUST NOT be processed further by the >> UAC. An implementation MAY discard the response, or MAY cache the >> response in the hopes of receiving the missing responses. >> >> NEW: >> Subsequent reliable provisional responses for the same initial >> request are guaranteed <> order of their RSeq values and must be acknowledged in that order>>. >> As a result, if the UAC receives another >> reliable provisional response to the same request, and its RSeq >> value is one higher than the value of the previously received RSeq >> value in the dialog, then the new RSeq value is saved and the >> response is handled as described above. If the RSeq value is not one >> higher than the value of the sequence number, that response MUST NOT >> be acknowledged with a PRACK, and MUST NOT be processed further by >> the UAC. An implementation MAY discard the response, or MAY cache >> the response <> after receiving >> the missing responses. > > I am ok with the text change. > > But, perhaps we also here could change: > > "of the previously received RSeq value in the dialog," > > to: > > "of the previously received RSeq value in the dialog (or early dialog)," > > > The problems mostly occur with forking, when there are multiple early dialogs, so I think it's good to explicitly mention them. Otherwise someone MAY think that "different dialogs" mean "different sessions", which of course is not true in case of forking. > > Regards, > > Christer > > From nobody Fri Dec 11 08:38:18 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A45E1B2D02 for ; Fri, 11 Dec 2015 08:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 9psrf6I98ac9 for ; Fri, 11 Dec 2015 08:38:15 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA27D1B2D10 for ; Fri, 11 Dec 2015 08:38:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8551; q=dns/txt; s=iport; t=1449851893; x=1451061493; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SLANlCuf5eDJHyKZK+l5dFspcIfi07f6r9NxZompGnU=; b=f06NTetu7ReWpkFxOihOH5b6PNT1jokL6GTdtenZkUbJdmMlXG3gdINZ 3NpTlL7I+e/dYGEq6lejOafCcmPNZ1eZqO2tzDOpcyvATUzDn34EOBpRU EzpEc0m49Vn2f1DJD+MUIblhVvEAimgs2IZY2zky+cuRowOya2L9rNc3/ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAgBA+2pW/5NdJa1eDoMsU24GvSkBD?= =?us-ascii?q?YFiFwqFJEoCgTA4FAEBAQEBAQGBCoQ0AQEBAwEBAQE3NAsFCwIBCA4KHhAnCyU?= =?us-ascii?q?CBA4FiCcIDb8VAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGVgGCDoJuhFmDTYEaB?= =?us-ascii?q?YdZjxkBiCWFHoFbl0KDcgEfAQFCg0Y+coRegQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,414,1444694400"; d="scan'208";a="215776343" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2015 16:38:12 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id tBBGcCK0032235 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 11 Dec 2015 16:38:12 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 11 Dec 2015 10:38:12 -0600 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Fri, 11 Dec 2015 10:38:12 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat Thread-Topic: [sipcore] RSeq and forking - Errata Thread-Index: AdCjwjb6aIhPA9HcRsaaDgKN4yT4tAG3gD/g///pywD//9iRUIAU+dAA//9WNoCAEf+lAIAADcgAgAAA4oCAASKMAP+ewsGQGbQTAoD//9WhMP//yj+A//9vwbD/gYZk8P8BISFZ/gHU8YA= Date: Fri, 11 Dec 2015 16:38:12 +0000 Message-ID: <8AEA0F42-9DF0-4CD9-8F01-DAD73EFD326C@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B37C935B7@ESESSMB209.ericsson.se> <87egeu6qef.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B37C966CE@ESESSMB209.ericsson.se> <566AF495.3000400@alum.mit.edu> In-Reply-To: <566AF495.3000400@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.250.136] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ben@nostrum.com" , "sipcore@ietf.org" , "Gonzalo Salgueiro \(gsalguei\)" , "Dale R. Worley" Subject: Re: [sipcore] RSeq and forking - Errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 16:38:17 -0000 I agree with all of them as well. -Gonzalo > On Dec 11, 2015, at 11:06 AM, Paul Kyzivat wrote: >=20 > Christer - I like all your proposals. >=20 > Thanks, > Paul >=20 > On 12/11/15 3:49 AM, Christer Holmberg wrote: >> Hi Dale, >>=20 >> Thanks for your excellent work. I do have a few comments on some of your= text change suggestions, though. >>=20 >> ... >>=20 >>> 3. Some proposed changes >>>=20 >>> Let me propose these changes, which include Paul's proposal of 21 Sep: >>>=20 >>> (I've highlighted changes with << >>.) >>>=20 >>> Section 3: >>> OLD: >>> The provisional response to be sent reliably is constructed by the >>> UAS core according to the procedures of Section 8.2.6 of RFC 3261. >>> In addition, it MUST contain a Require header field containing the >>> option tag 100rel, and MUST include an RSeq header field. The value >>> of the header field for the first reliable provisional response in a >>> transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that >>> it be chosen uniformly in this range. The RSeq numbering space is >>> within a single transaction. This means that provisional responses >>> for different requests MAY use the same values for the RSeq number. >>>=20 >>> NEW: >>> The provisional response to be sent reliably is constructed by the >>> UAS core according to the procedures of Section 8.2.6 of RFC 3261. >>> In addition, it MUST contain a Require header field containing the >>> option tag 100rel, and MUST include an RSeq header field. The >>> value of the header field for the first reliable provisional >>> response in a transaction MUST be between 1 and 2**31 - 1. It is >>> RECOMMENDED that it be chosen uniformly in this range. The RSeq >>> numbering space is within a single transaction <>> dialog>>. This means that provisional responses for different >>> requests<<, and forks of a request within different dialogs,>> MAY >>> use the same values for the RSeq number. >>=20 >> Question: why do we need to say "within different dialogs"? Why not simp= ly say ",and forks of a given request"? >>=20 >> It IS true that each fork creates a new (early) dialog, but I just think= the text suggestion sounds a little confusing. >>=20 >> Or, if we want to mention dialog, perhaps: >>=20 >> ",and forks of a given request (each fork is associated with a different= early dialog)"? >>=20 >> ------------ >>=20 >>> Section 4: >>> OLD: >>> If a provisional response is received for an initial request, and >>> that response contains a Require header field containing the option >>> tag 100rel, the response is to be sent reliably. If the response is >>> a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be >>> ignored, and the procedures below MUST NOT be used. >>>=20 >>> NEW: >>> If a provisional response is received for an initial request, and >>> that response contains a Require header field containing the option >>> tag 100rel, the response <>. If the >>> response is a 100 (Trying) (as opposed to 101 to 199), this option >>> tag MUST be ignored, and the procedures below MUST NOT be used. >>=20 >> WFM. >>=20 >> ------------ >>=20 >>> OLD: >>> Assuming the response is to be transmitted reliably, the UAC MUST >>> create a new request with method PRACK. This request is sent within >>> the dialog associated with the provisional response (indeed, the >>> provisional response may have created the dialog). PRACK requests >>> MAY contain bodies, which are interpreted according to their type and >>> disposition. >>>=20 >>> NEW: >>> Assuming the response <>, the UA= C MUST >>> create a new request with method PRACK. This request is sent within >>> the dialog associated with the provisional response (indeed, the >>> provisional response may have created the dialog). PRACK requests >>> MAY contain bodies, which are interpreted according to their type and >>> disposition. >>=20 >> WFM. >>=20 >> ------------ >>=20 >>> This change is from Paul's e-mail: >>> OLD: >>> Once a reliable provisional response is received, retransmissions of >>> that response MUST be discarded. A response is a retransmission when >>> its dialog ID, CSeq, and RSeq match the original response. The UAC >>> MUST maintain a sequence number that indicates the most recently >>> received in-order reliable provisional response for the initial >>> request. This sequence number MUST be maintained until a final >>> response is received for the initial request. Its value MUST be >>> initialized to the RSeq header field in the first reliable >>> provisional response received for the initial request. >>>=20 >>> NEW: >>>=20 >>> Once a reliable provisional response is received, retransmissions of >>> that response MUST be discarded. A response is a retransmission when >>> its dialog ID, CSeq, and RSeq match the original response. The UAC >>> MUST maintain<<, independently for each dialog ID,>> a sequence >>> number that indicates the most recently received in-order reliable >>> provisional response for the initial request. This sequence number >>> MUST be maintained until a final response is received for the initial >>> request. Its value MUST be initialized to the RSeq header field in >>> the first reliable provisional response received for the initial >>> request<< in a dialog>>. >>=20 >> I am ok with the first change. >>=20 >> However, the second change "initial request in a dialog" sounds a little= confusing. The dialog is created when the response of a previous request i= s received. >>=20 >> Perhaps: >>=20 >>> "Its value MUST<<, for each dialog (or early dialog),>> be initialize= d to the RSeq header field in >>> the first reliable provisional response<<, associated with the dialog= ,>> received for the initial >>> request. >>=20 >> ------------ >>=20 >>> This includes the changes in Paul's e-mail, with my additional changes = marked with << >>: >>> OLD: >>> Handling of subsequent reliable provisional responses for the same >>> initial request follows the same rules as above, with the following >>> difference: reliable provisional responses are guaranteed to be in >>> order. As a result, if the UAC receives another reliable provisional >>> response to the same request, and its RSeq value is not one higher >>> than the value of the sequence number, that response MUST NOT be >>> acknowledged with a PRACK, and MUST NOT be processed further by the >>> UAC. An implementation MAY discard the response, or MAY cache the >>> response in the hopes of receiving the missing responses. >>>=20 >>> NEW: >>> Subsequent reliable provisional responses for the same initial >>> request are guaranteed <>> order of their RSeq values and must be acknowledged in that order>>. >>> As a result, if the UAC receives another >>> reliable provisional response to the same request, and its RSeq >>> value is one higher than the value of the previously received RSeq >>> value in the dialog, then the new RSeq value is saved and the >>> response is handled as described above. If the RSeq value is not one >>> higher than the value of the sequence number, that response MUST NOT >>> be acknowledged with a PRACK, and MUST NOT be processed further by >>> the UAC. An implementation MAY discard the response, or MAY cache >>> the response <> after receiving >>> the missing responses. >>=20 >> I am ok with the text change. >>=20 >> But, perhaps we also here could change: >>=20 >> "of the previously received RSeq value in the dialog," >>=20 >> to: >>=20 >> "of the previously received RSeq value in the dialog (or early dialog)," >>=20 >>=20 >> The problems mostly occur with forking, when there are multiple early di= alogs, so I think it's good to explicitly mention them. Otherwise someone M= AY think that "different dialogs" mean "different sessions", which of cours= e is not true in case of forking. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Sun Dec 13 07:29:00 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 6791D1AD338 for ; Sun, 13 Dec 2015 07:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_WhvNA9T_q0 for ; Sun, 13 Dec 2015 07:28:56 -0800 (PST) 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 25FD11AD2F2 for ; Sun, 13 Dec 2015 07:28:55 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-3c-566d8eb5afc7 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id DF.2F.05041.5BE8D665; Sun, 13 Dec 2015 16:28:54 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0248.002; Sun, 13 Dec 2015 16:28:53 +0100 From: Christer Holmberg To: "Gonzalo Salgueiro (gsalguei)" , Paul Kyzivat Thread-Topic: [sipcore] RSeq and forking - Errata Thread-Index: AQHRM4MFaIhPA9HcRsaaDgKN4yT4tJ7FdEWwgABvzoCAAAjJAIADICUQ Date: Sun, 13 Dec 2015 15:28:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37CCAC82@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37C935B7@ESESSMB209.ericsson.se> <87egeu6qef.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B37C966CE@ESESSMB209.ericsson.se> <566AF495.3000400@alum.mit.edu> <8AEA0F42-9DF0-4CD9-8F01-DAD73EFD326C@cisco.com> In-Reply-To: <8AEA0F42-9DF0-4CD9-8F01-DAD73EFD326C@cisco.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+NgFlrJIsWRmVeSWpSXmKPExsUyM2K7ru62vtwwg64vXBbzO0+zW8yd4mfR 0LmS1WLFhgOsFl9/bGKzeHmizIHN4+/7D0wek/d/ZfaY8nsjq8eSJT+ZPGbtfMISwBrFZZOS mpNZllqkb5fAlXHidXVBr2/F9v//mRoY59h2MXJwSAiYSCyf7N7FyAlkiklcuLeerYuRi0NI 4DCjxI5X8xghnMWMEns2LWEHaWATsJDo/qcN0iAiEC/x+dQhdpAaZoFljBLnlv5lBUkICxhI /PjyggWiyFDi5Il2KNtN4vLHS2wgNouAqsSlLTPAbF4BX4mNnfuYIJb1M0ns/n2BHSTBKWAr 0f71DFgzI9B530+tYQKxmQXEJW49mc8EcbaAxJI955khbFGJl4//sULYShKLbn+GqteRWLD7 ExuErS2xbOFrZojFghInZz5hmcAoNgvJ2FlIWmYhaZmFpGUBI8sqRtHi1OLi3HQjI73Uoszk 4uL8PL281JJNjMAIPLjlt9UOxoPPHQ8xCnAwKvHwfliWEybEmlhWXJl7iFGCg1lJhLfRPDdM iDclsbIqtSg/vqg0J7X4EKM0B4uSOG8z04NQIYH0xJLU7NTUgtQimCwTB6dUA+OsaWZv83he zmhcJuMyI/aWZ5K0FUcU95J7gdp2O25fZqopnnTPvObyjYYZi+XlMnPvswdc1rpfLsu30iO6 +tW6dxN/l+1aqfJU7ILLb0f/zrMfZBXOrTRQWjM/5XnHz23nY10Lq3RcwzZPeaHb/tXi/UP5 Gs62/wK3j+z5NjH7g3zz6nMn5vYpsRRnJBpqMRcVJwIAGhNOy7wCAAA= Archived-At: Cc: "ben@nostrum.com" , "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2015 15:28:59 -0000 Hi, One additional change suggestion, based on a comment from a colleague. The new suggested text for section 3 contains the following: "MAY use the same values for the RSeq number." First, I don't think we should use capital letter "MAY use" here, because t= hat could give a picture that there is some kind of dependency. Instead I s= uggest to say something like "might end up using". Second, it would also be good to indicate that, in addition to saying that = the same values can be used, it should also be clarified that lower values = might be used. So, something like: "This means that provisional responses for different requests, and forks o= f a given request (each fork is associated with a different early dialog), might end up using identical, or lower, values for the RSeq number, compar= ed to the other forks." Regards, Christer=20 -----Original Message----- From: Gonzalo Salgueiro (gsalguei) [mailto:gsalguei@cisco.com]=20 Sent: 11 December 2015 18:38 To: Paul Kyzivat Cc: Gonzalo Salgueiro (gsalguei) ; Christer Holmberg ; Dale R. Worley ; mahone= y@nostrum.com; ben@nostrum.com; sipcore@ietf.org Subject: Re: [sipcore] RSeq and forking - Errata I agree with all of them as well. -Gonzalo > On Dec 11, 2015, at 11:06 AM, Paul Kyzivat wrote: >=20 > Christer - I like all your proposals. >=20 > Thanks, > Paul >=20 > On 12/11/15 3:49 AM, Christer Holmberg wrote: >> Hi Dale, >>=20 >> Thanks for your excellent work. I do have a few comments on some of your= text change suggestions, though. >>=20 >> ... >>=20 >>> 3. Some proposed changes >>>=20 >>> Let me propose these changes, which include Paul's proposal of 21 Sep: >>>=20 >>> (I've highlighted changes with << >>.) >>>=20 >>> Section 3: >>> OLD: >>> The provisional response to be sent reliably is constructed by the >>> UAS core according to the procedures of Section 8.2.6 of RFC 3261. >>> In addition, it MUST contain a Require header field containing the >>> option tag 100rel, and MUST include an RSeq header field. The value >>> of the header field for the first reliable provisional response in a >>> transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that >>> it be chosen uniformly in this range. The RSeq numbering space is >>> within a single transaction. This means that provisional responses >>> for different requests MAY use the same values for the RSeq number. >>>=20 >>> NEW: >>> The provisional response to be sent reliably is constructed by the >>> UAS core according to the procedures of Section 8.2.6 of RFC 3261. >>> In addition, it MUST contain a Require header field containing the >>> option tag 100rel, and MUST include an RSeq header field. The >>> value of the header field for the first reliable provisional >>> response in a transaction MUST be between 1 and 2**31 - 1. It is >>> RECOMMENDED that it be chosen uniformly in this range. The RSeq >>> numbering space is within a single transaction <>> dialog>>. This means that provisional responses for different >>> requests<<, and forks of a request within different dialogs,>> MAY >>> use the same values for the RSeq number. >>=20 >> Question: why do we need to say "within different dialogs"? Why not simp= ly say ",and forks of a given request"? >>=20 >> It IS true that each fork creates a new (early) dialog, but I just think= the text suggestion sounds a little confusing. >>=20 >> Or, if we want to mention dialog, perhaps: >>=20 >> ",and forks of a given request (each fork is associated with a different= early dialog)"? >>=20 >> ------------ >>=20 >>> Section 4: >>> OLD: >>> If a provisional response is received for an initial request, and >>> that response contains a Require header field containing the option >>> tag 100rel, the response is to be sent reliably. If the response is >>> a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be >>> ignored, and the procedures below MUST NOT be used. >>>=20 >>> NEW: >>> If a provisional response is received for an initial request, and >>> that response contains a Require header field containing the option >>> tag 100rel, the response <>. If the >>> response is a 100 (Trying) (as opposed to 101 to 199), this option >>> tag MUST be ignored, and the procedures below MUST NOT be used. >>=20 >> WFM. >>=20 >> ------------ >>=20 >>> OLD: >>> Assuming the response is to be transmitted reliably, the UAC MUST >>> create a new request with method PRACK. This request is sent within >>> the dialog associated with the provisional response (indeed, the >>> provisional response may have created the dialog). PRACK requests >>> MAY contain bodies, which are interpreted according to their type and >>> disposition. >>>=20 >>> NEW: >>> Assuming the response <>, the UA= C MUST >>> create a new request with method PRACK. This request is sent within >>> the dialog associated with the provisional response (indeed, the >>> provisional response may have created the dialog). PRACK requests >>> MAY contain bodies, which are interpreted according to their type and >>> disposition. >>=20 >> WFM. >>=20 >> ------------ >>=20 >>> This change is from Paul's e-mail: >>> OLD: >>> Once a reliable provisional response is received, retransmissions of >>> that response MUST be discarded. A response is a retransmission when >>> its dialog ID, CSeq, and RSeq match the original response. The UAC >>> MUST maintain a sequence number that indicates the most recently >>> received in-order reliable provisional response for the initial >>> request. This sequence number MUST be maintained until a final >>> response is received for the initial request. Its value MUST be >>> initialized to the RSeq header field in the first reliable >>> provisional response received for the initial request. >>>=20 >>> NEW: >>>=20 >>> Once a reliable provisional response is received, retransmissions of >>> that response MUST be discarded. A response is a retransmission when >>> its dialog ID, CSeq, and RSeq match the original response. The UAC >>> MUST maintain<<, independently for each dialog ID,>> a sequence >>> number that indicates the most recently received in-order reliable >>> provisional response for the initial request. This sequence number >>> MUST be maintained until a final response is received for the initial >>> request. Its value MUST be initialized to the RSeq header field in >>> the first reliable provisional response received for the initial >>> request<< in a dialog>>. >>=20 >> I am ok with the first change. >>=20 >> However, the second change "initial request in a dialog" sounds a little= confusing. The dialog is created when the response of a previous request i= s received. >>=20 >> Perhaps: >>=20 >>> "Its value MUST<<, for each dialog (or early dialog),>> be initialize= d to the RSeq header field in >>> the first reliable provisional response<<, associated with the dialog= ,>> received for the initial >>> request. >>=20 >> ------------ >>=20 >>> This includes the changes in Paul's e-mail, with my additional changes = marked with << >>: >>> OLD: >>> Handling of subsequent reliable provisional responses for the same >>> initial request follows the same rules as above, with the following >>> difference: reliable provisional responses are guaranteed to be in >>> order. As a result, if the UAC receives another reliable provisional >>> response to the same request, and its RSeq value is not one higher >>> than the value of the sequence number, that response MUST NOT be >>> acknowledged with a PRACK, and MUST NOT be processed further by the >>> UAC. An implementation MAY discard the response, or MAY cache the >>> response in the hopes of receiving the missing responses. >>>=20 >>> NEW: >>> Subsequent reliable provisional responses for the same initial >>> request are guaranteed <>> order of their RSeq values and must be acknowledged in that order>>. >>> As a result, if the UAC receives another >>> reliable provisional response to the same request, and its RSeq >>> value is one higher than the value of the previously received RSeq >>> value in the dialog, then the new RSeq value is saved and the >>> response is handled as described above. If the RSeq value is not one >>> higher than the value of the sequence number, that response MUST NOT >>> be acknowledged with a PRACK, and MUST NOT be processed further by >>> the UAC. An implementation MAY discard the response, or MAY cache >>> the response <> after receiving >>> the missing responses. >>=20 >> I am ok with the text change. >>=20 >> But, perhaps we also here could change: >>=20 >> "of the previously received RSeq value in the dialog," >>=20 >> to: >>=20 >> "of the previously received RSeq value in the dialog (or early dialog)," >>=20 >>=20 >> The problems mostly occur with forking, when there are multiple early di= alogs, so I think it's good to explicitly mention them. Otherwise someone M= AY think that "different dialogs" mean "different sessions", which of cours= e is not true in case of forking. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Sun Dec 13 08:21: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 AF2071B29E1 for ; Sun, 13 Dec 2015 08:21:12 -0800 (PST) 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 0d-1dXty-xkD for ; Sun, 13 Dec 2015 08:21:11 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA4B1B29CA for ; Sun, 13 Dec 2015 08:21:11 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-08v.sys.comcast.net with comcast id t4M51r00A2S2Q5R014MAyj; Sun, 13 Dec 2015 16:21:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-16v.sys.comcast.net with comcast id t4M91r00c3KdFy1014MADJ; Sun, 13 Dec 2015 16:21:10 +0000 To: Christer Holmberg , "Gonzalo Salgueiro (gsalguei)" References: <7594FB04B1934943A5C02806D1A2204B37C935B7@ESESSMB209.ericsson.se> <87egeu6qef.fsf@hobgoblin.ariadne.com> <7594FB04B1934943A5C02806D1A2204B37C966CE@ESESSMB209.ericsson.se> <566AF495.3000400@alum.mit.edu> <8AEA0F42-9DF0-4CD9-8F01-DAD73EFD326C@cisco.com> <7594FB04B1934943A5C02806D1A2204B37CCAC82@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <566D9AF5.1020306@alum.mit.edu> Date: Sun, 13 Dec 2015 11:21:09 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37CCAC82@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=1450023670; bh=Yp8lyDtLD7Or37NqqHRSpfWMoPfKn+ETwh36ibmADR0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=mn2UAYmKxU+P2YYuUdrcfJGqsa94KAJxLcNP4Vk1kIuvXthKvNqJs632Lss41Z1bc CmjLDmblnSDjj+K1LpPWJp2VSw/6H6H+HDZZSCATClSggFCG7pKRn9T1S+kvv+aiok nU4xL3nhLMAiW8VUbT26YLIFHwximnmjRASOQUv1wfcg+1/2UmJ579RQb5FJCVCacc BKcvQJTs0DaSTOmkErSAJ9jqt/ynf7QZ/te7I9fYO9TdpdY8h0sHzh59VfCe3pA6Nb zt5/vItH8zkULuralSuhZKS2ZWt2i4jegGJUifjsX4kDngvDBVrSJbiozOkymtHBH5 tcDoqUsTddTiw== Archived-At: Cc: "ben@nostrum.com" , "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2015 16:21:12 -0000 On 12/13/15 10:28 AM, Christer Holmberg wrote: > So, something like: > > "This means that provisional responses for different requests, and forks of a given request (each fork is associated with a different early dialog), > might end up using identical, or lower, values for the RSeq number, compared to the other forks." Yes, this is better! Thanks, Paul From nobody Mon Dec 14 02:47:25 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604171A92B6 for ; Mon, 14 Dec 2015 02:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7D7FZBTJx0z0 for ; Mon, 14 Dec 2015 02:47:22 -0800 (PST) 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 22B101A92B7 for ; Mon, 14 Dec 2015 02:47:21 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-ac-566e9e38b4c6 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 52.C7.05149.83E9E665; Mon, 14 Dec 2015 11:47:20 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0248.002; Mon, 14 Dec 2015 11:47:19 +0100 From: Christer Holmberg To: Paul Kyzivat , "Gonzalo Salgueiro (gsalguei)" Thread-Topic: [sipcore] RSeq and forking - Text for new errata Thread-Index: AdE2XJ2ayOAhoF5zQ/CoL3n3RD7LFQ== Date: Mon, 14 Dec 2015 10:47:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37CD5338@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbFdWtdiXl6Ywb1TwhbzO0+zW8yd4mfR 0LmS1WLFhgOsFl9/bGKzeHmizIHN4+/7D0wek/d/ZfaY8nsjq8eSJT+ZPGbtfMISwBrFZZOS mpNZllqkb5fAlfH20G/Ggjv6FQe/fmNqYGxU7WLk5JAQMJF48eMXG4QtJnHh3nowW0jgMKPE 1R5GCHsxo8T5W6ZdjBwcbAIWEt3/tEHCIgLxEncPtACVcHEwCyxjlDi39C8rSEJYwFbizpqr zBBFdhLb3y9nBOkVEdCT6H9nAhJmEVCVmPnxLVgJr4CvxOltn8BsRqATvp9awwRiMwuIS9x6 Mp8J4jQBiSV7zjND2KISLx//Y4WwFSXanzYwQtTrSCzY/YkNwtaWWLbwNdR8QYmTM5+wTGAU mYVk7CwkLbOQtMxC0rKAkWUVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmA0Hdzy22AH48vn jocYBTgYlXh4DQ7khgmxJpYVV+YeYpTgYFYS4U2wygsT4k1JrKxKLcqPLyrNSS0+xCjNwaIk ztvM9CBUSCA9sSQ1OzW1ILUIJsvEwSnVwDjtlLCdeGDWUZ1zTHtSjztHB2yYNj2S7/rSYLvA JztmOTsFl1Uxr0m8vb7FkdvKbAVXw+bilQYHjqTosxx6t0Rrq87sVv8cg9K2GTL388qXP/sc oWjCyM8ya/d0facvRm/+nXKe3PCqR+bTiaUqrzocpmaf3H9ZUz+67+xjKVcDTuuH8hfYRJVY ijMSDbWYi4oTAd3buaSiAgAA Archived-At: Cc: "ben@nostrum.com" , "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Text for new errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 10:47:24 -0000 Hi, Based on the e-mail discussion, the new errata would contain the following = change suggestions: ------------ Section 3: OLD: The provisional response to be sent reliably is constructed by the UAS core according to the procedures of Section 8.2.6 of RFC 3261. In addition, it MUST contain a Require header field containing the option tag 100rel, and MUST include an RSeq header field. The value of the header field for the first reliable provisional response in a transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that it be chosen uniformly in this range. The RSeq numbering space is within a single transaction. This means that provisional responses for different requests MAY use the same values for the RSeq number. NEW: The provisional response to be sent reliably is constructed by the UAS core according to the procedures of Section 8.2.6 of RFC 3261. In addition, it MUST contain a Require header field containing the option tag 100rel, and MUST include an RSeq header field. The value of the header field for the first reliable provisional response in a transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that it be chosen uniformly in this range. The RSeq numbering space is within a single transaction of a single dialog (or early dialog).This means that provisional responses for diffe= rent requests, and forks of a given request (each fork is associated with a different e= arly=20 dialog), might end up using identical, or lower, values for the RSeq num= ber,=20 compared to the other forks. Section 4: OLD: If a provisional response is received for an initial request, and that response contains a Require header field containing the option tag 100rel, the response is to be sent reliably. If the response is a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be ignored, and the procedures below MUST NOT be used. NEW: If a provisional response is received for an initial request, and that response contains a Require header field containing the option tag 100rel, the response was sent by the UAS reliably. If the response is a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be ignored, and the procedures below MUST NOT be used. OLD: Assuming the response is to be transmitted reliably, the UAC MUST create a new request with method PRACK. This request is sent within the dialog associated with the provisional response (indeed, the provisional response may have created the dialog). PRACK requests MAY contain bodies, which are interpreted according to their type and disposition. NEW: Assuming the response was transmitted reliably by the UAS, the UAC MUST create a new request with method PRACK. This request is sent within the dialog associated with the provisional response (indeed, the provisional response may have created the dialog). PRACK requests MAY contain bodies, which are interpreted according to their type and disposition. OLD: Once a reliable provisional response is received, retransmissions of that response MUST be discarded. A response is a retransmission when its dialog ID, CSeq, and RSeq match the original response. The UAC MUST maintain a sequence number that indicates the most recently received in-order reliable provisional response for the initial request. This sequence number MUST be maintained until a final response is received for the initial request. Its value MUST be initialized to the RSeq header field in the first reliable provisional response received for the initial request. NEW: Once a reliable provisional response is received, retransmissions of that response MUST be discarded. A response is a retransmission when its dialog ID, CSeq, and RSeq match the original response. The UAC MUST maintain, independently for each dialog ID, a sequence number that indicates the most recently received in-order reliable provisional response for the initial request. This sequence number MUST be maintained until a final response is received for the initial request. Its value MUST, for each dialog (or early dialog), be initializ= ed to the RSeq header field in the first reliable provisional response,=20 associated with the dialog, received for the initial request.=20 OLD: Handling of subsequent reliable provisional responses for the same initial request follows the same rules as above, with the following difference: reliable provisional responses are guaranteed to be in order. As a result, if the UAC receives another reliable provisional response to the same request, and its RSeq value is not one higher than the value of the sequence number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache the response in the hopes of receiving the missing responses. NEW: Subsequent reliable provisional responses for the same initial request are guaranteed to have been generated by the UAS in the order of their RSeq values and must be acknowledged in that order. As a result, if the UAC receives another reliable provisional response to the same request, and its RSeq value is one higher than the value of the previously received RSeq value in the dialog (or early dialog), then the new RSeq value is saved = and the response is handled as described above. If the RSeq value is not one higher than the value of the sequence number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache the response to be processed (and acknowledged) after receiving the missing responses. ------------- Can I go ahead and create a new errata? :) Regards, Christer From nobody Mon Dec 14 07:35: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 6431D1A6F77 for ; Mon, 14 Dec 2015 07:35:08 -0800 (PST) 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 xDIJ6KRZQSJa for ; Mon, 14 Dec 2015 07:35:07 -0800 (PST) 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 DA6071A1A83 for ; Mon, 14 Dec 2015 07:35:06 -0800 (PST) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-09v.sys.comcast.net with comcast id tTaJ1r0032Udklx01Tb6jN; Mon, 14 Dec 2015 15:35:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-18v.sys.comcast.net with comcast id tTb51r0043KdFy101Tb5J8; Mon, 14 Dec 2015 15:35:06 +0000 To: Christer Holmberg , "Gonzalo Salgueiro (gsalguei)" References: <7594FB04B1934943A5C02806D1A2204B37CD5338@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <566EE1A7.2010207@alum.mit.edu> Date: Mon, 14 Dec 2015 10:35:03 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37CD5338@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=1450107306; bh=7tmmwquNxtqt7mtSJiI/mQkbpwALDp9sG/Si6CxC5G8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=kgaHOE2XPiGodbLzBdJQeIE7E+jfwfbcMLcegU/dENafFytKny2PeG7XxMnzutOuX SJj/cWKLk/PV9YoxLghzj2/3xbkT9e0wiDk5Yllr5DqJ5qlT5dRAzv4Ya01KD6dop4 SCR63wu8FEgFcj4nh6YpqCClrPo1Urh76BMpNomR4sEnWbxJHNYVEAyb468LxdDpuM sFsJ09KNHbr8z6STcKLJp5UtFOoyL1Fk3VIS3UHSQKc4ugiRY212o3VpXe87PEQAGf R8duUueU2ybLR9UzJmjBuLHEgXm1n/u+lfK88mD5pFvL2tUe9tQ932w7ZgF3T45MEM EgQsiELt/5fSQ== Archived-At: Cc: "ben@nostrum.com" , "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Text for new errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 15:35:08 -0000 Go for it! Thanks, Paul On 12/14/15 5:47 AM, Christer Holmberg wrote: > Hi, > > Based on the e-mail discussion, the new errata would contain the following change suggestions: > > ------------ > > Section 3: > > OLD: > The provisional response to be sent reliably is constructed by the > UAS core according to the procedures of Section 8.2.6 of RFC 3261. > In addition, it MUST contain a Require header field containing the > option tag 100rel, and MUST include an RSeq header field. The value > of the header field for the first reliable provisional response in a > transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that > it be chosen uniformly in this range. The RSeq numbering space is > within a single transaction. This means that provisional responses > for different requests MAY use the same values for the RSeq number. > > NEW: > The provisional response to be sent reliably is constructed by the > UAS core according to the procedures of Section 8.2.6 of RFC 3261. > In addition, it MUST contain a Require header field containing the > option tag 100rel, and MUST include an RSeq header field. The > value of the header field for the first reliable provisional > response in a transaction MUST be between 1 and 2**31 - 1. It is > RECOMMENDED that it be chosen uniformly in this range. The RSeq > numbering space is within a single transaction of a single > dialog (or early dialog).This means that provisional responses for different requests, > and forks of a given request (each fork is associated with a different early > dialog), might end up using identical, or lower, values for the RSeq number, > compared to the other forks. > > > Section 4: > > OLD: > If a provisional response is received for an initial request, and > that response contains a Require header field containing the option > tag 100rel, the response is to be sent reliably. If the response is > a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be > ignored, and the procedures below MUST NOT be used. > > NEW: > If a provisional response is received for an initial request, and > that response contains a Require header field containing the option > tag 100rel, the response was sent by the UAS reliably. If the > response is a 100 (Trying) (as opposed to 101 to 199), this option > tag MUST be ignored, and the procedures below MUST NOT be used. > > > OLD: > Assuming the response is to be transmitted reliably, the UAC MUST > create a new request with method PRACK. This request is sent within > the dialog associated with the provisional response (indeed, the > provisional response may have created the dialog). PRACK requests > MAY contain bodies, which are interpreted according to their type and > disposition. > > NEW: > Assuming the response was transmitted reliably by the UAS, the UAC MUST > create a new request with method PRACK. This request is sent within > the dialog associated with the provisional response (indeed, the > provisional response may have created the dialog). PRACK requests > MAY contain bodies, which are interpreted according to their type and > disposition. > > > OLD: > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission when > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain a sequence number that indicates the most recently > received in-order reliable provisional response for the initial > request. This sequence number MUST be maintained until a final > response is received for the initial request. Its value MUST be > initialized to the RSeq header field in the first reliable > provisional response received for the initial request. > > NEW: > > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission when > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain, independently for each dialog ID, a sequence > number that indicates the most recently received in-order reliable > provisional response for the initial request. This sequence number > MUST be maintained until a final response is received for the initial > request. Its value MUST, for each dialog (or early dialog), be initialized > to the RSeq header field in the first reliable provisional response, > associated with the dialog, received for the initial request. > > > OLD: > Handling of subsequent reliable provisional responses for the same > initial request follows the same rules as above, with the following > difference: reliable provisional responses are guaranteed to be in > order. As a result, if the UAC receives another reliable provisional > response to the same request, and its RSeq value is not one higher > than the value of the sequence number, that response MUST NOT be > acknowledged with a PRACK, and MUST NOT be processed further by the > UAC. An implementation MAY discard the response, or MAY cache the > response in the hopes of receiving the missing responses. > > NEW: > Subsequent reliable provisional responses for the same initial > request are guaranteed to have been generated by the UAS in the > order of their RSeq values and must be acknowledged in that order. > As a result, if the UAC receives another > reliable provisional response to the same request, and its RSeq > value is one higher than the value of the previously received RSeq > value in the dialog (or early dialog), then the new RSeq value is saved and the > response is handled as described above. If the RSeq value is not one > higher than the value of the sequence number, that response MUST NOT > be acknowledged with a PRACK, and MUST NOT be processed further by > the UAC. An implementation MAY discard the response, or MAY cache > the response to be processed (and acknowledged) after receiving > the missing responses. > > > ------------- > > Can I go ahead and create a new errata? :) > > Regards, > > Christer > > > From nobody Mon Dec 14 08:16: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 302A71A8ACB for ; Mon, 14 Dec 2015 08:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 Fh8Ny9wjO6Rk for ; Mon, 14 Dec 2015 08:16:41 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5401B1A8AC2 for ; Mon, 14 Dec 2015 08:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6501; q=dns/txt; s=iport; t=1450109794; x=1451319394; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8zs9o3XOJCLzxtf2fUOTFc9yVvGSkyrk7+jTHZsXcAc=; b=CdM3wNLfVrdj68usrhbvraPJWxLp7JWctoMzUYmg893qQcpP9ZWFvcL3 lQWULTSMA4S0t95cm7znJPhNVfhlnQqkjvEXgMvkSOa3NOTI5YzYJsOLG w7RrsRW55JwNMKOtDa5zw9fN/vBwyu3OPilg1cSEeoWylsLDF+S5rL9mi 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A2BQDi6W5W/5xdJa1egzqBQQa9O4Fjh?= =?us-ascii?q?g4CgSg6EgEBAQEBAQGBCoQ0AQEBAwE6PwULAgEIGB4QMiUBAQQOBYgnCL0BAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARqGVgGCDoJuhFmDTYEaBYdZjx0BiCWFHp0TAScBO?= =?us-ascii?q?4QEcoN+gQgBAQE?= X-IronPort-AV: E=Sophos;i="5.20,427,1444694400"; d="scan'208";a="55264586" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2015 16:16:33 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tBEGGX7f027739 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Dec 2015 16:16:33 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 14 Dec 2015 10:16:32 -0600 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Mon, 14 Dec 2015 10:16:32 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Christer Holmberg Thread-Topic: [sipcore] RSeq and forking - Text for new errata Thread-Index: AdE2XJ2ayOAhoF5zQ/CoL3n3RD7LFQAYHicA Date: Mon, 14 Dec 2015 16:16:32 +0000 Message-ID: <21609DE6-F57E-4A47-A42A-D4E189196909@cisco.com> References: <7594FB04B1934943A5C02806D1A2204B37CD5338@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37CD5338@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.241.168] Content-Type: text/plain; charset="us-ascii" Content-ID: <0CCA0E8163A07446AD42EB2DCA1BD3C2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ben@nostrum.com" , "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Text for new errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 16:16:45 -0000 This all looks good and can be the basis for the errata. -G > On Dec 14, 2015, at 5:47 AM, Christer Holmberg wrote: >=20 > Hi, >=20 > Based on the e-mail discussion, the new errata would contain the followin= g change suggestions: >=20 > ------------ >=20 > Section 3: >=20 > OLD: > The provisional response to be sent reliably is constructed by the > UAS core according to the procedures of Section 8.2.6 of RFC 3261. > In addition, it MUST contain a Require header field containing the > option tag 100rel, and MUST include an RSeq header field. The value > of the header field for the first reliable provisional response in a > transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that > it be chosen uniformly in this range. The RSeq numbering space is > within a single transaction. This means that provisional responses > for different requests MAY use the same values for the RSeq number. >=20 > NEW: > The provisional response to be sent reliably is constructed by the > UAS core according to the procedures of Section 8.2.6 of RFC 3261. > In addition, it MUST contain a Require header field containing the > option tag 100rel, and MUST include an RSeq header field. The > value of the header field for the first reliable provisional > response in a transaction MUST be between 1 and 2**31 - 1. It is > RECOMMENDED that it be chosen uniformly in this range. The RSeq > numbering space is within a single transaction of a single > dialog (or early dialog).This means that provisional responses for diff= erent requests, > and forks of a given request (each fork is associated with a different = early=20 > dialog), might end up using identical, or lower, values for the RSeq nu= mber,=20 > compared to the other forks. >=20 >=20 > Section 4: >=20 > OLD: > If a provisional response is received for an initial request, and > that response contains a Require header field containing the option > tag 100rel, the response is to be sent reliably. If the response is > a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be > ignored, and the procedures below MUST NOT be used. >=20 > NEW: > If a provisional response is received for an initial request, and > that response contains a Require header field containing the option > tag 100rel, the response was sent by the UAS reliably. If the > response is a 100 (Trying) (as opposed to 101 to 199), this option > tag MUST be ignored, and the procedures below MUST NOT be used. >=20 >=20 > OLD: > Assuming the response is to be transmitted reliably, the UAC MUST > create a new request with method PRACK. This request is sent within > the dialog associated with the provisional response (indeed, the > provisional response may have created the dialog). PRACK requests > MAY contain bodies, which are interpreted according to their type and > disposition. >=20 > NEW: > Assuming the response was transmitted reliably by the UAS, the UAC MUST > create a new request with method PRACK. This request is sent within > the dialog associated with the provisional response (indeed, the > provisional response may have created the dialog). PRACK requests > MAY contain bodies, which are interpreted according to their type and > disposition. >=20 >=20 > OLD: > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission when > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain a sequence number that indicates the most recently > received in-order reliable provisional response for the initial > request. This sequence number MUST be maintained until a final > response is received for the initial request. Its value MUST be > initialized to the RSeq header field in the first reliable > provisional response received for the initial request. >=20 > NEW: >=20 > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission when > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain, independently for each dialog ID, a sequence > number that indicates the most recently received in-order reliable > provisional response for the initial request. This sequence number > MUST be maintained until a final response is received for the initial > request. Its value MUST, for each dialog (or early dialog), be initiali= zed > to the RSeq header field in the first reliable provisional response,=20 > associated with the dialog, received for the initial request.=20 >=20 >=20 > OLD: > Handling of subsequent reliable provisional responses for the same > initial request follows the same rules as above, with the following > difference: reliable provisional responses are guaranteed to be in > order. As a result, if the UAC receives another reliable provisional > response to the same request, and its RSeq value is not one higher > than the value of the sequence number, that response MUST NOT be > acknowledged with a PRACK, and MUST NOT be processed further by the > UAC. An implementation MAY discard the response, or MAY cache the > response in the hopes of receiving the missing responses. >=20 > NEW: > Subsequent reliable provisional responses for the same initial > request are guaranteed to have been generated by the UAS in the > order of their RSeq values and must be acknowledged in that order. > As a result, if the UAC receives another > reliable provisional response to the same request, and its RSeq > value is one higher than the value of the previously received RSeq > value in the dialog (or early dialog), then the new RSeq value is saved= and the > response is handled as described above. If the RSeq value is not one > higher than the value of the sequence number, that response MUST NOT > be acknowledged with a PRACK, and MUST NOT be processed further by > the UAC. An implementation MAY discard the response, or MAY cache > the response to be processed (and acknowledged) after receiving > the missing responses. >=20 >=20 > ------------- >=20 > Can I go ahead and create a new errata? :) >=20 > Regards, >=20 > Christer >=20 >=20 From nobody Mon Dec 14 08:41: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 F059E1AC3A6 for ; Mon, 14 Dec 2015 08:41:45 -0800 (PST) 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 jyAJWXrmJzOA for ; Mon, 14 Dec 2015 08:41:44 -0800 (PST) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46AA31AC3E8 for ; Mon, 14 Dec 2015 08:40:31 -0800 (PST) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-02v.sys.comcast.net with comcast id tUfZ1r0042TL4Rh01UgWli; Mon, 14 Dec 2015 16:40:30 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-17v.sys.comcast.net with comcast id tUgV1r00J1nMCLR01UgVc8; Mon, 14 Dec 2015 16:40:30 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id tBEGeT6m018635; Mon, 14 Dec 2015 11:40:29 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id tBEGeSO5018631; Mon, 14 Dec 2015 11:40:28 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C966CE@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 14 Dec 2015 11:40:28 -0500 Message-ID: <874mfl3rwj.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1450111230; bh=xEalw1iUygfiH7sKZV1KjlgAn//YUjXMICCYVTmL+0U=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=iEQMSYYUKHuExAne6ePcaFdaNzDCjJd7nkiPxaEW3fXBpf4v7gyNQZLZ//Ct/ZK2r 5rn22+CkT6MYucSjDpgkeky5TSh1wovY/JhfUACorrFSCrAU8mb831AsmugAorcTqo GMGI3Gy8buP9WBWJFxpiC6aNUaq15MratNO4KLxQnYSbEw31bbJf3Qz4zQXmCk4tyH /rpn5xi+pXz/0DB5jjjo93OQXlldvLv8HqN55ZwIqrZuXYjKOAhMOB4ZBVZLbIWj9b o+F+CuaRNjVjYWlb9JfEqr0JX/mrMEpSJMUDLlKcAKQQ1NhKBKwlksOxVI0AmwdEqB neVwi1+OXbvZQ== Archived-At: Cc: ben@nostrum.com, sipcore@ietf.org Subject: Re: [sipcore] RSeq and forking - Errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 16:41:46 -0000 I like your suggested changes. Let me flesh out this point: Christer Holmberg writes: >> Once a reliable provisional response is received, retransmissions of >> that response MUST be discarded. A response is a retransmission when >> its dialog ID, CSeq, and RSeq match the original response. The UAC >> MUST maintain<<, independently for each dialog ID,>> a sequence >> number that indicates the most recently received in-order reliable >> provisional response for the initial request. This sequence number >> MUST be maintained until a final response is received for the initial >> request. Its value MUST be initialized to the RSeq header field in >> the first reliable provisional response received for the initial >> request<< in a dialog>>. > > I am ok with the first change. > > However, the second change "initial request in a dialog" sounds a little confusing. The dialog is created when the response of a previous request is received. > > Perhaps: > >> "Its value MUST<<, for each dialog (or early dialog),>> be initialized to the RSeq header field in >> the first reliable provisional response<<, associated with the dialog,>> received for the initial >> request. I see now that I should have said "... the initial request<< in THAT dialog>>". Your wording makes the same change, but more explicitly. This change seems awkward to me: > "... The RSeq numbering space is within a single transaction ... . > This means that provisional responses for different requests, and > forks of a given request (each fork is associated with a different > early dialog), might end up using identical, or lower, values for > the RSeq number, compared to the other forks." That wording is clearer but seems awkward to me. Also, this paragraph is part of the text describing how a UAS sends the *first* reliable provisional response of a transaction, so the text isn't in a position to describe the entire sequence of RSeq numbers used in the set of reliable provisional responses in a single fork of a single request. Maybe this is better: > "... The RSeq numbering space is within a single transaction ... . > This means that RSeq value of the first provisional response within > a fork of a request is independent of the RSeq value of the first > provisional response within any other fork of that request, or for > the responses for any other request. It thus may be higher, lower, > or the same as any other such RSeq value. Dale From nobody Mon Dec 14 14:29:26 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6B41A0093 for ; Mon, 14 Dec 2015 14:29:24 -0800 (PST) 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 rhdkwrTHzDPp for ; Mon, 14 Dec 2015 14:29:22 -0800 (PST) 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 CB4871A0091 for ; Mon, 14 Dec 2015 14:29:22 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBEMTKYV033253 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 Dec 2015 16:29:20 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Paul Kyzivat" Date: Mon, 14 Dec 2015 16:29:20 -0600 Message-ID: <6263C891-71DE-41F8-91F8-6FFF7A71A091@nostrum.com> In-Reply-To: <5666EAC4.1040601@alum.mit.edu> References: <20151204140645.77D7B180004@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37C8372C@ESESSMB209.ericsson.se> <56635188.40009@nostrum.com> <6CF3A5B1-90E7-4F50-8424-0315287BB712@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C8B0E1@ESESSMB209.ericsson.se> <9FFEF072-6575-4FB8-8C80-E850F43F9BD6@nostrum.com> <5666EAC4.1040601@alum.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] [Technical Errata Reported] RFC3261 (4553) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 22:29:24 -0000 On 8 Dec 2015, at 8:35, Paul Kyzivat wrote: > I guess Ben's argument here is that there is a straightforward > work-around (insert a C-D rather than depending on the default) that > is entirely compliant to the standards and will fix the interop > problem. I wish I could take take credit for that, because it's a much better argument than mine :-) I had more in mind that a default of "required" would encourage people to fix implementations due to all the failed calls. I meant that at least sort of facetiously. > > That still leaves an issue that ought to be resolved, but it reduces > the urgency of addressing it. In any case, it seems to me from discussion so far that we do not have a settled consensus on what the default value of the handling parameter should be when C-D is not present. That suggests this should be done in an I-D, not in an erratum. If people disagree with that, please speak up. > > Thanks, > Paul > > On 12/8/15 9:11 AM, Ben Campbell wrote: >> >> >> On 8 Dec 2015, at 1:33, Christer Holmberg wrote: >> >>> Hi, >>> >>>> I am inclined to mark this, as submitted, as "hold for update", >>>> which >>>> I suspect is not what Christer wants to hear. >>> >>> Correct :) >>> >>>> There are two parts to this: >>>> >>>> Adding "or if the Content-Disposition header field is missing" >>>> seems >>>> reasonable. I have trouble imagining that the original intent was >>>> not >>>> exactly that. But I would like to >>>> see a bit more discussion about whether this is likely to cause >>>> unnecessary transaction failure. Would we expect the UAS to reject >>>> any request that had a a body with an >>>> unknown MIME type and no content-disposition? >>> >>> The alternative is having cases where different people make >>> different >>> assumptions, so that the same transaction is sometimes rejected, and >>> sometimes not, depending on what UAS the request reaches. That is >>> not >>> good, and makes it impossible to write specifications etc. >> >> Sure--but is that what we want it to do? It almost seems to me that >> if >> the sender wants the body part to be "required", it can say so. Is >> there >> a reasonable "success friendly" option here? >> >> If the answer to that requires thought or discussion, then maybe this >> should go in a draft, not an eratta. >> >>> >>>> The change from SHOULD to MUST second guesses the original intent. >>>> I >>>> don't think we have a reason to think people really meant to write >>>> MUST. >>>> Rather, I think this is more a (potentially reasonable) change in >>>> expectations between then and now. Also, list discussion on that >>>> point did not seem conclusive. It seem to me that if people want to >>>> make that change, it needs to be in the form of an update. >>> >>> I am ok to leave the "SHOULD->MUST" part outside the errata, and >>> handle that in an update. >>> >>>> Christer, you mentioned that this is causing deployment problems. >>>> Can >>>> you elaborate on the nature of those problems? >>> >>> Yes. Unfortunately I can't give any company names, so I'll call them >>> company X and company Y. >>> >>> - Company X UA sends a SIP request with a message body (I don't >>> remember the MIME type, but it doesn't really matter - it is not >>> SDP), >>> *WITHOUT* a C-D header field. >>> - Company Y UA does NOT support the MIME type, and assumes that the >>> absence of C-D means handling="required". So, company Y rejects the >>> request. >>> - Company X claims that it is wrong behavior to reject the request, >>> because since there is no C-D header field one should not assume >>> handling="required". Instead, the company Y UA should simply discard >>> the message body. >>> - Company Y claims that the absence of C-D means >>> handling="required", >>> and that rejecting the request is correct behavior. >>> >>> This is causing a serious amount of call failures in existing >>> deployments, and has been escalated up the ladders. >> >> Sounds like a default to "required" will cause even more call >> failures. >> I guess you might could use that as a lever to force Company X to >> insert >> C-D. Is that the preferred outcome? >> >>> >>> Sure, company X and Y could perhaps agree on some fix to handle >>> this. >>> But, later the same issue may later pop up somewhere else. The spec >>> needs to be clear on this, since we are talking about a case that >>> can >>> cause a SIP INVITE request to be rejected. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Dec 14 15:00: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 22B5C1A21A1 for ; Mon, 14 Dec 2015 15:00:45 -0800 (PST) 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 qaT3gKYhNyDK for ; Mon, 14 Dec 2015 15:00:43 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326181A219C for ; Mon, 14 Dec 2015 15:00:43 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-05v.sys.comcast.net with comcast id tav21r0022S2Q5R01b0inK; Mon, 14 Dec 2015 23:00:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-16v.sys.comcast.net with comcast id tb0h1r0093KdFy101b0hsl; Mon, 14 Dec 2015 23:00:42 +0000 To: Ben Campbell References: <20151204140645.77D7B180004@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37C8372C@ESESSMB209.ericsson.se> <56635188.40009@nostrum.com> <6CF3A5B1-90E7-4F50-8424-0315287BB712@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C8B0E1@ESESSMB209.ericsson.se> <9FFEF072-6575-4FB8-8C80-E850F43F9BD6@nostrum.com> <5666EAC4.1040601@alum.mit.edu> <6263C891-71DE-41F8-91F8-6FFF7A71A091@nostrum.com> From: Paul Kyzivat Message-ID: <566F4A18.8010503@alum.mit.edu> Date: Mon, 14 Dec 2015 18:00:40 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <6263C891-71DE-41F8-91F8-6FFF7A71A091@nostrum.com> 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=1450134042; bh=0jyqD6WtqzNP+7HxEYWobhZthDMnwYxge3CrpHtP0iA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=I51cRM7uv3PM76FlYJw+ARRyVTkHKIvJoX61QeRJA23UF0+EGGLf/y1Fz/muQ/rjA 0Y5DiYwIOmYU52VyT0+J41x0Y+/Wfh/G3eosH7hcaHMB2aknfsjn5XOfEa3gcRKwz5 xuCnvOHYWJyh7azgjkYHQysYrjme8691zHSPi4bDIo8exfWVdWpuQZ8zsKDI3aOlNI 88dGgar+mNbtBsL9iMXYkxontpf01sOBYF3kU1mj3ez3zz7qQourClKv+8+tsCVID7 xMI/hPju2OMTzHYWq6RI6f+bzrEGvBc00ZRCdJXMC5zHRrEqluLfsJDMnsirfjvO7M uSdUmmnUs9gFw== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] [Technical Errata Reported] RFC3261 (4553) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 23:00:45 -0000 On 12/14/15 5:29 PM, Ben Campbell wrote: > In any case, it seems to me from discussion so far that we do not have a > settled consensus on what the default value of the handling parameter > should be when C-D is not present. That suggests this should be done in > an I-D, not in an erratum. If people disagree with that, please speak up. I don't know if we have consensus. But is there any plausible argument for why the default should be different when the C-D is missing from when it is present but doesn't have a handling parameter? The only one I can think of would be if each distinct C-D value could have its own default value for handling. But that is itself nonsense. The purpose of the parameter is for when the recipient doesn't understand the value. In that case it won't know the default for that parameter. Thanks, Paul From nobody Mon Dec 14 15:22:06 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 27E9F1A802D for ; Mon, 14 Dec 2015 15:22:04 -0800 (PST) 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 ucWegrGICNtj for ; Mon, 14 Dec 2015 15:22:02 -0800 (PST) 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 140F01A802A for ; Mon, 14 Dec 2015 15:22:00 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBENLvXP038204 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 Dec 2015 17:21:58 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Paul Kyzivat" Date: Mon, 14 Dec 2015 17:21:57 -0600 Message-ID: In-Reply-To: <566F4A18.8010503@alum.mit.edu> References: <20151204140645.77D7B180004@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37C8372C@ESESSMB209.ericsson.se> <56635188.40009@nostrum.com> <6CF3A5B1-90E7-4F50-8424-0315287BB712@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C8B0E1@ESESSMB209.ericsson.se> <9FFEF072-6575-4FB8-8C80-E850F43F9BD6@nostrum.com> <5666EAC4.1040601@alum.mit.edu> <6263C891-71DE-41F8-91F8-6FFF7A71A091@nostrum.com> <566F4A18.8010503@alum.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] [Technical Errata Reported] RFC3261 (4553) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2015 23:22:04 -0000 On 14 Dec 2015, at 17:00, Paul Kyzivat wrote: > On 12/14/15 5:29 PM, Ben Campbell wrote: > >> In any case, it seems to me from discussion so far that we do not >> have a >> settled consensus on what the default value of the handling parameter >> should be when C-D is not present. That suggests this should be done >> in >> an I-D, not in an erratum. If people disagree with that, please >> speak up. > > I don't know if we have consensus. But is there any plausible argument > for why the default should be different when the C-D is missing from > when it is present but doesn't have a handling parameter? > I agree that this is already settled for the case where C-D is present but with no handling parameter, and consistency is a strong argument. But do we think it makes sense to say "If the content is critical, put in C-D" rather than "If the content is _not_ critical, put in C-D"? Do we really think "required" is or will be the most common case, or that the risk of accidentally failing to render critical content is high enough to default to failure? I'm personally on the fence here, if everyone paying attention thinks consistency with the default when C-D is present is the correct way to handle this, and was the original intent in 3261, then an erratum makes sense. But if we feel the need to discuss this further, this probably should come in the form of an I-D, even if the final answer is the same. (If it's not obvious, I question why people decided to make "required" the default when C-D is _present_, but that's water under the bridge.) > The only one I can think of would be if each distinct C-D value could > have its own default value for handling. But that is itself nonsense. > The purpose of the parameter is for when the recipient doesn't > understand the value. In that case it won't know the default for that > parameter. I agree with that part. > > Thanks, > Paul From nobody Mon Dec 14 16:53: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 79E2E1ACEDF for ; Mon, 14 Dec 2015 16:53:29 -0800 (PST) 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 uXvBD9ZuztFi for ; Mon, 14 Dec 2015 16:53:28 -0800 (PST) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9B01ABB19 for ; Mon, 14 Dec 2015 16:53:00 -0800 (PST) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-09v.sys.comcast.net with comcast id tcsr1r00356HXL001cszhR; Tue, 15 Dec 2015 00:52:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-12v.sys.comcast.net with comcast id tcsy1r0033KdFy101csyt8; Tue, 15 Dec 2015 00:52:59 +0000 To: Ben Campbell References: <20151204140645.77D7B180004@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37C8372C@ESESSMB209.ericsson.se> <56635188.40009@nostrum.com> <6CF3A5B1-90E7-4F50-8424-0315287BB712@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C8B0E1@ESESSMB209.ericsson.se> <9FFEF072-6575-4FB8-8C80-E850F43F9BD6@nostrum.com> <5666EAC4.1040601@alum.mit.edu> <6263C891-71DE-41F8-91F8-6FFF7A71A091@nostrum.com> <566F4A18.8010503@alum.mit.edu> From: Paul Kyzivat Message-ID: <566F6469.2000102@alum.mit.edu> Date: Mon, 14 Dec 2015 19:52:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1450140779; bh=hxVP51F3IIi5Nq9/MDM3ddz1DAc76DOZiApH1CIKMAk=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=udgGIgNk8uvl65LlC6y8n4jVZ40AcoC0j9ngT5NcjmfdO6/VnE/7cK2E6OEILlReO EfUDY30rvEoqFVJphXzNcXB0rP0druXX2BawR6gH1Luo1D/TD6u1jgjxnGa3851FDN 0gN5+FGlXGRZKdf6Pu3SM2IFkOt3r+oL02VCSHnL/P99xhWgxF5Z8taK5N7dT/acf8 sixfbDIytugbA6UkWjCOAXN/7VACjJ7eJgi4YnMJ1RD7LhtZDS14CDo0fWmksfjD9v 2KOHLHQ1500OebSXJITvUbSeGOJVGxSi+UGG4nALaGTBoNM1BIBymTyEHpzUEHuqaG 97tlJbYM6Nhcw== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] [Technical Errata Reported] RFC3261 (4553) 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, 15 Dec 2015 00:53:29 -0000 On 12/14/15 6:21 PM, Ben Campbell wrote: > On 14 Dec 2015, at 17:00, Paul Kyzivat wrote: > >> On 12/14/15 5:29 PM, Ben Campbell wrote: >> >>> In any case, it seems to me from discussion so far that we do not have a >>> settled consensus on what the default value of the handling parameter >>> should be when C-D is not present. That suggests this should be done in >>> an I-D, not in an erratum. If people disagree with that, please >>> speak up. >> >> I don't know if we have consensus. But is there any plausible argument >> for why the default should be different when the C-D is missing from >> when it is present but doesn't have a handling parameter? >> > > I agree that this is already settled for the case where C-D is present > but with no handling parameter, and consistency is a strong argument. > But do we think it makes sense to say "If the content is critical, put > in C-D" rather than "If the content is _not_ critical, put in C-D"? Do > we really think "required" is or will be the most common case, or that > the risk of accidentally failing to render critical content is high > enough to default to failure? > > > I'm personally on the fence here, if everyone paying attention thinks > consistency with the default when C-D is present is the correct way to > handle this, and was the original intent in 3261, then an erratum makes > sense. But if we feel the need to discuss this further, this probably > should come in the form of an I-D, even if the final answer is the same. Well, in the case where there is no C-D, and the C-T is SDP, then the default is handling=required. Is that enough to convince you? Thanks, Paul From nobody Mon Dec 14 17:31: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 0ACDF1AD06E for ; Mon, 14 Dec 2015 17:31:35 -0800 (PST) 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 7ogNifVoogLC for ; Mon, 14 Dec 2015 17:31:33 -0800 (PST) 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 513CE1AD06B for ; Mon, 14 Dec 2015 17:31:33 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBF1VTG5049579 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 14 Dec 2015 19:31:31 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Paul Kyzivat" Date: Mon, 14 Dec 2015 19:31:30 -0600 Message-ID: In-Reply-To: <566F6469.2000102@alum.mit.edu> References: <20151204140645.77D7B180004@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37C8372C@ESESSMB209.ericsson.se> <56635188.40009@nostrum.com> <6CF3A5B1-90E7-4F50-8424-0315287BB712@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C8B0E1@ESESSMB209.ericsson.se> <9FFEF072-6575-4FB8-8C80-E850F43F9BD6@nostrum.com> <5666EAC4.1040601@alum.mit.edu> <6263C891-71DE-41F8-91F8-6FFF7A71A091@nostrum.com> <566F4A18.8010503@alum.mit.edu> <566F6469.2000102@alum.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] [Technical Errata Reported] RFC3261 (4553) 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, 15 Dec 2015 01:31:35 -0000 On 14 Dec 2015, at 18:52, Paul Kyzivat wrote: > On 12/14/15 6:21 PM, Ben Campbell wrote: >> On 14 Dec 2015, at 17:00, Paul Kyzivat wrote: >> >>> On 12/14/15 5:29 PM, Ben Campbell wrote: >>> >>>> In any case, it seems to me from discussion so far that we do not >>>> have a >>>> settled consensus on what the default value of the handling >>>> parameter >>>> should be when C-D is not present. That suggests this should be >>>> done in >>>> an I-D, not in an erratum. If people disagree with that, please >>>> speak up. >>> >>> I don't know if we have consensus. But is there any plausible >>> argument >>> for why the default should be different when the C-D is missing from >>> when it is present but doesn't have a handling parameter? >>> >> >> I agree that this is already settled for the case where C-D is >> present >> but with no handling parameter, and consistency is a strong argument. >> But do we think it makes sense to say "If the content is critical, >> put >> in C-D" rather than "If the content is _not_ critical, put in C-D"? >> Do >> we really think "required" is or will be the most common case, or >> that >> the risk of accidentally failing to render critical content is high >> enough to default to failure? >> >> >> I'm personally on the fence here, if everyone paying attention thinks >> consistency with the default when C-D is present is the correct way >> to >> handle this, and was the original intent in 3261, then an erratum >> makes >> sense. But if we feel the need to discuss this further, this probably >> should come in the form of an I-D, even if the final answer is the >> same. > > Well, in the case where there is no C-D, and the C-T is SDP, then the > default is handling=required. Is that enough to convince you? SDP has a rather privileged place in SIP messages. But let me turn that around. Are you convinced? Does anyone else thing this needs further discussion? If you are, and no one else speaks out really soon now[1], I would approve an erratum without the SHOULD to MUST bit. [*] Meaning, "before such an erratum arrives in my email." Ben. > > Thanks, > Paul From nobody Mon Dec 14 20:26:23 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 DF5951B2A9D for ; Mon, 14 Dec 2015 20:26:22 -0800 (PST) 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 2SCclim5YKyu for ; Mon, 14 Dec 2015 20:26:21 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740011B2A9C for ; Mon, 14 Dec 2015 20:26:20 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-05v.sys.comcast.net with comcast id tgSC1r0052XD5SV01gSKMB; Tue, 15 Dec 2015 04:26:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-20v.sys.comcast.net with comcast id tgSJ1r0083KdFy101gSJGS; Tue, 15 Dec 2015 04:26:19 +0000 To: Ben Campbell References: <20151204140645.77D7B180004@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37C8372C@ESESSMB209.ericsson.se> <56635188.40009@nostrum.com> <6CF3A5B1-90E7-4F50-8424-0315287BB712@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C8B0E1@ESESSMB209.ericsson.se> <9FFEF072-6575-4FB8-8C80-E850F43F9BD6@nostrum.com> <5666EAC4.1040601@alum.mit.edu> <6263C891-71DE-41F8-91F8-6FFF7A71A091@nostrum.com> <566F4A18.8010503@alum.mit.edu> <566F6469.2000102@alum.mit.edu> From: Paul Kyzivat Message-ID: <566F9668.4000000@alum.mit.edu> Date: Mon, 14 Dec 2015 23:26:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1450153579; bh=KMA/HANFQQnFqiB0BcuUQi66G1TPxq/LsCGBEuiAm3Y=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=dWQc/FrDhvehUUaUPsO7gsF/LlGGvMp3dOQ4W336+qWhKsEFBXt3oyMWV2rvE72gF p4ICxSIRHLbHpLnO7y65ReCh6vEf+eV0hlxxeQKorA6va6/ryMCt+gPhkrpI0lLd0S n0/JFIpUoj9eGXIjjCdAk5DcM0FGxYZ9ZrEmts78qcidqVClyY4rmYSbF+qbDS9LOH jam4/X+bsdTqfm0K4YEdK16MiGZDRvK/HK1ET6ic9iVNhonV7WGqT4esLsRIH64M1m nWRWjhLCtmwAp8uKlQ9WskAHHbLnRzL9svUC+oFOm78H7RAL4rhJlQbv3hmGgamxSM 1F+hjpf9DCPXQ== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] [Technical Errata Reported] RFC3261 (4553) 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, 15 Dec 2015 04:26:23 -0000 On 12/14/15 8:31 PM, Ben Campbell wrote: > On 14 Dec 2015, at 18:52, Paul Kyzivat wrote: > >> On 12/14/15 6:21 PM, Ben Campbell wrote: >>> On 14 Dec 2015, at 17:00, Paul Kyzivat wrote: >>> >>>> On 12/14/15 5:29 PM, Ben Campbell wrote: >>>> >>>>> In any case, it seems to me from discussion so far that we do not >>>>> have a >>>>> settled consensus on what the default value of the handling parameter >>>>> should be when C-D is not present. That suggests this should be >>>>> done in >>>>> an I-D, not in an erratum. If people disagree with that, please >>>>> speak up. >>>> >>>> I don't know if we have consensus. But is there any plausible argument >>>> for why the default should be different when the C-D is missing from >>>> when it is present but doesn't have a handling parameter? >>>> >>> >>> I agree that this is already settled for the case where C-D is present >>> but with no handling parameter, and consistency is a strong argument. >>> But do we think it makes sense to say "If the content is critical, put >>> in C-D" rather than "If the content is _not_ critical, put in C-D"? Do >>> we really think "required" is or will be the most common case, or that >>> the risk of accidentally failing to render critical content is high >>> enough to default to failure? >>> >>> >>> I'm personally on the fence here, if everyone paying attention thinks >>> consistency with the default when C-D is present is the correct way to >>> handle this, and was the original intent in 3261, then an erratum makes >>> sense. But if we feel the need to discuss this further, this probably >>> should come in the form of an I-D, even if the final answer is the same. >> >> Well, in the case where there is no C-D, and the C-T is SDP, then the >> default is handling=required. Is that enough to convince you? > > SDP has a rather privileged place in SIP messages. Yes, it does. But some effort was made to arrange a consistent set of general rules for bodies that is backward compatible with that. > But let me turn that around. Are you convinced? Does anyone else thing > this needs further discussion? If you are, and no one else speaks out > really soon now[1], I would approve an erratum without the SHOULD to > MUST bit. > > [*] Meaning, "before such an erratum arrives in my email." Yes, I'm convinced. Thanks, Paul From nobody Tue Dec 15 00:03:10 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 9589B1A8754 for ; Tue, 15 Dec 2015 00:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Cy4FFPSaRSBE for ; Tue, 15 Dec 2015 00:03:07 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BDC71A8753 for ; Tue, 15 Dec 2015 00:03:07 -0800 (PST) X-AuditID: c1b4fb2d-f79456d000001332-17-566fc939dd5d Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 20.2D.04914.939CF665; Tue, 15 Dec 2015 09:03:05 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0248.002; Tue, 15 Dec 2015 09:03:05 +0100 From: Christer Holmberg To: Paul Kyzivat , Ben Campbell Thread-Topic: [sipcore] [Technical Errata Reported] RFC3261 (4553) Thread-Index: AQHRMTeSIo2kj1TwkUCTfZn6k/6AuJ7ArrtAgABi1oCAAAaxAIAJ8ksAgAAIwQCAAAXygIAAGW2AgAAKxQCAADDVAIAATRLA Date: Tue, 15 Dec 2015 08:03:03 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37CDCADF@ESESSMB209.ericsson.se> References: <20151204140645.77D7B180004@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37C8372C@ESESSMB209.ericsson.se> <56635188.40009@nostrum.com> <6CF3A5B1-90E7-4F50-8424-0315287BB712@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C8B0E1@ESESSMB209.ericsson.se> <9FFEF072-6575-4FB8-8C80-E850F43F9BD6@nostrum.com> <5666EAC4.1040601@alum.mit.edu> <6263C891-71DE-41F8-91F8-6FFF7A71A091@nostrum.com> <566F4A18.8010503@alum.mit.edu> <566F6469.2000102@alum.mit.edu> <566F9668.4000000@alum.mit.edu> In-Reply-To: <566F9668.4000000@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.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7q67lyfwwg137VSzmd55mt1ix4QCr xdcfm9gcmD3+vv/A5LFkyU8mj1k7n7AEMEdx2aSk5mSWpRbp2yVwZWzesp2loJW54nj/V7YG xlVMXYycHBICJhKT7+1ng7DFJC7cWw9kc3EICRxmlHh8/z8jhLOYUeL2t13MXYwcHGwCFhLd /7RBGkQEPCRWTHnMCmIzC2hKPNq5F2yosICjRPucrewQNU4SrWd/MELYeRJr3mwGi7MIqEoc a70MFucV8JU42wkSB9n1nkXi3JcLYEWcAjoSh9c1MYPYjEDXfT+1hglimbjErSfzoT4QkFiy 5zwzhC0q8fLxP1YIW1Fi59l2Zoh6HYkFuz+xQdjaEssWvmaGWCwocXLmE5YJjGKzkIydhaRl FpKWWUhaFjCyrGIULU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQIjKqDW37r7mBc/drxEKMAB6MS D+8GwfwwIdbEsuLK3EOMEhzMSiK8C3qBQrwpiZVVqUX58UWlOanFhxilOViUxHlbmB6ECgmk J5akZqemFqQWwWSZODilGhgTm3XapBj5N7SEqjv3N53buHRe3K3ZDtlnGTxWr3dZHrupM9DD 8Mrq60YRi1uOe9cplK7hYrrirPXGP3nqyVXbX8ZPSGGym8B3guWNSVd+XuXTjQbctXIKynMK 5XIv/1c6k7ZzAn/vryduDw3vnd557bq3TJ/2xTtPhdTDZnNsfp2hfubQ3KVKLMUZiYZazEXF iQBGgmfcpgIAAA== Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] [Technical Errata Reported] RFC3261 (4553) 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, 15 Dec 2015 08:03:08 -0000 Hi, ... >> But let me turn that around. Are you convinced? Does anyone else thing=20 >> this needs further discussion? If you are, and no one else speaks out=20 >> really soon now[1], I would approve an erratum without the SHOULD to=20 >> MUST bit. >> >> [*] Meaning, "before such an erratum arrives in my email." > > Yes, I'm convinced. Me too :) Regards, Christer From nobody Tue Dec 15 00:11: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 C01EB1A7014 for ; Tue, 15 Dec 2015 00:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ec7IFF90XCSy for ; Tue, 15 Dec 2015 00:11:27 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F82A1A7012 for ; Tue, 15 Dec 2015 00:11:27 -0800 (PST) X-AuditID: c1b4fb25-f79876d0000011ee-94-566fcb2d516d Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 53.5D.04590.D2BCF665; Tue, 15 Dec 2015 09:11:25 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Tue, 15 Dec 2015 09:11:24 +0100 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [sipcore] RSeq and forking - Errata Thread-Index: AQHRNo4jaIhPA9HcRsaaDgKN4yT4tJ7LsWHg Date: Tue, 15 Dec 2015 08:11:23 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37CDCB65@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37C966CE@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) <874mfl3rwj.fsf@hobgoblin.ariadne.com> In-Reply-To: <874mfl3rwj.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM2K7sa7u6fwwgyvtchbzO0+zWzR0rmS1 WLHhAKvF1x+b2CxenihzYPX4+/4Dk8fk/V+ZPZYs+cnkMWvnE5YAligum5TUnMyy1CJ9uwSu jBVL/rAWrOKrmP7sFksD402uLkZODgkBE4lt3/+xQNhiEhfurWfrYuTiEBI4zChx+PUMNpCE kMBiRonnhxK7GDk42AQsJLr/aYOYIgKaEh0LckDKmQU2MEps6mlmBykXFjCQ+PHlBdhMEQFD iZMn2qFsI4mnDceYQGwWAVWJh186GEHm8Ar4Sjy5HQyxdjqjxOPuLkaQGk4BY4nXny4yg9iM QLd9P7UGrJdZQFzi1pP5TBA3C0gs2XOeGcIWlXj5+B8rhK0osfNsOzNEvY7Egt2f2CBsbYll C1+DxXkFBCVOznzCMoFRbBaSsbOQtMxC0jILScsCRpZVjKLFqcVJuelGxnqpRZnJxcX5eXp5 qSWbGIHRdnDLb9UdjJffOB5iFOBgVOLh3SCYHybEmlhWXJl7iFGCg1lJhHdBL1CINyWxsiq1 KD++qDQntfgQozQHi5I4bzPTg1AhgfTEktTs1NSC1CKYLBMHp1QD40T20qZlN06lHtosa9AX sWt6dfi8Swz6S/1KFDTXS1RIvXjbsnxKWfnW6AdmK399v1DlGKV8Wzq15scdPt6iUKGfhVaO 6dfipj/m6CzsL1jd77Xmdp/Fjb3N5yeWTbKNeZrauX9d7VwZF0/vAx3lhc+SHt0N4WURYuK5 w+fot+eVwLba4u21SizFGYmGWsxFxYkAz5c01rICAAA= Archived-At: Cc: "ben@nostrum.com" , "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Errata X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 08:11:28 -0000 Hi, ... >> "... The RSeq numbering space is within a single transaction ... . >> This means that provisional responses for different requests, and >> forks of a given request (each fork is associated with a different >> early dialog), might end up using identical, or lower, values for >> the RSeq number, compared to the other forks." > > That wording is clearer but seems awkward to me. Also, this paragraph is= part of the text describing how a UAS sends the *first* reliable provision= al response=20 > of a transaction, so the text isn't in a position to describe the entire = sequence of RSeq numbers used in the set of reliable provisional responses = in a single fork=20 > of a single request. > > Maybe this is better: > > "... The RSeq numbering space is within a single transaction ... . > This means that RSeq value of the first provisional response within > a fork of a request is independent of the RSeq value of the first > provisional response within any other fork of that request, or for > the responses for any other request. It thus may be higher, lower, > or the same as any other such RSeq value. Your text looks good, but I don't think we should say " RSeq value of the f= irst provisional resposne", because it applies to the RSeq values of all pr= ovisional responses. So: "... The RSeq numbering space is within a single transaction ..= . . This means that RSeq value of a provisional response within a fork of a request is independent of the RSeq value of a provisional response within any other fork of that request, or = for the responses for any other request. It thus may be higher, lo= wer, or the same as any other such RSeq value. Regards, Christer From nobody Thu Dec 17 04:30:59 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 72FAD1B2A96 for ; Thu, 17 Dec 2015 04:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wfmi-KPbRAJg for ; Thu, 17 Dec 2015 04:30:54 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E75BD1A87AC for ; Thu, 17 Dec 2015 04:30:53 -0800 (PST) X-AuditID: c1b4fb25-f79876d0000011ee-eb-5672aafbc1c3 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 1C.61.04590.BFAA2765; Thu, 17 Dec 2015 13:30:52 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Thu, 17 Dec 2015 13:30:51 +0100 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , Ben Campbell Thread-Topic: [sipcore] [Technical Errata Reported] RFC3261 (4553) Thread-Index: AQHRMTeSIo2kj1TwkUCTfZn6k/6AuJ7ArrtAgABi1oCAAAaxAIAJ8ksAgAAIwQCAAAXygIAAGW2AgAAKxQCAADDVAIAATRLAgANvmPA= Date: Thu, 17 Dec 2015 12:30:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37CE7CBD@ESESSMB209.ericsson.se> References: <20151204140645.77D7B180004@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B37C8372C@ESESSMB209.ericsson.se> <56635188.40009@nostrum.com> <6CF3A5B1-90E7-4F50-8424-0315287BB712@nostrum.com> <7594FB04B1934943A5C02806D1A2204B37C8B0E1@ESESSMB209.ericsson.se> <9FFEF072-6575-4FB8-8C80-E850F43F9BD6@nostrum.com> <5666EAC4.1040601@alum.mit.edu> <6263C891-71DE-41F8-91F8-6FFF7A71A091@nostrum.com> <566F4A18.8010503@alum.mit.edu> <566F6469.2000102@alum.mit.edu> <566F9668.4000000@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37CDCADF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37CDCADF@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.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyM2K7ge6fVUVhBhu7uC3md55mt1ix4QCr xdcfm9gcmD3+vv/A5LFkyU8mj1k7n7AEMEdx2aSk5mSWpRbp2yVwZbQc62QpmMVecfrfP8YG xlesXYycHBICJhLLPk9lh7DFJC7cW8/WxcjFISRwmFFi6/UpUM5iRonWQ4uBHA4ONgELie5/ 2iANIgJ1Els/PgEbxCygKfFo514mEFtYwFGifc5WdogaJ4nWsz8YQVpFBMokljwvAgmzCKhK /Pt4CayEV8BX4kVPB9SqzawST+ZMYAKp5xTwk9h6LAGkhhHotu+n1jBBrBKXuPVkPhPEzQIS S/acZ4awRSVePv7HCtIqIaAkMW1rGkS5jsSC3Z/YIGxtiWULXzNDrBWUODnzCcsERrFZSKbO QtIyC0nLLCQtCxhZVjGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIExtPBLb9VdzBefuN4iFGA g1GJh/fDm8IwIdbEsuLK3EOMEhzMSiK8vhOLwoR4UxIrq1KL8uOLSnNSiw8xSnOwKInzNjM9 CBUSSE8sSc1OTS1ILYLJMnFwSjUwinyN+DH5NqNvQMfuoJl9SglC+fqJ2/gOS/D8bdGfOlHy /zG7l1av22/2/GnsDnzluSnkQbvFXZsjkguup68q3OOzxen22inpqeqb3lopHXNYHOjkOvnv ewW3N737fl3zK2Du3pDAxJK2+mjm71Ijni1umy4v33OifFJwUe7ZiYv6zC+mWV3YocRSnJFo qMVcVJwIAKpkGS6jAgAA Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] [Technical Errata Reported] RFC3261 (4553) 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, 17 Dec 2015 12:30:58 -0000 Hi, I have heard no objection, so I will create a new errata, without the SHOUL= D->MUST change. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: 15. joulukuuta 2015 10:03 To: Paul Kyzivat; Ben Campbell Cc: sipcore@ietf.org Subject: Re: [sipcore] [Technical Errata Reported] RFC3261 (4553) Hi, ... >> But let me turn that around. Are you convinced? Does anyone else=20 >> thing this needs further discussion? If you are, and no one else=20 >> speaks out really soon now[1], I would approve an erratum without the=20 >> SHOULD to MUST bit. >> >> [*] Meaning, "before such an erratum arrives in my email." > > Yes, I'm convinced. Me too :) Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Dec 17 05:56:53 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 7C60D1B2DE6 for ; Thu, 17 Dec 2015 05:56:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaEWR5uNcoPx for ; Thu, 17 Dec 2015 05:56:50 -0800 (PST) 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 340FE1B2DAE for ; Thu, 17 Dec 2015 05:56:50 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-8a-5672bf1f1c48 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BA.E4.05041.F1FB2765; Thu, 17 Dec 2015 14:56:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0248.002; Thu, 17 Dec 2015 14:56:47 +0100 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "Gonzalo Salgueiro (gsalguei)" Thread-Topic: [sipcore] RSeq and forking - Text for new errata - New version Thread-Index: AdE40sT+u5te+TuITJOTpS+nQ22kaQ== Date: Thu, 17 Dec 2015 13:56:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37CEAC73@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.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbHdTFdhf1GYQfM/Hov5nafZLeZO8bNY seEAq8XXH5vYLF6eKHNg9fj7/gOTx+T9X5k9pvzeyOqxZMlPJo9ZO5+wBLBGcdmkpOZklqUW 6dslcGUcOXGLpWCiQcWivfeYGhiXqnYxcnBICJhItK9j6WLkBDLFJC7cW8/WxcjFISRwmFHi +q45UM5iRokTb46ygjSwCVhIdP/TBomLCExmlPhx6hY7SDezQLnExzcv2UBsYQFvidW7VjGB 1IsI+EjMPloKEhYR0JN4dWciWAmLgKrEjpZXjCAlvAK+EmsbfEHCjEA3fD+1hgliorjErSfz mSBuE5BYsuc8M4QtKvHy8T9WiPOVJKZtTYMo15FYsPsTG4StLbFs4Wuwcl4BQYmTM5+wTGAU mYVk6iwkLbOQtMxC0rKAkWUVo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmAEHdzy22oH48Hn jocYBTgYlXh4P7wpDBNiTSwrrsw9xCjBwawkwsuwsyhMiDclsbIqtSg/vqg0J7X4EKM0B4uS OG8z04NQIYH0xJLU7NTUgtQimCwTB6cUMH4yj5dc3+N6WHnGWqaH+kn39nmcN7zoo3n4iZxP TTnLudmKD3QNV8wsWccU0jdftvE1d2zlHo7ooDsuJV8nO8UfXtdX1rZgU37lEYcf3xuDxCbt 1Og/PUPOLWm/id+mvbcX7aj57nPi7gTJPcwef313fvkrNk/7ZOwh90yBmiNNHlyyE+9GHVNi Kc5INNRiLipOBAA4uucynAIAAA== Archived-At: Cc: "ben@nostrum.com" , "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Text for new errata - New version 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, 17 Dec 2015 13:56:52 -0000 Hi, New version, based on Dale's last comment: Hi, Based on the e-mail discussion, the new errata would contain the following = change suggestions: ------------ Section 3: OLD: The provisional response to be sent reliably is constructed by the UAS core according to the procedures of Section 8.2.6 of RFC 3261. In addition, it MUST contain a Require header field containing the option tag 100rel, and MUST include an RSeq header field. The value of the header field for the first reliable provisional response in a transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that it be chosen uniformly in this range. The RSeq numbering space is within a single transaction. This means that provisional responses for different requests MAY use the same values for the RSeq number. NEW: The provisional response to be sent reliably is constructed by the UAS core according to the procedures of Section 8.2.6 of RFC 3261. In addition, it MUST contain a Require header field containing the option tag 100rel, and MUST include an RSeq header field. The value of the header field for the first reliable provisional response in a transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that it be chosen uniformly in this range.=20 The RSeq numbering space is within a single transaction. This means that RSeq value of a provisional response within a fork of a request is independent of the RSeq value of a provisional response within any other fork of that request, or for the responses for any other request. It thus may be higher, lower, or the same as any other such RSeq value Section 4: OLD: If a provisional response is received for an initial request, and that response contains a Require header field containing the option tag 100rel, the response is to be sent reliably. If the response is a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be ignored, and the procedures below MUST NOT be used. NEW: If a provisional response is received for an initial request, and that response contains a Require header field containing the option tag 100rel, the response was sent by the UAS reliably. If the response is a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be ignored, and the procedures below MUST NOT be used. OLD: Assuming the response is to be transmitted reliably, the UAC MUST create a new request with method PRACK. This request is sent within the dialog associated with the provisional response (indeed, the provisional response may have created the dialog). PRACK requests MAY contain bodies, which are interpreted according to their type and disposition. NEW: Assuming the response was transmitted reliably by the UAS, the UAC MUST create a new request with method PRACK. This request is sent within the dialog associated with the provisional response (indeed, the provisional response may have created the dialog). PRACK requests MAY contain bodies, which are interpreted according to their type and disposition. OLD: Once a reliable provisional response is received, retransmissions of that response MUST be discarded. A response is a retransmission when its dialog ID, CSeq, and RSeq match the original response. The UAC MUST maintain a sequence number that indicates the most recently received in-order reliable provisional response for the initial request. This sequence number MUST be maintained until a final response is received for the initial request. Its value MUST be initialized to the RSeq header field in the first reliable provisional response received for the initial request. NEW: Once a reliable provisional response is received, retransmissions of that response MUST be discarded. A response is a retransmission when its dialog ID, CSeq, and RSeq match the original response. The UAC MUST maintain, independently for each dialog ID, a sequence number that indicates the most recently received in-order reliable provisional response for the initial request. This sequence number MUST be maintained until a final response is received for the initial request. Its value MUST, for each dialog (or early dialog), be initializ= ed to the RSeq header field in the first reliable provisional response,=20 associated with the dialog, received for the initial request.=20 OLD: Handling of subsequent reliable provisional responses for the same initial request follows the same rules as above, with the following difference: reliable provisional responses are guaranteed to be in order. As a result, if the UAC receives another reliable provisional response to the same request, and its RSeq value is not one higher than the value of the sequence number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache the response in the hopes of receiving the missing responses. NEW: Subsequent reliable provisional responses for the same initial request are guaranteed to have been generated by the UAS in the order of their RSeq values and must be acknowledged in that order. As a result, if the UAC receives another reliable provisional response to the same request, and its RSeq value is one higher than the value of the previously received RSeq value in the dialog (or early dialog), then the new RSeq value is saved = and the response is handled as described above. If the RSeq value is not one higher than the value of the sequence number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache the response to be processed (and acknowledged) after receiving the missing responses. ------------- Can I go ahead and create a new errata? :) Regards, Christer From nobody Thu Dec 17 06:58: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 AAE021B2E74 for ; Thu, 17 Dec 2015 06:58:23 -0800 (PST) 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 EM-lTFs_X2Mj for ; Thu, 17 Dec 2015 06:58:21 -0800 (PST) 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 C80751B2E79 for ; Thu, 17 Dec 2015 06:58:21 -0800 (PST) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-11v.sys.comcast.net with comcast id uevN1r0032VvR6D01eyMa2; Thu, 17 Dec 2015 14:58:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-19v.sys.comcast.net with comcast id ueyL1r00L3KdFy101eyLRy; Thu, 17 Dec 2015 14:58:21 +0000 To: Christer Holmberg , "Gonzalo Salgueiro (gsalguei)" References: <7594FB04B1934943A5C02806D1A2204B37CEAC73@ESESSMB209.ericsson.se> From: Paul Kyzivat Message-ID: <5672CD8B.8060301@alum.mit.edu> Date: Thu, 17 Dec 2015 09:58:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37CEAC73@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=1450364301; bh=Tzn3uPPV2QZyQJq5CdNFxZJTouJMJVi1h6g1I8ax1dA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=aQxlQ2xz7Y99MRoMLRKIuKLV9gThCTc4g8833NI+mF8nKmvjz8Cl7LzPFLAI++o/1 TYw3GfEanqegMFVkjjqstLKmrpiMSv/NhYxInBec7Ud9Yi9ATdXeO+ZO2UmanAmGRV Cem+Tfft1maIFtafFyMRPkrjF6kOCByWGWUdpMIdSTXFBrNKHWRrmhOXx6s7mY9Sby v7dELcpA1hZW/pVY1yrH3bwJ5PbJCtVowyW8ZSSE6pVlYAvBA4/RW2W1ZJJ8nYqwVK afpb5UxpR8jlE+tMVxjwCfuINn01zM7x5qTJDAar6WyqR6ezlkHKMfrz0oOHkmo88X nG/FgqBXaTaiA== Archived-At: Cc: "ben@nostrum.com" , "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Text for new errata - New version 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, 17 Dec 2015 14:58:23 -0000 This all seems good to me. Thanks, Paul On 12/17/15 8:56 AM, Christer Holmberg wrote: > Hi, > > New version, based on Dale's last comment: > > Hi, > > Based on the e-mail discussion, the new errata would contain the following change suggestions: > > ------------ > > Section 3: > > OLD: > The provisional response to be sent reliably is constructed by the > UAS core according to the procedures of Section 8.2.6 of RFC 3261. > In addition, it MUST contain a Require header field containing the > option tag 100rel, and MUST include an RSeq header field. The value > of the header field for the first reliable provisional response in a > transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that > it be chosen uniformly in this range. The RSeq numbering space is > within a single transaction. This means that provisional responses > for different requests MAY use the same values for the RSeq number. > > NEW: > The provisional response to be sent reliably is constructed by the > UAS core according to the procedures of Section 8.2.6 of RFC 3261. > In addition, it MUST contain a Require header field containing the > option tag 100rel, and MUST include an RSeq header field. The > value of the header field for the first reliable provisional > response in a transaction MUST be between 1 and 2**31 - 1. It is > RECOMMENDED that it be chosen uniformly in this range. > The RSeq numbering space is within a single transaction. > This means that RSeq value of a provisional response within > a fork of a request is independent of the RSeq value of a > provisional response within any other fork of that request, or for > the responses for any other request. It thus may be higher, lower, > or the same as any other such RSeq value > > > Section 4: > > OLD: > If a provisional response is received for an initial request, and > that response contains a Require header field containing the option > tag 100rel, the response is to be sent reliably. If the response is > a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be > ignored, and the procedures below MUST NOT be used. > > NEW: > If a provisional response is received for an initial request, and > that response contains a Require header field containing the option > tag 100rel, the response was sent by the UAS reliably. If the > response is a 100 (Trying) (as opposed to 101 to 199), this option > tag MUST be ignored, and the procedures below MUST NOT be used. > > > OLD: > Assuming the response is to be transmitted reliably, the UAC MUST > create a new request with method PRACK. This request is sent within > the dialog associated with the provisional response (indeed, the > provisional response may have created the dialog). PRACK requests > MAY contain bodies, which are interpreted according to their type and > disposition. > > NEW: > Assuming the response was transmitted reliably by the UAS, the UAC MUST > create a new request with method PRACK. This request is sent within > the dialog associated with the provisional response (indeed, the > provisional response may have created the dialog). PRACK requests > MAY contain bodies, which are interpreted according to their type and > disposition. > > > OLD: > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission when > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain a sequence number that indicates the most recently > received in-order reliable provisional response for the initial > request. This sequence number MUST be maintained until a final > response is received for the initial request. Its value MUST be > initialized to the RSeq header field in the first reliable > provisional response received for the initial request. > > NEW: > > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission when > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain, independently for each dialog ID, a sequence > number that indicates the most recently received in-order reliable > provisional response for the initial request. This sequence number > MUST be maintained until a final response is received for the initial > request. Its value MUST, for each dialog (or early dialog), be initialized > to the RSeq header field in the first reliable provisional response, > associated with the dialog, received for the initial request. > > > OLD: > Handling of subsequent reliable provisional responses for the same > initial request follows the same rules as above, with the following > difference: reliable provisional responses are guaranteed to be in > order. As a result, if the UAC receives another reliable provisional > response to the same request, and its RSeq value is not one higher > than the value of the sequence number, that response MUST NOT be > acknowledged with a PRACK, and MUST NOT be processed further by the > UAC. An implementation MAY discard the response, or MAY cache the > response in the hopes of receiving the missing responses. > > NEW: > Subsequent reliable provisional responses for the same initial > request are guaranteed to have been generated by the UAS in the > order of their RSeq values and must be acknowledged in that order. > As a result, if the UAC receives another > reliable provisional response to the same request, and its RSeq > value is one higher than the value of the previously received RSeq > value in the dialog (or early dialog), then the new RSeq value is saved and the > response is handled as described above. If the RSeq value is not one > higher than the value of the sequence number, that response MUST NOT > be acknowledged with a PRACK, and MUST NOT be processed further by > the UAC. An implementation MAY discard the response, or MAY cache > the response to be processed (and acknowledged) after receiving > the missing responses. > > > ------------- > > Can I go ahead and create a new errata? :) > > Regards, > > Christer > From nobody Thu Dec 17 07:56:59 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 845351B2EF9 for ; Thu, 17 Dec 2015 07:56:57 -0800 (PST) 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 kZZdxQkfnDoj for ; Thu, 17 Dec 2015 07:56:55 -0800 (PST) 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 75A751B2EF3 for ; Thu, 17 Dec 2015 07:56:55 -0800 (PST) Received: from mutabilis-2.local (pool-96-226-213-187.dllstx.fios.verizon.net [96.226.213.187]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBHFuk45064734 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 17 Dec 2015 09:56:47 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-96-226-213-187.dllstx.fios.verizon.net [96.226.213.187] claimed to be mutabilis-2.local To: Christer Holmberg , Paul Kyzivat , "Gonzalo Salgueiro (gsalguei)" References: <7594FB04B1934943A5C02806D1A2204B37CEAC73@ESESSMB209.ericsson.se> From: "A. Jean Mahoney" Message-ID: <5672DB3E.6050306@nostrum.com> Date: Thu, 17 Dec 2015 09:56:46 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37CEAC73@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "ben@nostrum.com" , "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Text for new errata - New version 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, 17 Dec 2015 15:56:57 -0000 Hi Christer, Just two small nits highlighted below, otherwise I (as an individual) am ok with it - On 12/17/15 7:56 AM, Christer Holmberg wrote: > Hi, > > New version, based on Dale's last comment: > > Hi, > > Based on the e-mail discussion, the new errata would contain the following change suggestions: > > ------------ > > Section 3: > > OLD: > The provisional response to be sent reliably is constructed by the > UAS core according to the procedures of Section 8.2.6 of RFC 3261. > In addition, it MUST contain a Require header field containing the > option tag 100rel, and MUST include an RSeq header field. The value > of the header field for the first reliable provisional response in a > transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that > it be chosen uniformly in this range. The RSeq numbering space is > within a single transaction. This means that provisional responses > for different requests MAY use the same values for the RSeq number. > > NEW: > The provisional response to be sent reliably is constructed by the > UAS core according to the procedures of Section 8.2.6 of RFC 3261. > In addition, it MUST contain a Require header field containing the > option tag 100rel, and MUST include an RSeq header field. The > value of the header field for the first reliable provisional > response in a transaction MUST be between 1 and 2**31 - 1. It is > RECOMMENDED that it be chosen uniformly in this range. > The RSeq numbering space is within a single transaction. > This means that RSeq value of a provisional response within ^^^^ Insert "the" in front of "RSeq value" > a fork of a request is independent of the RSeq value of a > provisional response within any other fork of that request, or for > the responses for any other request. It thus may be higher, lower, > or the same as any other such RSeq value Last sentence above is missing a period. Thanks, Jean > > > Section 4: > > OLD: > If a provisional response is received for an initial request, and > that response contains a Require header field containing the option > tag 100rel, the response is to be sent reliably. If the response is > a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be > ignored, and the procedures below MUST NOT be used. > > NEW: > If a provisional response is received for an initial request, and > that response contains a Require header field containing the option > tag 100rel, the response was sent by the UAS reliably. If the > response is a 100 (Trying) (as opposed to 101 to 199), this option > tag MUST be ignored, and the procedures below MUST NOT be used. > > > OLD: > Assuming the response is to be transmitted reliably, the UAC MUST > create a new request with method PRACK. This request is sent within > the dialog associated with the provisional response (indeed, the > provisional response may have created the dialog). PRACK requests > MAY contain bodies, which are interpreted according to their type and > disposition. > > NEW: > Assuming the response was transmitted reliably by the UAS, the UAC MUST > create a new request with method PRACK. This request is sent within > the dialog associated with the provisional response (indeed, the > provisional response may have created the dialog). PRACK requests > MAY contain bodies, which are interpreted according to their type and > disposition. > > > OLD: > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission when > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain a sequence number that indicates the most recently > received in-order reliable provisional response for the initial > request. This sequence number MUST be maintained until a final > response is received for the initial request. Its value MUST be > initialized to the RSeq header field in the first reliable > provisional response received for the initial request. > > NEW: > > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission when > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain, independently for each dialog ID, a sequence > number that indicates the most recently received in-order reliable > provisional response for the initial request. This sequence number > MUST be maintained until a final response is received for the initial > request. Its value MUST, for each dialog (or early dialog), be initialized > to the RSeq header field in the first reliable provisional response, > associated with the dialog, received for the initial request. > > > OLD: > Handling of subsequent reliable provisional responses for the same > initial request follows the same rules as above, with the following > difference: reliable provisional responses are guaranteed to be in > order. As a result, if the UAC receives another reliable provisional > response to the same request, and its RSeq value is not one higher > than the value of the sequence number, that response MUST NOT be > acknowledged with a PRACK, and MUST NOT be processed further by the > UAC. An implementation MAY discard the response, or MAY cache the > response in the hopes of receiving the missing responses. > > NEW: > Subsequent reliable provisional responses for the same initial > request are guaranteed to have been generated by the UAS in the > order of their RSeq values and must be acknowledged in that order. > As a result, if the UAC receives another > reliable provisional response to the same request, and its RSeq > value is one higher than the value of the previously received RSeq > value in the dialog (or early dialog), then the new RSeq value is saved and the > response is handled as described above. If the RSeq value is not one > higher than the value of the sequence number, that response MUST NOT > be acknowledged with a PRACK, and MUST NOT be processed further by > the UAC. An implementation MAY discard the response, or MAY cache > the response to be processed (and acknowledged) after receiving > the missing responses. > > > ------------- > > Can I go ahead and create a new errata? :) > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Dec 17 11:26: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 2CB7C1A88EF for ; Thu, 17 Dec 2015 11:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Bq-hW9VLtOKD for ; Thu, 17 Dec 2015 11:26:41 -0800 (PST) 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 289251A88CB for ; Thu, 17 Dec 2015 11:26:40 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-ff-56730c6eccfe Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id EB.32.05041.E6C03765; Thu, 17 Dec 2015 20:26:39 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0248.002; Thu, 17 Dec 2015 20:26:38 +0100 From: Christer Holmberg To: "A. Jean Mahoney" , Paul Kyzivat , "Gonzalo Salgueiro (gsalguei)" Thread-Topic: [sipcore] RSeq and forking - Text for new errata - New version Thread-Index: AdE40sT+u5te+TuITJOTpS+nQ22kaQACGEwAAAlnkDA= Date: Thu, 17 Dec 2015 19:26:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37CEB9AA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37CEAC73@ESESSMB209.ericsson.se> <5672DB3E.6050306@nostrum.com> In-Reply-To: <5672DB3E.6050306@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+NgFlrBIsWRmVeSWpSXmKPExsUyM2K7pW4+T3GYwd3Z7BbzO0+zW8yd4mfR 0LmS1WLFhgOsFl9/bGKzeHmizIHN4+/7D0wek/d/ZfaY8nsjq8eSJT+ZPGbtfMISwBrFZZOS mpNZllqkb5fAlbH/3iTWgn6risZlk5gaGBfqdDFyckgImEj87b/FBmGLSVy4tx7I5uIQEjjM KPF7yzR2CGcxo8S/9r0sXYwcHGwCFhLd/7RB4iICHYwSE3vmsoJ0MwuUS3x88xJskrCAt8Tq XauYQOpFBHwkZh8tBQmLCFhJnFh1F6ycRUBVYvW+bcwgNq+Ar8TEmf/AyoUE8iQ2nrQECXMK aEtM3fSOCcRmBLrt+6k1TBCbxCVuPZnPBHGzgMSSPeeZIWxRiZeP/7FC2EoSi25/hqrXkViw +xMbhK0tsWzha6i1ghInZz5hmcAoNgvJ2FlIWmYhaZmFpGUBI8sqRtHi1OLi3HQjI73Uoszk 4uL8PL281JJNjMD4O7jlt9UOxoPPHQ8xCnAwKvHwGrAVhwmxJpYVV+YeYpTgYFYS4bV/XRQm xJuSWFmVWpQfX1Sak1p8iFGag0VJnLeZ6UGokEB6YklqdmpqQWoRTJaJg1OqgXFKv7i4h2fz Y7Z35rxVPbzsi1kimpTFZC9Iiy6eF6myy4dBtawpp4hJ3N3kA0dm+yfFMh35M2sbdb/84ph0 Z1podHhGp4/gJU2e1V7/ZgtYRSffu3WmrUVIO4vhX+/l6L/qWfkPdvP6v91/yVL+ynqDOU5H SuzCAjdonfqw9HBRzdOjBQGLlFiKMxINtZiLihMB0MB907sCAAA= Archived-At: Cc: "ben@nostrum.com" , "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] RSeq and forking - Text for new errata - New version 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, 17 Dec 2015 19:26:44 -0000 Hi Jean, I'll include your fixes when creating the errata :) Thanks! Regards, Christer -----Original Message----- From: A. Jean Mahoney [mailto:mahoney@nostrum.com]=20 Sent: 17 December 2015 17:57 To: Christer Holmberg ; Paul Kyzivat ; Gonzalo Salgueiro (gsalguei) Cc: ben@nostrum.com; Dale R. Worley ; sipcore@ietf.org Subject: Re: [sipcore] RSeq and forking - Text for new errata - New version Hi Christer, Just two small nits highlighted below, otherwise I (as an individual) am ok= with it - On 12/17/15 7:56 AM, Christer Holmberg wrote: > Hi, > > New version, based on Dale's last comment: > > Hi, > > Based on the e-mail discussion, the new errata would contain the followin= g change suggestions: > > ------------ > > Section 3: > > OLD: > The provisional response to be sent reliably is constructed by the > UAS core according to the procedures of Section 8.2.6 of RFC 3261. > In addition, it MUST contain a Require header field containing the > option tag 100rel, and MUST include an RSeq header field. The value > of the header field for the first reliable provisional response in a > transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that > it be chosen uniformly in this range. The RSeq numbering space is > within a single transaction. This means that provisional responses > for different requests MAY use the same values for the RSeq number. > > NEW: > The provisional response to be sent reliably is constructed by the > UAS core according to the procedures of Section 8.2.6 of RFC 3261. > In addition, it MUST contain a Require header field containing the > option tag 100rel, and MUST include an RSeq header field. The > value of the header field for the first reliable provisional > response in a transaction MUST be between 1 and 2**31 - 1. It is > RECOMMENDED that it be chosen uniformly in this range. > The RSeq numbering space is within a single transaction. > This means that RSeq value of a provisional response within ^^^^ Insert "the" in front of "RSeq value" > a fork of a request is independent of the RSeq value of a > provisional response within any other fork of that request, or for > the responses for any other request. It thus may be higher, lower, > or the same as any other such RSeq value Last sentence above is missing a period. Thanks, Jean > > > Section 4: > > OLD: > If a provisional response is received for an initial request, and > that response contains a Require header field containing the option > tag 100rel, the response is to be sent reliably. If the response is > a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be > ignored, and the procedures below MUST NOT be used. > > NEW: > If a provisional response is received for an initial request, and > that response contains a Require header field containing the option > tag 100rel, the response was sent by the UAS reliably. If the > response is a 100 (Trying) (as opposed to 101 to 199), this option > tag MUST be ignored, and the procedures below MUST NOT be used. > > > OLD: > Assuming the response is to be transmitted reliably, the UAC MUST > create a new request with method PRACK. This request is sent within > the dialog associated with the provisional response (indeed, the > provisional response may have created the dialog). PRACK requests > MAY contain bodies, which are interpreted according to their type and > disposition. > > NEW: > Assuming the response was transmitted reliably by the UAS, the UAC MU= ST > create a new request with method PRACK. This request is sent within > the dialog associated with the provisional response (indeed, the > provisional response may have created the dialog). PRACK requests > MAY contain bodies, which are interpreted according to their type and > disposition. > > > OLD: > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission when > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain a sequence number that indicates the most recently > received in-order reliable provisional response for the initial > request. This sequence number MUST be maintained until a final > response is received for the initial request. Its value MUST be > initialized to the RSeq header field in the first reliable > provisional response received for the initial request. > > NEW: > > Once a reliable provisional response is received, retransmissions of > that response MUST be discarded. A response is a retransmission when > its dialog ID, CSeq, and RSeq match the original response. The UAC > MUST maintain, independently for each dialog ID, a sequence > number that indicates the most recently received in-order reliable > provisional response for the initial request. This sequence number > MUST be maintained until a final response is received for the initial > request. Its value MUST, for each dialog (or early dialog), be initia= lized > to the RSeq header field in the first reliable provisional response, > associated with the dialog, received for the initial request. > > > OLD: > Handling of subsequent reliable provisional responses for the same > initial request follows the same rules as above, with the following > difference: reliable provisional responses are guaranteed to be in > order. As a result, if the UAC receives another reliable provisional > response to the same request, and its RSeq value is not one higher > than the value of the sequence number, that response MUST NOT be > acknowledged with a PRACK, and MUST NOT be processed further by the > UAC. An implementation MAY discard the response, or MAY cache the > response in the hopes of receiving the missing responses. > > NEW: > Subsequent reliable provisional responses for the same initial > request are guaranteed to have been generated by the UAS in the > order of their RSeq values and must be acknowledged in that order. > As a result, if the UAC receives another > reliable provisional response to the same request, and its RSeq > value is one higher than the value of the previously received RSeq > value in the dialog (or early dialog), then the new RSeq value is sav= ed and the > response is handled as described above. If the RSeq value is not one > higher than the value of the sequence number, that response MUST NOT > be acknowledged with a PRACK, and MUST NOT be processed further by > the UAC. An implementation MAY discard the response, or MAY cache > the response to be processed (and acknowledged) after receiving > the missing responses. > > > ------------- > > Can I go ahead and create a new errata? :) > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Dec 17 14:04:08 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FB61B30E9 for ; Thu, 17 Dec 2015 14:04:07 -0800 (PST) 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 gdQbITlel7ns for ; Thu, 17 Dec 2015 14:04:06 -0800 (PST) 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 886751A8A95 for ; Thu, 17 Dec 2015 14:04:06 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-09v.sys.comcast.net with comcast id um411r0012S2Q5R01m45uE; Thu, 17 Dec 2015 22:04:05 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-16v.sys.comcast.net with comcast id um441r0051nMCLR01m441X; Thu, 17 Dec 2015 22:04:05 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id tBHM43f4030585; Thu, 17 Dec 2015 17:04:03 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id tBHM41hF030567; Thu, 17 Dec 2015 17:04:02 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37CEAC73@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 17 Dec 2015 17:04:01 -0500 Message-ID: <8737v0ivfy.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1450389845; bh=c4lF+3xWUl4gQzr6pclSjWz/eRSBKXQBhbHegohbYds=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Y+Xamp6gxkrgFVJkJm+SuJ2bV7dYJv2met/ASRvRscOflTh+3+emo7Q/7tivGbH4V Z0wVjQ+qvAQJlwX5n9QcZsYhd3xJo25xETl/lIkW99GQ2S37Q8jvilj7WbsXLyRUYD W9LhMVyZDmQvSuE3EcR7O30bRM/NJ4RxoZ/8Cch7qmqcbhWbiXpEuqYLS3Bsa2+v5z /J0XZLKiJ8ty7At7NpJ6dF+d9U22qqk0Q1mXxJq+4bkKYsnGbgM6YpTlAwd36PFD/6 sg5rmh6AuywNC+4S6LfCInUj3cqAbrDhTdnqOw1R6OIOH6KF7bgtnO0ewDjOKRZRtx vxbUkkW1IVOxg== Archived-At: Cc: ben@nostrum.com, sipcore@ietf.org, gsalguei@cisco.com Subject: Re: [sipcore] RSeq and forking - Text for new errata - New version 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, 17 Dec 2015 22:04:08 -0000 Looks good to me. Dale From nobody Fri Dec 18 00:48: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 937A11B347D for ; Fri, 18 Dec 2015 00:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6X_qVkIugIj9 for ; Fri, 18 Dec 2015 00:48:15 -0800 (PST) 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 7CB401B348B for ; Fri, 18 Dec 2015 00:48:02 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-69-5673c84047bf Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id DA.E6.05149.048C3765; Fri, 18 Dec 2015 09:48:00 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Fri, 18 Dec 2015 09:48:00 +0100 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [sipcore] RSeq and forking - Text for new errata - New version Thread-Index: AQHRORbVu5te+TuITJOTpS+nQ22kaZ7QbvlA Date: Fri, 18 Dec 2015 08:47:58 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37CEDAE6@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B37CEAC73@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) <8737v0ivfy.fsf@hobgoblin.ariadne.com> In-Reply-To: <8737v0ivfy.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyM2K7oq7DieIwg9bzuhbzO0+zW8yd4mex YsMBVouvPzaxWbw8UebA6vH3/Qcmj8n7vzJ7TPm9kdVjyZKfTB6zdj5hCWCN4rJJSc3JLEst 0rdL4Mr4McerYCFzxZ7TT9gaGK8xdTFyckgImEi0fHrIDGGLSVy4t56ti5GLQ0jgMKPEv5tr mCGcxYwSD1f+BOrg4GATsJDo/qcNYooIaEp0LMgBKWEWWMcocXhdC9ggYQFvidW7VjFB1PhI zD5aChIWETCS2LzrMDtImEVAVaJ1czBImFfAV2Lz8o/sEJumM0rsm/aFBSTBKWAs0XnrLSOI zQh02/dTa8BuZhYQl7j1ZD7U/QISS/ach7pfVOLl43+sELaSxI8Nl1gg6nUkFuz+xAZha0ss W/iaGWKxoMTJmU9YJjCKzUIydhaSlllIWmYhaVnAyLKKUbQ4tTgpN93ISC+1KDO5uDg/Ty8v tWQTIzDmDm75bbCD8eVzx0OMAhyMSjy8BmzFYUKsiWXFlbmHGCU4mJVEeAWPA4V4UxIrq1KL 8uOLSnNSiw8xSnOwKInzNjM9CBUSSE8sSc1OTS1ILYLJMnFwSjUwtu/bsbjua7R2+6yvInYC sbO4k4MyOrX2dHjv/RL6v+pP9e3i4oaHEyK/31gX83WntUaE/Llfr54sMHk3KTyum1VFJMBj ywHJmvjwBosNNjJhopmTnGMdUmLyHb+y8C/wW3z5skLxin8ngx1P2K87siLkbGLRdweDwhcT ruwKOcbwpaWaz2SZEktxRqKhFnNRcSIACO85d7UCAAA= Archived-At: Cc: "ben@nostrum.com" , "sipcore@ietf.org" , "gsalguei@cisco.com" Subject: Re: [sipcore] RSeq and forking - Text for new errata - New version 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, 18 Dec 2015 08:48:16 -0000 Do I need to create separate erratas for each updated section? Regards, Christer -----Original Message----- From: Dale R. Worley [mailto:worley@ariadne.com]=20 Sent: 18. joulukuuta 2015 0:04 To: Christer Holmberg Cc: pkyzivat@alum.mit.edu; gsalguei@cisco.com; ben@nostrum.com; sipcore@iet= f.org Subject: Re: [sipcore] RSeq and forking - Text for new errata - New version Looks good to me. Dale From nobody Fri Dec 18 06:38:40 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 A64B81B365F for ; Fri, 18 Dec 2015 06:38:38 -0800 (PST) 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 9BnrI606LG9j for ; Fri, 18 Dec 2015 06:38:32 -0800 (PST) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCDAC1B3159 for ; Fri, 18 Dec 2015 06:38:31 -0800 (PST) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-09v.sys.comcast.net with comcast id v2eS1r00952QWKC012eX6F; Fri, 18 Dec 2015 14:38:31 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-po-09v.sys.comcast.net with comcast id v2eV1r0011nMCLR012eVtH; Fri, 18 Dec 2015 14:38:30 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id tBIEcStk015046; Fri, 18 Dec 2015 09:38:28 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id tBIEcQAf015043; Fri, 18 Dec 2015 09:38:26 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37CEDAE6@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 18 Dec 2015 09:38:26 -0500 Message-ID: <8737uzhlel.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1450449511; bh=pdl5XuyMUeWtLhuvDkc0zafw+8ghFsLi5HDD3gUyho0=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=aXG7nUWxsMUBORZh8SBYBaYkMDoakKkcwKF2FumVfF9058Jg4hrSFJkfWpfCGbBvL QSZsnj0TpQ1ZXSjj0GB+98oP6k1tqB7FmgerY1pghRZgCezfpU3FMhe9iCA+zrNYpx g6l7xdOlOkvNQCgP1HDJk3ohLLDXsWeRMk5xfkBdsI8Erzk8x7F4/OYPb2pqYeN6/O wSpAa7nAqYlDRVYTGfgMHx18VvsPlaRcY8blybUzD0voQQkBgfqC5o90DdqGersOLW cPZcO6lUOF+/5fWG/IG9d972ug+4fH+vhGYpbLfzj9IUE8N918HT/kQ5piq3Qgmigt Gb3veL4dFMbsg== Archived-At: Cc: ben@nostrum.com, sipcore@ietf.org, gsalguei@cisco.com Subject: Re: [sipcore] RSeq and forking - Text for new errata - New version 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, 18 Dec 2015 14:38:38 -0000 Christer Holmberg writes: > Do I need to create separate erratas for each updated section? I don't think it's necessary, but other people probably have a better understanding of how the errata process should work. Dale From nobody Wed Dec 23 13:47:23 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 552621A87AD for ; Wed, 23 Dec 2015 13:47:23 -0800 (PST) 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 kt5Jyd86X36r for ; Wed, 23 Dec 2015 13:47:22 -0800 (PST) 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 3FCA81A878A for ; Wed, 23 Dec 2015 13:47:22 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tBNLlDwx002540 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 23 Dec 2015 15:47:13 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: "Dale R. Worley" , "Christer Holmberg" Date: Wed, 23 Dec 2015 15:47:12 -0600 Message-ID: <70CAF158-ECC0-41D4-8EE4-1BCD2CB47035@nostrum.com> In-Reply-To: <8737uzhlel.fsf@hobgoblin.ariadne.com> References: <8737uzhlel.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: sipcore@ietf.org, gsalguei@cisco.com Subject: Re: [sipcore] RSeq and forking - Text for new errata - New version 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, 23 Dec 2015 21:47:23 -0000 On 18 Dec 2015, at 8:38, Dale R. Worley wrote: > Christer Holmberg writes: >> Do I need to create separate erratas for each updated section? > > I don't think it's necessary, but other people probably have a better > understanding of how the errata process should work. > If the changes are of the same type, should be be accepted or rejected as a group, and need to be understood as a group by the reader, it makes sense to do them in a single erratum. A couple of questions along those lines: Do the "is to be sent"/"was sent" changes need to be considered along wth the rest of the changes? Do people consider those to be technical or editorial? Ben. From nobody Mon Dec 28 05:34: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 3CB2E1A0011 for ; Mon, 28 Dec 2015 05:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f459qdSFwYtx for ; Mon, 28 Dec 2015 05:34:45 -0800 (PST) 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 BE2A61A000E for ; Mon, 28 Dec 2015 05:34:43 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-f5-56813a72c083 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 33.C9.05041.27A31865; Mon, 28 Dec 2015 14:34:42 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Mon, 28 Dec 2015 14:34:41 +0100 From: Christer Holmberg To: Ben Campbell , "Dale R. Worley" Thread-Topic: [sipcore] RSeq and forking - Text for new errata - New version Thread-Index: AQHROaHAu5te+TuITJOTpS+nQ22kaZ7ZEu4AgAdiQrA= Date: Mon, 28 Dec 2015 13:34:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37D009E2@ESESSMB209.ericsson.se> References: <8737uzhlel.fsf@hobgoblin.ariadne.com> <70CAF158-ECC0-41D4-8EE4-1BCD2CB47035@nostrum.com> In-Reply-To: <70CAF158-ECC0-41D4-8EE4-1BCD2CB47035@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM2K7om6RVWOYwfEffBbzO0+zW8yd4mfx 9ccmNouXJ8ocWDwm7//K7DHl90ZWjyVLfjJ5zNr5hCWAJYrLJiU1J7MstUjfLoErY8rJWWwF 99kqvn+dzdrAuJS1i5GTQ0LAROLW8l4mCFtM4sK99WxdjFwcQgKHGSX+HznNCuEsZpToO9AC 5HBwsAlYSHT/0wZpEBHwlPj4fjdYM7NAmETPjqmMILawgLfE6l2rmEDKRQR8JGYfLYUot5L4 8uc1WAmLgKrEykfn2UBsXgFfie97HoLFhQTSJXqWHQEbySlgL7FkyWswmxHotu+n1kCtEpe4 9WQ+1M0CEkv2nGeGsEUlXj7+B/WXokT70wZGiHodiQW7P7FB2NoSyxa+ZobYKyhxcuYTlgmM YrOQjJ2FpGUWkpZZSFoWMLKsYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMsINbflvtYDz4 3PEQowAHoxIP74alDWFCrIllxZW5hxglOJiVRHhXmjSGCfGmJFZWpRblxxeV5qQWH2KU5mBR EudNkgFKCaQnlqRmp6YWpBbBZJk4OKUaGFuZVytmnxV97u4q/lGt/MAN37d8V46GTp9XmpkU l2pl8tN9+zcz9z+LJmmXtVtOyZL+f/rAT5b1iQf3m2l/ij69M3t1NMPx69r+aybdvPb5Gnc6 v1CcBeci4Vz9FxX8s5aW+nbeXxR/rCf7y0nLU7qLm5RrL2vci320cV3/hJUFb++xOJQnmyqx FGckGmoxFxUnAgBrMUFxrAIAAA== Archived-At: Cc: "sipcore@ietf.org" , "gsalguei@cisco.com" Subject: Re: [sipcore] RSeq and forking - Text for new errata - New version 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, 28 Dec 2015 13:34:46 -0000 Hi, >> Christer Holmberg writes: >>> Do I need to create separate erratas for each updated section? >> >> I don't think it's necessary, but other people probably have a better=20 >> understanding of how the errata process should work. >> > > If the changes are of the same type, should be be accepted or rejected as= a group, and need to be understood as a group by the reader, it makes sens= e to do them in a single erratum. Ok. > A couple of questions along those lines: Do the "is to be sent"/"was sent= " changes need to be considered along wth the rest of the changes?=20 > Do people consider those to be technical or editorial? The change is done in one place only, and my understanding is that it is te= chnical, as it describes a case where the response has been sent. Regards, Christer From nobody Thu Dec 31 07:47:02 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5EA61A1B87 for ; Thu, 31 Dec 2015 07:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_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 47wnhYUiMs12 for ; Thu, 31 Dec 2015 07:46:59 -0800 (PST) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AC901A1B85 for ; Thu, 31 Dec 2015 07:46:59 -0800 (PST) Received: by mail-qg0-x235.google.com with SMTP id b35so73451951qge.0 for ; Thu, 31 Dec 2015 07:46:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jive-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=0tpX+cvxrShbYXViOtSgHo2uZ3ZTCRcptEQ1r1/Vmcs=; b=D1ePeUTVAIml07d5FJzKrC7aYE5/owQcWBzI/XyLWziSLe2tR2QQ/egHZ5X4LaaB2C KJiYB63ATdYY4mBW2jr7sj9R22eNHMiLevA9liqo7kqJsLZCkbO29gTHwHu9fYJvQrvd 5UGxmTaIO63pG/kyJo3suOmT1LNB8j3SNMNF4KeL2XQhPQ/6ucUTrLIib7FLsNHRKRC0 0G/N4xNd44YSl7ArEg1w1xS/zTL0rZBbzJHBNjo/3tW/Ium2kvqQywojCS3lZW/7heuG bPUSt2FKV2U+SmEoBXu8Hh4cHmN6OAl+atCejMB9oGkFRHarSM2de/4SjZdXfU2Bsjb3 8l9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=0tpX+cvxrShbYXViOtSgHo2uZ3ZTCRcptEQ1r1/Vmcs=; b=gB8pweF3bc3zsUFUOUfxli9IswcbECenZ/bc4rOXeYIXpLr6njJa5G+UR6sLiO94Lg 16sjOZAmFwQ0ZPwozz8WGpjZFPFYnLBWYg4xpYHNTh46ffFZFzz5Vm86PexN+vvgquj4 /quyRk9glGhl9oLd7jTiffy3pcKYi0nbZChPAu70o0+kqi4Le/50KK5Slzb0rTmMH+BA KNboeDh6wfZq8kFm6pUnoIuThA+WrLJiQP/ZPbf5wuBml8gfvNhZrlZ/kLErnyZy9nwO GZye8rMRSTA9a1Ike3nXaT1/x3nUKCSFOSesJ5u04qTUkLb2Idhm85tGKW8//nOS/FdH COMg== X-Gm-Message-State: ALoCoQn5JGqzIM8NFAGBIoTBiDPSyPEanO3t/J2CWLUpachAuo2gLdiO5CNBwT4uEh1SulE7FwHOWvP+ElSxMQOePkKOOYst4g== X-Received: by 10.140.22.74 with SMTP id 68mr92753971qgm.87.1451576818142; Thu, 31 Dec 2015 07:46:58 -0800 (PST) Received: from [192.168.1.57] (modemcable164.157-22-96.mc.videotron.ca. [96.22.157.164]) by smtp.googlemail.com with ESMTPSA id c7sm14386535qkb.38.2015.12.31.07.46.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Dec 2015 07:46:57 -0800 (PST) To: "Olle E. Johansson" , 'SIPCORE' References: <4D8AB601-3FB6-4262-9131-0DF0D881A611@edvina.net> From: Simon Perreault Message-ID: <56854DF0.4060503@jive.com> Date: Thu, 31 Dec 2015 10:46:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <4D8AB601-3FB6-4262-9131-0DF0D881A611@edvina.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] Response to Jari's blog 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, 31 Dec 2015 15:47:01 -0000 Olle, I sent a review of draft-ietf-sipcore-dns-dual-stack-01 more than a year ago: https://mailarchive.ietf.org/arch/msg/sipcore/bvqJHA6kLHOE0GamFfeJjN450Qc Those comments have still not been addressed. That fact was re-stated in June 2015: https://mailarchive.ietf.org/arch/msg/sipcore/43xNG4UuKC0A9nwZMLkCfNsPW6g Still no changes. When you say "documents still are not going anywhere because a lack of interest", do you mean lack of interest on the authors' part? Simon Le 2015-12-30 15:26, Olle E. Johansson a écrit : > Hi! > > Thank you Jari, for a great summary of 2015. > > One thing I’m missing is a continued focus on IPv6. I think there has > to be some pressure and ways to handle IPv6 bugs in current RFCs > outside of the normal process. > > We have submitted several drafts to the dispatch and sipcore working > groups, all died because of a lack of interest and discussion in the > group. The bugs we found in the SIP protocol still remains and needs > to be fixed in order for SIP implementations to handle dual stacks > properly - but I can’t find a way to get this published following the > normal process. > > So we have bugs related to IPv6, we have a group of authors and the > documents still are not going anywhere because a lack of interest. > > I know that we have several bugs related to TLS handling in the SIP > protocol as well. The handling of IPv6 issues doesn’t make me very > positive about even bothering with writing any drafts about them. > > Yes, I am pessimistic. Yes, I am pretty sure there are other > protocols that have bugs related to both IPv6 and TLS handling. I > think the IETF needs to find a way to handle these even in low-energy > working groups like the SIPcore group. > > Happy New Year! > > /O >