From nobody Mon Jan 5 07:37:13 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472731A00E4 for ; Mon, 5 Jan 2015 07:37:11 -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 yif5S_dtnqru for ; Mon, 5 Jan 2015 07:37: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 8FDC11A00A7 for ; Mon, 5 Jan 2015 07:37:08 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t05Fb2sA009705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Jan 2015 09:37:03 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54AAAF99.3020207@nostrum.com> Date: Mon, 05 Jan 2015 09:36:57 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Christer Holmberg , "sipcore@ietf.org" References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127A5796@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127A5FFC@ESESSMB301.ericsson.se> <547CB095.6060306@alum.mit.edu> <547CD80E.7000808@nostrum.com> <059F3547244B7F4DB728757635C2DC4B15DB21A7@DEMUMBX003.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1D578385@ESESSMB209.ericsson.se> <059F3547244B7F4DB728757635C2DC4B15DB3190@DEMUMBX003.nsn-intra.net> <39B5E4D390E9BD4890E2B31079006101127B7ECC@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/AsK2QH4CDKON4ekBoMvdvElOcIA 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, 05 Jan 2015 15:37:11 -0000 Iterating on this (with comments inline later): Add this as the 3rd paragraph of the introduction. Note that there are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media feature tags. Such implementations revert to creating a subscription inside the dialog when interoperating with standard implementations outside those environments. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative that prevents that additional dialog usage. And make this fairly minor change to section 4: If a user agent has used standardized mechanisms to ensure 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]. On 12/19/14 6:51 AM, Christer Holmberg wrote: > Hi Robert, > > In general, the text looks good, and I also very much appreciate the fact that you are willing to work on a compromise. A couple of comments, though. > > Q1: I don't think the statement regarding failed interoperability is correct (Ivo has previously explained how it would work), so I suggest to remove that. But, instead I suggest to extend the last sentence to: > > "The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative, which is also expected to be used future implementations in the specialized environments mentioned above." I took a slightly different approach that I hope resolves the tension. I don't think we should add what we think 3gpp will go do with this into the document - we only need to say what can be done. > > Q2: Your suggested section 4 text says: > > "If a user agent has used standardized mechanisms to ensure 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." > > To a reader that hasn't been following this discussion it may seem like you're "overwriting" the earlier statement regarding specialized environments, so personally I think we could keep the existing text (starting with "If a user agent can be certain..."). I think the proposed text is exactly what we're trying to say - it's defining the proposed standard for the internet. In the system described by the RFC series, it is not ok to send that REFER in the existing dialog. This document (with the proposed text here) is acknowledging that the behavior occurs in specialized environments, but it does not make it standard behavior on the Internet. The proposed text in no way takes overwrites the earlier statement that the behavior in those specialized environments exists. > > Regards, > > Christer > > > > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert Sparks > Sent: 19. joulukuuta 2014 0:46 > To: sipcore@ietf.org > Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt > > So, does this text work to accomplish the goal: > > > We put this as the 3rd paragraph of the introduction. > > Note that there are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media feature tags. Such implementations will fail to interoperate with standard implementations outside those environments. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative. > > And make this fairly minor change to section 4: > > If a user agent has used standardized mechanisms to ensure 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]. > > RjS > > On 12/18/14 10:57 AM, Christer Holmberg wrote: >> Hi, >> >>>> Can you live with this as a compromise? >>>> >>>> Basically document and accept that there are existing applications >>>> which use RFC4488 and feature tags to indicate that the UAS will accept the UAC request not to create a subscription. >>>> But deprecate this behavior for new applications going forward and >>>> require for future applications the use of [I-D.ietf-sipcore-refer-explicit-subscription] in order to reuse then existing dialog. >>> I'm not in love with it, but I can live with it. I'm still >>> apprehensive about the precedent of condoning out-of-spec behavior >>> after the fact, and would prefer something that drives 3GPP to incorporate more compliant behavior in future revisions. But if everyone else is happy with this general principle, I'll stay out of the way. >> I appreciate that you can live with the compromise. >> >> And, again, as we now will have an IETF mechanism, I am sure 3GPP will use it in any future use-cases. At least I would push for it, and I see no reason why others wouldn't. >> >> Regards, >> >> Christer >> >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Jan 5 07:37:58 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593331A00F7 for ; Mon, 5 Jan 2015 07:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMs93TtwACDz for ; Mon, 5 Jan 2015 07:37:55 -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 661BE1A0137 for ; Mon, 5 Jan 2015 07:37:55 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t05Fbpst009950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Jan 2015 09:37:51 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54AAAFCA.3090403@nostrum.com> Date: Mon, 05 Jan 2015 09:37:46 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ivo Sedlacek , Christer Holmberg , "sipcore@ietf.org" References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127A5FFC@ESESSMB301.ericsson.se> <547CB095.6060306@alum.mit.edu> <547CD80E.7000808@nostrum.com> <059F3547244B7F4DB728757635C2DC4B15DB21A7@DEMUMBX003.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1D578385@ESESSMB209.ericsson.se> <059F3547244B7F4DB728757635C2DC4B15DB3190@DEMUMBX003.nsn-intra.net> <39B5E4D390E9BD4890E2B31079006101127B7ECC@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <5494322D.4050801@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127CEA71@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127CEA71@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/b_hbSnr1RfKoJfE-fxvJbGxOaJQ 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, 05 Jan 2015 15:37:57 -0000 Thanks Ivo - I think I've aligned the proposed text to this (see the other thread). Does it work for you? RjS On 12/22/14 1:54 AM, Ivo Sedlacek wrote: >> I went looking for that explanation to refresh my memory, but couldn't find >> it quickly. Can you provide a pointer? > In short: > - UAC of the initial INVITE request indicates support of a feature using a media feature tag and support of norefersub in the initial INVITE request. > - the REFER with norefersub is sent (by the UA which acted as the UAS of the initial INVITE request) within the dialog *ONLY* if the UAC of initial INVITE request indicated the media feature tag and support of norefersub in the initial INVITE request. > - description of the feature associated with the media feature tag guarantees that recipient of the REFER with norefersub will accept the REFER without creating an implicit subscription. > > The original mail with the short description is attached. > > Kind regards > > Ivo Sedlacek From nobody Tue Jan 6 02:18:41 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2B81A9148 for ; Tue, 6 Jan 2015 02:18:39 -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 sAI4buYiv63I for ; Tue, 6 Jan 2015 02:18:37 -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 9D48F1A9144 for ; Tue, 6 Jan 2015 02:18:36 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-b6-54abb67ab263 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 73.35.04231.A76BBA45; Tue, 6 Jan 2015 11:18:34 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.90]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0195.001; Tue, 6 Jan 2015 11:18:33 +0100 From: Ivo Sedlacek To: Robert Sparks , Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQKP17EjRAnWupykGrnnDBrU0+j5yy3Rfg Date: Tue, 6 Jan 2015 10:18:33 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127A5796@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127A5FFC@ESESSMB301.ericsson.se> <547CB095.6060306@alum.mit.edu> <547CD80E.7000808@nostrum.com> <059F3547244B7F4DB728757635C2DC4B15DB21A7@DEMUMBX003.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1D578385@ESESSMB209.ericsson.se> <059F3547244B7F4DB728757635C2DC4B15DB3190@DEMUMBX003.nsn-intra.net> <39B5E4D390E9BD4890E2B31079006101127B7ECC@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> In-Reply-To: <54AAAF99.3020207@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.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvjW7VttUhBh9fGFpcm9PIZvH1xyY2 ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugStj2T6RgvsOFe9+7WBrYHxj0sXIySEhYCJx o/8tE4QtJnHh3nq2LkYuDiGBI4wSCxYcYIZwFjFKfD9wlQ2kik1AT2LiliOsIAkRgVZGidd/ z7OCJIQFgiVeb+5kAbFFBEIkZq7fwQhhG0kcnLKHHcRmEVCR2D+7EayeV8BX4ufhXawQG7o4 JGa/ugG2gVNAW+LLrc1ggxgFZCWu/ukFG8QsIC5x68l8qFsFJJbsOc8MYYtKvHz8jxXCVpS4 On05E0S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERtFZSMbOQtIyC0nLLCQtCxhZVjGKFqcW F+emGxnrpRZlJhcX5+fp5aWWbGIExsrBLb91dzCufu14iFGAg1GJh9fg38oQIdbEsuLK3EOM 0hwsSuK8i87NCxYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAuGpzot3cU6eM7sjemS2x0FrQ plriy/kcs0f2m28pVv58MrVMK8rh5/OUZZkVjFHfCqXMOd0V3kpPKH/NLOd/S/3Z5Pfpk6JZ p5wQvrsz+6P5gkWBkz6xT1NWzpwS5jEhc0PZdtG8kARW4d/vu1UfqR36udp07mfmv+X/PjeK 7Tf2LTszY4/LGSWW4oxEQy3mouJEAA1NqSF2AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/V4KwOlurrZHkpXEq3lAtFRFDKIY 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: Tue, 06 Jan 2015 10:18:40 -0000 Hello Robert, IMO, the statement "Such implementations revert to creating a subscription = inside the dialog when interoperating with standard implementations outside= those environments. " is incorrect. In 3GPP use case: 1) the particular media feature tag indicates that the UA ensures NOT creat= ing the subscription inside the dialog for received REFERs with norefersub 2) UA-A sending INVITE request includes the particular media feature tag in= INVITE request and thus indicates support of the feature in the bullet 1. 3) when UA-B receives an INVITE request: - if the INVITE request contains the particular media feature tag - i.e. U= A-A sending the INVITE request supports feature in bullet 1, the UA-B can s= afely send in-dialog REFER with norefersub. UA-A will ensure that the subsc= ription inside the dialog is not created due to bullet 1. - if the INVITE request does not contain the particular media feature tag,= the UA-B does not send in-dialog REFER to UA-A. Why would this procedure "revert to creating a subscription inside the dial= og when interoperating with standard implementations outside those environm= ents"? Thus, I would prefer to keep the existing text in section 4. Kind regards Ivo Sedlacek 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=20 -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert Sparks Sent: 5. ledna 2015 16:37 To: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Iterating on this (with comments inline later): Add this as the 3rd paragraph of the introduction. Note that there are implementations in some known specialized environments = (such as 3gpp) that use out-of-signalling agreements to ensure that in-dial= og REFER requests using the RFC4488 extension do not create a new subscript= ion inside that dialog. In the 3gpp environment, the behavior is based on c= apabilities advertised using media feature tags. Such implementations rever= t to creating a subscription inside the dialog when interoperating with sta= ndard implementations outside those environments. The extensions in [I-D.ie= tf-sipcore-refer-explicit-subscription] provide a standardized alternative = that prevents that additional dialog usage. And make this fairly minor change to section 4: If a user agent has used standardized mechanisms to ensure 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]. On 12/19/14 6:51 AM, Christer Holmberg wrote: > Hi Robert, > > In general, the text looks good, and I also very much appreciate the fact= that you are willing to work on a compromise. A couple of comments, though= . > > Q1: I don't think the statement regarding failed interoperability is corr= ect (Ivo has previously explained how it would work), so I suggest to remov= e that. But, instead I suggest to extend the last sentence to: > > "The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provid= e a standardized alternative, which is also expected to be used future impl= ementations in the specialized environments mentioned above." I took a slightly different approach that I hope resolves the tension. I do= n't think we should add what we think 3gpp will go do with this into the do= cument - we only need to say what can be done. > > Q2: Your suggested section 4 text says: > > "If a user agent has used standardized mechanisms to ensure 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 REF= ER > request MAY be sent within an existing dialog." > > To a reader that hasn't been following this discussion it may seem like y= ou're "overwriting" the earlier statement regarding specialized environment= s, so personally I think we could keep the existing text (starting with "If= a user agent can be certain..."). I think the proposed text is exactly what we're trying to say - it's defini= ng the proposed standard for the internet. In the system described by the RFC series, it is not ok to send that REFER = in the existing dialog. This document (with the proposed text here) is acknowledging that the behav= ior occurs in specialized environments, but it does not make it standard be= havior on the Internet. The proposed text in no way takes overwrites the ea= rlier statement that the behavior in those specialized environments exists. > > Regards, > > Christer > > > > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert=20 > Sparks > Sent: 19. joulukuuta 2014 0:46 > To: sipcore@ietf.org > Subject: Re: [sipcore] I-D Action:=20 > draft-ietf-sipcore-refer-clarifications-00.txt > > So, does this text work to accomplish the goal: > > > We put this as the 3rd paragraph of the introduction. > > Note that there are implementations in some known specialized environment= s (such as 3gpp) that use out-of-signalling agreements to ensure that in-di= alog REFER requests using the RFC4488 extension do not create a new subscri= ption inside that dialog. In the 3gpp environment, the behavior is based on= capabilities advertised using media feature tags. Such implementations wil= l fail to interoperate with standard implementations outside those environm= ents. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] prov= ide a standardized alternative. > > And make this fairly minor change to section 4: > > If a user agent has used standardized mechanisms to ensure 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 REFE= R > 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]. > > RjS > > On 12/18/14 10:57 AM, Christer Holmberg wrote: >> Hi, >> >>>> Can you live with this as a compromise? >>>> >>>> Basically document and accept that there are existing applications=20 >>>> which use RFC4488 and feature tags to indicate that the UAS will accep= t the UAC request not to create a subscription. >>>> But deprecate this behavior for new applications going forward and=20 >>>> require for future applications the use of [I-D.ietf-sipcore-refer-exp= licit-subscription] in order to reuse then existing dialog. >>> I'm not in love with it, but I can live with it. I'm still=20 >>> apprehensive about the precedent of condoning out-of-spec behavior=20 >>> after the fact, and would prefer something that drives 3GPP to incorpor= ate more compliant behavior in future revisions. But if everyone else is ha= ppy with this general principle, I'll stay out of the way. >> I appreciate that you can live with the compromise. >> >> And, again, as we now will have an IETF mechanism, I am sure 3GPP will u= se it in any future use-cases. At least I would push for it, and I see no r= eason why others wouldn't. >> >> Regards, >> >> Christer >> >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Jan 6 05:44:20 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA481A6F21 for ; Tue, 6 Jan 2015 05:44:19 -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 Nr12QrCUgLrv for ; Tue, 6 Jan 2015 05:44:16 -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 E0E551A7013 for ; Tue, 6 Jan 2015 05:44:13 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t06Di8u8084994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Jan 2015 07:44:09 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54ABE6A3.5000300@nostrum.com> Date: Tue, 06 Jan 2015 07:44:03 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ivo Sedlacek , Christer Holmberg , "sipcore@ietf.org" References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127A5FFC@ESESSMB301.ericsson.se> <547CB095.6060306@alum.mit.edu> <547CD80E.7000808@nostrum.com> <059F3547244B7F4DB728757635C2DC4B15DB21A7@DEMUMBX003.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1D578385@ESESSMB209.ericsson.se> <059F3547244B7F4DB728757635C2DC4B15DB3190@DEMUMBX003.nsn-intra.net> <39B5E4D390E9BD4890E2B31079006101127B7ECC@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/U4v9X8vAoq_MQjVVh2emqvTKxyY 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: Tue, 06 Jan 2015 13:44:19 -0000 On 1/6/15 4:18 AM, Ivo Sedlacek wrote: > Hello Robert, > > IMO, the statement "Such implementations revert to creating a subscription inside the dialog when interoperating with standard implementations outside those environments. " is incorrect. > > In 3GPP use case: > 1) the particular media feature tag indicates that the UA ensures NOT creating the subscription inside the dialog for received REFERs with norefersub > 2) UA-A sending INVITE request includes the particular media feature tag in INVITE request and thus indicates support of the feature in the bullet 1. > 3) when UA-B receives an INVITE request: > - if the INVITE request contains the particular media feature tag - i.e. UA-A sending the INVITE request supports feature in bullet 1, the UA-B can safely send in-dialog REFER with norefersub. UA-A will ensure that the subscription inside the dialog is not created due to bullet 1. > - if the INVITE request does not contain the particular media feature tag, the UA-B does not send in-dialog REFER to UA-A. > So, you're saying you will _NEVER_ send an in-dialog REFER to a UA that doesn't provide that media feature tag, correct? So, in the very last case above, do you send the REFER out-of-dialog, or do you refuse to send a REFER at all? If you send the REFER out-of-dialog, what do you do if UA-A doesn't accept out-of-dialog REFER requests? > > > Thus, I would prefer to keep the existing text in section 4. > > Kind regards > > Ivo Sedlacek > > This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer > > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert Sparks > Sent: 5. ledna 2015 16:37 > To: Christer Holmberg; sipcore@ietf.org > Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt > > Iterating on this (with comments inline later): > > Add this as the 3rd paragraph of the introduction. > > Note that there are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media feature tags. Such implementations revert to creating a subscription inside the dialog when interoperating with standard implementations outside those environments. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative that prevents that additional dialog usage. > > And make this fairly minor change to section 4: > > If a user agent has used standardized mechanisms to ensure 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]. > > On 12/19/14 6:51 AM, Christer Holmberg wrote: >> Hi Robert, >> >> In general, the text looks good, and I also very much appreciate the fact that you are willing to work on a compromise. A couple of comments, though. >> >> Q1: I don't think the statement regarding failed interoperability is correct (Ivo has previously explained how it would work), so I suggest to remove that. But, instead I suggest to extend the last sentence to: >> >> "The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative, which is also expected to be used future implementations in the specialized environments mentioned above." > I took a slightly different approach that I hope resolves the tension. I don't think we should add what we think 3gpp will go do with this into the document - we only need to say what can be done. >> Q2: Your suggested section 4 text says: >> >> "If a user agent has used standardized mechanisms to ensure 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." >> >> To a reader that hasn't been following this discussion it may seem like you're "overwriting" the earlier statement regarding specialized environments, so personally I think we could keep the existing text (starting with "If a user agent can be certain..."). > I think the proposed text is exactly what we're trying to say - it's defining the proposed standard for the internet. > In the system described by the RFC series, it is not ok to send that REFER in the existing dialog. > This document (with the proposed text here) is acknowledging that the behavior occurs in specialized environments, but it does not make it standard behavior on the Internet. The proposed text in no way takes overwrites the earlier statement that the behavior in those specialized environments exists. >> Regards, >> >> Christer >> >> >> >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert >> Sparks >> Sent: 19. joulukuuta 2014 0:46 >> To: sipcore@ietf.org >> Subject: Re: [sipcore] I-D Action: >> draft-ietf-sipcore-refer-clarifications-00.txt >> >> So, does this text work to accomplish the goal: >> >> >> We put this as the 3rd paragraph of the introduction. >> >> Note that there are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media feature tags. Such implementations will fail to interoperate with standard implementations outside those environments. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative. >> >> And make this fairly minor change to section 4: >> >> If a user agent has used standardized mechanisms to ensure 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]. >> >> RjS >> >> On 12/18/14 10:57 AM, Christer Holmberg wrote: >>> Hi, >>> >>>>> Can you live with this as a compromise? >>>>> >>>>> Basically document and accept that there are existing applications >>>>> which use RFC4488 and feature tags to indicate that the UAS will accept the UAC request not to create a subscription. >>>>> But deprecate this behavior for new applications going forward and >>>>> require for future applications the use of [I-D.ietf-sipcore-refer-explicit-subscription] in order to reuse then existing dialog. >>>> I'm not in love with it, but I can live with it. I'm still >>>> apprehensive about the precedent of condoning out-of-spec behavior >>>> after the fact, and would prefer something that drives 3GPP to incorporate more compliant behavior in future revisions. But if everyone else is happy with this general principle, I'll stay out of the way. >>> I appreciate that you can live with the compromise. >>> >>> And, again, as we now will have an IETF mechanism, I am sure 3GPP will use it in any future use-cases. At least I would push for it, and I see no reason why others wouldn't. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Jan 6 07:11:15 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5221A701E for ; Tue, 6 Jan 2015 07:11:12 -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 4TlAVfsYQypw for ; Tue, 6 Jan 2015 07:11:06 -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 F33FD1A8850 for ; Tue, 6 Jan 2015 07:11:05 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-99-54abfb071633 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 46.26.04231.70BFBA45; Tue, 6 Jan 2015 16:11:04 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.90]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0195.001; Tue, 6 Jan 2015 16:11:03 +0100 From: Ivo Sedlacek To: Robert Sparks , Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQKbbbQ1L4bNNdZUai/4eIafSY+pyzMYzw Date: Tue, 6 Jan 2015 15:11:03 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127D7FFC@ESESSMB301.ericsson.se> References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127A5FFC@ESESSMB301.ericsson.se> <547CB095.6060306@alum.mit.edu> <547CD80E.7000808@nostrum.com> <059F3547244B7F4DB728757635C2DC4B15DB21A7@DEMUMBX003.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1D578385@ESESSMB209.ericsson.se> <059F3547244B7F4DB728757635C2DC4B15DB3190@DEMUMBX003.nsn-intra.net> <39B5E4D390E9BD4890E2B31079006101127B7ECC@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> <54ABE6A3.5000300@nostrum.com> In-Reply-To: <54ABE6A3.5000300@nostrum.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+JvjS7H79UhBpc+cFlcm9PIZvH1xyY2 ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugSvjwO69LAU3uSs615g3MC7l7GLk5JAQMJH4 efkfK4QtJnHh3no2EFtI4AijRNsk6S5GLiB7EaPEmWubWUASbAJ6EhO3HGEFSYgItDJKvP57 HqxbWCBY4vXmTrAiEYEQiZnrdzBC2EYSX/c9AZvKIqAi0Tz/ODuIzSvgK7F723smiG1v2CUW bK4CsTkFtCWOH1sNNpNRQFbi6p9esDnMAuISt57MZ4K4VEBiyZ7zzBC2qMTLxyAfcADZShLT tqZBlOtILNj9iQ3C1pZYtvA1M8RaQYmTM5+wTGAUnYVk6iwkLbOQtMxC0rKAkWUVo2hxanFx brqRsV5qUWZycXF+nl5easkmRmCUHNzyW3cH4+rXjocYBTgYlXh4DQ6sDhFiTSwrrsw9xCjN waIkzrvo3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxO7FWCu/X4LgXaXtq9df2liR1r bpm8syx8dkRA3qFo77V3i6XnO975Y7dfyujxJh2tC7MOnWypyu8PvaB7p7WnIHMvi6fPv+sv z6z/b/7Kcckdt5MtjRfu/3fie+7gZP7uoPThuTfkjtjUCu1Y4p/PrV8l6jD5xYK/Mu/ebOtr EnAJr33XWf5YiaU4I9FQi7moOBEAHj9QtHMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/QyfrLFOeztD-LEYWvROlXaEbDNM 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: Tue, 06 Jan 2015 15:11:12 -0000 Hello, > > IMO, the statement "Such implementations revert to creating a subscript= ion inside the dialog when interoperating with standard implementations out= side those environments. " is incorrect. > > > > In 3GPP use case: > > 1) the particular media feature tag indicates that the UA ensures NOT=20 > > creating the subscription inside the dialog for received REFERs with=20 > > norefersub > > 2) UA-A sending INVITE request includes the particular media feature ta= g in INVITE request and thus indicates support of the feature in the bullet= 1. > > 3) when UA-B receives an INVITE request: > > - if the INVITE request contains the particular media feature tag - i.= e. UA-A sending the INVITE request supports feature in bullet 1, the UA-B c= an safely send in-dialog REFER with norefersub. UA-A will ensure that the s= ubscription inside the dialog is not created due to bullet 1. > > - if the INVITE request does not contain the particular media feature = tag, the UA-B does not send in-dialog REFER to UA-A. > > > > So, you're saying you will _NEVER_ send an in-dialog REFER to a UA that d= oesn't provide that media feature tag, correct? Correct. > So, in the very last case above, do you send the REFER out-of-dialog, or = do you refuse to send a REFER at all? If the INVITE request does not contain the particular media feature tag, th= e UA-B does not send REFER to UA-A - neither in-dialog, nor out-of-dialog. Kind regards Ivo Sedlacek From nobody Fri Jan 9 07:49:12 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F0F1A0233 for ; Fri, 9 Jan 2015 07:49:10 -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 DVWjQPZPZVDu for ; Fri, 9 Jan 2015 07:49: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 E5E571A0067 for ; Fri, 9 Jan 2015 07:49:08 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t09Fn2ZI066329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Jan 2015 09:49:03 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54AFF86A.9070605@nostrum.com> Date: Fri, 09 Jan 2015 09:48:58 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ivo Sedlacek , Christer Holmberg , "sipcore@ietf.org" References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <547CB095.6060306@alum.mit.edu> <547CD80E.7000808@nostrum.com> <059F3547244B7F4DB728757635C2DC4B15DB21A7@DEMUMBX003.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1D578385@ESESSMB209.ericsson.se> <059F3547244B7F4DB728757635C2DC4B15DB3190@DEMUMBX003.nsn-intra.net> <39B5E4D390E9BD4890E2B31079006101127B7ECC@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> <54ABE6A3.5000300@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7FFC@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127D7FFC@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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, 09 Jan 2015 15:49:11 -0000 On 1/6/15 9:11 AM, Ivo Sedlacek wrote: > Hello, > >>> IMO, the statement "Such implementations revert to creating a subscription inside the dialog when interoperating with standard implementations outside those environments. " is incorrect. >>> >>> In 3GPP use case: >>> 1) the particular media feature tag indicates that the UA ensures NOT >>> creating the subscription inside the dialog for received REFERs with >>> norefersub >>> 2) UA-A sending INVITE request includes the particular media feature tag in INVITE request and thus indicates support of the feature in the bullet 1. >>> 3) when UA-B receives an INVITE request: >>> - if the INVITE request contains the particular media feature tag - i.e. UA-A sending the INVITE request supports feature in bullet 1, the UA-B can safely send in-dialog REFER with norefersub. UA-A will ensure that the subscription inside the dialog is not created due to bullet 1. >>> - if the INVITE request does not contain the particular media feature tag, the UA-B does not send in-dialog REFER to UA-A. >>> >> So, you're saying you will _NEVER_ send an in-dialog REFER to a UA that doesn't provide that media feature tag, correct? > Correct. And for completeness, you will always reject any REFER sent from such a UA? >> So, in the very last case above, do you send the REFER out-of-dialog, or do you refuse to send a REFER at all? > If the INVITE request does not contain the particular media feature tag, the UA-B does not send REFER to UA-A - neither in-dialog, nor out-of-dialog. > > Kind regards > > Ivo Sedlacek From nobody Fri Jan 9 09:13:55 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C4C1A8728 for ; Fri, 9 Jan 2015 09:13:53 -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 JFJONf_kjnGq for ; Fri, 9 Jan 2015 09:13:50 -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 D0CAB1A7D82 for ; Fri, 9 Jan 2015 09:13:50 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t09HDjcP073285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Jan 2015 11:13:46 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54B00C45.3080500@nostrum.com> Date: Fri, 09 Jan 2015 11:13:41 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Christer Holmberg , "sipcore@ietf.org" References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127A5796@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127A5FFC@ESESSMB301.ericsson.se> <547CB095.6060306@alum.mit.edu> <547CD80E.7000808@nostrum.com> <059F3547244B7F4DB728757635C2DC4B15DB21A7@DEMUMBX003.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1D578385@ESESSMB209.ericsson.se> <059F3547244B7F4DB728757635C2DC4B15DB3190@DEMUMBX003.nsn-intra.net> <39B5E4D390E9BD4890E2B31079006101127B7ECC@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> In-Reply-To: <54AAAF99.3020207@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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, 09 Jan 2015 17:13:53 -0000 Ok. One more try, reflecting my understanding of what Ivo has provided in the changes to the introduction. Please make sure what it says is true (particularly the "or accept" part). Add this as the 3rd paragraph of the introduction: Note that there are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media feature tags. Such implementations will never send or accept any REFER from a peer that hasn't provided those media feature tags. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative. And leave the text in section 4 as is. On 1/5/15 9:36 AM, Robert Sparks wrote: > Iterating on this (with comments inline later): > > Add this as the 3rd paragraph of the introduction. > > Note that there are implementations in some known specialized > environments (such as 3gpp) that use out-of-signalling agreements to > ensure that in-dialog REFER requests using the RFC4488 extension do > not create a new subscription inside that dialog. In the 3gpp > environment, the behavior is based on capabilities advertised using > media feature tags. Such implementations revert to creating a > subscription inside the dialog when interoperating with standard > implementations outside those environments. The extensions in > [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized > alternative that prevents that additional dialog usage. > > And make this fairly minor change to section 4: > > If a user agent has used standardized mechanisms to ensure 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]. > > On 12/19/14 6:51 AM, Christer Holmberg wrote: >> Hi Robert, >> >> In general, the text looks good, and I also very much appreciate the >> fact that you are willing to work on a compromise. A couple of >> comments, though. >> >> Q1: I don't think the statement regarding failed interoperability is >> correct (Ivo has previously explained how it would work), so I >> suggest to remove that. But, instead I suggest to extend the last >> sentence to: >> >> "The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] >> provide a standardized alternative, which is also expected to be used >> future implementations in the specialized environments mentioned above." > I took a slightly different approach that I hope resolves the tension. > I don't think we should add what we think 3gpp will go do with this > into the document - we only need to say what can be done. >> >> Q2: Your suggested section 4 text says: >> >> "If a user agent has used standardized mechanisms to ensure 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." >> >> To a reader that hasn't been following this discussion it may seem >> like you're "overwriting" the earlier statement regarding specialized >> environments, so personally I think we could keep the existing text >> (starting with "If a user agent can be certain..."). > I think the proposed text is exactly what we're trying to say - it's > defining the proposed standard for the internet. > In the system described by the RFC series, it is not ok to send that > REFER in the existing dialog. > This document (with the proposed text here) is acknowledging that the > behavior occurs in specialized environments, but it does not make it > standard behavior on the Internet. The proposed text in no way takes > overwrites the earlier statement that the behavior in those > specialized environments exists. >> >> Regards, >> >> Christer >> >> >> >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert >> Sparks >> Sent: 19. joulukuuta 2014 0:46 >> To: sipcore@ietf.org >> Subject: Re: [sipcore] I-D Action: >> draft-ietf-sipcore-refer-clarifications-00.txt >> >> So, does this text work to accomplish the goal: >> >> >> We put this as the 3rd paragraph of the introduction. >> >> Note that there are implementations in some known specialized >> environments (such as 3gpp) that use out-of-signalling agreements to >> ensure that in-dialog REFER requests using the RFC4488 extension do >> not create a new subscription inside that dialog. In the 3gpp >> environment, the behavior is based on capabilities advertised using >> media feature tags. Such implementations will fail to interoperate >> with standard implementations outside those environments. The >> extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide >> a standardized alternative. >> >> And make this fairly minor change to section 4: >> >> If a user agent has used standardized mechanisms to ensure 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]. >> >> RjS >> >> On 12/18/14 10:57 AM, Christer Holmberg wrote: >>> Hi, >>> >>>>> Can you live with this as a compromise? >>>>> >>>>> Basically document and accept that there are existing applications >>>>> which use RFC4488 and feature tags to indicate that the UAS will >>>>> accept the UAC request not to create a subscription. >>>>> But deprecate this behavior for new applications going forward and >>>>> require for future applications the use of >>>>> [I-D.ietf-sipcore-refer-explicit-subscription] in order to reuse >>>>> then existing dialog. >>>> I'm not in love with it, but I can live with it. I'm still >>>> apprehensive about the precedent of condoning out-of-spec behavior >>>> after the fact, and would prefer something that drives 3GPP to >>>> incorporate more compliant behavior in future revisions. But if >>>> everyone else is happy with this general principle, I'll stay out >>>> of the way. >>> I appreciate that you can live with the compromise. >>> >>> And, again, as we now will have an IETF mechanism, I am sure 3GPP >>> will use it in any future use-cases. At least I would push for it, >>> and I see no reason why others wouldn't. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > From nobody Sun Jan 11 02:39:24 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99E41A1B76 for ; Sun, 11 Jan 2015 02:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, 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 5T286plooUIA for ; Sun, 11 Jan 2015 02:39:20 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id A1A961A1B75 for ; Sun, 11 Jan 2015 02:39:20 -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 6138393DE41; Sun, 11 Jan 2015 10:38:52 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 11 Jan 2015 11:39:12 +0100 Message-Id: <98D9A5ED-2B9B-415D-B0D3-F44314377E77@edvina.net> To: SIPCORE Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Olle E Johansson Subject: [sipcore] SIP and TLS in the light of Opportunistic Security 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, 11 Jan 2015 10:39:23 -0000 Opportunistic Security as defined in RFC 7435 says "Some protection most of the time". It causes a lot of rethinking. We need to look at this as well from a SIP perspective. Actually, most of the RFCs doesn't put a lot of hinders to changing policies in the UAs so that we can always try TLS and set up connections in an OS way, regardless if the certificate validates properly or not. I have found a few obstacles though: RFC 3261 says in section 26.3.1: " All SIP elements that support TLS MUST also support the SIPS URI scheme." I think it's time to remove the MUST support SIPS URI scheme. We will need to discuss ";transport=tls" again (as hinted by the latest SIPit report). And 26.3.2.1: "When it receives the TLS Certificate message, the UA SHOULD verify the certificate and inspect the site identified by the certificate. If the certificate is invalid, revoked, or if it does not identify the appropriate party, the UA MUST NOT send the REGISTER message and otherwise proceed with the registration." In the light of the work on Opportunistic Security (RFC 7435 - Informational) we can certainly discuss the MUST NOT and SHOULD in 26.3.2.1. We can certainly set up a TLS session with an invalid certificate, but should not in any way indicate anything to the user (no locks in the UI!). What do you think? /O From nobody Mon Jan 12 15:09:48 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B6F1ACE0C for ; Mon, 12 Jan 2015 15:09:43 -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 ffr44g56G4O5 for ; Mon, 12 Jan 2015 15:09:15 -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 5EE3D1ACE0D for ; Mon, 12 Jan 2015 15:08:02 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t0CN7mm1057920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2015 17:07:49 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54B453C4.4050000@nostrum.com> Date: Mon, 12 Jan 2015 17:07:48 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "Olle E. Johansson" , SIPCORE References: <98D9A5ED-2B9B-415D-B0D3-F44314377E77@edvina.net> In-Reply-To: <98D9A5ED-2B9B-415D-B0D3-F44314377E77@edvina.net> Content-Type: multipart/alternative; boundary="------------000503010505070302030205" Archived-At: Subject: Re: [sipcore] SIP and TLS in the light of Opportunistic Security 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, 12 Jan 2015 23:09:44 -0000 This is a multi-part message in MIME format. --------------000503010505070302030205 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 1/11/15 04:39, Olle E. Johansson wrote: > Opportunistic Security as defined in RFC 7435 says "Some protection > most of the time". It causes a lot of rethinking. We need to look at this > as well from a SIP perspective. Indeed. Thanks for taking the time to kick off this discussion. > Actually, most of the RFCs doesn't > put a lot of hinders to changing policies in the UAs so that we can > always try TLS and set up connections in an OS way, regardless > if the certificate validates properly or not. > > I have found a few obstacles though: > > RFC 3261 says in section 26.3.1: > > " All SIP elements that support TLS MUST also support the SIPS URI > scheme." > > I think it's time to remove the MUST support SIPS URI scheme. As part of a larger OE (opportunistic encryption) effort, a slight change here probably makes sense. But it wouldn't really be removing the MUST; it would be providing a very narrowly scoped exception. Basically, we'd be describing another TLS-based mechanism, and changing the normative statement you cite just enough to accommodate that new mechanism. > We will need to discuss ";transport=tls" again (as hinted by the latest > SIPit report). I think you're jumping to mechanism a bit too quickly here. Given the nature of OE, I'd prefer it not be something that's particularly visible on the signaling path to entities other than those actually participating in the TLS session. I certainly don't want to tempt someone to render a session as "partially secure," since that's only going to encourage the exact kind of risky user behavior that OE opponents frequently cite as a key objection. Also, you really need a design with graceful degradation to plaintext if OE is really going to be opportunistic (rather than merely unauthenticated), and pre-loading a transport onto a URI doesn't really do that (at least, without substantially changing the meaning of the "transport" parameter). There are probably other OE-specific requirements here, and maybe some SIP-specific requirements as well. We would need a more detailed treatment of the topic before we start deciding what needs to be changed. It's possible that doing something similar to "STARTTLS" would work here, but we won't know for sure until we work through the requirements. > And 26.3.2.1... 26.3.2.1 is, in its entirety, subservient to this statement from 26.3.2: "While implementers and network administrators MAY follow the normative guidelines given in the remainder of this section, these are provided only as example implementations." Given this, we don't really need to change 26.3.2.1 at all; we just need to clearly explain how a client that would otherwise use an unencrypted connection could leverage OE during registration. /a --------------000503010505070302030205 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 1/11/15 04:39, Olle E. Johansson wrote:
Opportunistic Security as defined in RFC 7435 says "Some protection
most of the time". It causes a lot of rethinking. We need to look at this
as well from a SIP perspective.

