From nobody Mon Nov 3 12:48:50 2014 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 4ACE61A0172 for ; Mon, 3 Nov 2014 12:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 c69qd9fJnCaV for ; Mon, 3 Nov 2014 12:48:34 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E134D1A016C for ; Mon, 3 Nov 2014 12:48:32 -0800 (PST) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sA3KmWjq060230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 3 Nov 2014 14:48:32 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <5457EA1B.9020908@nostrum.com> Date: Mon, 03 Nov 2014 14:48:27 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <54495077.8090502@alum.mit.edu> <545006B3.4000505@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4D26FE@ESESSMB209.ericsson.se> <54513A31.1080903@alum.mit.edu> In-Reply-To: <54513A31.1080903@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/A2BQ7NZx6dmFD09pZrVghGXWpsI Subject: Re: [sipcore] Agenda Items for SIPCORE at IETF91 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, 03 Nov 2014 20:48:41 -0000 Almost all of the time I think I need will be on explicit-subscriptions, and would be spent on the one Open Issue in the draft (related to Supported/Require and 421). I'll send a note in a few minutes summarizing what I think we need to talk about. If we can close the issue on list, I'll happily give back my time. If someone thinks we needed to spend time on some other aspect of either draft, please yell now. RjS On 10/29/14 2:04 PM, Paul Kyzivat wrote: > On 10/29/14 3:11 AM, Christer Holmberg wrote: >> Hi, >> >> Some comments on the pre-agenda: >> >> First, as I think 10 (or shorter) minute slots at f2f meetings are >> not very useful, > > I agree. I was intending to fix that after some discussion. > >> I am willing to give up my slot (Authorization server identity), and >> let you allocate that time to something else. > > Thank you! > >> However, I'd like to have some off-line/list discussions on whether >> people think the solution could be of general interest, or whether >> it's only of interest to 3GPP. > > I haven't had time to review it yet. And now, if its not going to be > on the agenda, I may not get to it until after the meeting. > > You may have better luck getting attention *after* the meeting. > (Realistically that probably means early next year.) > >> Second, while I do agree that Robert's draft has highest priority, do >> we really need f2f time for Explicit Subscriptions for REFER? Are >> there any open issues (we discussed the forking issue, but based on >> the input from people I believe we came to a conclusion on how to >> move forward)? Can't we just call for adoption of the draft on the list? >> Third, 5 minutes for Clarifications on use of REFER is just enough >> for Hadriel to give his >> break-the-ice-joke-that-nobody-but-himself-understands :) And, as >> there has actually been quite a bit of discussions on that draft, I'd >> like the chairs to allocate more time for it. But, also in this case >> I think we should ask for adoption on the list. > > Robert asked for at least 20 minutes, preferably 30, for both. The > split between them was a swag by me. > > Thanks, > Paul > >> Thanks! >> >> Christer >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul >> Kyzivat >> Sent: 28. lokakuuta 2014 23:12 >> To: sipcore@ietf.org >> Subject: Re: [sipcore] Agenda Items for SIPCORE at IETF91 >> >> I have now heard from three people with requests for agenda time. >> Based on those requests, I've posted a *preliminary* agenda, at: >> >> http://www.ietf.org/proceedings/91/agenda/agenda-91-sipcore >> >> We only have a one hour slot, and there are requests for more time >> that that. For now I have assigned Robert his minimum requested time >> for the two REFER drafts. I consider them the highest priority, and >> if need be we will let them run longer. >> >> For now I simply divided the remaining time among the other requests. >> But I don't expect it to stay that one. One of those is back for the >> 2nd time, with updates responding to comments in Toronto. It most >> likely will have priority over the others. >> >> The other two are new. Rifaat's key derivation draft has had some >> list discussion. Christer's is newer, and has had just a little bit >> of list discussion. >> >> It is probably counterproductive to give each draft too little time. >> So I'll be watching which ones have the most list discussion between >> now and the meeting, and will juggle the times accordingly. >> >> Thanks, >> Paul >> >> On 10/23/14 3:01 PM, Paul Kyzivat wrote: >>> Now is the time to speak up if you want time on the SIPCORE agenda for >>> the upcoming meeting. Please provide a rough outline of what you want >>> to cover and how long you think you need to do so. >>> >>> We have a one-hour session on Thursday, Nov 13. >>> >>> 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 Mon Nov 3 13:08:46 2014 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 1E2061A0158 for ; Mon, 3 Nov 2014 13:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] 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 dykDFjD8mmtz for ; Mon, 3 Nov 2014 13:08:41 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 6656A1A0278 for ; Mon, 3 Nov 2014 13:08:40 -0800 (PST) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sA3L8dZY061930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 3 Nov 2014 15:08:40 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <5457EED3.3080807@nostrum.com> Date: Mon, 03 Nov 2014 15:08:35 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="------------020601080200000808090301" Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/hz3Taaj0eMn0Ob-vWr8Z2PIh1xM Subject: [sipcore] Open issue in refer-explicit-subscriptions 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, 03 Nov 2014 21:08:45 -0000 This is a multi-part message in MIME format. --------------020601080200000808090301 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit -02 calls out one open issue - better aligning with 3261 Supported/Require definitions, and using 421 correctly. As most folks know, there has been many threads on the semantics of Supported and Require. We're avoiding the problems most of those threads call out by being very specific with when this extension can be used, and what to put in the messages when it is used. We're almost aligned with what's in 3261, but Ivo called my attention some time back to a rough edge with responses. Section 8.1.1.9 of RFC3261 requires responders to list any extensions applied to a result in a Require header field. Now we could burn a _lot_ more time arguing about whether doing so is worthwhile since we can only apply this extension if it was Required in a request, but I don't think it's worth the effort. Instead, I think the following replacement for section 6 of the draft gets us to a place where we aren't in conflict with any 3261 text. You can find a side-by-side diff of this suggestion against the current section at . If this works for folks, then I don't think we need time in Honolulu to discuss it. ------ 6. The 'explicitsub' and 'nosub' Option Tags This document defines the 'explicitsub' option tag, used to signal the use of the extension defined in Section 4, and the 'nosub' option tag, used to signal the use of the extension defined in Section 5. The use of either option tag in a Require header field is only defined when it appears in a REFER request or a response to a REFER request. A UA MUST NOT include the 'explicitsub' or 'nosub' option tag in the Require header field of any request other than REFER. A UA MUST NOT include the 'explicitsub' or 'nosub' option tag in the Require header field of any SIP response other than a 200 or 421 response to a REFER request. The 'explicitsub' and 'nosub' option tags MAY appear in the Supported header field of SIP messages, and in sip.extensions feature tag defined in [RFC3840]. This signals only that the UA including the value is aware of the extensions. In particular, a UA can only invoke the use of one of the extensions in a request. A UA MUST NOT include either option tag in the Require header field of a 200 response to a REFER request if that tag was not present in the Require header field of the request. A User-Agent Server (UAS) that is processing a REFER request that lists 'explicitsub' or 'nosub' in its Supported header field and wishes to use one of those extensions will return a 421 response indicating which extension is required. --------------020601080200000808090301 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit -02 calls out one open issue - better aligning with 3261 Supported/Require definitions, and using 421 correctly.

As most folks know, there has been many threads on the semantics of Supported and Require. We're avoiding the problems most of those threads call out by being very specific with when this extension can be used, and what to put in the messages when it is used. We're almost aligned with what's in 3261, but Ivo called my attention some time back to a rough edge with responses. Section 8.1.1.9 of RFC3261 requires responders to list any extensions applied to a result in a Require header field. Now we could burn a _lot_ more time arguing about whether doing so is worthwhile since we can only apply this extension if it was Required in a request, but I don't think it's worth the effort.

Instead, I think the following replacement for section 6 of the draft gets us to a place where we aren't in conflict with any 3261 text. You can find a side-by-side diff of this suggestion against the current section at <http://www.nostrum.com/~rjsparks/diff_before_after.html>.

If this works for folks, then I don't think we need time in Honolulu to discuss it.


------

6. The 'explicitsub' and 'nosub' Option Tags

   This document defines the 'explicitsub' option tag, used to signal
   the use of the extension defined in Section 4, and the 'nosub' option
   tag, used to signal the use of the extension defined in Section 5.

   The use of either option tag in a Require header field is only
   defined when it appears in a REFER request or a response to a
   REFER request.  A UA MUST NOT include the 'explicitsub' or 'nosub'
   option tag in the Require header field of any request other than
   REFER.  A UA MUST NOT include the 'explicitsub' or 'nosub' option
   tag in the Require header field of any SIP response other than a
   200 or 421 response to a REFER request.

   The 'explicitsub' and 'nosub' option tags MAY appear in the Supported
   header field of SIP messages, and in sip.extensions feature tag
   defined in [RFC3840].  This signals only that the UA including the
   value is aware of the extensions.  In particular, a UA can only
   invoke the use of one of the extensions in a request.  A UA MUST NOT
   include either option tag in the Require header field of a 200 response
   to a REFER request if that tag was not present in the Require header field
   of the request. A User-Agent Server (UAS) that is processing a REFER
   request that lists 'explicitsub' or 'nosub' in its Supported header field
   and wishes to use one of those extensions will return a 421 response
   indicating which extension is required.
--------------020601080200000808090301-- From nobody Tue Nov 4 00:09:21 2014 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 F09C61A88F8 for ; Tue, 4 Nov 2014 00:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q24Uz4T1E-4R for ; Tue, 4 Nov 2014 00:09:16 -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 E7EFA1A8847 for ; Tue, 4 Nov 2014 00:09:14 -0800 (PST) X-AuditID: c1b4fb3a-f79596d000001123-f1-545889a8b0d5 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A9.DF.04387.8A988545; Tue, 4 Nov 2014 09:09:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Tue, 4 Nov 2014 09:09:12 +0100 From: Christer Holmberg To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] Open issue in refer-explicit-subscriptions Thread-Index: AQHP96phoB9VmUajWU++EKVL3yn2SJxQGTWg Date: Tue, 4 Nov 2014 08:09:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4E22F4@ESESSMB209.ericsson.se> References: <5457EED3.3080807@nostrum.com> In-Reply-To: <5457EED3.3080807@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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4E22F4ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvje7KzogQg2tTWCyuzWlks/j6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJVx5/Vs9oJbvYwVz3fbNjB+6WTsYuTkkBAw kej895YdwhaTuHBvPVsXIxeHkMARRolVN/8xQjiLGSX2dncAVXFwsAlYSHT/0wZpEBEIlFg4 aQkLiC0s4CixausNJoi4k8ThVc/ZIGwjidkTp4DFWQRUJNadO8MKYvMK+EpsPH+IEWSkkICW RE8b2D2cAtoSS97cBCtnBLrn+6k1YDazgLjErSfzmSDuFJBYsuc8M4QtKvHy8T9WCFtRov1p A9hIZoF8iTfz8iE2CUqcnPmEZQKjyCwkk2YhVM1CUgUR1pRYv0sfolpRYkr3Q3YIW0Oidc5c dmTxBYzsqxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjECI+rglt9WOxgPPnc8xCjAwajEw2vg GBEixJpYVlyZe4hRmoNFSZx34bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYF0h1XROa xVC34eR9xQbRjffiXHk1alsd0/dHRi9osc/5uDfg/IupzJaKIYzhF49yTtv+tMx/3cLMgvs/ m/cXbBEt2t1XxbiqWOiEft/ndNlj+f+fcgkUfnjk99r1q1Hsuc3sutWa5x9ssZgq0Ww3W3Tx UROVN163ikUOBuucFQ+SWijUzK+uxFKckWioxVxUnAgAGnG6x4kCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/F5y5dJgRJCY7RVYyNltR8AwxpZY Subject: Re: [sipcore] Open issue in refer-explicit-subscriptions 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, 04 Nov 2014 08:09:19 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4E22F4ESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkluIGdlbmVyYWwgSSBhbSBvayB3aXRoIHRoZSBhcHByb2FjaCBzZWVuIGluIHRoZSBk aWZmLg0KDQpIb3dldmVyLCByZWxhdGVkIHRvIHRoZSBzZW1hbnRpY3MsIEkgdGhpbmsgd2UgaW4g c2VjdGlvbiA2IHNob3VsZCBtYWtlIGl0IG1vcmUgY2xlYXIgdGhhdCwgd2hlbiBwcmVzZW50IGlu IHRoZSBSZXF1aXJlIGhlYWRlciBmaWVsZCwgdGhlIHNlbWFudGljcyBtZWFucyDigJxNVVNUIFNV UFBPUlQgKkFORCogTVVTVCBVU0XigJ0uDQoNClRoYXQgY291bGQgYmUgZG9uZSBlLmcuIGJ5IGV4 dGVuZGluZyB0aGUgZm9sbG93aW5nIHNlbnRlbmNlOg0KDQogICAgICAgICAgICAgICAgICDigJxU aGUgdXNlIG9mIGVpdGhlciBvcHRpb24gdGFnIGluIGEgUmVxdWlyZSBoZWFkZXIgZmllbGQgaXMg b25seSBkZWZpbmVkIHdoZW4gaXQgYXBwZWFycyBpbiBhIFJFRkVSIHJlcXVlc3Qu4oCdDQoNCuKA pnRvOg0KDQogICAgICAgICAgICAgICAg4oCcVGhlIHVzZSBvZiBlaXRoZXIgb3B0aW9uIHRhZyBp biBhIFJlcXVpcmUgaGVhZGVyIGZpZWxkIGlzIG9ubHkgZGVmaW5lZCB3aGVuIGl0IGFwcGVhcnMg aW4gYSBSRUZFUiByZXF1ZXN0LCBhbmQgaW5kaWNhdGVzIHRoYXQgdGhlIHJlY2VpdmVyLCBpZiBp dCBhY2NlcHRzIHRoZSByZXF1ZXN0LCBtdXN0IHN1cHBvcnQgYW5kIHVzZSB0aGUgZXh0ZW5zaW9u IGFzc29jaWF0ZWQgd2l0aCB0aGUgb3B0aW9uLXRhZy7igJ0NCg0KUmVnYXJkcywNCg0KQ2hyaXN0 ZXINCg0KDQoNCkZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBSb2JlcnQgU3BhcmtzDQpTZW50OiAzLiBtYXJyYXNrdXV0YSAyMDE0IDIz OjA5DQpUbzogc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogW3NpcGNvcmVdIE9wZW4gaXNzdWUg aW4gcmVmZXItZXhwbGljaXQtc3Vic2NyaXB0aW9ucw0KDQotMDIgY2FsbHMgb3V0IG9uZSBvcGVu IGlzc3VlIC0gYmV0dGVyIGFsaWduaW5nIHdpdGggMzI2MSBTdXBwb3J0ZWQvUmVxdWlyZSBkZWZp bml0aW9ucywgYW5kIHVzaW5nIDQyMSBjb3JyZWN0bHkuDQoNCkFzIG1vc3QgZm9sa3Mga25vdywg dGhlcmUgaGFzIGJlZW4gbWFueSB0aHJlYWRzIG9uIHRoZSBzZW1hbnRpY3Mgb2YgU3VwcG9ydGVk IGFuZCBSZXF1aXJlLiBXZSdyZSBhdm9pZGluZyB0aGUgcHJvYmxlbXMgbW9zdCBvZiB0aG9zZSB0 aHJlYWRzIGNhbGwgb3V0IGJ5IGJlaW5nIHZlcnkgc3BlY2lmaWMgd2l0aCB3aGVuIHRoaXMgZXh0 ZW5zaW9uIGNhbiBiZSB1c2VkLCBhbmQgd2hhdCB0byBwdXQgaW4gdGhlIG1lc3NhZ2VzIHdoZW4g aXQgaXMgdXNlZC4gV2UncmUgYWxtb3N0IGFsaWduZWQgd2l0aCB3aGF0J3MgaW4gMzI2MSwgYnV0 IEl2byBjYWxsZWQgbXkgYXR0ZW50aW9uIHNvbWUgdGltZSBiYWNrIHRvIGEgcm91Z2ggZWRnZSB3 aXRoIHJlc3BvbnNlcy4gU2VjdGlvbiA4LjEuMS45IG9mIFJGQzMyNjEgcmVxdWlyZXMgcmVzcG9u ZGVycyB0byBsaXN0IGFueSBleHRlbnNpb25zIGFwcGxpZWQgdG8gYSByZXN1bHQgaW4gYSBSZXF1 aXJlIGhlYWRlciBmaWVsZC4gTm93IHdlIGNvdWxkIGJ1cm4gYSBfbG90XyBtb3JlIHRpbWUgYXJn dWluZyBhYm91dCB3aGV0aGVyIGRvaW5nIHNvIGlzIHdvcnRod2hpbGUgc2luY2Ugd2UgY2FuIG9u bHkgYXBwbHkgdGhpcyBleHRlbnNpb24gaWYgaXQgd2FzIFJlcXVpcmVkIGluIGEgcmVxdWVzdCwg YnV0IEkgZG9uJ3QgdGhpbmsgaXQncyB3b3J0aCB0aGUgZWZmb3J0Lg0KDQpJbnN0ZWFkLCBJIHRo aW5rIHRoZSBmb2xsb3dpbmcgcmVwbGFjZW1lbnQgZm9yIHNlY3Rpb24gNiBvZiB0aGUgZHJhZnQg Z2V0cyB1cyB0byBhIHBsYWNlIHdoZXJlIHdlIGFyZW4ndCBpbiBjb25mbGljdCB3aXRoIGFueSAz MjYxIHRleHQuIFlvdSBjYW4gZmluZCBhIHNpZGUtYnktc2lkZSBkaWZmIG9mIHRoaXMgc3VnZ2Vz dGlvbiBhZ2FpbnN0IHRoZSBjdXJyZW50IHNlY3Rpb24gYXQgPGh0dHA6Ly93d3cubm9zdHJ1bS5j b20vfnJqc3BhcmtzL2RpZmZfYmVmb3JlX2FmdGVyLmh0bWw+PGh0dHA6Ly93d3cubm9zdHJ1bS5j b20vfnJqc3BhcmtzL2RpZmZfYmVmb3JlX2FmdGVyLmh0bWw+Lg0KDQpJZiB0aGlzIHdvcmtzIGZv ciBmb2xrcywgdGhlbiBJIGRvbid0IHRoaW5rIHdlIG5lZWQgdGltZSBpbiBIb25vbHVsdSB0byBk aXNjdXNzIGl0Lg0KDQoNCi0tLS0tLQ0KDQo2LiBUaGUgJ2V4cGxpY2l0c3ViJyBhbmQgJ25vc3Vi JyBPcHRpb24gVGFncw0KDQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlICdleHBsaWNpdHN1 Yicgb3B0aW9uIHRhZywgdXNlZCB0byBzaWduYWwNCiAgIHRoZSB1c2Ugb2YgdGhlIGV4dGVuc2lv biBkZWZpbmVkIGluIFNlY3Rpb24gNCwgYW5kIHRoZSAnbm9zdWInIG9wdGlvbg0KICAgdGFnLCB1 c2VkIHRvIHNpZ25hbCB0aGUgdXNlIG9mIHRoZSBleHRlbnNpb24gZGVmaW5lZCBpbiBTZWN0aW9u IDUuDQoNCiAgIFRoZSB1c2Ugb2YgZWl0aGVyIG9wdGlvbiB0YWcgaW4gYSBSZXF1aXJlIGhlYWRl ciBmaWVsZCBpcyBvbmx5DQogICBkZWZpbmVkIHdoZW4gaXQgYXBwZWFycyBpbiBhIFJFRkVSIHJl cXVlc3Qgb3IgYSByZXNwb25zZSB0byBhDQogICBSRUZFUiByZXF1ZXN0LiAgQSBVQSBNVVNUIE5P VCBpbmNsdWRlIHRoZSAnZXhwbGljaXRzdWInIG9yICdub3N1YicNCiAgIG9wdGlvbiB0YWcgaW4g dGhlIFJlcXVpcmUgaGVhZGVyIGZpZWxkIG9mIGFueSByZXF1ZXN0IG90aGVyIHRoYW4NCiAgIFJF RkVSLiAgQSBVQSBNVVNUIE5PVCBpbmNsdWRlIHRoZSAnZXhwbGljaXRzdWInIG9yICdub3N1Yicg b3B0aW9uDQogICB0YWcgaW4gdGhlIFJlcXVpcmUgaGVhZGVyIGZpZWxkIG9mIGFueSBTSVAgcmVz cG9uc2Ugb3RoZXIgdGhhbiBhDQogICAyMDAgb3IgNDIxIHJlc3BvbnNlIHRvIGEgUkVGRVIgcmVx dWVzdC4NCg0KICAgVGhlICdleHBsaWNpdHN1YicgYW5kICdub3N1Yicgb3B0aW9uIHRhZ3MgTUFZ IGFwcGVhciBpbiB0aGUgU3VwcG9ydGVkDQogICBoZWFkZXIgZmllbGQgb2YgU0lQIG1lc3NhZ2Vz LCBhbmQgaW4gc2lwLmV4dGVuc2lvbnMgZmVhdHVyZSB0YWcNCiAgIGRlZmluZWQgaW4gW1JGQzM4 NDBdLiAgVGhpcyBzaWduYWxzIG9ubHkgdGhhdCB0aGUgVUEgaW5jbHVkaW5nIHRoZQ0KICAgdmFs dWUgaXMgYXdhcmUgb2YgdGhlIGV4dGVuc2lvbnMuICBJbiBwYXJ0aWN1bGFyLCBhIFVBIGNhbiBv bmx5DQogICBpbnZva2UgdGhlIHVzZSBvZiBvbmUgb2YgdGhlIGV4dGVuc2lvbnMgaW4gYSByZXF1 ZXN0LiAgQSBVQSBNVVNUIE5PVA0KICAgaW5jbHVkZSBlaXRoZXIgb3B0aW9uIHRhZyBpbiB0aGUg UmVxdWlyZSBoZWFkZXIgZmllbGQgb2YgYSAyMDAgcmVzcG9uc2UNCiAgIHRvIGEgUkVGRVIgcmVx dWVzdCBpZiB0aGF0IHRhZyB3YXMgbm90IHByZXNlbnQgaW4gdGhlIFJlcXVpcmUgaGVhZGVyIGZp ZWxkDQogICBvZiB0aGUgcmVxdWVzdC4gQSBVc2VyLUFnZW50IFNlcnZlciAoVUFTKSB0aGF0IGlz IHByb2Nlc3NpbmcgYSBSRUZFUg0KICAgcmVxdWVzdCB0aGF0IGxpc3RzICdleHBsaWNpdHN1Yicg b3IgJ25vc3ViJyBpbiBpdHMgU3VwcG9ydGVkIGhlYWRlciBmaWVsZA0KICAgYW5kIHdpc2hlcyB0 byB1c2Ugb25lIG9mIHRob3NlIGV4dGVuc2lvbnMgd2lsbCByZXR1cm4gYSA0MjEgcmVzcG9uc2UN CiAgIGluZGljYXRpbmcgd2hpY2ggZXh0ZW5zaW9uIGlzIHJlcXVpcmVkLg0K --_000_7594FB04B1934943A5C02806D1A2204B1D4E22F4ESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29s b3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg NzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIGdlbmVyYWwgSSBhbSBvayB3aXRoIHRoZSBhcHByb2FjaCBz ZWVuIGluIHRoZSBkaWZmLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SG93ZXZlciwgcmVsYXRlZCB0byB0aGUgc2VtYW50 aWNzLCBJIHRoaW5rIHdlIGluIHNlY3Rpb24gNiBzaG91bGQgbWFrZSBpdCBtb3JlIGNsZWFyIHRo YXQsIHdoZW4gcHJlc2VudCBpbiB0aGUgUmVxdWlyZSBoZWFkZXIgZmllbGQsIHRoZSBzZW1hbnRp Y3MgbWVhbnMg4oCcTVVTVA0KIFNVUFBPUlQgKjxiPkFORDwvYj4qIE1VU1QgVVNF4oCdLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VGhhdCBjb3VsZCBiZSBkb25lIGUuZy4gYnkgZXh0ZW5kaW5nIHRoZSBmb2xsb3dpbmcg c2VudGVuY2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5i c3A7IOKAnFRoZSB1c2Ugb2YgZWl0aGVyIG9wdGlvbiB0YWcgaW4gYSBSZXF1aXJlIGhlYWRlciBm aWVsZCBpcyBvbmx5IGRlZmluZWQgd2hlbiBpdCBhcHBlYXJzIGluIGEgUkVGRVIgcmVxdWVzdC7i gJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPuKApnRvOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyDigJxUaGUgdXNlIG9mIGVpdGhlciBvcHRpb24gdGFnIGluIGEgUmVxdWlyZSBoZWFkZXIgZmll bGQgaXMgb25seSBkZWZpbmVkIHdoZW4gaXQgYXBwZWFycyBpbiBhIFJFRkVSIHJlcXVlc3QsIGFu ZCBpbmRpY2F0ZXMgdGhhdCB0aGUgcmVjZWl2ZXIsDQogaWYgaXQgYWNjZXB0cyB0aGUgcmVxdWVz dCwgbXVzdCBzdXBwb3J0IGFuZCB1c2UgdGhlIGV4dGVuc2lvbiBhc3NvY2lhdGVkIHdpdGggdGhl IG9wdGlvbi10YWcu4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93 dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndp bmRvd3RleHQiPiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQgU3BhcmtzPGJyPg0KPGI+U2VudDo8L2I+IDMuIG1hcnJh c2t1dXRhIDIwMTQgMjM6MDk8YnI+DQo8Yj5Ubzo8L2I+IHNpcGNvcmVAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW3NpcGNvcmVdIE9wZW4gaXNzdWUgaW4gcmVmZXItZXhwbGljaXQtc3Vi c2NyaXB0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0wMiBjYWxscyBvdXQgb25lIG9wZW4gaXNzdWUgLSBiZXR0ZXIgYWxpZ25pbmcgd2l0aCAzMjYx IFN1cHBvcnRlZC9SZXF1aXJlIGRlZmluaXRpb25zLCBhbmQgdXNpbmcgNDIxIGNvcnJlY3RseS48 YnI+DQo8YnI+DQpBcyBtb3N0IGZvbGtzIGtub3csIHRoZXJlIGhhcyBiZWVuIG1hbnkgdGhyZWFk cyBvbiB0aGUgc2VtYW50aWNzIG9mIFN1cHBvcnRlZCBhbmQgUmVxdWlyZS4gV2UncmUgYXZvaWRp bmcgdGhlIHByb2JsZW1zIG1vc3Qgb2YgdGhvc2UgdGhyZWFkcyBjYWxsIG91dCBieSBiZWluZyB2 ZXJ5IHNwZWNpZmljIHdpdGggd2hlbiB0aGlzIGV4dGVuc2lvbiBjYW4gYmUgdXNlZCwgYW5kIHdo YXQgdG8gcHV0IGluIHRoZSBtZXNzYWdlcyB3aGVuIGl0IGlzIHVzZWQuDQogV2UncmUgYWxtb3N0 IGFsaWduZWQgd2l0aCB3aGF0J3MgaW4gMzI2MSwgYnV0IEl2byBjYWxsZWQgbXkgYXR0ZW50aW9u IHNvbWUgdGltZSBiYWNrIHRvIGEgcm91Z2ggZWRnZSB3aXRoIHJlc3BvbnNlcy4gU2VjdGlvbiA4 LjEuMS45IG9mIFJGQzMyNjEgcmVxdWlyZXMgcmVzcG9uZGVycyB0byBsaXN0IGFueSBleHRlbnNp b25zIGFwcGxpZWQgdG8gYSByZXN1bHQgaW4gYSBSZXF1aXJlIGhlYWRlciBmaWVsZC4gTm93IHdl IGNvdWxkIGJ1cm4gYSBfbG90Xw0KIG1vcmUgdGltZSBhcmd1aW5nIGFib3V0IHdoZXRoZXIgZG9p bmcgc28gaXMgd29ydGh3aGlsZSBzaW5jZSB3ZSBjYW4gb25seSBhcHBseSB0aGlzIGV4dGVuc2lv biBpZiBpdCB3YXMgUmVxdWlyZWQgaW4gYSByZXF1ZXN0LCBidXQgSSBkb24ndCB0aGluayBpdCdz IHdvcnRoIHRoZSBlZmZvcnQuDQo8YnI+DQo8YnI+DQpJbnN0ZWFkLCBJIHRoaW5rIHRoZSBmb2xs b3dpbmcgcmVwbGFjZW1lbnQgZm9yIHNlY3Rpb24gNiBvZiB0aGUgZHJhZnQgZ2V0cyB1cyB0byBh IHBsYWNlIHdoZXJlIHdlIGFyZW4ndCBpbiBjb25mbGljdCB3aXRoIGFueSAzMjYxIHRleHQuIFlv dSBjYW4gZmluZCBhIHNpZGUtYnktc2lkZSBkaWZmIG9mIHRoaXMgc3VnZ2VzdGlvbiBhZ2FpbnN0 IHRoZSBjdXJyZW50IHNlY3Rpb24gYXQNCjxhIGhyZWY9Imh0dHA6Ly93d3cubm9zdHJ1bS5jb20v fnJqc3BhcmtzL2RpZmZfYmVmb3JlX2FmdGVyLmh0bWwiPiZsdDtodHRwOi8vd3d3Lm5vc3RydW0u Y29tL35yanNwYXJrcy9kaWZmX2JlZm9yZV9hZnRlci5odG1sJmd0OzwvYT4uPGJyPg0KPGJyPg0K SWYgdGhpcyB3b3JrcyBmb3IgZm9sa3MsIHRoZW4gSSBkb24ndCB0aGluayB3ZSBuZWVkIHRpbWUg aW4gSG9ub2x1bHUgdG8gZGlzY3VzcyBpdC48YnI+DQo8YnI+DQo8YnI+DQotLS0tLS08YnI+DQo8 YnI+DQo2LiBUaGUgJ2V4cGxpY2l0c3ViJyBhbmQgJ25vc3ViJyBPcHRpb24gVGFnczxicj4NCjxi cj4NCiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlICdleHBsaWNpdHN1Yicg b3B0aW9uIHRhZywgdXNlZCB0byBzaWduYWw8YnI+DQombmJzcDsmbmJzcDsgdGhlIHVzZSBvZiB0 aGUgZXh0ZW5zaW9uIGRlZmluZWQgaW4gU2VjdGlvbiA0LCBhbmQgdGhlICdub3N1Yicgb3B0aW9u PGJyPg0KJm5ic3A7Jm5ic3A7IHRhZywgdXNlZCB0byBzaWduYWwgdGhlIHVzZSBvZiB0aGUgZXh0 ZW5zaW9uIGRlZmluZWQgaW4gU2VjdGlvbiA1Ljxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyBUaGUg dXNlIG9mIGVpdGhlciBvcHRpb24gdGFnIGluIGEgUmVxdWlyZSBoZWFkZXIgZmllbGQgaXMgb25s eTxicj4NCiZuYnNwOyZuYnNwOyBkZWZpbmVkIHdoZW4gaXQgYXBwZWFycyBpbiBhIFJFRkVSIHJl cXVlc3Qgb3IgYSByZXNwb25zZSB0byBhPGJyPg0KJm5ic3A7Jm5ic3A7IFJFRkVSIHJlcXVlc3Qu Jm5ic3A7IEEgVUEgTVVTVCBOT1QgaW5jbHVkZSB0aGUgJ2V4cGxpY2l0c3ViJyBvciAnbm9zdWIn IDxicj4NCiZuYnNwOyZuYnNwOyBvcHRpb24gdGFnIGluIHRoZSBSZXF1aXJlIGhlYWRlciBmaWVs ZCBvZiBhbnkgcmVxdWVzdCBvdGhlciB0aGFuIDxicj4NCiZuYnNwOyZuYnNwOyBSRUZFUi4mbmJz cDsgQSBVQSBNVVNUIE5PVCBpbmNsdWRlIHRoZSAnZXhwbGljaXRzdWInIG9yICdub3N1Yicgb3B0 aW9uIDxicj4NCiZuYnNwOyZuYnNwOyB0YWcgaW4gdGhlIFJlcXVpcmUgaGVhZGVyIGZpZWxkIG9m IGFueSBTSVAgcmVzcG9uc2Ugb3RoZXIgdGhhbiBhIDxicj4NCiZuYnNwOyZuYnNwOyAyMDAgb3Ig NDIxIHJlc3BvbnNlIHRvIGEgUkVGRVIgcmVxdWVzdC48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsg VGhlICdleHBsaWNpdHN1YicgYW5kICdub3N1Yicgb3B0aW9uIHRhZ3MgTUFZIGFwcGVhciBpbiB0 aGUgU3VwcG9ydGVkPGJyPg0KJm5ic3A7Jm5ic3A7IGhlYWRlciBmaWVsZCBvZiBTSVAgbWVzc2Fn ZXMsIGFuZCBpbiBzaXAuZXh0ZW5zaW9ucyBmZWF0dXJlIHRhZzxicj4NCiZuYnNwOyZuYnNwOyBk ZWZpbmVkIGluIFtSRkMzODQwXS4mbmJzcDsgVGhpcyBzaWduYWxzIG9ubHkgdGhhdCB0aGUgVUEg aW5jbHVkaW5nIHRoZTxicj4NCiZuYnNwOyZuYnNwOyB2YWx1ZSBpcyBhd2FyZSBvZiB0aGUgZXh0 ZW5zaW9ucy4mbmJzcDsgSW4gcGFydGljdWxhciwgYSBVQSBjYW4gb25seTxicj4NCiZuYnNwOyZu YnNwOyBpbnZva2UgdGhlIHVzZSBvZiBvbmUgb2YgdGhlIGV4dGVuc2lvbnMgaW4gYSByZXF1ZXN0 LiZuYnNwOyBBIFVBIE1VU1QgTk9UPGJyPg0KJm5ic3A7Jm5ic3A7IGluY2x1ZGUgZWl0aGVyIG9w dGlvbiB0YWcgaW4gdGhlIFJlcXVpcmUgaGVhZGVyIGZpZWxkIG9mIGEgMjAwIHJlc3BvbnNlIDxi cj4NCiZuYnNwOyZuYnNwOyB0byBhIFJFRkVSIHJlcXVlc3QgaWYgdGhhdCB0YWcgd2FzIG5vdCBw cmVzZW50IGluIHRoZSBSZXF1aXJlIGhlYWRlciBmaWVsZDxicj4NCiZuYnNwOyZuYnNwOyBvZiB0 aGUgcmVxdWVzdC4gQSBVc2VyLUFnZW50IFNlcnZlciAoVUFTKSB0aGF0IGlzIHByb2Nlc3Npbmcg YSBSRUZFUiA8YnI+DQombmJzcDsmbmJzcDsgcmVxdWVzdCB0aGF0IGxpc3RzICdleHBsaWNpdHN1 Yicgb3IgJ25vc3ViJyBpbiBpdHMgU3VwcG9ydGVkIGhlYWRlciBmaWVsZCA8YnI+DQombmJzcDsm bmJzcDsgYW5kIHdpc2hlcyB0byB1c2Ugb25lIG9mIHRob3NlIGV4dGVuc2lvbnMgd2lsbCByZXR1 cm4gYSA0MjEgcmVzcG9uc2UgPGJyPg0KJm5ic3A7Jm5ic3A7IGluZGljYXRpbmcgd2hpY2ggZXh0 ZW5zaW9uIGlzIHJlcXVpcmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D4E22F4ESESSMB209erics_-- From nobody Tue Nov 4 05:24:31 2014 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 EC5531A1B36 for ; Tue, 4 Nov 2014 05:24:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mikw48yHaZSi for ; Tue, 4 Nov 2014 05:24:27 -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 A1A701A1B0D for ; Tue, 4 Nov 2014 05:24:26 -0800 (PST) X-AuditID: c1b4fb3a-f79596d000001123-4b-5458d3885d2a Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 54.49.04387.883D8545; Tue, 4 Nov 2014 14:24:24 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.4]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0174.001; Tue, 4 Nov 2014 14:24:24 +0100 From: Ivo Sedlacek To: "sipcore@ietf.org" Thread-Topic: Comments to draft-sparks-sipcore-refer-clarifications-05.txt Thread-Index: Ac/4LMFVGM+M7RbfTpKpZBAgcDmyYA== Date: Tue, 4 Nov 2014 13:24:23 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127852C3@ESESSMB301.ericsson.se> 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: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101127852C3ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM+JvjW7H5YgQg3W/LSyuzWlks/j6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJXRMm0Ha8GUxYwVu/4cZWxgfDGPsYuRk0NC wETieMNnVghbTOLCvfVsXYxcHEICRxglDv59xArhLGSUOPZ8OlgHm4CexMQtR8A6RAQ0JZZ/ 28oOYjMLaEg8mbIGqIaDQ1jAVeLCaz+IEi+J/ad2sEDYehL93T1MIDaLgIrE2db/YDavgK/E y65PbCA2o4CsxNU/vYwQI8Ulbj2ZzwRxnIDEkj3nmSFsUYmXj/9BHa0o8fHVPqj6fInPO96z QcwUlDg58wnLBEbhWUhGzUJSNgtJ2Sygq5mBvlm/Sx+iRFFiSvdD9llQj7XOmcuOLL6AkX0V o2hxanFxbrqRkV5qUWZycXF+nl5easkmRmAEHdzy22oH48HnjocYBTgYlXh4DRwjQoRYE8uK K3MPMUpzsCiJ8y48Ny9YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6O99hf+rFPs/x7wXRc9 HGCibZtZUOdktvS7XXKKUdSb/zzObivtn7PdWSsieM4vY3L31ZvBzXNmym4Ra05betKrJvPF iwtcFvGaZtGaskX+D49NDNhydm3aWmnXokbdm5W85hlxfR8eSRpGfZnHkhP4eel0TyeL1Iev Nl/YtyP904Pusv38M5RYijMSDbWYi4oTAU0/THWBAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/nyCHw7isnpXqPCZNO7jCPc-V-0s Subject: [sipcore] Comments to draft-sparks-sipcore-refer-clarifications-05.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, 04 Nov 2014 13:24:30 -0000 --_000_39B5E4D390E9BD4890E2B31079006101127852C3ESESSMB301erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCg0KDQpJIHJldmlld2VkIHRoZSBkcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1j bGFyaWZpY2F0aW9ucy0wNSBhbmQgaGVyZSBhcmUgbXkgY29tbWVudHM6DQoNCg0KDQpDT01NRU5U IDE6DQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpBYnN0cmFjdCBzdGF0ZXMgIkFuIGFjY2VwdGVk IFNJUCBSRUZFUiBtZXRob2QgY3JlYXRlcyBhbiBpbXBsaWNpdCBzdWJzY3JpcHRpb24gdXNpbmcg dGhlIFNJUC1TcGVjaWZpYyBFdmVudCBOb3RpZmljYXRpb24gRnJhbWV3b3JrLiINCg0KDQoNClRo aXMgaXMgb25seSBwYXJ0bHkgdHJ1ZSBzaW5jZSBjcmVhdGlvbiBvZiBpbXBsaWNpdCBzdWJzY3Jp cHRpb24gZG8gbm90IG5lY2Vzc2FyaWx5IGhhcHBlbiB3aGVuIGRyYWZ0LXNwYXJrcy1zaXBjb3Jl LXJlZmVyLWV4cGxpY2l0LXN1YnNjcmlwdGlvbiBpcyB1c2VkIG9yIHdoZW4gUkZDNDQ4OCBpcyB1 c2VkIChhc3N1bWluZyBhcHBsaWNhdGlvbiBzcGVjaWZpYyBsb2dpYyBlbnN1cmVzIHRoYXQgdGhl IGltcGxpY2l0IHN1YnNjcmlwdGlvbiBpcyBub3QgY3JlYXRlZCkuDQoNCi0tLS0tLS0tLS0tLS0t LS0tLQ0KDQoNCg0KUFJPUE9TRUQgU09MVVRJT04gMToNCg0KLS0tLS0tLS0tLS0tLS0tLS0tDQoN ClN0YXRlOiAiQW4gYWNjZXB0ZWQgU0lQIFJFRkVSIG1ldGhvZCA+PmNhbjw8IGNyZWF0ZSBhbiBp bXBsaWNpdCBzdWJzY3JpcHRpb24gdXNpbmcgdGhlIFNJUC1TcGVjaWZpYyBFdmVudCBOb3RpZmlj YXRpb24gRnJhbWV3b3JrLiINCg0KLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQpDT01NRU5UIDI6 DQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpTZWN0aW9uIDIgc3RhdGVzICJBbiBhY2NlcHRlZCBT SVAgUkVGRVIgbWV0aG9kIGNyZWF0ZXMgYW4gaW1wbGljaXQgc3Vic2NyaXB0aW9uIHVzaW5nIHRo ZSBTSVAtU3BlY2lmaWMgRXZlbnQgTm90aWZpY2F0aW9uIEZyYW1ld29yay4iDQoNCg0KDQpUaGlz IGlzIG9ubHkgcGFydGx5IHRydWUgc2luY2UgY3JlYXRpb24gb2YgaW1wbGljaXQgc3Vic2NyaXB0 aW9uIGRvIG5vdCBuZWNlc3NhcmlseSBoYXBwZW4gd2hlbiBkcmFmdC1zcGFya3Mtc2lwY29yZS1y ZWZlci1leHBsaWNpdC1zdWJzY3JpcHRpb24gaXMgdXNlZCBvciB3aGVuIFJGQzQ0ODggaXMgdXNl ZCAoYXNzdW1pbmcgYXBwbGljYXRpb24gc3BlY2lmaWMgbG9naWMgZW5zdXJlcyB0aGF0IHRoZSBp bXBsaWNpdCBzdWJzY3JpcHRpb24gaXMgbm90IGNyZWF0ZWQpLg0KDQotLS0tLS0tLS0tLS0tLS0t LS0NCg0KDQoNClBST1BPU0VEIFNPTFVUSU9OIDI6DQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpT dGF0ZTogIkFuIGFjY2VwdGVkIFNJUCBSRUZFUiBtZXRob2QgPj5jYW48PCBjcmVhdGUgYW4gaW1w bGljaXQgc3Vic2NyaXB0aW9uIHVzaW5nIHRoZSBTSVAtU3BlY2lmaWMgRXZlbnQgTm90aWZpY2F0 aW9uIEZyYW1ld29yay4iDQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KQ09NTUVOVCAzOg0K DQotLS0tLS0tLS0tLS0tLS0tLS0NCg0KU2VjdGlvbiAzIHN0YXRlcyAiDQoNCiAgIFNlY3Rpb24g NC41LjEgb2YgW1JGQzY2NjVdIG1ha2VzIEdSVVUgW1JGQzU2MjddIG1hbmRhdG9yeSB0bw0KDQog ICBpbXBsZW1lbnQgYW5kIHVzZSBhcyB0aGUgbG9jYWwgdGFyZ2V0IGluIHRoZSBzdWJzY3JpcHRp b24gY3JlYXRlZCBieQ0KDQogICB0aGUgUkVGRVIgcmVxdWVzdC4NCg0KIg0KDQoNCg0KSW4gUkZD NjY2NSwgdXNhZ2Ugb2YgR1JVVSBpcyBtYW5kYXRvcnkgZm9yIG5vdGlmaWVyICgiPj5Ob3RpZmll cnM8PCBNVVNUIGltcGxlbWVudCB0aGUgR2xvYmFsbHkgUm91dGFibGUgVXNlciBBZ2VudCBVUkkg KEdSVVUpIGV4dGVuc2lvbiBkZWZpbmVkIGluIFtSRkM1NjI3XSwgYW5kIE1VU1QgdXNlIGEgR1JV VSBhcyB0aGVpciBsb2NhbCB0YXJnZXQuIiksIHdoaWxlIHRoZSBzdGF0ZW1lbnQgYWJvdmUgY291 bGQgYmUgdW5kZXJzdG9vZCB0byByZWZlciB0byBib3RoIHN1YnNjcmliZXIgYW5kIG5vdGlmaWVy Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNClBST1BPU0VEIFNPTFVUSU9OIDM6DQoNCi0t LS0tLS0tLS0tLS0tLS0tLQ0KDQpTdGF0ZTogIg0KDQogICBTZWN0aW9uIDQuNS4xIG9mIFtSRkM2 NjY1XSBtYWtlcyBHUlVVIFtSRkM1NjI3XSBtYW5kYXRvcnkgdG8NCg0KICAgaW1wbGVtZW50IGFu ZCB1c2UgYXMgdGhlIGxvY2FsIHRhcmdldCA+PmJ5IG5vdGlmaWVyczw8IGluIHRoZSBzdWJzY3Jp cHRpb24gY3JlYXRlZCBieQ0KDQogICB0aGUgUkVGRVIgcmVxdWVzdC4NCg0KIg0KDQotLS0tLS0t LS0tLS0tLS0tLS0NCg0KDQoNCkNPTU1FTlQgNDoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tDQoNClNl Y3Rpb24gMyBzdGF0ZXMgIg0KDQogICBBIFVBIHRoYXQgd2lsbCBhY2NlcHQgYSBSRUZFUiByZXF1 ZXN0IG5lZWRzIHRvIGluY2x1ZGUgYSBHUlVVIGluIHRoZQ0KDQogICBDb250YWN0IGhlYWRlciBm aWVsZCBvZiBhbGwgSU5WSVRFIHJlcXVlc3RzLiAgVGhpcyBlbnN1cmVzIHRoYXQgb3V0LQ0KDQog ICBvZi1kaWFsb2cgUkVGRVIgcmVxdWVzdHMgY29ycmVzcG9uZGluZyB0byBhbnkgcmVzdWx0aW5n IElOVklURQ0KDQogICBkaWFsb2dzIGFycml2ZSBhdCB0aGlzIFVBLiAgRnV0dXJlIGV4dGVuc2lv bnMgKHN1Y2ggYXMNCg0KICAgW0ktRC5zcGFya3Mtc2lwY29yZS1yZWZlci1leHBsaWNpdC1zdWJz Y3JpcHRpb25dKSBtaWdodCByZWxheCB0aGlzDQoNCiAgIHJlcXVpcmVtZW50IGJ5IGRlZmluaW5n IGEgUkVGRVIgcmVxdWVzdCB0aGF0IGNhbm5vdCBjcmVhdGUgYW4NCg0KICAgaW1wbGljaXQgc3Vi c2NyaXB0aW9uLg0KDQoiDQoNCg0KDQpUaGUgVUEgbWlnaHQgYmUgZ2xvYmFsbHkgcmVhY2hhYmxl IHdpdGhvdXQgaW5kaWNhdGluZyBHUlVVIC0gdGhpcyBpcyBjb21tb24gdG9kYXkgd2l0aCBuZXR3 b3JrIGNvbmZlcmVuY2Ugc2VydmVycy4gUmVxdWlyaW5nIEdSVVUgaXMgdW5uZWNlc3NhcnkuDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KUFJPUE9TRUQgU09MVVRJT04gNDoNCg0KLS0tLS0t LS0tLS0tLS0tLS0tDQoNCk1ha2UgdGhlIHN0YXRlbWVudCBnZW5lcmFsIHRvIHN0YXRlIHRoYXQg dGhlIFVBIG11c3QgcHJvdmlkZSBVUkkgd2hpY2ggaXMgYSBnbG9iYWxseSByZWFjaGFibGUgaW4g dGhlIENvbnRhY3Qgb2YgSU5WSVRFIHJlcXVlc3RzLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0NCg0K DQoNCkNPTU1FTlQgNToNCg0KLS0tLS0tLS0tLS0tLS0tLS0tDQoNClNlY3Rpb24gNCwgMXN0IHBh cmFncmFwaCBhbmQgMm5kIHBhcmFncmFwaCBwcm92aWRlIG92ZXJsYXBwaW5nIGluZm9ybWF0aW9u Lg0KDQoNCg0KSW4gMXN0IHBhcmFncmFwaCwgdGhlcmUgaXMgYSBzdGF0ZW1lbnQgdGhhdCBpZiBy ZW1vdGUgVUEgcHJvdmlkZWQgYSBHUlVVIGFzIGl0cyBsb2NhbCB0YXJnZXQgdGhlbiBhIHVzZXIg YWdlbnQgc2VuZGluZyBhIFJFRkVSIHJlcXVlc3QgKHRvd2FyZHMgdGhhdCB0YXJnZXQpIHRoYXQg Y291bGQgcmVzdWx0IGluIGFuICBpbXBsaWNpdCBzdWJzY3JpcHRpb24gd2l0aGluIGEgZGlhbG9n IGlzIHByb2hpYml0ZWQuDQoNCg0KDQpJbiAybmQgcGFyYWdyYXBoLCB0aGUgc2FtZSBpcyBzdGF0 ZWQgKGluIHBvc2l0aXZlIHdheSkgcmVnYXJkbGVzcyB3aGV0aGVyIHRoZSByZW1vdGUgVUEgcHJv dmlkZWQgYSBHUlVVIGFzIGl0cyBsb2NhbCB0YXJnZXQgb3Igbm90Lg0KDQotLS0tLS0tLS0tLS0t LS0tLS0NCg0KDQoNClBST1BPU0VEIFNPTFVUSU9OIDU6DQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0K DQpSZW1vdmUgdGhlIDFzdCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiA0Lg0KDQotLS0tLS0tLS0tLS0t LS0tLS0NCg0KDQoNCkNPTU1FTlQgNjoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tDQoNClNlY3Rpb24g MyBzdGF0ZXM6ICINCg0KICAgQSB1c2VyIGFnZW50IGNvbnN0cnVjdGluZyBhbnkgUkVGRVIgdGhh dCBjYW4gcmVzdWx0IGluIGFuIGltcGxpY2l0DQoNCiAgIHN1YnNjcmlwdGlvbiBNVVNUIHBvcHVs YXRlIGl0cyBDb250YWN0IGhlYWRlciBmaWVsZCB3aXRoIGEgR1JVVS4NCg0KIg0KDQoNCg0KSW4g UkZDNjY1LCB0aGVyZSBpcyBubyBzdWNoIHJlcXVpcmVtZW50IGZvciBzdWJzY3JpYmVyLiBXaHkg ZG8gd2Ugc3RhdGUgc3VjaCBuZXcgcmVxdWlyZW1lbnQ/DQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0K DQoNCg0KUFJPUE9TRUQgU09MVVRJT04gNjoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkNsYXJp ZnkgdGhlIG5lZWQgZm9yIHRoaXMgcmVxdWlyZW1lbnQgb3IgcmVtb3ZlIGl0Lg0KDQotLS0tLS0t LS0tLS0tLS0tLS0NCg0KDQoNCktpbmQgcmVnYXJkcw0KDQoNCg0KSXZvIFNlZGxhY2VrDQo= --_000_39B5E4D390E9BD4890E2B31079006101127852C3ESESSMB301erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxh aW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRl eHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJl Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkhlbGxvLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5J IHJldmlld2VkIHRoZSBkcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1jbGFyaWZpY2F0aW9ucy0w NSBhbmQgaGVyZSBhcmUgbXkgY29tbWVudHM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PkNPTU1FTlQgMTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0t LS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QWJz dHJhY3Qgc3RhdGVzICZxdW90O0FuIGFjY2VwdGVkIFNJUCBSRUZFUiBtZXRob2QgY3JlYXRlcyBh biBpbXBsaWNpdCBzdWJzY3JpcHRpb24gdXNpbmcgdGhlIFNJUC1TcGVjaWZpYyBFdmVudCBOb3Rp ZmljYXRpb24gRnJhbWV3b3JrLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5U aGlzIGlzIG9ubHkgcGFydGx5IHRydWUgc2luY2UgY3JlYXRpb24gb2YgaW1wbGljaXQgc3Vic2Ny aXB0aW9uIGRvIG5vdCBuZWNlc3NhcmlseSBoYXBwZW4gd2hlbiBkcmFmdC1zcGFya3Mtc2lwY29y ZS1yZWZlci1leHBsaWNpdC1zdWJzY3JpcHRpb24gaXMgdXNlZCBvciB3aGVuIFJGQzQ0ODggaXMg dXNlZCAoYXNzdW1pbmcgYXBwbGljYXRpb24gc3BlY2lmaWMgbG9naWMgZW5zdXJlcyB0aGF0IHRo ZSBpbXBsaWNpdA0KIHN1YnNjcmlwdGlvbiBpcyBub3QgY3JlYXRlZCkuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+UFJPUE9TRUQgU09MVVRJT04gMTo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U3RhdGU6ICZxdW90O0FuIGFjY2VwdGVkIFNJUCBSRUZF UiBtZXRob2QgJmd0OyZndDtjYW4mbHQ7Jmx0OyBjcmVhdGUgYW4gaW1wbGljaXQgc3Vic2NyaXB0 aW9uIHVzaW5nIHRoZSBTSVAtU3BlY2lmaWMgRXZlbnQgTm90aWZpY2F0aW9uIEZyYW1ld29yay4m cXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tLS0tLS0t LS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5DT01NRU5UIDI6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlNlY3Rpb24gMiBzdGF0ZXMgJnF1b3Q7 QW4gYWNjZXB0ZWQgU0lQIFJFRkVSIG1ldGhvZCBjcmVhdGVzIGFuIGltcGxpY2l0IHN1YnNjcmlw dGlvbiB1c2luZyB0aGUgU0lQLVNwZWNpZmljIEV2ZW50IE5vdGlmaWNhdGlvbiBGcmFtZXdvcmsu JnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoaXMgaXMgb25seSBwYXJ0bHkg dHJ1ZSBzaW5jZSBjcmVhdGlvbiBvZiBpbXBsaWNpdCBzdWJzY3JpcHRpb24gZG8gbm90IG5lY2Vz c2FyaWx5IGhhcHBlbiB3aGVuIGRyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWV4cGxpY2l0LXN1 YnNjcmlwdGlvbiBpcyB1c2VkIG9yIHdoZW4gUkZDNDQ4OCBpcyB1c2VkIChhc3N1bWluZyBhcHBs aWNhdGlvbiBzcGVjaWZpYyBsb2dpYyBlbnN1cmVzIHRoYXQgdGhlIGltcGxpY2l0DQogc3Vic2Ny aXB0aW9uIGlzIG5vdCBjcmVhdGVkKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPi0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Q Uk9QT1NFRCBTT0xVVElPTiAyOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+LS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5TdGF0ZTogJnF1b3Q7QW4gYWNjZXB0ZWQgU0lQIFJFRkVSIG1ldGhvZCAmZ3Q7Jmd0O2Nh biZsdDsmbHQ7IGNyZWF0ZSBhbiBpbXBsaWNpdCBzdWJzY3JpcHRpb24gdXNpbmcgdGhlIFNJUC1T cGVjaWZpYyBFdmVudCBOb3RpZmljYXRpb24gRnJhbWV3b3JrLiZxdW90OzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkNPTU1FTlQgMzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPi0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+U2VjdGlvbiAzIHN0YXRlcyAmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBTZWN0aW9uIDQuNS4xIG9mIFtSRkM2 NjY1XSBtYWtlcyBHUlVVIFtSRkM1NjI3XSBtYW5kYXRvcnkgdG88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBpbXBsZW1lbnQgYW5kIHVzZSBhcyB0 aGUgbG9jYWwgdGFyZ2V0IGluIHRoZSBzdWJzY3JpcHRpb24gY3JlYXRlZCBieTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHRoZSBSRUZFUiByZXF1 ZXN0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+JnF1b3Q7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkluIFJGQzY2NjUsIHVzYWdlIG9mIEdSVVUgaXMgbWFu ZGF0b3J5IGZvciBub3RpZmllciAoJnF1b3Q7Jmd0OyZndDtOb3RpZmllcnMmbHQ7Jmx0OyBNVVNU IGltcGxlbWVudCB0aGUgR2xvYmFsbHkgUm91dGFibGUgVXNlciBBZ2VudCBVUkkgKEdSVVUpIGV4 dGVuc2lvbiBkZWZpbmVkIGluIFtSRkM1NjI3XSwgYW5kIE1VU1QgdXNlIGEgR1JVVSBhcyB0aGVp ciBsb2NhbCB0YXJnZXQuJnF1b3Q7KSwgd2hpbGUgdGhlIHN0YXRlbWVudCBhYm92ZSBjb3VsZA0K IGJlIHVuZGVyc3Rvb2QgdG8gcmVmZXIgdG8gYm90aCBzdWJzY3JpYmVyIGFuZCBub3RpZmllci48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tLS0tLS0tLS0tLS0t LTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QUk9QT1NFRCBTT0xVVElPTiAzOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS0tLS0tLS0tLS0tLS0tPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TdGF0ZTogJnF1b3Q7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgU2VjdGlvbiA0 LjUuMSBvZiBbUkZDNjY2NV0gbWFrZXMgR1JVVSBbUkZDNTYyN10gbWFuZGF0b3J5IHRvPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgaW1wbGVtZW50 IGFuZCB1c2UgYXMgdGhlIGxvY2FsIHRhcmdldCAmZ3Q7Jmd0O2J5IG5vdGlmaWVycyZsdDsmbHQ7 IGluIHRoZSBzdWJzY3JpcHRpb24gY3JlYXRlZCBieTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IHRoZSBSRUZFUiByZXF1ZXN0LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+JnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Q09NTUVOVCA0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+LS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5TZWN0aW9uIDMgc3RhdGVzICZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IEEgVUEgdGhhdCB3aWxsIGFjY2VwdCBhIFJFRkVS IHJlcXVlc3QgbmVlZHMgdG8gaW5jbHVkZSBhIEdSVVUgaW4gdGhlPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgQ29udGFjdCBoZWFkZXIgZmllbGQg b2YgYWxsIElOVklURSByZXF1ZXN0cy4mbmJzcDsgVGhpcyBlbnN1cmVzIHRoYXQgb3V0LTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IG9mLWRpYWxv ZyBSRUZFUiByZXF1ZXN0cyBjb3JyZXNwb25kaW5nIHRvIGFueSByZXN1bHRpbmcgSU5WSVRFPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgZGlhbG9n cyBhcnJpdmUgYXQgdGhpcyBVQS4mbmJzcDsgRnV0dXJlIGV4dGVuc2lvbnMgKHN1Y2ggYXM8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBbSS1ELnNw YXJrcy1zaXBjb3JlLXJlZmVyLWV4cGxpY2l0LXN1YnNjcmlwdGlvbl0pIG1pZ2h0IHJlbGF4IHRo aXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBy ZXF1aXJlbWVudCBieSBkZWZpbmluZyBhIFJFRkVSIHJlcXVlc3QgdGhhdCBjYW5ub3QgY3JlYXRl IGFuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg aW1wbGljaXQgc3Vic2NyaXB0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+JnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBVQSBtaWdodCBi ZSBnbG9iYWxseSByZWFjaGFibGUgd2l0aG91dCBpbmRpY2F0aW5nIEdSVVUgLSB0aGlzIGlzIGNv bW1vbiB0b2RheSB3aXRoIG5ldHdvcmsgY29uZmVyZW5jZSBzZXJ2ZXJzLiBSZXF1aXJpbmcgR1JV VSBpcyB1bm5lY2Vzc2FyeS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi Pi0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QUk9QT1NF RCBTT0xVVElPTiA0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0t LS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5N YWtlIHRoZSBzdGF0ZW1lbnQgZ2VuZXJhbCB0byBzdGF0ZSB0aGF0IHRoZSBVQSBtdXN0IHByb3Zp ZGUgVVJJIHdoaWNoIGlzIGEgZ2xvYmFsbHkgcmVhY2hhYmxlIGluIHRoZSBDb250YWN0IG9mIElO VklURSByZXF1ZXN0cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0t LS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5DT01NRU5UIDU6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLS0tLS0tLS0tLS0t LS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlNlY3Rpb24gNCwgMXN0 IHBhcmFncmFwaCBhbmQgMm5kIHBhcmFncmFwaCBwcm92aWRlIG92ZXJsYXBwaW5nIGluZm9ybWF0 aW9uLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkluIDFzdCBwYXJhZ3JhcGgsIHRo ZXJlIGlzIGEgc3RhdGVtZW50IHRoYXQgaWYgcmVtb3RlIFVBIHByb3ZpZGVkIGEgR1JVVSBhcyBp dHMgbG9jYWwgdGFyZ2V0IHRoZW4gYSB1c2VyIGFnZW50IHNlbmRpbmcgYSBSRUZFUiByZXF1ZXN0 ICh0b3dhcmRzIHRoYXQgdGFyZ2V0KSB0aGF0IGNvdWxkIHJlc3VsdCBpbiBhbiZuYnNwOyBpbXBs aWNpdCBzdWJzY3JpcHRpb24gd2l0aGluIGEgZGlhbG9nIGlzIHByb2hpYml0ZWQuDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SW4gMm5kIHBhcmFncmFwaCwgdGhlIHNhbWUgaXMgc3Rh dGVkIChpbiBwb3NpdGl2ZSB3YXkpIHJlZ2FyZGxlc3Mgd2hldGhlciB0aGUgcmVtb3RlIFVBIHBy b3ZpZGVkIGEgR1JVVSBhcyBpdHMgbG9jYWwgdGFyZ2V0IG9yIG5vdC4NCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPlBST1BPU0VEIFNPTFVUSU9OIDU6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJlbW92ZSB0aGUgMXN0IHBhcmFncmFwaCBvZiBzZWN0 aW9uIDQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLS0tLS0t LS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q09NTUVOVCA2OjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS0tLS0tLS0tLS0tLS0tPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TZWN0aW9uIDMgc3RhdGVzOiAmcXVv dDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBB IHVzZXIgYWdlbnQgY29uc3RydWN0aW5nIGFueSBSRUZFUiB0aGF0IGNhbiByZXN1bHQgaW4gYW4g aW1wbGljaXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyBzdWJzY3JpcHRpb24gTVVTVCBwb3B1bGF0ZSBpdHMgQ29udGFjdCBoZWFkZXIgZmllbGQg d2l0aCBhIEdSVVUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mcXVv dDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SW4gUkZDNjY1LCB0aGVyZSBpcyBubyBz dWNoIHJlcXVpcmVtZW50IGZvciBzdWJzY3JpYmVyLiBXaHkgZG8gd2Ugc3RhdGUgc3VjaCBuZXcg cmVxdWlyZW1lbnQ/DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0t LS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5QUk9QT1NFRCBT T0xVVElPTiA2OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS0t LS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5DbGFy aWZ5IHRoZSBuZWVkIGZvciB0aGlzIHJlcXVpcmVtZW50IG9yIHJlbW92ZSBpdC48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5LaW5kIHJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+SXZvIFNlZGxhY2VrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_39B5E4D390E9BD4890E2B31079006101127852C3ESESSMB301erics_-- From nobody Tue Nov 4 06:58:43 2014 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 169571A895E for ; Tue, 4 Nov 2014 06:58:42 -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 pe4OHWT59Qrq for ; Tue, 4 Nov 2014 06:58:40 -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 DEA1C1A702A for ; Tue, 4 Nov 2014 06:58:39 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-1e-5458e99dcc1d Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F8.7E.04231.D99E8545; Tue, 4 Nov 2014 15:58:38 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.4]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0174.001; Tue, 4 Nov 2014 15:58:37 +0100 From: Ivo Sedlacek To: "sipcore@ietf.org" Thread-Topic: Comments to draft-sparks-sipcore-refer-explicit-subscription-02.txt Thread-Index: Ac/4OU/g07J/NMknQRKl76sp754aVw== Date: Tue, 4 Nov 2014 14:58:36 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061011278554E@ESESSMB301.ericsson.se> 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+NgFtrPLMWRmVeSWpSXmKPExsUyM+Jvje68lxEhBqfSLL7+2MTmwOixZMlP pgDGKC6blNSczLLUIn27BK6MKTtPMxWcF6o4uO4LWwNjH38XIyeHhICJxLXOXYwQtpjEhXvr 2boYuTiEBI4wSuy6f4EVwlnIKPFu72WwKjYBPYmJW46wgtgiApoSy79tZQexhQV8JN6fv8sG EQ+WWHTqDzOErSdx5eljJhCbRUBFYmrLU7A4r4CvxO8f+8DqGQVkJa7+6QWbzywgLnHryXwm iIsEJJbsOc8MYYtKvHz8jxXCVpT4+GofVL2OxILdn9ggbG2JZQtfQ80XlDg58wnLBEbhWUjG zkLSMgtJyywkLQsYWVYxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBIb4wS2/dXcwrn7teIhR gINRiYfXwDEiRIg1say4MvcQozQHi5I476Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MGZvaVfkON+ceX/nF8PwY5Eu+9imfdZfZu7JcHWP8b0JG7d5RhayWzHf8rhjkq6c/Xnb/qcm c55EBk5fY994NyN2j4F8qn0H746JLCdnic6e9oTZovqflNqu7jk3Fzm9lZMw+WJ3S031RsIx r+NLK/nETR9a63XeSlmbaswf78zO0tu+JkjplBJLcUaioRZzUXEiAOrmI/9SAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/lBuzEKIINqzgYFRb9QATpmpTAfM Subject: [sipcore] Comments to draft-sparks-sipcore-refer-explicit-subscription-02.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, 04 Nov 2014 14:58:42 -0000 Hello, I reviewed the draft-sparks-sipcore-refer-explicit-subscription-02. Generally, I consider it in a good shape. COMMENT 1: --------------------- Abstract states: " The Session Initiation Protocol (SIP) REFER request, as defined by RFC3515, triggers an implicit SIP-Specific Event Notification framework subscription. " It would be good to also point out that RFC4488 tried to remove this trigge= r for creating implicit notification but did not do the work entirely so us= age of RFC4488 may need to rely on application logic in UAS handling the RE= FER request. --------------------- COMMENT 2: --------------------- 2. Introduction states: " REFER as defined by [RFC3515] triggers an implicit SIP-Specific Event Framework subscription. Sending a REFER within a dialog established by an INVITE results in dialog reuse and the associated problems described in [RFC5057]." Again, it would be good to also state that usage of RFC4488 together with a= pplication logic enables prevention of creation of implicit subscription. H= owever, it would be good to have a protocol mechanism which do not need to = rely on the application logic. --------------------- COMMENT 3: --------------------- 6. Introduction states: " UA MUST NOT include the 'explicitsub' or 'nosub' option tag in the Require header field of any SIP response other than a 421 response to a REFER request." IMO, this is against RFC3261 stating ("Any extensions applied to a non-421 = response MUST be listed in a Require header field included in the response.= "). I have seen that this has already been raised at http://www.ietf.org/mail-a= rchive/web/sipcore/current/msg06338.html and I would be happy with resoluti= on proposed there. --------------------- COMMENT 4: --------------------- Some of the security issues apply only to explicitsub, but the text does no= t make it clear. --------------------- PROPOSED SOLUTION 4: --------------------- it might be good to split the section 8. Security Considerations to three = subsections,=20 - 1st subsection focused on generic issues applicable to both explicitsub = and nosub - 2nd subsection focused on issues applicable to explicitsub only - 3rd subsection focused on issues applicable to nosub only --------------------- Kind regards Ivo Sedlacek From nobody Wed Nov 5 10:06:42 2014 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 85A1B1A907D for ; Wed, 5 Nov 2014 10:06: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 8KbqE4vuH7mS for ; Wed, 5 Nov 2014 10:06:36 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3DA71A907C for ; Wed, 5 Nov 2014 10:06:36 -0800 (PST) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-07v.sys.comcast.net with comcast id Bu6P1p0034xDoy801u6cG5; Wed, 05 Nov 2014 18:06:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-05v.sys.comcast.net with comcast id Bu6b1p00R3Ge9ey01u6bWA; Wed, 05 Nov 2014 18:06:36 +0000 Message-ID: <545A672B.9050905@alum.mit.edu> Date: Wed, 05 Nov 2014 13:06:35 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1415210796; bh=DXMy5bBTdlVzmv4MxSiVMRv5V5lB6kMI5zQdJklVV6E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YlkffgpAQxmTcgNQ1aqB6rxXeg+Y6kEsxBXwvMkEQJ/pH4vUOdCHOdRfz4YxKJJvE EoURHL0d58iH/IETsRSoipWYOXrVGw+ikF4WQiEl8G882TBEL7FhD7DPgDSBZeDdsz 5uM5hjX/lVGcmDSZ/BpUgUs6j1xgQ/hqTamb1GI5DdHSgpch96sdQr2tlpi064+MPf ER+b5vdrhDYHr8JkO5SalGzhyDOt9FN0frA6r7FNTyQ3XVHiHOVQztlgDXOVjVaeqd 8wC98gGXLnmQbs342m20rgQHp2OOM9tBJ3YB5o6/Jha95VvJ72rD+dXubdWlKxf4lW w0awvcW+CJDBg== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/LlOCsiAaIVmfm8rsKbOtZdLgLo0 Subject: [sipcore] Note takers for the CLUE sessions next week 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, 05 Nov 2014 18:06:38 -0000 To avoid a delay in the meetings while we seek note takers, who will volunteer to take notes in Honolulu? - note taker, Thurs - jabber scribe, Thurs As a reward to note takers, I will give you a "get out of note-taking jail" card for non-SIPCORE sessions. (Of course these are non-binding on other chairs.) Thanks, Paul From nobody Thu Nov 6 11:24:33 2014 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 EA6701A1AFF for ; Thu, 6 Nov 2014 11:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] 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 756CheYSoRSm for ; Thu, 6 Nov 2014 11:24:28 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2B9201A1A80 for ; Thu, 6 Nov 2014 11:24:28 -0800 (PST) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sA6JONYU012805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Nov 2014 13:24:23 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <545BCAE2.2000008@nostrum.com> Date: Thu, 06 Nov 2014 13:24:18 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Christer Holmberg , "sipcore@ietf.org" References: <5457EED3.3080807@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D4E22F4@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4E22F4@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------060306040403050202070305" Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/e9t2hqnkzmX9WmS2rFgyQFVC54k Subject: Re: [sipcore] Open issue in refer-explicit-subscriptions 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, 06 Nov 2014 19:24:32 -0000 This is a multi-part message in MIME format. --------------060306040403050202070305 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I really think the document covers this. If the receiver accepts the request, and doesn't use the extension, it will violate one or more MUST requirements already in the document. Saying more risks providing a place to argue (and for implementers to disagree) about what "use" means. What do you see going wrong if we leave the text as is? RjS On 11/4/14 2:09 AM, Christer Holmberg wrote: > > Hi, > > In general I am ok with the approach seen in the diff. > > However, related to the semantics, I think we in section 6 should make > it more clear that, when present in the Require header field, the > semantics means “MUST SUPPORT **AND** MUST USE”. > > That could be done e.g. by extending the following sentence: > > “The use of either option tag in a Require header field is only > defined when it appears in a REFER request.” > > …to: > > “The use of either option tag in a Require header field > is only defined when it appears in a REFER request, and indicates that > the receiver, if it accepts the request, must support and use the > extension associated with the option-tag.” > > Regards, > > Christer > > *From:*sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf Of *Robert > Sparks > *Sent:* 3. marraskuuta 2014 23:09 > *To:* sipcore@ietf.org > *Subject:* [sipcore] Open issue in refer-explicit-subscriptions > > -02 calls out one open issue - better aligning with 3261 > Supported/Require definitions, and using 421 correctly. > > As most folks know, there has been many threads on the semantics of > Supported and Require. We're avoiding the problems most of those > threads call out by being very specific with when this extension can > be used, and what to put in the messages when it is used. We're almost > aligned with what's in 3261, but Ivo called my attention some time > back to a rough edge with responses. Section 8.1.1.9 of RFC3261 > requires responders to list any extensions applied to a result in a > Require header field. Now we could burn a _lot_ more time arguing > about whether doing so is worthwhile since we can only apply this > extension if it was Required in a request, but I don't think it's > worth the effort. > > Instead, I think the following replacement for section 6 of the draft > gets us to a place where we aren't in conflict with any 3261 text. You > can find a side-by-side diff of this suggestion against the current > section at > . > > If this works for folks, then I don't think we need time in Honolulu > to discuss it. > > > ------ > > 6. The 'explicitsub' and 'nosub' Option Tags > > This document defines the 'explicitsub' option tag, used to signal > the use of the extension defined in Section 4, and the 'nosub' option > tag, used to signal the use of the extension defined in Section 5. > > The use of either option tag in a Require header field is only > defined when it appears in a REFER request or a response to a > REFER request. A UA MUST NOT include the 'explicitsub' or 'nosub' > option tag in the Require header field of any request other than > REFER. A UA MUST NOT include the 'explicitsub' or 'nosub' option > tag in the Require header field of any SIP response other than a > 200 or 421 response to a REFER request. > > The 'explicitsub' and 'nosub' option tags MAY appear in the Supported > header field of SIP messages, and in sip.extensions feature tag > defined in [RFC3840]. This signals only that the UA including the > value is aware of the extensions. In particular, a UA can only > invoke the use of one of the extensions in a request. A UA MUST NOT > include either option tag in the Require header field of a 200 > response > to a REFER request if that tag was not present in the Require > header field > of the request. A User-Agent Server (UAS) that is processing a REFER > request that lists 'explicitsub' or 'nosub' in its Supported header > field > and wishes to use one of those extensions will return a 421 response > indicating which extension is required. > --------------060306040403050202070305 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I really think the document covers this.

If the receiver accepts the request, and doesn't use the extension, it will violate one or more MUST requirements already in the document.
Saying more risks providing a place to argue (and for implementers to disagree) about what "use" means.

What do you see going wrong if we leave the text as is?

RjS


On 11/4/14 2:09 AM, Christer Holmberg wrote:

Hi,

 

In general I am ok with the approach seen in the diff.

 

However, related to the semantics, I think we in section 6 should make it more clear that, when present in the Require header field, the semantics means “MUST SUPPORT *AND* MUST USE”.

 

That could be done e.g. by extending the following sentence:

 

                  “The use of either option tag in a Require header field is only defined when it appears in a REFER request.”

 

…to:

 

                “The use of either option tag in a Require header field is only defined when it appears in a REFER request, and indicates that the receiver, if it accepts the request, must support and use the extension associated with the option-tag.”

 

Regards,

 

Christer

 

 

 

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert Sparks
Sent: 3. marraskuuta 2014 23:09
To: sipcore@ietf.org
Subject: [sipcore] Open issue in refer-explicit-subscriptions

 

-02 calls out one open issue - better aligning with 3261 Supported/Require definitions, and using 421 correctly.

As most folks know, there has been many threads on the semantics of Supported and Require. We're avoiding the problems most of those threads call out by being very specific with when this extension can be used, and what to put in the messages when it is used. We're almost aligned with what's in 3261, but Ivo called my attention some time back to a rough edge with responses. Section 8.1.1.9 of RFC3261 requires responders to list any extensions applied to a result in a Require header field. Now we could burn a _lot_ more time arguing about whether doing so is worthwhile since we can only apply this extension if it was Required in a request, but I don't think it's worth the effort.

Instead, I think the following replacement for section 6 of the draft gets us to a place where we aren't in conflict with any 3261 text. You can find a side-by-side diff of this suggestion against the current section at <http://www.nostrum.com/~rjsparks/diff_before_after.html>.

If this works for folks, then I don't think we need time in Honolulu to discuss it.


------

6. The 'explicitsub' and 'nosub' Option Tags

   This document defines the 'explicitsub' option tag, used to signal
   the use of the extension defined in Section 4, and the 'nosub' option
   tag, used to signal the use of the extension defined in Section 5.

   The use of either option tag in a Require header field is only
   defined when it appears in a REFER request or a response to a
   REFER request.  A UA MUST NOT include the 'explicitsub' or 'nosub'
   option tag in the Require header field of any request other than
   REFER.  A UA MUST NOT include the 'explicitsub' or 'nosub' option
   tag in the Require header field of any SIP response other than a
   200 or 421 response to a REFER request.

   The 'explicitsub' and 'nosub' option tags MAY appear in the Supported
   header field of SIP messages, and in sip.extensions feature tag
   defined in [RFC3840].  This signals only that the UA including the
   value is aware of the extensions.  In particular, a UA can only
   invoke the use of one of the extensions in a request.  A UA MUST NOT
   include either option tag in the Require header field of a 200 response
   to a REFER request if that tag was not present in the Require header field
   of the request. A User-Agent Server (UAS) that is processing a REFER
   request that lists 'explicitsub' or 'nosub' in its Supported header field
   and wishes to use one of those extensions will return a 421 response
   indicating which extension is required.


--------------060306040403050202070305-- From nobody Thu Nov 6 11:43:00 2014 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 9E65D1A1A27 for ; Thu, 6 Nov 2014 11:42: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, 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 C56gnLfNQiD3 for ; Thu, 6 Nov 2014 11:42:56 -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 107411A1A24 for ; Thu, 6 Nov 2014 11:42:54 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-9c-545bcf3d2aa5 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 57.71.24955.D3FCB545; Thu, 6 Nov 2014 20:42:53 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0174.001; Thu, 6 Nov 2014 20:42:52 +0100 From: Christer Holmberg To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] Open issue in refer-explicit-subscriptions Thread-Index: AQHP96phoB9VmUajWU++EKVL3yn2SJxQGTWggAPVNwCAABSdsA== Date: Thu, 6 Nov 2014 19:42:52 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4E9F3B@ESESSMB209.ericsson.se> References: <5457EED3.3080807@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D4E22F4@ESESSMB209.ericsson.se> <545BCAE2.2000008@nostrum.com> In-Reply-To: <545BCAE2.2000008@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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4E9F3BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvja7t+egQgz09ghbX5jSyWXz9sYnN gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4Mpo+7eWrWDKWsaKR2vmsjQwnljB2MXIySEh YCIx5/4mVghbTOLCvfVsXYxcHEICRxglbn7dxgLhLGaUmHJpBVCGg4NNwEKi+582SIOIQKDE wklLWEBsYQFHiVVbbzBBxJ0kDq96zgZj/zo5gRWklUVARWLu9hyQMK+Ar8TiNU/YIcb3M0pc XLkIbDyngLbEzyn6IDWMQPd8P7UGbCSzgLjErSfzmSDuFJBYsuc8M4QtKvHy8T+o+5UkGpc8 YYWoz5d42feLBWKXoMTJmU9YJjCKzEIyahaSsllIymYBXcEsoCmxfpc+RImixJTuh+wQtoZE 65y57MjiCxjZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIExtXBLb9VdzBefuN4iFGAg1GJ h9fgSVSIEGtiWXFl7iFGaQ4WJXHehefmBQsJpCeWpGanphakFsUXleakFh9iZOLglGpgdLpR X+VkwXakN0DB+liAG+uW2jN3l+32vijqt0xZf9GS/Lc3SzTabiU4zYgIXJ9WkKPwbdkGzeQL liaB/7/4L+L0FF/nZBXl8K+AdSLb4r/fHs5pnptd5tT2TPrl+uNL/9V7LzcujZLUN5vJ+6j4 oviDABVtM5dUvbeLTjkKpryRi3bh1nJSYinOSDTUYi4qTgQAVej+MYwCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/fsSwb5JF_hKmEZ_q4sLIBfidNMs Subject: Re: [sipcore] Open issue in refer-explicit-subscriptions 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, 06 Nov 2014 19:42:58 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4E9F3BESESSMB209erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5JIHJlYWxseSB0aGluayB0aGUgZG9jdW1lbnQgY292ZXJzIHRoaXMuDQo+DQo+SWYg dGhlIHJlY2VpdmVyIGFjY2VwdHMgdGhlIHJlcXVlc3QsIGFuZCBkb2Vzbid0IHVzZSB0aGUgZXh0 ZW5zaW9uLCBpdCB3aWxsIHZpb2xhdGUgb25lIG9yID5tb3JlIE1VU1QgcmVxdWlyZW1lbnRzIGFs cmVhZHkgaW4gdGhlIGRvY3VtZW50Lg0KPlNheWluZyBtb3JlIHJpc2tzIHByb3ZpZGluZyBhIHBs YWNlIHRvIGFyZ3VlIChhbmQgZm9yIGltcGxlbWVudGVycyB0byBkaXNhZ3JlZSkgPmFib3V0IHdo YXQgInVzZSIgbWVhbnMuDQo+DQo+V2hhdCBkbyB5b3Ugc2VlIGdvaW5nIHdyb25nIGlmIHdlIGxl YXZlIHRoZSB0ZXh0IGFzIGlzPw0KSSBqdXN0IHdhbnQgdG8gYXZvaWQgZnV0dXJlIGRpc2N1c3Np b25zIChzaW1pbGFyIHRvIG9uZXMgd2UgaGF2ZSBoYWQgaW4gdGhlIHBhc3QpIGFib3V0IHdoZXRo ZXIgUmVxdWlyZSBmb3IgdGhlc2UgdGFncyBvbmx5IG1lYW5zIG11c3Qgc3VwcG9ydCwgb3IgbXVz dCBzdXBwb3J0IG9yIHVzZS4NClJlZ2FyZHMsDQpDaHJpc3Rlcg0KDQpPbiAxMS80LzE0IDI6MDkg QU0sIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KSGksDQoNCkluIGdlbmVyYWwgSSBhbSBvayB3 aXRoIHRoZSBhcHByb2FjaCBzZWVuIGluIHRoZSBkaWZmLg0KDQpIb3dldmVyLCByZWxhdGVkIHRv IHRoZSBzZW1hbnRpY3MsIEkgdGhpbmsgd2UgaW4gc2VjdGlvbiA2IHNob3VsZCBtYWtlIGl0IG1v cmUgY2xlYXIgdGhhdCwgd2hlbiBwcmVzZW50IGluIHRoZSBSZXF1aXJlIGhlYWRlciBmaWVsZCwg dGhlIHNlbWFudGljcyBtZWFucyDigJxNVVNUIFNVUFBPUlQgKkFORCogTVVTVCBVU0XigJ0uDQoN ClRoYXQgY291bGQgYmUgZG9uZSBlLmcuIGJ5IGV4dGVuZGluZyB0aGUgZm9sbG93aW5nIHNlbnRl bmNlOg0KDQogICAgICAgICAgICAgICAgICDigJxUaGUgdXNlIG9mIGVpdGhlciBvcHRpb24gdGFn IGluIGEgUmVxdWlyZSBoZWFkZXIgZmllbGQgaXMgb25seSBkZWZpbmVkIHdoZW4gaXQgYXBwZWFy cyBpbiBhIFJFRkVSIHJlcXVlc3Qu4oCdDQoNCuKApnRvOg0KDQogICAgICAgICAgICAgICAg4oCc VGhlIHVzZSBvZiBlaXRoZXIgb3B0aW9uIHRhZyBpbiBhIFJlcXVpcmUgaGVhZGVyIGZpZWxkIGlz IG9ubHkgZGVmaW5lZCB3aGVuIGl0IGFwcGVhcnMgaW4gYSBSRUZFUiByZXF1ZXN0LCBhbmQgaW5k aWNhdGVzIHRoYXQgdGhlIHJlY2VpdmVyLCBpZiBpdCBhY2NlcHRzIHRoZSByZXF1ZXN0LCBtdXN0 IHN1cHBvcnQgYW5kIHVzZSB0aGUgZXh0ZW5zaW9uIGFzc29jaWF0ZWQgd2l0aCB0aGUgb3B0aW9u LXRhZy7igJ0NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCkZyb206IHNpcGNvcmUgW21h aWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb2JlcnQgU3Bhcmtz DQpTZW50OiAzLiBtYXJyYXNrdXV0YSAyMDE0IDIzOjA5DQpUbzogc2lwY29yZUBpZXRmLm9yZzxt YWlsdG86c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtzaXBjb3JlXSBPcGVuIGlzc3VlIGlu IHJlZmVyLWV4cGxpY2l0LXN1YnNjcmlwdGlvbnMNCg0KLTAyIGNhbGxzIG91dCBvbmUgb3BlbiBp c3N1ZSAtIGJldHRlciBhbGlnbmluZyB3aXRoIDMyNjEgU3VwcG9ydGVkL1JlcXVpcmUgZGVmaW5p dGlvbnMsIGFuZCB1c2luZyA0MjEgY29ycmVjdGx5Lg0KDQpBcyBtb3N0IGZvbGtzIGtub3csIHRo ZXJlIGhhcyBiZWVuIG1hbnkgdGhyZWFkcyBvbiB0aGUgc2VtYW50aWNzIG9mIFN1cHBvcnRlZCBh bmQgUmVxdWlyZS4gV2UncmUgYXZvaWRpbmcgdGhlIHByb2JsZW1zIG1vc3Qgb2YgdGhvc2UgdGhy ZWFkcyBjYWxsIG91dCBieSBiZWluZyB2ZXJ5IHNwZWNpZmljIHdpdGggd2hlbiB0aGlzIGV4dGVu c2lvbiBjYW4gYmUgdXNlZCwgYW5kIHdoYXQgdG8gcHV0IGluIHRoZSBtZXNzYWdlcyB3aGVuIGl0 IGlzIHVzZWQuIFdlJ3JlIGFsbW9zdCBhbGlnbmVkIHdpdGggd2hhdCdzIGluIDMyNjEsIGJ1dCBJ dm8gY2FsbGVkIG15IGF0dGVudGlvbiBzb21lIHRpbWUgYmFjayB0byBhIHJvdWdoIGVkZ2Ugd2l0 aCByZXNwb25zZXMuIFNlY3Rpb24gOC4xLjEuOSBvZiBSRkMzMjYxIHJlcXVpcmVzIHJlc3BvbmRl cnMgdG8gbGlzdCBhbnkgZXh0ZW5zaW9ucyBhcHBsaWVkIHRvIGEgcmVzdWx0IGluIGEgUmVxdWly ZSBoZWFkZXIgZmllbGQuIE5vdyB3ZSBjb3VsZCBidXJuIGEgX2xvdF8gbW9yZSB0aW1lIGFyZ3Vp bmcgYWJvdXQgd2hldGhlciBkb2luZyBzbyBpcyB3b3J0aHdoaWxlIHNpbmNlIHdlIGNhbiBvbmx5 IGFwcGx5IHRoaXMgZXh0ZW5zaW9uIGlmIGl0IHdhcyBSZXF1aXJlZCBpbiBhIHJlcXVlc3QsIGJ1 dCBJIGRvbid0IHRoaW5rIGl0J3Mgd29ydGggdGhlIGVmZm9ydC4NCg0KSW5zdGVhZCwgSSB0aGlu ayB0aGUgZm9sbG93aW5nIHJlcGxhY2VtZW50IGZvciBzZWN0aW9uIDYgb2YgdGhlIGRyYWZ0IGdl dHMgdXMgdG8gYSBwbGFjZSB3aGVyZSB3ZSBhcmVuJ3QgaW4gY29uZmxpY3Qgd2l0aCBhbnkgMzI2 MSB0ZXh0LiBZb3UgY2FuIGZpbmQgYSBzaWRlLWJ5LXNpZGUgZGlmZiBvZiB0aGlzIHN1Z2dlc3Rp b24gYWdhaW5zdCB0aGUgY3VycmVudCBzZWN0aW9uIGF0IDxodHRwOi8vd3d3Lm5vc3RydW0uY29t L35yanNwYXJrcy9kaWZmX2JlZm9yZV9hZnRlci5odG1sPjxodHRwOi8vd3d3Lm5vc3RydW0uY29t LyU3RXJqc3BhcmtzL2RpZmZfYmVmb3JlX2FmdGVyLmh0bWw+Lg0KDQpJZiB0aGlzIHdvcmtzIGZv ciBmb2xrcywgdGhlbiBJIGRvbid0IHRoaW5rIHdlIG5lZWQgdGltZSBpbiBIb25vbHVsdSB0byBk aXNjdXNzIGl0Lg0KDQoNCi0tLS0tLQ0KDQo2LiBUaGUgJ2V4cGxpY2l0c3ViJyBhbmQgJ25vc3Vi JyBPcHRpb24gVGFncw0KDQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlICdleHBsaWNpdHN1 Yicgb3B0aW9uIHRhZywgdXNlZCB0byBzaWduYWwNCiAgIHRoZSB1c2Ugb2YgdGhlIGV4dGVuc2lv biBkZWZpbmVkIGluIFNlY3Rpb24gNCwgYW5kIHRoZSAnbm9zdWInIG9wdGlvbg0KICAgdGFnLCB1 c2VkIHRvIHNpZ25hbCB0aGUgdXNlIG9mIHRoZSBleHRlbnNpb24gZGVmaW5lZCBpbiBTZWN0aW9u IDUuDQoNCiAgIFRoZSB1c2Ugb2YgZWl0aGVyIG9wdGlvbiB0YWcgaW4gYSBSZXF1aXJlIGhlYWRl ciBmaWVsZCBpcyBvbmx5DQogICBkZWZpbmVkIHdoZW4gaXQgYXBwZWFycyBpbiBhIFJFRkVSIHJl cXVlc3Qgb3IgYSByZXNwb25zZSB0byBhDQogICBSRUZFUiByZXF1ZXN0LiAgQSBVQSBNVVNUIE5P VCBpbmNsdWRlIHRoZSAnZXhwbGljaXRzdWInIG9yICdub3N1YicNCiAgIG9wdGlvbiB0YWcgaW4g dGhlIFJlcXVpcmUgaGVhZGVyIGZpZWxkIG9mIGFueSByZXF1ZXN0IG90aGVyIHRoYW4NCiAgIFJF RkVSLiAgQSBVQSBNVVNUIE5PVCBpbmNsdWRlIHRoZSAnZXhwbGljaXRzdWInIG9yICdub3N1Yicg b3B0aW9uDQogICB0YWcgaW4gdGhlIFJlcXVpcmUgaGVhZGVyIGZpZWxkIG9mIGFueSBTSVAgcmVz cG9uc2Ugb3RoZXIgdGhhbiBhDQogICAyMDAgb3IgNDIxIHJlc3BvbnNlIHRvIGEgUkVGRVIgcmVx dWVzdC4NCg0KICAgVGhlICdleHBsaWNpdHN1YicgYW5kICdub3N1Yicgb3B0aW9uIHRhZ3MgTUFZ IGFwcGVhciBpbiB0aGUgU3VwcG9ydGVkDQogICBoZWFkZXIgZmllbGQgb2YgU0lQIG1lc3NhZ2Vz LCBhbmQgaW4gc2lwLmV4dGVuc2lvbnMgZmVhdHVyZSB0YWcNCiAgIGRlZmluZWQgaW4gW1JGQzM4 NDBdLiAgVGhpcyBzaWduYWxzIG9ubHkgdGhhdCB0aGUgVUEgaW5jbHVkaW5nIHRoZQ0KICAgdmFs dWUgaXMgYXdhcmUgb2YgdGhlIGV4dGVuc2lvbnMuICBJbiBwYXJ0aWN1bGFyLCBhIFVBIGNhbiBv bmx5DQogICBpbnZva2UgdGhlIHVzZSBvZiBvbmUgb2YgdGhlIGV4dGVuc2lvbnMgaW4gYSByZXF1 ZXN0LiAgQSBVQSBNVVNUIE5PVA0KICAgaW5jbHVkZSBlaXRoZXIgb3B0aW9uIHRhZyBpbiB0aGUg UmVxdWlyZSBoZWFkZXIgZmllbGQgb2YgYSAyMDAgcmVzcG9uc2UNCiAgIHRvIGEgUkVGRVIgcmVx dWVzdCBpZiB0aGF0IHRhZyB3YXMgbm90IHByZXNlbnQgaW4gdGhlIFJlcXVpcmUgaGVhZGVyIGZp ZWxkDQogICBvZiB0aGUgcmVxdWVzdC4gQSBVc2VyLUFnZW50IFNlcnZlciAoVUFTKSB0aGF0IGlz IHByb2Nlc3NpbmcgYSBSRUZFUg0KICAgcmVxdWVzdCB0aGF0IGxpc3RzICdleHBsaWNpdHN1Yicg b3IgJ25vc3ViJyBpbiBpdHMgU3VwcG9ydGVkIGhlYWRlciBmaWVsZA0KICAgYW5kIHdpc2hlcyB0 byB1c2Ugb25lIG9mIHRob3NlIGV4dGVuc2lvbnMgd2lsbCByZXR1cm4gYSA0MjEgcmVzcG9uc2UN CiAgIGluZGljYXRpbmcgd2hpY2ggZXh0ZW5zaW9uIGlzIHJlcXVpcmVkLg0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B1D4E9F3BESESSMB209erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1HQiIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jmd0Ozwvc3Bhbj5JIHJlYWxseSB0aGluayB0aGUgZG9jdW1lbnQgY292ZXJzIHRoaXMuPGJyPg0K PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+SWYgdGhlIHJlY2VpdmVyIGFjY2VwdHMgdGhlIHJl cXVlc3QsIGFuZCBkb2Vzbid0IHVzZSB0aGUgZXh0ZW5zaW9uLCBpdCB3aWxsIHZpb2xhdGUgb25l IG9yDQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5tb3JlIE1VU1QgcmVx dWlyZW1lbnRzIGFscmVhZHkgaW4gdGhlIGRvY3VtZW50Ljxicj4NCjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4mZ3Q7PC9zcGFuPlNheWluZyBtb3JlIHJpc2tzIHByb3ZpZGluZyBhIHBsYWNl IHRvIGFyZ3VlIChhbmQgZm9yIGltcGxlbWVudGVycyB0byBkaXNhZ3JlZSkNCjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPmFib3V0IHdoYXQgJnF1b3Q7dXNlJnF1b3Q7IG1l YW5zLjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPjxicj4NCjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPldoYXQgZG8geW91IHNlZSBnb2lu ZyB3cm9uZyBpZiB3ZSBsZWF2ZSB0aGUgdGV4dCBhcyBpcz88c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBq dXN0IHdhbnQgdG8gYXZvaWQgZnV0dXJlIGRpc2N1c3Npb25zIChzaW1pbGFyIHRvIG9uZXMgd2Ug aGF2ZSBoYWQgaW4gdGhlIHBhc3QpIGFib3V0IHdoZXRoZXIgUmVxdWlyZSBmb3IgdGhlc2UgdGFn cyBvbmx5IG1lYW5zDQogbXVzdCBzdXBwb3J0LCBvciBtdXN0IHN1cHBvcnQgb3IgdXNlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hyaXN0ZXI8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIDExLzQvMTQgMjowOSBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SW4gZ2VuZXJhbCBJIGFtIG9rIHdpdGggdGhlIGFwcHJvYWNoIHNlZW4gaW4gdGhl IGRpZmYuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ib3dldmVy LCByZWxhdGVkIHRvIHRoZSBzZW1hbnRpY3MsIEkgdGhpbmsgd2UgaW4gc2VjdGlvbiA2IHNob3Vs ZCBtYWtlIGl0IG1vcmUgY2xlYXIgdGhhdCwgd2hlbiBwcmVzZW50IGluIHRoZSBSZXF1aXJlIGhl YWRlciBmaWVsZCwgdGhlIHNlbWFudGljcyBtZWFucyDigJxNVVNUDQogU1VQUE9SVCAqPGI+QU5E PC9iPiogTVVTVCBVU0XigJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5UaGF0IGNvdWxkIGJlIGRvbmUgZS5nLiBieSBleHRlbmRpbmcgdGhlIGZvbGxvd2luZyBz ZW50ZW5jZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsg4oCcVGhlIHVzZSBvZiBlaXRoZXIg b3B0aW9uIHRhZyBpbiBhIFJlcXVpcmUgaGVhZGVyIGZpZWxkIGlzIG9ubHkgZGVmaW5lZCB3aGVu IGl0IGFwcGVhcnMgaW4gYSBSRUZFUiByZXF1ZXN0LuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+4oCmdG86PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnFRoZSB1c2Ugb2Yg ZWl0aGVyIG9wdGlvbiB0YWcgaW4gYSBSZXF1aXJlIGhlYWRlciBmaWVsZCBpcyBvbmx5IGRlZmlu ZWQgd2hlbiBpdCBhcHBlYXJzIGluIGEgUkVGRVIgcmVxdWVzdCwgYW5kIGluZGljYXRlcyB0aGF0 IHRoZSByZWNlaXZlciwgaWYNCiBpdCBhY2NlcHRzIHRoZSByZXF1ZXN0LCBtdXN0IHN1cHBvcnQg YW5kIHVzZSB0aGUgZXh0ZW5zaW9uIGFzc29jaWF0ZWQgd2l0aCB0aGUgb3B0aW9uLXRhZy7igJ08 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaHJpc3Rlcjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5k b3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+ IHNpcGNvcmUgWzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3Jn Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssc2Fucy1zZXJpZiI+bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+XQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5Sb2JlcnQgU3BhcmtzPGJyPg0KPGI+U2VudDo8L2I+IDMuIG1hcnJhc2t1dXRhIDIwMTQgMjM6 MDk8YnI+DQo8Yj5Ubzo8L2I+IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9y ZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWYiPnNpcGNvcmVAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOndpbmRvd3RleHQiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbc2lwY29yZV0gT3Bl biBpc3N1ZSBpbiByZWZlci1leHBsaWNpdC1zdWJzY3JpcHRpb25zPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LTAyIGNhbGxzIG91dCBvbmUgb3BlbiBpc3N1 ZSAtIGJldHRlciBhbGlnbmluZyB3aXRoIDMyNjEgU3VwcG9ydGVkL1JlcXVpcmUgZGVmaW5pdGlv bnMsIGFuZCB1c2luZyA0MjEgY29ycmVjdGx5Ljxicj4NCjxicj4NCkFzIG1vc3QgZm9sa3Mga25v dywgdGhlcmUgaGFzIGJlZW4gbWFueSB0aHJlYWRzIG9uIHRoZSBzZW1hbnRpY3Mgb2YgU3VwcG9y dGVkIGFuZCBSZXF1aXJlLiBXZSdyZSBhdm9pZGluZyB0aGUgcHJvYmxlbXMgbW9zdCBvZiB0aG9z ZSB0aHJlYWRzIGNhbGwgb3V0IGJ5IGJlaW5nIHZlcnkgc3BlY2lmaWMgd2l0aCB3aGVuIHRoaXMg ZXh0ZW5zaW9uIGNhbiBiZSB1c2VkLCBhbmQgd2hhdCB0byBwdXQgaW4gdGhlIG1lc3NhZ2VzIHdo ZW4gaXQgaXMgdXNlZC4NCiBXZSdyZSBhbG1vc3QgYWxpZ25lZCB3aXRoIHdoYXQncyBpbiAzMjYx LCBidXQgSXZvIGNhbGxlZCBteSBhdHRlbnRpb24gc29tZSB0aW1lIGJhY2sgdG8gYSByb3VnaCBl ZGdlIHdpdGggcmVzcG9uc2VzLiBTZWN0aW9uIDguMS4xLjkgb2YgUkZDMzI2MSByZXF1aXJlcyBy ZXNwb25kZXJzIHRvIGxpc3QgYW55IGV4dGVuc2lvbnMgYXBwbGllZCB0byBhIHJlc3VsdCBpbiBh IFJlcXVpcmUgaGVhZGVyIGZpZWxkLiBOb3cgd2UgY291bGQgYnVybiBhIF9sb3RfDQogbW9yZSB0 aW1lIGFyZ3VpbmcgYWJvdXQgd2hldGhlciBkb2luZyBzbyBpcyB3b3J0aHdoaWxlIHNpbmNlIHdl IGNhbiBvbmx5IGFwcGx5IHRoaXMgZXh0ZW5zaW9uIGlmIGl0IHdhcyBSZXF1aXJlZCBpbiBhIHJl cXVlc3QsIGJ1dCBJIGRvbid0IHRoaW5rIGl0J3Mgd29ydGggdGhlIGVmZm9ydC4NCjxicj4NCjxi cj4NCkluc3RlYWQsIEkgdGhpbmsgdGhlIGZvbGxvd2luZyByZXBsYWNlbWVudCBmb3Igc2VjdGlv biA2IG9mIHRoZSBkcmFmdCBnZXRzIHVzIHRvIGEgcGxhY2Ugd2hlcmUgd2UgYXJlbid0IGluIGNv bmZsaWN0IHdpdGggYW55IDMyNjEgdGV4dC4gWW91IGNhbiBmaW5kIGEgc2lkZS1ieS1zaWRlIGRp ZmYgb2YgdGhpcyBzdWdnZXN0aW9uIGFnYWluc3QgdGhlIGN1cnJlbnQgc2VjdGlvbiBhdA0KPGEg aHJlZj0iaHR0cDovL3d3dy5ub3N0cnVtLmNvbS8lN0VyanNwYXJrcy9kaWZmX2JlZm9yZV9hZnRl ci5odG1sIj4mbHQ7aHR0cDovL3d3dy5ub3N0cnVtLmNvbS9+cmpzcGFya3MvZGlmZl9iZWZvcmVf YWZ0ZXIuaHRtbCZndDs8L2E+Ljxicj4NCjxicj4NCklmIHRoaXMgd29ya3MgZm9yIGZvbGtzLCB0 aGVuIEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0aW1lIGluIEhvbm9sdWx1IHRvIGRpc2N1c3MgaXQu PGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0tPGJyPg0KPGJyPg0KNi4gVGhlICdleHBsaWNpdHN1Yicg YW5kICdub3N1YicgT3B0aW9uIFRhZ3M8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgVGhpcyBkb2N1 bWVudCBkZWZpbmVzIHRoZSAnZXhwbGljaXRzdWInIG9wdGlvbiB0YWcsIHVzZWQgdG8gc2lnbmFs PGJyPg0KJm5ic3A7Jm5ic3A7IHRoZSB1c2Ugb2YgdGhlIGV4dGVuc2lvbiBkZWZpbmVkIGluIFNl Y3Rpb24gNCwgYW5kIHRoZSAnbm9zdWInIG9wdGlvbjxicj4NCiZuYnNwOyZuYnNwOyB0YWcsIHVz ZWQgdG8gc2lnbmFsIHRoZSB1c2Ugb2YgdGhlIGV4dGVuc2lvbiBkZWZpbmVkIGluIFNlY3Rpb24g NS48YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgVGhlIHVzZSBvZiBlaXRoZXIgb3B0aW9uIHRhZyBp biBhIFJlcXVpcmUgaGVhZGVyIGZpZWxkIGlzIG9ubHk8YnI+DQombmJzcDsmbmJzcDsgZGVmaW5l ZCB3aGVuIGl0IGFwcGVhcnMgaW4gYSBSRUZFUiByZXF1ZXN0IG9yIGEgcmVzcG9uc2UgdG8gYTxi cj4NCiZuYnNwOyZuYnNwOyBSRUZFUiByZXF1ZXN0LiZuYnNwOyBBIFVBIE1VU1QgTk9UIGluY2x1 ZGUgdGhlICdleHBsaWNpdHN1Yicgb3IgJ25vc3ViJyA8YnI+DQombmJzcDsmbmJzcDsgb3B0aW9u IHRhZyBpbiB0aGUgUmVxdWlyZSBoZWFkZXIgZmllbGQgb2YgYW55IHJlcXVlc3Qgb3RoZXIgdGhh biA8YnI+DQombmJzcDsmbmJzcDsgUkVGRVIuJm5ic3A7IEEgVUEgTVVTVCBOT1QgaW5jbHVkZSB0 aGUgJ2V4cGxpY2l0c3ViJyBvciAnbm9zdWInIG9wdGlvbiA8YnI+DQombmJzcDsmbmJzcDsgdGFn IGluIHRoZSBSZXF1aXJlIGhlYWRlciBmaWVsZCBvZiBhbnkgU0lQIHJlc3BvbnNlIG90aGVyIHRo YW4gYSA8YnI+DQombmJzcDsmbmJzcDsgMjAwIG9yIDQyMSByZXNwb25zZSB0byBhIFJFRkVSIHJl cXVlc3QuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IFRoZSAnZXhwbGljaXRzdWInIGFuZCAnbm9z dWInIG9wdGlvbiB0YWdzIE1BWSBhcHBlYXIgaW4gdGhlIFN1cHBvcnRlZDxicj4NCiZuYnNwOyZu YnNwOyBoZWFkZXIgZmllbGQgb2YgU0lQIG1lc3NhZ2VzLCBhbmQgaW4gc2lwLmV4dGVuc2lvbnMg ZmVhdHVyZSB0YWc8YnI+DQombmJzcDsmbmJzcDsgZGVmaW5lZCBpbiBbUkZDMzg0MF0uJm5ic3A7 IFRoaXMgc2lnbmFscyBvbmx5IHRoYXQgdGhlIFVBIGluY2x1ZGluZyB0aGU8YnI+DQombmJzcDsm bmJzcDsgdmFsdWUgaXMgYXdhcmUgb2YgdGhlIGV4dGVuc2lvbnMuJm5ic3A7IEluIHBhcnRpY3Vs YXIsIGEgVUEgY2FuIG9ubHk8YnI+DQombmJzcDsmbmJzcDsgaW52b2tlIHRoZSB1c2Ugb2Ygb25l IG9mIHRoZSBleHRlbnNpb25zIGluIGEgcmVxdWVzdC4mbmJzcDsgQSBVQSBNVVNUIE5PVDxicj4N CiZuYnNwOyZuYnNwOyBpbmNsdWRlIGVpdGhlciBvcHRpb24gdGFnIGluIHRoZSBSZXF1aXJlIGhl YWRlciBmaWVsZCBvZiBhIDIwMCByZXNwb25zZSA8YnI+DQombmJzcDsmbmJzcDsgdG8gYSBSRUZF UiByZXF1ZXN0IGlmIHRoYXQgdGFnIHdhcyBub3QgcHJlc2VudCBpbiB0aGUgUmVxdWlyZSBoZWFk ZXIgZmllbGQ8YnI+DQombmJzcDsmbmJzcDsgb2YgdGhlIHJlcXVlc3QuIEEgVXNlci1BZ2VudCBT ZXJ2ZXIgKFVBUykgdGhhdCBpcyBwcm9jZXNzaW5nIGEgUkVGRVIgPGJyPg0KJm5ic3A7Jm5ic3A7 IHJlcXVlc3QgdGhhdCBsaXN0cyAnZXhwbGljaXRzdWInIG9yICdub3N1YicgaW4gaXRzIFN1cHBv cnRlZCBoZWFkZXIgZmllbGQgPGJyPg0KJm5ic3A7Jm5ic3A7IGFuZCB3aXNoZXMgdG8gdXNlIG9u ZSBvZiB0aG9zZSBleHRlbnNpb25zIHdpbGwgcmV0dXJuIGEgNDIxIHJlc3BvbnNlIDxicj4NCiZu YnNwOyZuYnNwOyBpbmRpY2F0aW5nIHdoaWNoIGV4dGVuc2lvbiBpcyByZXF1aXJlZC48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B1D4E9F3BESESSMB209erics_-- From nobody Thu Nov 6 11:58:35 2014 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 F3FBA1A1BCF for ; Thu, 6 Nov 2014 11:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] 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 pwupqg1mqzax for ; Thu, 6 Nov 2014 11:58:29 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 053AF1A1BB0 for ; Thu, 6 Nov 2014 11:58:29 -0800 (PST) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sA6JwO56015786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Nov 2014 13:58:24 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <545BD2DB.1030907@nostrum.com> Date: Thu, 06 Nov 2014 13:58:19 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Christer Holmberg , "sipcore@ietf.org" References: <5457EED3.3080807@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D4E22F4@ESESSMB209.ericsson.se> <545BCAE2.2000008@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D4E9F3B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4E9F3B@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------010205010502070807080500" Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/bPQwVKfVsgPE8qPjKOBhcPOmHtM Subject: Re: [sipcore] Open issue in refer-explicit-subscriptions 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, 06 Nov 2014 19:58:33 -0000 This is a multi-part message in MIME format. --------------010205010502070807080500 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/6/14 1:42 PM, Christer Holmberg wrote: > > Hi, > > >I really think the document covers this. > > > >If the receiver accepts the request, and doesn't use the extension, it > will violate one or >more MUST requirements already in the document. > >Saying more risks providing a place to argue (and for implementers to > disagree) >about what "use" means. > > > >What do you see going wrong if we leave the text as is? > > I just want to avoid future discussions (similar to ones we have had > in the past) about whether Require for these tags only means must > support, or must support or use. > I hear that. Lets see if we can come up with something in the hallway to bring back to the list that raises that highlight without adding the risk I point to above. > > Regards, > > Christer > > On 11/4/14 2:09 AM, Christer Holmberg wrote: > > Hi, > > In general I am ok with the approach seen in the diff. > > However, related to the semantics, I think we in section 6 should > make it more clear that, when present in the Require header field, > the semantics means “MUST SUPPORT **AND** MUST USE”. > > That could be done e.g. by extending the following sentence: > > “The use of either option tag in a Require header field is only > defined when it appears in a REFER request.” > > …to: > > “The use of either option tag in a Require header > field is only defined when it appears in a REFER request, and > indicates that the receiver, if it accepts the request, must > support and use the extension associated with the option-tag.” > > Regards, > > Christer > > *From:*sipcore [mailto:sipcore-bounces@ietf.org] *On Behalf Of > *Robert Sparks > *Sent:* 3. marraskuuta 2014 23:09 > *To:* sipcore@ietf.org > *Subject:* [sipcore] Open issue in refer-explicit-subscriptions > > -02 calls out one open issue - better aligning with 3261 > Supported/Require definitions, and using 421 correctly. > > As most folks know, there has been many threads on the semantics > of Supported and Require. We're avoiding the problems most of > those threads call out by being very specific with when this > extension can be used, and what to put in the messages when it is > used. We're almost aligned with what's in 3261, but Ivo called my > attention some time back to a rough edge with responses. Section > 8.1.1.9 of RFC3261 requires responders to list any extensions > applied to a result in a Require header field. Now we could burn a > _lot_ more time arguing about whether doing so is worthwhile since > we can only apply this extension if it was Required in a request, > but I don't think it's worth the effort. > > Instead, I think the following replacement for section 6 of the > draft gets us to a place where we aren't in conflict with any 3261 > text. You can find a side-by-side diff of this suggestion against > the current section at > > . > > If this works for folks, then I don't think we need time in > Honolulu to discuss it. > > > ------ > > 6. The 'explicitsub' and 'nosub' Option Tags > > This document defines the 'explicitsub' option tag, used to signal > the use of the extension defined in Section 4, and the 'nosub' > option > tag, used to signal the use of the extension defined in Section 5. > > The use of either option tag in a Require header field is only > defined when it appears in a REFER request or a response to a > REFER request. A UA MUST NOT include the 'explicitsub' or 'nosub' > option tag in the Require header field of any request other than > REFER. A UA MUST NOT include the 'explicitsub' or 'nosub' option > tag in the Require header field of any SIP response other than a > 200 or 421 response to a REFER request. > > The 'explicitsub' and 'nosub' option tags MAY appear in the > Supported > header field of SIP messages, and in sip.extensions feature tag > defined in [RFC3840]. This signals only that the UA including the > value is aware of the extensions. In particular, a UA can only > invoke the use of one of the extensions in a request. A UA > MUST NOT > include either option tag in the Require header field of a 200 > response > to a REFER request if that tag was not present in the Require > header field > of the request. A User-Agent Server (UAS) that is processing a > REFER > request that lists 'explicitsub' or 'nosub' in its Supported > header field > and wishes to use one of those extensions will return a 421 > response > indicating which extension is required. > --------------010205010502070807080500 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/6/14 1:42 PM, Christer Holmberg wrote:

Hi,

 

>I really think the document covers this.
>
>If the receiver accepts the request, and doesn't use the extension, it will violate one or >more MUST requirements already in the document.
>Saying more risks providing a place to argue (and for implementers to disagree) >about what "use" means.
>
>What do you see going wrong if we leave the text as is?

I just want to avoid future discussions (similar to ones we have had in the past) about whether Require for these tags only means must support, or must support or use.

I hear that. Lets see if we can come up with something in the hallway to bring back to the list that raises that highlight without adding the risk I point to above.

Regards,

Christer

 

On 11/4/14 2:09 AM, Christer Holmberg wrote:

Hi,

 

In general I am ok with the approach seen in the diff.

 

However, related to the semantics, I think we in section 6 should make it more clear that, when present in the Require header field, the semantics means “MUST SUPPORT *AND* MUST USE”.

 

That could be done e.g. by extending the following sentence:

 

                  “The use of either option tag in a Require header field is only defined when it appears in a REFER request.”

 

…to:

 

                “The use of either option tag in a Require header field is only defined when it appears in a REFER request, and indicates that the receiver, if it accepts the request, must support and use the extension associated with the option-tag.”

 

Regards,

 

Christer

 

 

 

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert Sparks
Sent: 3. marraskuuta 2014 23:09
To: sipcore@ietf.org
Subject: [sipcore] Open issue in refer-explicit-subscriptions

 

-02 calls out one open issue - better aligning with 3261 Supported/Require definitions, and using 421 correctly.

As most folks know, there has been many threads on the semantics of Supported and Require. We're avoiding the problems most of those threads call out by being very specific with when this extension can be used, and what to put in the messages when it is used. We're almost aligned with what's in 3261, but Ivo called my attention some time back to a rough edge with responses. Section 8.1.1.9 of RFC3261 requires responders to list any extensions applied to a result in a Require header field. Now we could burn a _lot_ more time arguing about whether doing so is worthwhile since we can only apply this extension if it was Required in a request, but I don't think it's worth the effort.

Instead, I think the following replacement for section 6 of the draft gets us to a place where we aren't in conflict with any 3261 text. You can find a side-by-side diff of this suggestion against the current section at <http://www.nostrum.com/~rjsparks/diff_before_after.html>.

If this works for folks, then I don't think we need time in Honolulu to discuss it.


------

6. The 'explicitsub' and 'nosub' Option Tags

   This document defines the 'explicitsub' option tag, used to signal
   the use of the extension defined in Section 4, and the 'nosub' option
   tag, used to signal the use of the extension defined in Section 5.

   The use of either option tag in a Require header field is only
   defined when it appears in a REFER request or a response to a
   REFER request.  A UA MUST NOT include the 'explicitsub' or 'nosub'
   option tag in the Require header field of any request other than
   REFER.  A UA MUST NOT include the 'explicitsub' or 'nosub' option
   tag in the Require header field of any SIP response other than a
   200 or 421 response to a REFER request.

   The 'explicitsub' and 'nosub' option tags MAY appear in the Supported
   header field of SIP messages, and in sip.extensions feature tag
   defined in [RFC3840].  This signals only that the UA including the
   value is aware of the extensions.  In particular, a UA can only
   invoke the use of one of the extensions in a request.  A UA MUST NOT
   include either option tag in the Require header field of a 200 response
   to a REFER request if that tag was not present in the Require header field
   of the request. A User-Agent Server (UAS) that is processing a REFER
   request that lists 'explicitsub' or 'nosub' in its Supported header field
   and wishes to use one of those extensions will return a 421 response
   indicating which extension is required.

 


--------------010205010502070807080500-- From nobody Thu Nov 6 12:16:40 2014 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 B68371A1B44 for ; Thu, 6 Nov 2014 12:16:37 -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 DIfSZAX3x65e for ; Thu, 6 Nov 2014 12:16:36 -0800 (PST) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B95131A1B3D for ; Thu, 6 Nov 2014 12:16:34 -0800 (PST) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-01v.sys.comcast.net with comcast id CLF41p0075BUCh401LGZ6L; Thu, 06 Nov 2014 20:16:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-16v.sys.comcast.net with comcast id CLGY1p00U3Ge9ey01LGZqq; Thu, 06 Nov 2014 20:16:33 +0000 Message-ID: <545BD720.109@alum.mit.edu> Date: Thu, 06 Nov 2014 15:16:32 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1415304993; bh=K61+OqaupkzA0+w5lC44QxZ2IF58X3iTSZPQ3OO1WBU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=m9HHvQG0jaBMl9pOuXE9gb/+HWfGiZ78yFzr1/8UjdC+aJ+eguNV8fPxSI9PudRIA xKxpPWKRQzi1JNKXqQNGXedSDQCuLj4lNAZ6Qeyv41pbdAhtCOQYqMpZOdXIdjB/Cv S3tWPoaHGMInzGQvbwz//biJKgXhx0/dT1Q6KZud4SvPrBt0DQSOPj0lWe+NBlG9dD E0rC/DjFSadaXh6bRbuAFFZgC+RAEzgZD6gxzy4Nl55JREgi12mCkMRjri47OUZwoQ 0dsPFv9Z5wkcF3rlK37QHDvNhVdSW2Mx8CINHXydH7cPEcXh1y367Fmv4miSEUenP2 Lb5asA9S4EsNw== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/J53ja19B7vkCYA5Vo30eZ8Lc9Zo Subject: [sipcore] Call to adopt the REFER drafts 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, 06 Nov 2014 20:16:37 -0000 There has been considerable discussion and interest in the REFER drafts: draft-sparks-sipcore-refer-clarifications-05 draft-sparks-sipcore-refer-explicit-subscription-02 As co-chairman, I believe it is now appropriate to adopt these as SIPCORE WG documents. If you have an opinion on this, please comment on this list between now and the SIPCORE meeting next Thursday. Barring some unexpected objections, I expect we will be able to confirm adoption during the session. Thanks, Paul From nobody Thu Nov 6 12:19:15 2014 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 3101B1A1BBF for ; Thu, 6 Nov 2014 12:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] 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 Nmrz65qnj8vK for ; Thu, 6 Nov 2014 12:19:08 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 AD5171A1BAD for ; Thu, 6 Nov 2014 12:19:08 -0800 (PST) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sA6KJ4f4017471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Nov 2014 14:19:05 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <545BD7B4.1090509@nostrum.com> Date: Thu, 06 Nov 2014 14:19:00 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Ivo Sedlacek , "sipcore@ietf.org" References: <39B5E4D390E9BD4890E2B31079006101127852C3@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127852C3@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------090305090203000706090002" Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/vOQrFtEbOzb-QooUBywOJwKEX3M Subject: Re: [sipcore] Comments to draft-sparks-sipcore-refer-clarifications-05.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: Thu, 06 Nov 2014 20:19:14 -0000 This is a multi-part message in MIME format. --------------090305090203000706090002 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 11/4/14 7:24 AM, Ivo Sedlacek wrote: > > Hello, > > I reviewed the draft-sparks-sipcore-refer-clarifications-05 and here > are my comments: > > COMMENT 1: > > ------------------ > > Abstract states "An accepted SIP REFER method creates an implicit > subscription using the SIP-Specific Event Notification Framework." > > This is only partly true since creation of implicit subscription do > not necessarily happen when > draft-sparks-sipcore-refer-explicit-subscription is used or when > RFC4488 is used (assuming application specific logic ensures that the > implicit subscription is not created). > > ------------------ > > PROPOSED SOLUTION 1: > > ------------------ > > State: "An accepted SIP REFER method >>can<< create an implicit > subscription using the SIP-Specific Event Notification Framework." > > ------------------ > Hrmm - this is effectively the same feedback you sent earlier on sentences like this in the document (but thanks for the cleaner proposed text). My response then (and now) is that accounting for the one case where you can ask (but not be guaranteed) to suppress the subscription doesn't help with the clarity of this document. I'd like to hear from others in the group. Do you want to find a way to call out this case, or leave the text as is? I would prefer to leave the text alone. If we change it, I don't think this proposal is the right one yet. "Can" understates the issue significantly. > COMMENT 2: > > ------------------ > > Section 2 states "An accepted SIP REFER method creates an implicit > subscription using the SIP-Specific Event Notification Framework." > > This is only partly true since creation of implicit subscription do > not necessarily happen when > draft-sparks-sipcore-refer-explicit-subscription is used or when > RFC4488 is used (assuming application specific logic ensures that the > implicit subscription is not created). > > ------------------ > > PROPOSED SOLUTION 2: > > ------------------ > > State: "An accepted SIP REFER method >>can<< create an implicit > subscription using the SIP-Specific Event Notification Framework." > > ------------------ > Same as 1: > > COMMENT 3: > > ------------------ > > Section 3 states " > > Section 4.5.1 of [RFC6665] makes GRUU [RFC5627] mandatory to > > implement and use as the local target in the subscription created by > > the REFER request. > > " > > In RFC6665, usage of GRUU is mandatory for notifier (">>Notifiers<< > MUST implement the Globally Routable User Agent URI (GRUU) extension > defined in [RFC5627], and MUST use a GRUU as their local target."), > while the statement above could be understood to refer to both > subscriber and notifier. > > ------------------ > I think Adam tried to address this in an earlier response. The new 6665 clarifications draft may address it more strongly. > > PROPOSED SOLUTION 3: > > ------------------ > > State: " > > Section 4.5.1 of [RFC6665] makes GRUU [RFC5627] mandatory to > > implement and use as the local target >>by notifiers<< in the > subscription created by > > the REFER request. > > " > > ------------------ > > COMMENT 4: > > ------------------ > > Section 3 states " > > A UA that will accept a REFER request needs to include a GRUU in the > > Contact header field of all INVITE requests. This ensures that out- > > of-dialog REFER requests corresponding to any resulting INVITE > > dialogs arrive at this UA. Future extensions (such as > > [I-D.sparks-sipcore-refer-explicit-subscription]) might relax this > > requirement by defining a REFER request that cannot create an > > implicit subscription. > > " > > The UA might be globally reachable without indicating GRUU - this is > common today with network conference servers. Requiring GRUU is > unnecessary. > > ------------------ > Again, see Adam's 6665 clarifications draft (and please take any argument with it to the list under that name as a subject, not this draft). > > PROPOSED SOLUTION 4: > > ------------------ > > Make the statement general to state that the UA must provide URI which > is a globally reachable in the Contact of INVITE requests. > > ------------------ > > COMMENT 5: > > ------------------ > > Section 4, 1st paragraph and 2nd paragraph provide overlapping > information. > > In 1st paragraph, there is a statement that if remote UA provided a > GRUU as its local target then a user agent sending a REFER request > (towards that target) that could result in an implicit subscription > within a dialog is prohibited. > > In 2nd paragraph, the same is stated (in positive way) regardless > whether the remote UA provided a GRUU as its local target or not. > > ------------------ > > PROPOSED SOLUTION 5: > > ------------------ > > Remove the 1st paragraph of section 4. > > ------------------ > I can almost see the overlap you are talking about, but I don't see where that introduces any weakness into the text. Removing the paragraph is not the right thing to do. The first paragraph describes the prohibition, the second talks about what's left that you can do. The document is less accurate if you leave either point out. > > COMMENT 6: > > ------------------ > > Section 3 states: " > > A user agent constructing any REFER that can result in an implicit > > subscription MUST populate its Contact header field with a GRUU. > > " > > In RFC665, there is no such requirement for subscriber. Why do we > state such new requirement? > > ------------------ > See Adam's earlier response and the 6665 clarifications draft. > > PROPOSED SOLUTION 6: > > ------------------ > > Clarify the need for this requirement or remove it. > > ------------------ > > Kind regards > > Ivo Sedlacek > --------------090305090203000706090002 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/4/14 7:24 AM, Ivo Sedlacek wrote:

Hello,

 

I reviewed the draft-sparks-sipcore-refer-clarifications-05 and here are my comments:

 

COMMENT 1:

------------------

Abstract states "An accepted SIP REFER method creates an implicit subscription using the SIP-Specific Event Notification Framework."

 

This is only partly true since creation of implicit subscription do not necessarily happen when draft-sparks-sipcore-refer-explicit-subscription is used or when RFC4488 is used (assuming application specific logic ensures that the implicit subscription is not created).

------------------

 

PROPOSED SOLUTION 1:

------------------

State: "An accepted SIP REFER method >>can<< create an implicit subscription using the SIP-Specific Event Notification Framework."

------------------

Hrmm - this is effectively the same feedback you sent earlier on sentences like this in the document (but thanks for the cleaner proposed text).

My response then (and now) is that accounting for the one case where you can ask (but not be guaranteed)
to suppress the subscription doesn't help with the clarity of this document.

I'd like to hear from others in the group.
Do you want to find a way to call out this case, or leave the text as is?
I would prefer to leave the text alone.
If we change it, I don't think this proposal is the right one yet. "Can" understates the issue significantly.

COMMENT 2:

------------------

Section 2 states "An accepted SIP REFER method creates an implicit subscription using the SIP-Specific Event Notification Framework."

 

This is only partly true since creation of implicit subscription do not necessarily happen when draft-sparks-sipcore-refer-explicit-subscription is used or when RFC4488 is used (assuming application specific logic ensures that the implicit subscription is not created).

------------------

 

PROPOSED SOLUTION 2:

------------------

State: "An accepted SIP REFER method >>can<< create an implicit subscription using the SIP-Specific Event Notification Framework."

------------------

Same as 1:

 

COMMENT 3:

------------------

Section 3 states "

   Section 4.5.1 of [RFC6665] makes GRUU [RFC5627] mandatory to

   implement and use as the local target in the subscription created by

   the REFER request.

"

 

In RFC6665, usage of GRUU is mandatory for notifier (">>Notifiers<< MUST implement the Globally Routable User Agent URI (GRUU) extension defined in [RFC5627], and MUST use a GRUU as their local target."), while the statement above could be understood to refer to both subscriber and notifier.

------------------

I think Adam tried to address this in an earlier response. The new 6665 clarifications draft may address it more strongly.

 

PROPOSED SOLUTION 3:

------------------

State: "

   Section 4.5.1 of [RFC6665] makes GRUU [RFC5627] mandatory to

   implement and use as the local target >>by notifiers<< in the subscription created by

   the REFER request.

"

------------------

 

COMMENT 4:

------------------

Section 3 states "

   A UA that will accept a REFER request needs to include a GRUU in the

   Contact header field of all INVITE requests.  This ensures that out-

   of-dialog REFER requests corresponding to any resulting INVITE

   dialogs arrive at this UA.  Future extensions (such as

   [I-D.sparks-sipcore-refer-explicit-subscription]) might relax this

   requirement by defining a REFER request that cannot create an

   implicit subscription.

"

 

The UA might be globally reachable without indicating GRUU - this is common today with network conference servers. Requiring GRUU is unnecessary.

------------------

Again, see Adam's 6665 clarifications draft (and please take any argument with it to the list under that name as a subject, not this draft).

 

PROPOSED SOLUTION 4:

------------------

Make the statement general to state that the UA must provide URI which is a globally reachable in the Contact of INVITE requests.

------------------

 

COMMENT 5:

------------------

Section 4, 1st paragraph and 2nd paragraph provide overlapping information.

 

In 1st paragraph, there is a statement that if remote UA provided a GRUU as its local target then a user agent sending a REFER request (towards that target) that could result in an  implicit subscription within a dialog is prohibited.

 

In 2nd paragraph, the same is stated (in positive way) regardless whether the remote UA provided a GRUU as its local target or not.

------------------

 

PROPOSED SOLUTION 5:

------------------

Remove the 1st paragraph of section 4.

------------------

I can almost see the overlap you are talking about, but I don't see where that introduces any weakness into the text.
Removing the paragraph is not the right thing to do. The first paragraph describes the prohibition, the second talks
about what's left that you can do. The document is less accurate if you leave either point out.

 

COMMENT 6:

------------------

Section 3 states: "

   A user agent constructing any REFER that can result in an implicit

   subscription MUST populate its Contact header field with a GRUU.

"

 

In RFC665, there is no such requirement for subscriber. Why do we state such new requirement?

------------------

See Adam's earlier response and the 6665 clarifications draft.

 

PROPOSED SOLUTION 6:

------------------

Clarify the need for this requirement or remove it.

------------------

 

Kind regards

 

Ivo Sedlacek


--------------090305090203000706090002-- From nobody Thu Nov 6 12:21:04 2014 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 BB18C1A6F2C for ; Thu, 6 Nov 2014 12:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_DBL_ABUSE_REDIR=0.001, URIBL_DBL_REDIR=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 eXACIHkdoBeQ for ; Thu, 6 Nov 2014 12:21:00 -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 C1B5B1A1BF4 for ; Thu, 6 Nov 2014 12:21:00 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id E98AB6724DF6; Thu, 6 Nov 2014 20:20:54 +0000 (GMT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id sA6KKuR1020319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Nov 2014 15:20:57 -0500 Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id sA6KKtZf002403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 6 Nov 2014 14:20:56 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.169]) by umail.lucent.com (8.13.8/TPES) with ESMTP id sA6KKtSd010740; Thu, 6 Nov 2014 14:20:55 -0600 (CST) Message-ID: <545BD91E.1060206@bell-labs.com> Date: Thu, 06 Nov 2014 14:25:02 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Paul Kyzivat , SIPCORE References: <545BD720.109@alum.mit.edu> In-Reply-To: <545BD720.109@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/ylhR6JsBoaziAzaw1s_voa9JwuE Subject: Re: [sipcore] Call to adopt the REFER drafts 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, 06 Nov 2014 20:21:02 -0000 On 11/06/2014 02:16 PM, Paul Kyzivat wrote: > There has been considerable discussion and interest in the REFER drafts: > > draft-sparks-sipcore-refer-clarifications-05 > draft-sparks-sipcore-refer-explicit-subscription-02 > > As co-chairman, I believe it is now appropriate to adopt these as > SIPCORE WG documents. If you have an opinion on this, please comment on > this list between now and the SIPCORE meeting next Thursday. > > Barring some unexpected objections, I expect we will be able to confirm > adoption during the session. I support adoption. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Thu Nov 6 14:18:16 2014 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 9DF831A930A for ; Thu, 6 Nov 2014 14:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.093 X-Spam-Level: X-Spam-Status: No, score=-15.093 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, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, URIBL_DBL_ABUSE_REDIR=0.001, URIBL_DBL_REDIR=0.001, 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 hZlxWQjvUqW2 for ; Thu, 6 Nov 2014 14:18:13 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4BC91ABC0F for ; Thu, 6 Nov 2014 14:18:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1176; q=dns/txt; s=iport; t=1415312294; x=1416521894; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sMIjId0HHoivddCX+dctHwFQKnFjDcEbmPH3xJxBqo8=; b=CQaeNPCo8CuYB1LY1sewSqj+SwHO/fqow60za4/6Kb2MTppHXKnnVhf2 uLF0YDGQ7LoXdKWUk3PlZSsXhMndVrSS+Gl4JJBN69hCFjzXWjBMFt1px oSXOxuqLOIAp4pdSIUG6C9ctiMVXin0Gtd6Z3uR1k5Qw3fnT5BMFIeMrW E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFALzyW1StJA2D/2dsb2JhbABbgw5UVAXLKgqGeVQCgSEWAQEBAQF9hAIBAQEDAQEBATc0CwULAgEIGA0RECcLJQIEDgWIOAkIBc8sAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5AvEQFQB4MtgR4FkiSEU4cfgTKDTopuAYZsg3hsCwEBgQKBPAEBAQ X-IronPort-AV: E=Sophos;i="5.07,328,1413244800"; d="scan'208";a="370080990" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-3.cisco.com with ESMTP; 06 Nov 2014 22:18:13 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sA6MIBtY028546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Nov 2014 22:18:11 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.91]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 6 Nov 2014 16:18:11 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: "Vijay K. Gurbani" Thread-Topic: [sipcore] Call to adopt the REFER drafts Thread-Index: AQHP+f6UhWalGso5vUq3e2pKdKvnOZxUcBQA//+7CJY= Date: Thu, 6 Nov 2014 22:18:11 +0000 Message-ID: References: <545BD720.109@alum.mit.edu>,<545BD91E.1060206@bell-labs.com> In-Reply-To: <545BD91E.1060206@bell-labs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/zhWsR5AYkRTfnx3vwSJ5Gc2sy74 Cc: SIPCORE Subject: Re: [sipcore] Call to adopt the REFER drafts 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, 06 Nov 2014 22:18:14 -0000 +1 Regards, Gonzalo > On Nov 6, 2014, at 3:21 PM, Vijay K. Gurbani wrote: >=20 >> On 11/06/2014 02:16 PM, Paul Kyzivat wrote: >> There has been considerable discussion and interest in the REFER drafts: >>=20 >> draft-sparks-sipcore-refer-clarifications-05 >> draft-sparks-sipcore-refer-explicit-subscription-02 >>=20 >> As co-chairman, I believe it is now appropriate to adopt these as >> SIPCORE WG documents. If you have an opinion on this, please comment on >> this list between now and the SIPCORE meeting next Thursday. >>=20 >> Barring some unexpected objections, I expect we will be able to confirm >> adoption during the session. >=20 > I support adoption. >=20 > Cheers, >=20 > - vijay > --=20 > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Sat Nov 8 06:16:21 2014 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 CAD761A86FB for ; Sat, 8 Nov 2014 06:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001, URIBL_DBL_ABUSE_REDIR=0.001, URIBL_DBL_REDIR=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vDzrMf2nx2b for ; Sat, 8 Nov 2014 06:16:17 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id A5BA71A86EE for ; Sat, 8 Nov 2014 06:16:16 -0800 (PST) Received: from [192.168.40.29] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 8EC2F93C1AF; Sat, 8 Nov 2014 14:15:54 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Olle E. Johansson" In-Reply-To: Date: Sat, 8 Nov 2014 15:16:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <97A90A8D-B6AA-4E8E-95C7-89931CC8427E@edvina.net> References: <545BD720.109@alum.mit.edu>, <545BD91E.1060206@bell-labs.com> To: "Gonzalo Salgueiro (gsalguei)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/lLFgOG1gLRHDFChlpIfcQHMwjhk Cc: "Vijay K. Gurbani" , SIPCORE , Olle E Johansson Subject: Re: [sipcore] Call to adopt the REFER drafts 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, 08 Nov 2014 14:16:20 -0000 On 06 Nov 2014, at 23:18, Gonzalo Salgueiro (gsalguei) = wrote: > +1 >=20 +1 /O > Regards, >=20 > Gonzalo >=20 >=20 >=20 >> On Nov 6, 2014, at 3:21 PM, Vijay K. Gurbani = wrote: >>=20 >>> On 11/06/2014 02:16 PM, Paul Kyzivat wrote: >>> There has been considerable discussion and interest in the REFER = drafts: >>>=20 >>> draft-sparks-sipcore-refer-clarifications-05 >>> draft-sparks-sipcore-refer-explicit-subscription-02 >>>=20 >>> As co-chairman, I believe it is now appropriate to adopt these as >>> SIPCORE WG documents. If you have an opinion on this, please comment = on >>> this list between now and the SIPCORE meeting next Thursday. >>>=20 >>> Barring some unexpected objections, I expect we will be able to = confirm >>> adoption during the session. >>=20 >> I support adoption. >>=20 >> Cheers, >>=20 >> - vijay >> --=20 >> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) >> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com >> Web: http://ect.bell-labs.com/who/vkg/ | Calendar: = http://goo.gl/x3Ogq >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Sat Nov 8 09:14:22 2014 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 8381B1A1B3C for ; Sat, 8 Nov 2014 09:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_DBL_ABUSE_REDIR=0.001, URIBL_DBL_REDIR=0.001, URIBL_RHS_DOB=1.514] 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 vIH_2O0r2WQY for ; Sat, 8 Nov 2014 09:14:06 -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 04B341A1B35 for ; Sat, 8 Nov 2014 09:14:05 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-ac-545e4f5b868d Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 62.04.24955.B5F4E545; Sat, 8 Nov 2014 18:14:03 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0174.001; Sat, 8 Nov 2014 18:14:03 +0100 From: Christer Holmberg To: "Olle E. Johansson" , "Gonzalo Salgueiro (gsalguei)" Thread-Topic: [sipcore] Call to adopt the REFER drafts Thread-Index: AQHP+f6VH91H9GR7w0GSO75IWsY/XJxT+rsAgAAfnYCAAp4BgIAAQnLJ Date: Sat, 8 Nov 2014 17:14:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4ED99A@ESESSMB209.ericsson.se> References: <545BD720.109@alum.mit.edu>, <545BD91E.1060206@bell-labs.com> , <97A90A8D-B6AA-4E8E-95C7-89931CC8427E@edvina.net> In-Reply-To: <97A90A8D-B6AA-4E8E-95C7-89931CC8427E@edvina.net> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D4ED99AESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGfG3RjfaPy7E4OsPC4u5U/wsXq4+xGzx 9ccmNouGNXIOLB59l108pvzeyOoxbe1KVo8lS34yBbBEcdmkpOZklqUW6dslcGWc+vKOsWCR acXOJT8YGxhv6nUxcnJICJhIfJ+wggXCFpO4cG89WxcjF4eQwBFGiU0L2xkhnMWMEv3XLwBl ODjYBCwkuv9pg5giAvES+6/wgfQyC7hJtB99zgpiCwuYSszavpoZxBYRMJM4OukjO4TtJnGj bzZYnEVARWLmu82sIGN4BXwl9nxwgti0jlGidcEksBpOATuJRW1PwWxGoNu+n1rDBLFLXKLp y0pWiJsFJJbsOc8MYYtKvHz8jxWiJl9i4jqIXbwCghInZz5hmcAoMgtJ+ywkZbOQlEHEDSS+ vL8NZWtLLFv4mhnC1pfofn+aCVl8ASP7KkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzAuDu4 5bfqDsbLbxwPMQpwMCrx8Bq0x4YIsSaWFVfmHmKU5mBREuddeG5esJBAemJJanZqakFqUXxR aU5q8SFGJg5OqQbGhopnTwMcxecc2PTkbvVZDRV1HdXo5qNcqbc1HodcnXNw+ZLSJPbb2QbX Cy8KbmKy+suinPlzY/MfSRW3A88XMfFvfOlwTTu7/33x351dem99Xt1LOV3IMkF8QfdFy9lq DWbvLDL7n3T7p047ub5l4XvONnWOW3qCO7YHNKT/nS/+ZvW1ba7/lFiKMxINtZiLihMBwoye 0ZwCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/mNOzghBOBZ_ovZBVDvabtNzvU7c Cc: SIPCORE , "Vijay K. Gurbani" Subject: Re: [sipcore] Call to adopt the REFER drafts 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, 08 Nov 2014 17:14:18 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D4ED99AESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable We still have some work to do, but I support adoption of the drafts. Regards, Christer Sent from my Windows Phone ________________________________ From: Olle E. Johansson Sent: =FD08/=FD11/=FD2014 04:16 To: Gonzalo Salgueiro (gsalguei) Cc: Vijay K. Gurbani; SIPCORE; Olle E Johansson Subject: Re: [sipcore] Call to adopt the REFER drafts On 06 Nov 2014, at 23:18, Gonzalo Salgueiro (gsalguei) = wrote: > +1 > +1 /O > Regards, > > Gonzalo > > > >> On Nov 6, 2014, at 3:21 PM, Vijay K. Gurbani wrote: >> >>> On 11/06/2014 02:16 PM, Paul Kyzivat wrote: >>> There has been considerable discussion and interest in the REFER drafts= : >>> >>> draft-sparks-sipcore-refer-clarifications-05 >>> draft-sparks-sipcore-refer-explicit-subscription-02 >>> >>> As co-chairman, I believe it is now appropriate to adopt these as >>> SIPCORE WG documents. If you have an opinion on this, please comment on >>> this list between now and the SIPCORE meeting next Thursday. >>> >>> Barring some unexpected objections, I expect we will be able to confirm >>> adoption during the session. >> >> I support adoption. >> >> Cheers, >> >> - vijay >> -- >> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) >> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com >> Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq >> >> _______________________________________________ >> 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 --_000_7594FB04B1934943A5C02806D1A2204B1D4ED99AESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
We still have= some work to do, but I support adoption of the drafts.

Regards,

Christer

Sent from my Windows Phone
From: Olle E. Johansson
Sent: =FD08= /=FD11/=FD2014 04:16
To: Gonzalo Salgueiro (gsalguei) Cc: Vijay K. Gurbani; SIPCORE; Olle E Johansson
Subject: Re: [= sipcore] Call to adopt the REFER drafts


On 06 Nov 2014, at 23:18, Gonzalo Salgueiro (gsalguei) <gsalguei@cisco.c= om> wrote:

> +1
>
+1
/O
> Regards,
>
> Gonzalo
>
>
>
>> On Nov 6, 2014, at 3:21 PM, Vijay K. Gurbani <vkg@bell-labs.com= > wrote:
>>
>>> On 11/06/2014 02:16 PM, Paul Kyzivat wrote:
>>> There has been considerable discussion and interest in the REF= ER drafts:
>>>
>>> draft-sparks-sipcore-refer-clarifications-05
>>> draft-sparks-sipcore-refer-explicit-subscription-02
>>>
>>> As co-chairman, I believe it is now appropriate to adopt these= as
>>> SIPCORE WG documents. If you have an opinion on this, please c= omment on
>>> this list between now and the SIPCORE meeting next Thursday. >>>
>>> Barring some unexpected objections, I expect we will be able t= o confirm
>>> adoption during the session.
>>
>> I support adoption.
>>
>> Cheers,
>>
>> - vijay
>> --
>> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
>> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.= com
>> Web: http://ect.bell= -labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
>>
>> _______________________________________________
>> 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
 --_000_7594FB04B1934943A5C02806D1A2204B1D4ED99AESESSMB209erics_-- From nobody Sun Nov 9 03:16:49 2014 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 5849C1A1A97 for ; Sun, 9 Nov 2014 03:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, URIBL_DBL_ABUSE_REDIR=0.001, URIBL_DBL_REDIR=0.001, URIBL_RHS_DOB=1.514] 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 h8x579oXQG9M for ; Sun, 9 Nov 2014 03:16:45 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id D5A2B1A1A8D for ; Sun, 9 Nov 2014 03:16:44 -0800 (PST) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 09 Nov 2014 06:16:19 -0500 Received: from XCT116CNC.rim.net (10.65.161.216) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.3.174.1; Sun, 9 Nov 2014 06:16:18 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0174.001; Sun, 9 Nov 2014 06:16:18 -0500 From: Andrew Allen To: "christer.holmberg@ericsson.com" , "oej@edvina.net" , "gsalguei@cisco.com" Thread-Topic: [sipcore] Call to adopt the REFER drafts Thread-Index: AQHP/A6UeHrw6CaIk0yCqVkgvZRq8Q== Date: Sun, 9 Nov 2014 11:16:17 +0000 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4ED99A@ESESSMB209.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD23399551E7XMB122CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/8ywmv0SW7NvgG-pDKGHd4bLvs2k Cc: "sipcore@ietf.org" , "vkg@bell-labs.com" Subject: Re: [sipcore] Call to adopt the REFER drafts 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, 09 Nov 2014 11:16:48 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD23399551E7XMB122CNCrimnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJIGFsc28gc3VwcG9ydCBhZG9wdGlvbiBvZiBib3RoIGRyYWZ0cy4NCg0KQW5kcmV3DQoNCkZy b206IENocmlzdGVyIEhvbG1iZXJnIFttYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tXQ0KU2VudDogU2F0dXJkYXksIE5vdmVtYmVyIDA4LCAyMDE0IDEyOjE0IFBNIEVhc3Rlcm4g U3RhbmRhcmQgVGltZQ0KVG86IE9sbGUgRS4gSm9oYW5zc29uIDxvZWpAZWR2aW5hLm5ldD47IEdv bnphbG8gU2FsZ3VlaXJvIChnc2FsZ3VlaSkgPGdzYWxndWVpQGNpc2NvLmNvbT4NCkNjOiBTSVBD T1JFIDxzaXBjb3JlQGlldGYub3JnPjsgVmlqYXkgSy4gR3VyYmFuaSA8dmtnQGJlbGwtbGFicy5j b20+DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIENhbGwgdG8gYWRvcHQgdGhlIFJFRkVSIGRyYWZ0 cw0KDQpXZSBzdGlsbCBoYXZlIHNvbWUgd29yayB0byBkbywgYnV0IEkgc3VwcG9ydCBhZG9wdGlv biBvZiB0aGUgZHJhZnRzLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpTZW50IGZyb20gbXkg V2luZG93cyBQaG9uZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IE9s bGUgRS4gSm9oYW5zc29uPG1haWx0bzpvZWpAZWR2aW5hLm5ldD4NClNlbnQ6IOKAjjA4L+KAjjEx L+KAjjIwMTQgMDQ6MTYNClRvOiBHb256YWxvIFNhbGd1ZWlybyAoZ3NhbGd1ZWkpPG1haWx0bzpn c2FsZ3VlaUBjaXNjby5jb20+DQpDYzogVmlqYXkgSy4gR3VyYmFuaTxtYWlsdG86dmtnQGJlbGwt bGFicy5jb20+OyBTSVBDT1JFPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPjsgT2xsZSBFIEpvaGFu c3NvbjxtYWlsdG86b2VqQGVkdmluYS5uZXQ+DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIENhbGwg dG8gYWRvcHQgdGhlIFJFRkVSIGRyYWZ0cw0KDQoNCk9uIDA2IE5vdiAyMDE0LCBhdCAyMzoxOCwg R29uemFsbyBTYWxndWVpcm8gKGdzYWxndWVpKSA8Z3NhbGd1ZWlAY2lzY28uY29tPiB3cm90ZToN Cg0KPiArMQ0KPg0KKzENCi9PDQo+IFJlZ2FyZHMsDQo+DQo+IEdvbnphbG8NCj4NCj4NCj4NCj4+ IE9uIE5vdiA2LCAyMDE0LCBhdCAzOjIxIFBNLCBWaWpheSBLLiBHdXJiYW5pIDx2a2dAYmVsbC1s YWJzLmNvbT4gd3JvdGU6DQo+Pg0KPj4+IE9uIDExLzA2LzIwMTQgMDI6MTYgUE0sIFBhdWwgS3l6 aXZhdCB3cm90ZToNCj4+PiBUaGVyZSBoYXMgYmVlbiBjb25zaWRlcmFibGUgZGlzY3Vzc2lvbiBh bmQgaW50ZXJlc3QgaW4gdGhlIFJFRkVSIGRyYWZ0czoNCj4+Pg0KPj4+IGRyYWZ0LXNwYXJrcy1z aXBjb3JlLXJlZmVyLWNsYXJpZmljYXRpb25zLTA1DQo+Pj4gZHJhZnQtc3BhcmtzLXNpcGNvcmUt cmVmZXItZXhwbGljaXQtc3Vic2NyaXB0aW9uLTAyDQo+Pj4NCj4+PiBBcyBjby1jaGFpcm1hbiwg SSBiZWxpZXZlIGl0IGlzIG5vdyBhcHByb3ByaWF0ZSB0byBhZG9wdCB0aGVzZSBhcw0KPj4+IFNJ UENPUkUgV0cgZG9jdW1lbnRzLiBJZiB5b3UgaGF2ZSBhbiBvcGluaW9uIG9uIHRoaXMsIHBsZWFz ZSBjb21tZW50IG9uDQo+Pj4gdGhpcyBsaXN0IGJldHdlZW4gbm93IGFuZCB0aGUgU0lQQ09SRSBt ZWV0aW5nIG5leHQgVGh1cnNkYXkuDQo+Pj4NCj4+PiBCYXJyaW5nIHNvbWUgdW5leHBlY3RlZCBv YmplY3Rpb25zLCBJIGV4cGVjdCB3ZSB3aWxsIGJlIGFibGUgdG8gY29uZmlybQ0KPj4+IGFkb3B0 aW9uIGR1cmluZyB0aGUgc2Vzc2lvbi4NCj4+DQo+PiBJIHN1cHBvcnQgYWRvcHRpb24uDQo+Pg0K Pj4gQ2hlZXJzLA0KPj4NCj4+IC0gdmlqYXkNCj4+IC0tDQo+PiBWaWpheSBLLiBHdXJiYW5pLCBC ZWxsIExhYm9yYXRvcmllcywgQWxjYXRlbC1MdWNlbnQNCj4+IDE5NjAgTHVjZW50IExhbmUsIFJt LiA5Qy01MzMsIE5hcGVydmlsbGUsIElsbGlub2lzIDYwNTYzIChVU0EpDQo+PiBFbWFpbDogdmtn QHtiZWxsLWxhYnMuY29tLGFjbS5vcmd9IC8gdmlqYXkuZ3VyYmFuaUBhbGNhdGVsLWx1Y2VudC5j b20NCj4+IFdlYjogaHR0cDovL2VjdC5iZWxsLWxhYnMuY29tL3doby92a2cvICB8IENhbGVuZGFy OiBodHRwOi8vZ29vLmdsL3gzT2dxDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+PiBzaXBjb3Jl QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNv cmUNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBj b3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNv cmUNCg== --_000_BBF5DDFE515C3946BC18D733B20DAD23399551E7XMB122CNCrimnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxmb250IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48YnI+DQpJIGFsc28gc3VwcG9ydCBhZG9wdGlvbiBvZiBib3RoIGRyYWZ0cy48YnI+DQo8YnI+ DQpBbmRyZXc8L2ZvbnQ+PGJyPg0KJm5ic3A7PGJyPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxiPkZyb208L2I+OiBDaHJpc3RlciBIb2xt YmVyZyBbbWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbV0NCjxicj4NCjxiPlNl bnQ8L2I+OiBTYXR1cmRheSwgTm92ZW1iZXIgMDgsIDIwMTQgMTI6MTQgUE0gRWFzdGVybiBTdGFu ZGFyZCBUaW1lPGJyPg0KPGI+VG88L2I+OiBPbGxlIEUuIEpvaGFuc3NvbiAmbHQ7b2VqQGVkdmlu YS5uZXQmZ3Q7OyBHb256YWxvIFNhbGd1ZWlybyAoZ3NhbGd1ZWkpICZsdDtnc2FsZ3VlaUBjaXNj by5jb20mZ3Q7DQo8YnI+DQo8Yj5DYzwvYj46IFNJUENPUkUgJmx0O3NpcGNvcmVAaWV0Zi5vcmcm Z3Q7OyBWaWpheSBLLiBHdXJiYW5pICZsdDt2a2dAYmVsbC1sYWJzLmNvbSZndDsgPGJyPg0KPGI+ U3ViamVjdDwvYj46IFJlOiBbc2lwY29yZV0gQ2FsbCB0byBhZG9wdCB0aGUgUkVGRVIgZHJhZnRz IDxicj4NCjwvZm9udD4mbmJzcDs8YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+V2Ugc3Rp bGwgaGF2ZSBzb21lIHdvcmsgdG8gZG8sIGJ1dCBJIHN1cHBvcnQgYWRvcHRpb24gb2YgdGhlIGRy YWZ0cy48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0K U2VudCBmcm9tIG15IFdpbmRvd3MgUGhvbmU8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9Imx0ciI+ DQo8aHI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250 LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbToNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdCI+PGEgaHJlZj0i bWFpbHRvOm9lakBlZHZpbmEubmV0Ij5PbGxlIEUuIEpvaGFuc3NvbjwvYT48L3NwYW4+PGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjEx cHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlNlbnQ6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPuKAjjA4L+KAjjExL+KAjjIw MTQgMDQ6MTY8L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fu cy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlRvOg0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0 Ij48YSBocmVmPSJtYWlsdG86Z3NhbGd1ZWlAY2lzY28uY29tIj5Hb256YWxvIFNhbGd1ZWlybyAo Z3NhbGd1ZWkpPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJy aSxzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6DQo8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXpl OjExcHQiPjxhIGhyZWY9Im1haWx0bzp2a2dAYmVsbC1sYWJzLmNvbSI+VmlqYXkgSy4gR3VyYmFu aTwvYT47DQo8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+U0lQQ09SRTwvYT47IDxh IGhyZWY9Im1haWx0bzpvZWpAZWR2aW5hLm5ldCI+T2xsZSBFIEpvaGFuc3NvbjwvYT48L3NwYW4+ PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1z aXplOjExcHQ7IGZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQiPlJlOiBbc2lw Y29yZV0gQ2FsbCB0byBhZG9wdCB0aGUgUkVGRVIgZHJhZnRzPC9zcGFuPjxicj4NCjxicj4NCjwv ZGl2Pg0KPC9kaXY+DQo8Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7 Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+PGJyPg0KT24gMDYgTm92IDIwMTQsIGF0IDIzOjE4 LCBHb256YWxvIFNhbGd1ZWlybyAoZ3NhbGd1ZWkpICZsdDtnc2FsZ3VlaUBjaXNjby5jb20mZ3Q7 IHdyb3RlOjxicj4NCjxicj4NCiZndDsgJiM0MzsxPGJyPg0KJmd0OyA8YnI+DQomIzQzOzE8YnI+ DQovTzxicj4NCiZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgR29uemFsbzxicj4N CiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7IE9uIE5vdiA2LCAyMDE0 LCBhdCAzOjIxIFBNLCBWaWpheSBLLiBHdXJiYW5pICZsdDt2a2dAYmVsbC1sYWJzLmNvbSZndDsg d3JvdGU6PGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IE9uIDExLzA2LzIwMTQgMDI6 MTYgUE0sIFBhdWwgS3l6aXZhdCB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsgVGhlcmUgaGFzIGJl ZW4gY29uc2lkZXJhYmxlIGRpc2N1c3Npb24gYW5kIGludGVyZXN0IGluIHRoZSBSRUZFUiBkcmFm dHM6PGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBkcmFmdC1zcGFya3Mtc2lw Y29yZS1yZWZlci1jbGFyaWZpY2F0aW9ucy0wNTxicj4NCiZndDsmZ3Q7Jmd0OyBkcmFmdC1zcGFy a3Mtc2lwY29yZS1yZWZlci1leHBsaWNpdC1zdWJzY3JpcHRpb24tMDI8YnI+DQomZ3Q7Jmd0OyZn dDsgPGJyPg0KJmd0OyZndDsmZ3Q7IEFzIGNvLWNoYWlybWFuLCBJIGJlbGlldmUgaXQgaXMgbm93 IGFwcHJvcHJpYXRlIHRvIGFkb3B0IHRoZXNlIGFzPGJyPg0KJmd0OyZndDsmZ3Q7IFNJUENPUkUg V0cgZG9jdW1lbnRzLiBJZiB5b3UgaGF2ZSBhbiBvcGluaW9uIG9uIHRoaXMsIHBsZWFzZSBjb21t ZW50IG9uPGJyPg0KJmd0OyZndDsmZ3Q7IHRoaXMgbGlzdCBiZXR3ZWVuIG5vdyBhbmQgdGhlIFNJ UENPUkUgbWVldGluZyBuZXh0IFRodXJzZGF5Ljxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7 Jmd0OyZndDsgQmFycmluZyBzb21lIHVuZXhwZWN0ZWQgb2JqZWN0aW9ucywgSSBleHBlY3Qgd2Ug d2lsbCBiZSBhYmxlIHRvIGNvbmZpcm08YnI+DQomZ3Q7Jmd0OyZndDsgYWRvcHRpb24gZHVyaW5n IHRoZSBzZXNzaW9uLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEkgc3VwcG9ydCBhZG9w dGlvbi48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBDaGVlcnMsPGJyPg0KJmd0OyZndDsg PGJyPg0KJmd0OyZndDsgLSB2aWpheTxicj4NCiZndDsmZ3Q7IC0tIDxicj4NCiZndDsmZ3Q7IFZp amF5IEsuIEd1cmJhbmksIEJlbGwgTGFib3JhdG9yaWVzLCBBbGNhdGVsLUx1Y2VudDxicj4NCiZn dDsmZ3Q7IDE5NjAgTHVjZW50IExhbmUsIFJtLiA5Qy01MzMsIE5hcGVydmlsbGUsIElsbGlub2lz IDYwNTYzIChVU0EpPGJyPg0KJmd0OyZndDsgRW1haWw6IHZrZ0B7YmVsbC1sYWJzLmNvbSxhY20u b3JnfSAvIHZpamF5Lmd1cmJhbmlAYWxjYXRlbC1sdWNlbnQuY29tPGJyPg0KJmd0OyZndDsgV2Vi OiA8YSBocmVmPSJodHRwOi8vZWN0LmJlbGwtbGFicy5jb20vd2hvL3ZrZy8iPmh0dHA6Ly9lY3Qu YmVsbC1sYWJzLmNvbS93aG8vdmtnLzwvYT4mbmJzcDsgfCBDYWxlbmRhcjoNCjxhIGhyZWY9Imh0 dHA6Ly9nb28uZ2wveDNPZ3EiPmh0dHA6Ly9nb28uZ2wveDNPZ3E8L2E+PGJyPg0KJmd0OyZndDsg PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7Jmd0OyBzaXBjb3JlIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IHNp cGNvcmVAaWV0Zi5vcmc8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lwY29yZTwvYT48YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHNpcGNvcmUgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyBzaXBjb3JlQGlldGYub3JnPGJyPg0KJmd0OyA8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNpcGNvcmUgbWFpbGlu ZyBsaXN0PGJyPg0Kc2lwY29yZUBpZXRmLm9yZzxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zaXBjb3JlPC9hPjxicj4NCjwvZGl2Pg0KPC9zcGFuPjwvZm9udD4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_BBF5DDFE515C3946BC18D733B20DAD23399551E7XMB122CNCrimnet_-- From nobody Mon Nov 10 10:31:24 2014 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 B99E11A86EE for ; Mon, 10 Nov 2014 10:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.579 X-Spam-Level: X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TErmpIjuLaF for ; Mon, 10 Nov 2014 10:31:16 -0800 (PST) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E692C1A8A06 for ; Mon, 10 Nov 2014 10:28:47 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id s7so5821345qap.14 for ; Mon, 10 Nov 2014 10:28:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=MdSb/9xsli66p+ttyjYNrS8wgYQs7b/gIpbZ+dZ9EWM=; b=MqbmafA2W6ovJSt9mBTADGUyF2QPhF6twUQPLiPy771WS7f1O1o96FtoTh/Zyug0Fd 1ZMz7fm1J2x1MQmTwGqHsMGEbhxH8RCsQShGhPV0txYkl1fzwFIWe9kAnNMhuQRGlcx/ 0x1JIyAPbMKxGwrBd+FLIgwQXnXBkJeuCTVe9aZ0oUlb019s6fvnqfIo1AqC/QwUJAcA vFvFr5h9O8tWrw9z5MG/u30F6bFPpiwuoQ2nq7wSFpowPEvd8l2Vyb/m9NwO21KLslkN QKlnOD+4a+j9rQdYEDUrDN9G1xB89x2XJd6PbzBGTKnmmjcl/t/1V9do0bv1SBftyMlk Ffew== X-Gm-Message-State: ALoCoQlrwu4xYzV4Ep5jBMAJJe7sfMMt+cfyNc4fZ/dAYNHev/4xV3reDlDjtWVmCgc0leoU6cEk X-Received: by 10.224.130.135 with SMTP id t7mr45688497qas.95.1415644122765; Mon, 10 Nov 2014 10:28:42 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/9E8AR1A33V2yxS3W3NSzKRX717Q== Date: Mon, 10 Nov 2014 13:28:39 -0500 Message-ID: To: draft-sparks-sipcore-refer-clarifications@tools.ietf.org, sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/KwcupPeR_imU4EEixJdY7JiiBLw Subject: [sipcore] draft-sparks-sipcore-refer-clarifications-05: comments 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, 10 Nov 2014 18:31:18 -0000 Hi, Draft-sparks-sipcore-refer-clarifications-05 section 3 indicates the following: "A UA that will accept a REFER request needs to include a GRUU in the Contact header field of all INVITE requests. This ensures that out- of-dialog REFER requests corresponding to any resulting INVITE dialogs arrive at this UA. Future extensions (such as [I-D.sparks-sipcore-refer-explicit-subscription]) might relax this requirement by defining a REFER request that cannot create an implicit subscription." Concerning the first sentence, potentially should reword so that it isn't just for INVITE. Is there a reason why not relaxing the requirement for REFER notifiers which only send NOTIFY with Subscription-State terminated? For instance, RFC 6665 section 4.4.1 indicates that the NOTIFY does not create a dialog usage. "Dialogs usages are created upon completion of a NOTIFY transaction for a new subscription, unless the NOTIFY request contains a "Subscription-State" of "terminated."" Thanks, Brett From nobody Mon Nov 10 11:07:14 2014 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 60C461AC399 for ; Mon, 10 Nov 2014 11:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2NruHe-ijQ3 for ; Mon, 10 Nov 2014 11:07:12 -0800 (PST) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6571ABD3A for ; Mon, 10 Nov 2014 11:07:06 -0800 (PST) Received: by mail-qg0-f52.google.com with SMTP id a108so5908409qge.39 for ; Mon, 10 Nov 2014 11:07:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=PBP6gwxOloMg4i/1wtkBgjlhd5rmyUPb9eQ1oQy8hl0=; b=N54wU6lOfZT9KWVEWMW6raiMikRDOp+Ppo9ryCB3NTgS8FHczVeSe5nRVd+PehyX2F zfLXSceJEWLzVt3I0iD+iE8c7jzHh8IDqrM8Aqyh3afTdQLSf4LogvYwIrHKth+R4ckm eWk+akjZMSvi/Y5V34j9vig7/p51swhdyhdsMB46eQudvEiiG9TW1zER8fFRDdRV6KCf l6NH9lHrN5oiJKfX5bHxKjxKai4byGYxx/GT8UekbxceewcsRmnZl+I9hpgQMIa03lNy zE8/6r1qmiaAkC4nltjbBAdr7egkOJ8aYZ+xzpSayPyYF6tYQkNzsQWVIsKI4sprFcLs tq3g== X-Gm-Message-State: ALoCoQk0esJNXxApYVeKDSq7YIZ9CLS9pGK7GvufKQ+19tQKufXbLIQ/O0sAAuQkASvdCZkeZdSp X-Received: by 10.224.89.69 with SMTP id d5mr46010122qam.84.1415646425739; Mon, 10 Nov 2014 11:07:05 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/9GW7nx4tKzJjGQgG5Qx/+RcN5vQ== Date: Mon, 10 Nov 2014 14:07:02 -0500 Message-ID: To: draft-sparks-sipcore-refer-explicit-subscription@tools.ietf.org, sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/OeD6RjuJkQxDzbwiiyM85DClxfM Subject: [sipcore] draft-sparks-sipcore-refer-explicit-subscription-02: comments 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, 10 Nov 2014 19:07:13 -0000 Hi, The following are some comments concerning draft-sparks-sipcore-refer-explicit-subscription-02. Thanks, Brett ------- If something within this draft allows a RFC 6665 compliant notifier to not supply a GRUU Contact within call's dialog, please clearly indicate it. For instance if true, indicate that the notifier is not required to supply a GRUU Contact if notifier supports 'nosub' (even if referrer does not support 'nosub'). Section 6 indicates the following: "The 'explicitsub' and 'nosub' option tags MAY appear in the Supported header field of SIP messages, and in sip.extensions feature tag defined in [RFC3840]. This signals only that the UA including the value is aware of the extensions. In particular, a UA can only invoke the use of one of the extensions in a request. A User-Agent Server (UAS) that is processing a REFER request that lists 'explicitsub' or 'nosub' in its Supported header field and wishes to use one of those extensions will return a 421 response indicating which extension is required. OPEN ISSUE: This description of the use of 421 is not yet perfectly aligned with RFC3261's definition." I think that the open issue should be closed by not mandating the 421 response (at least if REFER was sent within dialog). Similar to the RFC 3262 behavior, the UAS can indicate it is being used by including option-tag within Require header of 2xx response. From nobody Mon Nov 10 11:13:39 2014 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 25EB71AC3BA for ; Mon, 10 Nov 2014 11:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 1dZcKd-1UQEt for ; Mon, 10 Nov 2014 11:13:27 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 752531AC3A1 for ; Mon, 10 Nov 2014 11:13:06 -0800 (PST) Received: from dhcp-b418.meeting.ietf.org (dhcp-b418.meeting.ietf.org [31.133.180.24]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAAJD3SG031734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Nov 2014 13:13:03 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <54610E3E.8030003@nostrum.com> Date: Mon, 10 Nov 2014 09:13:02 -1000 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Brett Tate , draft-sparks-sipcore-refer-explicit-subscription@tools.ietf.org, sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/LQNEAwZLuGziO0dV4yVBAoCcu8c Subject: Re: [sipcore] draft-sparks-sipcore-refer-explicit-subscription-02: comments 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, 10 Nov 2014 19:13:32 -0000 On 11/10/14 9:07 AM, Brett Tate wrote: > Hi, > > The following are some comments concerning > draft-sparks-sipcore-refer-explicit-subscription-02. > > Thanks, > Brett > > ------- > > If something within this draft allows a RFC 6665 compliant notifier to not > supply a GRUU Contact within call's dialog, please clearly indicate it. > For instance if true, indicate that the notifier is not required to supply > a GRUU Contact if notifier supports 'nosub' (even if referrer does not > support 'nosub'). > > Section 6 indicates the following: > > "The 'explicitsub' and 'nosub' option tags MAY appear in the Supported > header field of SIP messages, and in sip.extensions feature tag > defined in [RFC3840]. This signals only that the UA including the > value is aware of the extensions. In particular, a UA can only > invoke the use of one of the extensions in a request. A User-Agent > Server (UAS) that is processing a REFER request that lists > 'explicitsub' or 'nosub' in its Supported header field and wishes to > use one of those extensions will return a 421 response indicating > which extension is required. > > OPEN ISSUE: This description of the use of 421 is not yet perfectly > aligned with RFC3261's definition." > > I think that the open issue should be closed by not mandating the 421 > response (at least if REFER was sent within dialog). Similar to the RFC > 3262 behavior, the UAS can indicate it is being used by including > option-tag within Require header of 2xx response. Hi Brett - I sent text last week proposing how to address this (Subject 'Open issue in refer-explicit-subscriptions'). Was that text problematic for you? RjS From nobody Mon Nov 10 12:20:18 2014 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 0921A1ACE03 for ; Mon, 10 Nov 2014 12:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBkyf45rCT3l for ; Mon, 10 Nov 2014 12:20:08 -0800 (PST) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C70C91A00F9 for ; Mon, 10 Nov 2014 12:19:55 -0800 (PST) Received: by mail-qg0-f47.google.com with SMTP id j107so6063749qga.6 for ; Mon, 10 Nov 2014 12:19:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=ZgxbCxfqYs4S60+tWjGSIMbNnBquvhUrSiGkcc4gPP4=; b=PHznQzFRzRVB2huhG7ARHCYB6kZe2UZutQRGVNkBZi1eYPvRWUr1o493TzrXlRPYpt 7viz6wjnv47rX4g4l6v0sPQ4K+KaY2y12di80Fzh1ZriWj0+98oI7q68yLRBRtUg60EE ljfCn2EEOHrebCCMV7lh8GgtloqEIJ/GhN9OwE5wgPjlbGkuxUU+/jxbPcp33wnuU0TB oDRsmv+zg3xnwDwfue+vDLImjtZGQ1yawmRY3hVoq4a/gL6wb/S0ZWdupbY4r1lPKEz1 1Z9sGz+5MjZIRkpPXJxiBjlZIFVE1gtQJ91qz48qjdrOiMT33PwqQnJZTlz0VVgethQM IMqA== X-Gm-Message-State: ALoCoQlLYxH8EKHS9vzflvBCdnt1AxCjn/Bf4L7LWNOQuYkTIVUs9NGYQfrDzwqV+pk/5SJVHYKz X-Received: by 10.224.12.145 with SMTP id x17mr46979095qax.13.1415650795063; Mon, 10 Nov 2014 12:19:55 -0800 (PST) From: Brett Tate References: <54610E3E.8030003@nostrum.com> In-Reply-To: <54610E3E.8030003@nostrum.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFfeN8LiET/kWztblTf6xQUrobKVAGHHR+ZnS8SkpA= Date: Mon, 10 Nov 2014 15:19:51 -0500 Message-ID: <16c53b2416e5d5ae6e327d9b7d0399ed@mail.gmail.com> To: draft-sparks-sipcore-refer-explicit-subscription@tools.ietf.org, sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/LjYlobs3SZVIsGRvXSrcPxLdl_4 Subject: Re: [sipcore] draft-sparks-sipcore-refer-explicit-subscription-02: comments 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, 10 Nov 2014 20:20:11 -0000 Hi Robert, Thanks for the response; reply is inline. > > If something within this draft allows a RFC 6665 compliant notifier to > > not supply a GRUU Contact within call's dialog, please clearly indicate > > it. > > For instance if true, indicate that the notifier is not required to > > supply a GRUU Contact if notifier supports 'nosub' (even if referrer > > does not support 'nosub'). > > > > Section 6 indicates the following: > > > > "The 'explicitsub' and 'nosub' option tags MAY appear in the Supported > > header field of SIP messages, and in sip.extensions feature tag > > defined in [RFC3840]. This signals only that the UA including the > > value is aware of the extensions. In particular, a UA can only > > invoke the use of one of the extensions in a request. A User-Agent > > Server (UAS) that is processing a REFER request that lists > > 'explicitsub' or 'nosub' in its Supported header field and wishes to > > use one of those extensions will return a 421 response indicating > > which extension is required. > > > > OPEN ISSUE: This description of the use of 421 is not yet perfectly > > aligned with RFC3261's definition." > > > > I think that the open issue should be closed by not mandating the 421 > > response (at least if REFER was sent within dialog). Similar to the > > RFC > > 3262 behavior, the UAS can indicate it is being used by including > > option-tag within Require header of 2xx response. > Hi Brett - > > I sent text last week proposing how to address this > (Subject 'Open issue in refer-explicit-subscriptions'). > Was that text problematic for you? The proposal continues to mandate that the option-tag only be honored if received within a Require header of REFER. If REFER is received within dialog, mandating that the UAS return a 421 appears to do nothing but require extra messaging for those attempting to use it. I recommend allowing behavior similar to RFC 3262 so that the option tag can be within Supported of mid-dialog REFER and Require of REFER's 2xx response. Thanks, Brett From nobody Mon Nov 10 12:24:52 2014 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 1E87D1ACE6B for ; Mon, 10 Nov 2014 12:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 B0lJW1-yR0v3 for ; Mon, 10 Nov 2014 12:24:48 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 7D4A21ACE61 for ; Mon, 10 Nov 2014 12:23:53 -0800 (PST) Received: from dhcp-b418.meeting.ietf.org (dhcp-b418.meeting.ietf.org [31.133.180.24]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAAKNofX039127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Nov 2014 14:23:51 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <54611ED5.2020809@nostrum.com> Date: Mon, 10 Nov 2014 10:23:49 -1000 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Brett Tate , draft-sparks-sipcore-refer-explicit-subscription@tools.ietf.org, sipcore@ietf.org References: <54610E3E.8030003@nostrum.com> <16c53b2416e5d5ae6e327d9b7d0399ed@mail.gmail.com> In-Reply-To: <16c53b2416e5d5ae6e327d9b7d0399ed@mail.gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/fRJp5T3ghH59Vv3z58w-PjhZsKI Subject: Re: [sipcore] draft-sparks-sipcore-refer-explicit-subscription-02: comments 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, 10 Nov 2014 20:24:51 -0000 On 11/10/14 10:19 AM, Brett Tate wrote: > Hi Robert, > > Thanks for the response; reply is inline. > >>> If something within this draft allows a RFC 6665 compliant notifier to >>> not supply a GRUU Contact within call's dialog, please clearly indicate >>> it. >>> For instance if true, indicate that the notifier is not required to >>> supply a GRUU Contact if notifier supports 'nosub' (even if referrer >>> does not support 'nosub'). >>> >>> Section 6 indicates the following: >>> >>> "The 'explicitsub' and 'nosub' option tags MAY appear in the Supported >>> header field of SIP messages, and in sip.extensions feature tag >>> defined in [RFC3840]. This signals only that the UA including the >>> value is aware of the extensions. In particular, a UA can only >>> invoke the use of one of the extensions in a request. A User-Agent >>> Server (UAS) that is processing a REFER request that lists >>> 'explicitsub' or 'nosub' in its Supported header field and wishes to >>> use one of those extensions will return a 421 response indicating >>> which extension is required. >>> >>> OPEN ISSUE: This description of the use of 421 is not yet perfectly >>> aligned with RFC3261's definition." >>> >>> I think that the open issue should be closed by not mandating the 421 >>> response (at least if REFER was sent within dialog). Similar to the >>> RFC >>> 3262 behavior, the UAS can indicate it is being used by including >>> option-tag within Require header of 2xx response. >> Hi Brett - >> >> I sent text last week proposing how to address this >> (Subject 'Open issue in refer-explicit-subscriptions'). >> Was that text problematic for you? > The proposal continues to mandate that the option-tag only be honored if > received within a Require header of REFER. > > If REFER is received within dialog, mandating that the UAS return a 421 > appears to do nothing but require extra messaging for those attempting to > use it. I recommend allowing behavior similar to RFC 3262 so that the > option tag can be within Supported of mid-dialog REFER and Require of > REFER's 2xx response. We _specifically_ avoided that design. It takes us into the "I don't know if this will create a subscription or not when I send the REFER" territory. You have Supported around _before_ you get to sending the REFER require to help you avoid discovering lack of support by trying to require it if you care about that extra messaging. > > Thanks, > Brett From nobody Mon Nov 10 12:55:08 2014 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 770D61ACEA1 for ; Mon, 10 Nov 2014 12:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iF5thNq2mzdj for ; Mon, 10 Nov 2014 12:55:01 -0800 (PST) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85BA91ACE55 for ; Mon, 10 Nov 2014 12:55:01 -0800 (PST) Received: by mail-qg0-f53.google.com with SMTP id z107so6066133qgd.26 for ; Mon, 10 Nov 2014 12:55:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=q+Rc0vCmb/vHvzRXTaOWCjx/koyWTPmKvU/fxIbm6lk=; b=aAYDdhr3yTfH2ZZPfQvsEuPdtAPMykI1BaTVWvw3I8UKx7L0c4ETi80jtJhd6JtXjJ NaKdMOc0lKbVx1sN45hc1LujlIHSt/gwc//Y6QKDYx/EfmIPxXLxYQioYpmMQHgT+IvV s61QIte0t5jO76f0d1/LdYNhOCVyDNBvHrdGyXOtim8l3oODasyh+3gWj5WKJIIpWpH9 l1Ki2FgKQ7lnOkmm1eNAc/LoapSIB8JpjBptvnBezBCPIm+xGG2tLaUHKSEWUTwot+1I CiVcsAY8t/luhQUNywo8AYhXuOiLUAHqkWEb/fYMs3hr/4f34oAPlz7uTdWJjDFM2nHR nJDA== X-Gm-Message-State: ALoCoQkPwuuwprkIPXwOoUbFhf6bckjwBcLIlbobwlh3IVxud5AmkALRr780xks5Ny0LRJGJyn4d X-Received: by 10.224.137.10 with SMTP id u10mr4804163qat.82.1415652900816; Mon, 10 Nov 2014 12:55:00 -0800 (PST) From: Brett Tate References: <54610E3E.8030003@nostrum.com> <16c53b2416e5d5ae6e327d9b7d0399ed@mail.gmail.com> <54611ED5.2020809@nostrum.com> In-Reply-To: <54611ED5.2020809@nostrum.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFfeN8LiET/kWztblTf6xQUrobKVAGHHR+ZAivDLlwBa0TPDJ0SZfAw Date: Mon, 10 Nov 2014 15:54:57 -0500 Message-ID: To: Robert Sparks , draft-sparks-sipcore-refer-explicit-subscription@tools.ietf.org, sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/hvxMZ_8QfI_3ylXvyYnMEjkFpVo Subject: Re: [sipcore] draft-sparks-sipcore-refer-explicit-subscription-02: comments 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, 10 Nov 2014 20:55:03 -0000 > >> Was that text problematic for you? > > The proposal continues to mandate that the option-tag only be honored > > if received within a Require header of REFER. > > > > If REFER is received within dialog, mandating that the UAS return a > > 421 appears to do nothing but require extra messaging for those > > attempting to use it. I recommend allowing behavior similar to RFC > > 3262 so that the option tag can be within Supported of mid-dialog > > REFER and Require of REFER's 2xx response. > > We _specifically_ avoided that design. It takes us into the "I don't > know if this will create a subscription or not when I send the REFER" >territory. If referrer sends a REFER within dialog without using the Require, they know that it might create a subscription since they don't know if the option-tag is supported. The 2xx response can indicate if it did create a subscription by supplying Require indicating what occurred. If the desire is to allow RFC 6665 compliant device to send REFER over dialog during GRUU situation, they would need to use the Require (AFAIK). I still haven't noticed how the draft avoids RFC 6665 compliant notifier from needing to supply GRUU Contact within call dialog. > You have Supported around _before_ you get to sending the REFER > require to help you avoid discovering lack of support by trying to > require it if you care about that extra messaging. If the REFER was sent within dialog, the lack of support/use would be observed by receiving REFER's 2xx response without Require option-tag. The referrer can use Require when REFER sent outside of dialog (or within dialog if desired) if they want to avoid ambiguity during forking situation. Thanks, Brett From nobody Mon Nov 10 13:19:21 2014 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 699A31A1B15 for ; Mon, 10 Nov 2014 13:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 j8p3y8XP893N for ; Mon, 10 Nov 2014 13:19:17 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 87AA61A1B24 for ; Mon, 10 Nov 2014 13:19:05 -0800 (PST) Received: from dhcp-b418.meeting.ietf.org (dhcp-b418.meeting.ietf.org [31.133.180.24]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAALJ2YN044083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Nov 2014 15:19:02 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <54612BC5.5060201@nostrum.com> Date: Mon, 10 Nov 2014 11:19:01 -1000 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Brett Tate , draft-sparks-sipcore-refer-explicit-subscription@tools.ietf.org, sipcore@ietf.org References: <54610E3E.8030003@nostrum.com> <16c53b2416e5d5ae6e327d9b7d0399ed@mail.gmail.com> <54611ED5.2020809@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/fRDy1AluYqdVRJMVf9MY48dWY2w Subject: Re: [sipcore] draft-sparks-sipcore-refer-explicit-subscription-02: comments 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, 10 Nov 2014 21:19:20 -0000 On 11/10/14 10:54 AM, Brett Tate wrote: >>>> Was that text problematic for you? >>> The proposal continues to mandate that the option-tag only be honored >>> if received within a Require header of REFER. >>> >>> If REFER is received within dialog, mandating that the UAS return a >>> 421 appears to do nothing but require extra messaging for those >>> attempting to use it. I recommend allowing behavior similar to RFC >>> 3262 so that the option tag can be within Supported of mid-dialog >>> REFER and Require of REFER's 2xx response. >> We _specifically_ avoided that design. It takes us into the "I don't >> know if this will create a subscription or not when I send the REFER" >> territory. So, there are two things I think you're trying to talk about. I'm going to draw lines around them just to double-check that I'm hearing you correctly. First is the suggestion to change how we're using Supported/Require. I don't understand yet why you would _want_ to send a REFER with Supported: explicitsub and learn later whether the other side chose to use an implicit subscription or an explicit subscription, signaled in the 200 OK to the REFER. Essentially, you are positing "I don't care as a client, you choose as the server". I don't think we have a need for that, and trying to support something like it is what led norefersub to being what it is. It's even _less_ obvious what the semantic would be if you did this with nosub. When you are in a dialog, you have the opportunity to see that the extension is supported before you start preparing your in-dialog refer by watching Supported in the transactions earlier in the dialog. If your peer hasn't been playing nicely and telling you about what it supports, you can probe by sending the REFER with the require and see the 421. That is not new behavior defined by this draft - it's basic 3261. Our case here is different from 100rel. The semantic there is that the server gets to invoke _using_ the extension because it's the thing that knows whether the extension is needed. It's been a fundamental point of this proposal from the beginning that this is a decision that the client is going to make. > If referrer sends a REFER within dialog without using the Require, they know > that it might create a subscription since they don't know if the option-tag > is supported. The 2xx response can indicate if it did create a subscription > by supplying Require indicating what occurred. > > If the desire is to allow RFC 6665 compliant device to send REFER over > dialog during GRUU situation, they would need to use the Require (AFAIK). If I'm reading you correctly, your second comment is that the draft isn't clear enough that if you are requiring explicitsub (or nosub), the REFER request itself isn't bound by the requirements of 3265 since its contact isn't used in setting up a subscription. I'll go look at the draft between meetings (I'm in other sessions right now), and see if I can pump that up. > > I still haven't noticed how the draft avoids RFC 6665 compliant notifier > from needing to supply GRUU Contact within call dialog. > > >> You have Supported around _before_ you get to sending the REFER >> require to help you avoid discovering lack of support by trying to >> require it if you care about that extra messaging. > If the REFER was sent within dialog, the lack of support/use would be > observed by receiving REFER's 2xx response without Require option-tag. > > The referrer can use Require when REFER sent outside of dialog (or within > dialog if desired) if they want to avoid ambiguity during forking situation. > > Thanks, > Brett From nobody Tue Nov 11 04:39:32 2014 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 771B41A86FC for ; Tue, 11 Nov 2014 04:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjqoKsrlKP74 for ; Tue, 11 Nov 2014 04:39:25 -0800 (PST) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDEF71A1ACF for ; Tue, 11 Nov 2014 04:39:24 -0800 (PST) Received: by mail-qg0-f44.google.com with SMTP id q107so7109664qgd.3 for ; Tue, 11 Nov 2014 04:39:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=nMKlofdk3LLCeSR8RKJBZf5pe+pJZ1zfLv55Hf6MiDY=; b=m0sfdlb5ES9dkkBv1Mxhj/1rmslF8QzqYpnDe63NAhwsy38Xse+JrvqiyBQtzkndvV L7QGQQJpp8InrLH3/+/STneNZsH+C69Sd1JOgTAOFgZcBxpYeso0lSQ5JaWGhGrjwkl2 rYwswvf8MMh/TnyUZtx0Xg4hYaS0N8kr1FWJeqUIljEL48IRq9dTveSLATMrOMfKTS1I GitdnoB2+wuf5k5YNoT8H48s6SyVHXiCgcvOBZKws0SzxkNaguttlV0Eu4gBWcAXM06+ IU9ja6QqYMj04dv6P8WaWD9LW3D85t2gRbhwstNwDQ/sizrnarnefM1/jrukzx990NCN VAvw== X-Gm-Message-State: ALoCoQmKdSKUcKkRUbOeF5f43oUDFE0FC0qPDvwBrrFClQcl4bHx5zrAGx95F98JZnAXjfKSNjtz X-Received: by 10.140.108.182 with SMTP id j51mr50165073qgf.27.1415709563562; Tue, 11 Nov 2014 04:39:23 -0800 (PST) From: Brett Tate References: <54610E3E.8030003@nostrum.com> <16c53b2416e5d5ae6e327d9b7d0399ed@mail.gmail.com> <54611ED5.2020809@nostrum.com> <54612BC5.5060201@nostrum.com> In-Reply-To: <54612BC5.5060201@nostrum.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFfeN8LiET/kWztblTf6xQUrobKVAGHHR+ZAivDLlwBa0TPDAHBTd30AP1Go+Kc/V2lMA== Date: Tue, 11 Nov 2014 07:39:20 -0500 Message-ID: To: draft-sparks-sipcore-refer-explicit-subscription@tools.ietf.org, sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/FZsJYbVTAK3iKcuhyMy5NgeIFb0 Subject: Re: [sipcore] draft-sparks-sipcore-refer-explicit-subscription-02: comments 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, 11 Nov 2014 12:39:29 -0000 Hi, Thanks for the response; reply is inline. > >>>> Was that text problematic for you? > >>> The proposal continues to mandate that the option-tag only be > >>> honored if received within a Require header of REFER. > >>> > >>> If REFER is received within dialog, mandating that the UAS return a > >>> 421 appears to do nothing but require extra messaging for those > >>> attempting to use it. I recommend allowing behavior similar to RFC > >>> 3262 so that the option tag can be within Supported of mid-dialog > >>> REFER and Require of REFER's 2xx response. > >> We _specifically_ avoided that design. It takes us into the "I don't > >> know if this will create a subscription or not when I send the REFER" > >> territory. > So, there are two things I think you're trying to talk about. I'm going > to draw lines around them just to double-check that I'm hearing > you correctly. > > First is the suggestion to change how we're using Supported/Require. > > I don't understand yet why you would _want_ to send a REFER > with Supported: explicitsub and learn later whether the other > side chose to use an implicit subscription or an explicit subscription, > signaled in the 200 OK to the REFER. > > Essentially, you are positing "I don't care as a client, you choose > as the server". I don't think we have a need for that, and trying > to support something like it is what led norefersub to being > what it is. That is not my proposal. If the client cares, they can use Require or not include option-tag within Supported. My proposal is that if the client sent mid-dialog REFER with Supported indicating one or both new option-tags, there is no reason to mandate returning 421 if the UAS desires to use the feature. Why do you want to restrict the functionality so that it can only be used if option-tag sent within REFER's Require header? The working group (and RFC 4485) typically discourages the use of Require within requests unless truly needed. Depending upon interpretation of RFC 4485's "basic SIP services", the use of Require is potentially "NOT RECOMMENDED". > When you are in a dialog, you have the opportunity to see that the > extension > is supported before you start preparing your in-dialog refer by watching > Supported in the transactions earlier in the dialog. If your peer hasn't > been > playing nicely and telling you about what it supports, you can probe by > sending the REFER with the require and see the 421. That is not new > behavior > defined by this draft > - it's basic 3261. I agree. However, it isn't basic SIP to restrict option-tag related functionality to only occur when the request uses the Require header unless there is truly a need for the restriction. > Our case here is different from 100rel. The semantic there is that the > server > gets to invoke _using_ the extension because it's the thing that knows > whether the extension is needed. It's been a fundamental point of this > proposal from the beginning that this is a decision that the client is > going to > make. If they want/have to make the decision, they can use the Require. If they don't want/need to decide, they should be able to use Supported within mid-dialog REFER without requiring the subsequent 421 to occur. > > If referrer sends a REFER within dialog without using the Require, > > they know that it might create a subscription since they don't know if > > the option-tag is supported. The 2xx response can indicate if it did > > create a subscription by supplying Require indicating what occurred. > > > > If the desire is to allow RFC 6665 compliant device to send REFER over > > dialog during GRUU situation, they would need to use the Require > > (AFAIK). > If I'm reading you correctly, your second comment is that the draft isn't > clear > enough that if you are requiring explicitsub (or nosub), the REFER request > itself isn't bound by the requirements of 3265 since its contact isn't > used in > setting up a subscription. I'll go look at the draft between meetings (I'm > in > other sessions right now), and see if I can pump that up. The draft might be adequate from referrer perspective (I didn't perform a detailed search). However as indicated below, I haven't noticed how the draft enables a RFC 6665 compliant notifier from needing to supply GRUU Contact within call dialog (i.e. as mentioned within draft-sparks-sipcore-refer-clarifications-05 section 3 last paragraph). > > I still haven't noticed how the draft avoids RFC 6665 compliant > > notifier from needing to supply GRUU Contact within call dialog. > > > > > >> You have Supported around _before_ you get to sending the REFER > >> require to help you avoid discovering lack of support by trying to > >> require it if you care about that extra messaging. > > If the REFER was sent within dialog, the lack of support/use would be > > observed by receiving REFER's 2xx response without Require option-tag. > > > > The referrer can use Require when REFER sent outside of dialog (or > > within dialog if desired) if they want to avoid ambiguity during forking > situation. > > > > Thanks, > > Brett From nobody Tue Nov 11 07:18:38 2014 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 3BCF21A8A9A for ; Tue, 11 Nov 2014 07:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJAi8GCwKiHN for ; Tue, 11 Nov 2014 07:18:35 -0800 (PST) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78ADF1A8A96 for ; Tue, 11 Nov 2014 07:18:35 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id o8so7872789qcw.10 for ; Tue, 11 Nov 2014 07:18:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=K+hd9TrkdgAbmEQ7xYcrruMqCgDOJcWgUMsmi+9VIhw=; b=IZq9LQlYUju5539vaaakAlnpTBQ9M0bnuUQhEx/ej2kXJxMYKsTyVJa6OTeOsfpw8O vwSE89ABc1eY4jDgxzxvoqKhhGaB5YOEElSVgpl+rK0+Pj53aElP6gsvyXt7Zh6Tgh3j DtA4XMlXKdEnDsOUL9XljSBJfOIV2Kcu5l4G88iL9a5KY+o0XcHkAPYEhH+OgOUTbFIw XgIeoRlhErtyIlnIrZim1ZRt3c047/ztua3JIqGezMzqIzOVtCqa1q3Zq0CvfOLZ9Ape GlZZHhWW2VkxMYpjqybqBN1jD7tUfKde6+6LNHk2zp4H9wutYs+9pD8fMcNNedksVU0H xqjg== X-Gm-Message-State: ALoCoQkZaGRNuXL3/7vXnSPccLGiVgCID3RfVI9pU1AKQm3AL+Ec/Jp4DQR6y3Rtw3msERNTDeSz X-Received: by 10.224.12.145 with SMTP id x17mr53809113qax.13.1415719114558; Tue, 11 Nov 2014 07:18:34 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/9wrQBO4aVruMDQzGXBwSF82K37g== Date: Tue, 11 Nov 2014 10:18:32 -0500 Message-ID: To: sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/t4fg5dTMIFrwW9LVdupUb97iJKo Subject: [sipcore] draft-roach-sipcore-6665-clarification-00: comment 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, 11 Nov 2014 15:18:37 -0000 Hi, Draft-roach-sipcore-6665-clarification-00 section 3 indicates the following: This document updates [RFC6665] to clarify the actual requirement: "Notifiers MUST implement the Globally Routable User Agent URI (GRUU) extension defined in [RFC5627], and MUST use a GRUU as their local target for all dialog-forming methods and all target-refresh methods. This specifically includes dialogs created by the INVITE method." Similar to my draft-sparks-sipcore-refer-clarifications-04 comment, it is hard to not recommend that the following be added as the next paragraph. ;) "The mandate ensures that GRUU and the related patents are applicable to as many devices as possible. At least one Patent Holder states that its position with respect to licensing any patent claims contained in the disclosed patent would necessarily be infringed by implementation of the technology required by the relevant IETF specification, for the purpose of implementing such specification, is as follows: Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee." https://datatracker.ietf.org/ipr/1832/ https://datatracker.ietf.org/ipr/1226/ Cheers, Brett From nobody Tue Nov 11 09:30:14 2014 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 E86D81A00E9 for ; Tue, 11 Nov 2014 09:30:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 pEd_9LIias-K for ; Tue, 11 Nov 2014 09:30:11 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A23971A00E4 for ; Tue, 11 Nov 2014 09:30:11 -0800 (PST) Received: from dhcp-8a99.meeting.ietf.org (dhcp-8a99.meeting.ietf.org [31.133.138.153]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sABHU7Zr049087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Nov 2014 11:30:08 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <546247A1.5090905@nostrum.com> Date: Tue, 11 Nov 2014 07:30:09 -1000 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Brett Tate , sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Zevk0tHZOpE3lUeEGM-3qLkI4x0 Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment 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, 11 Nov 2014 17:30:13 -0000 On 11/11/14 05:18, Brett Tate wrote: > "The mandate ensures that GRUU and the related patents are applicable to > as many devices as possible..." > I'm sympathetic to the point you're trying to make, but the fact of the matter is that this space is already rife with claims of IPR applicablity; for example: https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=3261 /a From nobody Wed Nov 12 07:25:47 2014 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 0EB421A1AC6 for ; Wed, 12 Nov 2014 07:25: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 LSpWN6YJzIuB for ; Wed, 12 Nov 2014 07:25: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 C440E1A1B18 for ; Wed, 12 Nov 2014 07:25:38 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-8b-54637bf06015 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 2A.90.24955.0FB73645; Wed, 12 Nov 2014 16:25:36 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.4]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0174.001; Wed, 12 Nov 2014 16:25:36 +0100 From: Ivo Sedlacek To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: Comments to draft-sparks-sipcore-refer-clarifications-05.txt Thread-Index: AQHP+f7mGM+M7RbfTpKpZBAgcDmyYJxdIHtQ Date: Wed, 12 Nov 2014 15:25:35 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061011278D7C3@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101127852C3@ESESSMB301.ericsson.se> <545BD7B4.1090509@nostrum.com> In-Reply-To: <545BD7B4.1090509@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.16] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B310790061011278D7C3ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyM+Jvje6H6uQQg8Xv9SyuzWlks/j6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJWxadYZxoJnS5gqHty8y9rAOGEuUxcjJ4eE gInEm/6nULaYxIV769m6GLk4hASOMEo86PjPDuEsYpRYeWgmM0gVm4CexMQtR1hBbBGBQImF k5awgNjCAp4Sh18cYIeIe0nsP7WDBcI2kjiyayEjiM0ioCrxcuUCNhCbV8BX4smBb2BxIYE8 iY4LEPM5BbQlVkx9AjaHUUBW4uqfXrAaZgFxiVtP5kNdKiCxZM95ZghbVOLl43+sELaixM6z 7UBxDqD6fIkPv5QgVglKnJz5hGUCo8gsJJNmIVTNQlIFEdaUWL9LH6JaUWJK90N2CFtDonXO XHZk8QWM7KsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAuPq4JbfqjsYL79xPMQowMGoxMNr cDYpRIg1say4MvcQozQHi5I478Jz84KFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MHqf/ta9 YcEHEVHWtw6fbttv+7W5WF3df5mEjLpxwA2R7UVJi3561cvWLJ4iz7uQJf3LNGXXVzIL9HIj pouzrJny8f+nbfcPZXTmFzXa+7967jwtc/5q9aXOmwr+fszdZ/D+mF9arc5GY63nAjIitz5s Yi74yPWt/VHClKJZjTum+2jdf5v0W1aJpTgj0VCLuag4EQBrTeh2jAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/jL3FY-AXh_AFuJ8Xq8bNn_osBH4 Subject: Re: [sipcore] Comments to draft-sparks-sipcore-refer-clarifications-05.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: Wed, 12 Nov 2014 15:25:44 -0000 --_000_39B5E4D390E9BD4890E2B310790061011278D7C3ESESSMB301erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gUm9iZXJ0LA0KDQpwbGVhc2Ugc2VlIGJlbG93Lg0KDQoNCg0KQ09NTUVOVCAxOg0KDQot LS0tLS0tLS0tLS0tLS0tLS0NCg0KQWJzdHJhY3Qgc3RhdGVzICJBbiBhY2NlcHRlZCBTSVAgUkVG RVIgbWV0aG9kIGNyZWF0ZXMgYW4gaW1wbGljaXQgc3Vic2NyaXB0aW9uIHVzaW5nIHRoZSBTSVAt U3BlY2lmaWMgRXZlbnQgTm90aWZpY2F0aW9uIEZyYW1ld29yay4iDQoNCg0KDQpUaGlzIGlzIG9u bHkgcGFydGx5IHRydWUgc2luY2UgY3JlYXRpb24gb2YgaW1wbGljaXQgc3Vic2NyaXB0aW9uIGRv IG5vdCBuZWNlc3NhcmlseSBoYXBwZW4gd2hlbiBkcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1l eHBsaWNpdC1zdWJzY3JpcHRpb24gaXMgdXNlZCBvciB3aGVuIFJGQzQ0ODggaXMgdXNlZCAoYXNz dW1pbmcgYXBwbGljYXRpb24gc3BlY2lmaWMgbG9naWMgZW5zdXJlcyB0aGF0IHRoZSBpbXBsaWNp dCBzdWJzY3JpcHRpb24gaXMgbm90IGNyZWF0ZWQpLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0NCg0K DQoNClBST1BPU0VEIFNPTFVUSU9OIDE6DQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpTdGF0ZTog IkFuIGFjY2VwdGVkIFNJUCBSRUZFUiBtZXRob2QgPj5jYW48PCBjcmVhdGUgYW4gaW1wbGljaXQg c3Vic2NyaXB0aW9uIHVzaW5nIHRoZSBTSVAtU3BlY2lmaWMgRXZlbnQgTm90aWZpY2F0aW9uIEZy YW1ld29yay4iDQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KSHJtbSAtIHRoaXMgaXMgZWZmZWN0aXZl bHkgdGhlIHNhbWUgZmVlZGJhY2sgeW91IHNlbnQgZWFybGllciBvbiBzZW50ZW5jZXMgbGlrZSB0 aGlzIGluIHRoZSBkb2N1bWVudCAoYnV0IHRoYW5rcyBmb3IgdGhlIGNsZWFuZXIgcHJvcG9zZWQg dGV4dCkuDQoNCk15IHJlc3BvbnNlIHRoZW4gKGFuZCBub3cpIGlzIHRoYXQgYWNjb3VudGluZyBm b3IgdGhlIG9uZSBjYXNlIHdoZXJlIHlvdSBjYW4gYXNrIChidXQgbm90IGJlIGd1YXJhbnRlZWQp DQp0byBzdXBwcmVzcyB0aGUgc3Vic2NyaXB0aW9uIGRvZXNuJ3QgaGVscCB3aXRoIHRoZSBjbGFy aXR5IG9mIHRoaXMgZG9jdW1lbnQuDQoNCg0KW0l2b10NClRoZSBkb2N1bWVudCBuZWVkcyB0byBi ZSBjb3JyZWN0IGFzIHdlbGwgYXMgY2xlYXIuDQoNCk9taXR0aW5nIHRoZSBvbmUgY2FzZSByZXN1 bHRzIHRvIGluY29ycmVjdCBkb2N1bWVudC4NCg0KVG8gbWUsIHlvdXIgc3RhdGVtZW50ICIuLi4u IGRvZXNuJ3QgaGVscCB3aXRoIHRoZSBjbGFyaXR5IG9mIHRoaXMgZG9jdW1lbnQuIiBpcyBjb21w YXJhYmxlIHdpdGggYSBqdWRnZSBzdGF0aW5nIHRvIGFuIGFjY3VzZWQ6ICJUaGVyZSBpcyBvbmUg cG9zc2liaWxpdHkgdGhhdCB5b3UgYXJlIGlubm9jZW50LiBIb3dldmVyLCBkZXNjcmliaW5nIGl0 IGluIGp1ZGdlbWVudCBkb2Vzbid0IGhlbHAgd2l0aCB0aGUgY2xhcml0eSBvZiB0aGUganVkZ2Vt ZW50LiBTbywgSSBkZWNsYXJlIHlvdSBndWlsdHkgaW5zdGVhZC4iLg0KDQoNCkknZCBsaWtlIHRv IGhlYXIgZnJvbSBvdGhlcnMgaW4gdGhlIGdyb3VwLg0KRG8geW91IHdhbnQgdG8gZmluZCBhIHdh eSB0byBjYWxsIG91dCB0aGlzIGNhc2UsIG9yIGxlYXZlIHRoZSB0ZXh0IGFzIGlzPw0KSSB3b3Vs ZCBwcmVmZXIgdG8gbGVhdmUgdGhlIHRleHQgYWxvbmUuDQpJZiB3ZSBjaGFuZ2UgaXQsIEkgZG9u J3QgdGhpbmsgdGhpcyBwcm9wb3NhbCBpcyB0aGUgcmlnaHQgb25lIHlldC4gIkNhbiIgdW5kZXJz dGF0ZXMgdGhlIGlzc3VlIHNpZ25pZmljYW50bHkuDQoNCg0KDQpDT01NRU5UIDI6DQoNCi0tLS0t LS0tLS0tLS0tLS0tLQ0KDQpTZWN0aW9uIDIgc3RhdGVzICJBbiBhY2NlcHRlZCBTSVAgUkVGRVIg bWV0aG9kIGNyZWF0ZXMgYW4gaW1wbGljaXQgc3Vic2NyaXB0aW9uIHVzaW5nIHRoZSBTSVAtU3Bl Y2lmaWMgRXZlbnQgTm90aWZpY2F0aW9uIEZyYW1ld29yay4iDQoNCg0KDQpUaGlzIGlzIG9ubHkg cGFydGx5IHRydWUgc2luY2UgY3JlYXRpb24gb2YgaW1wbGljaXQgc3Vic2NyaXB0aW9uIGRvIG5v dCBuZWNlc3NhcmlseSBoYXBwZW4gd2hlbiBkcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1leHBs aWNpdC1zdWJzY3JpcHRpb24gaXMgdXNlZCBvciB3aGVuIFJGQzQ0ODggaXMgdXNlZCAoYXNzdW1p bmcgYXBwbGljYXRpb24gc3BlY2lmaWMgbG9naWMgZW5zdXJlcyB0aGF0IHRoZSBpbXBsaWNpdCBz dWJzY3JpcHRpb24gaXMgbm90IGNyZWF0ZWQpLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoN ClBST1BPU0VEIFNPTFVUSU9OIDI6DQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpTdGF0ZTogIkFu IGFjY2VwdGVkIFNJUCBSRUZFUiBtZXRob2QgPj5jYW48PCBjcmVhdGUgYW4gaW1wbGljaXQgc3Vi c2NyaXB0aW9uIHVzaW5nIHRoZSBTSVAtU3BlY2lmaWMgRXZlbnQgTm90aWZpY2F0aW9uIEZyYW1l d29yay4iDQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KU2FtZSBhcyAxOg0KDQoNCltJdm9dDQoNClNh bWUgYXMgMToNCg0KDQoNCg0KDQpDT01NRU5UIDM6DQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpT ZWN0aW9uIDMgc3RhdGVzICINCg0KICAgU2VjdGlvbiA0LjUuMSBvZiBbUkZDNjY2NV0gbWFrZXMg R1JVVSBbUkZDNTYyN10gbWFuZGF0b3J5IHRvDQoNCiAgIGltcGxlbWVudCBhbmQgdXNlIGFzIHRo ZSBsb2NhbCB0YXJnZXQgaW4gdGhlIHN1YnNjcmlwdGlvbiBjcmVhdGVkIGJ5DQoNCiAgIHRoZSBS RUZFUiByZXF1ZXN0Lg0KDQoiDQoNCg0KDQpJbiBSRkM2NjY1LCB1c2FnZSBvZiBHUlVVIGlzIG1h bmRhdG9yeSBmb3Igbm90aWZpZXIgKCI+Pk5vdGlmaWVyczw8IE1VU1QgaW1wbGVtZW50IHRoZSBH bG9iYWxseSBSb3V0YWJsZSBVc2VyIEFnZW50IFVSSSAoR1JVVSkgZXh0ZW5zaW9uIGRlZmluZWQg aW4gW1JGQzU2MjddLCBhbmQgTVVTVCB1c2UgYSBHUlVVIGFzIHRoZWlyIGxvY2FsIHRhcmdldC4i KSwgd2hpbGUgdGhlIHN0YXRlbWVudCBhYm92ZSBjb3VsZCBiZSB1bmRlcnN0b29kIHRvIHJlZmVy IHRvIGJvdGggc3Vic2NyaWJlciBhbmQgbm90aWZpZXIuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0K SSB0aGluayBBZGFtIHRyaWVkIHRvIGFkZHJlc3MgdGhpcyBpbiBhbiBlYXJsaWVyIHJlc3BvbnNl LiBUaGUgbmV3IDY2NjUgY2xhcmlmaWNhdGlvbnMgZHJhZnQgbWF5IGFkZHJlc3MgaXQgbW9yZSBz dHJvbmdseS4NCg0KW0l2b10NCiJUaGUgbmV3IDY2NjUgY2xhcmlmaWNhdGlvbnMgZHJhZnQgbWF5 IGFkZHJlc3MgaXQgbW9yZSBzdHJvbmdseS4iIHNlZW1zIHRvIHN1Z2dlc3QgdGhhdCB0aGUgY29t bWVudCBhYm92ZSBpcyBhY3R1YWxseSBjb3JyZWN0LCBpLmUuIFJGQzY2NSBkb2VzIG5vdCBjb250 YWluIHN1Y2ggc3RhdGVtZW50LCBhbmQgbmV3IDY2NjUgY2xhcmlmaWNhdGlvbnMgZHJhZnQgIGlz IG5lY2Vzc2FyeSB0byBtYWtlIGl0Lg0KDQoNCg0KDQpQUk9QT1NFRCBTT0xVVElPTiAzOg0KDQot LS0tLS0tLS0tLS0tLS0tLS0NCg0KU3RhdGU6ICINCg0KICAgU2VjdGlvbiA0LjUuMSBvZiBbUkZD NjY2NV0gbWFrZXMgR1JVVSBbUkZDNTYyN10gbWFuZGF0b3J5IHRvDQoNCiAgIGltcGxlbWVudCBh bmQgdXNlIGFzIHRoZSBsb2NhbCB0YXJnZXQgPj5ieSBub3RpZmllcnM8PCBpbiB0aGUgc3Vic2Ny aXB0aW9uIGNyZWF0ZWQgYnkNCg0KICAgdGhlIFJFRkVSIHJlcXVlc3QuDQoNCiINCg0KLS0tLS0t LS0tLS0tLS0tLS0tDQoNCg0KDQpDT01NRU5UIDQ6DQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpT ZWN0aW9uIDMgc3RhdGVzICINCg0KICAgQSBVQSB0aGF0IHdpbGwgYWNjZXB0IGEgUkVGRVIgcmVx dWVzdCBuZWVkcyB0byBpbmNsdWRlIGEgR1JVVSBpbiB0aGUNCg0KICAgQ29udGFjdCBoZWFkZXIg ZmllbGQgb2YgYWxsIElOVklURSByZXF1ZXN0cy4gIFRoaXMgZW5zdXJlcyB0aGF0IG91dC0NCg0K ICAgb2YtZGlhbG9nIFJFRkVSIHJlcXVlc3RzIGNvcnJlc3BvbmRpbmcgdG8gYW55IHJlc3VsdGlu ZyBJTlZJVEUNCg0KICAgZGlhbG9ncyBhcnJpdmUgYXQgdGhpcyBVQS4gIEZ1dHVyZSBleHRlbnNp b25zIChzdWNoIGFzDQoNCiAgIFtJLUQuc3BhcmtzLXNpcGNvcmUtcmVmZXItZXhwbGljaXQtc3Vi c2NyaXB0aW9uXSkgbWlnaHQgcmVsYXggdGhpcw0KDQogICByZXF1aXJlbWVudCBieSBkZWZpbmlu ZyBhIFJFRkVSIHJlcXVlc3QgdGhhdCBjYW5ub3QgY3JlYXRlIGFuDQoNCiAgIGltcGxpY2l0IHN1 YnNjcmlwdGlvbi4NCg0KIg0KDQoNCg0KVGhlIFVBIG1pZ2h0IGJlIGdsb2JhbGx5IHJlYWNoYWJs ZSB3aXRob3V0IGluZGljYXRpbmcgR1JVVSAtIHRoaXMgaXMgY29tbW9uIHRvZGF5IHdpdGggbmV0 d29yayBjb25mZXJlbmNlIHNlcnZlcnMuIFJlcXVpcmluZyBHUlVVIGlzIHVubmVjZXNzYXJ5Lg0K DQotLS0tLS0tLS0tLS0tLS0tLS0NCkFnYWluLCBzZWUgQWRhbSdzIDY2NjUgY2xhcmlmaWNhdGlv bnMgZHJhZnQgKGFuZCBwbGVhc2UgdGFrZSBhbnkgYXJndW1lbnQgd2l0aCBpdCB0byB0aGUgbGlz dCB1bmRlciB0aGF0IG5hbWUgYXMgYSBzdWJqZWN0LCBub3QgdGhpcyBkcmFmdCkuDQoNCltJdm9d DQpXZWxsLCB0aGlzIGRyYWZ0IHN0YXRlcyB0aGlzIHJlcXVpcmVtZW50IGFuZCB0aGVyZWZvcmUg aXQgY2FuIGJlIHF1ZXN0aW9uZWQuDQoNClllcywgdGhlIHNhbWUgY29tbWVudHMgY2FuIGJlIHJh aXNlZCBhZ2FpbnN0IHRoZSAiNjY2NSBjbGFyaWZpY2F0aW9ucyBkcmFmdCIgYnV0IHRoYXQgZG9l cyBub3QgbWFrZSB0aGlzIGRvY3VtZW50IGNvcnJlY3QuDQoNCg0KDQoNClBST1BPU0VEIFNPTFVU SU9OIDQ6DQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpNYWtlIHRoZSBzdGF0ZW1lbnQgZ2VuZXJh bCB0byBzdGF0ZSB0aGF0IHRoZSBVQSBtdXN0IHByb3ZpZGUgVVJJIHdoaWNoIGlzIGEgZ2xvYmFs bHkgcmVhY2hhYmxlIGluIHRoZSBDb250YWN0IG9mIElOVklURSByZXF1ZXN0cy4NCg0KLS0tLS0t LS0tLS0tLS0tLS0tDQoNCg0KDQpDT01NRU5UIDU6DQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpT ZWN0aW9uIDQsIDFzdCBwYXJhZ3JhcGggYW5kIDJuZCBwYXJhZ3JhcGggcHJvdmlkZSBvdmVybGFw cGluZyBpbmZvcm1hdGlvbi4NCg0KDQoNCkluIDFzdCBwYXJhZ3JhcGgsIHRoZXJlIGlzIGEgc3Rh dGVtZW50IHRoYXQgaWYgcmVtb3RlIFVBIHByb3ZpZGVkIGEgR1JVVSBhcyBpdHMgbG9jYWwgdGFy Z2V0IHRoZW4gYSB1c2VyIGFnZW50IHNlbmRpbmcgYSBSRUZFUiByZXF1ZXN0ICh0b3dhcmRzIHRo YXQgdGFyZ2V0KSB0aGF0IGNvdWxkIHJlc3VsdCBpbiBhbiAgaW1wbGljaXQgc3Vic2NyaXB0aW9u IHdpdGhpbiBhIGRpYWxvZyBpcyBwcm9oaWJpdGVkLg0KDQoNCg0KSW4gMm5kIHBhcmFncmFwaCwg dGhlIHNhbWUgaXMgc3RhdGVkIChpbiBwb3NpdGl2ZSB3YXkpIHJlZ2FyZGxlc3Mgd2hldGhlciB0 aGUgcmVtb3RlIFVBIHByb3ZpZGVkIGEgR1JVVSBhcyBpdHMgbG9jYWwgdGFyZ2V0IG9yIG5vdC4N Cg0KLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KDQpQUk9QT1NFRCBTT0xVVElPTiA1Og0KDQotLS0t LS0tLS0tLS0tLS0tLS0NCg0KUmVtb3ZlIHRoZSAxc3QgcGFyYWdyYXBoIG9mIHNlY3Rpb24gNC4N Cg0KLS0tLS0tLS0tLS0tLS0tLS0tDQpJIGNhbiBhbG1vc3Qgc2VlIHRoZSBvdmVybGFwIHlvdSBh cmUgdGFsa2luZyBhYm91dCwgYnV0IEkgZG9uJ3Qgc2VlIHdoZXJlIHRoYXQgaW50cm9kdWNlcyBh bnkgd2Vha25lc3MgaW50byB0aGUgdGV4dC4NClJlbW92aW5nIHRoZSBwYXJhZ3JhcGggaXMgbm90 IHRoZSByaWdodCB0aGluZyB0byBkby4gVGhlIGZpcnN0IHBhcmFncmFwaCBkZXNjcmliZXMgdGhl IHByb2hpYml0aW9uLCB0aGUgc2Vjb25kIHRhbGtzDQphYm91dCB3aGF0J3MgbGVmdCB0aGF0IHlv dSBjYW4gZG8uIFRoZSBkb2N1bWVudCBpcyBsZXNzIGFjY3VyYXRlIGlmIHlvdSBsZWF2ZSBlaXRo ZXIgcG9pbnQgb3V0Lg0KDQpbSXZvXQ0KVGhlIHRleHQgaXMgaW5jb25zaXN0ZW50Lg0KDQpUaGUg cmVhZGVyIHdpbGwgd29uZGVyIHdoeToNCi0gdGhlIDFzdCBwYXJhZ3JhcGggcHJvaGliaXRzIGRp YWxvZyByZXVzZSBpZiB0aGUgcmVtb3RlIFVFIHByb3ZpZGVkIEdSVVU7IGFuZA0KLSB0aGUgMm5k IHBhcmFncmFwaCByZXF1aXJlcyBvdXQtb2YtZGlhbG9nIFJFRkVSIHJlZ2FyZGxlc3Mgb2Ygd2hl dGhlciB0aGUgcmVtb3RlIFVFIHByb3ZpZGVkIEdSVVUuDQoNCg0KDQoNCg0KQ09NTUVOVCA2Og0K DQotLS0tLS0tLS0tLS0tLS0tLS0NCg0KU2VjdGlvbiAzIHN0YXRlczogIg0KDQogICBBIHVzZXIg YWdlbnQgY29uc3RydWN0aW5nIGFueSBSRUZFUiB0aGF0IGNhbiByZXN1bHQgaW4gYW4gaW1wbGlj aXQNCg0KICAgc3Vic2NyaXB0aW9uIE1VU1QgcG9wdWxhdGUgaXRzIENvbnRhY3QgaGVhZGVyIGZp ZWxkIHdpdGggYSBHUlVVLg0KDQoiDQoNCg0KDQpJbiBSRkM2NjUsIHRoZXJlIGlzIG5vIHN1Y2gg cmVxdWlyZW1lbnQgZm9yIHN1YnNjcmliZXIuIFdoeSBkbyB3ZSBzdGF0ZSBzdWNoIG5ldyByZXF1 aXJlbWVudD8NCg0KLS0tLS0tLS0tLS0tLS0tLS0tDQpTZWUgQWRhbSdzIGVhcmxpZXIgcmVzcG9u c2UgYW5kIHRoZSA2NjY1IGNsYXJpZmljYXRpb25zIGRyYWZ0Lg0KDQpbSXZvXSBBZ2FpbiwgdGhp cyBkb2N1bWVudCByZWZlcnMgdG8gUkZDNjY2NSBhbmQgUkZDNjY2NSBkb2VzIG5vdCBzdGF0ZSBp dC4NCg0KDQoNClBST1BPU0VEIFNPTFVUSU9OIDY6DQoNCi0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpD bGFyaWZ5IHRoZSBuZWVkIGZvciB0aGlzIHJlcXVpcmVtZW50IG9yIHJlbW92ZSBpdC4NCg0KLS0t LS0tLS0tLS0tLS0tLS0tDQoNCg0KDQpLaW5kIHJlZ2FyZHMNCg0KDQoNCkl2byBTZWRsYWNlaw0K DQo= --_000_39B5E4D390E9BD4890E2B310790061011278D7C3ESESSMB301erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1Bs YWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0 ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28t c3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6Izk4NDgw Njt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hp dGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiM5ODQ4MDYiPkhlbGxvIFJvYmVydCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5 ODQ4MDYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk4NDgwNiI+cGxlYXNlIHNlZSBiZWxv dy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q09NTUVOVCAxOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS0tLS0tLS0tLS0tLS0tPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BYnN0cmFjdCBzdGF0ZXMgJnF1 b3Q7QW4gYWNjZXB0ZWQgU0lQIFJFRkVSIG1ldGhvZCBjcmVhdGVzIGFuIGltcGxpY2l0IHN1YnNj cmlwdGlvbiB1c2luZyB0aGUgU0lQLVNwZWNpZmljIEV2ZW50IE5vdGlmaWNhdGlvbiBGcmFtZXdv cmsuJnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoaXMgaXMgb25seSBwYXJ0 bHkgdHJ1ZSBzaW5jZSBjcmVhdGlvbiBvZiBpbXBsaWNpdCBzdWJzY3JpcHRpb24gZG8gbm90IG5l Y2Vzc2FyaWx5IGhhcHBlbiB3aGVuIGRyYWZ0LXNwYXJrcy1zaXBjb3JlLXJlZmVyLWV4cGxpY2l0 LXN1YnNjcmlwdGlvbiBpcyB1c2VkIG9yIHdoZW4gUkZDNDQ4OCBpcyB1c2VkIChhc3N1bWluZyBh cHBsaWNhdGlvbiBzcGVjaWZpYyBsb2dpYyBlbnN1cmVzIHRoYXQgdGhlIGltcGxpY2l0DQogc3Vi c2NyaXB0aW9uIGlzIG5vdCBjcmVhdGVkKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPi0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5QUk9QT1NFRCBTT0xVVElPTiAxOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+LS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5TdGF0ZTogJnF1b3Q7QW4gYWNjZXB0ZWQgU0lQIFJFRkVSIG1ldGhvZCAmZ3Q7Jmd0 O2NhbiZsdDsmbHQ7IGNyZWF0ZSBhbiBpbXBsaWNpdCBzdWJzY3JpcHRpb24gdXNpbmcgdGhlIFNJ UC1TcGVjaWZpYyBFdmVudCBOb3RpZmljYXRpb24gRnJhbWV3b3JrLiZxdW90OzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPkhybW0gLSB0aGlzIGlzIGVmZmVjdGl2ZWx5IHRoZSBzYW1lIGZl ZWRiYWNrIHlvdSBzZW50IGVhcmxpZXIgb24gc2VudGVuY2VzIGxpa2UgdGhpcyBpbiB0aGUgZG9j dW1lbnQgKGJ1dCB0aGFua3MgZm9yIHRoZSBjbGVhbmVyIHByb3Bvc2VkIHRleHQpLjxicj4NCjxi cj4NCk15IHJlc3BvbnNlIHRoZW4gKGFuZCBub3cpIGlzIHRoYXQgYWNjb3VudGluZyBmb3IgdGhl IG9uZSBjYXNlIHdoZXJlIHlvdSBjYW4gYXNrIChidXQgbm90IGJlIGd1YXJhbnRlZWQpPGJyPg0K dG8gc3VwcHJlc3MgdGhlIHN1YnNjcmlwdGlvbiBkb2Vzbid0IGhlbHAgd2l0aCB0aGUgY2xhcml0 eSBvZiB0aGlzIGRvY3VtZW50Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6Izk4NDgwNiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTg0ODA2Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiM5ODQ4MDYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk4NDgwNiI+ W0l2b108bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5ODQ4MDYiPlRoZSBkb2N1bWVudCBuZWVkcyB0byBi ZSBjb3JyZWN0IGFzIHdlbGwgYXMgY2xlYXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTg0ODA2Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5ODQ4MDYiPk9taXR0aW5nIHRoZSBvbmUgY2FzZSBy ZXN1bHRzIHRvIGluY29ycmVjdCBkb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5ODQ4MDYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk4NDgwNiI+VG8gbWUsIHlvdXIgc3RhdGVtZW50 ICZxdW90Oy4uLi4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPmRvZXNu J3QgaGVscCB3aXRoIHRoZSBjbGFyaXR5IG9mIHRoaXMgZG9jdW1lbnQuPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk4NDgwNiI+JnF1b3Q7IGlzIGNvbXBhcmFibGUgd2l0 aCBhIGp1ZGdlIHN0YXRpbmcgdG8gYW4gYWNjdXNlZDoNCiAmcXVvdDtUaGVyZSBpcyBvbmUgcG9z c2liaWxpdHkgdGhhdCB5b3UgYXJlIGlubm9jZW50LiBIb3dldmVyLCBkZXNjcmliaW5nIGl0IGlu IGp1ZGdlbWVudCBkb2Vzbid0IGhlbHAgd2l0aCB0aGUgY2xhcml0eSBvZiB0aGUganVkZ2VtZW50 LiBTbywgSSBkZWNsYXJlIHlvdSBndWlsdHkgaW5zdGVhZC4mcXVvdDsuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij48YnI+DQo8YnI+DQpJJ2QgbGlrZSB0byBoZWFyIGZyb20gb3RoZXJzIGluIHRoZSBncm91 cC4gPGJyPg0KRG8geW91IHdhbnQgdG8gZmluZCBhIHdheSB0byBjYWxsIG91dCB0aGlzIGNhc2Us IG9yIGxlYXZlIHRoZSB0ZXh0IGFzIGlzPzxicj4NCkkgd291bGQgcHJlZmVyIHRvIGxlYXZlIHRo ZSB0ZXh0IGFsb25lLjxicj4NCklmIHdlIGNoYW5nZSBpdCwgSSBkb24ndCB0aGluayB0aGlzIHBy b3Bvc2FsIGlzIHRoZSByaWdodCBvbmUgeWV0LiAmcXVvdDtDYW4mcXVvdDsgdW5kZXJzdGF0ZXMg dGhlIGlzc3VlIHNpZ25pZmljYW50bHkuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q09NTUVOVCAyOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TZWN0aW9uIDIgc3RhdGVzICZxdW90O0FuIGFj Y2VwdGVkIFNJUCBSRUZFUiBtZXRob2QgY3JlYXRlcyBhbiBpbXBsaWNpdCBzdWJzY3JpcHRpb24g dXNpbmcgdGhlIFNJUC1TcGVjaWZpYyBFdmVudCBOb3RpZmljYXRpb24gRnJhbWV3b3JrLiZxdW90 OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGlzIGlzIG9ubHkgcGFydGx5IHRydWUg c2luY2UgY3JlYXRpb24gb2YgaW1wbGljaXQgc3Vic2NyaXB0aW9uIGRvIG5vdCBuZWNlc3Nhcmls eSBoYXBwZW4gd2hlbiBkcmFmdC1zcGFya3Mtc2lwY29yZS1yZWZlci1leHBsaWNpdC1zdWJzY3Jp cHRpb24gaXMgdXNlZCBvciB3aGVuIFJGQzQ0ODggaXMgdXNlZCAoYXNzdW1pbmcgYXBwbGljYXRp b24gc3BlY2lmaWMgbG9naWMgZW5zdXJlcyB0aGF0IHRoZSBpbXBsaWNpdA0KIHN1YnNjcmlwdGlv biBpcyBub3QgY3JlYXRlZCkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UFJPUE9T RUQgU09MVVRJT04gMjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0t LS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ U3RhdGU6ICZxdW90O0FuIGFjY2VwdGVkIFNJUCBSRUZFUiBtZXRob2QgJmd0OyZndDtjYW4mbHQ7 Jmx0OyBjcmVhdGUgYW4gaW1wbGljaXQgc3Vic2NyaXB0aW9uIHVzaW5nIHRoZSBTSVAtU3BlY2lm aWMgRXZlbnQgTm90aWZpY2F0aW9uIEZyYW1ld29yay4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5TYW1l IGFzIDE6PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5ODQ4MDYiPltJdm9dPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5ODQ4 MDYiPlNhbWUgYXMgMTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5ODQ4MDYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q09NTUVOVCAzOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TZWN0aW9uIDMgc3RhdGVzICZxdW90OzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFNlY3Rpb24g NC41LjEgb2YgW1JGQzY2NjVdIG1ha2VzIEdSVVUgW1JGQzU2MjddIG1hbmRhdG9yeSB0bzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGltcGxlbWVu dCBhbmQgdXNlIGFzIHRoZSBsb2NhbCB0YXJnZXQgaW4gdGhlIHN1YnNjcmlwdGlvbiBjcmVhdGVk IGJ5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsg dGhlIFJFRkVSIHJlcXVlc3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SW4gUkZDNjY2NSwgdXNhZ2Ug b2YgR1JVVSBpcyBtYW5kYXRvcnkgZm9yIG5vdGlmaWVyICgmcXVvdDsmZ3Q7Jmd0O05vdGlmaWVy cyZsdDsmbHQ7IE1VU1QgaW1wbGVtZW50IHRoZSBHbG9iYWxseSBSb3V0YWJsZSBVc2VyIEFnZW50 IFVSSSAoR1JVVSkgZXh0ZW5zaW9uIGRlZmluZWQgaW4gW1JGQzU2MjddLCBhbmQgTVVTVCB1c2Ug YSBHUlVVIGFzIHRoZWlyIGxvY2FsIHRhcmdldC4mcXVvdDspLCB3aGlsZSB0aGUgc3RhdGVtZW50 IGFib3ZlIGNvdWxkDQogYmUgdW5kZXJzdG9vZCB0byByZWZlciB0byBib3RoIHN1YnNjcmliZXIg YW5kIG5vdGlmaWVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0t LS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkkgdGhpbmsgQWRhbSB0cmllZCB0byBhZGRyZXNz IHRoaXMgaW4gYW4gZWFybGllciByZXNwb25zZS4gVGhlIG5ldyA2NjY1IGNsYXJpZmljYXRpb25z IGRyYWZ0IG1heSBhZGRyZXNzIGl0IG1vcmUgc3Ryb25nbHkuPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjojOTg0ODA2Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5ODQ4 MDYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk4NDgwNiI+W0l2b10NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6Izk4NDgwNiI+JnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+VGhlIG5ldyA2NjY1IGNsYXJpZmljYXRpb25zIGRyYWZ0IG1heSBhZGRyZXNzIGl0IG1v cmUgc3Ryb25nbHkuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk4NDgw NiI+JnF1b3Q7DQogc2VlbXMgdG8gc3VnZ2VzdCB0aGF0IHRoZSBjb21tZW50IGFib3ZlIGlzIGFj dHVhbGx5IGNvcnJlY3QsIGkuZS4gUkZDNjY1IGRvZXMgbm90IGNvbnRhaW4gc3VjaCBzdGF0ZW1l bnQsIGFuZA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+bmV3IDY2NjUg Y2xhcmlmaWNhdGlvbnMgZHJhZnQNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiM5ODQ4MDYiPiZuYnNwO2lzIG5lY2Vzc2FyeSB0byBtYWtlIGl0Ljwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiM5ODQ4MDYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+UFJPUE9TRUQgU09MVVRJT04gMzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPi0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+U3RhdGU6ICZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IFNlY3Rpb24gNC41LjEgb2YgW1JGQzY2NjVdIG1ha2Vz IEdSVVUgW1JGQzU2MjddIG1hbmRhdG9yeSB0bzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGltcGxlbWVudCBhbmQgdXNlIGFzIHRoZSBsb2NhbCB0 YXJnZXQgJmd0OyZndDtieSBub3RpZmllcnMmbHQ7Jmx0OyBpbiB0aGUgc3Vic2NyaXB0aW9uIGNy ZWF0ZWQgYnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyB0aGUgUkVGRVIgcmVxdWVzdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0t LS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkNPTU1FTlQgNDo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tLS0tLS0tLS0tLS0t LTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+U2VjdGlvbiAzIHN0YXRl cyAmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZu YnNwOyBBIFVBIHRoYXQgd2lsbCBhY2NlcHQgYSBSRUZFUiByZXF1ZXN0IG5lZWRzIHRvIGluY2x1 ZGUgYSBHUlVVIGluIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jm5ic3A7Jm5ic3A7IENvbnRhY3QgaGVhZGVyIGZpZWxkIG9mIGFsbCBJTlZJVEUgcmVxdWVzdHMu Jm5ic3A7IFRoaXMgZW5zdXJlcyB0aGF0IG91dC08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyBvZi1kaWFsb2cgUkVGRVIgcmVxdWVzdHMgY29ycmVz cG9uZGluZyB0byBhbnkgcmVzdWx0aW5nIElOVklURTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGRpYWxvZ3MgYXJyaXZlIGF0IHRoaXMgVUEuJm5i c3A7IEZ1dHVyZSBleHRlbnNpb25zIChzdWNoIGFzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgW0ktRC5zcGFya3Mtc2lwY29yZS1yZWZlci1leHBs aWNpdC1zdWJzY3JpcHRpb25dKSBtaWdodCByZWxheCB0aGlzPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgcmVxdWlyZW1lbnQgYnkgZGVmaW5pbmcg YSBSRUZFUiByZXF1ZXN0IHRoYXQgY2Fubm90IGNyZWF0ZSBhbjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7IGltcGxpY2l0IHN1YnNjcmlwdGlvbi48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZxdW90OzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgVUEgbWlnaHQgYmUgZ2xvYmFsbHkgcmVhY2hhYmxlIHdp dGhvdXQgaW5kaWNhdGluZyBHUlVVIC0gdGhpcyBpcyBjb21tb24gdG9kYXkgd2l0aCBuZXR3b3Jr IGNvbmZlcmVuY2Ugc2VydmVycy4gUmVxdWlyaW5nIEdSVVUgaXMgdW5uZWNlc3NhcnkuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLS0tLS0tLS0tLS0tLS08bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+QWdhaW4sIHNlZSBBZGFtJ3MgNjY2NSBjbGFyaWZpY2F0aW9ucyBkcmFmdCAoYW5k IHBsZWFzZSB0YWtlIGFueSBhcmd1bWVudCB3aXRoIGl0IHRvIHRoZSBsaXN0IHVuZGVyIHRoYXQg bmFtZSBhcyBhIHN1YmplY3QsIG5vdCB0aGlzIGRyYWZ0KS48YnI+DQo8YnI+DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiM5ODQ4MDYiPltJdm9dDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5ODQ4MDYiPldl bGwsIHRoaXMgZHJhZnQgc3RhdGVzIHRoaXMgcmVxdWlyZW1lbnQgYW5kIHRoZXJlZm9yZSBpdCBj YW4gYmUgcXVlc3Rpb25lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5ODQ4MDYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6Izk4NDgwNiI+WWVzLCB0aGUgc2FtZSBjb21tZW50cyBjYW4gYmUgcmFp c2VkIGFnYWluc3QgdGhlICZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPjY2NjUgY2xhcmlmaWNhdGlvbnMgZHJhZnQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojOTg0ODA2Ij4mcXVvdDsNCiBidXQgdGhhdCBkb2VzIG5vdCBtYWtlIHRoaXMg ZG9jdW1lbnQgY29ycmVjdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM5ODQ4MDYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UFJPUE9TRUQgU09MVVRJT04gNDo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tLS0tLS0tLS0tLS0tLTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+TWFrZSB0aGUgc3RhdGVtZW50 IGdlbmVyYWwgdG8gc3RhdGUgdGhhdCB0aGUgVUEgbXVzdCBwcm92aWRlIFVSSSB3aGljaCBpcyBh IGdsb2JhbGx5IHJlYWNoYWJsZSBpbiB0aGUgQ29udGFjdCBvZiBJTlZJVEUgcmVxdWVzdHMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLS0tLS0tLS0tLS0tLS08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q09NTUVOVCA1OjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5TZWN0aW9uIDQsIDFzdCBwYXJhZ3JhcGggYW5kIDJu ZCBwYXJhZ3JhcGggcHJvdmlkZSBvdmVybGFwcGluZyBpbmZvcm1hdGlvbi4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5JbiAxc3QgcGFyYWdyYXBoLCB0aGVyZSBpcyBhIHN0YXRlbWVu dCB0aGF0IGlmIHJlbW90ZSBVQSBwcm92aWRlZCBhIEdSVVUgYXMgaXRzIGxvY2FsIHRhcmdldCB0 aGVuIGEgdXNlciBhZ2VudCBzZW5kaW5nIGEgUkVGRVIgcmVxdWVzdCAodG93YXJkcyB0aGF0IHRh cmdldCkgdGhhdCBjb3VsZCByZXN1bHQgaW4gYW4mbmJzcDsgaW1wbGljaXQgc3Vic2NyaXB0aW9u IHdpdGhpbiBhIGRpYWxvZyBpcyBwcm9oaWJpdGVkLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPkluIDJuZCBwYXJhZ3JhcGgsIHRoZSBzYW1lIGlzIHN0YXRlZCAoaW4gcG9zaXRpdmUg d2F5KSByZWdhcmRsZXNzIHdoZXRoZXIgdGhlIHJlbW90ZSBVQSBwcm92aWRlZCBhIEdSVVUgYXMg aXRzIGxvY2FsIHRhcmdldCBvciBub3QuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPi0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5QUk9QT1NFRCBTT0xVVElPTiA1OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+LS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5SZW1vdmUgdGhlIDFzdCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiA0LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPkkgY2FuIGFsbW9zdCBzZWUgdGhlIG92ZXJsYXAgeW91IGFyZSB0YWxraW5nIGFib3V0LCBi dXQgSSBkb24ndCBzZWUgd2hlcmUgdGhhdCBpbnRyb2R1Y2VzIGFueSB3ZWFrbmVzcyBpbnRvIHRo ZSB0ZXh0Ljxicj4NClJlbW92aW5nIHRoZSBwYXJhZ3JhcGggaXMgbm90IHRoZSByaWdodCB0aGlu ZyB0byBkby4gVGhlIGZpcnN0IHBhcmFncmFwaCBkZXNjcmliZXMgdGhlIHByb2hpYml0aW9uLCB0 aGUgc2Vjb25kIHRhbGtzPGJyPg0KYWJvdXQgd2hhdCdzIGxlZnQgdGhhdCB5b3UgY2FuIGRvLiBU aGUgZG9jdW1lbnQgaXMgbGVzcyBhY2N1cmF0ZSBpZiB5b3UgbGVhdmUgZWl0aGVyIHBvaW50IG91 dC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiM5ODQ4MDYiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6Izk4NDgwNiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTg0 ODA2Ij5bSXZvXQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTg0ODA2Ij5UaGUgdGV4dCBpcyBpbmNv bnNpc3RlbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTg0ODA2Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiM5ODQ4MDYiPlRoZSByZWFkZXIgd2lsbCB3b25kZXIgd2h5OjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6Izk4NDgwNiI+LSB0aGUgMXN0IHBhcmFncmFwaCBwcm9oaWJpdHMgZGlhbG9nIHJldXNl DQo8dT5pZiB0aGUgcmVtb3RlIFVFIHByb3ZpZGVkIEdSVVU8L3U+OyBhbmQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiM5ODQ4MDYiPi0gdGhlIDJuZCBwYXJhZ3JhcGggcmVxdWlyZXMgb3V0LW9mLWRpYWxv ZyBSRUZFUg0KPHU+cmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSByZW1vdGUgVUUgcHJvdmlkZWQg R1JVVS48L3U+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPkNPTU1FTlQgNjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPi0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+U2VjdGlvbiAzIHN0YXRlczogJnF1b3Q7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgQSB1c2VyIGFnZW50IGNvbnN0 cnVjdGluZyBhbnkgUkVGRVIgdGhhdCBjYW4gcmVzdWx0IGluIGFuIGltcGxpY2l0PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsgc3Vic2NyaXB0aW9u IE1VU1QgcG9wdWxhdGUgaXRzIENvbnRhY3QgaGVhZGVyIGZpZWxkIHdpdGggYSBHUlVVLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+JnF1b3Q7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPkluIFJGQzY2NSwgdGhlcmUgaXMgbm8gc3VjaCByZXF1aXJlbWVudCBm b3Igc3Vic2NyaWJlci4gV2h5IGRvIHdlIHN0YXRlIHN1Y2ggbmV3IHJlcXVpcmVtZW50Pw0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tLS0tLS0tLS0tLS0tLS0tLS08 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+U2VlIEFkYW0ncyBlYXJsaWVyIHJlc3BvbnNlIGFuZCB0aGUgNjY2NSBjbGFy aWZpY2F0aW9ucyBkcmFmdC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2Nv bG9yOiM5ODQ4MDYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Izk4NDgwNiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojOTg0ODA2Ij5bSXZvXSBBZ2FpbiwgdGhpcyBkb2N1bWVudCByZWZlcnMgdG8g UkZDNjY2NSBhbmQgUkZDNjY2NSBkb2VzIG5vdCBzdGF0ZSBpdC48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PlBST1BPU0VEIFNPTFVUSU9OIDY6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij4tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPkNsYXJpZnkgdGhlIG5lZWQgZm9yIHRoaXMgcmVxdWlyZW1lbnQgb3IgcmVtb3ZlIGl0 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+LS0tLS0tLS0tLS0tLS0t LS0tPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPktpbmQgcmVnYXJkczxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5Jdm8gU2VkbGFjZWs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_39B5E4D390E9BD4890E2B310790061011278D7C3ESESSMB301erics_-- From nobody Wed Nov 12 11:09:33 2014 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 047491ACE4C for ; Wed, 12 Nov 2014 11:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_RFdmDcACbv for ; Wed, 12 Nov 2014 11:09:17 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B05E51ACF0F for ; Wed, 12 Nov 2014 11:07:57 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id u7so9082968qaz.11 for ; Wed, 12 Nov 2014 11:07:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=uRVrcEw+rHDqW0rfQhCMRQtg/ktBJIBRHxRufKNpduE=; b=kNqBX8YIuN/r+o+RFY0RHrh493jVNl+6H96gENF34C3aSwCSyAuXDnNZogsppEPPms W9UkEIXZCCkWS9uHwyg5mPB+giAwNXNaRppSf0L84XQ9DgeQiJh9IGWDWavv11l60gIn 56hs4/jzlZvkxUHevgY8sZy/SRj4JSJ/EEcBRMtKz13OEJaKRh6b/avb0x77l39oaC4B su4MP8Hx8k5nSv6otAxAkVTSs6+A0ZO2C7E/9EE3QjuNi/2IyqfrsdqeMbQKDKO+k0ae xaIwQHAQWxMXFH78MWWT7w29iCtJyfzHn70hZZ40uNCj1Ul75ODfqP5/2ZHQP9YD6+KZ lVng== X-Gm-Message-State: ALoCoQmexz1JhP9T3MyvTwGMw4+buxhrWW87yepcMAA18N6jKalhV7tCGtSX52J8SX7SZLSz3ztN X-Received: by 10.229.209.136 with SMTP id gg8mr56987206qcb.16.1415819276785; Wed, 12 Nov 2014 11:07:56 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/+q5IqqHtheaN4T1Ss2CrQXUfOhA== Date: Wed, 12 Nov 2014 14:07:54 -0500 Message-ID: <99d6b834e9213667f7e6adef67fecc0f@mail.gmail.com> To: Adam Roach , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/3Cd0HcF8b9Cs4YuRUf67hczlF4c Subject: [sipcore] mandating GRUU (was RE: draft-roach-sipcore-6665-clarification-00: comment) 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, 12 Nov 2014 19:09:23 -0000 Hi, Thanks for response. I was mainly just checking if the working group wanted to reconsider the GRUU mandate because of the patents, draft-kaplan-dispatch-gruu-problematic, et cetera. Based upon issues raised within draft-kaplan-dispatch-gruu-problematic, I wouldn't be surprised to eventually see something GRUU related dispatched to the straw working group. > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, November 11, 2014 12:30 PM > To: Brett Tate; sipcore@ietf.org > Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment > > On 11/11/14 05:18, Brett Tate wrote: > > "The mandate ensures that GRUU and the related patents are applicable > > to as many devices as possible..." > > > > I'm sympathetic to the point you're trying to make, but the fact of the matter > is that this space is already rife with claims of IPR applicability; for example: > https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=3261 > > /a From nobody Wed Nov 12 11:28:04 2014 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 993571ACF7D for ; Wed, 12 Nov 2014 11:28:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 vj9dVSeSkMdw for ; Wed, 12 Nov 2014 11:28:00 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B39E1ACF90 for ; Wed, 12 Nov 2014 11:27:56 -0800 (PST) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-03v.sys.comcast.net with comcast id EjTX1p0084s37d401jTvqS; Wed, 12 Nov 2014 19:27:55 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-po-01v.sys.comcast.net with comcast id EjTu1p0091KKtkw01jTuS8; Wed, 12 Nov 2014 19:27:55 +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 sACJRrfg005489; Wed, 12 Nov 2014 14:27:53 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id sACJRr8H005488; Wed, 12 Nov 2014 14:27:53 -0500 Date: Wed, 12 Nov 2014 14:27:53 -0500 Message-Id: <201411121927.sACJRr8H005488@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Adam Roach In-reply-to: <546247A1.5090905@nostrum.com> (adam@nostrum.com) References: <546247A1.5090905@nostrum.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1415820475; bh=0AdKKm7kLR5cBime8IpNr0yV+blo1uygYymDvl7r6Oo=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=TsGJOoex8fWodk/mQFBbHS0fD6VKAki63Jt2HdHAQaIlZ/XiZ2V7QLVJg9QjByPpf NRgmOiQKLvWyoHlkQRcM9JbwW/a5CQp8du252opeiBqlwA0QCsgNfLmDo1xfIHLnEz cCrSBZxKezgZVZUqsH2oSs8FHWAwTzKnI236VaDaZIETO3DCMuqigCNE4IEKDMCEoD 7fuN/tZd67p7qfStYNMh4Dk9R4CmicdKMRCpmjQVw+yE5oNkIPADVXcaEHJBLtPfZc KOz8MNXVEQ7ZLYNWDShPwFEvaMO+i9Z+qK6jGYmFgW2Y0sbd/7J9skLHq9VVhiDQVr 9gkTtB41HPcSQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/GQJa9mUm5dBBCQo38EVyYmk8g3M Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment 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, 12 Nov 2014 19:28:01 -0000 > From: Adam Roach > I'm sympathetic to the point you're trying to make, but the fact of the > matter is that this space is already rife with claims of IPR > applicablity; for example: > https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=3261 Do we have any sort of list of the IPR claims that relate specifically to the use of GRUUs in these contexts? Presumably that list is far shorter than the complete list for 3261. I mean, how can we estimate how much of a problem this all is for *this* draft? Dale From nobody Wed Nov 12 11:50:10 2014 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 81E391A19E7 for ; Wed, 12 Nov 2014 11:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 PPuHsCqB_nZv for ; Wed, 12 Nov 2014 11:50:05 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 69F8C1A19F3 for ; Wed, 12 Nov 2014 11:50:05 -0800 (PST) Received: from xct107cnc.rim.net ([10.65.161.207]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 12 Nov 2014 14:50:00 -0500 Received: from XCT111CNC.rim.net (10.65.161.211) by XCT107CNC.rim.net (10.65.161.207) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 12 Nov 2014 14:49:58 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT111CNC.rim.net ([::1]) with mapi id 14.03.0174.001; Wed, 12 Nov 2014 14:49:58 -0500 From: Andrew Allen To: "brett@broadsoft.com" , "adam@nostrum.com" , "sipcore@ietf.org" Thread-Topic: [sipcore] mandating GRUU (was RE: draft-roach-sipcore-6665-clarification-00: comment) Thread-Index: Ac/+q5IqqHtheaN4T1Ss2CrQXUfOhAABkSSA Date: Wed, 12 Nov 2014 19:49:58 +0000 Message-ID: In-Reply-To: <99d6b834e9213667f7e6adef67fecc0f@mail.gmail.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/KUiBMyQwYykwSFC3VG2Vbxn9y8o Subject: Re: [sipcore] mandating GRUU (was RE: draft-roach-sipcore-6665-clarification-00: comment) 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, 12 Nov 2014 19:50:07 -0000 Brett The following draft which expired a short while ago http://www.ietf.org/archive/id/draft-allen-dispatch-routing-out-of-dialog-r= equest-00.txt was submitted by me to address some of the problems B2BUAs cause for GRUU.= It evoked quite a bit of discussion however I chose a bad time to submit i= t since I was away and unable to respond during that discussion. I do inten= d to resurrect the draft soon by submitting a revision.=20 Andrew ----- Original Message ----- From: Brett Tate [mailto:brett@broadsoft.com] Sent: Wednesday, November 12, 2014 02:07 PM Eastern Standard Time=0A= To: Adam Roach ; sipcore@ietf.org Subject: [sipcore] mandating GRUU (was RE: draft-roach-sipcore-6665-clarifi= cation-00: comment) Hi, Thanks for response. I was mainly just checking if the working group wanted to reconsider the GRUU mandate because of the patents, draft-kaplan-dispatch-gruu-problematic, et cetera. Based upon issues raised within draft-kaplan-dispatch-gruu-problematic, I wouldn't be surprised to eventually see something GRUU related dispatched to the straw working group. > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, November 11, 2014 12:30 PM > To: Brett Tate; sipcore@ietf.org > Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment > > On 11/11/14 05:18, Brett Tate wrote: > > "The mandate ensures that GRUU and the related patents are applicable > > to as many devices as possible..." > > > > I'm sympathetic to the point you're trying to make, but the fact of the matter > is that this space is already rife with claims of IPR applicability; for example: > https://datatracker.ietf.org/ipr/search/?option=3Drfc_search&rfc_search=3D3= 261 > > /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Nov 12 12:02:33 2014 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 3027B1AD002 for ; Wed, 12 Nov 2014 12:02:30 -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 TuJdXp_O00C4 for ; Wed, 12 Nov 2014 12:02:25 -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 CA1591A8757 for ; Wed, 12 Nov 2014 12:01:54 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-65-5463bcb0730d Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 76.7A.24955.0BCB3645; Wed, 12 Nov 2014 21:01:53 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0174.001; Wed, 12 Nov 2014 21:01:52 +0100 From: Christer Holmberg To: "Dale R. Worley" , Adam Roach Thread-Topic: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Thread-Index: Ac/9wrQBO4aVruMDQzGXBwSF82K37gACg4uAADiBxrQAAQ/pkA== Date: Wed, 12 Nov 2014 20:01:51 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4F32BA@ESESSMB209.ericsson.se> References: <546247A1.5090905@nostrum.com> <201411121927.sACJRr8H005488@hobgoblin.ariadne.com> In-Reply-To: <201411121927.sACJRr8H005488@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.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvje7GPckhBsdWcVjs+buI3eLrj01s Fi9PlDkwe0ze/5XZY8mSn0wes3Y+YQlgjuKySUnNySxLLdK3S+DKOLNtJWPBc86K3ec3sDQw dnJ0MXJySAiYSPQtf8IEYYtJXLi3nq2LkYtDSOAIo0R70yxWCGcJo8T0t0uBMhwcbAIWEt3/ tEEaRAQ8JG63P2cFsZkFNCUe7dwLNkhYwFNiwcO9rBA1XhIbH35ihrCdJK5OPcEGYrMIqEp8 eDEZzOYV8JV4sGM11K4pjBLrOo+xg+ziFHCQOHc0B6SGEei476fWMEHsEpe49WQ+1NECEkv2 nGeGsEUlXj7+xwphK0k0LnkCdZuOxILdn9ggbG2JZQtfM0PsFZQ4OfMJywRGsVlIxs5C0jIL ScssJC0LGFlWMYoWpxYn5aYbGeulFmUmFxfn5+nlpZZsYgRG1MEtv1V3MF5+43iIUYCDUYmH 1+BsUogQa2JZcWXuIUZpDhYlcd6F5+YFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCsWSZq 2GY4be0eOTeRM2lf5uReLCvL2n7rknUSy2JGx34tDyM2jinzmSd82anmNUVEXiDJsPdhS8Wt ghK2ObfiIu8/XHI2L/XD+6hTjjN4WSWNdMQ0A2evN9Mofbz905VICU+Jqd+qOXjLntr2Z01c nPRuR4/RYZ0lM55qJm4xXPjiMM+/yflKLMUZiYZazEXFiQCk75lCiQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/pg4AeYGNOVslQIWm9bl2uxAhBAI Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment 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, 12 Nov 2014 20:02:30 -0000 Hi, I think the main technical reason for considering relaxing the GRUU require= ment is that there are deployments and use-cases that work without GRUU, be= cause there are other mechanisms to ensure that requests go where they are = supposed to. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: 12 November 2014 21:28 To: Adam Roach Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment > From: Adam Roach > I'm sympathetic to the point you're trying to make, but the fact of=20 > the matter is that this space is already rife with claims of IPR=20 > applicablity; for example: > https://datatracker.ietf.org/ipr/search/?option=3Drfc_search&rfc_search= =3D > 3261 Do we have any sort of list of the IPR claims that relate specifically to t= he use of GRUUs in these contexts? Presumably that list is far shorter tha= n the complete list for 3261. I mean, how can we estimate how much of a pr= oblem this all is for *this* draft? Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Nov 12 14:54:41 2014 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 96C611A00F7 for ; Wed, 12 Nov 2014 14:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 B5waIsK5FzVc for ; Wed, 12 Nov 2014 14:54:37 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 051C51A011D for ; Wed, 12 Nov 2014 14:54:36 -0800 (PST) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 12 Nov 2014 17:54:28 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT105CNC.rim.net ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.03.0174.001; Wed, 12 Nov 2014 17:54:26 -0500 From: Andrew Allen To: "christer.holmberg@ericsson.com" , "worley@ariadne.com" , "adam@nostrum.com" Thread-Topic: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Thread-Index: Ac/9wrQBO4aVruMDQzGXBwSF82K37gAPFjGAACvvF7YAC6fSgAAEcye1 Date: Wed, 12 Nov 2014 22:54:26 +0000 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4F32BA@ESESSMB209.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/0ldUD-AuhPxdScuJDHEmhqqnwhI Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment 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, 12 Nov 2014 22:54:39 -0000 Christer My understanding is that the deployments you are talking about only don't h= ave the potential to create an implicit subscription because of something d= efined outside of the SIP protocol ensures that they only perform a subset = of the defined behavior in RFCs 3515, 6665 and 4488 i.e. by defining that t= he UAC always includes refersub=3Dfalse and by defining that the UAS always= accepts that request to not create a subscription with the only way for a = UAC to determine that the UAS will behave that way is because it received a= media-feature tag or feature capability indicator that it knows by means o= utside the SIP protocol that this will happen. I think we should clearly decide whether this fulfils the criteria for a UA= C to determine definitively that no implicit subscription will be created a= nd hence allows the UAC to send the Refer on an existing dialog.=20 My own preference is not to have this qualify as a way for a UAC to be cert= ain as this makes SIP protocol behavior dependent on some higher layer appl= ication semantic and also means that it is likely that the UAS in these cas= es becomes only a partial implementation of the protocol (e.g. It doesn't e= ven implement receiving a Refer out of dialog and cannot send a Notify even= if a UAC did not include Refersub =3D false). I think the discusion we had= in Dispatch yesterday shows that problems are caused when only partial imp= lementations of the protocol are done and assumptions about the behavior of= the UAC are made. My preference is that refer-clarifications should only allow refer-explicit= -subscription mechanism as a means for UAC to determine that its ok to send= the Refer on an existing dialog. If that means we have to make these two drafts part of the same package the= n so be it. Andrew ----- Original Message ----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, November 12, 2014 03:01 PM Eastern Standard Time=0A= To: Dale R. Worley ; Adam Roach Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Hi, I think the main technical reason for considering relaxing the GRUU require= ment is that there are deployments and use-cases that work without GRUU, be= cause there are other mechanisms to ensure that requests go where they are = supposed to. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: 12 November 2014 21:28 To: Adam Roach Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment > From: Adam Roach > I'm sympathetic to the point you're trying to make, but the fact of=20 > the matter is that this space is already rife with claims of IPR=20 > applicablity; for example: > https://datatracker.ietf.org/ipr/search/?option=3Drfc_search&rfc_search= =3D > 3261 Do we have any sort of list of the IPR claims that relate specifically to t= he use of GRUUs in these contexts? Presumably that list is far shorter tha= n the complete list for 3261. I mean, how can we estimate how much of a pr= oblem this all is for *this* draft? Dale _______________________________________________ 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 Nov 12 15:14:47 2014 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 2A3131A1AFA for ; Wed, 12 Nov 2014 15:14: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 vzdseP9obeGP for ; Wed, 12 Nov 2014 15:14:38 -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 EBB911A1AF1 for ; Wed, 12 Nov 2014 15:14:37 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-60-5463e9db9c0d Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BA.56.24955.BD9E3645; Thu, 13 Nov 2014 00:14:35 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Thu, 13 Nov 2014 00:14:35 +0100 From: Christer Holmberg To: Andrew Allen , "worley@ariadne.com" , "adam@nostrum.com" Thread-Topic: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Thread-Index: Ac/9wrQBO4aVruMDQzGXBwSF82K37gACg4uAADiBxrQAAQ/pkAAEDD0AAAK57UA= Date: Wed, 12 Nov 2014 23:14:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4F3A0C@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4F32BA@ESESSMB209.ericsson.se> In-Reply-To: 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+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3Rvf2y+QQg/8fbCzuz9vKaLHn7yJ2 i68/NrFZvDxR5sDiMXn/V2aPWQ1r2T2WLPnJ5DFr5xOWAJYoLpuU1JzMstQifbsEroy1f7gL 3itU/L2xnbWB8b9UFyMnh4SAicS7GXvZIWwxiQv31rN1MXJxCAkcYZR4v6aLHcJZwijxuaMD yOHgYBOwkOj+pw3SICJQI7Hw6yImEJtZQFPi0c69YLawgKfEgod7WSFqvCQ2PvzEDGH7Say7 eh4sziKgKnHk4HcWEJtXwFdi8bFPrBC7ehglTjZcZgRJcAINmr9nHdhQRqDrvp9aA7VMXOLW k/lMEFcLSCzZc54ZwhaVePn4HyuErSTRuOQJK0S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsE RrFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIERtnBLb9VdzBe fuN4iFGAg1GJh9fgbFKIEGtiWXFl7iFGaQ4WJXHehefmBQsJpCeWpGanphakFsUXleakFh9i ZOLglGpgrHA46rRyssON9OAjHJwPooVLCk+KTn0ZnrPQlut39OfbTE/ZO0Q+f1bOvFXilCW9 JOUiG7ff290W3Rl8ctOyNi7XOKVtsudS1YSgMME75pILf1yLfroxXd0m+b3C/J8PZZ7NDdtz yz7BU/bunTzlW/sebXLmmnyy9DnTrU3+8zX3mx42au26p8RSnJFoqMVcVJwIAOKe5gOTAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Hi2hQM5wuv_PSQNkGA5FehUbaXA Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment 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, 12 Nov 2014 23:14:44 -0000 Hi Andrew, My comment was not about knowing whether an implicit registration will be c= reated or not, but mandating GRUU. A URI might be properly routable without= being a GRUU, and adding a "dummy" gr parameter just to make the URI look = like a GRUU is not good protocol design, in my opinion... Regards, Christer -----Original Message----- From: Andrew Allen [mailto:aallen@blackberry.com]=20 Sent: 13 November 2014 00:54 To: Christer Holmberg; worley@ariadne.com; adam@nostrum.com Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Christer My understanding is that the deployments you are talking about only don't h= ave the potential to create an implicit subscription because of something d= efined outside of the SIP protocol ensures that they only perform a subset = of the defined behavior in RFCs 3515, 6665 and 4488 i.e. by defining that t= he UAC always includes refersub=3Dfalse and by defining that the UAS always= accepts that request to not create a subscription with the only way for a = UAC to determine that the UAS will behave that way is because it received a= media-feature tag or feature capability indicator that it knows by means o= utside the SIP protocol that this will happen. I think we should clearly decide whether this fulfils the criteria for a UA= C to determine definitively that no implicit subscription will be created a= nd hence allows the UAC to send the Refer on an existing dialog.=20 My own preference is not to have this qualify as a way for a UAC to be cert= ain as this makes SIP protocol behavior dependent on some higher layer appl= ication semantic and also means that it is likely that the UAS in these cas= es becomes only a partial implementation of the protocol (e.g. It doesn't e= ven implement receiving a Refer out of dialog and cannot send a Notify even= if a UAC did not include Refersub =3D false). I think the discusion we had= in Dispatch yesterday shows that problems are caused when only partial imp= lementations of the protocol are done and assumptions about the behavior of= the UAC are made. My preference is that refer-clarifications should only allow refer-explicit= -subscription mechanism as a means for UAC to determine that its ok to send= the Refer on an existing dialog. If that means we have to make these two drafts part of the same package the= n so be it. Andrew ----- Original Message ----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, November 12, 2014 03:01 PM Eastern Standard Time To: Dale R. Worley ; Adam Roach Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Hi, I think the main technical reason for considering relaxing the GRUU require= ment is that there are deployments and use-cases that work without GRUU, be= cause there are other mechanisms to ensure that requests go where they are = supposed to. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: 12 November 2014 21:28 To: Adam Roach Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment > From: Adam Roach > I'm sympathetic to the point you're trying to make, but the fact of=20 > the matter is that this space is already rife with claims of IPR=20 > applicablity; for example: > https://datatracker.ietf.org/ipr/search/?option=3Drfc_search&rfc_search= =3D > 3261 Do we have any sort of list of the IPR claims that relate specifically to t= he use of GRUUs in these contexts? Presumably that list is far shorter tha= n the complete list for 3261. I mean, how can we estimate how much of a pr= oblem this all is for *this* draft? Dale _______________________________________________ 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 Nov 12 15:34:19 2014 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 B4C551A1B58 for ; Wed, 12 Nov 2014 15:34:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 xjndo9EbgOOV for ; Wed, 12 Nov 2014 15:34:15 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 04F731A1B51 for ; Wed, 12 Nov 2014 15:34:14 -0800 (PST) Received: from xct107cnc.rim.net ([10.65.161.207]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 12 Nov 2014 18:34:09 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT107CNC.rim.net ([fe80::b815:71ef:9f8f:e07c%16]) with mapi id 14.03.0174.001; Wed, 12 Nov 2014 18:34:08 -0500 From: Andrew Allen To: "christer.holmberg@ericsson.com" , "worley@ariadne.com" , "adam@nostrum.com" Thread-Topic: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Thread-Index: Ac/9wrQBO4aVruMDQzGXBwSF82K37gAPFjGAACvvF7YAC6fSgAAEcye1AAJH3gAACctIaw== Date: Wed, 12 Nov 2014 23:34:07 +0000 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4F3A0C@ESESSMB209.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Y5bCMtrjC8t5hcwgaaoUIhxveh0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment 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, 12 Nov 2014 23:34:17 -0000 Christer How else does the UA know that the URI is globally routable but by the pres= ence of a gr parameter? Basically a GRUU is a URI with the globally routabl= e property (and not just one obtained using the registration mechanism defi= nes in RFC 5627). The way we indicate that a URI has the globally routable = property is by the presence of the gr parameter. A URI with the globally ro= utable property and the gr parameter is called a GRUU. Andrew ----- Original Message ----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, November 12, 2014 06:14 PM Eastern Standard Time=0A= To: Andrew Allen; worley@ariadne.com ; adam@nostrum.com= Cc: sipcore@ietf.org Subject: RE: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Hi Andrew, My comment was not about knowing whether an implicit registration will be c= reated or not, but mandating GRUU. A URI might be properly routable without= being a GRUU, and adding a "dummy" gr parameter just to make the URI look = like a GRUU is not good protocol design, in my opinion... Regards, Christer -----Original Message----- From: Andrew Allen [mailto:aallen@blackberry.com]=20 Sent: 13 November 2014 00:54 To: Christer Holmberg; worley@ariadne.com; adam@nostrum.com Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Christer My understanding is that the deployments you are talking about only don't h= ave the potential to create an implicit subscription because of something d= efined outside of the SIP protocol ensures that they only perform a subset = of the defined behavior in RFCs 3515, 6665 and 4488 i.e. by defining that t= he UAC always includes refersub=3Dfalse and by defining that the UAS always= accepts that request to not create a subscription with the only way for a = UAC to determine that the UAS will behave that way is because it received a= media-feature tag or feature capability indicator that it knows by means o= utside the SIP protocol that this will happen. I think we should clearly decide whether this fulfils the criteria for a UA= C to determine definitively that no implicit subscription will be created a= nd hence allows the UAC to send the Refer on an existing dialog.=20 My own preference is not to have this qualify as a way for a UAC to be cert= ain as this makes SIP protocol behavior dependent on some higher layer appl= ication semantic and also means that it is likely that the UAS in these cas= es becomes only a partial implementation of the protocol (e.g. It doesn't e= ven implement receiving a Refer out of dialog and cannot send a Notify even= if a UAC did not include Refersub =3D false). I think the discusion we had= in Dispatch yesterday shows that problems are caused when only partial imp= lementations of the protocol are done and assumptions about the behavior of= the UAC are made. My preference is that refer-clarifications should only allow refer-explicit= -subscription mechanism as a means for UAC to determine that its ok to send= the Refer on an existing dialog. If that means we have to make these two drafts part of the same package the= n so be it. Andrew ----- Original Message ----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, November 12, 2014 03:01 PM Eastern Standard Time To: Dale R. Worley ; Adam Roach Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Hi, I think the main technical reason for considering relaxing the GRUU require= ment is that there are deployments and use-cases that work without GRUU, be= cause there are other mechanisms to ensure that requests go where they are = supposed to. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: 12 November 2014 21:28 To: Adam Roach Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment > From: Adam Roach > I'm sympathetic to the point you're trying to make, but the fact of=20 > the matter is that this space is already rife with claims of IPR=20 > applicablity; for example: > https://datatracker.ietf.org/ipr/search/?option=3Drfc_search&rfc_search= =3D > 3261 Do we have any sort of list of the IPR claims that relate specifically to t= he use of GRUUs in these contexts? Presumably that list is far shorter tha= n the complete list for 3261. I mean, how can we estimate how much of a pr= oblem this all is for *this* draft? Dale _______________________________________________ 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 Nov 12 15:56:54 2014 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 2BBF41A0068 for ; Wed, 12 Nov 2014 15:56:53 -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 jbEJZZHYhlZ2 for ; Wed, 12 Nov 2014 15:56: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 DF6001A0062 for ; Wed, 12 Nov 2014 15:56:47 -0800 (PST) X-AuditID: c1b4fb3a-f79596d000001123-cc-5463f3bd3dae Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 61.FA.04387.DB3F3645; Thu, 13 Nov 2014 00:56:45 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0174.001; Thu, 13 Nov 2014 00:56:45 +0100 From: Christer Holmberg To: Andrew Allen , "worley@ariadne.com" , "adam@nostrum.com" Thread-Topic: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Thread-Index: Ac/9wrQBO4aVruMDQzGXBwSF82K37gACg4uAADiBxrQAAQ/pkAAEDD0AAAK57UD///VGgP//645g Date: Wed, 12 Nov 2014 23:56:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4F3BA7@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D4F3A0C@ESESSMB209.ericsson.se> In-Reply-To: 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+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3Rnfv5+QQg83PrCzuz9vKaLHn7yJ2 i68/NrFZvDxR5sDiMXn/V2aPWQ1r2T2WLPnJ5DFr5xOWAJYoLpuU1JzMstQifbsEroxTSwUK 1qlXfP00kbGBcblCFyMnh4SAicTr5rWMELaYxIV769m6GLk4hASOMEqcmLucHcJZwijR2nKR uYuRg4NNwEKi+582SIOIQI3Ewq+LmEBsZgFNiUc794LZwgKeEgse7mWFqPGS2PjwEzOEHSUx 9/VzsBoWAVWJY9dWgNm8Ar4SOxvfQi3uYZS40NUFluAEGrR4zhYWEJsR6Lrvp9ZALROXuPVk PhPE1QISS/acZ4awRSVePv7HCmErSTQuecIKUa8jsWD3JzYIW1ti2cLXzBCLBSVOznzCMoFR bBaSsbOQtMxC0jILScsCRpZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIFRdnDLb6sdjAef Ox5iFOBgVOLhNTibFCLEmlhWXJl7iFGag0VJnHfhuXnBQgLpiSWp2ampBalF8UWlOanFhxiZ ODilGhhlDIztZixnO8W1ZQX375KU4/cFE4+Hi02O6+Sc8H+/r6rVz9aXp3M2L3btzziq+o1F 5qGtq/uKQ/v/SG62EyvcyMQdyP/GdImsb4Ry5qmcutWGu3d+nXLh2YeZIRl3UhhfspyV4coO eRIY0/fMq23j/y6BfTt7C73vJU1ofiBn6hq0k51DM1iJpTgj0VCLuag4EQAXfVDQkwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/H5ONEKKN7LRVoW-b8v4l_ieTKbk Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment 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, 12 Nov 2014 23:56:53 -0000 Hi, >How else does the UA know that the URI is globally routable but by the pre= sence of a >gr parameter? The UA has to trust that the one providing the URI provides you something t= hat works. And, there are environments where the UA has no reason to doubt = that. Having said that, I have no problem to say "SHOULD use GRUU". But, we shoul= d allow for the use-cases and scenarios where it is not needed. Regards, Christer ----- Original Message ----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, November 12, 2014 06:14 PM Eastern Standard Time To: Andrew Allen; worley@ariadne.com ; adam@nostrum.com= Cc: sipcore@ietf.org Subject: RE: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Hi Andrew, My comment was not about knowing whether an implicit registration will be c= reated or not, but mandating GRUU. A URI might be properly routable without= being a GRUU, and adding a "dummy" gr parameter just to make the URI look = like a GRUU is not good protocol design, in my opinion... Regards, Christer -----Original Message----- From: Andrew Allen [mailto:aallen@blackberry.com]=20 Sent: 13 November 2014 00:54 To: Christer Holmberg; worley@ariadne.com; adam@nostrum.com Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Christer My understanding is that the deployments you are talking about only don't h= ave the potential to create an implicit subscription because of something d= efined outside of the SIP protocol ensures that they only perform a subset = of the defined behavior in RFCs 3515, 6665 and 4488 i.e. by defining that t= he UAC always includes refersub=3Dfalse and by defining that the UAS always= accepts that request to not create a subscription with the only way for a = UAC to determine that the UAS will behave that way is because it received a= media-feature tag or feature capability indicator that it knows by means o= utside the SIP protocol that this will happen. I think we should clearly decide whether this fulfils the criteria for a UA= C to determine definitively that no implicit subscription will be created a= nd hence allows the UAC to send the Refer on an existing dialog.=20 My own preference is not to have this qualify as a way for a UAC to be cert= ain as this makes SIP protocol behavior dependent on some higher layer appl= ication semantic and also means that it is likely that the UAS in these cas= es becomes only a partial implementation of the protocol (e.g. It doesn't e= ven implement receiving a Refer out of dialog and cannot send a Notify even= if a UAC did not include Refersub =3D false). I think the discusion we had= in Dispatch yesterday shows that problems are caused when only partial imp= lementations of the protocol are done and assumptions about the behavior of= the UAC are made. My preference is that refer-clarifications should only allow refer-explicit= -subscription mechanism as a means for UAC to determine that its ok to send= the Refer on an existing dialog. If that means we have to make these two drafts part of the same package the= n so be it. Andrew ----- Original Message ----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, November 12, 2014 03:01 PM Eastern Standard Time To: Dale R. Worley ; Adam Roach Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Hi, I think the main technical reason for considering relaxing the GRUU require= ment is that there are deployments and use-cases that work without GRUU, be= cause there are other mechanisms to ensure that requests go where they are = supposed to. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: 12 November 2014 21:28 To: Adam Roach Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment > From: Adam Roach > I'm sympathetic to the point you're trying to make, but the fact of=20 > the matter is that this space is already rife with claims of IPR=20 > applicablity; for example: > https://datatracker.ietf.org/ipr/search/?option=3Drfc_search&rfc_search= =3D > 3261 Do we have any sort of list of the IPR claims that relate specifically to t= he use of GRUUs in these contexts? Presumably that list is far shorter tha= n the complete list for 3261. I mean, how can we estimate how much of a pr= oblem this all is for *this* draft? Dale _______________________________________________ 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 Nov 12 16:08:38 2014 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 AE90A1A0069 for ; Wed, 12 Nov 2014 16:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 rIM_Q9M5ztis for ; Wed, 12 Nov 2014 16:08:23 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 635F01A0016 for ; Wed, 12 Nov 2014 16:08:23 -0800 (PST) Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 12 Nov 2014 19:08:17 -0500 Received: from XCT115CNC.rim.net (10.65.161.215) by XCT101CNC.rim.net (10.65.161.201) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 12 Nov 2014 19:08:17 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT115CNC.rim.net ([::1]) with mapi id 14.03.0174.001; Wed, 12 Nov 2014 19:08:17 -0500 From: Andrew Allen To: "christer.holmberg@ericsson.com" , "worley@ariadne.com" , "adam@nostrum.com" Thread-Topic: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Thread-Index: Ac/9wrQBO4aVruMDQzGXBwSF82K37gAPFjGAACvvF7YAC6fSgAAEcye1AAJH3gAACctIa///vW0AgABQmMk= Date: Thu, 13 Nov 2014 00:08:15 +0000 Message-ID: In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4F3BA7@ESESSMB209.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/3FSxzlz4A25XX_Zd95xCtHAj0MQ Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment 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, 13 Nov 2014 00:08:29 -0000 Christer That again sounds to me like some kind of special magic source that allows = entities to know things which they don't know from the protocol. SIP is by = design verbose and explicit and entities are supposed to determine the capa= bilities or properties of things using indications in the protocol not by s= ome other special magic that only works within walled gardens. I really don't see why requiring entities to add ";gr" to their URIs that a= re globally routable should be an issue. Andrew ----- Original Message ----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, November 12, 2014 06:56 PM Eastern Standard Time=0A= To: Andrew Allen; worley@ariadne.com ; adam@nostrum.com= Cc: sipcore@ietf.org Subject: RE: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Hi, >How else does the UA know that the URI is globally routable but by the pre= sence of a >gr parameter? The UA has to trust that the one providing the URI provides you something t= hat works. And, there are environments where the UA has no reason to doubt = that. Having said that, I have no problem to say "SHOULD use GRUU". But, we shoul= d allow for the use-cases and scenarios where it is not needed. Regards, Christer ----- Original Message ----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, November 12, 2014 06:14 PM Eastern Standard Time To: Andrew Allen; worley@ariadne.com ; adam@nostrum.com= Cc: sipcore@ietf.org Subject: RE: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Hi Andrew, My comment was not about knowing whether an implicit registration will be c= reated or not, but mandating GRUU. A URI might be properly routable without= being a GRUU, and adding a "dummy" gr parameter just to make the URI look = like a GRUU is not good protocol design, in my opinion... Regards, Christer -----Original Message----- From: Andrew Allen [mailto:aallen@blackberry.com]=20 Sent: 13 November 2014 00:54 To: Christer Holmberg; worley@ariadne.com; adam@nostrum.com Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Christer My understanding is that the deployments you are talking about only don't h= ave the potential to create an implicit subscription because of something d= efined outside of the SIP protocol ensures that they only perform a subset = of the defined behavior in RFCs 3515, 6665 and 4488 i.e. by defining that t= he UAC always includes refersub=3Dfalse and by defining that the UAS always= accepts that request to not create a subscription with the only way for a = UAC to determine that the UAS will behave that way is because it received a= media-feature tag or feature capability indicator that it knows by means o= utside the SIP protocol that this will happen. I think we should clearly decide whether this fulfils the criteria for a UA= C to determine definitively that no implicit subscription will be created a= nd hence allows the UAC to send the Refer on an existing dialog.=20 My own preference is not to have this qualify as a way for a UAC to be cert= ain as this makes SIP protocol behavior dependent on some higher layer appl= ication semantic and also means that it is likely that the UAS in these cas= es becomes only a partial implementation of the protocol (e.g. It doesn't e= ven implement receiving a Refer out of dialog and cannot send a Notify even= if a UAC did not include Refersub =3D false). I think the discusion we had= in Dispatch yesterday shows that problems are caused when only partial imp= lementations of the protocol are done and assumptions about the behavior of= the UAC are made. My preference is that refer-clarifications should only allow refer-explicit= -subscription mechanism as a means for UAC to determine that its ok to send= the Refer on an existing dialog. If that means we have to make these two drafts part of the same package the= n so be it. Andrew ----- Original Message ----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, November 12, 2014 03:01 PM Eastern Standard Time To: Dale R. Worley ; Adam Roach Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Hi, I think the main technical reason for considering relaxing the GRUU require= ment is that there are deployments and use-cases that work without GRUU, be= cause there are other mechanisms to ensure that requests go where they are = supposed to. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: 12 November 2014 21:28 To: Adam Roach Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment > From: Adam Roach > I'm sympathetic to the point you're trying to make, but the fact of=20 > the matter is that this space is already rife with claims of IPR=20 > applicablity; for example: > https://datatracker.ietf.org/ipr/search/?option=3Drfc_search&rfc_search= =3D > 3261 Do we have any sort of list of the IPR claims that relate specifically to t= he use of GRUUs in these contexts? Presumably that list is far shorter tha= n the complete list for 3261. I mean, how can we estimate how much of a pr= oblem this all is for *this* draft? Dale _______________________________________________ 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 Nov 12 16:11:53 2014 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 ECBFD1A0016 for ; Wed, 12 Nov 2014 16:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 5wp2BcdZWVo4 for ; Wed, 12 Nov 2014 16:11:17 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id D78511A006C for ; Wed, 12 Nov 2014 16:11:15 -0800 (PST) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 12 Nov 2014 19:11:15 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT106CNC.rim.net ([fe80::d824:6c98:60dc:3918%16]) with mapi id 14.03.0174.001; Wed, 12 Nov 2014 19:11:13 -0500 From: Andrew Allen To: "christer.holmberg@ericsson.com" , "worley@ariadne.com" , "adam@nostrum.com" Thread-Topic: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Thread-Index: Ac/9wrQBO4aVruMDQzGXBwSF82K37gAPFjGAACvvF7YAC6fSgAAEcye1AAJH3gAACctIa///vW0AgABQmMmAAKBdtA== Date: Thu, 13 Nov 2014 00:11:12 +0000 Message-ID: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/acRDnzSd8PZ6uMo9Z3g8aXQkrr8 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment 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, 13 Nov 2014 00:11:27 -0000 I meant magic sauce not magic source! ----- Original Message ----- From: Andrew Allen [mailto:aallen@blackberry.com] Sent: Wednesday, November 12, 2014 07:08 PM Eastern Standard Time=0A= To: christer.holmberg@ericsson.com ; worley= @ariadne.com ; adam@nostrum.com Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Christer That again sounds to me like some kind of special magic source that allows = entities to know things which they don't know from the protocol. SIP is by = design verbose and explicit and entities are supposed to determine the capa= bilities or properties of things using indications in the protocol not by s= ome other special magic that only works within walled gardens. I really don't see why requiring entities to add ";gr" to their URIs that a= re globally routable should be an issue. Andrew ----- Original Message ----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, November 12, 2014 06:56 PM Eastern Standard Time To: Andrew Allen; worley@ariadne.com ; adam@nostrum.com= Cc: sipcore@ietf.org Subject: RE: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Hi, >How else does the UA know that the URI is globally routable but by the pre= sence of a >gr parameter? The UA has to trust that the one providing the URI provides you something t= hat works. And, there are environments where the UA has no reason to doubt = that. Having said that, I have no problem to say "SHOULD use GRUU". But, we shoul= d allow for the use-cases and scenarios where it is not needed. Regards, Christer ----- Original Message ----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, November 12, 2014 06:14 PM Eastern Standard Time To: Andrew Allen; worley@ariadne.com ; adam@nostrum.com= Cc: sipcore@ietf.org Subject: RE: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Hi Andrew, My comment was not about knowing whether an implicit registration will be c= reated or not, but mandating GRUU. A URI might be properly routable without= being a GRUU, and adding a "dummy" gr parameter just to make the URI look = like a GRUU is not good protocol design, in my opinion... Regards, Christer -----Original Message----- From: Andrew Allen [mailto:aallen@blackberry.com]=20 Sent: 13 November 2014 00:54 To: Christer Holmberg; worley@ariadne.com; adam@nostrum.com Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Christer My understanding is that the deployments you are talking about only don't h= ave the potential to create an implicit subscription because of something d= efined outside of the SIP protocol ensures that they only perform a subset = of the defined behavior in RFCs 3515, 6665 and 4488 i.e. by defining that t= he UAC always includes refersub=3Dfalse and by defining that the UAS always= accepts that request to not create a subscription with the only way for a = UAC to determine that the UAS will behave that way is because it received a= media-feature tag or feature capability indicator that it knows by means o= utside the SIP protocol that this will happen. I think we should clearly decide whether this fulfils the criteria for a UA= C to determine definitively that no implicit subscription will be created a= nd hence allows the UAC to send the Refer on an existing dialog.=20 My own preference is not to have this qualify as a way for a UAC to be cert= ain as this makes SIP protocol behavior dependent on some higher layer appl= ication semantic and also means that it is likely that the UAS in these cas= es becomes only a partial implementation of the protocol (e.g. It doesn't e= ven implement receiving a Refer out of dialog and cannot send a Notify even= if a UAC did not include Refersub =3D false). I think the discusion we had= in Dispatch yesterday shows that problems are caused when only partial imp= lementations of the protocol are done and assumptions about the behavior of= the UAC are made. My preference is that refer-clarifications should only allow refer-explicit= -subscription mechanism as a means for UAC to determine that its ok to send= the Refer on an existing dialog. If that means we have to make these two drafts part of the same package the= n so be it. Andrew ----- Original Message ----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Wednesday, November 12, 2014 03:01 PM Eastern Standard Time To: Dale R. Worley ; Adam Roach Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment Hi, I think the main technical reason for considering relaxing the GRUU require= ment is that there are deployments and use-cases that work without GRUU, be= cause there are other mechanisms to ensure that requests go where they are = supposed to. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: 12 November 2014 21:28 To: Adam Roach Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment > From: Adam Roach > I'm sympathetic to the point you're trying to make, but the fact of=20 > the matter is that this space is already rife with claims of IPR=20 > applicablity; for example: > https://datatracker.ietf.org/ipr/search/?option=3Drfc_search&rfc_search= =3D > 3261 Do we have any sort of list of the IPR claims that relate specifically to t= he use of GRUUs in these contexts? Presumably that list is far shorter tha= n the complete list for 3261. I mean, how can we estimate how much of a pr= oblem this all is for *this* draft? Dale _______________________________________________ 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 Nov 13 00:00:56 2014 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 9790B1A212D for ; Thu, 13 Nov 2014 00:00:55 -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 wlDf6ofOZ0fz for ; Thu, 13 Nov 2014 00:00:54 -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 541891A1F04 for ; Thu, 13 Nov 2014 00:00:53 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-d8-54646532f08f Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B9.BB.04231.23564645; Thu, 13 Nov 2014 09:00:51 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.4]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0174.001; Thu, 13 Nov 2014 09:00:50 +0100 From: Ivo Sedlacek To: "sipcore@ietf.org" Thread-Topic: Comments to draft-roach-sipcore-6665-clarification-00 Thread-Index: Ac//Fvt0Tj2a9IRkR3mLh8GSWTd/9w== Date: Thu, 13 Nov 2014 08:00:49 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061011278DFFE@ESESSMB301.ericsson.se> 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+NgFtrLLMWRmVeSWpSXmKPExsUyM+Jvja5xakqIwap33BZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRs/uC2wFtwQqFn+MaWD8ytvFyMkhIWAiMW/xAhYIW0ziwr31 bCC2kMARRomD/QJdjFxA9iJGiUvNzYwgCTYBPYmJW46wgtgiApoSy79tZQexhQXsJNZOPcwC EXeWWHXkHDOErSfxf+4hsDiLgKrEgZ9PweK8Ar4SW5/+YAKxGQVkJa7+6QWbzywgLnHryXwm iIMEJJbsOc8MYYtKvHz8D2gvB5CtJDFtaxpEuY7Egt2f2CBsbYllC19DjReUODnzCcsERuFZ SKbOQtIyC0nLLCQtCxhZVjGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIEhvfBLb91dzCufu14 iFGAg1GJh3eDXEqIEGtiWXFl7iFGaQ4WJXHeRefmBQsJpCeWpGanphakFsUXleakFh9iZOLg lGpgDNH7qFSg5y4ckmjxjVemRlg399mqLRXyWsv/qdVla5rVOldUm/2YOFH+4Yqi+wJtX6xq 1Z4seCfY+sp6Z/yOXK1vnzOctQ7N/RudulG1Y2Y0g891r76QoBvPtFKLVuwv33Ljuv40ew7h F94KBr1zJQ+z7LcN3Xe6xkBel/vEesu07kXLVBWVWIozEg21mIuKEwF8T6EaUAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/aAUgayK8O9FSiqcF5e1EqNBQjWA Subject: [sipcore] Comments to draft-roach-sipcore-6665-clarification-00 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, 13 Nov 2014 08:00:55 -0000 Hello, I reviewed the draft and here are my comments: COMMENT 1: ------------------------------------------------- Section 1 states: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D The second sentence of this paragraph attempted to set context for the normative statement: the reason GRUUs are required in this context is to allow you to send SUBSCRIBE or REFER requests to a specific user agent, with the target of the subscription request being something like an INVITE dialog on that device. Consequently, the requirement to include a GRUU as a local target applies not just to the local target for SUBSCRIBE-created dialogs, but for *all* dialogs, even those created by INVITE. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D UA can have dialogs for which the UA rejects any related out-of-dialog REFE= R request.=20 Those dialogs are simply not transferrable. Requiring GRUU for such dialogs is unnecessary. ------------------------------------------------- PROPOSED SOLUTION 1: ------------------------------------------------- Restrict the requirement above to only dialogs for which the UA is willing = to accept an out-of-dialog REFER request. ------------------------------------------------- COMMENT 2: Section 1 states: ------------------------------------------------- This document updates [RFC6665] to clarify the actual requirement: "Notifiers MUST implement the Globally Routable User Agent URI (GRUU) extension defined in [RFC5627], and MUST use a GRUU as their local target for all dialog-forming methods and all target-refresh methods. This specifically includes dialogs created by the INVITE method." ------------------------------------------------- Same comment as in COMMENT 1 Kind regards Ivo Sedlacek Ericsson Mobile +420 608 234 709 ivo.sedlacek@ericsson.com www.ericsson.com This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer From nobody Thu Nov 13 01:16:18 2014 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 B3FAB1A6FA9 for ; Thu, 13 Nov 2014 01:15:48 -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 IpgQBPuiIuyE for ; Thu, 13 Nov 2014 01:15:44 -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 68CA81A6FC8 for ; Thu, 13 Nov 2014 01:15:40 -0800 (PST) X-AuditID: c1b4fb3a-f79596d000001123-e8-546476b91c8c Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 0D.F2.04387.9B674645; Thu, 13 Nov 2014 10:15:38 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.4]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0174.001; Thu, 13 Nov 2014 10:15:37 +0100 From: Ivo Sedlacek To: "sipcore@ietf.org" Thread-Topic: Comments to draft-roach-sipcore-6665-clarification-00 Thread-Index: Ac//Fvt0Tj2a9IRkR3mLh8GSWTd/9w== Date: Thu, 13 Nov 2014 09:15:36 +0000 Message-ID: <39B5E4D390E9BD4890E2B310790061011278E192@ESESSMB301.ericsson.se> 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_39B5E4D390E9BD4890E2B310790061011278E192ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvje6uspQQg/3XeSy+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujO5ZW5gLfnhUTNu0mL2B8aV9FyMnh4SAicSkSTeZIGwxiQv3 1rN1MXJxCAkcYZS4PrOLFcJZxCix4vVhdpAqNgE9iYlbjrCC2CICmhLLv20FiwsL2EmsnXqY BSLuLLHqyDlmCFtP4v/cQ2BxFgFViZ2vXjGC2LwCvhKr30wA62UUkJW4+qcXLM4sIC5x68l8 qIsEJJbsOc8MYYtKvHz8D2gvB5CtJDFtaxpEeb7E5wf/mSBGCkqcnPmEZQKj0Cwkk2YhKZuF pAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3Z xAiMiYNbflvtYDz43PEQowAHoxIP7wa5lBAh1sSy4srcQ4zSHCxK4rwLz80LFhJITyxJzU5N LUgtii8qzUktPsTIxMEp1cDoY/XL89cnufoQi4lPPYSv92yXel8fp7H3++MPut3Rsss/fVSd YBJ650DmmsWSytGlKzifz/oza6aMSKih9Pzc6ifb3pW/3r1m3vwNp329Fux3svxzNv5+WG7J r6KC3zldb7Yms4lzmzNZcqxakF4iwveY60lA8Lw1i1pczxgf+cnjcDZkT8I3JZbijERDLeai 4kQAmUhkgGoCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/kFWEJQYvQJLIDuwiYp63i0OTa-M Subject: [sipcore] Comments to draft-roach-sipcore-6665-clarification-00 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, 13 Nov 2014 09:15:49 -0000 --_000_39B5E4D390E9BD4890E2B310790061011278E192ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (a small extension below) Hello, I reviewed the draft and here are my comments: COMMENT 1: ------------------------------------------------- Section 1 states: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D The second sentence of this paragraph attempted to set context for the normative statement: the reason GRUUs are required in this context is to allow you to send SUBSCRIBE or REFER requests to a specific user agent, with the target of the subscription request being something like an INVITE dialog on that device. Consequently, the requirement to include a GRUU as a local target applies not just to the local target for SUBSCRIBE-created dialogs, but for *all* dialogs, even those created by INVITE. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D UA can have dialogs for which the UA rejects any related out-of-dialog REFE= R request (and any out-of-dialog SUBSCRIBE request). Those dialogs are simply not transferrable (and not subscribeable). Requiring GRUU for such dialogs is unnecessary. ------------------------------------------------- PROPOSED SOLUTION 1: ------------------------------------------------- Restrict the requirement above to only dialogs for which the UA is willing = to accept an out-of-dialog REFER request (or any out-of-dialog SUBSCRIBE re= quest). ------------------------------------------------- COMMENT 2: Section 1 states: ------------------------------------------------- This document updates [RFC6665] to clarify the actual requirement: "Notifiers MUST implement the Globally Routable User Agent URI (GRUU) extension defined in [RFC5627], and MUST use a GRUU as their local target for all dialog-forming methods and all target-refresh methods. This specifically includes dialogs created by the INVITE method." ------------------------------------------------- Same comment as in COMMENT 1 Kind regards Ivo Sedlacek Ericsson Mobile +420 608 234 709 ivo.sedlacek@ericsson.com www.ericsson.com This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer --_000_39B5E4D390E9BD4890E2B310790061011278E192ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(a small extension below)

 

Hello,

 

I reviewed the draft and here are my comments:

 

COMMENT 1:

-------------------------------------------------=

Section 1 states:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

   The second sentence of this paragrap= h attempted to set context for

   the normative statement: the reason = GRUUs are required in this

   context is to allow you to send SUBS= CRIBE or REFER requests to a

   specific user agent, with the target= of the subscription request

   being something like an INVITE dialo= g on that device.  Consequently,

   the requirement to include a GRUU as= a local target applies not just

   to the local target for SUBSCRIBE-cr= eated dialogs, but for *all*

   dialogs, even those created by INVIT= E.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

UA can have dialogs for which the UA rejects any = related out-of-dialog REFER request (and any out-of-dialog SUBSCRIBE request).

Those dialogs are simply not transferrable = (and not subscribeable).

Requiring GRUU for such dialogs is unnecessary.

-------------------------------------------------=

 

PROPOSED SOLUTION 1:

-------------------------------------------------=

Restrict the requirement above to only dialogs fo= r which the UA is willing to accept an out-of-dialog REFER request (or any out-of-dialog SUBSCRIBE request).

-------------------------------------------------=

 

COMMENT 2:

 

Section 1 states:

-------------------------------------------------=

   This document updates [RFC6665] to c= larify the actual requirement:

   "Notifiers MUST implement the G= lobally Routable User Agent URI (GRUU)

   extension defined in [RFC5627], and = MUST use a GRUU as their local

   target for all dialog-forming method= s and all target-refresh methods.

   This specifically includes dialogs c= reated by the INVITE method."

-------------------------------------------------=

 

Same comment as in COMMENT 1

 

Kind regards

 

Ivo Sedlacek

Ericsson

Mobile +420 608 234 709

ivo.sedlacek@ericsson.com

www.ericsson.com

 

This Communication is Confidential. We only send = and receive email on the basis of the terms set out at www.ericsson.com/ema= il_disclaimer

--_000_39B5E4D390E9BD4890E2B310790061011278E192ESESSMB301erics_-- From nobody Thu Nov 13 04:19:53 2014 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 AE3491A797C for ; Thu, 13 Nov 2014 04:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcpBI1JTvYWh for ; Thu, 13 Nov 2014 04:19:50 -0800 (PST) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697861A7028 for ; Thu, 13 Nov 2014 04:19:50 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id b13so12457444qcw.9 for ; Thu, 13 Nov 2014 04:19:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=6SHugyjPqRM81wA/VMHAjoJ2H4nLDVq4t1DPyP3OSo8=; b=MPVSf3jBSykHCdREg+sbT+Fv+YN5MrCGxX+0NE8xFxdC2k5tr8oKPPo2nS9iw2RcVH BgnY3z/KPKWSOVUwLu9kJz8AU5nLygv4HTnT67x4xNK+bySqyzCddKykGnhcYIfbnorq h0ylUNnyLI+L0UAAV4sggAsB5+p7CSREpo4wu/VJ9ua/FI1a92lc8hvHlhkRpL0EAG9z EROf5lrikMBuPvTMgo9UfDCtDo+qQVLTP/anEbxD8nUK8t0h3S5T0/Qe3O/51UlX3uRs tt/OlHVWxZWVk7XGnD9Gl7phV3ZrCvxA08z8uyb7Lc8LGHoP3xtyjx6LP/EV804GwMAQ 62VA== X-Gm-Message-State: ALoCoQlgO+8CTHg5PB9unB+SCJNLdiddwEmkGKu5XrSAFVTKFTNXy67Tx4ofzae0Clt7vReWliMb X-Received: by 10.224.130.135 with SMTP id t7mr2624302qas.95.1415881189589; Thu, 13 Nov 2014 04:19:49 -0800 (PST) From: Brett Tate References: <7594FB04B1934943A5C02806D1A2204B1D4F3BA7@ESESSMB209.ericsson.se> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHcXEc7KkuVUIOi12US5Lu2N0rvI5xFrh5Q Date: Thu, 13 Nov 2014 07:19:45 -0500 Message-ID: <29a36bf541a5de675eedf056270865b7@mail.gmail.com> To: Andrew Allen , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/JmUCQ3cgonczrJcyFHN75Ik0Hvk Subject: Re: [sipcore] draft-roach-sipcore-6665-clarification-00: comment 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, 13 Nov 2014 12:19:51 -0000 Hi, > SIP is by design verbose and explicit and entities are supposed > to determine the capabilities or properties of things using > indications in the protocol not by some other special magic > that only works within walled gardens. RFC 6665 basically says that compliant notifiers cannot be deployed within a walled garden. Do you think that operators, governments, et cetera will adhere to that mandate? RFC 3261 also mandates using globally routable Contacts. Do you think devices are only deployed that way? > I really don't see why requiring entities to add ";gr" to their > URIs that are globally routable should be an issue. Why should a notifier indicate that their Contact is globally routable when it isn't? Do you think vendors design their endpoints so that they only work when allocated a globally routable address? Even if globally routable, why should an operator be required to indicate ";gr" if they are concerned that the consequence of the indication may be poor interoperability or other non-desirable issues such as those mentioned within draft-kaplan-dispatch-gruu-problematic and draft-allen-dispatch-routing-out-of-dialog-request? Thanks, Brett From nobody Thu Nov 13 09:32:01 2014 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 C7E9A1A8BAF for ; Thu, 13 Nov 2014 09:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ak18ZdkgcgFn for ; Thu, 13 Nov 2014 09:31:58 -0800 (PST) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F48B1A8AE9 for ; Thu, 13 Nov 2014 09:31:56 -0800 (PST) Received: by mail-qg0-f49.google.com with SMTP id z60so10820488qgd.36 for ; Thu, 13 Nov 2014 09:31:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=Ko6fCNXDPyTC38Ke0DFoN0v8wxfVCbTFtF76E+3ygHg=; b=SbE2qy4gtQYvbGsqIvbLZatB6/I+SFzJvUbT5+UHWKNo+oahzblJ2PBuZVUyPMBn4W hGZzCtL6KTTgSEwdIHxE7gDHwvIIJYNwXCkOphEI9gSEY8Qnuthub6eZqz5Oc7DX9Mqe 5ZCMTYHwDuGuGNzUwRkcr5lTitZHr/6oieFhwRlC1bpcHXqbXOh0PtfiOJyAjz5EN+GQ xcApttht6aLa1cfSGwgzETiyj1bzqMNgRZFRCbJpa0ZHP5sWhgsiXk9QTswSP1M4UdO7 bfXwL9bderAjxdRu1oFSHsCHhsQg0N+s9Xr0eCVEeu7RusQ19vlSFoTY5FTXU3hH5M8m lffQ== X-Gm-Message-State: ALoCoQlXIjrShv3PFHVld9Qd9jzHUm7Y4zan3BtbHAp9+//l71r8WbfbS7XrqPzykpbr+QMd91N6 X-Received: by 10.229.115.7 with SMTP id g7mr4733064qcq.2.1415899915125; Thu, 13 Nov 2014 09:31:55 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac//Z6O7nJc9xfGTR9uU8Bj8zlFlcA== Date: Thu, 13 Nov 2014 12:31:51 -0500 Message-ID: To: draft-sparks-sipcore-refer-explicit-subscription@tools.ietf.org, sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/RXMuyFd_Vf8478CtDgLVVcF-Hv8 Subject: [sipcore] draft-sparks-sipcore-refer-explicit-subscription-02: 200 response 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, 13 Nov 2014 17:32:00 -0000 Hi, I just wanted to relay a comment that Dale made on the sip-implementors list concerning draft-sparks-sipcore-refer-explicit-subscription-02 section 4.8. The draft currently restricts the Refer-Events-At to have meaning only within 200 response instead of 2xx responses. One of the benefits of loosening up the restriction is that the RFC will not need to be updated if new 2xx response codes are defined. Thanks, Brett ----- > From: Brett Tate > Draft-sparks-sipcore-refer-explicit-subscription intends to deprecate > the use of 202 for a REFER response (i.e. updating RFC 3515). Specifically, 202 is deprecated in favor of 200. > If you think (or know) it will cause interoperability issues, please > express your concerns and/or update code as needed. I see in section 3.8 of draft-sparks-sipcore-refer-explicit-subscription-02: The 'Refer-Events-At' header field is only meaningful in a 200 response to a REFER request. If it appears in the header of any other SIP message, its meaning is undefined and it MUST be ignored. It seems to me that this is dangerously strict, and should say "is only meaningful in a *2xx* response to a REFER request". Dale From nobody Thu Nov 13 10:38:56 2014 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 A7F571A90EE for ; Thu, 13 Nov 2014 10:38:54 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 gtav39Q6rpE1 for ; Thu, 13 Nov 2014 10:38:53 -0800 (PST) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [96.114.154.171]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA6A81A90E2 for ; Thu, 13 Nov 2014 10:38:53 -0800 (PST) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-12v.sys.comcast.net with comcast id F6eU1p00553iAfU016etuo; Thu, 13 Nov 2014 18:38:53 +0000 Received: from dhcp-b28b.meeting.ietf.org ([31.133.178.139]) by resomta-po-10v.sys.comcast.net with comcast id F6cl1p00930qcoX016cnMA; Thu, 13 Nov 2014 18:36:51 +0000 Message-ID: <5464FA3E.70108@alum.mit.edu> Date: Thu, 13 Nov 2014 08:36:46 -1000 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1415903933; bh=kfWY5g4EwUyrrDhA/D2PtCxVA3AY9N3WoECQUn3cWJI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NQXqK8zDn19VocWZR969IzwfsagejezmWMoM+ZsVBCZwj8PqwVazjXZrsSH+3FEc3 PImfDNIqF2N059rpTBRJCE55hCGpol8UeIZp61cFpDYzDYT0ZXWlbYV37xrZE1mLC6 pK4lZQIxfl9GfBJ4Fu5gF2qJAdPwaCaP9Id9iMVqUIXML8N5e6Npmut1d0lNvxruit zWmEmcJIMJFZu7onLZqf5d+LmzHyrCXwMBz/BHNi/WANbg6asX1EBMXb6EVL/vLo5Z ESiWzo8iMkYgoeB6gQ/W183D7A1TQIq5QpeorQX/Nb4appirHTDzRU8ZP9MHlf8Wrv AR7z22YKgA66A== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Hq3_tBJwC65UJNya_DpqgQy71jE Subject: [sipcore] Note takers for the SIPCORE session TODAY 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, 13 Nov 2014 18:38:54 -0000 To avoid a delay in the meeting while we seek note takers, who will volunteer to take notes in SIPCORE today? - note taker (two desired) - jabber scribe As a reward to note takers, I will give you a "get out of note-taking jail" card for non-SIPCORE sessions. (Of course these are non-binding on other chairs.) Thanks, Paul From nobody Thu Nov 13 11:20:24 2014 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 A41421ACD4D for ; Thu, 13 Nov 2014 11:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 5LrlM2y1xRtV for ; Thu, 13 Nov 2014 11:20:09 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 7FC711ACD18 for ; Thu, 13 Nov 2014 11:13:21 -0800 (PST) Received: from dhcp-b418.meeting.ietf.org (dhcp-b418.meeting.ietf.org [31.133.180.24]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sADJDFoa027809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Nov 2014 13:13:16 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <546502CA.3020907@nostrum.com> Date: Thu, 13 Nov 2014 09:13:14 -1000 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Brett Tate , draft-sparks-sipcore-refer-explicit-subscription@tools.ietf.org, sipcore@ietf.org References: <54610E3E.8030003@nostrum.com> <16c53b2416e5d5ae6e327d9b7d0399ed@mail.gmail.com> <54611ED5.2020809@nostrum.com> <54612BC5.5060201@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/xVJruB0ymzind2gQ8yWv7hsGUCg Subject: Re: [sipcore] draft-sparks-sipcore-refer-explicit-subscription-02: comments 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, 13 Nov 2014 19:20:17 -0000 I think I found our disconnect: On 11/11/14 2:39 AM, Brett Tate wrote: > Hi, > > Thanks for the response; reply is inline. > >>>>>> Was that text problematic for you? >>>>> The proposal continues to mandate that the option-tag only be >>>>> honored if received within a Require header of REFER. >>>>> >>>>> If REFER is received within dialog, mandating that the UAS return a >>>>> 421 appears to do nothing but require extra messaging for those >>>>> attempting to use it. I recommend allowing behavior similar to RFC >>>>> 3262 so that the option tag can be within Supported of mid-dialog >>>>> REFER and Require of REFER's 2xx response. >>>> We _specifically_ avoided that design. It takes us into the "I don't >>>> know if this will create a subscription or not when I send the REFER" >>>> territory. >> So, there are two things I think you're trying to talk about. I'm going >> to draw lines around them just to double-check that I'm hearing >> you correctly. >> >> First is the suggestion to change how we're using Supported/Require. >> >> I don't understand yet why you would _want_ to send a REFER >> with Supported: explicitsub and learn later whether the other >> side chose to use an implicit subscription or an explicit subscription, >> signaled in the 200 OK to the REFER. >> >> Essentially, you are positing "I don't care as a client, you choose >> as the server". I don't think we have a need for that, and trying >> to support something like it is what led norefersub to being >> what it is. > That is not my proposal. If the client cares, they can use Require or not > include option-tag within Supported. My proposal is that if the client sent > mid-dialog REFER with Supported indicating one or both new option-tags, > there is no reason to mandate returning 421 if the UAS desires to use the > feature. > > Why do you want to restrict the functionality so that it can only be used if > option-tag sent within REFER's Require header? So that you don't end up with dialog reuse, which is an essential goal of this extension. If you allow the case you're suggesting, where the REFER only contains Supported: explicitsub and the server didn't implement the extension, or just chose not to use it, then you end up with a shared dialog via an implicit subscription. > The working group (and RFC > 4485) typically discourages the use of Require within requests unless truly > needed. Preventing the dialog reuse is the essence of "needed" here. > Depending upon interpretation of RFC 4485's "basic SIP services", > the use of Require is potentially "NOT RECOMMENDED". > > >> When you are in a dialog, you have the opportunity to see that the >> extension >> is supported before you start preparing your in-dialog refer by watching >> Supported in the transactions earlier in the dialog. If your peer hasn't >> been >> playing nicely and telling you about what it supports, you can probe by >> sending the REFER with the require and see the 421. That is not new >> behavior >> defined by this draft >> - it's basic 3261. > I agree. However, it isn't basic SIP to restrict option-tag related > functionality to only occur when the request uses the Require header unless > there is truly a need for the restriction. > > >> Our case here is different from 100rel. The semantic there is that the >> server >> gets to invoke _using_ the extension because it's the thing that knows >> whether the extension is needed. It's been a fundamental point of this >> proposal from the beginning that this is a decision that the client is >> going to >> make. > If they want/have to make the decision, they can use the Require. If they > don't want/need to decide, they should be able to use Supported within > mid-dialog REFER without requiring the subsequent 421 to occur. > > >>> If referrer sends a REFER within dialog without using the Require, >>> they know that it might create a subscription since they don't know if >>> the option-tag is supported. The 2xx response can indicate if it did >>> create a subscription by supplying Require indicating what occurred. >>> >>> If the desire is to allow RFC 6665 compliant device to send REFER over >>> dialog during GRUU situation, they would need to use the Require >>> (AFAIK). >> If I'm reading you correctly, your second comment is that the draft isn't >> clear >> enough that if you are requiring explicitsub (or nosub), the REFER request >> itself isn't bound by the requirements of 3265 since its contact isn't >> used in >> setting up a subscription. I'll go look at the draft between meetings (I'm >> in >> other sessions right now), and see if I can pump that up. > The draft might be adequate from referrer perspective (I didn't perform a > detailed search). However as indicated below, I haven't noticed how the > draft enables a RFC 6665 compliant notifier from needing to supply GRUU > Contact within call dialog (i.e. as mentioned within > draft-sparks-sipcore-refer-clarifications-05 section 3 last paragraph). This is confused, or I'm not following what you're looking for yet. The point is that if you send a REFER within a dialog using these extensions, you are guaranteed to not engage in sip-events as part of this dialog, so the 6665 requirements on what contact you provide in this dialog do not kick in. The fact that the endpoint is otherwise an RFC6665 compliant notifier isn't relevant to the dialog in this case (unless it might enter into _other_ sip-event dialog-usages as part of this dialog. > > >>> I still haven't noticed how the draft avoids RFC 6665 compliant >>> notifier from needing to supply GRUU Contact within call dialog. >>> >>> >>>> You have Supported around _before_ you get to sending the REFER >>>> require to help you avoid discovering lack of support by trying to >>>> require it if you care about that extra messaging. >>> If the REFER was sent within dialog, the lack of support/use would be >>> observed by receiving REFER's 2xx response without Require option-tag. >>> >>> The referrer can use Require when REFER sent outside of dialog (or >>> within dialog if desired) if they want to avoid ambiguity during forking >> situation. >>> Thanks, >>> Brett Thanks for helping work this through, RjS From nobody Thu Nov 13 11:20:44 2014 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 7EBE11ACD6B for ; Thu, 13 Nov 2014 11:20:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 hnX63vV3CnOB for ; Thu, 13 Nov 2014 11:20:30 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 910DA1ACDB8 for ; Thu, 13 Nov 2014 11:14:12 -0800 (PST) Received: from dhcp-b418.meeting.ietf.org (dhcp-b418.meeting.ietf.org [31.133.180.24]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sADJEBqS027873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 13 Nov 2014 13:14:12 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <54650303.1050209@nostrum.com> Date: Thu, 13 Nov 2014 09:14:11 -1000 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Bt6YZyjLXCIqvAhxnx7HHwsDsfQ Subject: Re: [sipcore] draft-sparks-sipcore-refer-explicit-subscription-02: 200 response 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, 13 Nov 2014 19:20:35 -0000 This looks like a reasonable change to me. On 11/13/14 7:31 AM, Brett Tate wrote: > Hi, > > I just wanted to relay a comment that Dale made on the sip-implementors > list concerning draft-sparks-sipcore-refer-explicit-subscription-02 > section 4.8. > > The draft currently restricts the Refer-Events-At to have meaning only > within 200 response instead of 2xx responses. > > One of the benefits of loosening up the restriction is that the RFC will > not need to be updated if new 2xx response codes are defined. > > Thanks, > Brett > > ----- > >> From: Brett Tate >> Draft-sparks-sipcore-refer-explicit-subscription intends to deprecate >> the use of 202 for a REFER response (i.e. updating RFC 3515). > Specifically, 202 is deprecated in favor of 200. > >> If you think (or know) it will cause interoperability issues, please >> express your concerns and/or update code as needed. > I see in section 3.8 of > draft-sparks-sipcore-refer-explicit-subscription-02: > > The 'Refer-Events-At' header field is only meaningful in a 200 > response to a REFER request. If it appears in the header of any > other SIP message, its meaning is undefined and it MUST be ignored. > > It seems to me that this is dangerously strict, and should say "is only > meaningful in a *2xx* response to a REFER request". > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Nov 14 06:01:10 2014 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 711AC1A010E for ; Fri, 14 Nov 2014 06:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCG--SKgEvLO for ; Fri, 14 Nov 2014 06:00:58 -0800 (PST) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961D11A010D for ; Fri, 14 Nov 2014 06:00:58 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id l6so12872255qcy.1 for ; Fri, 14 Nov 2014 06:00:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to:content-type; bh=1SlFRWfo0jZnd2xao/lGUq/+fT5f0O7JXcLNhHA5bOE=; b=HfRdVGeljyPe66GhmibmxTWj1VZHiVa0rikSHv81xoGCfZVQnjSn7kBdADVAM6jGT8 bRfXo7Pa4IaXxQkCcwLdh9HgaOFuCoq153hT+RLLZYhH6YLrIuh+BvE9JI5+yzD2LrsN j/7K/JvV1C/1v91vLlCpOElqfcMLLxMdH0vxYqYr3L6LgBC4BNP6Jx6E1VThtd8J+pwk KoKGvPsr6LshrwuDg2ot9nJtsweqv/jNQPyPKhbBFdm9O02EZ+qs8D3FBFs+Nt8rneOK 9+s/oo+AIsDAXdH3jxTJDUUKiTJ4fAtzOpwoJbUbbdnjp60K7PvoOVHfcJvhJ2eXQ1Tc 8crw== X-Gm-Message-State: ALoCoQmZz8jyUCbZFIO3pvG3hJhUejMzcW/p+XF5PGAbTp7ki5lvC12PZYxQmMA0KlICENM96PXv X-Received: by 10.140.25.208 with SMTP id 74mr11406211qgt.18.1415973657741; Fri, 14 Nov 2014 06:00:57 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAAE2JECmhaNrgMQ+OBebBHI6+OKQ== Date: Fri, 14 Nov 2014 09:00:56 -0500 Message-ID: <800c20ed395ea97f1bbb22caaf0fbc19@mail.gmail.com> To: draft-sparks-sipcore-refer-explicit-subscription@tools.ietf.org, sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/AYLlTM9pdZVSCXgq5iOLFrI0dRg Subject: Re: [sipcore] draft-sparks-sipcore-refer-explicit-subscription-02: comments 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, 14 Nov 2014 14:01:02 -0000 Hi, Thanks for the response; reply is inline. > So that you don't end up with dialog reuse, which is an essential > goal of this extension. If you allow the case you're suggesting, > where the REFER only contains Supported: explicitsub > and the server didn't implement the extension, or just chose > not to use it, then you end up with a shared dialog via an implicit > subscription. 1) RFC 6665 specifies that the referrer cannot send REFER over the dialog if target is a GRUU. 2) Draft-sparks-sipcore-refer-explicit-subscription section 6 allows number 1 to be ignored by sending REFER without Require and with Supported. Supposedly this is because the referrer is aware that one or both of the option tags are supported. "A User-Agent Server (UAS) that is processing a REFER request that lists 'explicitsub' or 'nosub' in its Supported header field and wishes to use one of those extensions will return a 421 response indicating which extension is required." 3) When number 2 occurs for a mid-dialog REFER, the draft mandates returning 421 instead of allowing returning a 2xx with Require header containing the selected option-tag. I'm saying that number 3 is useless extra messaging. Number 2 was compliant or non-compliant; there is no reason to require returning 421 since the 2xx can communicate the selected behavior. > > The working group (and RFC4485) typically discourages the > > use of Require within requests unless truly needed. > > Preventing the dialog reuse is the essence of "needed" here. Number 2 was compliant or non-compliant; number 3 does not rectify anything. > This is confused, or I'm not following what you're looking for yet. Draft-sparks-sipcore-refer-clarifications-05 section 3 indicates the following. "A UA that will accept a REFER request needs to include a GRUU in the Contact header field of all INVITE requests. This ensures that out- of-dialog REFER requests corresponding to any resulting INVITE dialogs arrive at this UA. Future extensions (such as [I-D.sparks-sipcore-refer-explicit-subscription]) might relax this requirement by defining a REFER request that cannot create an implicit subscription." If something within draft-sparks-sipcore-refer-explicit-subscription allows a RFC 6665 compliant notifier to not supply a GRUU Contact within call's dialog, please clearly indicate it. For instance if the following is true, indicate that the notifier is not required to supply a GRUU Contact if notifier supports 'nosub' (even if referrer does not support 'nosub'). Thanks, Brett From nobody Fri Nov 14 06:29:04 2014 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 BC8381A19F4 for ; Fri, 14 Nov 2014 06:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlDmCqhIVAKb for ; Fri, 14 Nov 2014 06:29:02 -0800 (PST) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212021A19E5 for ; Fri, 14 Nov 2014 06:29:02 -0800 (PST) Received: by mail-qg0-f48.google.com with SMTP id q108so12136220qgd.35 for ; Fri, 14 Nov 2014 06:29:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type :content-transfer-encoding; bh=BiL91TFUwYxRnQ9jEvHc0r6KuFLHp8tVDuNeKxxz8tE=; b=kshJpJlS1pNA+Fx8yWK2zHYZK3+y1LAIv4BNNLtU7WVpvCD9rD/r9RY+bFiJT7FS06 MG3rwlioktc15YLQBZgwh2shCgbCtboTL2yBi1a2iiY/x4wnbUIf/k3qN3e3NvgFBvGn zYeRcZ58kXNdj5OeChCLey4hbPnpknlQmsyWoJa3GYhv7aCPl5cjv7kkw40UwLfwdmjj A0Uf8KeRIReC6DwXgQug4xE2y/gnFJriLsgG5tDBJEtfXDE8I+EhrbmuwTSzCurAxVkf Ff8ZRrSW6yHFqRu5Zjpsq/WY60MC5g6EN1GRUGAQoBrXtggddECIkX69uEi78eXoaMIW rWdA== X-Gm-Message-State: ALoCoQmnb3nOMXk1k7wpil5ILeMIiqyqyO60WDzySGoqC4vj2J1LvJ3EUQYaGo83bkv/RpsrncOw X-Received: by 10.229.209.136 with SMTP id gg8mr11772805qcb.16.1415975341330; Fri, 14 Nov 2014 06:29:01 -0800 (PST) From: Brett Tate References: <39B5E4D390E9BD4890E2B310790061011278E192@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B310790061011278E192@ESESSMB301.ericsson.se> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHJG9cbz7m2Lf6iOn3n7mZ6ZTN9RJxt9rVA Date: Fri, 14 Nov 2014 09:29:00 -0500 Message-ID: <128feace0c9075f945faa5117a915841@mail.gmail.com> To: Ivo Sedlacek , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/SN6Fq-tEIBWu5MGuhBTgOGjWygc Subject: Re: [sipcore] Comments to draft-roach-sipcore-6665-clarification-00 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, 14 Nov 2014 14:29:03 -0000 I agree with Ivo's comments. --- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek Sent: Thursday, November 13, 2014 4:16 AM To: sipcore@ietf.org Subject: [sipcore] Comments to draft-roach-sipcore-6665-clarification-00 (a small extension below) Hello, I reviewed the draft and here are my comments: COMMENT 1: ------------------------------------------------- Section 1 states: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D =C2=A0=C2=A0 The second sentence of this paragraph attempted to set context= for =C2=A0=C2=A0 the normative statement: the reason GRUUs are required in this =C2=A0=C2=A0 context is to allow you to send SUBSCRIBE or REFER requests to= a =C2=A0=C2=A0 specific user agent, with the target of the subscription reque= st =C2=A0=C2=A0 being something like an INVITE dialog on that device.=C2=A0 Co= nsequently, =C2=A0=C2=A0 the requirement to include a GRUU as a local target applies no= t just =C2=A0=C2=A0 to the local target for SUBSCRIBE-created dialogs, but for *al= l* =C2=A0=C2=A0 dialogs, even those created by INVITE. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D UA can have dialogs for which the UA rejects any related out-of-dialog REFER request (and any out-of-dialog SUBSCRIBE request). Those dialogs are simply not transferrable (and not subscribeable). Requiring GRUU for such dialogs is unnecessary. ------------------------------------------------- PROPOSED SOLUTION 1: ------------------------------------------------- Restrict the requirement above to only dialogs for which the UA is willing to accept an out-of-dialog REFER request (or any out-of-dialog SUBSCRIBE request). ------------------------------------------------- COMMENT 2: Section 1 states: ------------------------------------------------- =C2=A0=C2=A0 This document updates [RFC6665] to clarify the actual requirem= ent: =C2=A0=C2=A0 "Notifiers MUST implement the Globally Routable User Agent URI= (GRUU) =C2=A0=C2=A0 extension defined in [RFC5627], and MUST use a GRUU as their l= ocal =C2=A0=C2=A0 target for all dialog-forming methods and all target-refresh m= ethods. =C2=A0=C2=A0 This specifically includes dialogs created by the INVITE metho= d." ------------------------------------------------- Same comment as in COMMENT 1 Kind regards Ivo Sedlacek Ericsson Mobile +420 608 234 709 ivo.sedlacek@ericsson.com www.ericsson.com This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer From nobody Fri Nov 14 09:28:41 2014 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 1232D1A8891 for ; Fri, 14 Nov 2014 02:23:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.496 X-Spam-Level: X-Spam-Status: No, score=-107.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-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 Db0kWiK03cHe for ; Fri, 14 Nov 2014 02:23:47 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id BFCFE1A88A3 for ; Fri, 14 Nov 2014 02:23:47 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id AD1F9181C7D; Fri, 14 Nov 2014 02:23:10 -0800 (PST) To: mary.ietf.barnes@gmail.com, francois.audet@skype.net, shida@ntt-at.com, ietf.hanserik@gmail.com, christer.holmberg@ericsson.com, rlb@ipv.sx, alissa@cooperw.in, adam@nostrum.com, pkyzivat@alum.mit.edu X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20141114102310.AD1F9181C7D@rfc-editor.org> Date: Fri, 14 Nov 2014 02:23:10 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/n_i84JdWgvOHoZVwqyj5SxoQrVA X-Mailman-Approved-At: Fri, 14 Nov 2014 09:28:38 -0800 Cc: rfc-editor@rfc-editor.org, sipcore@ietf.org Subject: [sipcore] [Editorial Errata Reported] RFC7044 (4181) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 10:23:49 -0000 The following errata report has been submitted for RFC7044, "An Extension to the Session Initiation Protocol (SIP) for Request History Information". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7044&eid=4181 -------------------------------------- Type: Editorial Reported by: Hans Erik van Elburg Section: 9.3 Original Text ------------- 9.3. Receiving a Response with History-Info or Request Timeouts Corrected Text -------------- 9.3. Receiving a Response or Request times out Notes ----- The title of section 9.3 is misleading in the sense that it suggests that it only applies to responses that contain the History-Info header. This is not correct, it applies to all responses when the RFC7044 applies. 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. -------------------------------------- RFC7044 (draft-ietf-sipcore-rfc4244bis-12) -------------------------------------- Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Publication Date : February 2014 Author(s) : M. Barnes, F. Audet, S. Schubert, J. van Elburg, C. Holmberg Category : PROPOSED STANDARD Source : Session Initiation Protocol Core Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Wed Nov 19 12:06:57 2014 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 8B0D71AD4B1 for ; Wed, 19 Nov 2014 12:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.594] 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 DyBERROE7dUW for ; Wed, 19 Nov 2014 12:06:53 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B3AF31AD4F2 for ; Wed, 19 Nov 2014 12:05:42 -0800 (PST) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAJK5cD5050455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Nov 2014 14:05:38 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <546CF80D.4010005@nostrum.com> Date: Wed, 19 Nov 2014 14:05:33 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Brett Tate , draft-sparks-sipcore-refer-clarifications@tools.ietf.org, sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/clruFwuAsa8wwUS27e5MAWVV0dc Subject: Re: [sipcore] draft-sparks-sipcore-refer-clarifications-05: comments 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, 19 Nov 2014 20:06:55 -0000 On 11/10/14 12:28 PM, Brett Tate wrote: > Hi, > > Draft-sparks-sipcore-refer-clarifications-05 section 3 indicates the > following: > > "A UA that will accept a REFER request needs to include a GRUU in the > Contact header field of all INVITE requests. This ensures that out- > of-dialog REFER requests corresponding to any resulting INVITE > dialogs arrive at this UA. Future extensions (such as > [I-D.sparks-sipcore-refer-explicit-subscription]) might relax this > requirement by defining a REFER request that cannot create an > implicit subscription." > > Concerning the first sentence, potentially should reword so that it isn't > just for INVITE. > > Is there a reason why not relaxing the requirement for REFER notifiers > which only send NOTIFY with Subscription-State terminated? Such a thing would be very unusual (you are required to send an immediate NOTIFY - so you're talking about an endpoint that can always _immediately_ send a notify with subscription-state terminated. Unless it's lying about the result of the referenced request, that means it's guaranteed to immediately know the result of that request (usually an INVITE). But even if you could guarantee such unique conditions, there is always the possibility that the NOTIFY could be answered with a 503/Retry-After, or any other response indicating that the NOTIFY needs to be reconditioned and submitted again, during which time there is dialog reusage. > > For instance, RFC 6665 section 4.4.1 indicates that the NOTIFY does not > create a dialog usage. > > "Dialogs usages are created upon completion of a NOTIFY transaction > for a new subscription, unless the NOTIFY request contains a > "Subscription-State" of "terminated."" Sigh. I should have argued harder for "created and immediately destroyed" when we were working on 6665 instead settling on this text, because of the possibility pointed to above of getting a non-200 response that indicates something should be changed (or delayed) and the request resubmitted. > > Thanks, > Brett From nobody Thu Nov 20 11:50:34 2014 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 F18491ABD3C for ; Thu, 20 Nov 2014 11:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 fMafsvvLNBKn for ; Thu, 20 Nov 2014 11:50:23 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A4E551ABD39 for ; Thu, 20 Nov 2014 11:50:23 -0800 (PST) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAKJoIAG086761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Nov 2014 13:50:18 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <546E45F5.30302@nostrum.com> Date: Thu, 20 Nov 2014 13:50:13 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Brett Tate , draft-sparks-sipcore-refer-explicit-subscription@tools.ietf.org, sipcore@ietf.org References: <800c20ed395ea97f1bbb22caaf0fbc19@mail.gmail.com> In-Reply-To: <800c20ed395ea97f1bbb22caaf0fbc19@mail.gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/SL4uQE4GGxRuPp0_1fRtJSZlQNY Subject: Re: [sipcore] draft-sparks-sipcore-refer-explicit-subscription-02: comments 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, 20 Nov 2014 19:50:31 -0000 On 11/14/14 8:00 AM, Brett Tate wrote: > Hi, > > Thanks for the response; reply is inline. > >> So that you don't end up with dialog reuse, which is an essential >> goal of this extension. If you allow the case you're suggesting, >> where the REFER only contains Supported: explicitsub >> and the server didn't implement the extension, or just chose >> not to use it, then you end up with a shared dialog via an implicit >> subscription. > 1) RFC 6665 specifies that the referrer cannot send REFER over the dialog if > target is a GRUU. > > 2) Draft-sparks-sipcore-refer-explicit-subscription section 6 allows number > 1 to be ignored by sending REFER without Require and with Supported. > Supposedly this is because the referrer is aware that one or both of the > option tags are supported. > > "A User-Agent > Server (UAS) that is processing a REFER request that lists > 'explicitsub' or 'nosub' in its Supported header field and wishes to > use one of those extensions will return a 421 response indicating > which extension is required." I don't see how that text allows you to ignore 1). If I'm missing that, please point it out and we'll fix it. If you're in an INVITE dialog whose peer has provided a GRUU contact, and you construct a REFER, and there's any chance you might create an implicit subscription, you have to send it out of dialog. I don't see where you draw the conclusion that allowing these tokens in Supported changes that. To make sure I'm being clear, this means that you MUST NOT send that REFER in-dialog with either of these tokens only in a Supported header, because the far end has the option to create an implicit subscription, and the draft already covers that case. You _could_ chose to send the out-of-dialog refer with one of the tokens in Supported, and none in Require. As the document is currently written, the peer could choose to accept the REFER without invoking the extension, creating a dialog through the implicit subscription that results. If the peer was unwilling to do that, and wanted to use the extension, it would return the 421 saying to do so. I think your argument, then, reduces to the opportunity for optimizing out the 421 and resubmission of REFER in that out-of-dialog case. I don't believe we need that optimization, but the group should discuss it. For completeness, if you're talking about an in-dialog REFER where the peer has _not_ provided a GRUU as his contact, you're talking to a peer that has not implemented 6665 yet - the backwards-compatibility fallback is for things that are already deployed and that don't know that the standard has moved on. Such things aren't going to know these extensions either. > > 3) When number 2 occurs for a mid-dialog REFER, > the draft mandates returning > 421 instead of allowing returning a 2xx with Require header containing the > selected option-tag. > > I'm saying that number 3 is useless extra messaging. Number 2 was compliant > or non-compliant; there is no reason to require returning 421 since the 2xx > can communicate the selected behavior. > > >>> The working group (and RFC4485) typically discourages the >>> use of Require within requests unless truly needed. >> Preventing the dialog reuse is the essence of "needed" here. > Number 2 was compliant or non-compliant; number 3 does not rectify anything. > > > > >> This is confused, or I'm not following what you're looking for yet. > Draft-sparks-sipcore-refer-clarifications-05 section 3 indicates the > following. > > "A UA that will accept a REFER request needs to include a GRUU in the > Contact header field of all INVITE requests. This ensures that out- > of-dialog REFER requests corresponding to any resulting INVITE > dialogs arrive at this UA. Future extensions (such as > [I-D.sparks-sipcore-refer-explicit-subscription]) might relax this > requirement by defining a REFER request that cannot create an > implicit subscription." > > If something within draft-sparks-sipcore-refer-explicit-subscription allows > a RFC 6665 compliant notifier to not supply a GRUU Contact within call's > dialog, please clearly indicate it. For instance if the following is true, > indicate that the notifier is not required to supply a GRUU Contact if > notifier supports 'nosub' (even if referrer does not support 'nosub'). > > Thanks, > Brett From nobody Thu Nov 20 12:14:50 2014 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 AE6121AC529 for ; Thu, 20 Nov 2014 12:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 sym1BXtb4kLn for ; Thu, 20 Nov 2014 12:14:39 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 9EDF71AC44A for ; Thu, 20 Nov 2014 12:14:34 -0800 (PST) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAKKEUdu088841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Nov 2014 14:14:31 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <546E4BA2.7040202@nostrum.com> Date: Thu, 20 Nov 2014 14:14:26 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Brett Tate , draft-sparks-sipcore-refer-explicit-subscription@tools.ietf.org, sipcore@ietf.org References: <800c20ed395ea97f1bbb22caaf0fbc19@mail.gmail.com> In-Reply-To: <800c20ed395ea97f1bbb22caaf0fbc19@mail.gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/zBXsiSiq3LL_qhYcVFZ_WDx3lYc Subject: Re: [sipcore] draft-sparks-sipcore-refer-explicit-subscription-02: comments 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, 20 Nov 2014 20:14:48 -0000 Replying to the other section of this mail (and snipping the part I just replied to): On 11/14/14 8:00 AM, Brett Tate wrote: > Hi, >> This is confused, or I'm not following what you're looking for yet. > Draft-sparks-sipcore-refer-clarifications-05 section 3 indicates the > following. > > "A UA that will accept a REFER request needs to include a GRUU in the > Contact header field of all INVITE requests. This ensures that out- > of-dialog REFER requests corresponding to any resulting INVITE > dialogs arrive at this UA. Future extensions (such as > [I-D.sparks-sipcore-refer-explicit-subscription]) might relax this > requirement by defining a REFER request that cannot create an > implicit subscription." > > If something within draft-sparks-sipcore-refer-explicit-subscription allows > a RFC 6665 compliant notifier to not supply a GRUU Contact within call's > dialog, please clearly indicate it. For instance if the following is true, > indicate that the notifier is not required to supply a GRUU Contact if > notifier supports 'nosub' (even if referrer does not support 'nosub'). Ah - ok - I think I understand, and I think I can build clearer text. Nothing in draft-sparks-sipcore-refer-explicit-subscription will allow an RFC 6665 compliant notifier to not supply a GRUU Contact withing a call's dialog. What it does do is allow that endpoint to avoid becoming an RFC6665 notifier in the context of this dialog. The statement about relaxing needs to make it clear that since the REFER request cannot create an implicit subscription, accepting it doesn't make you a notifier. In fact, SIP events is not involved at all, so none of requirements in 6665 don't come to bear. I'll work on building words that makes that more obvious. > > Thanks, > Brett From nobody Fri Nov 21 11:19:03 2014 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 6DAB11A039A for ; Fri, 21 Nov 2014 11:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 ZJg7kypi5K2V for ; Fri, 21 Nov 2014 11:18:59 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A9B641A0392 for ; Fri, 21 Nov 2014 11:18:59 -0800 (PST) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sALJIwgU015443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 21 Nov 2014 13:18:59 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <546F901E.6090604@nostrum.com> Date: Fri, 21 Nov 2014 13:18:54 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "sipcore@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/m1FYB_yMIXU1fUTCWfO6iWnhR5M Subject: [sipcore] WG -00 versions of refer-clarifications and refer-explicit-subscription 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, 21 Nov 2014 19:19:01 -0000 I have submitted -00s for the two drafts in the subject line. They should appear in the archive and a pointer will be sent to the list when the chairs clear them from -00 approval jail. As we discussed in Hawaii, I tried to take the list comments to date into account. This had notable impact on some text in the clarifications draft. I finally wrapped my head around what Ivo and Brett were saying about what 6665 and the 6665-clarifications document actually requires vs what the earlier versions of refer-clarifications claimed it requires. Please review the diffs carefully. I have not yet changed the way the explicit-subscription draft says to use 421. That discussion is still ongoing on-list. RjS From nobody Fri Nov 21 15:19:11 2014 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 5EC481A902B; Fri, 21 Nov 2014 15:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 SxxqG-qVdbC8; Fri, 21 Nov 2014 15:19:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 994001A9026; Fri, 21 Nov 2014 15:19:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141121231904.11706.25046.idtracker@ietfa.amsl.com> Date: Fri, 21 Nov 2014 15:19:04 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/1_kw0MrwRagEk8g6PkRHdmSeUTc Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-refer-explicit-subscription-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 23:19:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Explicit Subscriptions for the REFER Method Author : Robert Sparks Filename : draft-ietf-sipcore-refer-explicit-subscription-00.txt Pages : 14 Date : 2014-11-21 Abstract: The Session Initiation Protocol (SIP) REFER request, as defined by RFC3515, triggers an implicit SIP-Specific Event Notification framework subscription. Conflating the start of the subscription with handling the REFER request makes negotiating SUBSCRIBE extensions impossible, and complicates avoiding SIP dialog sharing. This document defines extensions to REFER to remove the implicit subscription and, if desired, replace it with an explicit one. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-explicit-subscription/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-refer-explicit-subscription-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Nov 21 15:19:35 2014 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 D27D91A9040; Fri, 21 Nov 2014 15:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 XB6bATYd8oxc; Fri, 21 Nov 2014 15:19:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1BDE1A9036; Fri, 21 Nov 2014 15:19:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> Date: Fri, 21 Nov 2014 15:19:18 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/_kTWLDaMgZskA0JAonL6ZC82xHs Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 23:19:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Clarifications for the use of REFER with RFC6665 Authors : Robert Sparks Adam Roach Filename : draft-ietf-sipcore-refer-clarifications-00.txt Pages : 6 Date : 2014-11-21 Abstract: The SIP REFER method relies on the SIP-Specific Event Notification Framework. That framework was revised by RFC6665. This document highlights the implications of the requirement changes in RFC6665, and updates the definition of the REFER method, RFC3515, to clarify and disambiguate the impact of those changes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarifications/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-refer-clarifications-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 25 03:20:13 2014 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 AFD251A00B9 for ; Tue, 25 Nov 2014 03:20:10 -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 i7Ezqvs5yHhv for ; Tue, 25 Nov 2014 03:20:03 -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 3A2351A00EB for ; Tue, 25 Nov 2014 03:20:02 -0800 (PST) X-AuditID: c1b4fb30-f79e66d000000ff1-f6-547465e09810 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 47.88.04081.0E564745; Tue, 25 Nov 2014 12:20:00 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.101]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 12:19:59 +0100 From: Ivo Sedlacek To: "sipcore@ietf.org" Thread-Topic: Precondition and swap of 200 (OK) for INVITE and 200 (OK) for UPDATE Thread-Index: AdAIobIU/X3RKFytS+CJybDMOoda2Q== Date: Tue, 25 Nov 2014 11:19:58 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127A248D@ESESSMB301.ericsson.se> 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: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101127A248DESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyM+Jvje6D1JIQg3tzhSy+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJnnZrAVdPYxVUx/tYStgfHZS8YuRk4OCQETiUsrf7JC2GIS F+6tZ+ti5OIQEjjCKPF+9QFWCGcJo0THhytgVWwCehITtxwBs0UENCWWf9vKDmILC/hK/Ni6 gQ0iHiKxv/kJE4StJ3Hk5XywOIuAqsShVXvAbF6g+mW3P4DZjAKyElf/9IJdxCwgLnHryXwm iIsEJJbsOc8MYYtKvHz8D+pSRYmPr/ZB1edLtB68wQwxU1Di5MwnLBMYhWYhGTULSdksJGUQ cR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZg ZBzc8ttgB+PL546HGAU4GJV4eDd8KA4RYk0sK67MPcQozcGiJM678Ny8YCGB9MSS1OzU1ILU ovii0pzU4kOMTBycUg2MGel9W4OOS7u0cuiE2J94wbP6qVzQtqt/Ha8ez/7Q/nUWf/WJtm1L pcpvvXmefWDBmY/6kz4umHNhc+pGobvmOkptXza1vdz55GhNwEF7Rd6drEwCB612275yCFJN dvcQUWyYfjxtxmdxF46rsf4mrxmsH5WkPG/Ic//KeuhP2erqT1nKsSc6lFiKMxINtZiLihMB h/K+T20CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/P6JRO-KM8fSktIasm_DyUA3bN0o Subject: [sipcore] Precondition and swap of 200 (OK) for INVITE and 200 (OK) for UPDATE 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, 25 Nov 2014 11:20:10 -0000 --_000_39B5E4D390E9BD4890E2B31079006101127A248DESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, can anyone please give advice on the following problem related to precondit= ion usage in SIP session? Use case: - Alice is a mobile phone - AS is an network based announcement service. AS accepts any received INVI= TE request, sends audio with 24 hour weather forecast, and hangs up. - Alice and AS use precondition with segmented status type to indicate stat= e of their resources, Alice needs to reserve resources for the call, AS alw= ays have resources available when call setup - the normal flow for the call is: Alice AS | | |-------------(1) INVITE SDP1--------------->| | | |<------(2) 183 Session Progress SDP2--------| | *** | |--*R*-----------(3) PRACK------------------>| | *E* | |<-*S*-------(4) 200 OK (PRACK)--------------| | *E* | | *R* | | *V* | | *A* | | *T* | | *I* | | *O* | | *N* | | *** | | *** | | *** | |-------------(5) UPDATE SDP3--------------->| | | |<--------(6) 200 OK (UPDATE) SDP4-----------| | | |<-----------(7) 200 OK (INVITE)-------------| | | |------------------(8) ACK------------------>| | | QUESTION: What is expected Alice's behavior if message (6) and message (7) = happened to be swapped during transport from AS to Alice, as shown below? Alice AS | | |-------------(1) INVITE SDP1--------------->| | | |<------(2) 183 Session Progress SDP2--------| | *** | |--*R*-----------(3) PRACK------------------>| | *E* | |<-*S*-------(4) 200 OK (PRACK)--------------| | *E* | | *R* | | *V* | | *A* | | *T* | | *I* | | *O* | | *N* | | *** | | *** | | *** | |-------------(5) UPDATE SDP3--------------->| | | | +-(6) 200 OK (UPDATE) SDP4-----------| | | | |<-----------(7) 200 OK (INVITE)-------------| | | | |<------+ | In my opinion: - when receiving message (7), Alice should consider the call as established= since 200 (OK) response is received for INVITE request. Alice should send = media according to SDP2 as SDP answer to SDP3 has not been received yet. - when receiving message (6), Alice should start sending media according to= SDP4. Any views? Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B31079006101127A248DESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

can anyone please give advice on the following problem = related to precondition usage in SIP session?

 

Use case:

- Alice is a mobile phone

- AS is an network based announcement service. AS accep= ts any received INVITE request, sends audio with 24 hour weather forecast, = and hangs up.

- Alice and AS use precondition with segmented status t= ype to indicate state of their resources, Alice needs to reserve resources = for the call, AS always have resources available when call setup

- the normal flow for the call is:

 

          =      Alice      &nbs= p;            &= nbsp;           &nbs= p;        AS

 

         &= nbsp;     |       &n= bsp;            = ;            &n= bsp;           |

         &= nbsp;     |-------------(1) INVITE SDP1---------------&= gt;|

         &= nbsp;     |       &n= bsp;            = ;            &n= bsp;           |

         &= nbsp;     |<------(2) 183 Session Progress SDP2-----= ---|

         &= nbsp;     |  ***     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |--*R*-----------(3) PRACK------------------&= gt;|

         &= nbsp;     |  *E*     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |<-*S*-------(4) 200 OK (PRACK)-----------= ---|

         &= nbsp;     |  *E*     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |  *R*     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |  *V*     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |  *A*     &nbs= p;             =             &nb= sp;       |

         &= nbsp;     |  *T*     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |  *I*     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |  *O*     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |  *N*     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |  ***     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |  ***     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |  ***     &nbs= p;            &= nbsp;           &nbs= p;        |

          =      |-------------(5) UPDATE SDP3---------------&= gt;|

         &= nbsp;     |       &n= bsp;            = ;            &n= bsp;           |

         &= nbsp;     |<--------(6) 200 OK (UPDATE) SDP4--------= ---|

         &= nbsp;     |       &n= bsp;            = ;            &n= bsp;           |

         &= nbsp;     |<-----------(7) 200 OK (INVITE)----------= ---|

         &= nbsp;     |       &n= bsp;            = ;            &n= bsp;           |

         &= nbsp;     |------------------(8) ACK------------------&= gt;|

         &= nbsp;     |       &n= bsp;            = ;            &n= bsp;           |

 

 

QUESTION: What is expected Alice's behavior if message = (6) and message (7) happened to be swapped during transport from AS to Alic= e, as shown below?

 

 

         &= nbsp;     Alice      &nbs= p;            &= nbsp;           &nbs= p;        AS

 

         &= nbsp;     |       &n= bsp;            = ;            &n= bsp;           |

         &= nbsp;     |-------------(1) INVITE SDP1---------------&= gt;|

         &= nbsp;     |       &n= bsp;            = ;            &n= bsp;           |

         &= nbsp;     |<------(2) 183 Session Progress SDP2-----= ---|

         &= nbsp;     |  ***     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |--*R*-----------(3) PRACK------------------&= gt;|

         &= nbsp;     |  *E*     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |<-*S*-------(4) 200 OK (PRACK)-----------= ---|

         &= nbsp;     |  *E*     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |  *R*     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |  *V*     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |  *A*     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |  *T*     &nbs= p;            &= nbsp;           &nbs= p;        |

          =      |  *I*     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |  *O*     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |  *N*     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |  ***     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |  ***     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |  ***     &nbs= p;            &= nbsp;           &nbs= p;        |

         &= nbsp;     |-------------(5) UPDATE SDP3---------------&= gt;|

         &= nbsp;     |       &n= bsp;            = ;            &n= bsp;           |

         &= nbsp;     |       +-(6) 200 OK (UPDATE) SDP4-----------|=

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

         &= nbsp;     |<-----------(7) 200 OK (INVITE)----------= ---|

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

         &= nbsp;     |<------+            &n= bsp;            = ;           |

 

 

In my opinion:

- when receiving message (7), Alice should consider the= call as established since 200 (OK) response is received for INVITE request= . Alice should send media according to SDP2 as SDP answer to SDP3 has not been received yet.

- when receiving message (6), Alice should start sendin= g media according to SDP4.

 

Any views?

 

Kind regards

 

Ivo Sedlacek

 

--_000_39B5E4D390E9BD4890E2B31079006101127A248DESESSMB301erics_-- From nobody Tue Nov 25 06:27:35 2014 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 469461A1AA1 for ; Tue, 25 Nov 2014 06:27:32 -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 YOKwTKFfAz2Y for ; Tue, 25 Nov 2014 06:27:22 -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 74F141A1AB2 for ; Tue, 25 Nov 2014 06:27:21 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-fe-547491c7b841 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C2.82.04231.7C194745; Tue, 25 Nov 2014 15:27:19 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.101]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0195.001; Tue, 25 Nov 2014 15:27:19 +0100 From: Ivo Sedlacek To: "sipcore@ietf.org" Thread-Topic: 503 response with Retry-After header field - request for clarification Thread-Index: AdAItrEhAw0Kwt47TAiENftPp02mYA== Date: Tue, 25 Nov 2014 14:27:18 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127A29FB@ESESSMB301.ericsson.se> 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: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101127A29FBESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvje7xiSUhBvOPall8/bGJzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGVPvf2QtmOVXse7xQaYGxmdOXYycHBICJhKHvncxQdhiEhfu rWfrYuTiEBI4wihx+udHFghnCaPErs+TwKrYBPQkJm45wgpiiwhoSiz/tpUdxBYWCJS4MKuV BSIeJtHxbzMzhK0n8W3DTzYQm0VAVWLx9Etgc3gFfCXubLoDVs8oICtx9U8vI4jNLCAucevJ fKiLBCSW7DnPDGGLSrx8/I8VwlaU+PhqH1R9vsTWM99YIGYKSpyc+YRlAqPQLCSjZiEpm4Wk DCKuI7Fg9yc2CFtbYtnC18ww9pkDj5mQxRcwsq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnE CIyKg1t+6+5gXP3a8RCjAAejEg/vhg/FIUKsiWXFlbmHGKU5WJTEeRedmxcsJJCeWJKanZpa kFoUX1Sak1p8iJGJg1OqgXHNHiN9G+Mbc4wFb19RPR5UzcQ169G5flNX3dWXX5xg7//E2vJ1 uY53+XZR62BrD66J/TyvhG4nztsousbNc5Lw3o2NnAu5HoSFvlh5ovAVl6BdZ3HWki3Lt7l/ 467Zkr7+kN+fzH4BSbdeMcVHEUx6++Yrr442f55jkuCSUPltbv/6PGu1zUosxRmJhlrMRcWJ ACpRcj9rAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/4g36o5f7oF_DEO_x7fySGERjSAU Subject: [sipcore] 503 response with Retry-After header field - request for clarification 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, 25 Nov 2014 14:27:32 -0000 --_000_39B5E4D390E9BD4890E2B31079006101127A29FBESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, can anyone please help me with interpretation of the following RFC3261 requ= irement? RFC3261 states: ---------------------------------------------------- 21.5.4 503 Service Unavailable The server is temporarily unable to process the request due to a temporary overloading or maintenance of the server. The server MAY indicate when the client should retry the request in a Retry-After header field. If no Retry-After is given, the client MUST act as if it had received a 500 (Server Internal Error) response. A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. >>It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present.<< Servers MAY refuse the connection or drop the request instead of responding with 503 (Service Unavailable). ---------------------------------------------------- Use case: - an entity E and an entity X record-route an INVITE-based dialog D - entity E sends out-of-dialog SUBSCRIBE request to entity X. entity X reje= cts the SUBSCRIBE request with 503 response and with Retry-After header fie= ld. QUESTION-1: After reception of 503 response to the SUBSCRIBE request, is e= ntity E allowed and expected to forward a BYE request sent as in-dialog req= uest of the dialog D to entity X? ASSUMED ANSWER-1: Yes, since BYE needs to pass via entity X. The only other= possible alternative is reject the BYE and that's not a good idea as the d= ialog D would not be released. QUESTION-2: After reception of 503 response to the SUBSCRIBE request, is e= ntity E allowed and expected to forward an in-dialog request (other than BY= E) sent as in-dialog request of the dialog D to entity X? ASSUMED ANSWER-2: In-dialog request (other than BYE) needs to pass via enti= ty X. However, it is unclear whether entity E is allowed and expected to fo= rward it to entity X as consequences are not so severe. QUESTION-3: After reception of 503 response to the SUBSCRIBE request, is e= ntity E allowed and expected to forward another out-of-dialog SUBSCRIBE req= uest to entity X? ASSUMED ANSWER-3: No, given the marked statement above. QUESTION-4: After reception of 503 response to the SUBSCRIBE request, is e= ntity E allowed and expected to forward another out-of-dialog request other= than SUBSCRIBE request to entity X? ASSUMED ANSWER-4: No, given the marked statement above. Any views on the questions and assumed answers? Are other interpretation of= SHOULD requirement above possible? Thanks for clarification. Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B31079006101127A29FBESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

can anyone please help me with interpretation of = the following RFC3261 requirement?

 

RFC3261 states:

-------------------------------------------------= ---

21.5.4 503 Service Unavailable

 

   The server is temporarily unable to = process the request due to a

   temporary overloading or maintenance= of the server.  The server MAY

   indicate when the client should retr= y the request in a Retry-After

   header field.  If no Retry-Afte= r is given, the client MUST act as if

   it had received a 500 (Server Intern= al Error) response.

 

   A client (proxy or UAC) receiving a = 503 (Service Unavailable) SHOULD

   attempt to forward the request to an= alternate server.  >>It SHOULD NOT

   forward any other requests to tha= t server for the duration specified

   in the Retry-After header field, = if present.<<

 

   Servers MAY refuse the connection or= drop the request instead of

   responding with 503 (Service Unavail= able).

-------------------------------------------------= ---

 

Use case:

- an entity E and an entity X record-route an INV= ITE-based dialog D

- entity E sends out-of-dialog SUBSCRIBE request = to entity X. entity X rejects the SUBSCRIBE request with 503 response and w= ith Retry-After header field.

 

QUESTION-1:  After reception of 503 response= to the SUBSCRIBE request, is entity E allowed and expected to forward a BY= E request sent as in-dialog request of the dialog D to entity X?

ASSUMED ANSWER-1: Yes, since BYE needs to pass vi= a entity X. The only other possible alternative is reject the BYE and that'= s not a good idea as the dialog D would not be released.

 

QUESTION-2:  After reception of 503 response= to the SUBSCRIBE request, is entity E allowed and expected to forward an i= n-dialog request (other than BYE) sent as in-dialog request of the dialog D= to entity X?

ASSUMED ANSWER-2: In-dialog request (other than B= YE) needs to pass via entity X. However, it is unclear whether entity E is = allowed and expected to forward it to entity X as consequences are not so s= evere.

 

QUESTION-3:  After reception of 503 response= to the SUBSCRIBE request, is entity E allowed and expected to forward anot= her out-of-dialog SUBSCRIBE request to entity X?

ASSUMED ANSWER-3: No, given the marked statement = above.

 

QUESTION-4:  After reception of 503 response= to the SUBSCRIBE request, is entity E allowed and expected to forward anot= her out-of-dialog request other than SUBSCRIBE request to entity X?

ASSUMED ANSWER-4: No, given the marked statement = above.

 

Any views on the questions and assumed answers? A= re other interpretation of SHOULD requirement above possible? Thanks for cl= arification.

 

Kind regards

 

Ivo Sedlacek

--_000_39B5E4D390E9BD4890E2B31079006101127A29FBESESSMB301erics_-- From nobody Tue Nov 25 08:55:41 2014 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 A11CA1ACE3B for ; Tue, 25 Nov 2014 08:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] 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 4DqgWB82vRou for ; Tue, 25 Nov 2014 08:55:30 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF05F1ACE16 for ; Tue, 25 Nov 2014 08:55:29 -0800 (PST) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-03v.sys.comcast.net with comcast id KsvF1p0035BUCh401svVBh; Tue, 25 Nov 2014 16:55:29 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-po-16v.sys.comcast.net with comcast id KsvU1p0091KKtkw01svUT1; Tue, 25 Nov 2014 16:55:29 +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 sAPGtRtl018658; Tue, 25 Nov 2014 11:55:27 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id sAPGtRMX018657; Tue, 25 Nov 2014 11:55:27 -0500 Date: Tue, 25 Nov 2014 11:55:27 -0500 Message-Id: <201411251655.sAPGtRMX018657@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Ivo Sedlacek In-reply-to: <39B5E4D390E9BD4890E2B31079006101127A29FB@ESESSMB301.ericsson.se> (ivo.sedlacek@ericsson.com) References: <39B5E4D390E9BD4890E2B31079006101127A29FB@ESESSMB301.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1416934529; bh=QhKQw79NDqzmOTMvVF4rDW84ErXvCu/kcZSYnff/fjs=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=hVKpGSR3PtZClSbKLIjg77WwyvBmaIirRO7gqPZg6l+SkPhJjv/Bei8AWqfNsiwaI gX5olM3nBoI/cX4ovTKSscUmitB8ZPqsvWFDftz3AipWorfeTfVvGoh/pSsiUij7cm ftZ8SuZZYrR14+vz7GHAu1GnKnzhiCyuND7mS52mcgOa9F8Y5VGMpM0/BRl6UWe1w4 zkMOc+mKZGk13DsuyW/czJQK/loQK15lA4K5oirIpSx6rMysNuEHWug9kKa8rFMbw1 U/xafzoOh6k0HrbmRc1IPEF5ZYcVKlqHj/jQkzss1/1r3s3NHXBf6LGoDxG8gU8S3n L0oxrRDw2hKvQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/kQe1uiMzdkopfreRvaK6clcjOHY Cc: sipcore@ietf.org Subject: Re: [sipcore] 503 response with Retry-After header field - request for clarification 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, 25 Nov 2014 16:55:35 -0000 > From: Ivo Sedlacek > Use case: > > - an entity E and an entity X record-route an INVITE-based dialog D > > - entity E sends out-of-dialog SUBSCRIBE request to entity X. entity > - X rejects the SUBSCRIBE request with 503 response and with > - Retry-After header field. > > > > QUESTION-1: After reception of 503 response to the SUBSCRIBE > request, is entity E allowed and expected to forward a BYE request > sent as in-dialog request of the dialog D to entity X? > > ASSUMED ANSWER-1: Yes, since BYE needs to pass via entity X. The > only other possible alternative is reject the BYE and that's not a > good idea as the dialog D would not be released. That looks correct to me. But an alternative situation is where the Record-Route URI resolves to more than one target address, only one of which is "entity X". In that case, the BYE can be forwarded as required by sending it to a different target address. Dale From nobody Tue Nov 25 20:00:33 2014 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 728B51A87E1 for ; Tue, 25 Nov 2014 20:00:31 -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 subvlFCUDjH7 for ; Tue, 25 Nov 2014 20:00:28 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B3CA01A878E for ; Tue, 25 Nov 2014 20:00:28 -0800 (PST) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sAQ40K7v024872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 25 Nov 2014 22:00:28 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <5475504F.3070400@nostrum.com> Date: Tue, 25 Nov 2014 22:00:15 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <39B5E4D390E9BD4890E2B31079006101127A29FB@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127A29FB@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------090706050303010907080408" Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/gAFWeYnrCUnu2R7VgV6w2e4dN8Q Subject: Re: [sipcore] 503 response with Retry-After header field - request for clarification 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, 26 Nov 2014 04:00:31 -0000 This is a multi-part message in MIME format. --------------090706050303010907080408 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 11/25/14 8:27 AM, Ivo Sedlacek wrote: > > Hello, > > can anyone please help me with interpretation of the following RFC3261 > requirement? > > RFC3261 states: > > ---------------------------------------------------- > > 21.5.4 503 Service Unavailable > > The server is temporarily unable to process the request due to a > > temporary overloading or maintenance of the server. The server MAY > > indicate when the client should retry the request in a Retry-After > > header field. If no Retry-After is given, the client MUST act as if > > it had received a 500 (Server Internal Error) response. > > A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD > > attempt to forward the request to an alternate server. _>>It SHOULD > NOT_ > > _ forward any other requests to that server for the duration specified_ > > _ in the Retry-After header field, if present.<<_ > > Servers MAY refuse the connection or drop the request instead of > > responding with 503 (Service Unavailable). > > ---------------------------------------------------- > > Use case: > > - an entity E and an entity X record-route an INVITE-based dialog D > > - entity E sends out-of-dialog SUBSCRIBE request to entity X. entity X > rejects the SUBSCRIBE request with 503 response and with Retry-After > header field. > > QUESTION-1: After reception of 503 response to the SUBSCRIBE request, > is entity E allowed and expected to forward a BYE request sent as > in-dialog request of the dialog D to entity X? > > ASSUMED ANSWER-1: Yes, since BYE needs to pass via entity X. The only > other possible alternative is reject the BYE and that's not a good > idea as the dialog D would not be released. > If something has sent you a 503 it's said not to talk to it until Retry-After passes. For _anything_. If you send anything, you are likely to make the condition that caused the 503 in the first place worse. 503 is not transaction or dialog specific. It is a statement about the server. It's an very big hammer, and it should ONLY be sent when there's no alternative, exactly because of the edge cases you point out. You'll also find that in a multi-hop proxy environment, the load redistribution that should happen after a 503 is sent can easily lead to to 503s from the other elements (due to overload) if the environment isn't carefully engineered for this kind of sudden, large, traffic flow disruption. If you send a BYE to the same thing that sent you a 503 for any other reason, before the Retry-After has expired, you are violating protocol. I understand that it leaves the BYE in terrible shape, but we have that for _anything_ that rejects a BYE (even the far endpoint). > > QUESTION-2: After reception of 503 response to the SUBSCRIBE request, > is entity E allowed and expected to forward an in-dialog request > (other than BYE) sent as in-dialog request of the dialog D to entity X? > > ASSUMED ANSWER-2: In-dialog request (other than BYE) needs to pass via > entity X. However, it is unclear whether entity E is allowed and > expected to forward it to entity X as consequences are not so severe. > Same thing. As Dale pointed out, it's best if you have a name in the record-route element you first described, so you have the opprotunity to move on to finding another concrete place to send the requests per 3263 resolution. > > QUESTION-3: After reception of 503 response to the SUBSCRIBE request, > is entity E allowed and expected to forward another out-of-dialog > SUBSCRIBE request to entity X? > > ASSUMED ANSWER-3: No, given the marked statement above. > > QUESTION-4: After reception of 503 response to the SUBSCRIBE request, > is entity E allowed and expected to forward another out-of-dialog > request other than SUBSCRIBE request to entity X? > > ASSUMED ANSWER-4: No, given the marked statement above. > > Any views on the questions and assumed answers? Are other > interpretation of SHOULD requirement above possible? Thanks for > clarification. > > Kind regards > > Ivo Sedlacek > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --------------090706050303010907080408 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 11/25/14 8:27 AM, Ivo Sedlacek wrote:

Hello,

can anyone please help me with interpretation of the following RFC3261 requirement?

RFC3261 states:

----------------------------------------------------

21.5.4 503 Service Unavailable

The server is temporarily unable to process the request due to a

temporary overloading or maintenance of the server. The server MAY

indicate when the client should retry the request in a Retry-After

header field. If no Retry-After is given, the client MUST act as if

it had received a 500 (Server Internal Error) response.

A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD

attempt to forward the request to an alternate server. >>It SHOULD NOT

forward any other requests to that server for the duration specified

in the Retry-After header field, if present.<<

Servers MAY refuse the connection or drop the request instead of

responding with 503 (Service Unavailable).

----------------------------------------------------

Use case:

- an entity E and an entity X record-route an INVITE-based dialog D

- entity E sends out-of-dialog SUBSCRIBE request to entity X. entity X rejects the SUBSCRIBE request with 503 response and with Retry-After header field.

QUESTION-1: After reception of 503 response to the SUBSCRIBE request, is entity E allowed and expected to forward a BYE request sent as in-dialog request of the dialog D to entity X?

ASSUMED ANSWER-1: Yes, since BYE needs to pass via entity X. The only other possible alternative is reject the BYE and that's not a good idea as the dialog D would not be released.

If something has sent you a 503 it's said not to talk to it until Retry-After passes. For _anything_. If you send anything, you are likely to make the condition that caused the 503 in the first place worse.

503 is not transaction or dialog specific. It is a statement about the server.

It's an very big hammer, and it should ONLY be sent when there's no alternative, exactly because of the edge cases you point out. You'll also find that in a multi-hop proxy environment, the load redistribution that should happen after a 503 is sent can easily lead to to 503s from the other elements (due to overload) if the environment isn't carefully engineered for this kind of sudden, large, traffic flow disruption.

If you send a BYE to the same thing that sent you a 503 for any other reason, before the Retry-After has expired, you are violating protocol.
I understand that it leaves the BYE in terrible shape, but we have that for _anything_ that rejects a BYE (even the far endpoint).

QUESTION-2: After reception of 503 response to the SUBSCRIBE request, is entity E allowed and expected to forward an in-dialog request (other than BYE) sent as in-dialog request of the dialog D to entity X?

ASSUMED ANSWER-2: In-dialog request (other than BYE) needs to pass via entity X. However, it is unclear whether entity E is allowed and expected to forward it to entity X as consequences are not so severe.

Same thing. As Dale pointed out, it's best if you have a name in the record-route element you first described, so you have the opprotunity to move on to finding another concrete place to send the requests per 3263 resolution.

QUESTION-3: After reception of 503 response to the SUBSCRIBE request, is entity E allowed and expected to forward another out-of-dialog SUBSCRIBE request to entity X?

ASSUMED ANSWER-3: No, given the marked statement above.

QUESTION-4: After reception of 503 response to the SUBSCRIBE request, is entity E allowed and expected to forward another out-of-dialog request other than SUBSCRIBE request to entity X?

ASSUMED ANSWER-4: No, given the marked statement above.

Any views on the questions and assumed answers? Are other interpretation of SHOULD requirement above possible? Thanks for clarification.

Kind regards

Ivo Sedlacek



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

--------------090706050303010907080408-- From nobody Thu Nov 27 17:05:04 2014 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 C2E841A0387 for ; Thu, 27 Nov 2014 17:05:00 -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 PihYvqHwzzWG for ; Thu, 27 Nov 2014 17:04:58 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id ACA8C1A0302 for ; Thu, 27 Nov 2014 17:04:57 -0800 (PST) Received: from xct103cnc.rim.net ([10.65.161.203]) by mhs213cnc.rim.net with ESMTP/TLS/AES128-SHA; 27 Nov 2014 20:04:31 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT103CNC.rim.net ([fe80::b8:d5e:26a5:f4d6%17]) with mapi id 14.03.0174.001; Thu, 27 Nov 2014 20:04:30 -0500 From: Andrew Allen To: "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQBeGiwaMk5ORsmEyvUhfkEzOyiJxzzZqw Date: Fri, 28 Nov 2014 01:04:30 +0000 Message-ID: References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> In-Reply-To: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/USEpjxmR7mDZ-Sdp85dltps5l1U Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.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: Fri, 28 Nov 2014 01:05:01 -0000 Robert Thanks for getting the WG version of the draft out. The main issue for me with the draft is the criteria for how the UA knows t= hat it will not end up with an explicit subscription. Currently the draft i= s vague about that. Some deployments don't currently have the potential to create an implicit s= ubscription because of something defined outside of the SIP protocol ensure= s that they only perform a subset of the defined behavior in RFCs 3515, 666= 5 and 4488 i.e. by defining that the UAC always includes refersub=3Dfalse a= nd by defining that the UAS always accepts that request to not create a sub= scription with the only way for a UAC to determine that the UAS will behave= that way is because it (maybe) received a media-feature tag or feature cap= ability indicator that it knows by means outside the SIP protocol (from som= e other SDOs specification or it's a proprietary implementation where a sin= gle vendor defines both ends) that this will be the behavior. I think we should clearly decide whether this fulfils the criteria for a UA= C to determine definitively that no implicit subscription will be created a= nd hence allows the UAC to send the Refer on an existing dialog or not.=20 My own preference is not to have this qualify as a way for a UAC to be cert= ain as this makes SIP protocol behavior dependent on some higher layer appl= ication semantic creating a tight coupling between the application and the = SIP protocol stack making it difficult to reuse off the shelf SIP stacks fo= r you application. It should be a protocol issue (defined in RFCs) not an a= pplication issue as to whether a request is sent on the same or a different= dialog. I am also concerned that this kind of thing makes it more likely that the U= AS in these cases ends up being only a partial implementation of the protoc= ol (e.g. It doesn't even implement receiving a Refer out of dialog and cann= ot send a Notify even if a UAC did not include Refersub =3D false). I think= the discussion we had in Dispatch in Hawaii shows that future interoperabi= lity problems are caused when only partial implementations of the protocol = are done and assumptions about the behavior in perpetuity of the UAC are ma= de. My preference is that refer-clarifications should only allow refer-explicit= -subscription mechanism as a means for UAC to determine that its ok to send= the Refer on an existing dialog and that we make refer-clarifications depe= ndent on refer-explicit-subscription. If you want to send on an existing di= alog then you use the refer-explicit-subscription mechanism and Require nos= ub otherwise you follow the RFC 6665 behavior and if you have a GRUU as the= target then you send outside the existing dialog. That is clear and deter= ministic. So my proposal is to change the following text in section 4 from : If a user agent can be certain that no implicit subscription will be created as a result of sending a REFER request (such as by requiring an extension that disallows any such subscription [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request MAY be sent within an existing dialog. Such a REFER will be constructed with its Contact header field populated with the dialog's Local URI as specified in section 12 of [RFC3261]. To A user agent can be certain that no implicit subscription will be created as a result of sending a REFER request by using the extension in [I-D.ietf-sipcore-refer-explicit-subscription] to=20 require the UAS not to create an implicit subscription. Only=20 when using the explicit subscription mechanism to require that a subscription not be created MAY the REFER request be sent=20 within an existing dialog. Such a REFER will be constructed with=20 its Contact header field populated with the dialog's Local URI as=20 specified in section 12 of [RFC3261]. Andrew -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Friday, November 21, 2014 6:19 PM To: i-d-announce@ietf.org Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.t= xt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : Clarifications for the use of REFER with RFC6665 Authors : Robert Sparks Adam Roach Filename : draft-ietf-sipcore-refer-clarifications-00.txt Pages : 6 Date : 2014-11-21 Abstract: The SIP REFER method relies on the SIP-Specific Event Notification Framework. That framework was revised by RFC6665. This document highlights the implications of the requirement changes in RFC6665, and updates the definition of the REFER method, RFC3515, to clarify and disambiguate the impact of those changes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarifications/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-refer-clarifications-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Nov 27 23:38:23 2014 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 A91121A1A63 for ; Thu, 27 Nov 2014 23:38:21 -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 ECUgERDryPBZ for ; Thu, 27 Nov 2014 23:38:19 -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 166BB1A1A4B for ; Thu, 27 Nov 2014 23:38:17 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-61-547826685b44 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 6F.6A.04231.86628745; Fri, 28 Nov 2014 08:38:16 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.101]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 08:38:16 +0100 From: Ivo Sedlacek To: Andrew Allen , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQBeGiwaMk5ORsmEyvUhfkEzOyiJxzzZqwgAHi0uA= Date: Fri, 28 Nov 2014 07:38:15 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127A5796@ESESSMB301.ericsson.se> References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> 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.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvjW6GWkWIwfo1Uhb3521ltPj6YxOb A5PHrIa17B5LlvxkCmCK4rJJSc3JLEst0rdL4MqYsmoVY8Ev44qDs7awNjBe0exi5OSQEDCR mDFrHzOELSZx4d56ti5GLg4hgSOMEjsPf2aHcJYwSuzoaWQHqWIT0JOYuOUIK4gtIhAo8bb5 PVhcWCBY4vXmThaIeIjEzPU7GCFsK4nGI3PA6lkEVCX6e5+DbeMV8JV49GUr1LYGRomOZcvB ijgFPCWaF20BsxkFZCWu/ukFG8QsIC5x68l8JohTBSSW7DkPdbaoxMvH/1ghbCWJtYe3s0DU 60gs2P2JDcLWlli28DXUYkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFaNocWpxcW66kbFe alFmcnFxfp5eXmrJJkZgrBzc8lt3B+Pq146HGAU4GJV4eAtkK0KEWBPLiitzDzFKc7AoifMu OjcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj/N07mcksP+xeylw9eO9Qgkn20V/Pg50b WtgvHLmVPsHMZ/e8I3NSIjbk9M71ZC88JFW991qwpnX4//of8jwM5rzC7z/Md1tSpRa0fsm/ 7QyBUWff8Cnurlhm2hjz6fU7+1nqG17fn/vglsvxTJdaizuO3usTLj1stmfurm5rkv/0vc8r qv24EktxRqKhFnNRcSIAzKjCEHYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/LXigj5_duhGtKQnncpST-wQ5iiQ Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.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: Fri, 28 Nov 2014 07:38:21 -0000 Hello, I disagree with proposed statement:=20 "Only=20 when using the explicit subscription mechanism to require that a subscription not be created MAY the REFER request be sent=20 within an existing dialog." There are existing means how the UA can be sure that implicit subscription = will not be created - they rely on media feature tag and RFC4488, but work = neverthless. Therefore, I see the proposed statement as unnecessary restrictive. RFC6665= statement is sufficient. Kind regards Ivo Sedlacek -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew Allen Sent: 28. listopadu 2014 2:04 To: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Robert Thanks for getting the WG version of the draft out. The main issue for me with the draft is the criteria for how the UA knows t= hat it will not end up with an explicit subscription. Currently the draft i= s vague about that. Some deployments don't currently have the potential to create an implicit s= ubscription because of something defined outside of the SIP protocol ensure= s that they only perform a subset of the defined behavior in RFCs 3515, 666= 5 and 4488 i.e. by defining that the UAC always includes refersub=3Dfalse a= nd by defining that the UAS always accepts that request to not create a sub= scription with the only way for a UAC to determine that the UAS will behave= that way is because it (maybe) received a media-feature tag or feature cap= ability indicator that it knows by means outside the SIP protocol (from som= e other SDOs specification or it's a proprietary implementation where a sin= gle vendor defines both ends) that this will be the behavior. I think we should clearly decide whether this fulfils the criteria for a UA= C to determine definitively that no implicit subscription will be created a= nd hence allows the UAC to send the Refer on an existing dialog or not.=20 My own preference is not to have this qualify as a way for a UAC to be cert= ain as this makes SIP protocol behavior dependent on some higher layer appl= ication semantic creating a tight coupling between the application and the = SIP protocol stack making it difficult to reuse off the shelf SIP stacks fo= r you application. It should be a protocol issue (defined in RFCs) not an a= pplication issue as to whether a request is sent on the same or a different= dialog. I am also concerned that this kind of thing makes it more likely that the U= AS in these cases ends up being only a partial implementation of the protoc= ol (e.g. It doesn't even implement receiving a Refer out of dialog and cann= ot send a Notify even if a UAC did not include Refersub =3D false). I think= the discussion we had in Dispatch in Hawaii shows that future interoperabi= lity problems are caused when only partial implementations of the protocol = are done and assumptions about the behavior in perpetuity of the UAC are ma= de. My preference is that refer-clarifications should only allow refer-explicit= -subscription mechanism as a means for UAC to determine that its ok to send= the Refer on an existing dialog and that we make refer-clarifications depe= ndent on refer-explicit-subscription. If you want to send on an existing di= alog then you use the refer-explicit-subscription mechanism and Require nos= ub otherwise you follow the RFC 6665 behavior and if you have a GRUU as the= target then you send outside the existing dialog. That is clear and deter= ministic. So my proposal is to change the following text in section 4 from : If a user agent can be certain that no implicit subscription will be created as a result of sending a REFER request (such as by requiring an extension that disallows any such subscription [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request MAY be sent within an existing dialog. Such a REFER will be constructed with its Contact header field populated with the dialog's Local URI as specified in section 12 of [RFC3261]. To A user agent can be certain that no implicit subscription will be created as a result of sending a REFER request by using the extension in [I-D.ietf-sipcore-refer-explicit-subscription] to=20 require the UAS not to create an implicit subscription. Only=20 when using the explicit subscription mechanism to require that a subscription not be created MAY the REFER request be sent=20 within an existing dialog. Such a REFER will be constructed with=20 its Contact header field populated with the dialog's Local URI as=20 specified in section 12 of [RFC3261]. Andrew -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Friday, November 21, 2014 6:19 PM To: i-d-announce@ietf.org Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.t= xt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : Clarifications for the use of REFER with RFC6665 Authors : Robert Sparks Adam Roach Filename : draft-ietf-sipcore-refer-clarifications-00.txt Pages : 6 Date : 2014-11-21 Abstract: The SIP REFER method relies on the SIP-Specific Event Notification Framework. That framework was revised by RFC6665. This document highlights the implications of the requirement changes in RFC6665, and updates the definition of the REFER method, RFC3515, to clarify and disambiguate the impact of those changes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarifications/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-refer-clarifications-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 Nov 28 02:56:58 2014 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 4AE2A1A1B07 for ; Fri, 28 Nov 2014 02:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 XmjxMuRFLq6Q for ; Fri, 28 Nov 2014 02:56:54 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332701A1AEB for ; Fri, 28 Nov 2014 02:56:53 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sASAumt1010450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Nov 2014 10:56:49 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sASAulLN027870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Nov 2014 11:56:47 +0100 Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 28 Nov 2014 11:56:47 +0100 Received: from DEMUMBX003.nsn-intra.net ([169.254.2.85]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 11:56:47 +0100 From: "Leis, Peter (NSN - DE/Munich)" To: ext Ivo Sedlacek , Andrew Allen , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQBeGiwaMk5ORsmEyvUhfkEzOyiJxzzZqwgAHi0uCAADeigA== Date: Fri, 28 Nov 2014 10:56:46 +0000 Message-ID: <059F3547244B7F4DB728757635C2DC4B15DB18E0@DEMUMBX003.nsn-intra.net> References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127A5796@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127A5796@ESESSMB301.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 7122 X-purgate-ID: 151667::1417172209-0000677A-B8CB92A0/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/tRSeiAaqyE-thz2mLRL1-jczwJU Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.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: Fri, 28 Nov 2014 10:56:57 -0000 Hi, I have the same view as Ivo. Regards Peter -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Ivo Sedlac= ek Sent: Friday, November 28, 2014 8:38 AM To: Andrew Allen; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hello, I disagree with proposed statement:=20 "Only=20 when using the explicit subscription mechanism to require that a subscription not be created MAY the REFER request be sent=20 within an existing dialog." There are existing means how the UA can be sure that implicit subscription = will not be created - they rely on media feature tag and RFC4488, but work = neverthless. Therefore, I see the proposed statement as unnecessary restrictive. RFC6665= statement is sufficient. Kind regards Ivo Sedlacek -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew Allen Sent: 28. listopadu 2014 2:04 To: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Robert Thanks for getting the WG version of the draft out. The main issue for me with the draft is the criteria for how the UA knows t= hat it will not end up with an explicit subscription. Currently the draft i= s vague about that. Some deployments don't currently have the potential to create an implicit s= ubscription because of something defined outside of the SIP protocol ensure= s that they only perform a subset of the defined behavior in RFCs 3515, 666= 5 and 4488 i.e. by defining that the UAC always includes refersub=3Dfalse a= nd by defining that the UAS always accepts that request to not create a sub= scription with the only way for a UAC to determine that the UAS will behave= that way is because it (maybe) received a media-feature tag or feature cap= ability indicator that it knows by means outside the SIP protocol (from som= e other SDOs specification or it's a proprietary implementation where a sin= gle vendor defines both ends) that this will be the behavior. I think we should clearly decide whether this fulfils the criteria for a UA= C to determine definitively that no implicit subscription will be created a= nd hence allows the UAC to send the Refer on an existing dialog or not.=20 My own preference is not to have this qualify as a way for a UAC to be cert= ain as this makes SIP protocol behavior dependent on some higher layer appl= ication semantic creating a tight coupling between the application and the = SIP protocol stack making it difficult to reuse off the shelf SIP stacks fo= r you application. It should be a protocol issue (defined in RFCs) not an a= pplication issue as to whether a request is sent on the same or a different= dialog. I am also concerned that this kind of thing makes it more likely that the U= AS in these cases ends up being only a partial implementation of the protoc= ol (e.g. It doesn't even implement receiving a Refer out of dialog and cann= ot send a Notify even if a UAC did not include Refersub =3D false). I think= the discussion we had in Dispatch in Hawaii shows that future interoperabi= lity problems are caused when only partial implementations of the protocol = are done and assumptions about the behavior in perpetuity of the UAC are ma= de. My preference is that refer-clarifications should only allow refer-explicit= -subscription mechanism as a means for UAC to determine that its ok to send= the Refer on an existing dialog and that we make refer-clarifications depe= ndent on refer-explicit-subscription. If you want to send on an existing di= alog then you use the refer-explicit-subscription mechanism and Require nos= ub otherwise you follow the RFC 6665 behavior and if you have a GRUU as the= target then you send outside the existing dialog. That is clear and deter= ministic. So my proposal is to change the following text in section 4 from : If a user agent can be certain that no implicit subscription will be created as a result of sending a REFER request (such as by requiring an extension that disallows any such subscription [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request MAY be sent within an existing dialog. Such a REFER will be constructed with its Contact header field populated with the dialog's Local URI as specified in section 12 of [RFC3261]. To A user agent can be certain that no implicit subscription will be created as a result of sending a REFER request by using the extension in [I-D.ietf-sipcore-refer-explicit-subscription] to=20 require the UAS not to create an implicit subscription. Only=20 when using the explicit subscription mechanism to require that a subscription not be created MAY the REFER request be sent=20 within an existing dialog. Such a REFER will be constructed with=20 its Contact header field populated with the dialog's Local URI as=20 specified in section 12 of [RFC3261]. Andrew -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Friday, November 21, 2014 6:19 PM To: i-d-announce@ietf.org Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.t= xt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : Clarifications for the use of REFER with RFC6665 Authors : Robert Sparks Adam Roach Filename : draft-ietf-sipcore-refer-clarifications-00.txt Pages : 6 Date : 2014-11-21 Abstract: The SIP REFER method relies on the SIP-Specific Event Notification Framework. That framework was revised by RFC6665. This document highlights the implications of the requirement changes in RFC6665, and updates the definition of the REFER method, RFC3515, to clarify and disambiguate the impact of those changes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarifications/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-refer-clarifications-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 Nov 28 07:28:53 2014 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 8ED2E1A0077 for ; Fri, 28 Nov 2014 07:28:50 -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 Ydw3nz2CA_gS for ; Fri, 28 Nov 2014 07:28: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 C0FC01A0073 for ; Fri, 28 Nov 2014 07:28:46 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-c1-547894ac6d6f Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D8.28.04076.CA498745; Fri, 28 Nov 2014 16:28:45 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.101]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0195.001; Fri, 28 Nov 2014 16:28:44 +0100 From: Ivo Sedlacek To: Ivo Sedlacek , Andrew Allen , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQBeGiwaMk5ORsmEyvUhfkEzOyiJxzzZqwgAHi0uCAAIN8oA== Date: Fri, 28 Nov 2014 15:28:43 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127A5FFC@ESESSMB301.ericsson.se> References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127A5796@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127A5796@ESESSMB301.ericsson.se> Accept-Language: en-US, cs-CZ 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+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvje7aKRUhBhd2sljcn7eV0eLrj01s DkwesxrWsnssWfKTKYApissmJTUnsyy1SN8ugSvjff9zxoKH9hVHm2azNDCeMu5i5OSQEDCR OHF7JiOELSZx4d56ti5GLg4hgSOMEjdmLodyljBKbFtxFqyKTUBPYuKWI6wgtohAtcSGpj6w uLBAsMTrzZ0sEPEQiZnrdzBC2E4Sb7bMZwaxWQRUJa6/+QE0lIODV8BX4vBafrhl7U1vwXo5 Bfwk3jz9zQRiMwrISlz90ws2h1lAXOLWk/lMEJcKSCzZc54ZwhaVePn4HyuErSSxYvslqHod iQW7P7FB2NoSyxa+BqvnFRCUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGKFqcWF+emGxnp pRZlJhcX5+fp5aWWbGIERsrBLb+tdjAefO54iFGAg1GJh7dAtiJEiDWxrLgy9xCjNAeLkjjv wnPzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwrjWceM/xgtBTpz0qb5s3M91xn9vi31lf 5Pxdd3+kVRuDHsP5pWUSjoZNgSW3Pl++YR/ooOJ2gCdipf2rFS9qJ5oef69Zvc9g8YbL+mrX 054kPKtbIL1e8uuxl7zqE2U1mcNfVX2YkrNrh3J9g/zCxyHnnA613vMSvrTw/a5D+mH/b9l/ cjr6VImlOCPRUIu5qDgRAEyr0h51AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/EBxQrUysYxubD6YL14GMTea8dC4 Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.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: Fri, 28 Nov 2014 15:28:50 -0000 Hello, I think Andrew's proposed statement can be replaced by the statement alread= y existing in the draft, i.e. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D If a user agent can be certain that no implicit subscription will be created as a result of sending a REFER request (such as by requiring an extension that disallows any such subscription [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request MAY be sent within an existing dialog. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D and extended as follows: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D If a user agent can be certain that no implicit subscription will be created as a result of sending a REFER request (such as by requiring an extension that disallows any such subscription [I-D.ietf-sipcore-refer-explicit-subscription] >>>or by RFC4488 together= with configuration / application logic in specific environment ensuring t= hat implicit subscription is not created<<<), the REFER request MAY be sent within an existing dialog. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Kind regards Ivo Sedlacek -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek Sent: 28. listopadu 2014 8:38 To: Andrew Allen; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hello, I disagree with proposed statement:=20 "Only=20 when using the explicit subscription mechanism to require that a subscription not be created MAY the REFER request be sent=20 within an existing dialog." There are existing means how the UA can be sure that implicit subscription = will not be created - they rely on media feature tag and RFC4488, but work = neverthless. Therefore, I see the proposed statement as unnecessary restrictive. RFC6665= statement is sufficient. Kind regards Ivo Sedlacek -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew Allen Sent: 28. listopadu 2014 2:04 To: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Robert Thanks for getting the WG version of the draft out. The main issue for me with the draft is the criteria for how the UA knows t= hat it will not end up with an explicit subscription. Currently the draft i= s vague about that. Some deployments don't currently have the potential to create an implicit s= ubscription because of something defined outside of the SIP protocol ensure= s that they only perform a subset of the defined behavior in RFCs 3515, 666= 5 and 4488 i.e. by defining that the UAC always includes refersub=3Dfalse a= nd by defining that the UAS always accepts that request to not create a sub= scription with the only way for a UAC to determine that the UAS will behave= that way is because it (maybe) received a media-feature tag or feature cap= ability indicator that it knows by means outside the SIP protocol (from som= e other SDOs specification or it's a proprietary implementation where a sin= gle vendor defines both ends) that this will be the behavior. I think we should clearly decide whether this fulfils the criteria for a UA= C to determine definitively that no implicit subscription will be created a= nd hence allows the UAC to send the Refer on an existing dialog or not.=20 My own preference is not to have this qualify as a way for a UAC to be cert= ain as this makes SIP protocol behavior dependent on some higher layer appl= ication semantic creating a tight coupling between the application and the = SIP protocol stack making it difficult to reuse off the shelf SIP stacks fo= r you application. It should be a protocol issue (defined in RFCs) not an a= pplication issue as to whether a request is sent on the same or a different= dialog. I am also concerned that this kind of thing makes it more likely that the U= AS in these cases ends up being only a partial implementation of the protoc= ol (e.g. It doesn't even implement receiving a Refer out of dialog and cann= ot send a Notify even if a UAC did not include Refersub =3D false). I think= the discussion we had in Dispatch in Hawaii shows that future interoperabi= lity problems are caused when only partial implementations of the protocol = are done and assumptions about the behavior in perpetuity of the UAC are ma= de. My preference is that refer-clarifications should only allow refer-explicit= -subscription mechanism as a means for UAC to determine that its ok to send= the Refer on an existing dialog and that we make refer-clarifications depe= ndent on refer-explicit-subscription. If you want to send on an existing di= alog then you use the refer-explicit-subscription mechanism and Require nos= ub otherwise you follow the RFC 6665 behavior and if you have a GRUU as the= target then you send outside the existing dialog. That is clear and deter= ministic. So my proposal is to change the following text in section 4 from : If a user agent can be certain that no implicit subscription will be created as a result of sending a REFER request (such as by requiring an extension that disallows any such subscription [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request MAY be sent within an existing dialog. Such a REFER will be constructed with its Contact header field populated with the dialog's Local URI as specified in section 12 of [RFC3261]. To A user agent can be certain that no implicit subscription will be created as a result of sending a REFER request by using the extension in [I-D.ietf-sipcore-refer-explicit-subscription] to=20 require the UAS not to create an implicit subscription. Only=20 when using the explicit subscription mechanism to require that a subscription not be created MAY the REFER request be sent=20 within an existing dialog. Such a REFER will be constructed with=20 its Contact header field populated with the dialog's Local URI as=20 specified in section 12 of [RFC3261]. Andrew -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Friday, November 21, 2014 6:19 PM To: i-d-announce@ietf.org Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.t= xt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : Clarifications for the use of REFER with RFC6665 Authors : Robert Sparks Adam Roach Filename : draft-ietf-sipcore-refer-clarifications-00.txt Pages : 6 Date : 2014-11-21 Abstract: The SIP REFER method relies on the SIP-Specific Event Notification Framework. That framework was revised by RFC6665. This document highlights the implications of the requirement changes in RFC6665, and updates the definition of the REFER method, RFC3515, to clarify and disambiguate the impact of those changes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarifications/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-refer-clarifications-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 Sat Nov 29 08:48:04 2014 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 1301E1A017C for ; Sat, 29 Nov 2014 08:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iv1btsnKaF9g for ; Sat, 29 Nov 2014 08:47:58 -0800 (PST) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2B5D1A0172 for ; Sat, 29 Nov 2014 08:47:57 -0800 (PST) Received: by mail-la0-f45.google.com with SMTP id gq15so6819231lab.4 for ; Sat, 29 Nov 2014 08:47:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=SDvmOP1afTcHheWZ/fpKrGzPOzO8k/7IvxDfqdPoK6o=; b=SgErLJGChDhOR43i3ceBkmVV5U3DW1feHPIB/LMMifALOjcK9h/PmSM7ZrAx6ld6MH e0qLQZ3Av9Vr0GWoRFWpNpJwLkKEDfrFp5nNbrrOEKcil61UZSxQhl1IN/4zDcOKUv++ 9gts5MaQ78OiKNJ4ko2+F2VBThK8RovTHToiAkiPHD9qWvDkFCHJQzpgfeANEcEuxfvf KxmT5HcNOVZCTiyGlSVYTSWbbhYQH1SNhyqM3+bpsLGa4BA4GWkXnEeY0pLfMw7+etXp 4/sbR5ymV/Wu3Rnrpx5ZycqD3S5HfJnOF/ZhEGV1bn/SBECZcxqq1sJRqaULYcidCPhs VWsQ== X-Gm-Message-State: ALoCoQn/Z8c5ITCk8LUBb3BeMQQ7eaByVGJiOTb364gr8R5BCZJOJ+shIcy2JmtTsC2ENjPg2yHT MIME-Version: 1.0 X-Received: by 10.152.206.67 with SMTP id lm3mr48807989lac.16.1417279676133; Sat, 29 Nov 2014 08:47:56 -0800 (PST) Received: by 10.25.84.145 with HTTP; Sat, 29 Nov 2014 08:47:56 -0800 (PST) Date: Sat, 29 Nov 2014 11:47:56 -0500 Message-ID: From: Simon Perreault To: draft-ietf-sipcore-dns-dual-stack@tools.ietf.org, sipcore@ietf.org Content-Type: multipart/alternative; boundary=001a113494b2a4cd3805090223ea Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/bvqJHA6kLHOE0GamFfeJjN450Qc Subject: [sipcore] Review of draft-ietf-sipcore-dns-dual-stack-01 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, 29 Nov 2014 16:48:01 -0000 --001a113494b2a4cd3805090223ea Content-Type: text/plain; charset=UTF-8 All, In Honolulu I agreed to review this draft. Here's my review! Simon Major ===== - It's not clear to me whether Section 4.1 advocates parallel connections or not. Is Happy Eyeballs to be applied or not? Or are we not recommending one way or another? This needs to be made more explicit. - The guidance in Section 4.2 could benefit from stronger normative language: When indicating address family preference through SRV, IPv4-only and/ or IPv6-only clients should be prepared to handle SRV record sets that don't resolve into an ip address in the address family used by that client. In such a case, the client should simply proceed to the next priority and try the hostnames in the alternate address family. Suggestion: s/should/MUST/g And please remove the "and try the hostnames in the alternate address family." part, which makes no sense (a hostname cannot be "in an address family"). Minor ===== - Should this draft formally update RFC 3263? - In section 1, has this been resolved? [[TODO: Sync with Vijay Gurbani on impacts of this draft to RFC 6157 , especially relative to the additional requirement that DNS be populated such that a certain address family is preferred.]] - Please remove normative language from section 1 (i.e., the SHOULD in the last paragraph). - Section 4.1: Happy Eyeballs [RFC6555 ] has proven that looking up the "A or AAAA record" is not an effective practice for dual-stack clients and that it can add significant connection delay and greatly degrade user experience. It is not Happy Eyeballs which has proven that, it is experience with dual-stack. Suggestion: "Experience with dual-stack has proven that...". - Section 4.1: The dual-stack client SHOULD perform an A and AAAA record lookup of the domain name and add the respective IPv4/IPv6 addresses to the list of IP addresses to be contacted. Suggested rewording: "A dual-stack client SHOULD perform A and AAAA record lookups of the domain name and add all resulting IPv4 and/or IPv6 addresses to the list of IP addresses to be contacted." Nits === - In the abstract, add a reference to the Happy Eyeballs RFC. - Section 4.1: Once the transport protocol has been determined, the procedure for discovering an ip address s/ip/IP/ --001a113494b2a4cd3805090223ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,

In Honolulu I agreed to= review this draft. Here's my review!

Simon



Major
=3D=3D= =3D=3D=3D

- It's not clear to me whether Secti= on 4.1 advocates parallel connections or not. Is Happy Eyeballs to be appli= ed or not? Or are we not recommending one way or another? This needs to be = made more explicit.

- The guidance in Section 4.2 = could benefit from stronger normative language:

When indicating address family preference through SRV, IPv4= -only and/ or IPv6-only clients should be prepared to handle SRV record sets that don't resolve into an ip address in the address family used by that client. In such a case, the client should simply proceed to the next priority and try the hostnames in the alternate address family.

Suggestion: s/should/MUST/g

And please remove the "and try the hostnames in the alternate address family." part, wh= ich makes no sense (a hostname cannot be "in an address family").=


Minor
=3D=3D=3D= =3D=3D

- Should this draft formally update RFC 326= 3?

- In section 1, has this been resolved?

   [[TODO: Sync with Vijay Gurbani on impa=
cts of this draft to RFC 61=
57,
   especially relative to the additional requirement that DNS be
   populated such that a certain address family is preferred.]]
=

- Please remove normative language from section 1 (i.e.= , the SHOULD in the last paragraph).

- Section 4.1= :

   Happy Eyeballs [RFC6555] has proven that looking up the &quo=
t;A or AAAA
   record" is not an effective practice for dual-stack clients and tha=
t
   it can add significant connection delay and greatly degrade user
   experience.

It is not Happy Eyeballs whic= h has proven that, it is experience with dual-stack. Suggestion: "Expe= rience with dual-stack has proven that...".

-= Section 4.1:

      The dual-stack =
client SHOULD perform an A and AAAA record lookup
      of the domain name and add the respective IPv4/IPv6 addresses to
      the list of IP addresses to be contacted.

<= div>Suggested rewording: "A dual-stack client SHOULD perform A and AAA= A record lookups of the domain name and add all resulting IPv4 and/or IPv6 = addresses to the list of IP addresses to be contacted."

=

Nits
=3D=3D=3D

- In the a= bstract, add a reference to the Happy Eyeballs RFC.

- Section 4.1:

   Once the transp=
ort protocol has been determined, the procedure for
   discovering an ip address

s/ip/IP/
--001a113494b2a4cd3805090223ea-- From nobody Sat Nov 29 13:11:27 2014 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 12D611A1EF2 for ; Sat, 29 Nov 2014 13:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Vl_EXJWouYO for ; Sat, 29 Nov 2014 13:11:18 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id B00751A0146 for ; Sat, 29 Nov 2014 13:11:17 -0800 (PST) Received: from [192.168.40.15] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 1928693C2A3; Sat, 29 Nov 2014 21:10:38 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_C793A8B6-2469-4CD9-8D15-293EB5B86EB5" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Olle E. Johansson" In-Reply-To: Date: Sat, 29 Nov 2014 22:11:09 +0100 Message-Id: <9A8678A7-6527-467C-B914-86F7241E34C4@edvina.net> References: To: Simon Perreault X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/HDJ52DjkHaJmHrRgi-WNk5yfU40 Cc: sipcore@ietf.org, Olle E Johansson , draft-ietf-sipcore-dns-dual-stack@tools.ietf.org Subject: Re: [sipcore] Review of draft-ietf-sipcore-dns-dual-stack-01 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, 29 Nov 2014 21:11:25 -0000 --Apple-Mail=_C793A8B6-2469-4CD9-8D15-293EB5B86EB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29 Nov 2014, at 17:47, Simon Perreault wrote: > All, >=20 > In Honolulu I agreed to review this draft. Here's my review! >=20 > Simon >=20 >=20 >=20 > Major > =3D=3D=3D=3D=3D >=20 > - It's not clear to me whether Section 4.1 advocates parallel = connections or not. Is Happy Eyeballs to be applied or not? Or are we = not recommending one way or another? This needs to be made more = explicit. We tried to avoid that to prepare for another draft that talks about the = connections. This draft focuses on making both the IPv4 and IPv6 candidates available. >=20 > - The guidance in Section 4.2 could benefit from stronger normative = language: >=20 > When indicating address family preference through SRV, IPv4-only = and/ > or IPv6-only clients should be prepared to handle SRV record sets > that don't resolve into an ip address in the address family used by > that client. In such a case, the client should simply proceed to = the > next priority and try the hostnames in the alternate address = family. >=20 > Suggestion: s/should/MUST/g Agree. >=20 > And please remove the "and try the hostnames in the alternate address = family." part, which makes no sense (a hostname cannot be "in an address = family"). >=20 >=20 > Minor > =3D=3D=3D=3D=3D >=20 > - Should this draft formally update RFC 3263? At one point it did, but the wg - especially Cullen Jennings - did not = accept it. I personally still think it's needed. >=20 > - In section 1, has this been resolved? >=20 > [[TODO: Sync with Vijay Gurbani on impacts of this draft to RFC = 6157, > especially relative to the additional requirement that DNS be > populated such that a certain address family is preferred.]] It's been in planning for a long time - we have a set date in december = now. >=20 > - Please remove normative language from section 1 (i.e., the SHOULD in = the last paragraph). >=20 > - Section 4.1: >=20 > Happy Eyeballs [RFC6555] has proven that looking up the "A or AAAA > record" is not an effective practice for dual-stack clients and = that > it can add significant connection delay and greatly degrade user > experience. >=20 > It is not Happy Eyeballs which has proven that, it is experience with = dual-stack. Suggestion: "Experience with dual-stack has proven that...". >=20 > - Section 4.1: >=20 > The dual-stack client SHOULD perform an A and AAAA record lookup > of the domain name and add the respective IPv4/IPv6 addresses to > the list of IP addresses to be contacted. >=20 > Suggested rewording: "A dual-stack client SHOULD perform A and AAAA = record lookups of the domain name and add all resulting IPv4 and/or IPv6 = addresses to the list of IP addresses to be contacted." THe normative language here is actually RFC 2782 - DNS SRV. Maybe we = should avoid "should" here. >=20 >=20 > Nits > =3D=3D=3D >=20 > - In the abstract, add a reference to the Happy Eyeballs RFC. >=20 > - Section 4.1: >=20 > Once the transport protocol has been determined, the procedure for > discovering an ip address >=20 > s/ip/IP/ Thank you very much for your review! We'll update the draft. /O > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_C793A8B6-2469-4CD9-8D15-293EB5B86EB5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 29 Nov 2014, at 17:47, Simon = Perreault <sperreault@jive.com> = wrote:

All,

In = Honolulu I agreed to review this draft. Here's my = review!

Simon


=

Major
=3D=3D=3D=3D=3D

- It's not clear to me whether Section 4.1 advocates parallel = connections or not. Is Happy Eyeballs to be applied or not? Or are we = not recommending one way or another? This needs to be made more = explicit.
We tried to avoid that to prepare for = another draft that talks about the connections. This draft focuses on = making
both the IPv4 and IPv6 candidates = available.

- The guidance in Section 4.2 could = benefit from stronger normative language:

   When indicating address family preference through SRV, =
IPv4-only and/
   or IPv6-only clients should be prepared to handle SRV record sets
   that don't resolve into an ip address in the address family used by
   that client.  In such a case, the client should simply proceed to the
   next priority and try the hostnames in the alternate address =
family.

Suggestion: = s/should/MUST/g
Agree.

And please remove the = "and try the hostnames in the alternate = address family." part, which makes no sense (a hostname cannot be "in an = address = family").


Minor
=3D= =3D=3D=3D=3D

- Should this draft formally = update RFC 3263?
At one point it did, but the wg = - especially Cullen Jennings - did not accept it. I personally still = think it's needed.

- In section 1, has this been = resolved?

   [[TODO: Sync with Vijay =
Gurbani on impacts of this draft to RFC 6157,
   especially relative to the additional requirement that DNS be
   populated such that a certain address family is =
preferred.]]
It's been in planning for a = long time - we have a set date in december = now.


- Please remove normative language from = section 1 (i.e., the SHOULD in the last = paragraph).

- Section = 4.1:

   Happy Eyeballs [RFC6555] has proven =
that looking up the "A or AAAA
   record" is not an effective practice for dual-stack clients and that
   it can add significant connection delay and greatly degrade user
   experience.

It is not Happy Eyeballs = which has proven that, it is experience with dual-stack. Suggestion: = "Experience with dual-stack has proven = that...".

- Section = 4.1:

      The dual-stack client SHOULD =
perform an A and AAAA record lookup
      of the domain name and add the respective IPv4/IPv6 addresses to
      the list of IP addresses to be =
contacted.

Suggested rewording: "A = dual-stack client SHOULD perform A and AAAA record lookups of the domain = name and add all resulting IPv4 and/or IPv6 addresses to the list of IP = addresses to be contacted."
THe normative = language here is actually RFC 2782 - DNS SRV. Maybe we should avoid = "should" here.


Nits
=3D=3D=3D
- In the abstract, add a reference to the Happy Eyeballs = RFC.

- Section = 4.1:

   Once the transport protocol has =
been determined, the procedure for
   discovering an ip address

s/ip/IP/

Thank you very much for your review! We'll update = the draft.

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

= --Apple-Mail=_C793A8B6-2469-4CD9-8D15-293EB5B86EB5-- From nobody Sun Nov 30 07:51:04 2014 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 6E8FB1A037E for ; Sun, 30 Nov 2014 07:51:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WXryku9RU9w for ; Sun, 30 Nov 2014 07:51:02 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1042E1A0370 for ; Sun, 30 Nov 2014 07:51:02 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id u10so7517315lbd.17 for ; Sun, 30 Nov 2014 07:51:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=uiwb6A5KcrSo4ncPRgNeyZXTSPiEQy96GwwB6DxeD8U=; b=Pk1N/KiKpW4aTuGzShJpMiK9s0kOrkZEI7bq5XADGIqCsh3tjVmMremIz3aYLaiLV4 H0xebT0bR3oB9ms51r8npc/XayCTCgtUXqIx/9UBgy1B8zLmCwZ4ywX4PminWZun480V v8l6GmFJzqVwSm0bRyNH78Ls2kYAGAuV5WuIQMzux4CNP2eEXC2PNOivbm3XDtFPN5vI zNEaKMTV/OCmTFSbuH9FOBFI5tIFWwD8rZ3qa6M1PaiKCMktgu6SLXsxKvcx9kt4/SbC UcyVomCXV6xfTAiEO6IhnAmY90iZNzW36Q9vy3hahWKuTIp1I2TzkbcKajryB0V0MMRJ u5Cg== X-Gm-Message-State: ALoCoQk3EFsd7mLxBVeCC9DCml35kc4+CKOM6vZP2l2LtP+QNBTp0MNxT4cRkvocu0sC6putQYHy MIME-Version: 1.0 X-Received: by 10.152.29.4 with SMTP id f4mr7321084lah.43.1417362660426; Sun, 30 Nov 2014 07:51:00 -0800 (PST) Received: by 10.25.84.145 with HTTP; Sun, 30 Nov 2014 07:51:00 -0800 (PST) In-Reply-To: <9A8678A7-6527-467C-B914-86F7241E34C4@edvina.net> References: <9A8678A7-6527-467C-B914-86F7241E34C4@edvina.net> Date: Sun, 30 Nov 2014 10:51:00 -0500 Message-ID: From: Simon Perreault To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=089e0160b754e49fb6050915752a Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/YpvnNJKZMjuzXbSvYBDf28KDQc0 Cc: sipcore@ietf.org, draft-ietf-sipcore-dns-dual-stack@tools.ietf.org Subject: Re: [sipcore] Review of draft-ietf-sipcore-dns-dual-stack-01 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, 30 Nov 2014 15:51:03 -0000 --089e0160b754e49fb6050915752a Content-Type: text/plain; charset=UTF-8 On Sat, Nov 29, 2014 at 4:11 PM, Olle E. Johansson wrote: > - It's not clear to me whether Section 4.1 advocates parallel connections > or not. Is Happy Eyeballs to be applied or not? Or are we not recommending > one way or another? This needs to be made more explicit. > > We tried to avoid that to prepare for another draft that talks about the > connections. This draft focuses on making > both the IPv4 and IPv6 candidates available. > Ok, then say so explicitly. The numerous references to HE throughout the text can easily trick the reader into thinking that HE is implicitly required. Simon --089e0160b754e49fb6050915752a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sat, Nov 29, 2014 at 4:11 PM, Olle E. Johansson <oej@edvina.net> wrote:
- It's not clear to me whether= Section 4.1 advocates parallel connections or not. Is Happy Eyeballs to be= applied or not? Or are we not recommending one way or another? This needs = to be made more explicit.
We tried to avoid = that to prepare for another draft that talks about the connections. This dr= aft focuses on making
both the IPv4 and IPv6 candidates available= .

Ok, then say so explicitly. The numerous refe= rences to HE throughout the text can easily trick the reader into thinking = that HE is implicitly required.

<= div class=3D"gmail_extra">Simon --089e0160b754e49fb6050915752a-- From nobody Sun Nov 30 23:50:29 2014 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 A61121A1A46 for ; Sun, 30 Nov 2014 23:50:27 -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 uFNQ6Ywywfsy for ; Sun, 30 Nov 2014 23:50:25 -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 7EAF71A1B0A for ; Sun, 30 Nov 2014 23:50:24 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-70-547c1dbebacc Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 70.D5.24955.EBD1C745; Mon, 1 Dec 2014 08:50:22 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 08:50:21 +0100 From: Christer Holmberg To: Ivo Sedlacek , Andrew Allen , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQBeGiFbV1ztW9cUOimw2I9kop/5x1Mf8AgABuBICAAINygIAER0LQ Date: Mon, 1 Dec 2014 07:50:21 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D55F0A8@ESESSMB209.ericsson.se> References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127A5796@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127A5FFC@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127A5FFC@ESESSMB301.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+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje4+2ZoQg7MLRSzuz9vKaPH1xyY2 ByaPWQ1r2T2WLPnJFMAUxWWTkpqTWZZapG+XwJVx8clX9oIV3hV3DlxibmBcZ9vFyMkhIWAi MXvWdCYIW0ziwr31bF2MXBxCAkcYJba2PmOHcBYzSrS9aWTpYuTgYBOwkOj+pw3SICJQLbGh qY8RxBYWCJZ4vbmTBSIeIjFz/Q5GCNtN4sedt2wgNouAisT3y0vAbF4BX4mLf+cwQszvYJK4 0PGWHSTBKeAncePKOrAiRqCLvp9aA3Yds4C4xK0n86EuFZBYsuc8M4QtKvHy8T9WkNskBJQk pm1NgyjXkViw+xMbhK0tsWzha2aIvYISJ2c+YZnAKDoLydRZSFpmIWmZhaRlASPLKkbR4tTi pNx0I2O91KLM5OLi/Dy9vNSSTYzAODm45bfqDsbLbxwPMQpwMCrx8BYsrA4RYk0sK67MPcQo zcGiJM678Ny8YCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MVQfsbDvy50TO9Mq/ttDkV0/w RJ4lNdaKeTKK9/2LbjHZ/jAJZDR+fa8lrlxXvzTqg4FAie3GGJXcVyxJ6kwbao8khFYeXsF5 TuHeCVeJ+3L27ApC81Pv7jXfYbVnt/uqXe9F9get6H+5Zp6VKvfCHb7NBwU2LDKXcvzuoW17 6sgN+xKRryFKLMUZiYZazEXFiQBB4AojdAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/N-U6zrg8dO7R7loBf_MPVRgFrpw Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.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: Mon, 01 Dec 2014 07:50:27 -0000 Hi, I think the text suggested by Ivo looks good. It makes it clear that [I-D.i= etf-sipcore-refer-explicit-subscription] IS the "pure" protocol mechanism f= or preventing an implicit subscription, while there exists "special environ= ments" where it is dealt with using other means. The only reason these "special environment" use-cases exist to begin with i= s because previously there was no "pure" protocol mechanism for preventing = implicit subscriptions. And, as they have existed for a while already, and = have been implemented, they will not suddenly go away just because we now h= ave [I-D.ietf-sipcore-refer-explicit-subscription]. Neither will they go aw= ay just because we now have drafts clarifying some RFCs.=20 BUT, because we now DO have a "pure" protocol mechanism [I-D.ietf-sipcore-r= efer-explicit-subscription] for preventing implicit subscriptions, I assume= there will be no NEW "special environment" use-cases in future - people WI= LL use [I-D.ietf-sipcore-refer-explicit-subscription] :) Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek Sent: 28. marraskuuta 2014 17:29 To: Ivo Sedlacek; Andrew Allen; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hello, I think Andrew's proposed statement can be replaced by the statement alread= y existing in the draft, i.e. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D If a user agent can be certain that no implicit subscription will be created as a result of sending a REFER request (such as by requiring an extension that disallows any such subscription [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request MAY be sent within an existing dialog. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D and extended as follows: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D If a user agent can be certain that no implicit subscription will be created as a result of sending a REFER request (such as by requiring an extension that disallows any such subscription [I-D.ietf-sipcore-refer-explicit-subscription] >>>or by RFC4488 together= with configuration / application logic in specific environment ensuring t= hat implicit subscription is not created<<<), the REFER request MAY be sent within an existing dialog. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Kind regards Ivo Sedlacek -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek Sent: 28. listopadu 2014 8:38 To: Andrew Allen; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hello, I disagree with proposed statement:=20 "Only=20 when using the explicit subscription mechanism to require that a subscription not be created MAY the REFER request be sent=20 within an existing dialog." There are existing means how the UA can be sure that implicit subscription = will not be created - they rely on media feature tag and RFC4488, but work = neverthless. Therefore, I see the proposed statement as unnecessary restrictive. RFC6665= statement is sufficient. Kind regards Ivo Sedlacek -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew Allen Sent: 28. listopadu 2014 2:04 To: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Robert Thanks for getting the WG version of the draft out. The main issue for me with the draft is the criteria for how the UA knows t= hat it will not end up with an explicit subscription. Currently the draft i= s vague about that. Some deployments don't currently have the potential to create an implicit s= ubscription because of something defined outside of the SIP protocol ensure= s that they only perform a subset of the defined behavior in RFCs 3515, 666= 5 and 4488 i.e. by defining that the UAC always includes refersub=3Dfalse a= nd by defining that the UAS always accepts that request to not create a sub= scription with the only way for a UAC to determine that the UAS will behave= that way is because it (maybe) received a media-feature tag or feature cap= ability indicator that it knows by means outside the SIP protocol (from som= e other SDOs specification or it's a proprietary implementation where a sin= gle vendor defines both ends) that this will be the behavior. I think we should clearly decide whether this fulfils the criteria for a UA= C to determine definitively that no implicit subscription will be created a= nd hence allows the UAC to send the Refer on an existing dialog or not.=20 My own preference is not to have this qualify as a way for a UAC to be cert= ain as this makes SIP protocol behavior dependent on some higher layer appl= ication semantic creating a tight coupling between the application and the = SIP protocol stack making it difficult to reuse off the shelf SIP stacks fo= r you application. It should be a protocol issue (defined in RFCs) not an a= pplication issue as to whether a request is sent on the same or a different= dialog. I am also concerned that this kind of thing makes it more likely that the U= AS in these cases ends up being only a partial implementation of the protoc= ol (e.g. It doesn't even implement receiving a Refer out of dialog and cann= ot send a Notify even if a UAC did not include Refersub =3D false). I think= the discussion we had in Dispatch in Hawaii shows that future interoperabi= lity problems are caused when only partial implementations of the protocol = are done and assumptions about the behavior in perpetuity of the UAC are ma= de. My preference is that refer-clarifications should only allow refer-explicit= -subscription mechanism as a means for UAC to determine that its ok to send= the Refer on an existing dialog and that we make refer-clarifications depe= ndent on refer-explicit-subscription. If you want to send on an existing di= alog then you use the refer-explicit-subscription mechanism and Require nos= ub otherwise you follow the RFC 6665 behavior and if you have a GRUU as the= target then you send outside the existing dialog. That is clear and deter= ministic. So my proposal is to change the following text in section 4 from : If a user agent can be certain that no implicit subscription will be created as a result of sending a REFER request (such as by requiring an extension that disallows any such subscription [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request MAY be sent within an existing dialog. Such a REFER will be constructed with its Contact header field populated with the dialog's Local URI as specified in section 12 of [RFC3261]. To A user agent can be certain that no implicit subscription will be created as a result of sending a REFER request by using the extension in [I-D.ietf-sipcore-refer-explicit-subscription] to=20 require the UAS not to create an implicit subscription. Only=20 when using the explicit subscription mechanism to require that a subscription not be created MAY the REFER request be sent=20 within an existing dialog. Such a REFER will be constructed with=20 its Contact header field populated with the dialog's Local URI as=20 specified in section 12 of [RFC3261]. Andrew -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Friday, November 21, 2014 6:19 PM To: i-d-announce@ietf.org Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.t= xt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : Clarifications for the use of REFER with RFC6665 Authors : Robert Sparks Adam Roach Filename : draft-ietf-sipcore-refer-clarifications-00.txt Pages : 6 Date : 2014-11-21 Abstract: The SIP REFER method relies on the SIP-Specific Event Notification Framework. That framework was revised by RFC6665. This document highlights the implications of the requirement changes in RFC6665, and updates the definition of the REFER method, RFC3515, to clarify and disambiguate the impact of those changes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarifications/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-refer-clarifications-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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