Indeed. Thanks for taking the time to kick off this discussion.

Actually, most of the RFCs doesn't
put a lot of hinders to changing policies in the UAs so that we can
always try TLS and set up connections in an OS way, regardless
if the certificate validates properly or not. 

I have found a few obstacles though:

RFC 3261 says in section 26.3.1:

"   All SIP elements that support TLS MUST also support the SIPS URI
   scheme."

I think it's time to remove the MUST support SIPS URI scheme.

As part of a larger OE (opportunistic encryption) effort, a slight change here probably makes sense. But it wouldn't really be removing the MUST; it would be providing a very narrowly scoped exception. Basically, we'd be describing another TLS-based mechanism, and changing the normative statement you cite just enough to accommodate that new mechanism.

We will need to discuss ";transport=tls" again (as hinted by the latest
SIPit report).

I think you're jumping to mechanism a bit too quickly here. Given the nature of OE, I'd prefer it not be something that's particularly visible on the signaling path to entities other than those actually participating in the TLS session. I certainly don't want to tempt someone to render a session as "partially secure," since that's only going to encourage the exact kind of risky user behavior that OE opponents frequently cite as a key objection.

Also, you really need a design with graceful degradation to plaintext if OE is really going to be opportunistic (rather than merely unauthenticated), and pre-loading a transport onto a URI doesn't really do that (at least, without substantially changing the meaning of the "transport" parameter). There are probably other OE-specific requirements here, and maybe some SIP-specific requirements as well. We would need a more detailed treatment of the topic before we start deciding what needs to be changed.

It's possible that doing something similar to "STARTTLS" would work here, but we won't know for sure until we work through the requirements.

And 26.3.2.1...

26.3.2.1 is, in its entirety, subservient to this statement from 26.3.2:
  "While implementers and network
   administrators MAY follow the normative guidelines given in the
   remainder of this section, these are provided only as example
   implementations."

Given this, we don't really need to change 26.3.2.1 at all; we just need to clearly explain how a client that would otherwise use an unencrypted connection could leverage OE during registration.

/a
--------------000503010505070302030205-- From nobody Mon Jan 12 22:59:07 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7535D1A8A17 for ; Mon, 12 Jan 2015 22:59:06 -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 zO25dy9UnXbG for ; Mon, 12 Jan 2015 22:59:04 -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 0950E1A89B4 for ; Mon, 12 Jan 2015 22:59:02 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-e2-54b4c234b698 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B2.E1.04484.432C4B45; Tue, 13 Jan 2015 07:59:01 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.90]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0195.001; Tue, 13 Jan 2015 07:59:00 +0100 From: Ivo Sedlacek To: Robert Sparks , Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQLCPOmAnYCj77wkS/z9Cxo2sng5y9ou3A Date: Tue, 13 Jan 2015 06:59:00 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127DB15E@ESESSMB301.ericsson.se> References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <547CB095.6060306@alum.mit.edu> <547CD80E.7000808@nostrum.com> <059F3547244B7F4DB728757635C2DC4B15DB21A7@DEMUMBX003.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1D578385@ESESSMB209.ericsson.se> <059F3547244B7F4DB728757635C2DC4B15DB3190@DEMUMBX003.nsn-intra.net> <39B5E4D390E9BD4890E2B31079006101127B7ECC@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> <54ABE6A3.5000300@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7FFC@ESESSMB301.ericsson.se> <54AFF86A.9070605@nostrum.com> In-Reply-To: <54AFF86A.9070605@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.17] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101127DB15EESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvja7poS0hBtsvsllcm9PIZvH1xyY2 ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugStj87Ve9oK7yRWT791hbmDcGtrFyMEhIWAi MaNTpIuRE8gUk7hwbz1bFyMXh5DAEUaJ15unM0I4ixklnlx4wgJSxSagJzFxyxFWkISIQCtQ 1d/zrCAJYYFgoI5OsCIRgRCJmet3MELYRhK/VjcA1bBzsAioSrypANnLK+ArseywJcT4Xg6J nt4H7CDVnALaElt6f7GB2IwCshJX//SCTWEWEJe49WQ+E8ShAhJL9pxnhrBFJV4+/scK8Yui xPJ+OYjyfIlz7XvBxvAKCEqcnPmEZQKjyCwkk2YhKZuFpAwiriOxYPcnNghbW2LZwtfMMPaZ A4+ZkMUXMLKvYhQtTi1Oyk03MtJLLcpMLi7Oz9PLSy3ZxAiMqYNbfhvsYHz53PEQowAHoxIP r0HXlhAh1sSy4srcQ4zSHCxK4rx5DhtChATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTA2x+nv Uvm6K1at4vwU7/UWXe/XTNsibXL4+Ya3TYu/HZ7e94nVs/Lvx9m7kxyb09PuOmnvzioWZFk5 fYK02eKwO9uEzBYobQw0zjeZp7DSa1Lv/V3Hdu3Ifpg2bXl816yd3G/MFmbuvXG6+CH/qqe8 9cUZcxXD3K2n+dx2nbGnL/fY34U1YYLCSizFGYmGWsxFxYkAOfd2sYoCAAA= Archived-At: 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: Tue, 13 Jan 2015 06:59:06 -0000 --_000_39B5E4D390E9BD4890E2B31079006101127DB15EESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, > >>> In 3GPP use case: > >>> 1) the particular media feature tag indicates that the UA ensures > >>> NOT creating the subscription inside the dialog for received REFERs > >>> with norefersub > >>> 2) UA-A sending INVITE request includes the particular media feature = tag > in INVITE request and thus indicates support of the feature in the bullet= 1. > >>> 3) when UA-B receives an INVITE request: > >>> - if the INVITE request contains the particular media feature tag = - i.e. > UA-A sending the INVITE request supports feature in bullet 1, the UA-B ca= n > safely send in-dialog REFER with norefersub. UA-A will ensure that the > subscription inside the dialog is not created due to bullet 1. > >>> - if the INVITE request does not contain the particular media feat= ure > tag, the UA-B does not send in-dialog REFER to UA-A. > >>> > >> So, you're saying you will _NEVER_ send an in-dialog REFER to a UA tha= t > doesn't provide that media feature tag, correct? > > Correct. > > And for completeness, you will always reject any REFER sent from such a U= A? The flow in 3GPP TS 24.237 (where the procedure above is defined and used) = is as follows (only tags important for this discussion are listed): Alice Bob |-------- 1. INVITE (media feature tag X)---------------------------->| |<------- 2. 200 for INVITE ------------------------------------------| |-------- 3. ACK----------------------------------------------------->| | 4. *ONLY* if media feature t= ag X is present in the INVITE, | step 5 is pe= rformed |<------- 5. in-dialog REFER (norefersub, Refer-Sub: false)-----------| 6. *ONLY* if norefersub and Refer-Sub: false | are included in the in-dialog REFER, steps 7 and 8 are performed | |-------- 7. 200 for in-dialog REFER ---------------------------------| 8. don't create implicit subscription | | | 3GPP TS 24.237: - does not give any statements how Alice is to handle a received in-dialog = REFER without norefersub and without Refer-Sub: false. If norefersub is mis= sing or if Refer-Sub: false is missing in the received in-dialog REFER, the= n RFC3515 and RFC6665 rules apply. - does not give any statements how Bob is to handle a received in-dialog RE= FER. RFC3515 and RFC6665 rules apply for the received in-dialog REFER. Does this clarify the question? Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B31079006101127DB15EESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

> >>> In 3GPP use case:

> >>> 1) the particular media feature= tag indicates that the UA ensures

> >>> NOT creating the subscription i= nside the dialog for received REFERs

> >>> with norefersub

> >>> 2) UA-A sending INVITE request = includes the particular media feature tag

> in INVITE request and thus indicates support= of the feature in the bullet 1.

> >>> 3) when UA-B receives an INVITE= request:

> >>>    - if the INVITE re= quest contains the particular media feature tag - i.e.

> UA-A sending the INVITE request supports fea= ture in bullet 1, the UA-B can

> safely send in-dialog REFER with norefersub.= UA-A will ensure that the

> subscription inside the dialog is not create= d due to bullet 1.

> >>>    - if the INVITE re= quest does not contain the particular media feature

> tag, the UA-B does not send in-dialog REFER = to UA-A.

> >>>

> >> So, you're saying you will _NEVER_ = send an in-dialog REFER to a UA that

> doesn't provide that media feature tag, corr= ect?

> > Correct.

> 

> And for completeness, you will always reject= any REFER sent from such a UA?

 

The flow in 3GPP TS 24.237 (where the procedure a= bove is defined and used) is as follows (only tags important for this discu= ssion are listed):

 

 Alice           =             &nb= sp;            =             &nb= sp;            =      Bob

   |-------- 1. INVITE (media feature tag X)-------------= --------------->|

    |<------- 2. 200 for INVITE ----------------------= --------------------|

    |-------- 3. ACK-------------------------------------= ---------------->|

    |        &nbs= p;             =             &nb= sp;       4. *ONLY* if media feature tag= X is present in the INVITE,

    |        = ;             &= nbsp;           &nbs= p;            &= nbsp;           step= 5 is performed

    |<------- 5. in-dialog REFER (norefersub, Refer-Su= b: false)-----------|

6. *ONLY* if norefersub and Refer-Sub: false     &nb= sp;            =             |

are included in the in-dialog REFER, steps 7 and 8 are performed &n= bsp;        |

    |-------- 7. 200 for in-dialog REFER ----------------= -----------------|

8. don't create implicit subscription      = ;             &= nbsp;           &nbs= p;     |

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

 

 

3GPP TS 24.237:

- does not give any statements how Alice is to ha= ndle a received in-dialog REFER without norefersub and without Refer-Sub: f= alse. If norefersub is missing or if Refer-Sub: false is missing in the rec= eived in-dialog REFER, then RFC3515 and RFC6665 rules apply.

- does not give any statements how Bob is to hand= le a received in-dialog REFER. RFC3515 and RFC6665 rules apply for the rece= ived in-dialog REFER.

 

Does this clarify the question?

 

Kind regards

 

Ivo Sedlacek

 

--_000_39B5E4D390E9BD4890E2B31079006101127DB15EESESSMB301erics_-- From nobody Tue Jan 13 00:09:56 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B3F1A8A42 for ; Tue, 13 Jan 2015 00:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8y0eI_hVLo8 for ; Tue, 13 Jan 2015 00:09:49 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCC451A8A3F for ; Tue, 13 Jan 2015 00:09:48 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-8c-54b4d2ca613e Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EB.D9.24955.AC2D4B45; Tue, 13 Jan 2015 09:09:46 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.90]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0195.001; Tue, 13 Jan 2015 09:09:46 +0100 From: Ivo Sedlacek To: Robert Sparks , Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQLC+dmAnYCj77wkS/z9Cxo2sng5y9twrw Date: Tue, 13 Jan 2015 08:09:45 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127DB332@ESESSMB301.ericsson.se> References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127A5796@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127A5FFC@ESESSMB301.ericsson.se> <547CB095.6060306@alum.mit.edu> <547CD80E.7000808@nostrum.com> <059F3547244B7F4DB728757635C2DC4B15DB21A7@DEMUMBX003.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1D578385@ESESSMB209.ericsson.se> <059F3547244B7F4DB728757635C2DC4B15DB3190@DEMUMBX003.nsn-intra.net> <39B5E4D390E9BD4890E2B31079006101127B7ECC@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> <54B00C45.3080500@nostrum.com> In-Reply-To: <54B00C45.3080500@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.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvje6pS1tCDLo/mltcm9PIZvH1xyY2 ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugStj3raFzAUHeSq+NU1ma2DcyNXFyMkhIWAi cWXlF0YIW0ziwr31bF2MXBxCAkcYJc6eaWaFcBYzSsw6u4EFpIpNQE9i4pYjYAkRgVZGidd/ z7OCJIQFgiVeb+4EKxIRCJGYuX4HI4RtJHHt5ymwGhYBVYnln98xdzFycPAK+Ep8a/KFWPCK XWJe22lmkBpOAW2JY9cvgdUzCshKXP3TCzaHWUBc4taT+UwQpwpILNlznhnCFpV4+fgfK8hM CQFFieX9chDlOhILdn9ig7C1JZYtfA1WzisgKHFy5hOWCYyis5BMnYWkZRaSlllIWhYwsqxi FC1OLU7KTTcy1kstykwuLs7P08tLLdnECIyUg1t+q+5gvPzG8RCjAAejEg+vQdeWECHWxLLi ytxDjNIcLErivHkOG0KEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MGb9SzM73j9L6sb0Ce1M Ow/ZFM1uO51x7n6764nr017cXSYo8F90UyKjVIFF4u+d3Sc0/8iLP9M3yn4j/KvjgMKtp9f3 KPoE+J+J6S5lkDQ6ZmbzT+NeJ9e6czdKP3QHHxez9TbcPXnKmihrxpCp3FfUEiqcly19NyOg Zm9E48TVxZdb83nUm5RYijMSDbWYi4oTAUxmfoV1AgAA Archived-At: 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: Tue, 13 Jan 2015 08:09:51 -0000 Hello, > Add this as the 3rd paragraph of the introduction: >=20 > Note that there are implementations in some known specialized=20 > environments (such as 3gpp) that use out-of-signalling agreements to=20 > ensure that in-dialog REFER requests using the RFC4488 extension do=20 > not create a new subscription inside that dialog. In the 3gpp=20 > environment, the behavior is based on capabilities advertised using=20 > media feature tags. Such implementations will never send or accept any=20 > REFER from a peer that hasn't provided those media feature tags. The=20 > extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a st= andardized alternative. IMO, it would be more appropriate to state: --------------- Note that there are implementations in some known specialized environments = (such as 3gpp) that use out-of-signalling agreements to ensure that in-dial= og REFER requests using the RFC4488 extension do not create a new subscript= ion inside that dialog. In the 3gpp environment, the behavior is based on c= apabilities advertised using media feature tags. >>In the 3gpp environment,= <>by definition<<< will never send >>an in-dialog<<= REFER request >>to<< a peer that hasn't provided those media feature tags = >>and never accept in-dialog REFER request without norefersub and without R= efer-Sub: false<<. The extensions in [I-D.ietf-sipcore-refer-explicit-subsc= ription] provide a standardized alternative. --------------- =20 > And leave the text in section 4 as is. OK. Kind regards Ivo Sedlacek From nobody Tue Jan 13 06:59:53 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2034C1A8AFE for ; Tue, 13 Jan 2015 06:59:52 -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 cX-KPo0VO_F5 for ; Tue, 13 Jan 2015 06:59:50 -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 EB7851A8AF9 for ; Tue, 13 Jan 2015 06:59:49 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t0DExgg4003854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Jan 2015 08:59:42 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54B532D9.8010305@nostrum.com> Date: Tue, 13 Jan 2015 08:59:37 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ivo Sedlacek , Christer Holmberg , "sipcore@ietf.org" References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D578385@ESESSMB209.ericsson.se> <059F3547244B7F4DB728757635C2DC4B15DB3190@DEMUMBX003.nsn-intra.net> <39B5E4D390E9BD4890E2B31079006101127B7ECC@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> <54ABE6A3.5000300@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7FFC@ESESSMB301.ericsson.se> <54AFF86A.9070605@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DB15E@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127DB15E@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------050805060407030404020503" Archived-At: 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: Tue, 13 Jan 2015 14:59:52 -0000 This is a multi-part message in MIME format. --------------050805060407030404020503 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 1/13/15 12:59 AM, Ivo Sedlacek wrote: > > Hello, > > > >>> In 3GPP use case: > > > >>> 1) the particular media feature tag indicates that the UA ensures > > > >>> NOT creating the subscription inside the dialog for received REFERs > > > >>> with norefersub > > > >>> 2) UA-A sending INVITE request includes the particular media > feature tag > > > in INVITE request and thus indicates support of the feature in the > bullet 1. > > > >>> 3) when UA-B receives an INVITE request: > > > >>> - if the INVITE request contains the particular media feature > tag - i.e. > > > UA-A sending the INVITE request supports feature in bullet 1, the > UA-B can > > > safely send in-dialog REFER with norefersub. UA-A will ensure that the > > > subscription inside the dialog is not created due to bullet 1. > > > >>> - if the INVITE request does not contain the particular media > feature > > > tag, the UA-B does not send in-dialog REFER to UA-A. > > > >>> > > > >> So, you're saying you will _NEVER_ send an in-dialog REFER to a > UA that > > > doesn't provide that media feature tag, correct? > > > > Correct. > > > > > > And for completeness, you will always reject any REFER sent from > such a UA? > > The flow in 3GPP TS 24.237 (where the procedure above is defined and > used) is as follows (only tags important for this discussion are listed): > > Alice Bob > > |-------- 1. INVITE (media feature tag X)---------------------------->| > > |<------- 2. 200 for INVITE > ------------------------------------------| > > |-------- 3. > ACK----------------------------------------------------->| > > | 4. *ONLY* if media > feature tag X is present in the INVITE, > > | step 5 is performed > > |<------- 5. in-dialog REFER (norefersub, Refer-Sub: > false)-----------| > > 6. *ONLY* if norefersub and Refer-Sub: false > | > > are included in the in-dialog REFER, steps 7 and 8 are > performed | > > |-------- 7. 200 for in-dialog REFER > ---------------------------------| > > 8. don't create implicit subscription > | > > | | > > 3GPP TS 24.237: > > - does not give any statements how Alice is to handle a received > in-dialog REFER without norefersub and without Refer-Sub: false. If > norefersub is missing or if Refer-Sub: false is missing in the > received in-dialog REFER, then RFC3515 and RFC6665 rules apply. > Then my currently proposed text is inaccurate, and we're back to "Such implementations revert to creating a subscription inside the dialog when interoperating with standard implementations outside those environments." > - does not give any statements how Bob is to handle a received > in-dialog REFER. RFC3515 and RFC6665 rules apply for the received > in-dialog REFER. > > Does this clarify the question? > > Kind regards > > Ivo Sedlacek > --------------050805060407030404020503 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 1/13/15 12:59 AM, Ivo Sedlacek wrote:

Hello,

 

> >>> In 3GPP use case:

> >>> 1) the particular media feature tag indicates that the UA ensures

> >>> NOT creating the subscription inside the dialog for received REFERs

> >>> with norefersub

> >>> 2) UA-A sending INVITE request includes the particular media feature tag

> in INVITE request and thus indicates support of the feature in the bullet 1.

> >>> 3) when UA-B receives an INVITE request:

> >>>    - if the INVITE request contains the particular media feature tag - i.e.

> UA-A sending the INVITE request supports feature in bullet 1, the UA-B can

> safely send in-dialog REFER with norefersub. UA-A will ensure that the

> subscription inside the dialog is not created due to bullet 1.

> >>>    - if the INVITE request does not contain the particular media feature

> tag, the UA-B does not send in-dialog REFER to UA-A.

> >>>

> >> So, you're saying you will _NEVER_ send an in-dialog REFER to a UA that

> doesn't provide that media feature tag, correct?

> > Correct.

> 

> And for completeness, you will always reject any REFER sent from such a UA?

 

The flow in 3GPP TS 24.237 (where the procedure above is defined and used) is as follows (only tags important for this discussion are listed):

 

 Alice                                                                  Bob

   |-------- 1. INVITE (media feature tag X)---------------------------->|

    |<------- 2. 200 for INVITE ------------------------------------------|

    |-------- 3. ACK----------------------------------------------------->|

    |                                          4. *ONLY* if media feature tag X is present in the INVITE,

    |                                                          step 5 is performed

    |<------- 5. in-dialog REFER (norefersub, Refer-Sub: false)-----------|

6. *ONLY* if norefersub and Refer-Sub: false                              |

are included in the in-dialog REFER, steps 7 and 8 are performed          |

    |-------- 7. 200 for in-dialog REFER ---------------------------------|

8. don't create implicit subscription                                     |

    |                                                                     |

 

 

3GPP TS 24.237:

- does not give any statements how Alice is to handle a received in-dialog REFER without norefersub and without Refer-Sub: false. If norefersub is missing or if Refer-Sub: false is missing in the received in-dialog REFER, then RFC3515 and RFC6665 rules apply.

Then my currently proposed text is inaccurate, and we're back to
"Such implementations revert to creating a subscription inside the dialog when interoperating with standard implementations outside those environments."


- does not give any statements how Bob is to handle a received in-dialog REFER. RFC3515 and RFC6665 rules apply for the received in-dialog REFER.

 

Does this clarify the question?

 

Kind regards

 

Ivo Sedlacek

 


--------------050805060407030404020503-- From nobody Tue Jan 13 07:02:17 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0211A1EF4 for ; Tue, 13 Jan 2015 07:02:16 -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 kwvXFVeaQSmj for ; Tue, 13 Jan 2015 07:02:13 -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 9CF971A1EEF for ; Tue, 13 Jan 2015 07:02:13 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t0DF1mcn016126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Jan 2015 09:01:54 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54B53355.2020307@nostrum.com> Date: Tue, 13 Jan 2015 09:01:41 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ivo Sedlacek , Christer Holmberg , "sipcore@ietf.org" References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127A5FFC@ESESSMB301.ericsson.se> <547CB095.6060306@alum.mit.edu> <547CD80E.7000808@nostrum.com> <059F3547244B7F4DB728757635C2DC4B15DB21A7@DEMUMBX003.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1D578385@ESESSMB209.ericsson.se> <059F3547244B7F4DB728757635C2DC4B15DB3190@DEMUMBX003.nsn-intra.net> <39B5E4D390E9BD4890E2B31079006101127B7ECC@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> <54B00C45.3080500@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DB332@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127DB332@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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: Tue, 13 Jan 2015 15:02:16 -0000 On 1/13/15 2:09 AM, Ivo Sedlacek wrote: > Hello, > >> Add this as the 3rd paragraph of the introduction: >> >> Note that there are implementations in some known specialized >> environments (such as 3gpp) that use out-of-signalling agreements to >> ensure that in-dialog REFER requests using the RFC4488 extension do >> not create a new subscription inside that dialog. In the 3gpp >> environment, the behavior is based on capabilities advertised using >> media feature tags. Such implementations will never send or accept any >> REFER from a peer that hasn't provided those media feature tags. The >> extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative. > IMO, it would be more appropriate to state: > --------------- > Note that there are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media feature tags. >>In the 3gpp environment, <>by definition<<< will never send >>an in-dialog<< REFER request >>to<< a peer that hasn't provided those media feature tags >>and never accept in-dialog REFER request without norefersub and without Refer-Sub: false<<. That "never accept" doesn't say the same thing as your other message where you said they followed 3515 or 6665. > The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative. > --------------- > >> And leave the text in section 4 as is. > OK. > > Kind regards > > Ivo Sedlacek > From nobody Tue Jan 13 07:13:19 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A780F1A8AAC for ; Tue, 13 Jan 2015 07:13:17 -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 cqF37autwKT6 for ; Tue, 13 Jan 2015 07:13:16 -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 361881A8AA6 for ; Tue, 13 Jan 2015 07:13:16 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t0DFDCu6040015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Jan 2015 09:13:12 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54B53603.1070200@nostrum.com> Date: Tue, 13 Jan 2015 09:13:07 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ivo Sedlacek , Christer Holmberg , "sipcore@ietf.org" References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127A5FFC@ESESSMB301.ericsson.se> <547CB095.6060306@alum.mit.edu> <547CD80E.7000808@nostrum.com> <059F3547244B7F4DB728757635C2DC4B15DB21A7@DEMUMBX003.nsn-intra.net> <7594FB04B1934943A5C02806D1A2204B1D578385@ESESSMB209.ericsson.se> <059F3547244B7F4DB728757635C2DC4B15DB3190@DEMUMBX003.nsn-intra.net> <39B5E4D390E9BD4890E2B31079006101127B7ECC@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> <54B00C45.3080500@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DB332@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127DB332@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: 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: Tue, 13 Jan 2015 15:13:17 -0000 On 1/13/15 2:09 AM, Ivo Sedlacek wrote: > Hello, > >> Add this as the 3rd paragraph of the introduction: >> >> Note that there are implementations in some known specialized >> environments (such as 3gpp) that use out-of-signalling agreements to >> ensure that in-dialog REFER requests using the RFC4488 extension do >> not create a new subscription inside that dialog. In the 3gpp >> environment, the behavior is based on capabilities advertised using >> media feature tags. Such implementations will never send or accept any >> REFER from a peer that hasn't provided those media feature tags. The >> extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative. > IMO, it would be more appropriate to state: > --------------- > Note that there are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media feature tags. > >>In the 3gpp environment, The problem the original text is trying to point out is what happens when one of the implementations is _not_ from the 3gpp environment. > <>by definition<<< will never send >>an in-dialog<< REFER request >>to<< a peer that hasn't provided those media feature tags >>and never accept in-dialog REFER request without norefersub and without Refer-Sub: false<<. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative. > --------------- > >> And leave the text in section 4 as is. > OK. > > Kind regards > > Ivo Sedlacek > From nobody Tue Jan 13 07:17:52 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9481A1EF2 for ; Tue, 13 Jan 2015 07:17: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 gNij-_HZOK2i for ; Tue, 13 Jan 2015 07:17:46 -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 993291A8AA9 for ; Tue, 13 Jan 2015 07:17:45 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-08-54b537172f64 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 61.90.24955.71735B45; Tue, 13 Jan 2015 16:17:43 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.90]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0195.001; Tue, 13 Jan 2015 16:17:43 +0100 From: Ivo Sedlacek To: Robert Sparks , Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQL0GUDaxcxV97kEmRpWzibXpAGJy+Jybw Date: Tue, 13 Jan 2015 15:17:42 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127DBF82@ESESSMB301.ericsson.se> References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D578385@ESESSMB209.ericsson.se> <059F3547244B7F4DB728757635C2DC4B15DB3190@DEMUMBX003.nsn-intra.net> <39B5E4D390E9BD4890E2B31079006101127B7ECC@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> <54ABE6A3.5000300@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7FFC@ESESSMB301.ericsson.se> <54AFF86A.9070605@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DB15E@ESESSMB301.ericsson.se> <54B532D9.8010305@nostrum.com> In-Reply-To: <54B532D9.8010305@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.17] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101127DBF82ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvja64+dYQg+sTDCyuzWlks/j6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJXxcuExxoJNBhX/t3xkbmDcpNXFyMkhIWAi cXTWcXYIW0ziwr31bF2MXBxCAkcYJebua2KHcBYzSrxc8JMNpIpNQE9i4pYjrCAJEYFWRonX f8+zgiSEBYIlXm/uZAGxRQRCJGau38EIYRtJbJu3mAnEZhFQlbi5+DxYnFfAV+Lz8w8sEBte s0t0H5kEdgengLbEvclbwbYxCshKXP3TC9bALCAucevJfCaIWwUkluw5zwxhi0q8fPwP6AgO IFtRYnm/HER5vsS7j+1QuwQlTs58wjKBUWQWkkmzkJTNQlIGEdeRWLD7ExuErS2xbOFrZhj7 zIHHTMjiCxjZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIExtbBLb9VdzBefuN4iFGAg1GJ h9ega0uIEGtiWXFl7iFGaQ4WJXHePIcNIUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYq1PP BrVv3aBw0Ep7r4bXhFrVmtgsTUeuj38czGK6RVLyp/a51P1/pp6/9KUEh6vVrAke/2a4zJTs /itwz8+rVeHEO8eaN0E//wqa38n/knfreoONuHthqZnJ9UXb99hKs9YoMG/6+IQ78WC4hYRM iFV5emD/6t3FrM8kTU52zWVyFnloyqvEUpyRaKjFXFScCAANLoPzjgIAAA== Archived-At: 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: Tue, 13 Jan 2015 15:17:49 -0000 --_000_39B5E4D390E9BD4890E2B31079006101127DBF82ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Robert, 3GPP TS 24.237: - does not give any statements how Alice is to handle a received in-dialog = REFER without norefersub and without Refer-Sub: false. If norefersub is mis= sing or if Refer-Sub: false is missing in the received in-dialog REFER, the= n RFC3515 and RFC6665 rules apply. Then my currently proposed text is inaccurate, and we're back to "Such implementations revert to creating a subscription inside the dialog w= hen interoperating with standard implementations outside those environments= ." You asked how the 3GPP solution acts when a REFER request *NOT* described b= y 3GPP solution is received by 3GPP entity. My answer was that in such case the UA acts as in RFC3515 and RFC6665. You claim that such implementation reverts to creating a subscription insid= e the dialog when interoperating with standard implementations outside thos= e environments. If that's correct, then *EACH* UA implementation of RFC3515 and RFC6665,*NO= T* limited to those described in the 3GPP solution, reverts to creating a s= ubscription inside the dialog when interoperating with standard implementat= ions. Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B31079006101127DBF82ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Robert,

 

3GPP TS 24.237:

- does not give any statements how Alice is to ha= ndle a received in-dialog REFER without norefersub and without Refer-Sub: f= alse. If norefersub is missing or if Refer-Sub: false is missing in the rec= eived in-dialog REFER, then RFC3515 and RFC6665 rules apply.

Then my currently proposed text is i= naccurate, and we're back to
"Such implementations revert to creating a subscription inside the dia= log when interoperating with standard implementations outside those environ= ments."


You asked how the 3GPP= solution acts when a REFER request *NOT* described by 3GPP solution is rec= eived by 3GPP entity.

 

My answer was that in = such case the UA acts as in RFC3515 and RFC6665.

 

You claim that such im= plementation reverts to creating a subscription inside the dialog when inte= roperating with standard implementations outside those environments.

 

If that's correct, the= n *EACH* UA implementation of RFC3515 and RFC6665,*NOT* limited to those de= scribed in the 3GPP solution, reverts to creating a subscription inside the= dialog when interoperating with standard implementations.

 

Kind regards

 

Ivo Sedlacek

--_000_39B5E4D390E9BD4890E2B31079006101127DBF82ESESSMB301erics_-- From nobody Tue Jan 13 07:28:15 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F382C1A1EF2 for ; Tue, 13 Jan 2015 07:28:12 -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 3PHhP66baefX for ; Tue, 13 Jan 2015 07:28: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 08F291A1EF4 for ; Tue, 13 Jan 2015 07:28:08 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t0DFS20S041332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Jan 2015 09:28:03 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54B5397E.7010404@nostrum.com> Date: Tue, 13 Jan 2015 09:27:58 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ivo Sedlacek , Christer Holmberg , "sipcore@ietf.org" References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D578385@ESESSMB209.ericsson.se> <059F3547244B7F4DB728757635C2DC4B15DB3190@DEMUMBX003.nsn-intra.net> <39B5E4D390E9BD4890E2B31079006101127B7ECC@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> <54ABE6A3.5000300@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7FFC@ESESSMB301.ericsson.se> <54AFF86A.9070605@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DB15E@ESESSMB301.ericsson.se> <54B532D9.8010305@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DBF82@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127DBF82@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------010201050006030608010609" Archived-At: 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: Tue, 13 Jan 2015 15:28:13 -0000 This is a multi-part message in MIME format. --------------010201050006030608010609 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 1/13/15 9:17 AM, Ivo Sedlacek wrote: > > Hello Robert, > > 3GPP TS 24.237: > > - does not give any statements how Alice is to handle a received > in-dialog REFER without norefersub and without Refer-Sub: false. > If norefersub is missing or if Refer-Sub: false is missing in the > received in-dialog REFER, then RFC3515 and RFC6665 rules apply. > > Then my currently proposed text is inaccurate, and we're back to > "Such implementations revert to creating a subscription inside the > dialog when interoperating with standard implementations outside those > environments." > > > You asked how the 3GPP solution acts when a REFER request *NOT* > described by 3GPP solution is received by 3GPP entity. > > My answer was that in such case the UA acts as in RFC3515 and RFC6665. > > You claim that such implementation reverts to creating a subscription > inside the dialog when interoperating with standard implementations > outside those environments. > > If that's correct, then *EACH* UA implementation of RFC3515 and > RFC6665,*NOT* limited to those described in the 3GPP solution, reverts > to creating a subscription inside the dialog when interoperating with > standard implementations. > you should be saying _or_ to account for the fielded implementations of 3515 that don't know 6665. And that's exactly my point - without standardized extension, those implementions risk dialog use , so the 6665 restrictions come into play. With the extensions in refer-explicit-subscription, an implementation can return a 421/Require to REFER requests that don't use the extension and would create dialog reuse. > > Kind regards > > Ivo Sedlacek > --------------010201050006030608010609 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 1/13/15 9:17 AM, Ivo Sedlacek wrote:

Hello Robert,

 

3GPP TS 24.237:

- does not give any statements how Alice is to handle a received in-dialog REFER without norefersub and without Refer-Sub: false. If norefersub is missing or if Refer-Sub: false is missing in the received in-dialog REFER, then RFC3515 and RFC6665 rules apply.

Then my currently proposed text is inaccurate, and we're back to
"Such implementations revert to creating a subscription inside the dialog when interoperating with standard implementations outside those environments."


You asked how the 3GPP solution acts when a REFER request *NOT* described by 3GPP solution is received by 3GPP entity.

 

My answer was that in such case the UA acts as in RFC3515 and RFC6665.

 

You claim that such implementation reverts to creating a subscription inside the dialog when interoperating with standard implementations outside those environments.

 

If that's correct, then *EACH* UA implementation of RFC3515 and RFC6665,*NOT* limited to those described in the 3GPP solution, reverts to creating a subscription inside the dialog when interoperating with standard implementations.

you should be saying _or_ to account for the fielded implementations of 3515 that don't know 6665.

And that's exactly my point - without standardized extension, those implementions risk dialog use , so the 6665 restrictions come into play.

With the extensions in refer-explicit-subscription, an implementation can return a 421/Require to REFER requests that don't use the extension and would create dialog reuse.

 

Kind regards

 

Ivo Sedlacek


--------------010201050006030608010609-- From nobody Wed Jan 14 01:16:54 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD841A6F96 for ; Wed, 14 Jan 2015 01:16:51 -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 RghbRjTUPJCK for ; Wed, 14 Jan 2015 01:16:41 -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 AC9BF1A8ADF for ; Wed, 14 Jan 2015 01:16:40 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-7c-54b633f6297c Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id DB.4E.04231.6F336B45; Wed, 14 Jan 2015 10:16:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0195.001; Wed, 14 Jan 2015 10:16:37 +0100 From: Christer Holmberg To: Robert Sparks , Ivo Sedlacek , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQBeGiFbV1ztW9cUOimw2I9kop/5x1Mf8AgABuBICAAINygIAE5fuAgAAvDgCAANc/AIACMF4AgAEKyRCAAV2XgIAAI1YAgADoEgCAEizAQIABwFeAgAAZMiCAAFIZAIAA+ddQgBrYPYCAATlfgIAAOWuAgAAYT4CABMGWAIAFtUEAgACGSYCAAAUNAIAAAt4AgAEoIJA= Date: Wed, 14 Jan 2015 09:16:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D637D10@ESESSMB209.ericsson.se> References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D578385@ESESSMB209.ericsson.se> <059F3547244B7F4DB728757635C2DC4B15DB3190@DEMUMBX003.nsn-intra.net> <39B5E4D390E9BD4890E2B31079006101127B7ECC@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> <54ABE6A3.5000300@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7FFC@ESESSMB301.ericsson.se> <54AFF86A.9070605@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DB15E@ESESSMB301.ericsson.se> <54B532D9.8010305@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DBF82@ESESSMB301.ericsson.se> <54B5397E.7010404@nostrum.com> In-Reply-To: <54B5397E.7010404@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D637D10ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvje43420hBu+aDC2uzWlks/j6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJWxduEh1oK34RU7nn5laWC84tPFyMkhIWAi 0X7rAzOELSZx4d56ti5GLg4hgSOMEp1HTzFCOEsYJY5OmgNUxcHBJmAh0f1PG6RBRKBaYte8 p0wgtrBAsMTrzZ0sEPEQiZnrd4D1igjcYpTo3nuEHSTBIqAq0bJ6AiOIzSvgK3H68XGoBRM5 JB6euckGkuAU0JZo+/8TzGYEOun7qTVgG5gFxCVuPZnPBHGqgMSSPeehzhaVePn4HyuErSjx 8dU+Roj6fIkLUxZDLROUODnzCcsERpFZSEbNQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwce MyGLL2BkX8UoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGFsHt/zW3cG4+rXjIUYBDkYlHt4N t7eGCLEmlhVX5h5ilOZgURLnzXPYECIkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB0f9tmue/ 095202Xuml6Z5hhxfIPLmm97DR+tiH7wwKVm3vrFW7wMZgXo9b+IevHe2Znv7JY/5gW6c7PF xLgOPLqT01VwfsJu0+U/ND9FFoWeuLuDnf3lz4OPP0XETtdt6d70xJqZ+/zDuwIysk38nwoD Ot8+4Iw6pn/nQkdowpUZ+1K33dz0QEOJpTgj0VCLuag4EQChMkWLjgIAAA== Archived-At: 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: Wed, 14 Jan 2015 09:16:52 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D637D10ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am a little lost... If 3GPP-Bob receives a INVITE request WITHOUT the media feature tag, 3GPP-B= ob will not send in-dialog REFERs. If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER fro= m an entity that does not support any mechanism (standardized or 3GPP-speci= fic), there obviously is risk of a dialog reuse. But, that is according to = the backward compatibility rules in RFC6665, and ANY entity has to be able = to deal with that somehow. Regards, Christer From: Robert Sparks [mailto:rjsparks@nostrum.com] Sent: 13. tammikuuta 2015 17:28 To: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt On 1/13/15 9:17 AM, Ivo Sedlacek wrote: Hello Robert, 3GPP TS 24.237: - does not give any statements how Alice is to handle a received in-dialog = REFER without norefersub and without Refer-Sub: false. If norefersub is mis= sing or if Refer-Sub: false is missing in the received in-dialog REFER, the= n RFC3515 and RFC6665 rules apply. Then my currently proposed text is inaccurate, and we're back to "Such implementations revert to creating a subscription inside the dialog w= hen interoperating with standard implementations outside those environments= ." You asked how the 3GPP solution acts when a REFER request *NOT* described b= y 3GPP solution is received by 3GPP entity. My answer was that in such case the UA acts as in RFC3515 and RFC6665. You claim that such implementation reverts to creating a subscription insid= e the dialog when interoperating with standard implementations outside thos= e environments. If that's correct, then *EACH* UA implementation of RFC3515 and RFC6665,*NO= T* limited to those described in the 3GPP solution, reverts to creating a s= ubscription inside the dialog when interoperating with standard implementat= ions. you should be saying _or_ to account for the fielded implementations of 351= 5 that don't know 6665. And that's exactly my point - without standardized extension, those impleme= ntions risk dialog use , so the 6665 restrictions come into play. With the extensions in refer-explicit-subscription, an implementation can r= eturn a 421/Require to REFER requests that don't use the extension and woul= d create dialog reuse. Kind regards Ivo Sedlacek --_000_7594FB04B1934943A5C02806D1A2204B1D637D10ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

I am a little lostR= 30;

 

If 3GPP-Bob receives a= INVITE request WITHOUT the media feature tag, 3GPP-Bob will not send in-di= alog REFERs.

 

If ANY entity (3GPP-Al= ice or Internet-Alice) receive an in-dialog REFER from an entity that does = not support any mechanism (standardized or 3GPP-specific), there obviously = is risk of a dialog reuse. But, that is according to the backward compatibility rules in RFC6665, and ANY entit= y has to be able to deal with that somehow.

 

Regards,

 

Christer

 

 

 

 

 

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 13. tammikuuta 2015 17:28
To: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarific= ations-00.txt

 

 

On 1/13/15 9:17 AM, Ivo Sedlacek wrote:

Hello Robert,

 

3GPP TS 24.237:

- does not give any statements how Alice is to ha= ndle a received in-dialog REFER without norefersub and without Refer-Sub: f= alse. If norefersub is missing or if Refer-Sub: false is missing in the rec= eived in-dialog REFER, then RFC3515 and RFC6665 rules apply.

Then my currently proposed t= ext is inaccurate, and we're back to
"Such implementations revert to creating a subscription inside the dia= log when interoperating with standard implementations outside those environ= ments."



You asked how the 3GPP= solution acts when a REFER request *NOT* described by 3GPP solution is rec= eived by 3GPP entity.

 

My answer was that in = such case the UA acts as in RFC3515 and RFC6665.

 

You claim that such im= plementation reverts to creating a subscription inside the dialog when inte= roperating with standard implementations outside those environments.=

 

If that's correct, the= n *EACH* UA implementation of RFC3515 and RFC6665,*NOT* limited to those de= scribed in the 3GPP solution, reverts to creating a subscription inside the= dialog when interoperating with standard implementations.

you should be saying _or_ to account= for the fielded implementations of 3515 that don't know 6665.

And that's exactly my point - without standardized extension, those impleme= ntions risk dialog use , so the 6665 restrictions come into play.

With the extensions in refer-explicit-subscription, an implementation can r= eturn a 421/Require to REFER requests that don't use the extension and woul= d create dialog reuse.

 

Kind regards

 

Ivo Sedlacek

 

--_000_7594FB04B1934943A5C02806D1A2204B1D637D10ESESSMB209erics_-- From nobody Wed Jan 14 06:01:31 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C540F1B2CA6 for ; Wed, 14 Jan 2015 06:01:29 -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 dyYKbygkIlvM for ; Wed, 14 Jan 2015 06:01: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 E663A1B2CA2 for ; Wed, 14 Jan 2015 06:01:26 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t0EE1M20082780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Jan 2015 08:01:23 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54B676AD.7030509@nostrum.com> Date: Wed, 14 Jan 2015 08:01:17 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Christer Holmberg , Ivo Sedlacek , "sipcore@ietf.org" References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127B7ECC@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> <54ABE6A3.5000300@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7FFC@ESESSMB301.ericsson.se> <54AFF86A.9070605@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DB15E@ESESSMB301.ericsson.se> <54B532D9.8010305@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DBF82@ESESSMB301.ericsson.se> <54B5397E.7010404@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D637D10@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D637D10@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------060702000005050007040409" Archived-At: 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: Wed, 14 Jan 2015 14:01:30 -0000 This is a multi-part message in MIME format. --------------060702000005050007040409 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 1/14/15 3:16 AM, Christer Holmberg wrote: > > Hi, > > I am a little lost… > > If 3GPP-Bob receives a INVITE request WITHOUT the media feature tag, > 3GPP-Bob will not send in-dialog REFERs. > Thanks for reconfirming that. > > If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog > REFER from an entity that does not support any mechanism (standardized > or 3GPP-specific), there obviously is risk of a dialog reuse. But, > that is according to the backward compatibility rules in RFC6665, and > ANY entity has to be able to deal with that somehow. > Which, when the peer is an unextended UA, is to fall back and use 3515, hence fall back to dialog reuse. Let me take yet another stab at the paragraph for the introduction, given this set of exchanges. Please read it in the context of the introduction, not just in isolation: Note that there are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media feature tags. Such implementations revert to RFC 3515 (as described in section 4.5.2 of RFC6665), creating a subscription inside the dialog when interoperating with standard implementations outside those environments. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative that allows avoiding any additional dialog usage. > Regards, > > Christer > > *From:*Robert Sparks [mailto:rjsparks@nostrum.com] > *Sent:* 13. tammikuuta 2015 17:28 > *To:* Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org > *Subject:* Re: [sipcore] I-D Action: > draft-ietf-sipcore-refer-clarifications-00.txt > > On 1/13/15 9:17 AM, Ivo Sedlacek wrote: > > Hello Robert, > > 3GPP TS 24.237: > > - does not give any statements how Alice is to handle a > received in-dialog REFER without norefersub and without > Refer-Sub: false. If norefersub is missing or if Refer-Sub: > false is missing in the received in-dialog REFER, then RFC3515 > and RFC6665 rules apply. > > Then my currently proposed text is inaccurate, and we're back to > "Such implementations revert to creating a subscription inside the > dialog when interoperating with standard implementations outside > those environments." > > > > You asked how the 3GPP solution acts when a REFER request *NOT* > described by 3GPP solution is received by 3GPP entity. > > My answer was that in such case the UA acts as in RFC3515 and RFC6665. > > You claim that such implementation reverts to creating a > subscription inside the dialog when interoperating with standard > implementations outside those environments. > > If that's correct, then *EACH* UA implementation of RFC3515 and > RFC6665,*NOT* limited to those described in the 3GPP solution, > reverts to creating a subscription inside the dialog when > interoperating with standard implementations. > > you should be saying _or_ to account for the fielded implementations > of 3515 that don't know 6665. > > And that's exactly my point - without standardized extension, those > implementions risk dialog use , so the 6665 restrictions come into play. > > With the extensions in refer-explicit-subscription, an implementation > can return a 421/Require to REFER requests that don't use the > extension and would create dialog reuse. > > Kind regards > > Ivo Sedlacek > --------------060702000005050007040409 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 1/14/15 3:16 AM, Christer Holmberg wrote:

Hi,

 

I am a little lost…

 

If 3GPP-Bob receives a INVITE request WITHOUT the media feature tag, 3GPP-Bob will not send in-dialog REFERs.

Thanks for reconfirming that.

 

If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER from an entity that does not support any mechanism (standardized or 3GPP-specific), there obviously is risk of a dialog reuse. But, that is according to the backward compatibility rules in RFC6665, and ANY entity has to be able to deal with that somehow.

Which, when the peer is an unextended UA, is to fall back and use 3515, hence fall back to dialog reuse.

Let me take yet another stab at the paragraph for the introduction, given this set of exchanges. Please read it in the context of the introduction, not just in isolation:

Note that there are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media feature tags. Such implementations revert to RFC 3515 (as described in section 4.5.2 of RFC6665), creating a subscription inside the dialog when interoperating with standard implementations outside those environments. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative that allows avoiding any additional dialog usage.


 

Regards,

 

Christer

 

 

 

 

 

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 13. tammikuuta 2015 17:28
To: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

 

 

On 1/13/15 9:17 AM, Ivo Sedlacek wrote:

Hello Robert,

 

3GPP TS 24.237:

- does not give any statements how Alice is to handle a received in-dialog REFER without norefersub and without Refer-Sub: false. If norefersub is missing or if Refer-Sub: false is missing in the received in-dialog REFER, then RFC3515 and RFC6665 rules apply.

Then my currently proposed text is inaccurate, and we're back to
"Such implementations revert to creating a subscription inside the dialog when interoperating with standard implementations outside those environments."



You asked how the 3GPP solution acts when a REFER request *NOT* described by 3GPP solution is received by 3GPP entity.

 

My answer was that in such case the UA acts as in RFC3515 and RFC6665.

 

You claim that such implementation reverts to creating a subscription inside the dialog when interoperating with standard implementations outside those environments.

 

If that's correct, then *EACH* UA implementation of RFC3515 and RFC6665,*NOT* limited to those described in the 3GPP solution, reverts to creating a subscription inside the dialog when interoperating with standard implementations.

you should be saying _or_ to account for the fielded implementations of 3515 that don't know 6665.

And that's exactly my point - without standardized extension, those implementions risk dialog use , so the 6665 restrictions come into play.

With the extensions in refer-explicit-subscription, an implementation can return a 421/Require to REFER requests that don't use the extension and would create dialog reuse.

 

Kind regards

 

Ivo Sedlacek

 


--------------060702000005050007040409-- From nobody Wed Jan 14 06:48:13 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06031B2CD3 for ; Wed, 14 Jan 2015 06:48: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 wXYHx7tKsWBN for ; Wed, 14 Jan 2015 06:48:02 -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 81C301B2CCE for ; Wed, 14 Jan 2015 06:48:01 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-9d-54b6819fdcda Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 89.4E.04076.F9186B45; Wed, 14 Jan 2015 15:47:59 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0195.001; Wed, 14 Jan 2015 15:47:58 +0100 From: Christer Holmberg To: Robert Sparks , Ivo Sedlacek , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQBeGiFbV1ztW9cUOimw2I9kop/5x1Mf8AgABuBICAAINygIAE5fuAgAAvDgCAANc/AIACMF4AgAEKyRCAAV2XgIAAI1YAgADoEgCAEizAQIABwFeAgAAZMiCAAFIZAIAA+ddQgBrYPYCAATlfgIAAOWuAgAAYT4CABMGWAIAFtUEAgACGSYCAAAUNAIAAAt4AgAEoIJCAAFH9gIAAGHEQ Date: Wed, 14 Jan 2015 14:47:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D638580@ESESSMB209.ericsson.se> References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127B7ECC@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> <54ABE6A3.5000300@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7FFC@ESESSMB301.ericsson.se> <54AFF86A.9070605@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DB15E@ESESSMB301.ericsson.se> <54B532D9.8010305@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DBF82@ESESSMB301.ericsson.se> <54B5397E.7010404@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D637D10@ESESSMB209.ericsson.se> <54B676AD.7030509@nostrum.com> In-Reply-To: <54B676AD.7030509@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_7594FB04B1934943A5C02806D1A2204B1D638580ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvje78xm0hBjenK1lcm9PIZvH1xyY2 ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugStjwpwDTAWflzBWrGhqZW9g/N7P2MXIySEh YCLxaeoVKFtM4sK99WwgtpDAEUaJb4/tuxi5gOwljBIP7k5n6WLk4GATsJDo/qcNUiMiUC2x a95TJhBbWCBY4vXmThaIeIjEzPU7GEF6RQSeMUpcX/6ZHSTBIqAq0bNpJTOIzSvgK7H31HEm iGVv2CV65nGA2JwC2hIdfzeCHcEIdND3U2vAapgFxCVuPZnPBHGogMSSPeeZIWxRiZeP/7FC 2IoS7U8bGCHq8yUmPp0BtUtQ4uTMJywTGEVmIRk1C0nZLCRlEHEdiQW7P7FB2NoSyxa+Zoax zxx4zIQsvoCRfRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYGwd3PLbagfjweeOhxgFOBiV eHg33N4aIsSaWFZcmXuIUZqDRUmcN89hQ4iQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxgkh bvc2/nr89j7vhAez7Jsfdv38EZx2eMmUqrvdZo9TnjNf6Hz/+T1n1bY4Tt1jLmZakm9bl562 jviUNKnD/0Hhw+8fJ1x+0eg1a+/01EuOOx7uFiiSfS/Iy97ZLzGhpfX3udOznnididyW/OtF mVjOrkLlbz+2SQgXtvtJPRfqLV1oLH5FL1aJpTgj0VCLuag4EQA1mWirjgIAAA== Archived-At: 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: Wed, 14 Jan 2015 14:48:11 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D638580ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Robert, >If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER fr= om an entity that does not support any mechanism (standardized or 3GPP-spec= ific), there >obviously is risk of a dialog reuse. But, that is according to the backwar= d compatibility rules in RFC6665, and ANY entity has to be able to deal wit= h that somehow. > >Which, when the peer is an unextended UA, is to fall back and use 3515, he= nce fall back to dialog reuse. Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the peer in = an unextended UA. Your suggested "Such implementations" wording make it sound like only 3GPP = entities will revert :) What about? "There are implementations in some known specialized environments (such as = 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not cre= ate a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media f= eature tags. SIP implementations will revert to RFC 3515 (as described in section 4.5.2= of RFC6665), creating a subscription inside the dialog, when interoperating with implementations that do not sup= port a mechanism for avoiding additional dialog usage. The extensions in [I-D.ietf-sipcore-refer-explicit= -subscription] provide a standardized mechanism that allows avoiding any additional dialog usage." Or, perhaps we should FIRST say what happens when the remote peer is unexte= nded. "SIP implementations will revert to RFC 3515 (as described in section 4.5.= 2 of RFC6665), creating a subscription inside the dialog, when interoperating with implementations that do not sup= port a mechanism for avoiding additional dialog usage. There are implementations in some known specialized environments (such as 3= gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not cre= ate a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media f= eature tags. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a = standardized mechanism that allows avoiding any additional dialog usage." Regards, Christer Let me take yet another stab at the paragraph for the introduction, given t= his set of exchanges. Please read it in the context of the introduction, no= t just in isolation: Note that there are implementations in some known specialized environments = (such as 3gpp) that use out-of-signalling agreements to ensure that in-dial= og REFER requests using the RFC4488 extension do not create a new subscript= ion inside that dialog. In the 3gpp environment, the behavior is based on c= apabilities advertised using media feature tags. Such implementations rever= t to RFC 3515 (as described in section 4.5.2 of RFC6665), creating a subscr= iption inside the dialog when interoperating with standard implementations = outside those environments. The extensions in [I-D.ietf-sipcore-refer-expli= cit-subscription] provide a standardized alternative that allows avoiding a= ny additional dialog usage. Regards, Christer From: Robert Sparks [mailto:rjsparks@nostrum.com] Sent: 13. tammikuuta 2015 17:28 To: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt On 1/13/15 9:17 AM, Ivo Sedlacek wrote: Hello Robert, 3GPP TS 24.237: - does not give any statements how Alice is to handle a received in-dialog = REFER without norefersub and without Refer-Sub: false. If norefersub is mis= sing or if Refer-Sub: false is missing in the received in-dialog REFER, the= n RFC3515 and RFC6665 rules apply. Then my currently proposed text is inaccurate, and we're back to "Such implementations revert to creating a subscription inside the dialog w= hen interoperating with standard implementations outside those environments= ." You asked how the 3GPP solution acts when a REFER request *NOT* described b= y 3GPP solution is received by 3GPP entity. My answer was that in such case the UA acts as in RFC3515 and RFC6665. You claim that such implementation reverts to creating a subscription insid= e the dialog when interoperating with standard implementations outside thos= e environments. If that's correct, then *EACH* UA implementation of RFC3515 and RFC6665,*NO= T* limited to those described in the 3GPP solution, reverts to creating a s= ubscription inside the dialog when interoperating with standard implementat= ions. you should be saying _or_ to account for the fielded implementations of 351= 5 that don't know 6665. And that's exactly my point - without standardized extension, those impleme= ntions risk dialog use , so the 6665 restrictions come into play. With the extensions in refer-explicit-subscription, an implementation can r= eturn a 421/Require to REFER requests that don't use the extension and woul= d create dialog reuse. Kind regards Ivo Sedlacek --_000_7594FB04B1934943A5C02806D1A2204B1D638580ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Robert,<= /span>

 

>If ANY entity (3GPP-Alice or Internet-Alice) receive an = in-dialog REFER from an entity that does not support any mechanism (standar= dized or 3GPP-specific), there

>obviously is risk of a dialog reuse. But, that is accord= ing to the backward compatibility rules in RFC6665, and ANY entity has to b= e able to deal with that somehow.=

> <= /span>

>Which, when the peer is an unextended UA, is to fall back and use 3515= , hence fall back to dialog reuse.=

 

Correct. But, it appli= es to ANY entity (3GPP or non-3GPP) when the peer in an unextended UA.=

 

Your suggested “= Such implementations” wording make it sound like only 3GPP entities w= ill revert :)

 

What about?=

 

“There are imple= mentations in some known specialized environments (such as 3gpp) that use o= ut-of-signalling agreements to

ensure that in-dialog = REFER requests using the RFC4488 extension do not create a new subscription= inside that dialog. In the 3gpp

environment, the behav= ior is based on capabilities advertised using media feature tags.

SIP implementations wi= ll revert to RFC 3515  (as described in section 4.5.2 of RFC6665), cre= ating a subscription

inside the dialog, whe= n interoperating with implementations that do not support a mechanism for a= voiding

additional dialog usag= e. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide= a standardized

mechanism that allows = avoiding any additional dialog usage.”

 

Or, perhaps we should = FIRST say what happens when the remote peer is unextended.

 

“SIP implementat= ions will revert to RFC 3515  (as described in section 4.5.2 of RFC666= 5), creating a subscription

inside the dialog, whe= n interoperating with implementations that do not support a mechanism for a= voiding

additional dialog usag= e.

 

There are implementati= ons in some known specialized environments (such as 3gpp) that use out-of-s= ignalling agreements to

ensure that in-dialog = REFER requests using the RFC4488 extension do not create a new subscription= inside that dialog. In the 3gpp

environment, the behav= ior is based on capabilities advertised using media feature tags.

 

The extensions in [I-D= .ietf-sipcore-refer-explicit-subscription] provide a standardized mechanism= that allows avoiding

any additional dialog = usage.”

 

 

Regards,

 

Christer

 





Let me take yet another stab at the paragraph for the introduction, given t= his set of exchanges. Please read it in the context of the introduction, no= t just in isolation:

Note that there are implementations in some known specialized environments = (such as 3gpp) that use out-of-signalling agreements to ensure that in-dial= og REFER requests using the RFC4488 extension do not create a new subscript= ion inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media = feature tags. Such implementations revert to RFC 3515 (as described in sect= ion 4.5.2 of RFC6665), creating a subscription inside the dialog when inter= operating with standard implementations outside those environments. The extensions in [I-D.ietf-sipcore-refer-expl= icit-subscription] provide a standardized alternative that allows avoiding = any additional dialog usage.



 

Regards,

 

Christer

 

 

 

 

 

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 13. tammikuuta 2015 17:28
To: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarific= ations-00.txt

 

 

On 1/13/15 9:17 AM, Ivo Sedlacek wrote:

Hello Robert,

 

3GPP TS 24.237:

- does not give any statements how Alice is to ha= ndle a received in-dialog REFER without norefersub and without Refer-Sub: f= alse. If norefersub is missing or if Refer-Sub: false is missing in the rec= eived in-dialog REFER, then RFC3515 and RFC6665 rules apply.

Then my currently proposed text is i= naccurate, and we're back to
"Such implementations revert to creating a subscription inside the dia= log when interoperating with standard implementations outside those environ= ments."




You asked how the 3GPP= solution acts when a REFER request *NOT* described by 3GPP solution is rec= eived by 3GPP entity.

 

My answer was that in = such case the UA acts as in RFC3515 and RFC6665.

 

You claim that such im= plementation reverts to creating a subscription inside the dialog when inte= roperating with standard implementations outside those environments.=

 

If that's correct, the= n *EACH* UA implementation of RFC3515 and RFC6665,*NOT* limited to those de= scribed in the 3GPP solution, reverts to creating a subscription inside the= dialog when interoperating with standard implementations.

you should be saying _or_ to= account for the fielded implementations of 3515 that don't know 6665.

And that's exactly my point - without standardized extension, those impleme= ntions risk dialog use , so the 6665 restrictions come into play.

With the extensions in refer-explicit-subscription, an implementation can r= eturn a 421/Require to REFER requests that don't use the extension and woul= d create dialog reuse.


 

Kind regards

 

Ivo Sedlacek

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D638580ESESSMB209erics_-- From nobody Wed Jan 14 07:03:55 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5F11A1B91 for ; Wed, 14 Jan 2015 07:03:53 -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 IVEKLIRZd_Ma for ; Wed, 14 Jan 2015 07:03:50 -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 CBAF41A1B42 for ; Wed, 14 Jan 2015 07:03:49 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t0EF3gfB088158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Jan 2015 09:03:42 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54B68549.4080408@nostrum.com> Date: Wed, 14 Jan 2015 09:03:37 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Christer Holmberg , Ivo Sedlacek , "sipcore@ietf.org" References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> <54ABE6A3.5000300@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7FFC@ESESSMB301.ericsson.se> <54AFF86A.9070605@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DB15E@ESESSMB301.ericsson.se> <54B532D9.8010305@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DBF82@ESESSMB301.ericsson.se> <54B5397E.7010404@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D637D10@ESESSMB209.ericsson.se> <54B676AD.7030509@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D638580@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D638580@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------050207040802020300080305" Archived-At: 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: Wed, 14 Jan 2015 15:03:53 -0000 This is a multi-part message in MIME format. --------------050207040802020300080305 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 1/14/15 8:47 AM, Christer Holmberg wrote: > > Hi Robert, > > >If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog > REFER from an entity that does not support any mechanism (standardized > or 3GPP-specific), there > > >obviously is risk of a dialog reuse. But, that is according to the > backward compatibility rules in RFC6665, and ANY entity has to be able > to deal with that somehow. > > > > > >Which, when the peer is an unextended UA, is to fall back and use > 3515, hence fall back to dialog reuse. > > Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the > peer in an unextended UA. > > Your suggested “Such implementations” wording make it sound like only > 3GPP entities will revert :) > It is exactly the 3gpp entities that this paragraph is about. I don't agree that pulling in the general case helps with the text. The point of the addition was to acknowledge that there was some non-standard behavior that elements might encounter and point to the edges of that behavior. Can we hold it to that scope? > What about? > > “There are implementations in some known specialized environments > (such as 3gpp) that use out-of-signalling agreements to > > ensure that in-dialog REFER requests using the RFC4488 extension do > not create a new subscription inside that dialog. In the 3gpp > > environment, the behavior is based on capabilities advertised using > media feature tags. > > SIP implementations will revert to RFC 3515 (as described in section > 4.5.2 of RFC6665), creating a subscription > > inside the dialog, when interoperating with implementations that do > not support a mechanism for avoiding > > additional dialog usage. The extensions in > [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized > > mechanism that allows avoiding any additional dialog usage.” > > Or, perhaps we should FIRST say what happens when the remote peer is > unextended. > > “SIP implementations will revert to RFC 3515 (as described in section > 4.5.2 of RFC6665), creating a subscription > > inside the dialog, when interoperating with implementations that do > not support a mechanism for avoiding > > additional dialog usage. > > There are implementations in some known specialized environments (such > as 3gpp) that use out-of-signalling agreements to > > ensure that in-dialog REFER requests using the RFC4488 extension do > not create a new subscription inside that dialog. In the 3gpp > > environment, the behavior is based on capabilities advertised using > media feature tags. > > The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] > provide a standardized mechanism that allows avoiding > > any additional dialog usage.” > > Regards, > > Christer > > > > > > Let me take yet another stab at the paragraph for the introduction, > given this set of exchanges. Please read it in the context of the > introduction, not just in isolation: > > Note that there are implementations in some known specialized > environments (such as 3gpp) that use out-of-signalling agreements to > ensure that in-dialog REFER requests using the RFC4488 extension do > not create a new subscription inside that dialog. In the 3gpp > environment, the behavior is based on capabilities advertised using > media feature tags. Such implementations revert to RFC 3515 (as > described in section 4.5.2 of RFC6665), creating a subscription inside > the dialog when interoperating with standard implementations outside > those environments. The extensions in > [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized > alternative that allows avoiding any additional dialog usage. > > > > Regards, > > Christer > > *From:*Robert Sparks [mailto:rjsparks@nostrum.com] > *Sent:* 13. tammikuuta 2015 17:28 > *To:* Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org > > *Subject:* Re: [sipcore] I-D Action: > draft-ietf-sipcore-refer-clarifications-00.txt > > On 1/13/15 9:17 AM, Ivo Sedlacek wrote: > > Hello Robert, > > 3GPP TS 24.237: > > - does not give any statements how Alice is to handle a > received in-dialog REFER without norefersub and without > Refer-Sub: false. If norefersub is missing or if Refer-Sub: > false is missing in the received in-dialog REFER, then RFC3515 > and RFC6665 rules apply. > > Then my currently proposed text is inaccurate, and we're back to > "Such implementations revert to creating a subscription inside the > dialog when interoperating with standard implementations outside > those environments." > > > > > You asked how the 3GPP solution acts when a REFER request *NOT* > described by 3GPP solution is received by 3GPP entity. > > My answer was that in such case the UA acts as in RFC3515 and RFC6665. > > You claim that such implementation reverts to creating a > subscription inside the dialog when interoperating with standard > implementations outside those environments. > > If that's correct, then *EACH* UA implementation of RFC3515 and > RFC6665,*NOT* limited to those described in the 3GPP solution, > reverts to creating a subscription inside the dialog when > interoperating with standard implementations. > > you should be saying _or_ to account for the fielded implementations > of 3515 that don't know 6665. > > And that's exactly my point - without standardized extension, those > implementions risk dialog use , so the 6665 restrictions come into play. > > With the extensions in refer-explicit-subscription, an implementation > can return a 421/Require to REFER requests that don't use the > extension and would create dialog reuse. > > > Kind regards > > Ivo Sedlacek > --------------050207040802020300080305 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 1/14/15 8:47 AM, Christer Holmberg wrote:

Hi Robert,

 

>If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER from an entity that does not support any mechanism (standardized or 3GPP-specific), there

>obviously is risk of a dialog reuse. But, that is according to the backward compatibility rules in RFC6665, and ANY entity has to be able to deal with that somehow.

> 

>Which, when the peer is an unextended UA, is to fall back and use 3515, hence fall back to dialog reuse.

 

Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the peer in an unextended UA.

 

Your suggested “Such implementations” wording make it sound like only 3GPP entities will revert :)

It is exactly the 3gpp entities that this paragraph is about.

I don't agree that pulling in the general case helps with the text.

The point of the addition was to acknowledge that there was some non-standard behavior that elements might encounter and point to the edges of that behavior. Can we hold it to that scope?

 

What about?

 

“There are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to

ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp

environment, the behavior is based on capabilities advertised using media feature tags.

SIP implementations will revert to RFC 3515  (as described in section 4.5.2 of RFC6665), creating a subscription

inside the dialog, when interoperating with implementations that do not support a mechanism for avoiding

additional dialog usage. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized

mechanism that allows avoiding any additional dialog usage.”

 

Or, perhaps we should FIRST say what happens when the remote peer is unextended.

 

“SIP implementations will revert to RFC 3515  (as described in section 4.5.2 of RFC6665), creating a subscription

inside the dialog, when interoperating with implementations that do not support a mechanism for avoiding

additional dialog usage.

 

There are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to

ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp

environment, the behavior is based on capabilities advertised using media feature tags.

 

The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized mechanism that allows avoiding

any additional dialog usage.”

 

 

Regards,

 

Christer

 





Let me take yet another stab at the paragraph for the introduction, given this set of exchanges. Please read it in the context of the introduction, not just in isolation:

Note that there are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media feature tags. Such implementations revert to RFC 3515 (as described in section 4.5.2 of RFC6665), creating a subscription inside the dialog when interoperating with standard implementations outside those environments. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized alternative that allows avoiding any additional dialog usage.



 

Regards,

 

Christer

 

 

 

 

 

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 13. tammikuuta 2015 17:28
To: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

 

 

On 1/13/15 9:17 AM, Ivo Sedlacek wrote:

Hello Robert,

 

3GPP TS 24.237:

- does not give any statements how Alice is to handle a received in-dialog REFER without norefersub and without Refer-Sub: false. If norefersub is missing or if Refer-Sub: false is missing in the received in-dialog REFER, then RFC3515 and RFC6665 rules apply.

Then my currently proposed text is inaccurate, and we're back to
"Such implementations revert to creating a subscription inside the dialog when interoperating with standard implementations outside those environments."




You asked how the 3GPP solution acts when a REFER request *NOT* described by 3GPP solution is received by 3GPP entity.

 

My answer was that in such case the UA acts as in RFC3515 and RFC6665.

 

You claim that such implementation reverts to creating a subscription inside the dialog when interoperating with standard implementations outside those environments.

 

If that's correct, then *EACH* UA implementation of RFC3515 and RFC6665,*NOT* limited to those described in the 3GPP solution, reverts to creating a subscription inside the dialog when interoperating with standard implementations.

you should be saying _or_ to account for the fielded implementations of 3515 that don't know 6665.

And that's exactly my point - without standardized extension, those implementions risk dialog use , so the 6665 restrictions come into play.

With the extensions in refer-explicit-subscription, an implementation can return a 421/Require to REFER requests that don't use the extension and would create dialog reuse.


 

Kind regards

 

Ivo Sedlacek

 

 


--------------050207040802020300080305-- From nobody Wed Jan 14 07:33:36 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EE61A8707 for ; Wed, 14 Jan 2015 07:33:27 -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 sKl3rd6R1-zV for ; Wed, 14 Jan 2015 07:33:22 -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 D1FCC1A8A08 for ; Wed, 14 Jan 2015 07:33:21 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-76-54b68c3feadc Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F1.58.04076.F3C86B45; Wed, 14 Jan 2015 16:33:19 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.90]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0195.001; Wed, 14 Jan 2015 16:33:19 +0100 From: Ivo Sedlacek To: Robert Sparks , Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQMAtN7Z2KiznJCUi6ZK5VLo+HhZy/vgEw Date: Wed, 14 Jan 2015 15:33:18 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127DD10A@ESESSMB301.ericsson.se> References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> <54ABE6A3.5000300@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7FFC@ESESSMB301.ericsson.se> <54AFF86A.9070605@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DB15E@ESESSMB301.ericsson.se> <54B532D9.8010305@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DBF82@ESESSMB301.ericsson.se> <54B5397E.7010404@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D637D10@ESESSMB209.ericsson.se> <54B676AD.7030509@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D638580@ESESSMB209.ericsson.se> <54B68549.4080408@nostrum.com> In-Reply-To: <54B68549.4080408@nostrum.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101127DD10AESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM+Jvja59z7YQg/m3jS2uzWlks/j6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJUxdx1bwXaTir71m5kaGH/odjFyckgImEjM 77jADGGLSVy4t56ti5GLQ0jgCKPEsvf3oJzFjBL/5k5gBaliE9CTmLjlCCtIQkSglVHi9d/z YAlhgWCJ15s7WUBsEYEQiZnrdzBC2EYS+1etAouzCKhKfNzyFyzOK+ArcaD5MjvEhl4OiZMf noIlOAW0Jd48ugk2lFFAVuLqn16wOLOAuMStJ/OZIG4VkFiy5zzU3aISLx//A6rnALKVJKZt TYMoz5f48+YyC8QuQYmTM5+wTGAUmYVk0iwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DET svgCRvZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIGRdXDLb6sdjAefOx5iFOBgVOLh3XB7 a4gQa2JZcWXuIUZpDhYlcd48hw0hQgLpiSWp2ampBalF8UWlOanFhxiZODilGhhV1PjcI89W KG9a2Dm5LbZyt6xP4pODzveY8nuPci553NBw5NBqRqubzeoNvR/Wzl898VLQceffzgfff/gz /5LyvR3p027lsqRKv3g4c3PHl89vCtbaGLG859/3/HBo6Ad1EdtI47jjZs/fdfNH/zmxaHpv ZlyrmvPyc93B3uyaqlfnTFvF6rRHiaU4I9FQi7moOBEAqs/AZI0CAAA= Archived-At: 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: Wed, 14 Jan 2015 15:33:28 -0000 --_000_39B5E4D390E9BD4890E2B31079006101127DD10AESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER fr= om an entity that does not support any mechanism (standardized or 3GPP-spec= ific), there >obviously is risk of a dialog reuse. But, that is according to the backwar= d compatibility rules in RFC6665, and ANY entity has to be able to deal wit= h that somehow. > >Which, when the peer is an unextended UA, is to fall back and use 3515, he= nce fall back to dialog reuse. Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the peer in = an unextended UA. Your suggested "Such implementations" wording make it sound like only 3GPP = entities will revert :) It is exactly the 3gpp entities that this paragraph is about. How is behaviour of the 3GPP entity different from behaviour of an IETF ent= ity supporting RFC6665 and RFC3515 when interworking with an unextended UA = sending in-dialog REFER? Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B31079006101127DD10AESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialo= g REFER from an entity that does not support any mechanism (standardized or= 3GPP-specific), there

>obviously is risk of a dialog reuse. But, that is according to t= he backward compatibility rules in RFC6665, and ANY entity has to be able t= o deal with that somehow.

> 

>Which, when the peer is an une= xtended UA, is to fall back and use 3515, hence fall back to dialog reuse.

 

Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the p= eer in an unextended UA.

 

Your suggested “Such implementations” wording make it so= und like only 3GPP entities will revert :)

It is e= xactly the 3gpp entities that this paragraph is about.


How is behaviour of th= e 3GPP entity different from behaviour of an IETF entity supporting RFC6665= and RFC3515 when interworking with an unextended UA sending in-dialog REFE= R?

 

Kind regards

 

Ivo Sedlacek

--_000_39B5E4D390E9BD4890E2B31079006101127DD10AESESSMB301erics_-- From nobody Wed Jan 14 07:44:52 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3B31A8AAC for ; Wed, 14 Jan 2015 07:44:48 -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 SRTTQHuIqvWO for ; Wed, 14 Jan 2015 07:44:46 -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 C416B1A886C for ; Wed, 14 Jan 2015 07:44:46 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t0EFifgf091374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Jan 2015 09:44:41 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54B68EE4.1000303@nostrum.com> Date: Wed, 14 Jan 2015 09:44:36 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ivo Sedlacek , Christer Holmberg , "sipcore@ietf.org" References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> <54ABE6A3.5000300@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7FFC@ESESSMB301.ericsson.se> <54AFF86A.9070605@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DB15E@ESESSMB301.ericsson.se> <54B532D9.8010305@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DBF82@ESESSMB301.ericsson.se> <54B5397E.7010404@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D637D10@ESESSMB209.ericsson.se> <54B676AD.7030509@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D638580@ESESSMB209.ericsson.se> <54B68549.4080408@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DD10A@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127DD10A@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------050803060406020706040300" Archived-At: 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: Wed, 14 Jan 2015 15:44:49 -0000 This is a multi-part message in MIME format. --------------050803060406020706040300 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 1/14/15 9:33 AM, Ivo Sedlacek wrote: > > >If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER from an entity that does > not support any mechanism (standardized or 3GPP-specific), there > > >obviously is risk of a dialog reuse. But, that is according to the backward compatibility rules in > RFC6665, and ANY entity has to be able to deal with that somehow. > > > > > >Which, when the peer is an unextended UA, is to fall back and use > 3515, hence fall back to dialog reuse. > > Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the > peer in an unextended UA. > > Your suggested “Such implementations” wording make it sound like only > 3GPP entities will revert :) > > It is exactly the 3gpp entities that this paragraph is about. > > > How is behaviour of the 3GPP entity different from behaviour of an > IETF entity supporting RFC6665 and RFC3515 when interworking with an > unextended UA sending in-dialog REFER? > Please go read my proposed text again. Whether it's the same or different, the text is accurate, and calls out the edge case that matters for this document. Whether you can end up with the same or different fallback paths in other circumstances is irrelevant. If you want to increase the accuracy, we can add text about how the unextended UA won't even be aware that something was _trying_ or was capable of invoking an extension, but I don't see the value in that. The goal of this additional text was to reach the compromise that Andrew pointed to back in December. The focus of this paragraph needs to remain on the private application. > > Kind regards > > Ivo Sedlacek > --------------050803060406020706040300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 1/14/15 9:33 AM, Ivo Sedlacek wrote:

>If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER from an entity that does not support any mechanism (standardized or 3GPP-specific), there

>obviously is risk of a dialog reuse. But, that is according to the backward compatibility rules in RFC6665, and ANY entity has to be able to deal with that somehow.

> 

>Which, when the peer is an unextended UA, is to fall back and use 3515, hence fall back to dialog reuse.

 

Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the peer in an unextended UA.

 

Your suggested “Such implementations” wording make it sound like only 3GPP entities will revert :)

It is exactly the 3gpp entities that this paragraph is about.


How is behaviour of the 3GPP entity different from behaviour of an IETF entity supporting RFC6665 and RFC3515 when interworking with an unextended UA sending in-dialog REFER?

Please go read my proposed text again. Whether it's the same or different, the text is accurate, and calls out the edge case that matters for this document. Whether you can end up with the same or different fallback paths in other circumstances is irrelevant.

If you want to increase the accuracy, we can add text about how the unextended UA won't even be aware that something was _trying_ or was capable of invoking an extension, but I don't see the value in that.

The goal of this additional text was to reach the compromise that Andrew pointed to back in December. The focus of this paragraph needs to remain on the private application.

 

Kind regards

 

Ivo Sedlacek


--------------050803060406020706040300-- From nobody Wed Jan 14 11:09:25 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8231ACE5B for ; Wed, 14 Jan 2015 11:09:07 -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 3VaPBoK1lIM2 for ; Wed, 14 Jan 2015 11:08:58 -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 623461ACE48 for ; Wed, 14 Jan 2015 11:08:53 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-15-54b6bec33e75 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 31.BA.04484.3CEB6B45; Wed, 14 Jan 2015 20:08:51 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0195.001; Wed, 14 Jan 2015 20:08:51 +0100 From: Christer Holmberg To: Robert Sparks , Ivo Sedlacek , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQBeGiFbV1ztW9cUOimw2I9kop/5x1Mf8AgABuBICAAINygIAE5fuAgAAvDgCAANc/AIACMF4AgAEKyRCAAV2XgIAAI1YAgADoEgCAEizAQIABwFeAgAAZMiCAAFIZAIAA+ddQgBrYPYCAATlfgIAAOWuAgAAYT4CABMGWAIAFtUEAgACGSYCAAAUNAIAAAt4AgAEoIJCAAFH9gIAAGHEQ///4+oCAAAhLAIAAAygAgABF+KA= Date: Wed, 14 Jan 2015 19:08:50 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D6389A9@ESESSMB209.ericsson.se> References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <5492FF29.3070206@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.ericsson.se> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> <54ABE6A3.5000300@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7FFC@ESESSMB301.ericsson.se> <54AFF86A.9070605@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DB15E@ESESSMB301.ericsson.se> <54B532D9.8010305@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DBF82@ESESSMB301.ericsson.se> <54B5397E.7010404@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D637D10@ESESSMB209.ericsson.se> <54B676AD.7030509@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D638580@ESESSMB209.ericsson.se> <54B68549.4080408@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DD10A@ESESSMB301.ericsson.se> <54B68EE4.1000303@nostrum.com> In-Reply-To: <54B68EE4.1000303@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D6389A9ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM+Jvje7hfdtCDPof6Flcm9PIZvH1xyY2 ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugSvj4csu9oIHpRU/up+yNTB+Seti5OSQEDCR mLBkCSOELSZx4d56NhBbSOAIo8TyM/ldjFxA9hJGiYank5m6GDk42AQsJLr/aYPUiAhUS+ya 95QJxBYWCJZ4vbmTBSIeIjFz/Q5GkF4RgSYmiceL3rKDJFgEVCUap0xnBbF5BXwlJrdtY4dY 8J5dYun/22BXcApoS/z5sBdsKiPQRd9PrQGzmQXEJW49mc8EcamAxJI955khbFGJl4//sULY ShJrD29ngajPlzi+rokRYpmgxMmZT1gmMIrMQjJqFpKyWUjKIOI6Egt2f2KDsLUlli18zQxj nznwmAlZfAEj+ypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwMg6uOW3wQ7Gl88dDzEKcDAq 8fBuuL01RIg1say4MvcQozQHi5I4b57DhhAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjNXp e8R3Vd3eMPXihHmy/qG3+WT83ewf7dk+665KRYvuugCVx4uf/nIysvO6J1V5buozj06ezQn2 rtMD5nziu8mg/ahE1OF+fnTSF9ZfEQH3v3rd+GmblrDP9bCiq0jbKYG2aX8OSLz6e9tk29tY 9wNfDNqf2Ty5e5NpWV/7x4PFO+cvYOSI71FiKc5INNRiLipOBAAf92HijQIAAA== Archived-At: 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: Wed, 14 Jan 2015 19:09:08 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D6389A9ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I THINK I've found the reason why we seem to talk past each other :) If I understand Robert correctly, he simply wants to clarify that the 3GPP = mechanism does not prevent dialog re-use when interworking with an unextend= ed UAs from sending an in-dialog REFER. Nothing more, nothing less. Is that= correct, Robert? If so, perhaps we instead of talking about the 3GPP implementations could t= alk about the 3GPP MECHANISM, and state that it does not prevent dialog re-= use when interworking with unextended UAs. That way we put the focus on the mechanism, rather than on the UAs, and it = also matches the subsequent sentence about standardized mechanism better. Something like: "There are implementations in some known specialized environments (such as = 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not cre= ate a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media f= eature tags. That mechanism does not, however, prevent additional dialog usages when interoperating with implementations that do n= ot support the mechanism. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized mecha= nism that allows avoiding any additional dialog usage." Regards, Christer From: Robert Sparks [mailto:rjsparks@nostrum.com] Sent: 14 January 2015 17:45 To: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt On 1/14/15 9:33 AM, Ivo Sedlacek wrote: >If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER fr= om an entity that does not support any mechanism (standardized or 3GPP-spec= ific), there >obviously is risk of a dialog reuse. But, that is according to the backwar= d compatibility rules in RFC6665, and ANY entity has to be able to deal wit= h that somehow. > >Which, when the peer is an unextended UA, is to fall back and use 3515, he= nce fall back to dialog reuse. Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the peer in = an unextended UA. Your suggested "Such implementations" wording make it sound like only 3GPP = entities will revert :) It is exactly the 3gpp entities that this paragraph is about. How is behaviour of the 3GPP entity different from behaviour of an IETF ent= ity supporting RFC6665 and RFC3515 when interworking with an unextended UA = sending in-dialog REFER? Please go read my proposed text again. Whether it's the same or different, = the text is accurate, and calls out the edge case that matters for this doc= ument. Whether you can end up with the same or different fallback paths in = other circumstances is irrelevant. If you want to increase the accuracy, we can add text about how the unexten= ded UA won't even be aware that something was _trying_ or was capable of in= voking an extension, but I don't see the value in that. The goal of this additional text was to reach the compromise that Andrew po= inted to back in December. The focus of this paragraph needs to remain on t= he private application. Kind regards Ivo Sedlacek --_000_7594FB04B1934943A5C02806D1A2204B1D6389A9ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I THINK I’ve found the reason why we seem to talk past each othe= r :)

 

If I understand Robert correctly, he simply wants to clarify that the 3GPP mechanism does not prevent dialog re-use when interworking with= an unextended UAs from sending an in-dialog REFER. Nothing more, nothing l= ess. Is that correct, Robert?

 

If so, perhaps we instead of talking about the 3GPP implementations co= uld talk about the 3GPP MECHANISM, and state that it does not prevent dialog re-use whe= n interworking with unextended UAs.

 

That way we put the focus on the mechanism, rather than on the UAs, an= d it also matches the subsequent sentence about standardized mechanism bett= er.

 

Something like:

 

“There are implementations in some known specia= lized environments (such as 3gpp) that use out-of-signalling agreements to

ensure that in-dialog REFER requests using the RFC448= 8 extension do not create a new subscription inside that dialog. In the 3gp= p

environment, the behavior is based on capabilities ad= vertised using media feature tags. That mechanism does not, however, preven= t

additional dialog usages when interoperating with imp= lementations that do not support the mechanism. The extensions in

[I-D.ietf-sipcore-refer-explicit-subscription] provid= e a standardized mechanism that allows avoiding any additional dialog usage= .”

 

Regards,

 

Christer

 

 

F= rom: Robert Spar= ks [mailto:rjsparks@nostrum.com]
Sent: 14 January 2015 17:45
To: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarific= ations-00.txt

 

 

On 1/14/15 9:33 AM, Ivo Sedlacek wrote:

>If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialo= g REFER from an entity that does not support any mechanism (standardized or= 3GPP-specific), there

>obviously is risk of a dialog reuse. But, that is according to t= he backward compatibility rules in RFC6665, and ANY entity has to be able t= o deal with that somehow.

> 

>Which, when the peer is an unextended UA, is to fall back and= use 3515, hence fall back to dialog reuse.

 

Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the p= eer in an unextended UA.

 

Your suggested “Such implementations” wording make it so= und like only 3GPP entities will revert :)

It is exact= ly the 3gpp entities that this paragraph is about.



How is behaviour of th= e 3GPP entity different from behaviour of an IETF entity supporting RFC6665= and RFC3515 when interworking with an unextended UA sending in-dialog REFE= R?

Please go read my proposed text again. Whether i= t's the same or different, the text is accurate, and calls out the edge cas= e that matters for this document. Whether you can end up with the same or different fallback paths in other circumstance= s is irrelevant.

If you want to increase the accuracy, we can add text about how the unexten= ded UA won't even be aware that something was _trying_ or was capable of in= voking an extension, but I don't see the value in that.

The goal of this additional text was to reach the compromise that Andrew po= inted to back in December. The focus of this paragraph needs to remain on t= he private application.

 

Kind regards

 

Ivo Sedlacek

 

--_000_7594FB04B1934943A5C02806D1A2204B1D6389A9ESESSMB209erics_-- From nobody Wed Jan 14 12:12:12 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF99C1B29B1 for ; Wed, 14 Jan 2015 12:12:00 -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 2-Q42n7HrUIO for ; Wed, 14 Jan 2015 12:11:46 -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 C6E651B29AE for ; Wed, 14 Jan 2015 12:11:41 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t0EKBaVY013630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Jan 2015 14:11:36 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54B6CD73.2050504@nostrum.com> Date: Wed, 14 Jan 2015 14:11:31 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Christer Holmberg , Ivo Sedlacek , "sipcore@ietf.org" References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> <54ABE6A3.5000300@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7FFC@ESESSMB301.ericsson.se> <54AFF86A.9070605@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DB15E@ESESSMB301.ericsson.se> <54B532D9.8010305@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DBF82@ESESSMB301.ericsson.se> <54B5397E.7010404@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D637D10@ESESSMB209.ericsson.se> <54B676AD.7030509@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D638580@ESESSMB209.ericsson.se> <54B68549.4080408@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DD10A@ESESSMB301.ericsson.se> <54B68EE4.1000303@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D6389A9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D6389A9@ESESSMB209.ericsson.se> Content-Type: multipart/alternative; boundary="------------080906020506080809050708" Archived-At: 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: Wed, 14 Jan 2015 20:12:01 -0000 This is a multi-part message in MIME format. --------------080906020506080809050708 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 1/14/15 1:08 PM, Christer Holmberg wrote: > > Hi, > > I THINK I’ve found the reason why we seem to talk past each other :) > > If I understand Robert correctly, he simply wants to clarify that the > *3GPP mechanism* does not prevent dialog re-use when interworking with > an unextended UAs from sending an in-dialog REFER. Nothing more, > nothing less. Is that correct, Robert? > > If so, perhaps we instead of talking about the 3GPP implementations > could talk about the *3GPP MECHANISM*, and state that it does not > prevent dialog re-use when interworking with unextended UAs. > > That way we put the focus on the mechanism, rather than on the UAs, > and it also matches the subsequent sentence about standardized > mechanism better. > > Something like: > > “There are implementations in some known specialized environments > (such as 3gpp) that use out-of-signalling agreements to > > ensure that in-dialog REFER requests using the RFC4488 extension do > not create a new subscription inside that dialog. In the 3gpp > > environment, the behavior is based on capabilities advertised using > media feature tags. That mechanism does not, however, prevent > > additional dialog usages when interoperating with implementations that > do not support the mechanism. The extensions in > > [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized > mechanism that allows avoiding any additional dialog usage.” > I would be fine with that text. > > Regards, > > Christer > > *From:*Robert Sparks [mailto:rjsparks@nostrum.com] > *Sent:* 14 January 2015 17:45 > *To:* Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org > *Subject:* Re: [sipcore] I-D Action: > draft-ietf-sipcore-refer-clarifications-00.txt > > On 1/14/15 9:33 AM, Ivo Sedlacek wrote: > > >If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER from an entity that > does not support any mechanism (standardized or 3GPP-specific), there > > >obviously is risk of a dialog reuse. But, that is according to the backward compatibility rules > in RFC6665, and ANY entity has to be able to deal with that somehow. > > > > > >Which, when the peer is an unextended UA, is to fall back and use 3515, hence fall back to > dialog reuse. > > Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the > peer in an unextended UA. > > Your suggested “Such implementations” wording make it sound like > only 3GPP entities will revert :) > > It is exactly the 3gpp entities that this paragraph is about. > > > > How is behaviour of the 3GPP entity different from behaviour of an > IETF entity supporting RFC6665 and RFC3515 when interworking with > an unextended UA sending in-dialog REFER? > > Please go read my proposed text again. Whether it's the same or > different, the text is accurate, and calls out the edge case that > matters for this document. Whether you can end up with the same or > different fallback paths in other circumstances is irrelevant. > > If you want to increase the accuracy, we can add text about how the > unextended UA won't even be aware that something was _trying_ or was > capable of invoking an extension, but I don't see the value in that. > > The goal of this additional text was to reach the compromise that > Andrew pointed to back in December. The focus of this paragraph needs > to remain on the private application. > > Kind regards > > Ivo Sedlacek > --------------080906020506080809050708 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 1/14/15 1:08 PM, Christer Holmberg wrote:

Hi,

 

I THINK I’ve found the reason why we seem to talk past each other :)

 

If I understand Robert correctly, he simply wants to clarify that the 3GPP mechanism does not prevent dialog re-use when interworking with an unextended UAs from sending an in-dialog REFER. Nothing more, nothing less. Is that correct, Robert?

 

If so, perhaps we instead of talking about the 3GPP implementations could talk about the 3GPP MECHANISM, and state that it does not prevent dialog re-use when interworking with unextended UAs.

 

That way we put the focus on the mechanism, rather than on the UAs, and it also matches the subsequent sentence about standardized mechanism better.

 

Something like:

 

“There are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to

ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp

environment, the behavior is based on capabilities advertised using media feature tags. That mechanism does not, however, prevent

additional dialog usages when interoperating with implementations that do not support the mechanism. The extensions in

[I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized mechanism that allows avoiding any additional dialog usage.”

I would be fine with that text.

 

Regards,

 

Christer

 

 

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 14 January 2015 17:45
To: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

 

 

On 1/14/15 9:33 AM, Ivo Sedlacek wrote:

>If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER from an entity that does not support any mechanism (standardized or 3GPP-specific), there

>obviously is risk of a dialog reuse. But, that is according to the backward compatibility rules in RFC6665, and ANY entity has to be able to deal with that somehow.

> 

>Which, when the peer is an unextended UA, is to fall back and use 3515, hence fall back to dialog reuse.

 

Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the peer in an unextended UA.

 

Your suggested “Such implementations” wording make it sound like only 3GPP entities will revert :)

It is exactly the 3gpp entities that this paragraph is about.



How is behaviour of the 3GPP entity different from behaviour of an IETF entity supporting RFC6665 and RFC3515 when interworking with an unextended UA sending in-dialog REFER?

Please go read my proposed text again. Whether it's the same or different, the text is accurate, and calls out the edge case that matters for this document. Whether you can end up with the same or different fallback paths in other circumstances is irrelevant.

If you want to increase the accuracy, we can add text about how the unextended UA won't even be aware that something was _trying_ or was capable of invoking an extension, but I don't see the value in that.

The goal of this additional text was to reach the compromise that Andrew pointed to back in December. The focus of this paragraph needs to remain on the private application.

 

Kind regards

 

Ivo Sedlacek

 


--------------080906020506080809050708-- From nobody Wed Jan 14 14:08:27 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7BE1ACDCF for ; Wed, 14 Jan 2015 14:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 O6bcEjosCEk3 for ; Wed, 14 Jan 2015 14:08:24 -0800 (PST) Received: from mx0b-0019e102.pphosted.com (mx0b-0019e102.pphosted.com [67.231.157.237]) (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 408AB1ACDBA for ; Wed, 14 Jan 2015 14:08:24 -0800 (PST) Received: from pps.filterd (m0074415.ppops.net [127.0.0.1]) by mx0b-0019e102.pphosted.com (8.14.7/8.14.7) with SMTP id t0EM6Mv1020455 for ; Wed, 14 Jan 2015 16:08:23 -0600 Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by mx0b-0019e102.pphosted.com with ESMTP id 1rwyrtg24u-1 (version=TLSv1/SSLv3 cipher=AES256-SHA256 bits=256 verify=NOT) for ; Wed, 14 Jan 2015 16:08:23 -0600 Received: from CO2PR04MB697.namprd04.prod.outlook.com (10.141.230.12) by CO2PR04MB697.namprd04.prod.outlook.com (10.141.230.12) with Microsoft SMTP Server (TLS) id 15.1.53.17; Wed, 14 Jan 2015 22:08:16 +0000 Received: from CO2PR04MB697.namprd04.prod.outlook.com ([10.141.230.12]) by CO2PR04MB697.namprd04.prod.outlook.com ([10.141.230.12]) with mapi id 15.01.0053.000; Wed, 14 Jan 2015 22:08:16 +0000 From: Adam Lewis To: "sipcore@ietf.org" Thread-Topic: Question on drafft-yusef-sipcore-sip-oauth-01 Thread-Index: AdAwRpf70V4oWpEmSk2Qphv1i8LamA== Date: Wed, 14 Jan 2015 22:08:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [150.130.151.69] authentication-results: spf=none (sender IP is ) smtp.mailfrom=Adam.Lewis@motorolasolutions.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:CO2PR04MB697; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:CO2PR04MB697; x-forefront-prvs: 04569283F9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(52034003)(19300405004)(229853001)(106356001)(107886001)(33656002)(97736003)(2501002)(50986999)(54356999)(110136001)(2351001)(54206007)(18717965001)(16236675004)(46102003)(54606007)(15975445007)(2656002)(40100003)(77096005)(87936001)(68736005)(76576001)(74316001)(230783001)(92566002)(101416001)(19625215002)(64706001)(66066001)(450100001)(19580395003)(102836002)(99286002)(62966003)(105586002)(77156002)(86362001)(2900100001)(19609705001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR04MB697; H:CO2PR04MB697.namprd04.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: motorolasolutions.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_CO2PR04MB6977D14DBD9CB164994AD6A95410CO2PR04MB697namprd_" MIME-Version: 1.0 X-OriginatorOrg: motorolasolutions.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2015 22:08:16.0052 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 93f5baf9-414a-4f1b-88bc-33f3013923d7 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR04MB697 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=8.0459186535542e-09 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.99939988688917 urlsuspect_oldscore=0.99939988688917 suspectscore=0 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.99939988688917 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1501140211 Archived-At: Subject: [sipcore] Question on drafft-yusef-sipcore-sip-oauth-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: Wed, 14 Jan 2015 22:08:27 -0000 --_000_CO2PR04MB6977D14DBD9CB164994AD6A95410CO2PR04MB697namprd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am confused by the way that OAuth is currently proposed to be used with S= IP in this draft. Looking at the flow of messages in section 3.2, it shows= at F3 that the SIP UA (after receiving the 401 in F2) triggers an authori= zation request to the authorization endpoint of the authorization server, a= t which point the UA utilizes the master-key to authenticate to the authori= zation server at F5. Finally the UA gets the authorization code at F6. Al= l good so far. My confusion starts at F7 where the UA sends the code to the Proxy, and whe= re the proxy exchanges the code for the actual token (F8/F9). This is a bi= t of an unconventional flow, as normally the client that obtains the author= ization code is the same client that exchanges it for the token. Why in th= is flow is the UA obtaining the code, only to send it to the proxy to obtai= n the token? I would have thought that the UA would use the code to obtain the token, an= d embed the token in its request to the proxy, to authenticate the user. T= hen the proxy could do a p-asserted-id or something similar when routing SI= P messages onward ... tx! adam --_000_CO2PR04MB6977D14DBD9CB164994AD6A95410CO2PR04MB697namprd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am confused by the way that OAuth is currently pro= posed to be used with SIP in this draft.  Looking at the flow of messa= ges in section 3.2, it shows at F3  that the SIP UA (after receiving t= he 401 in F2) triggers an authorization request to the authorization endpoint of the authorization server, at which point = the UA utilizes the master-key to authenticate to the authorization server = at F5.  Finally the UA gets the authorization code at F6.  All go= od so far.

 

My confusion starts at F7 where the UA sends the cod= e to the Proxy, and where the proxy exchanges the code for the actual token= (F8/F9).  This is a bit of an unconventional flow, as normally the cl= ient that obtains the authorization code is the same client that exchanges it for the token.  Why in this flow= is the UA obtaining the code, only to send it to the proxy to obtain the t= oken? 

 

I would have thought that the UA would use the code = to obtain the token, and embed the token in its request to the proxy, to au= thenticate the user.  Then the proxy could do a p-asserted-id or somet= hing similar when routing SIP messages onward …

 

 

tx!

adam

--_000_CO2PR04MB6977D14DBD9CB164994AD6A95410CO2PR04MB697namprd_-- From nobody Thu Jan 15 00:05:14 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5021B2BAE for ; Thu, 15 Jan 2015 00:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 O1RXgxnISjFY for ; Thu, 15 Jan 2015 00:05:10 -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 5FC981B2BAD for ; Thu, 15 Jan 2015 00:05:09 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-45-54b774b3d6e6 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 0E.D2.04484.3B477B45; Thu, 15 Jan 2015 09:05:07 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.90]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0195.001; Thu, 15 Jan 2015 09:05:06 +0100 From: Ivo Sedlacek To: Robert Sparks , Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQMAtN7Z2KiznJCUi6ZK5VLo+HhZy/vgEw///zJACAADkQAIAAEYOAgADPlwA= Date: Thu, 15 Jan 2015 08:05:06 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127DD62C@ESESSMB301.ericsson.se> References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <5493592A.3080302@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.ericsson.se> <54AAAF99.3020207@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> <54ABE6A3.5000300@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7FFC@ESESSMB301.ericsson.se> <54AFF86A.9070605@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DB15E@ESESSMB301.ericsson.se> <54B532D9.8010305@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DBF82@ESESSMB301.ericsson.se> <54B5397E.7010404@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D637D10@ESESSMB209.ericsson.se> <54B676AD.7030509@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D638580@ESESSMB209.ericsson.se> <54B68549.4080408@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DD10A@ESESSMB301.ericsson.se> <54B68EE4.1000303@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D6389A9@ESESSMB209.ericsson.se> <54B6CD73.2050504@nostrum.com> In-Reply-To: <54B6CD73.2050504@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.146] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101127DD62CESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM+Jvje7mku0hBnPfKFhcm9PIZvH1xyY2 ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugStj8e6bjAX7VzFWrG49x9rAOG0qYxcjJ4eE gInEsb5+VghbTOLCvfVsXYxcHEICRxglmha0M4EkhAQWM0q8PRMKYrMJ6ElM3HKEFaRIRKCV UeL13/Ng3cICwRKvN3eygNgiAiESM9fvYISw/STef7zLBmKzCKhKzN9+DszmFfCV+PZjASPE gvfsEotm5YPYnALaEsfX7mEHsRkFZCWu/ukFq2EWEJe49WQ+E8SlAhJL9pxnhrBFJV4+/gf1 gZLEjw2XWCDq8yVOrG1ggdglKHFy5hOWCYwis5CMmoWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD 2GcOPGZCFl/AyL6KUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzC6Dm75bbCD8eVzx0OMAhyM Sjy8BanbQ4RYE8uKK3MPMUpzsCiJ8+Y5bAgREkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwKi/ xGLLvxmHwpTOMT+639iUJxHCpdoiP+P7khPXtqdrM04SdBd0nXZXPJLt7tP4wo6sY9n/2tJ3 eb6pSjRiEn7clzNf5rKnx6ENG1NFL/o3RKRyZJ0OUjQQeb5k68aX68pvvfLb95tFLc/Tb+nd fzMlZOavF1wao71plouK0ovFR68+crtpxKfEUpyRaKjFXFScCABGZwzsjwIAAA== Archived-At: 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: Thu, 15 Jan 2015 08:05:13 -0000 --_000_39B5E4D390E9BD4890E2B31079006101127DD62CESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Robert, In order to avoid any misunderstandings among future readers of the draft o= n what is the route cause of the problem, I'd like to add the following sta= tement to the beginning: "RFC3515 and RFC6665 do not prevent additional dia= log usages when interoperating with implementations that do not support RFC= 6665." Also, I think the last sentence needs to be aligned with second last senten= ce. I.e. "RFC3515 and RFC6665 do not prevent additional dialog usages when interoper= ating with implementations that do not support RFC6665. There are implement= ations in some known specialized environments (such as 3gpp) that use out-o= f-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not cre= ate a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media f= eature tags. That mechanism does not, however, prevent additional dialog usages when interoperating with implementations that do n= ot support the mechanism. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized mecha= nism that allows avoiding any additional dialog usage when interoperating w= ith implementations that do not support the mechanism." If this is acceptable, I would be OK with this text. Kind regards Ivo Sedlacek 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: Robert Sparks [mailto:rjsparks@nostrum.com] Sent: 14. ledna 2015 21:12 To: Christer Holmberg; Ivo Sedlacek; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt On 1/14/15 1:08 PM, Christer Holmberg wrote: Hi, I THINK I've found the reason why we seem to talk past each other :) If I understand Robert correctly, he simply wants to clarify that the 3GPP = mechanism does not prevent dialog re-use when interworking with an unextend= ed UAs from sending an in-dialog REFER. Nothing more, nothing less. Is that= correct, Robert? If so, perhaps we instead of talking about the 3GPP implementations could t= alk about the 3GPP MECHANISM, and state that it does not prevent dialog re-= use when interworking with unextended UAs. That way we put the focus on the mechanism, rather than on the UAs, and it = also matches the subsequent sentence about standardized mechanism better. Something like: "There are implementations in some known specialized environments (such as = 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not cre= ate a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media f= eature tags. That mechanism does not, however, prevent additional dialog usages when interoperating with implementations that do n= ot support the mechanism. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized mecha= nism that allows avoiding any additional dialog usage." I would be fine with that text. Regards, Christer From: Robert Sparks [mailto:rjsparks@nostrum.com] Sent: 14 January 2015 17:45 To: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt On 1/14/15 9:33 AM, Ivo Sedlacek wrote: >If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER fr= om an entity that does not support any mechanism (standardized or 3GPP-spec= ific), there >obviously is risk of a dialog reuse. But, that is according to the backwar= d compatibility rules in RFC6665, and ANY entity has to be able to deal wit= h that somehow. > >Which, when the peer is an unextended UA, is to fall back and use 3515, he= nce fall back to dialog reuse. Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the peer in = an unextended UA. Your suggested "Such implementations" wording make it sound like only 3GPP = entities will revert :) It is exactly the 3gpp entities that this paragraph is about. How is behaviour of the 3GPP entity different from behaviour of an IETF ent= ity supporting RFC6665 and RFC3515 when interworking with an unextended UA = sending in-dialog REFER? Please go read my proposed text again. Whether it's the same or different, = the text is accurate, and calls out the edge case that matters for this doc= ument. Whether you can end up with the same or different fallback paths in = other circumstances is irrelevant. If you want to increase the accuracy, we can add text about how the unexten= ded UA won't even be aware that something was _trying_ or was capable of in= voking an extension, but I don't see the value in that. The goal of this additional text was to reach the compromise that Andrew po= inted to back in December. The focus of this paragraph needs to remain on t= he private application. Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B31079006101127DD62CESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Robert,

 

In order to avoid any = misunderstandings among future readers of the draft on what is the route ca= use of the problem, I'd like to add the following statement to the beginnin= g: "RFC3515 and RFC6665 do not prevent additional dialog usages when interoperating with implementations that do = not support RFC6665."

 

Also, I think the last= sentence needs to be aligned with second last sentence.<= /p>

 

I.e.=

 

“RFC3515 and RFC6665 do n= ot prevent additional dialog usages when interoperating with implementation= s that do not support RFC6665. There are implementations in some know= n specialized environments (such as 3gpp) that use out-of-signalling agreem= ents to

ensure that in-dialog REFER requests using the RFC4488 extension do = not create a new subscription inside that dialog. In the 3gpp

environment, the behavior is based on capabilities advertised using = media feature tags. That mechanism does not, however, prevent

additional dialog usages when interoperating with implementations th= at do not support the mechanism. The extensions in

[I-D.ietf-sipcore-refer-explicit-subscription] provide a standardize= d mechanism that allows avoiding any additional dialog usage when = interoperating with implementations that do not support the mechanism.”

 

If this is acceptable,= I would be OK with this text.

 

Kind regards

 

Ivo Sedlacek

 

 

This Communication is Confid= ential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer =

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 14. ledna 2015 21:12
To: Christer Holmberg; Ivo Sedlacek; sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarific= ations-00.txt

 

 

On 1/14/15 1:08 PM, Christer Holmberg wrote:

Hi,<= /p>

 

I THINK I’ve fou= nd the reason why we seem to talk past each other :)

 

If I understand Robert= correctly, he simply wants to clarify that the 3GPP mechanism does not prevent dialog re-use when interworking with= an unextended UAs from sending an in-dialog REFER. Nothing more, nothing l= ess. Is that correct, Robert?

 

If so, perhaps we inst= ead of talking about the 3GPP implementations could talk about the 3GPP MECHANISM, and state that it does not prevent dialog re-use whe= n interworking with unextended UAs.

 

That way we put the fo= cus on the mechanism, rather than on the UAs, and it also matches the subse= quent sentence about standardized mechanism better.

 

Something like:=

 

“There are implementations in some known specialized environme= nts (such as 3gpp) that use out-of-signalling agreements to

ensure that in-dialog REFER requests using the RFC4488 extension do = not create a new subscription inside that dialog. In the 3gpp

environment, the behavior is based on capabilities advertised using = media feature tags. That mechanism does not, however, prevent

additional dialog usages when interoperating with implementations th= at do not support the mechanism. The extensions in

[I-D.ietf-sipcore-refer-explicit-subscription] provide a standardize= d mechanism that allows avoiding any additional dialog usage.”=

I would be fine with that text.

 

Regards,

 

Christer

 

 

From:= Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 14 January 2015 17:45
To: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarific= ations-00.txt

 

 <= /o:p>

On 1/14/15 9:33 AM, Ivo Sedlacek wrote:

>If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialo= g REFER from an entity that does not support any mechanism (standardized or= 3GPP-specific), there

>obviously is risk of a dialog reuse. But, that is according to t= he backward compatibility rules in RFC6665, and ANY entity has to be able t= o deal with that somehow.

> 

>Which, when the peer is an unextended UA, is to fall back and= use 3515, hence fall back to dialog reuse.

 

Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the p= eer in an unextended UA.

 

Your suggested “Such implementations” wording make it so= und like only 3GPP entities will revert :)

It is e= xactly the 3gpp entities that this paragraph is about.




How is behaviour of th= e 3GPP entity different from behaviour of an IETF entity supporting RFC6665= and RFC3515 when interworking with an unextended UA sending in-dialog REFE= R?

Please go read my proposed te= xt again. Whether it's the same or different, the text is accurate, and cal= ls out the edge case that matters for this document. Whether you can end up with the same or different fallback paths in other circumst= ances is irrelevant.

If you want to increase the accuracy, we can add text about how the unexten= ded UA won't even be aware that something was _trying_ or was capable of in= voking an extension, but I don't see the value in that.

The goal of this additional text was to reach the compromise that Andrew po= inted to back in December. The focus of this paragraph needs to remain on t= he private application.


 

Kind regards

 

Ivo Sedlacek

 

 

--_000_39B5E4D390E9BD4890E2B31079006101127DD62CESESSMB301erics_-- From nobody Thu Jan 15 07:03:20 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1771C1B2BFB for ; Thu, 15 Jan 2015 07:03:18 -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 yvVDwvirHiXA for ; Thu, 15 Jan 2015 07:03:15 -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 144111B2B24 for ; Thu, 15 Jan 2015 07:03:15 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t0FF38LD020734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Jan 2015 09:03:09 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54B7D6A7.7040904@nostrum.com> Date: Thu, 15 Jan 2015 09:03:03 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ivo Sedlacek , Christer Holmberg , "sipcore@ietf.org" References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <54AAAF99.3020207@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> <54ABE6A3.5000300@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7FFC@ESESSMB301.ericsson.se> <54AFF86A.9070605@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DB15E@ESESSMB301.ericsson.se> <54B532D9.8010305@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DBF82@ESESSMB301.ericsson.se> <54B5397E.7010404@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D637D10@ESESSMB209.ericsson.se> <54B676AD.7030509@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D638580@ESESSMB209.ericsson.se> <54B68549.4080408@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DD10A@ESESSMB301.ericsson.se> <54B68EE4.1000303@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D6389A9@ESESSMB209.ericsson.se> <54B6CD73.2050504@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DD62C@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127DD62C@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------010202010707040407050700" Archived-At: 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: Thu, 15 Jan 2015 15:03:18 -0000 This is a multi-part message in MIME format. --------------010202010707040407050700 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 1/15/15 2:05 AM, Ivo Sedlacek wrote: > > Hello Robert, > > In order to avoid any misunderstandings among future readers of the > draft on what is the route cause of the problem, I'd like to add the > following statement to the beginning: "RFC3515 and RFC6665 do not > prevent additional dialog usages when interoperating with > implementations that do not support RFC6665." > I don't agree. I think this addition would be unnecessary and not helpful. > > Also, I think the last sentence needs to be aligned with second last > sentence. > > I.e. > > “RFC3515 and RFC6665 do not prevent additional dialog usages when > interoperating with implementations that do not support RFC6665. There > are implementations in some known specialized environments (such as > 3gpp) that use out-of-signalling agreements to > > ensure that in-dialog REFER requests using the RFC4488 extension do > not create a new subscription inside that dialog. In the 3gpp > > environment, the behavior is based on capabilities advertised using > media feature tags. That mechanism does not, however, prevent > > additional dialog usages when interoperating with implementations that > do not support the mechanism. The extensions in > > [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized > mechanism that allows avoiding any additional dialog usage when > interoperating with implementations that do not support the mechanism.” > Again, I don't agree. The sentence is correct without the clause you add - it covers avoiding additional dialog usage in general, not just in the case the added clause calls out. > > If this is acceptable, I would be OK with this text. > > Kind regards > > Ivo Sedlacek > > This Communication is Confidential. We only send and receive email on > the basis of the terms set out at www.ericsson.com/email_disclaimer > > > *From:*Robert Sparks [mailto:rjsparks@nostrum.com] > *Sent:* 14. ledna 2015 21:12 > *To:* Christer Holmberg; Ivo Sedlacek; sipcore@ietf.org > *Subject:* Re: [sipcore] I-D Action: > draft-ietf-sipcore-refer-clarifications-00.txt > > On 1/14/15 1:08 PM, Christer Holmberg wrote: > > Hi, > > I THINK I’ve found the reason why we seem to talk past each other :) > > If I understand Robert correctly, he simply wants to clarify that > the *3GPP mechanism* does not prevent dialog re-use when > interworking with an unextended UAs from sending an in-dialog > REFER. Nothing more, nothing less. Is that correct, Robert? > > If so, perhaps we instead of talking about the 3GPP > implementations could talk about the *3GPP MECHANISM*, and state > that it does not prevent dialog re-use when interworking with > unextended UAs. > > That way we put the focus on the mechanism, rather than on the > UAs, and it also matches the subsequent sentence about > standardized mechanism better. > > Something like: > > “There are implementations in some known specialized environments > (such as 3gpp) that use out-of-signalling agreements to > > ensure that in-dialog REFER requests using the RFC4488 extension > do not create a new subscription inside that dialog. In the 3gpp > > environment, the behavior is based on capabilities advertised > using media feature tags. That mechanism does not, however, prevent > > additional dialog usages when interoperating with implementations > that do not support the mechanism. The extensions in > > [I-D.ietf-sipcore-refer-explicit-subscription] provide a > standardized mechanism that allows avoiding any additional dialog > usage.” > > I would be fine with that text. > > Regards, > > Christer > > *From:*Robert Sparks [mailto:rjsparks@nostrum.com] > *Sent:* 14 January 2015 17:45 > *To:* Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org > > *Subject:* Re: [sipcore] I-D Action: > draft-ietf-sipcore-refer-clarifications-00.txt > > On 1/14/15 9:33 AM, Ivo Sedlacek wrote: > > >If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER from an entity that > does not support any mechanism (standardized or 3GPP-specific), there > > >obviously is risk of a dialog reuse. But, that is according to the backward compatibility rules > in RFC6665, and ANY entity has to be able to deal with that somehow. > > > > > >Which, when the peer is an unextended UA, is to fall back and use 3515, hence fall back to > dialog reuse. > > Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the > peer in an unextended UA. > > Your suggested “Such implementations” wording make it sound like > only 3GPP entities will revert :) > > It is exactly the 3gpp entities that this paragraph is about. > > > > > How is behaviour of the 3GPP entity different from behaviour of an > IETF entity supporting RFC6665 and RFC3515 when interworking with > an unextended UA sending in-dialog REFER? > > Please go read my proposed text again. Whether it's the same or > different, the text is accurate, and calls out the edge case that > matters for this document. Whether you can end up with the same or > different fallback paths in other circumstances is irrelevant. > > If you want to increase the accuracy, we can add text about how the > unextended UA won't even be aware that something was _trying_ or was > capable of invoking an extension, but I don't see the value in that. > > The goal of this additional text was to reach the compromise that > Andrew pointed to back in December. The focus of this paragraph needs > to remain on the private application. > > > Kind regards > > Ivo Sedlacek > --------------010202010707040407050700 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 1/15/15 2:05 AM, Ivo Sedlacek wrote:

Hello Robert,

 

In order to avoid any misunderstandings among future readers of the draft on what is the route cause of the problem, I'd like to add the following statement to the beginning: "RFC3515 and RFC6665 do not prevent additional dialog usages when interoperating with implementations that do not support RFC6665."

I don't agree. I think this addition would be unnecessary and not helpful.

 

Also, I think the last sentence needs to be aligned with second last sentence.

 

I.e.

 

“RFC3515 and RFC6665 do not prevent additional dialog usages when interoperating with implementations that do not support RFC6665. There are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to

ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp

environment, the behavior is based on capabilities advertised using media feature tags. That mechanism does not, however, prevent

additional dialog usages when interoperating with implementations that do not support the mechanism. The extensions in

[I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized mechanism that allows avoiding any additional dialog usage when interoperating with implementations that do not support the mechanism.”

Again, I don't agree. The sentence is correct without the clause you add - it covers avoiding additional dialog usage in general, not just in the case the added clause calls out.

 

If this is acceptable, I would be OK with this text.

 

Kind regards

 

Ivo Sedlacek

 

 

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

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 14. ledna 2015 21:12
To: Christer Holmberg; Ivo Sedlacek; sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

 

 

On 1/14/15 1:08 PM, Christer Holmberg wrote:

Hi,

 

I THINK I’ve found the reason why we seem to talk past each other :)

 

If I understand Robert correctly, he simply wants to clarify that the 3GPP mechanism does not prevent dialog re-use when interworking with an unextended UAs from sending an in-dialog REFER. Nothing more, nothing less. Is that correct, Robert?

 

If so, perhaps we instead of talking about the 3GPP implementations could talk about the 3GPP MECHANISM, and state that it does not prevent dialog re-use when interworking with unextended UAs.

 

That way we put the focus on the mechanism, rather than on the UAs, and it also matches the subsequent sentence about standardized mechanism better.

 

Something like:

 

“There are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to

ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp

environment, the behavior is based on capabilities advertised using media feature tags. That mechanism does not, however, prevent

additional dialog usages when interoperating with implementations that do not support the mechanism. The extensions in

[I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized mechanism that allows avoiding any additional dialog usage.”

I would be fine with that text.

 

Regards,

 

Christer

 

 

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 14 January 2015 17:45
To: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

 

 

On 1/14/15 9:33 AM, Ivo Sedlacek wrote:

>If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER from an entity that does not support any mechanism (standardized or 3GPP-specific), there

>obviously is risk of a dialog reuse. But, that is according to the backward compatibility rules in RFC6665, and ANY entity has to be able to deal with that somehow.

> 

>Which, when the peer is an unextended UA, is to fall back and use 3515, hence fall back to dialog reuse.

 

Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the peer in an unextended UA.

 

Your suggested “Such implementations” wording make it sound like only 3GPP entities will revert :)

It is exactly the 3gpp entities that this paragraph is about.




How is behaviour of the 3GPP entity different from behaviour of an IETF entity supporting RFC6665 and RFC3515 when interworking with an unextended UA sending in-dialog REFER?

Please go read my proposed text again. Whether it's the same or different, the text is accurate, and calls out the edge case that matters for this document. Whether you can end up with the same or different fallback paths in other circumstances is irrelevant.

If you want to increase the accuracy, we can add text about how the unextended UA won't even be aware that something was _trying_ or was capable of invoking an extension, but I don't see the value in that.

The goal of this additional text was to reach the compromise that Andrew pointed to back in December. The focus of this paragraph needs to remain on the private application.


 

Kind regards

 

Ivo Sedlacek

 

 


--------------010202010707040407050700-- From nobody Fri Jan 16 00:17:14 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0D41AC3BA for ; Fri, 16 Jan 2015 00:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 e48VNvfFoex0 for ; Fri, 16 Jan 2015 00:16:58 -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 AFFDF1AC3B2 for ; Fri, 16 Jan 2015 00:16:57 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-d5-54b8c8f7879f Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 39.DB.04484.7F8C8B45; Fri, 16 Jan 2015 09:16:55 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.90]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0195.001; Fri, 16 Jan 2015 09:16:54 +0100 From: Ivo Sedlacek To: Robert Sparks , Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQMNRjVM0KOFN5cUy9xkvOhqhaAZzCZhTg Date: Fri, 16 Jan 2015 08:16:53 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127DE750@ESESSMB301.ericsson.se> References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <54AAAF99.3020207@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7A23@ESESSMB301.ericsson.se> <54ABE6A3.5000300@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7FFC@ESESSMB301.ericsson.se> <54AFF86A.9070605@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DB15E@ESESSMB301.ericsson.se> <54B532D9.8010305@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DBF82@ESESSMB301.ericsson.se> <54B5397E.7010404@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D637D10@ESESSMB209.ericsson.se> <54B676AD.7030509@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D638580@ESESSMB209.ericsson.se> <54B68549.4080408@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DD10A@ESESSMB301.ericsson.se> <54B68EE4.1000303@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D6389A9@ESESSMB209.ericsson.se> <54B6CD73.2050504@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DD62C@ESESSMB301.ericsson.se> <54B7D6A7.7040904@nostrum.com> In-Reply-To: <54B7D6A7.7040904@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.19] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101127DE750ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvje73EztCDFpOKVlcm9PIZvH1xyY2 ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugStj18U57AV7zjFW9J5TaWC8uYWxi5GTQ0LA RGL6nxWsELaYxIV769m6GLk4hASOMEqsfrGLEcJZzCix9/9sFpAqNgE9iYlbjrCCJEQEWhkl Xv89D9YuLBAs8XpzJ1iRiECIxMz1OxghbCOJd+8+M3cxcnCwCKhKXJwXDGLyCvhKPJ9rDjH/ PbvE/4YmsHJOAW2JvfMeMoHYjAKyElf/9ILFmQXEJW49mc8EcamAxJI955khbFGJl4//QX2g KNH+tAGqPl/ixKq1YPW8AoISJ2c+YZnAKDILyahZSMpmISmDiOtILNj9iQ3C1pZYtvA1M4x9 5sBjJmTxBYzsqxhFi1OLk3LTjYz0Uosyk4uL8/P08lJLNjECY+vglt8GOxhfPnc8xCjAwajE w/th244QIdbEsuLK3EOM0hwsSuK8eQ4bQoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwcm7T OHN2XehtjvZfB8Vk2Kb+cu6YpeUYoJb57uoP59ubVt0NaWKS+PNz76Eys8NP++dWR24NUbl3 59YPja9yRi8PNVbedOar9+xI9eFfkjLjoCv72+2mk+1fCLz+4unR/v/HvYAd7+/WubgzXPz8 uNs95NDMZ023FuWtnTnR7bHq/t8fFur+LFBiKc5INNRiLipOBABLlPDvjgIAAA== Archived-At: 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, 16 Jan 2015 08:17:05 -0000 --_000_39B5E4D390E9BD4890E2B31079006101127DE750ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Robert, I re-checked the draft and found that the text (2nd paragraph in section 2)= immediately preceding the new addition more or less covers what I wanted t= o say with "RFC3515 and RFC6665 do not prevent additional dialog usages whe= n interoperating with implementations that do not support RFC6665." Thus, I am OK with text proposed by Christer. Kind regards Ivo Sedlacek 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: Robert Sparks [mailto:rjsparks@nostrum.com] Sent: 15. ledna 2015 16:03 To: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt On 1/15/15 2:05 AM, Ivo Sedlacek wrote: Hello Robert, In order to avoid any misunderstandings among future readers of the draft o= n what is the route cause of the problem, I'd like to add the following sta= tement to the beginning: "RFC3515 and RFC6665 do not prevent additional dia= log usages when interoperating with implementations that do not support RFC= 6665." I don't agree. I think this addition would be unnecessary and not helpful. Also, I think the last sentence needs to be aligned with second last senten= ce. I.e. "RFC3515 and RFC6665 do not prevent additional dialog usages when interoper= ating with implementations that do not support RFC6665. There are implement= ations in some known specialized environments (such as 3gpp) that use out-o= f-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not cre= ate a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media f= eature tags. That mechanism does not, however, prevent additional dialog usages when interoperating with implementations that do n= ot support the mechanism. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized mecha= nism that allows avoiding any additional dialog usage when interoperating w= ith implementations that do not support the mechanism." Again, I don't agree. The sentence is correct without the clause you add - = it covers avoiding additional dialog usage in general, not just in the case= the added clause calls out. If this is acceptable, I would be OK with this text. Kind regards Ivo Sedlacek 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: Robert Sparks [mailto:rjsparks@nostrum.com] Sent: 14. ledna 2015 21:12 To: Christer Holmberg; Ivo Sedlacek; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt On 1/14/15 1:08 PM, Christer Holmberg wrote: Hi, I THINK I've found the reason why we seem to talk past each other :) If I understand Robert correctly, he simply wants to clarify that the 3GPP = mechanism does not prevent dialog re-use when interworking with an unextend= ed UAs from sending an in-dialog REFER. Nothing more, nothing less. Is that= correct, Robert? If so, perhaps we instead of talking about the 3GPP implementations could t= alk about the 3GPP MECHANISM, and state that it does not prevent dialog re-= use when interworking with unextended UAs. That way we put the focus on the mechanism, rather than on the UAs, and it = also matches the subsequent sentence about standardized mechanism better. Something like: "There are implementations in some known specialized environments (such as = 3gpp) that use out-of-signalling agreements to ensure that in-dialog REFER requests using the RFC4488 extension do not cre= ate a new subscription inside that dialog. In the 3gpp environment, the behavior is based on capabilities advertised using media f= eature tags. That mechanism does not, however, prevent additional dialog usages when interoperating with implementations that do n= ot support the mechanism. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized mecha= nism that allows avoiding any additional dialog usage." I would be fine with that text. Regards, Christer From: Robert Sparks [mailto:rjsparks@nostrum.com] Sent: 14 January 2015 17:45 To: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt On 1/14/15 9:33 AM, Ivo Sedlacek wrote: >If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER fr= om an entity that does not support any mechanism (standardized or 3GPP-spec= ific), there >obviously is risk of a dialog reuse. But, that is according to the backwar= d compatibility rules in RFC6665, and ANY entity has to be able to deal wit= h that somehow. > >Which, when the peer is an unextended UA, is to fall back and use 3515, he= nce fall back to dialog reuse. Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the peer in = an unextended UA. Your suggested "Such implementations" wording make it sound like only 3GPP = entities will revert :) It is exactly the 3gpp entities that this paragraph is about. How is behaviour of the 3GPP entity different from behaviour of an IETF ent= ity supporting RFC6665 and RFC3515 when interworking with an unextended UA = sending in-dialog REFER? Please go read my proposed text again. Whether it's the same or different, = the text is accurate, and calls out the edge case that matters for this doc= ument. Whether you can end up with the same or different fallback paths in = other circumstances is irrelevant. If you want to increase the accuracy, we can add text about how the unexten= ded UA won't even be aware that something was _trying_ or was capable of in= voking an extension, but I don't see the value in that. The goal of this additional text was to reach the compromise that Andrew po= inted to back in December. The focus of this paragraph needs to remain on t= he private application. Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B31079006101127DE750ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Robert,

 

I re-checked the draft= and found that the text (2nd paragraph in section 2) immediately preceding= the new addition more or less covers what I wanted to say with "RFC35= 15 and RFC6665 do not prevent additional dialog usages when interoperating with implementations that do not support= RFC6665."

 

Thus, I am OK with tex= t proposed by Christer.

 

Kind regards

 

Ivo Sedlacek

 

 

This Communication is Confid= ential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer =

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 15. ledna 2015 16:03
To: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarific= ations-00.txt

 

 

On 1/15/15 2:05 AM, Ivo Sedlacek wrote:

Hello Robert,

 

In order to avoid any = misunderstandings among future readers of the draft on what is the route ca= use of the problem, I'd like to add the following statement to the beginnin= g: "RFC3515 and RFC6665 do not prevent additional dialog usages when interoperating with implementations that do = not support RFC6665."

I don't agree. I think this addition= would be unnecessary and not helpful.

 

Also, I think the last= sentence needs to be aligned with second last sentence.<= /p>

 

I.e.=

 

“RFC3515 and RFC6665 do n= ot prevent additional dialog usages when interoperating with implementation= s that do not support RFC6665. There are implementations in some know= n specialized environments (such as 3gpp) that use out-of-signalling agreem= ents to

ensure that in-dialog REFER requests using the RFC4488 extension do = not create a new subscription inside that dialog. In the 3gpp

environment, the behavior is based on capabilities advertised using = media feature tags. That mechanism does not, however, prevent

additional dialog usages when interoperating with implementations th= at do not support the mechanism. The extensions in

[I-D.ietf-sipcore-refer-explicit-subscription] provide a standardize= d mechanism that allows avoiding any additional dialog usage when interoperating with implementatio= ns that do not support the mechanism.&= #8221;

Again, I don't agree. The sentence i= s correct without the clause you add - it covers avoiding additional dialog= usage in general, not just in the case the added clause calls out.

 

If this is acceptable,= I would be OK with this text.

 

Kind regards

 

Ivo Sedlacek

 

 

This Communication is Confid= ential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 14. ledna 2015 21:12
To: Christer Holmberg; Ivo Sedlacek; sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarific= ations-00.txt

 

 

On 1/14/15 1:08 PM, Christer Holmberg wrote:

Hi,<= /p>

 

I THINK I’ve fou= nd the reason why we seem to talk past each other :)

 

If I understand Robert= correctly, he simply wants to clarify that the 3GPP mechanism does not prevent dialog re-use when interworking with= an unextended UAs from sending an in-dialog REFER. Nothing more, nothing l= ess. Is that correct, Robert?

 

If so, perhaps we inst= ead of talking about the 3GPP implementations could talk about the 3GPP MECHANISM, and state that it does not prevent dialog re-use whe= n interworking with unextended UAs.

 

That way we put the fo= cus on the mechanism, rather than on the UAs, and it also matches the subse= quent sentence about standardized mechanism better.

 

Something like:=

 

“There are implementations in some known specialized environme= nts (such as 3gpp) that use out-of-signalling agreements to

ensure that in-dialog REFER requests using the RFC4488 extension do = not create a new subscription inside that dialog. In the 3gpp

environment, the behavior is based on capabilities advertised using = media feature tags. That mechanism does not, however, prevent

additional dialog usages when interoperating with implementations th= at do not support the mechanism. The extensions in

[I-D.ietf-sipcore-refer-explicit-subscription] provide a standardize= d mechanism that allows avoiding any additional dialog usage.”=

I would be fine with that te= xt.


 

Regards,

 

Christer

 

 

From:= Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 14 January 2015 17:45
To: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarific= ations-00.txt

 

 <= /o:p>

On 1/14/15 9:33 AM, Ivo Sedlacek wrote:

>If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialo= g REFER from an entity that does not support any mechanism (standardized or= 3GPP-specific), there

>obviously is risk of a dialog reuse. But, that is according to t= he backward compatibility rules in RFC6665, and ANY entity has to be able t= o deal with that somehow.

> 

>Which, when the peer is an unextended UA, is to fall back and= use 3515, hence fall back to dialog reuse.

 

Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the p= eer in an unextended UA.

 

Your suggested “Such implementations” wording make it so= und like only 3GPP entities will revert :)

It is exactly the 3gpp entities that this paragraph is about.





How is behaviour of th= e 3GPP entity different from behaviour of an IETF entity supporting RFC6665= and RFC3515 when interworking with an unextended UA sending in-dialog REFE= R?

Please go read my proposed text agai= n. Whether it's the same or different, the text is accurate, and calls out = the edge case that matters for this document. Whether you can end up with the same or different fallback paths in other circumstance= s is irrelevant.

If you want to increase the accuracy, we can add text about how the unexten= ded UA won't even be aware that something was _trying_ or was capable of in= voking an extension, but I don't see the value in that.

The goal of this additional text was to reach the compromise that Andrew po= inted to back in December. The focus of this paragraph needs to remain on t= he private application.



 

Kind regards

 

Ivo Sedlacek

 

 

 

--_000_39B5E4D390E9BD4890E2B31079006101127DE750ESESSMB301erics_-- From nobody Fri Jan 16 06:58:16 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 183871ACDCE for ; Fri, 16 Jan 2015 06:58:10 -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 Uoq2DJ2mgytd for ; Fri, 16 Jan 2015 06:58:02 -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 A43FC1ACD73 for ; Fri, 16 Jan 2015 06:58:02 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t0GEvvpg048406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Jan 2015 08:57:58 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54B926F0.1070300@nostrum.com> Date: Fri, 16 Jan 2015 08:57:52 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ivo Sedlacek , Christer Holmberg , "sipcore@ietf.org" References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <54ABE6A3.5000300@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127D7FFC@ESESSMB301.ericsson.se> <54AFF86A.9070605@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DB15E@ESESSMB301.ericsson.se> <54B532D9.8010305@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DBF82@ESESSMB301.ericsson.se> <54B5397E.7010404@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D637D10@ESESSMB209.ericsson.se> <54B676AD.7030509@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D638580@ESESSMB209.ericsson.se> <54B68549.4080408@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DD10A@ESESSMB301.ericsson.se> <54B68EE4.1000303@nostrum.com> <7594FB04B1934943A5C02806D1A2204B1D6389A9@ESESSMB209.ericsson.se> <54B6CD73.2050504@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DD62C@ESESSMB301.ericsson.se> <54B7D6A7.7040904@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127DE750@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127DE750@ESESSMB301.ericsson.se> Content-Type: multipart/alternative; boundary="------------040501080001010600040506" Archived-At: 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, 16 Jan 2015 14:58:10 -0000 This is a multi-part message in MIME format. --------------040501080001010600040506 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 1/16/15 2:16 AM, Ivo Sedlacek wrote: > > Hello Robert, > > I re-checked the draft and found that the text (2nd paragraph in > section 2) immediately preceding the new addition more or less covers > what I wanted to say with "RFC3515 and RFC6665 do not prevent > additional dialog usages when interoperating with implementations that > do not support RFC6665." > > Thus, I am OK with text proposed by Christer. > > Kind regards > > Ivo Sedlacek > Thanks Ivo. I'll send in a new version RjS > > 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:*Robert Sparks [mailto:rjsparks@nostrum.com] > *Sent:* 15. ledna 2015 16:03 > *To:* Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org > *Subject:* Re: [sipcore] I-D Action: > draft-ietf-sipcore-refer-clarifications-00.txt > > On 1/15/15 2:05 AM, Ivo Sedlacek wrote: > > Hello Robert, > > In order to avoid any misunderstandings among future readers of > the draft on what is the route cause of the problem, I'd like to > add the following statement to the beginning: "RFC3515 and RFC6665 > do not prevent additional dialog usages when interoperating with > implementations that do not support RFC6665." > > I don't agree. I think this addition would be unnecessary and not helpful. > > Also, I think the last sentence needs to be aligned with second last > sentence. > > I.e. > > “RFC3515 and RFC6665 do not prevent additional dialog usages when > interoperating with implementations that do not support RFC6665. There > are implementations in some known specialized environments (such as > 3gpp) that use out-of-signalling agreements to > > ensure that in-dialog REFER requests using the RFC4488 extension do > not create a new subscription inside that dialog. In the 3gpp > > environment, the behavior is based on capabilities advertised using > media feature tags. That mechanism does not, however, prevent > > additional dialog usages when interoperating with implementations that > do not support the mechanism. The extensions in > > [I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized > mechanism that allows avoiding any additional dialog usage when > interoperating with implementations that do not support the mechanism.” > > Again, I don't agree. The sentence is correct without the clause you > add - it covers avoiding additional dialog usage in general, not just > in the case the added clause calls out. > > If this is acceptable, I would be OK with this text. > > Kind regards > > Ivo Sedlacek > > This Communication is Confidential. We only send and receive email on > the basis of the terms set out at www.ericsson.com/email_disclaimer > > > *From:*Robert Sparks [mailto:rjsparks@nostrum.com] > *Sent:* 14. ledna 2015 21:12 > *To:* Christer Holmberg; Ivo Sedlacek; sipcore@ietf.org > > *Subject:* Re: [sipcore] I-D Action: > draft-ietf-sipcore-refer-clarifications-00.txt > > On 1/14/15 1:08 PM, Christer Holmberg wrote: > > Hi, > > I THINK I’ve found the reason why we seem to talk past each other :) > > If I understand Robert correctly, he simply wants to clarify that > the *3GPP mechanism* does not prevent dialog re-use when > interworking with an unextended UAs from sending an in-dialog > REFER. Nothing more, nothing less. Is that correct, Robert? > > If so, perhaps we instead of talking about the 3GPP > implementations could talk about the *3GPP MECHANISM*, and state > that it does not prevent dialog re-use when interworking with > unextended UAs. > > That way we put the focus on the mechanism, rather than on the > UAs, and it also matches the subsequent sentence about > standardized mechanism better. > > Something like: > > “There are implementations in some known specialized environments > (such as 3gpp) that use out-of-signalling agreements to > > ensure that in-dialog REFER requests using the RFC4488 extension > do not create a new subscription inside that dialog. In the 3gpp > > environment, the behavior is based on capabilities advertised > using media feature tags. That mechanism does not, however, prevent > > additional dialog usages when interoperating with implementations > that do not support the mechanism. The extensions in > > [I-D.ietf-sipcore-refer-explicit-subscription] provide a > standardized mechanism that allows avoiding any additional dialog > usage.” > > I would be fine with that text. > > > Regards, > > Christer > > *From:*Robert Sparks [mailto:rjsparks@nostrum.com] > *Sent:* 14 January 2015 17:45 > *To:* Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org > > *Subject:* Re: [sipcore] I-D Action: > draft-ietf-sipcore-refer-clarifications-00.txt > > On 1/14/15 9:33 AM, Ivo Sedlacek wrote: > > >If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER from an entity that > does not support any mechanism (standardized or 3GPP-specific), there > > >obviously is risk of a dialog reuse. But, that is according to the backward compatibility rules > in RFC6665, and ANY entity has to be able to deal with that somehow. > > > > > >Which, when the peer is an unextended UA, is to fall back and use 3515, hence fall back to > dialog reuse. > > Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the > peer in an unextended UA. > > Your suggested “Such implementations” wording make it sound like > only 3GPP entities will revert :) > > It is exactly the 3gpp entities that this paragraph is about. > > > > > > How is behaviour of the 3GPP entity different from behaviour of an > IETF entity supporting RFC6665 and RFC3515 when interworking with > an unextended UA sending in-dialog REFER? > > Please go read my proposed text again. Whether it's the same or > different, the text is accurate, and calls out the edge case that > matters for this document. Whether you can end up with the same or > different fallback paths in other circumstances is irrelevant. > > If you want to increase the accuracy, we can add text about how the > unextended UA won't even be aware that something was _trying_ or was > capable of invoking an extension, but I don't see the value in that. > > The goal of this additional text was to reach the compromise that > Andrew pointed to back in December. The focus of this paragraph needs > to remain on the private application. > > > > Kind regards > > Ivo Sedlacek > --------------040501080001010600040506 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 1/16/15 2:16 AM, Ivo Sedlacek wrote:

Hello Robert,

 

I re-checked the draft and found that the text (2nd paragraph in section 2) immediately preceding the new addition more or less covers what I wanted to say with "RFC3515 and RFC6665 do not prevent additional dialog usages when interoperating with implementations that do not support RFC6665."

 

Thus, I am OK with text proposed by Christer.

 

Kind regards

 

Ivo Sedlacek

Thanks Ivo.

I'll send in a new version

RjS

 

 

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: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 15. ledna 2015 16:03
To: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

 

 

On 1/15/15 2:05 AM, Ivo Sedlacek wrote:

Hello Robert,

 

In order to avoid any misunderstandings among future readers of the draft on what is the route cause of the problem, I'd like to add the following statement to the beginning: "RFC3515 and RFC6665 do not prevent additional dialog usages when interoperating with implementations that do not support RFC6665."

I don't agree. I think this addition would be unnecessary and not helpful.

 

Also, I think the last sentence needs to be aligned with second last sentence.

 

I.e.

 

“RFC3515 and RFC6665 do not prevent additional dialog usages when interoperating with implementations that do not support RFC6665. There are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to

ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp

environment, the behavior is based on capabilities advertised using media feature tags. That mechanism does not, however, prevent

additional dialog usages when interoperating with implementations that do not support the mechanism. The extensions in

[I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized mechanism that allows avoiding any additional dialog usage when interoperating with implementations that do not support the mechanism.”

Again, I don't agree. The sentence is correct without the clause you add - it covers avoiding additional dialog usage in general, not just in the case the added clause calls out.

 

If this is acceptable, I would be OK with this text.

 

Kind regards

 

Ivo Sedlacek

 

 

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

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 14. ledna 2015 21:12
To: Christer Holmberg; Ivo Sedlacek; sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

 

 

On 1/14/15 1:08 PM, Christer Holmberg wrote:

Hi,

 

I THINK I’ve found the reason why we seem to talk past each other :)

 

If I understand Robert correctly, he simply wants to clarify that the 3GPP mechanism does not prevent dialog re-use when interworking with an unextended UAs from sending an in-dialog REFER. Nothing more, nothing less. Is that correct, Robert?

 

If so, perhaps we instead of talking about the 3GPP implementations could talk about the 3GPP MECHANISM, and state that it does not prevent dialog re-use when interworking with unextended UAs.

 

That way we put the focus on the mechanism, rather than on the UAs, and it also matches the subsequent sentence about standardized mechanism better.

 

Something like:

 

“There are implementations in some known specialized environments (such as 3gpp) that use out-of-signalling agreements to

ensure that in-dialog REFER requests using the RFC4488 extension do not create a new subscription inside that dialog. In the 3gpp

environment, the behavior is based on capabilities advertised using media feature tags. That mechanism does not, however, prevent

additional dialog usages when interoperating with implementations that do not support the mechanism. The extensions in

[I-D.ietf-sipcore-refer-explicit-subscription] provide a standardized mechanism that allows avoiding any additional dialog usage.”

I would be fine with that text.


 

Regards,

 

Christer

 

 

From: Robert Sparks [mailto:rjsparks@nostrum.com]
Sent: 14 January 2015 17:45
To: Ivo Sedlacek; Christer Holmberg; sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt

 

 

On 1/14/15 9:33 AM, Ivo Sedlacek wrote:

>If ANY entity (3GPP-Alice or Internet-Alice) receive an in-dialog REFER from an entity that does not support any mechanism (standardized or 3GPP-specific), there

>obviously is risk of a dialog reuse. But, that is according to the backward compatibility rules in RFC6665, and ANY entity has to be able to deal with that somehow.

> 

>Which, when the peer is an unextended UA, is to fall back and use 3515, hence fall back to dialog reuse.

 

Correct. But, it applies to ANY entity (3GPP or non-3GPP) when the peer in an unextended UA.

 

Your suggested “Such implementations” wording make it sound like only 3GPP entities will revert :)

It is exactly the 3gpp entities that this paragraph is about.





How is behaviour of the 3GPP entity different from behaviour of an IETF entity supporting RFC6665 and RFC3515 when interworking with an unextended UA sending in-dialog REFER?

Please go read my proposed text again. Whether it's the same or different, the text is accurate, and calls out the edge case that matters for this document. Whether you can end up with the same or different fallback paths in other circumstances is irrelevant.

If you want to increase the accuracy, we can add text about how the unextended UA won't even be aware that something was _trying_ or was capable of invoking an extension, but I don't see the value in that.

The goal of this additional text was to reach the compromise that Andrew pointed to back in December. The focus of this paragraph needs to remain on the private application.



 

Kind regards

 

Ivo Sedlacek

 

 

 


--------------040501080001010600040506-- From nobody Fri Jan 16 07:34:03 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FAD1ACD2A for ; Fri, 16 Jan 2015 07:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zSV2J6LOD7P for ; Fri, 16 Jan 2015 07:33:59 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87EE21A924C for ; Fri, 16 Jan 2015 07:33:55 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id pn19so19495621lab.9 for ; Fri, 16 Jan 2015 07:33:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Jmdo9Enq2C2edCZr5ljFwSzhWaSSUqdx75djpvAdYfI=; b=OnRVVEWH2DR14oNwVmRnnS6OteG91B11zzaYc4+SCce9ZJzQbqmsUBSu/PeMXMQk6F xjY6wiMvbfYBb/HcklAXcDoZq+U4ux0ta5svmL5RjVyP4hNShPrmsnyo/rAI1UL2zt/E yJ0GCXNdNdkdnrJjMyb4+2aVhIiP17w4RWYX76fVflHIdKahEEflZehUFbISGD7QLeoQ PGUbysmTH7BMti/bsz2pJXTq/SP19xFGXr0PyIZjNAqtPuEHt2jEftoTM3NzV6FyQqqw ofarKBaf+9wILdIZs+zQzBE5lJE6WEHfp4js9mDZfLZhKxGxomIHzRpBGFzHGJkt4xmS wCDA== MIME-Version: 1.0 X-Received: by 10.112.140.196 with SMTP id ri4mr16145872lbb.55.1421422433889; Fri, 16 Jan 2015 07:33:53 -0800 (PST) Received: by 10.114.27.162 with HTTP; Fri, 16 Jan 2015 07:33:53 -0800 (PST) In-Reply-To: References: Date: Fri, 16 Jan 2015 10:33:53 -0500 Message-ID: From: Rifaat Shekh-Yusef To: Adam Lewis Content-Type: multipart/alternative; boundary=001a11c2605e3f7740050cc6b305 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Question on drafft-yusef-sipcore-sip-oauth-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: Fri, 16 Jan 2015 15:34:02 -0000 --001a11c2605e3f7740050cc6b305 Content-Type: text/plain; charset=ISO-8859-1 Hi Adam, Thanks for your review and comments. Please, see my reply inline... Regards, Rifaat On Wed, Jan 14, 2015 at 5:08 PM, Adam Lewis < Adam.Lewis@motorolasolutions.com> wrote: > Hi, > > > > I am confused by the way that OAuth is currently proposed to be used with > SIP in this draft. Looking at the flow of messages in section 3.2, it > shows at F3 that the SIP UA (after receiving the 401 in F2) triggers an > authorization request to the authorization endpoint of the authorization > server, at which point the UA utilizes the master-key to authenticate to > the authorization server at F5. Finally the UA gets the authorization code > at F6. All good so far. > > > > My confusion starts at F7 where the UA sends the code to the Proxy, and > where the proxy exchanges the code for the actual token (F8/F9). This is a > bit of an unconventional flow, as normally the client that obtains the > authorization code is the same client that exchanges it for the token. Why > in this flow is the UA obtaining the code, only to send it to the proxy to > obtain the token? > Notice that in F9 the authorization server returns the ID Token and the master-key to the proxy. The master-key is needed to allow us to use the proof-of-possession mechanism for any subsequent messages as described at the top of page 8 (F11/F12). > > I would have thought that the UA would use the code to obtain the token, > and embed the token in its request to the proxy, to authenticate the user. > Then the proxy could do a p-asserted-id or something similar when routing > SIP messages onward ... > With the current document the ID Token is not sent to the UA; we have an open issue around that, and I think it probably makes more sense to send it back to the UA to allow the UA to use the ID Token with its communication with SIP and non-SIP network elements. Regards, Rifaat > > > > tx! > > adam > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --001a11c2605e3f7740050cc6b305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Adam,

Thanks for your review and com= ments.
Please, see my reply inline...

Re= gards,
 Rifaat


On Wed, Jan 14, 2015 at 5:08 PM, Adam Lewi= s <Adam.Lewis@motorolasolutions.com> wrote:

Hi,

 

I am confused by the way that OAuth is currently pro= posed to be used with SIP in this draft.  Looking at the flow of messa= ges in section 3.2, it shows at F3  that the SIP UA (after receiving t= he 401 in F2) triggers an authorization request to the authorization endpoint of the authorization server, at which point = the UA utilizes the master-key to authenticate to the authorization server = at F5.  Finally the UA gets the authorization code at F6.  All go= od so far.

 

My confusion starts at F7 where the UA sends the cod= e to the Proxy, and where the proxy exchanges the code for the actual token= (F8/F9).  This is a bit of an unconventional flow, as normally the cl= ient that obtains the authorization code is the same client that exchanges it for the token.  Why in this flow= is the UA obtaining the code, only to send it to the proxy to obtain the t= oken? 


Notice that in = F9 the authorization server returns the ID Token and the master-key to the = proxy. The master-key is needed to allow us to use the proof-of-possession = mechanism for any subsequent messages as described at the top of page 8 (F1= 1/F12).


 

I would have thought that the UA would use the code = to obtain the token, and embed the token in its request to the proxy, to au= thenticate the user.  Then the proxy could do a p-asserted-id or somet= hing similar when routing SIP messages onward …


With the c= urrent document the ID Token is not sent to the UA; we have an open issue a= round that, and I think it probably makes more sense to send it back to the= UA to allow the UA to use the ID Token with its communication with SIP and= non-SIP network elements.

Regards,
&nbs= p;Rifaat


=

 

 

tx!

adam


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


--001a11c2605e3f7740050cc6b305-- From nobody Mon Jan 19 08:55:00 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28F31B29F5 for ; Mon, 19 Jan 2015 07:49:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MwRMPs4ms2x for ; Mon, 19 Jan 2015 07:49:20 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 184451AD10A for ; Mon, 19 Jan 2015 07:49:20 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 3E5EC187A98; Mon, 19 Jan 2015 07:49:06 -0800 (PST) To: jmpolk@cisco.com, br@brianrosen.net, jon.peterson@neustar.biz, 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: <20150119154906.3E5EC187A98@rfc-editor.org> Date: Mon, 19 Jan 2015 07:49:06 -0800 (PST) Archived-At: X-Mailman-Approved-At: Mon, 19 Jan 2015 08:54:59 -0800 Cc: rappleto@avaya.com, sipcore@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] [Technical Errata Reported] RFC6442 (4236) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jan 2015 15:49:21 -0000 The following errata report has been submitted for RFC6442, "Location Conveyance for the Session Initiation Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6442&eid=4236 -------------------------------------- Type: Technical Reported by: Richard Appleton Section: 5.1, 5.2 Original Text ------------- false Corrected Text -------------- no Notes ----- as per section 4.4 This location error is specific to having the PIDF-LO [RFC4119] element set to "no". This location error is stating it requires permission (i.e., PIDF-LO element set to "yes") and RFC4119 section 2.2.2 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. -------------------------------------- RFC6442 (draft-ietf-sipcore-location-conveyance-09) -------------------------------------- Title : Location Conveyance for the Session Initiation Protocol Publication Date : December 2011 Author(s) : J. Polk, B. Rosen, J. Peterson Category : PROPOSED STANDARD Source : Session Initiation Protocol Core Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From nobody Wed Jan 21 13:05:37 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EAF1A887C; Wed, 21 Jan 2015 13:05:27 -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 BuQB8TIXJt55; Wed, 21 Jan 2015 13:05:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D621A8878; Wed, 21 Jan 2015 13:05:26 -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.10.0.p8 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150121210526.24004.59206.idtracker@ietfa.amsl.com> Date: Wed, 21 Jan 2015 13:05:26 -0800 Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-01.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: Wed, 21 Jan 2015 21:05:28 -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-01.txt Pages : 6 Date : 2015-01-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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-refer-clarifications-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 21 13:16:59 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4C51A887A for ; Wed, 21 Jan 2015 13:16:58 -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 L9wbZtWKqzOd for ; Wed, 21 Jan 2015 13:16:56 -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 C08111A888A for ; Wed, 21 Jan 2015 13:16:56 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t0LLGtjC063150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 21 Jan 2015 15:16:56 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54C01742.8080802@nostrum.com> Date: Wed, 21 Jan 2015 15:16:50 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <20150121210526.24004.59206.idtracker@ietfa.amsl.com> In-Reply-To: <20150121210526.24004.59206.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jan 2015 21:16:58 -0000 I think this, and refer-explicit-subscriptions are ready for WGLC. Let me know if I've missed anything. RjS On 1/21/15 3:05 PM, internet-drafts@ietf.org wrote: > 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-01.txt > Pages : 6 > Date : 2015-01-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-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-refer-clarifications-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Jan 23 04:10:13 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB60E1A909B for ; Fri, 23 Jan 2015 04:10:11 -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 BgOy1QOCtsCv for ; Fri, 23 Jan 2015 04:10:09 -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 EF1441A90A2 for ; Fri, 23 Jan 2015 04:10:08 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-6e-54c23a1ea74d Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 7A.00.04484.E1A32C45; Fri, 23 Jan 2015 13:10:06 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 13:10:06 +0100 From: Christer Holmberg To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-01.txt Thread-Index: AQHQNb4QXdNpSzFLNk6rGVkHu2+UK5zLAuQAgAKaUuA= Date: Fri, 23 Jan 2015 12:10:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D679B06@ESESSMB209.ericsson.se> References: <20150121210526.24004.59206.idtracker@ietfa.amsl.com> <54C01742.8080802@nostrum.com> In-Reply-To: <54C01742.8080802@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvja6c1aEQg/uHzCyuzWlks/j6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJWx5HB6wTrJip9nHzE2MLaJdDFyckgImEgs bm5jh7DFJC7cW8/WxcjFISRwhFHi+4wNUM5iRol/TTeYuhg5ONgELCS6/2mDNIgIBEosnLSE BcQWFgiWuPf8MTtEPETixttfbBC2lcTemT/AalgEVCVu/P/MDGLzCvhKNOy6zwoyUkggSWLq mUgQk1NAW2L/0giQCkagc76fWsMEYjMLiEvcejKfCeJMAYkle84zQ9iiEi8f/2OFsJUkfmy4 xAJRryOxYPcnNghbW2LZwtdQWwUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYyixanFSbnp RkZ6qUWZycXF+Xl6eaklmxiBEXJwy2+DHYwvnzseYhTgYFTi4S34eDBEiDWxrLgy9xCjNAeL kjivnfGhECGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MLCvNfMxKFRTm2YfPmK/X0HWcpzfQ 0827905exPrTzJPnzWksrlq662tz/2Whac7bmlc4LZjVNjWwKGDa362v7i9a1fr5X+KVeQIu BzeGmP0+sdnokaMwR/qleim1Y61BL5I2bru2bcLHhtfnE8zZo+Tq+9ffYFi5Y4XS6UUub6wn RKY3snzhVGIpzkg01GIuKk4EADawkY9xAgAA Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 12:10:11 -0000 Hi Robert, The document looks good, and I also think it's ready for WGLC. I do have an= editorial comment, though: The second last paragraph in section 4 says: "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]." Since the draft earlier talks about having to send REFERs out-of-dialog if = the remote Contact is a GRUU, I think it would be good to explicitly clarif= y that in this case sending an in-dialog REFER is allowed even if the remot= e Contact is a GRUU. (Because, there may many non-REFER related reasons why the remote UA provid= ed a GRUU.) Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert Sparks Sent: 21. tammikuuta 2015 23:17 To: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 01.txt I think this, and refer-explicit-subscriptions are ready for WGLC. Let me know if I've missed anything. RjS On 1/21/15 3:05 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Session Initiation Protocol Core Worki= ng Group of the IETF. > > Title : Clarifications for the use of REFER with RFC66= 65 > Authors : Robert Sparks > Adam Roach > Filename : draft-ietf-sipcore-refer-clarifications-01.txt > Pages : 6 > Date : 2015-01-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-clarificatio > ns/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sipcore-refer-clarifications-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-refer-clarificatio > ns-01 > > > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.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 Jan 23 04:26:39 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385271A909D for ; Fri, 23 Jan 2015 04:26:38 -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 21RXohZFNiEk for ; Fri, 23 Jan 2015 04:26:33 -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 2628B1A909B for ; Fri, 23 Jan 2015 04:26:32 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-ee-54c23df79e83 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 32.C2.04484.7FD32C45; Fri, 23 Jan 2015 13:26:31 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0195.001; Fri, 23 Jan 2015 13:26:31 +0100 From: Christer Holmberg To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: Comments on draft-ietf-sipcore-refer-explicit-subscription-00 Thread-Index: AdA3Bra9jrCJN4u7SBSRERVqqjw7TA== Date: Fri, 23 Jan 2015 12:26:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D679CD5@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+Jvje5320MhBpNPylhcm9PIZvH1xyY2 ByaPJUt+MnnM2vmEJYApissmJTUnsyy1SN8ugSvj7pcnTAVHRSped11lb2D8wd/FyMEhIWAi cfORRRcjJ5ApJnHh3no2EFtI4AijxOQjTl2MXED2YkaJfwcnMoLUswlYSHT/0wapEREIlFg4 aQkLiC0s4CZxedZpJpASEQFvicmPMiFK9CS2v37NChJmEVCVeDOjFMTkFfCV+NRdDVLBCLT0 +6k1TCA2s4C4xK0n85kgjhGQWLLnPDOELSrx8vE/VghbSeLHhkssEPU6Egt2f2KDsLUlli18 DVbPKyAocXLmE5YJjMKzkIydhaRlFpKWWUhaFjCyrGIULU4tTspNNzLSSy3KTC4uzs/Ty0st 2cQIDPaDW34b7GB8+dzxEKMAB6MSD2/Bx4MhQqyJZcWVuYcYpTlYlMR57YwPhQgJpCeWpGan phakFsUXleakFh9iZOLglGpgjLzTXd4oGlX3surIxxd6avWrLh3eKdRrK37lQHrOlqW3jjJm SkncXXLx85Gks4sYVmc7vD+4y3KXyO696nPMl65Z/O2mwfFT687/qYtYMOnAL63stPtve+WW 3Ui48JVLQXjtm4RVc1tsb7f15jYIcN8sL9twWOrotVkv/S9fz9pzP8xt/qp5njOUWIozEg21 mIuKEwG778A4VwIAAA== Archived-At: Subject: [sipcore] Comments on draft-ietf-sipcore-refer-explicit-subscription-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, 23 Jan 2015 12:26:38 -0000 Hi, Some comments on draft-ietf-sipcore-refer-explicit-subscription-00: ----------- Q1 (General): Is there a reason why we need to limit the mechanism to INVITE-established = dialogs? (I do agree that, today, there are probably no other dialog types in which = we would send REFER.) ----------- Q2 (General): Assume a UA sends an INVITE without including "NOTIFY" in the Allow header = field. The UA does, however, include "REFER". Assuming that the scope of Allow is for the given dialog (there is a separa= te thread on the scope of Allow), doesn't that mean that the UA, while it w= ill accept REFERs, will not create implicit subscriptions within the dialog= ? Would we need to say something about that? ----------- Q3 (General) The draft talks about mandating support and usage of the mechanisms by inse= rting the associated option-tags in the REFER Require header field. But, the draft doesn't talk about the dialog creating request (i.e. the INV= ITE). I think it would be good to say that the mechanism can be used even if the = INVITE-sender did not indicate support (using the Supported header field). (Otherwise we can only use the mechanism when the INVITE-sender also suppor= ts it, which reduces the applicability very much.) ----------- Q4 (Section 3.1): The text says: "If the recipient of the REFER accepts the request, it will begin managing the 'refer' event state described in RFC 3515, and w= ill provide a URI that will reach an event server that will servi= ce subscriptions to that state." Assuming that the subscription-event state terminates already when the REFE= R response is sent, is there really a need for the REFER-receiver to return= a URI?=20 Perhaps we could say that NOT providing a URI (or, providing a URI with a "= null" value) means that the associated subscription-event state is terminat= ed. Of course, the REFER-sender could have included "Require: nosub" in the REF= ER request - IF it would have known that there will be no need for a subscr= iption. But, it may not always know. ----------- Q5 (Section 4.3 and/or 4.6): Would it be good to explicitly clarify that the REFER-receiver, if acceptin= g usage of the mechanism and providing a subscription-URI pointing to itsel= f, MUST NOT send a NOTIFY until it has received the associated SUBSCRIBE? It may be obvious to the SIPCORE participants, but I think it would be a go= od clarification for unexperienced readers :) ----------- Regards, Christer From nobody Mon Jan 26 04:55:15 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 620281A8A56 for ; Mon, 26 Jan 2015 04:55:12 -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 zJOvPuo-QPfN for ; Mon, 26 Jan 2015 04:55:10 -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 136E11A8A70 for ; Mon, 26 Jan 2015 04:55:09 -0800 (PST) X-AuditID: c1b4fb30-f79106d000001184-26-54c6392bf16f Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id DA.44.04484.B2936C45; Mon, 26 Jan 2015 13:55:08 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.154]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0195.001; Mon, 26 Jan 2015 13:55:07 +0100 From: Ivo Sedlacek To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-refer-explicit-subscription-00 Thread-Index: AdA5YDMZRkvdtlS/T7eX27kn1JhplQ== Date: Mon, 26 Jan 2015 12:55:06 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127F3799@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.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvja6O5bEQg8m/WCyuzWlks/j6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJXxet005oJnHBUvX3QxNjBOYu9i5OSQEDCR OHbqGAuELSZx4d56NhBbSOAIo8TBCdldjFxA9hJGiZlLO8ESbAJ6EhO3HGEFsUUEAiUWTloC 1iwsECRx5MRrFoh4uMTXvfugavQkFl5sArNZBFQlbp1ewwRi8wr4SmybeIkRxGYUkJW4+qcX zGYWEJe49WQ+E8RBAhJL9pxnhrBFJV4+/scKYStKtD9tgKrXkViw+xMbhK0tsWzha2aI+YIS J2c+YZnAKDwLydhZSFpmIWmZhaRlASPLKkbR4tTipNx0IyO91KLM5OLi/Dy9vNSSTYzAsD+4 5bfBDsaXzx0PMQpwMCrx8G5YezREiDWxrLgy9xCjNAeLkjivnfGhECGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2MWQuSRe4feWZVc/678Wenqzl7bl5YsKClaO3fF1VKtb//pZrqXTI8+fDf nwspr942frz3gqHr8XPpatEjtg6Ga/any6b/dC1gvnUn8mVJrNjcdUyHX3nue6OvpeGSpMwQ rLojwlbU1redZcO8L9yzOO53zDlQGTFp8asXeZf3zOYNsC6/82JdnBJLcUaioRZzUXEiABXl QeVcAgAA Archived-At: Subject: [sipcore] Comments on draft-ietf-sipcore-refer-explicit-subscription-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: Mon, 26 Jan 2015 12:55:12 -0000 Hello, The new version seems nearly OK. I still have one comment, but the rest is = fine. COMMENT: [I-D.roach-sipcore-6665-clarification] states what the UA does when the UA = becomes a notifier. In particular case of REFER, this applies only when the= UA accepts a REFER creating an implicit subscription. Moreover, the text of 3rd paragraph of section 3 duplicates too much of the= details given by [I-D.roach-sipcore-6665-clarification]. Thus, I suggest that we change the following statement of section 3: ----------------- A UA that will accept a REFER request needs to include a GRUU in the Contact header field of all dialog-forming and target-refresh methods (such as INVITE) [I-D.roach-sipcore-6665-clarification]. =20 ----------------- to: ----------------- A UA that will become a notifier (e.g. by accepting an REFER request tha= t creates a subscription) needs to include a GRUU in the Contact header field of dialog-forming and target-refresh methods as spe= cified in [I-D.roach-sipcore-6665-clarification]. =20 ----------------- Kind regards Ivo Sedlacek From nobody Mon Jan 26 11:07:20 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E595C1ACEA5 for ; Mon, 26 Jan 2015 11:07:17 -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 wbqM9S5_glHy for ; Mon, 26 Jan 2015 11:07:15 -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 235A01ACEA0 for ; Mon, 26 Jan 2015 11:07:15 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t0QJ7Bi9009217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Jan 2015 13:07:11 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54C6905A.3050102@nostrum.com> Date: Mon, 26 Jan 2015 13:07:06 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Christer Holmberg , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D679CD5@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D679CD5@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-refer-explicit-subscription-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: Mon, 26 Jan 2015 19:07:18 -0000 On 1/23/15 6:26 AM, Christer Holmberg wrote: > Hi, > > Some comments on draft-ietf-sipcore-refer-explicit-subscription-00: > > ----------- > > Q1 (General): > > Is there a reason why we need to limit the mechanism to INVITE-established dialogs? > > (I do agree that, today, there are probably no other dialog types in which we would send REFER.) No, and the existing language wasn't intended to create that limit - instead it was pointing out the applicability to INVITE-established dialogs. I'll change the wording in the next version to make it clear that this applies to dialog reuse in general. > > > ----------- > > > Q2 (General): > > Assume a UA sends an INVITE without including "NOTIFY" in the Allow header field. The UA does, however, include "REFER". > > Assuming that the scope of Allow is for the given dialog (there is a separate thread on the scope of Allow), doesn't that mean that the UA, while it will accept REFERs, will not create implicit subscriptions within the dialog? > > Would we need to say something about that? No, I don't think so. Let's leave that discussion to something that normatively refines the definition of Allow. In that context, we can talk about whether you draw the conclusion you suggest. (I don't think you can - Allow says "you can send me this method", so listing REFER, but not NOTIFY, does not say anything about whether the UA will or will not _generate_ NOTIFY requests.) Again, I don't think this document is the place to talk about such things. > > > ----------- > > > Q3 (General) > > The draft talks about mandating support and usage of the mechanisms by inserting the associated option-tags in the REFER Require header field. > > But, the draft doesn't talk about the dialog creating request (i.e. the INVITE). > > I think it would be good to say that the mechanism can be used even if the INVITE-sender did not indicate support (using the Supported header field). > > (Otherwise we can only use the mechanism when the INVITE-sender also supports it, which reduces the applicability very much.) I'm confused about what's motivating your Otherwise. RFC3261 in no way restricts the use of Require to only talk about things that have previously been signaled as Supported? I don't have a problem reminding the reader that it's ok to do so. (But only with plain prose - not with requirements language since that would repeat requirements from 3261. > > > ----------- > > > Q4 (Section 3.1): > > The text says: > > "If the recipient of the REFER accepts the request, it will begin > managing the 'refer' event state described in RFC 3515, and will > provide a URI that will reach an event server that will service > subscriptions to that state." > > Assuming that the subscription-event state terminates already when the REFER response is sent, is there really a need for the REFER-receiver to return a URI? > > Perhaps we could say that NOT providing a URI (or, providing a URI with a "null" value) means that the associated subscription-event state is terminated. > > Of course, the REFER-sender could have included "Require: nosub" in the REFER request - IF it would have known that there will be no need for a subscription. But, it may not always know. No, I don't think this attempt at an optimization is a good idea. There can (and usually should) be more information in that final NOTIFY than just the fact that the subscription event state is terminated. To optimize out the conduit for providing that NOTIFY, you'd have to build a way to carry all the information it might have contained. > > > ----------- > > > Q5 (Section 4.3 and/or 4.6): > > Would it be good to explicitly clarify that the REFER-receiver, if accepting usage of the mechanism and providing a subscription-URI pointing to itself, MUST NOT send a NOTIFY until it has received the associated SUBSCRIBE? > > It may be obvious to the SIPCORE participants, but I think it would be a good clarification for unexperienced readers :) I can call this out, but someone would have to invent a lot to get this wrong. Where would they send that NOTIFY _to_? We've already said we're not sending as part of the association the REFER occurred on. > > > ----------- > > > Regards, > > Christer From nobody Mon Jan 26 12:01:33 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197DD1B29B9 for ; Mon, 26 Jan 2015 12:01:30 -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 imvCtQHVJh_q for ; Mon, 26 Jan 2015 12:01: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 BBD361AD377 for ; Mon, 26 Jan 2015 12:01:24 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t0QK1K2Y013751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Jan 2015 14:01:20 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54C69D0C.8070909@nostrum.com> Date: Mon, 26 Jan 2015 14:01:16 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ivo Sedlacek , "sipcore@ietf.org" References: <39B5E4D390E9BD4890E2B31079006101127F3799@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127F3799@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-refer-explicit-subscription-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: Mon, 26 Jan 2015 20:01:30 -0000 Ivo - Just to be sure, this seems to be a comment on refer-clarifications, not (as the subject says) explicit-subscription? On 1/26/15 6:55 AM, Ivo Sedlacek wrote: > Hello, > > The new version seems nearly OK. I still have one comment, but the rest is fine. > > COMMENT: > > [I-D.roach-sipcore-6665-clarification] states what the UA does when the UA becomes a notifier. In particular case of REFER, this applies only when the UA accepts a REFER creating an implicit subscription. > > Moreover, the text of 3rd paragraph of section 3 duplicates too much of the details given by [I-D.roach-sipcore-6665-clarification]. > > Thus, I suggest that we change the following statement of section 3: > ----------------- > A UA that will accept a REFER request needs to include a GRUU in the > Contact header field of all dialog-forming and target-refresh methods > (such as INVITE) [I-D.roach-sipcore-6665-clarification]. > ----------------- > to: > ----------------- > A UA that will become a notifier (e.g. by accepting an REFER request that creates a subscription) needs to include a GRUU in the > Contact header field of dialog-forming and target-refresh methods as specified in [I-D.roach-sipcore-6665-clarification]. No, this change is not ok, and the current text is something we ground on quite a lot - this proposal risks taking us right back into that argument. Remember that the document is written from the context of what is currently standardized, and as currently standardized the sender of the REFER has no way to know if the REFER will create a subscription, so it must include a GRUU. The text we added to the introduction acknowledges that 3gpp has a private solution that won't create subscriptions as long as they don't end up talking to a non-3gpp endpoint, but it _can_ if a non-3gpp endpoint is involved. Again, without extension, a standard endpoint has to assume that it can become a notifier, and has to provide a GRUU. RjS > ----------------- > > Kind regards > > Ivo Sedlacek From nobody Mon Jan 26 12:18:53 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590751B29D3 for ; Mon, 26 Jan 2015 12:18:44 -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 3upBDJZZecyK for ; Mon, 26 Jan 2015 12:18:42 -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 6D4421B29B8 for ; Mon, 26 Jan 2015 12:18:29 -0800 (PST) Received: from unnumerable.local (pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t0QKIPE7015224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Jan 2015 14:18:25 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-96-107-228.dllstx.fios.verizon.net [71.96.107.228] claimed to be unnumerable.local Message-ID: <54C6A10C.4050906@nostrum.com> Date: Mon, 26 Jan 2015 14:18:20 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Ivo Sedlacek , "sipcore@ietf.org" References: <39B5E4D390E9BD4890E2B31079006101127F3799@ESESSMB301.ericsson.se> <54C69D0C.8070909@nostrum.com> In-Reply-To: <54C69D0C.8070909@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-refer-explicit-subscription-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: Mon, 26 Jan 2015 20:18:44 -0000 And I fell into one of the old traps in that old argument. Correction inline. On 1/26/15 2:01 PM, Robert Sparks wrote: > Ivo - > > Just to be sure, this seems to be a comment on refer-clarifications, > not (as the subject says) explicit-subscription? > > On 1/26/15 6:55 AM, Ivo Sedlacek wrote: >> Hello, >> >> The new version seems nearly OK. I still have one comment, but the >> rest is fine. >> >> COMMENT: >> >> [I-D.roach-sipcore-6665-clarification] states what the UA does when >> the UA becomes a notifier. In particular case of REFER, this applies >> only when the UA accepts a REFER creating an implicit subscription. >> >> Moreover, the text of 3rd paragraph of section 3 duplicates too much >> of the details given by [I-D.roach-sipcore-6665-clarification]. >> >> Thus, I suggest that we change the following statement of section 3: >> ----------------- >> A UA that will accept a REFER request needs to include a GRUU in the >> Contact header field of all dialog-forming and target-refresh >> methods >> (such as INVITE) [I-D.roach-sipcore-6665-clarification]. >> ----------------- >> to: >> ----------------- >> A UA that will become a notifier (e.g. by accepting an REFER >> request that creates a subscription) needs to include a GRUU in the >> Contact header field of dialog-forming and target-refresh methods >> as specified in [I-D.roach-sipcore-6665-clarification]. > No, this change is not ok, and the current text is something we ground > on quite a lot - this proposal risks taking us right back into that > argument. > > Remember that the document is written from the context of what is > currently standardized, and as currently standardized the sender of > the REFER has no way to know if the REFER will create a subscription, > so it must include a GRUU. Sorry - that put the argument on the wrong foot, and I apologize again for falling into the older trap. The issue, rather, is that if an agent might accept a REFER that would create a subscription at some point in the future, then it needs to include a GRUU as the contact of all of its dialog forming requests. Given that, the issue with your above text is in the "will become" as opposed to "might become", because in general, it can't know. (As we've discussed, with the 3gpp behavior, you can end up accepting an in-dialog refer becoming a notifier if you are working with a non-3gpp endpoint.) I could accept the sentence you propose if we change "will become" to "can possibly become". > > The text we added to the introduction acknowledges that 3gpp has a > private solution that won't create subscriptions as long as they don't > end up talking to a non-3gpp endpoint, but it _can_ if a non-3gpp > endpoint is involved. Again, without extension, a standard endpoint > has to assume that it can become a notifier, and has to provide a GRUU. > > RjS >> ----------------- >> >> Kind regards >> >> Ivo Sedlacek > From nobody Mon Jan 26 12:49:41 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80A91AD49F for ; Mon, 26 Jan 2015 12:49:37 -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 G6m4RjWERmil for ; Mon, 26 Jan 2015 12:49:36 -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 14A351A6FDB for ; Mon, 26 Jan 2015 12:49:36 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t0QKnWwa017830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2015 14:49:32 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local Message-ID: <54C6A85B.5030209@nostrum.com> Date: Mon, 26 Jan 2015 14:49:31 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Robert Sparks , Ivo Sedlacek , "sipcore@ietf.org" References: <39B5E4D390E9BD4890E2B31079006101127F3799@ESESSMB301.ericsson.se> <54C69D0C.8070909@nostrum.com> <54C6A10C.4050906@nostrum.com> In-Reply-To: <54C6A10C.4050906@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-refer-explicit-subscription-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: Mon, 26 Jan 2015 20:49:38 -0000 On 1/26/15 14:18, Robert Sparks wrote: > And I fell into one of the old traps in that old argument. Correction > inline. > > On 1/26/15 2:01 PM, Robert Sparks wrote: >> Ivo - >> >> Just to be sure, this seems to be a comment on refer-clarifications, >> not (as the subject says) explicit-subscription? >> >> On 1/26/15 6:55 AM, Ivo Sedlacek wrote: >>> Hello, >>> >>> The new version seems nearly OK. I still have one comment, but the >>> rest is fine. >>> >>> COMMENT: >>> >>> [I-D.roach-sipcore-6665-clarification] states what the UA does when >>> the UA becomes a notifier. In particular case of REFER, this applies >>> only when the UA accepts a REFER creating an implicit subscription. >>> >>> Moreover, the text of 3rd paragraph of section 3 duplicates too much >>> of the details given by [I-D.roach-sipcore-6665-clarification]. >>> >>> Thus, I suggest that we change the following statement of section 3: >>> ----------------- >>> A UA that will accept a REFER request needs to include a GRUU in >>> the >>> Contact header field of all dialog-forming and target-refresh >>> methods >>> (such as INVITE) [I-D.roach-sipcore-6665-clarification]. >>> ----------------- >>> to: >>> ----------------- >>> A UA that will become a notifier (e.g. by accepting an REFER >>> request that creates a subscription) needs to include a GRUU in the >>> Contact header field of dialog-forming and target-refresh >>> methods as specified in [I-D.roach-sipcore-6665-clarification]. >> No, this change is not ok, and the current text is something we >> ground on quite a lot - this proposal risks taking us right back into >> that argument. >> >> Remember that the document is written from the context of what is >> currently standardized, and as currently standardized the sender of >> the REFER has no way to know if the REFER will create a subscription, >> so it must include a GRUU. > Sorry - that put the argument on the wrong foot, and I apologize again > for falling into the older trap. > > The issue, rather, is that if an agent might accept a REFER that would > create a subscription at some point in the future, then it needs to > include a GRUU as the contact of all of its dialog forming requests. > > Given that, the issue with your above text is in the "will become" as > opposed to "might become", because in general, it can't know. > (As we've discussed, with the 3gpp behavior, you can end up accepting > an in-dialog refer becoming a notifier if you are working with a > non-3gpp endpoint.) > > I could accept the sentence you propose if we change "will become" to > "can possibly become". I think that specific change is fine, although we seem to be splitting some pretty fine hairs here, and harming clarity in the process. On the other hand, removing the "such as INVITE" phrase seems highly questionable -- I thought this was obvious in RFC 6665, but we later learned that people didn't fully connect the dots. It would seem the height of folly to repeat this specific mistake. I believe the following text addresses the issue that Ivo has raised without any unnecessary editorial rejiggering: "A UA that might possibly become a notifier (e.g. by accepting a REFER request that creates a subscription) needs to include a GRUU in the Contact header field of dialog-forming and target-refresh methods (such as INVITE) [I-D.roach-sipcore-6665-clarification]." /a From nobody Mon Jan 26 23:47:38 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B4B1B2BC1 for ; Mon, 26 Jan 2015 23:47:36 -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 Tj3cXXaL54bw for ; Mon, 26 Jan 2015 23:47:34 -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 BF6711B2BD0 for ; Mon, 26 Jan 2015 23:47:15 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-76-54c742812b22 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 42.5F.04231.18247C45; Tue, 27 Jan 2015 08:47:13 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0195.001; Tue, 27 Jan 2015 08:47:13 +0100 From: Christer Holmberg To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: Comments on draft-ietf-sipcore-refer-explicit-subscription-00 Thread-Index: AQHQOZtLtaWrHk3HlEKIqclN2qeReZzTk1fA Date: Tue, 27 Jan 2015 07:47:13 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D67F93E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D679CD5@ESESSMB209.ericsson.se> <54C6905A.3050102@nostrum.com> In-Reply-To: <54C6905A.3050102@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+JvjW6j0/EQg2nLzSyuzWlks/j6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJUxfc5Z5oKTahXb3yxlaWCcIdfFyMkhIWAi 8ffRJFYIW0ziwr31bF2MXBxCAkcYJb4/7gZLCAksZpTY+CWvi5GDg03AQqL7nzZIWEQgUGLh pCUsILawgJfEvdY/7CAlIgLeEpMfZUKUGEk8fbQFLMwioCox7SbYVl4BX4kfVzqYIIbnSUx5 280GYnMKaEs8e7gfbCkj0DXfT60Bq2EWEJe49WQ+E8SVAhJL9pxnhrBFJV4+/scKMl5CQEli 2tY0iHIdiQW7P7FB2NoSyxa+ZoZYKyhxcuYTlgmMorOQTJ2FpGUWkpZZSFoWMLKsYhQtTi0u zk03MtZLLcpMLi7Oz9PLSy3ZxAiMj4NbfuvuYFz92vEQowAHoxIPr8H/YyFCrIllxZW5hxil OViUxHntjA+FCAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamC0cHz/iO3wtis1Bg1fVq3MS/ZU N1LJ3sJ+pGfqYq+lUYHnRJe63+qME41/tNLNTPDpw/fzs2/OOcT1uOOArv/Bj7eEPqSlnHez Df/MqqPdx2r+JGCvc82BJ+/seIqnf5l3fX2mIpvL4dXR/GctE06uurRIdJ2x4Cpl89Zlc7L+ dj2Uu1K+RCRciaU4I9FQi7moOBEASCYajHACAAA= Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-refer-explicit-subscription-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: Tue, 27 Jan 2015 07:47:36 -0000 Hi, Q1 (General): >> Is there a reason why we need to limit the mechanism to INVITE-establish= ed dialogs? >> >> (I do agree that, today, there are probably no other dialog types in=20 >> which we would send REFER.) > No, and the existing language wasn't intended to create that limit - inst= ead it was pointing out the applicability to INVITE-established dialogs. > I'll change the wording in the next version to make it clear that this ap= plies to dialog reuse in general. Thanks. ----------- Q2 (General): >> Assume a UA sends an INVITE without including "NOTIFY" in the Allow head= er field. The UA does, however, include "REFER". >> >> Assuming that the scope of Allow is for the given dialog (there is a sep= arate thread on the scope of Allow), doesn't that mean that the UA, while i= t will accept REFERs, will not create implicit subscriptions within the dia= log? >> >> Would we need to say something about that? > > No, I don't think so. Let's leave that discussion to something that=20 > normatively refines the definition of Allow. > > In that context, we can talk about whether you draw the conclusion you=20 > suggest. (I don't think you can - Allow says "you can send me this=20 > method", so listing REFER, but not NOTIFY, does not say anything about=20 > whether the UA will or will not _generate_ NOTIFY requests.) > > Again, I don't think this document is the place to talk about such things= . Fair enough. ----------- Q3 (General) >> The draft talks about mandating support and usage of the mechanisms by i= nserting the associated option-tags in the REFER Require header field. >> >> But, the draft doesn't talk about the dialog creating request (i.e. the = INVITE). >> >> I think it would be good to say that the mechanism can be used even if t= he INVITE-sender did not indicate support (using the Supported header field= ). >> >> (Otherwise we can only use the mechanism when the INVITE-sender also sup= ports it, which reduces the applicability very much.) > > I'm confused about what's motivating your Otherwise. RFC3261 in no way=20 > restricts the use of Require to only talk about things that have=20 > previously been signaled as Supported? > > I don't have a problem reminding the reader that it's ok to do so. (But=20 > only with plain prose - not with requirements language since that would=20 > repeat requirements from 3261. It could be a short note. (I got this question from some implementers, so for that reason I think it = would be useful to clarify it.) ----------- Q4 (Section 3.1): >> The text says: >> >> "If the recipient of the REFER accepts the request, it will begin >> managing the 'refer' event state described in RFC 3515, a= nd will >> provide a URI that will reach an event server that will s= ervice >> subscriptions to that state." >> >> Assuming that the subscription-event state terminates already when the R= EFER response is sent, is there really a need for the REFER-receiver to ret= urn a URI? >> >> Perhaps we could say that NOT providing a URI (or, providing a URI with = a "null" value) means that the associated subscription-event state is termi= nated. >> >> Of course, the REFER-sender could have included "Require: nosub" in the = REFER request - IF it would have known that there will be no need for a sub= scription. But, it may not always know. > > No, I don't think this attempt at an optimization is a good idea. There=20 > can (and usually should) be more information in that final NOTIFY than=20 > just the fact that the subscription event state is terminated. To=20 > optimize out the conduit for providing that NOTIFY, you'd have to build=20 > a way to carry all the information it might have contained. Fair enough. (I did have a use-case in mind, but after some further thinking I think "Re= quire: nosub" can be used for that.) ----------- Q5 (Section 4.3 and/or 4.6): >> Would it be good to explicitly clarify that the REFER-receiver, if accep= ting usage of the mechanism and providing a subscription-URI pointing to it= self, MUST NOT send a NOTIFY until it has received the associated SUBSCRIBE= ? >> >> It may be obvious to the SIPCORE participants, but I think it would be a= good clarification for unexperienced readers :) > > I can call this out, but someone would have to invent a lot to get this=20 > wrong. Where would they send that NOTIFY _to_? We've already said we're=20 > not sending as part of the association the REFER occurred on. After further thinking, I agree with you, and I don't think we need to say = anything. So, I withdraw my comment. (The important thing is that, if the REFER-receiver accepts the mechanism, = a NOTIFY is not sent based on the REFER, but the text already says that.) Regards, Christer From nobody Tue Jan 27 00:05:53 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5AB1B2BBD for ; Tue, 27 Jan 2015 00:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZxNVvcpW2Pc for ; Tue, 27 Jan 2015 00:05:50 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0CFC1B2BBC for ; Tue, 27 Jan 2015 00:05:49 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-b5-54c746dbf414 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E6.13.04076.AD647C45; Tue, 27 Jan 2015 09:05:47 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.154]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0195.001; Tue, 27 Jan 2015 09:05:46 +0100 From: Ivo Sedlacek To: Adam Roach , Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-refer-explicit-subscription-00 Thread-Index: AQHQOaLcU/6xvLN2Z0+55Fd/LMv9MZzSxmoAgAAIt4CAAMquYA== Date: Tue, 27 Jan 2015 08:05:46 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127F42C6@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101127F3799@ESESSMB301.ericsson.se> <54C69D0C.8070909@nostrum.com> <54C6A10C.4050906@nostrum.com> <54C6A85B.5030209@nostrum.com> In-Reply-To: <54C6A85B.5030209@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.20] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvje5tt+MhBvNO8Fvs+buI3eLanEY2 i68/NrE5MHssWfKTyWPWzicsAUxRXDYpqTmZZalF+nYJXBn3j29gLdjFWrF9WUYD4wrWLkZO DgkBE4nnX74xQdhiEhfurWfrYuTiEBI4wijxYOlaVghnCaPEjFkHmEGq2AT0JCZuOQLWLSJQ IHHj+QRGEFtYIEyiY8MWRoh4uMTXvfuAajiAbCeJfdNTQUwWAVWJW3P8QCp4BXwl2l9fYYYY v45RouPhIjaQBKeAtsTmaRA2o4CsxNU/vWAjmQXEJW49mQ91qIDEkj3nmSFsUYmXj/9BPaMo cXX6ciaQXcwCmhLrd+lDtCpKTOl+yA6xV1Di5MwnLBMYRWchmToLoWMWko5ZSDoWMLKsYhQt Ti0uzk03MtJLLcpMLi7Oz9PLSy3ZxAiMlYNbflvtYDz43PEQowAHoxIPr8H/YyFCrIllxZW5 hxilOViUxHntjA+FCAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDsDWzZVL4gMvNxXcNUpRWl r7q7xMvcGMTFo+sXna/3MDnXIxaed38b2/PY+W9ZulzYIid3p/bJpq5x5VR1yGQs1FWzu+7i V5he+1Vjnkrl0xWvDk/T8eA8+zBlxWyXr56BGtsPCLAIuTqeOt0tpW1Yn74ycGvizvUHYn7J qMV9TFrAwq/zXImlOCPRUIu5qDgRAMlpxZ12AgAA Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-refer-explicit-subscription-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: Tue, 27 Jan 2015 08:05:51 -0000 SGVsbG8sDQoNCj4gSSBiZWxpZXZlIHRoZSBmb2xsb3dpbmcgdGV4dCBhZGRyZXNzZXMgdGhlIGlz c3VlIHRoYXQgSXZvIGhhcyByYWlzZWQgd2l0aG91dCANCj4gYW55IHVubmVjZXNzYXJ5IGVkaXRv cmlhbCByZWppZ2dlcmluZzogIkEgVUEgdGhhdCBtaWdodCBwb3NzaWJseSBiZWNvbWUgYSANCj4g bm90aWZpZXIgKGUuZy4gYnkgYWNjZXB0aW5nIGEgUkVGRVIgcmVxdWVzdCB0aGF0IGNyZWF0ZXMg YQ0KPiBzdWJzY3JpcHRpb24pIG5lZWRzIHRvIGluY2x1ZGUgYSBHUlVVIGluIHRoZSBDb250YWN0 IGhlYWRlciBmaWVsZCBvZiANCj4gZGlhbG9nLWZvcm1pbmcgYW5kIHRhcmdldC1yZWZyZXNoIG1l dGhvZHMgKHN1Y2ggYXMgSU5WSVRFKSBbSS1ELnJvYWNoLXNpcGNvcmUtNjY2NS1jbGFyaWZpY2F0 aW9uXS4iDQoNCldvcmtzIGZvciBtZS4gVGhhbmtzIGZvciB0YWtpbmcgbXkgY29tbWVudHMgaW50 byBjb25zaWRlcmF0aW9uLg0KDQpLaW5kIHJlZ2FyZHMNCg0KSXZvIFNlZGxhY2VrDQoNCg0K From nobody Wed Jan 28 03:16:44 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81791A1A4C for ; Wed, 28 Jan 2015 03:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zdZYkI9u8ryp for ; Wed, 28 Jan 2015 03:16: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 8D0921A1A4B for ; Wed, 28 Jan 2015 03:16:39 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-f3-54c8c515c8db Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CE.59.24955.515C8C45; Wed, 28 Jan 2015 12:16:37 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.22]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0195.001; Wed, 28 Jan 2015 12:16:37 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: WG adoption of draft-6665-clarifications? Thread-Index: AdA668zStxqWwPatTX2XwZhxctLBmw== Date: Wed, 28 Jan 2015 11:16:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D683434@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D683434ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvja7o0RMhBv/3mVt8/bGJzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGQ0/mhkL9klXPN7+m6WBsU2ii5GTQ0LARGLL3zZGCFtM4sK9 9WxdjFwcQgJHGCXWHOhjA0kICSxmlHj3W6WLkYODTcBCovufNkhYREBTYvm3rewgtrCAkcTp LfPYIeLmEqe3P2IGKRcR0JNonc8FEmYRUJU4enctK0iYV8BX4ue3KJAwI9DW76fWMIHYzALi EreezGeCuEZAYsme88wQtqjEy8f/wFolBJQkpm1NgyjPl1j2YSkriM0rIChxcuYTlgmMQrOQ TJqFpGwWkjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ilG0OLU4KTfdyFgvtSgzubg4 P08vL7VkEyMwFg5u+a26g/HyG8dDjAIcjEo8vBsCToQIsSaWFVfmHmKU5mBREue1Mz4UIiSQ nliSmp2aWpBaFF9UmpNafIiRiYNTqoFR59Ss/vO6y70VcvqOzXM30nw7a/I2joPm+z56TvkV sG6nzMuajOntcnrHhGMXnf2b+ffCIun3P8IF/nZ7HN/tm94lfbcx9LaB5LvXE+xydT6Yn/t3 fLGIVLtmxdZd7e9F3E9q/l6otS5LZfHk8JY1vZKFn+ZGRWRXTlvz+92LqSIeKxv2HcgxVGIp zkg01GIuKk4EAIkrmmJmAgAA Archived-At: Subject: [sipcore] WG adoption of draft-6665-clarifications? 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, 28 Jan 2015 11:16:42 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D683434ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In Honolulu, when the 6665-clarification-, refer-clarification- and refer-e= xplicit-subscription drafts were discussed, I suggested that we should WG a= dopt all of them. They are so related, that I think we need to work on them in parallel, and = they should also go to WGLC at the same time. So, while there may still be comments on 6665-clarification, I think we sho= uld WG adopt it, and try to move it to WGLC as soon as possible, together w= ith the two other drafts. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D683434ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In Honolulu, when the 6665-clarification-, refer-cla= rification- and refer-explicit-subscription drafts were discussed, I sugges= ted that we should WG adopt all of them.

 

They are so related, that I think we need to work on= them in parallel, and they should also go to WGLC at the same time.

 

So, while there may still be comments on 6665-clarif= ication, I think we should WG adopt it, and try to move it to WGLC as soon = as possible, together with the two other drafts.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D683434ESESSMB209erics_-- From nobody Wed Jan 28 03:18:20 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BA71A0AF7 for ; Wed, 28 Jan 2015 03:18:18 -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 qQeC5ap28Vra for ; Wed, 28 Jan 2015 03:18:16 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9461A039F for ; Wed, 28 Jan 2015 03:18:16 -0800 (PST) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs212cnc.rim.net with ESMTP/TLS/AES128-SHA; 28 Jan 2015 06:18:02 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT102CNC.rim.net ([fe80::2066:5d4f:8c45:af55%17]) with mapi id 14.03.0210.002; Wed, 28 Jan 2015 06:18:01 -0500 From: Andrew Allen To: Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] WG adoption of draft-6665-clarifications? Thread-Index: AQHQOuwTvLYNsfMYv0CLsMIIRqh3Hw== Date: Wed, 28 Jan 2015 11:18:00 +0000 Message-ID: <20150128111757.5984402.72369.9738@blackberry.com> References: <7594FB04B1934943A5C02806D1A2204B1D683434@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D683434@ESESSMB209.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_201501281117575984402723699738blackberrycom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] WG adoption of draft-6665-clarifications? 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, 28 Jan 2015 11:18:18 -0000 --_000_201501281117575984402723699738blackberrycom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Sent from my BlackBerry 10 smartphone. From: Christer Holmberg Sent: Wednesday, January 28, 2015 12:16 To: sipcore@ietf.org Subject: [sipcore] WG adoption of draft-6665-clarifications? Hi, In Honolulu, when the 6665-clarification-, refer-clarification- and refer-e= xplicit-subscription drafts were discussed, I suggested that we should WG a= dopt all of them. They are so related, that I think we need to work on them in parallel, and = they should also go to WGLC at the same time. So, while there may still be comments on 6665-clarification, I think we sho= uld WG adopt it, and try to move it to WGLC as soon as possible, together w= ith the two other drafts. Regards, Christer --_000_201501281117575984402723699738blackberrycom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+1

Sent from my BlackBerry 10 smartphone.
From: Christer Holmberg
Sent: Wednesday, January 28, 2015 12:16
To: sipcore@ietf.org
Subject: [sipcore] WG adoption of draft-6665-clarifications?

Hi,

 

In Honolulu, when the 6665-clarification-, refer-cla= rification- and refer-explicit-subscription drafts were discussed, I sugges= ted that we should WG adopt all of them.

 

They are so related, that I think we need to work on= them in parallel, and they should also go to WGLC at the same time.

 

So, while there may still be comments on 6665-clarif= ication, I think we should WG adopt it, and try to move it to WGLC as soon = as possible, together with the two other drafts.

 

Regards,

 

Christer

--_000_201501281117575984402723699738blackberrycom_-- From nobody Fri Jan 30 13:20:50 2015 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC57F1A9144; Fri, 30 Jan 2015 13:20:37 -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 dDR6JH3VN69e; Fri, 30 Jan 2015 13:20:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B1F1A910B; Fri, 30 Jan 2015 13:20:29 -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.10.1.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150130212029.12428.16755.idtracker@ietfa.amsl.com> Date: Fri, 30 Jan 2015 13:20:29 -0800 Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-02.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, 30 Jan 2015 21:20:38 -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-02.txt Pages : 6 Date : 2015-01-30 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-refer-clarifications-02 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/