From nobody Mon Dec 1 01:48:47 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39191A0166 for ; Mon, 1 Dec 2014 01:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNvV3sCKBsWo for ; Mon, 1 Dec 2014 01:48:42 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951C71A0141 for ; Mon, 1 Dec 2014 01:48:42 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sB19mWNF016025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Dec 2014 09:48:32 GMT Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sB19mWvo017365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Dec 2014 10:48:32 +0100 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 1 Dec 2014 10:48:31 +0100 Received: from DEMUMBX003.nsn-intra.net ([169.254.2.85]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 10:48:31 +0100 From: "Leis, Peter (NSN - DE/Munich)" To: ext Christer Holmberg , Ivo Sedlacek , Andrew Allen , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQBeGiwaMk5ORsmEyvUhfkEzOyiJx1Mf8AgABuBICAAINygIAER0LQgAAhKtA= Date: Mon, 1 Dec 2014 09:48:30 +0000 Message-ID: <059F3547244B7F4DB728757635C2DC4B15DB1C4E@DEMUMBX003.nsn-intra.net> References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127A5796@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127A5FFC@ESESSMB301.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D55F0A8@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D55F0A8@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 10169 X-purgate-ID: 151667::1417427312-0000658F-A277C7A1/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/WYb2gqXp68X5rlR2JcZpIXOMmBY Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 09:48:46 -0000 Hi, I support the proposal from Ivo, it caters for existing deployments. Regards Peter -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Christer H= olmberg Sent: Monday, December 01, 2014 8:50 AM To: Ivo Sedlacek; Andrew Allen; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hi, I think the text suggested by Ivo looks good. It makes it clear that [I-D.i= etf-sipcore-refer-explicit-subscription] IS the "pure" protocol mechanism f= or preventing an implicit subscription, while there exists "special environ= ments" where it is dealt with using other means. The only reason these "special environment" use-cases exist to begin with i= s because previously there was no "pure" protocol mechanism for preventing = implicit subscriptions. And, as they have existed for a while already, and = have been implemented, they will not suddenly go away just because we now h= ave [I-D.ietf-sipcore-refer-explicit-subscription]. Neither will they go aw= ay just because we now have drafts clarifying some RFCs.=20 BUT, because we now DO have a "pure" protocol mechanism [I-D.ietf-sipcore-r= efer-explicit-subscription] for preventing implicit subscriptions, I assume= there will be no NEW "special environment" use-cases in future - people WI= LL use [I-D.ietf-sipcore-refer-explicit-subscription] :) Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek Sent: 28. marraskuuta 2014 17:29 To: Ivo Sedlacek; Andrew Allen; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hello, I think Andrew's proposed statement can be replaced by the statement alread= y existing in the draft, i.e. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D If a user agent can be certain that no implicit subscription will be created as a result of sending a REFER request (such as by requiring an extension that disallows any such subscription [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request MAY be sent within an existing dialog. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D and extended as follows: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D If a user agent can be certain that no implicit subscription will be created as a result of sending a REFER request (such as by requiring an extension that disallows any such subscription [I-D.ietf-sipcore-refer-explicit-subscription] >>>or by RFC4488 together= with configuration / application logic in specific environment ensuring t= hat implicit subscription is not created<<<), the REFER request MAY be sent within an existing dialog. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Kind regards Ivo Sedlacek -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek Sent: 28. listopadu 2014 8:38 To: Andrew Allen; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hello, I disagree with proposed statement:=20 "Only=20 when using the explicit subscription mechanism to require that a subscription not be created MAY the REFER request be sent=20 within an existing dialog." There are existing means how the UA can be sure that implicit subscription = will not be created - they rely on media feature tag and RFC4488, but work = neverthless. Therefore, I see the proposed statement as unnecessary restrictive. RFC6665= statement is sufficient. Kind regards Ivo Sedlacek -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew Allen Sent: 28. listopadu 2014 2:04 To: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Robert Thanks for getting the WG version of the draft out. The main issue for me with the draft is the criteria for how the UA knows t= hat it will not end up with an explicit subscription. Currently the draft i= s vague about that. Some deployments don't currently have the potential to create an implicit s= ubscription because of something defined outside of the SIP protocol ensure= s that they only perform a subset of the defined behavior in RFCs 3515, 666= 5 and 4488 i.e. by defining that the UAC always includes refersub=3Dfalse a= nd by defining that the UAS always accepts that request to not create a sub= scription with the only way for a UAC to determine that the UAS will behave= that way is because it (maybe) received a media-feature tag or feature cap= ability indicator that it knows by means outside the SIP protocol (from som= e other SDOs specification or it's a proprietary implementation where a sin= gle vendor defines both ends) that this will be the behavior. I think we should clearly decide whether this fulfils the criteria for a UA= C to determine definitively that no implicit subscription will be created a= nd hence allows the UAC to send the Refer on an existing dialog or not.=20 My own preference is not to have this qualify as a way for a UAC to be cert= ain as this makes SIP protocol behavior dependent on some higher layer appl= ication semantic creating a tight coupling between the application and the = SIP protocol stack making it difficult to reuse off the shelf SIP stacks fo= r you application. It should be a protocol issue (defined in RFCs) not an a= pplication issue as to whether a request is sent on the same or a different= dialog. I am also concerned that this kind of thing makes it more likely that the U= AS in these cases ends up being only a partial implementation of the protoc= ol (e.g. It doesn't even implement receiving a Refer out of dialog and cann= ot send a Notify even if a UAC did not include Refersub =3D false). I think= the discussion we had in Dispatch in Hawaii shows that future interoperabi= lity problems are caused when only partial implementations of the protocol = are done and assumptions about the behavior in perpetuity of the UAC are ma= de. My preference is that refer-clarifications should only allow refer-explicit= -subscription mechanism as a means for UAC to determine that its ok to send= the Refer on an existing dialog and that we make refer-clarifications depe= ndent on refer-explicit-subscription. If you want to send on an existing di= alog then you use the refer-explicit-subscription mechanism and Require nos= ub otherwise you follow the RFC 6665 behavior and if you have a GRUU as the= target then you send outside the existing dialog. That is clear and deter= ministic. So my proposal is to change the following text in section 4 from : If a user agent can be certain that no implicit subscription will be created as a result of sending a REFER request (such as by requiring an extension that disallows any such subscription [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request MAY be sent within an existing dialog. Such a REFER will be constructed with its Contact header field populated with the dialog's Local URI as specified in section 12 of [RFC3261]. To A user agent can be certain that no implicit subscription will be created as a result of sending a REFER request by using the extension in [I-D.ietf-sipcore-refer-explicit-subscription] to=20 require the UAS not to create an implicit subscription. Only=20 when using the explicit subscription mechanism to require that a subscription not be created MAY the REFER request be sent=20 within an existing dialog. Such a REFER will be constructed with=20 its Contact header field populated with the dialog's Local URI as=20 specified in section 12 of [RFC3261]. Andrew -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Friday, November 21, 2014 6:19 PM To: i-d-announce@ietf.org Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.t= xt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : Clarifications for the use of REFER with RFC6665 Authors : Robert Sparks Adam Roach Filename : draft-ietf-sipcore-refer-clarifications-00.txt Pages : 6 Date : 2014-11-21 Abstract: The SIP REFER method relies on the SIP-Specific Event Notification Framework. That framework was revised by RFC6665. This document highlights the implications of the requirement changes in RFC6665, and updates the definition of the REFER method, RFC3515, to clarify and disambiguate the impact of those changes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarifications/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-refer-clarifications-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Dec 1 06:19:11 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1332E1A1BD4 for ; Mon, 1 Dec 2014 06:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsuPHqa6WXGh for ; Mon, 1 Dec 2014 06:19:04 -0800 (PST) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396A71A0115 for ; Mon, 1 Dec 2014 06:19:04 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id bm13so7320244qab.30 for ; Mon, 01 Dec 2014 06:19:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=v1qYb6NwPNaYZ9+WxpCRE6bnnO/bhmRlCx5f9W8k/dw=; b=DmNn2p+T0sDzu0rO9hq8Clw3okHJY8mBrdTdNogd6zWlCUXzhN86OYg5+VAm7+4Wdg O6yYnFnt7nbOzifAFbyIIBXONnx7Ec2rItfw8L2vOv/Bno3JFGTZB29oVi6bzlbcYxkm TrL5nLYvqd7pOfuv43Rb7REoT6rNRBAaJgv6jpBb78Jq6owOJuF6CDtajkTxeQycYINt nof8lNcFsZCdwizQJwNb3jx4294ZBGJafqqOk3wbI04f8kCRbGDpw6744gOe1HruAY1g LICmLTZy4FFm3KlBsHk9ts+XW4gFTSuJDuNOBAjBKJgl0JFoaZ/Ej9icVj43mZTIke+T emPA== X-Gm-Message-State: ALoCoQnS4cPsZyeNDe9orHOonCo2/sG8zIqlGxW7Y7xacfA4EY2P19z3D4A+BOA6FjQWArLjrLI/ X-Received: by 10.140.38.102 with SMTP id s93mr84348968qgs.18.1417443540741; Mon, 01 Dec 2014 06:19:00 -0800 (PST) From: Brett Tate References: <39B5E4D390E9BD4890E2B31079006101127A29FB@ESESSMB301.ericsson.se> <5475504F.3070400@nostrum.com> In-Reply-To: <5475504F.3070400@nostrum.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEgzkc0BWk9xbXBIc7ssa2HwqHocQGiIiNNncwoPnA= Date: Mon, 1 Dec 2014 09:18:59 -0500 Message-ID: To: sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/_4n8QcyNDbumfmF1O7dMuvyBiPo Subject: Re: [sipcore] 503 response with Retry-After header field - request for clarification X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 14:19:06 -0000 > If you send a BYE to the same thing that sent you a 503 > for any other reason, before the Retry-After has expired, > you are violating protocol. Yes; it is a violation of the RFC 3261 section 21.5.4 SHOULD NOT. "A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present." RFC 5390 presents some reasons (directly or indirectly) why you might want to violate the SHOULD NOT. For instance, you might consider the 503 with Retry-After mechanism to be too insecure to trust that you really should not send any requests to a particular server for the next hour, day, or year. Similarly as mentioned within RFC 5390 section 5.2, RFC 3261 is unclear concerning "server" in relation to the scope of the 503. It is unclear about "server" being 1) IP address where sent request, 2) source IP address of received response, and/or 3) something else. And based upon draft-ietf-sipcore-dns-dual-stack's intention to cause trying both IPv4 and IPv6 addresses, I'd love to hear the proposal about how you avoid attempting the same server twice when a 503 is received. Thanks, Brett From nobody Mon Dec 1 06:34:48 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8BD1A1BC2 for ; Mon, 1 Dec 2014 06:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vXOj0vNdBi2D for ; Mon, 1 Dec 2014 06:34:42 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 7559D1A01D6 for ; Mon, 1 Dec 2014 06:34:41 -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 ED1A393C1AF; Mon, 1 Dec 2014 14:34:00 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Olle E. Johansson" In-Reply-To: Date: Mon, 1 Dec 2014 15:34:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <39B5E4D390E9BD4890E2B31079006101127A29FB@ESESSMB301.ericsson.se> <5475504F.3070400@nostrum.com> To: Brett Tate X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/NmBxo19NKkNdkPC2Wpni5Bd0GJ0 Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] 503 response with Retry-After header field - request for clarification X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 14:34:46 -0000 On 01 Dec 2014, at 15:18, Brett Tate wrote: >> If you send a BYE to the same thing that sent you a 503 >> for any other reason, before the Retry-After has expired, >> you are violating protocol. >=20 > Yes; it is a violation of the RFC 3261 section 21.5.4 SHOULD NOT. >=20 > "A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD > attempt to forward the request to an alternate server. It SHOULD NOT > forward any other requests to that server for the duration specified > in the Retry-After header field, if present." >=20 > RFC 5390 presents some reasons (directly or indirectly) why you might = want > to violate the SHOULD NOT. For instance, you might consider the 503 = with > Retry-After mechanism to be too insecure to trust that you really = should > not send any requests to a particular server for the next hour, day, = or > year. >=20 > Similarly as mentioned within RFC 5390 section 5.2, RFC 3261 is = unclear > concerning "server" in relation to the scope of the 503. It is = unclear > about "server" being 1) IP address where sent request, 2) source IP > address of received response, and/or 3) something else. And based = upon > draft-ietf-sipcore-dns-dual-stack's intention to cause trying both = IPv4 > and IPv6 addresses, I'd love to hear the proposal about how you avoid > attempting the same server twice when a 503 is received. Given that with dual stack the IPv4 IP for a given host name may go to = one server, and the IPv6 to another, I think there's a need for clarification here. The IP that sends you the 503 with Retry-After has to be the one blacklisted for a time.=20 We may have to recommend not using one host name for IPs that leads to two different servers. One host name per "server". If one name has both A and AAAA it has to be *one* server with the same transport layer. Would that make it easier? Thank you for pointing this out. We all missed it. /O= From nobody Mon Dec 1 08:08:43 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7FD1A6EEC for ; Mon, 1 Dec 2014 08:08: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 hr5lz89LT2OL for ; Mon, 1 Dec 2014 08:08:33 -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 917A71A0392 for ; Mon, 1 Dec 2014 08:08:32 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-66-547c927e7ba8 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F5.76.04231.E729C745; Mon, 1 Dec 2014 17:08:30 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.89]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0195.001; Mon, 1 Dec 2014 17:08:29 +0100 From: Ivo Sedlacek To: Brett Tate , "sipcore@ietf.org" Thread-Topic: [sipcore] 503 response with Retry-After header field - request for clarification Thread-Index: AQEgzkc0BWk9xbXBIc7ssa2HwqHocQGiIiNNncwoPnCAACuugA== Date: Mon, 1 Dec 2014 16:08:29 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127B36DB@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101127A29FB@ESESSMB301.ericsson.se> <5475504F.3070400@nostrum.com> In-Reply-To: Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+JvjW7dpJoQg0tH5S2a5/9jtPj6YxOb A5PHj9uBHkuW/GQKYIrisklJzcksSy3St0vgyth7dytrwTKhigUbm1gbGF/zdTFyckgImEhs vfaVEcIWk7hwbz0biC0kcIRR4scTgy5GLiB7EaPElRmnmUASbAJ6EhO3HGHtYuTgEBHwlji+ PAUkLCwQL7Gu6woziC0ikCCxe+MqRgjbSWJK/3wwm0VAReL5kfvsIDavgK/E6Xsr2ODmd73Y wwKS4BSwk9iw5jzYLkYBWYmrf3rBmpkFxCVuPZnPBHGogMSSPeeZIWxRiZeP/7FC2IoS7U8b oOp1JBbs/sQGYWtLLFv4mhlisaDEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyilG0OLW4ODfd yFgvtSgzubg4P08vL7VkEyMwSg5u+a27g3H1a8dDjAIcjEo8vAULq0OEWBPLiitzDzFKc7Ao ifMuOjcvWEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj6b0rN2ZKvWFdavBi+4yVahMftPlM 8JpyV3XWD3FuJjZ7/V2ndqQZT7sdYSD8NbzU1WB/Yl25FpfehFPyp5+GX1wuxhmjHvybQei/ WsmjR43bnm9YOk31jEPRLSczntsnMu4efcsXk2Yr9HatWSevwBLR2V9uBfhc+W5s/K9hwfZz glNOspytU2Ipzkg01GIuKk4EAIoE2kZzAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/0Lr1XY69YVYbRD3S1l5pN4-qhL4 Subject: Re: [sipcore] 503 response with Retry-After header field - request for clarification X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 16:08:38 -0000 > It is unclear about "server" being 1) IP address where sent request, 2) s= ource IP address of received response, and/or 3) something else. =20 I thought "server" is: - entire URI (not just IP address and port) in the top Route header field o= f the request, if there is a Route header field in the request; and - entire Request-URI (not just IP address and port) of the request, if ther= e is no Route header field in the request. 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 Brett Tate Sent: 1. prosince 2014 15:19 To: sipcore@ietf.org Subject: Re: [sipcore] 503 response with Retry-After header field - request= for clarification > If you send a BYE to the same thing that sent you a 503 for any other=20 > reason, before the Retry-After has expired, you are violating=20 > protocol. Yes; it is a violation of the RFC 3261 section 21.5.4 SHOULD NOT. "A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attem= pt to forward the request to an alternate server. It SHOULD NOT forward an= y other requests to that server for the duration specified in the Retry-Aft= er header field, if present." RFC 5390 presents some reasons (directly or indirectly) why you might want = to violate the SHOULD NOT. For instance, you might consider the 503 with R= etry-After mechanism to be too insecure to trust that you really should not= send any requests to a particular server for the next hour, day, or year. Similarly as mentioned within RFC 5390 section 5.2, RFC 3261 is unclear con= cerning "server" in relation to the scope of the 503. It is unclear about = "server" being 1) IP address where sent request, 2) source IP address of re= ceived response, and/or 3) something else. And based upon draft-ietf-sipco= re-dns-dual-stack's intention to cause trying both IPv4 and IPv6 addresses,= I'd love to hear the proposal about how you avoid attempting the same serv= er twice when a 503 is received. Thanks, Brett _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Dec 1 09:15:52 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3031A702B for ; Mon, 1 Dec 2014 09:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjNlZUAInpte for ; Mon, 1 Dec 2014 09:15:49 -0800 (PST) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198D71A7011 for ; Mon, 1 Dec 2014 09:15:49 -0800 (PST) Received: by mail-qa0-f47.google.com with SMTP id s7so7361044qap.20 for ; Mon, 01 Dec 2014 09:15:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=w8+t4vryT5X7iHxvn5XI9nmolycV02QGh07PTkfh8HA=; b=T1ztLPOOJy3lqA/if0Jy0KQtsOKzmOg9cAd4akyBIdzLObmFHHs+3CprQ7I+psCm4K aI/G21TvWkVFEWOVdQH2FxYGEzuk2OoDNyb8eDNfDUxC/25WsEWA7qRiyn2XLV92LnN+ I14GA9ymx49+0KNzhNd7MZP4jxvq2NwdTv7TZFBZPRQelrL6lxKrOI0b95HEGFixLzzY TO3PN0n3o+hBJvi1i/1zharNQzku48NYTuuatucEBPW/tGzOAn3FQnqsMvBE2IVS27J9 /lkoLVRwYKCAL9ozqvt5CIGv65EwxWZ6GtAJqVJQGrVffI9JiJ+aDQxz0aEQJZQ8JMPD FSIA== X-Gm-Message-State: ALoCoQnb1GiWJ3iWfU98MZR6Ce+E6jumDAmxMxn0h6gi3iPmD6aWnQsgCIxspQoZEakaDQW/Yhfo X-Received: by 10.140.48.233 with SMTP id o96mr87455628qga.47.1417454148272; Mon, 01 Dec 2014 09:15:48 -0800 (PST) From: Brett Tate References: <39B5E4D390E9BD4890E2B31079006101127A29FB@ESESSMB301.ericsson.se> <5475504F.3070400@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127B36DB@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127B36DB@ESESSMB301.ericsson.se> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEgzkc0BWk9xbXBIc7ssa2HwqHocQGiIiNNAhxFTrIB5BjiqZ2sWYzQ Date: Mon, 1 Dec 2014 12:15:47 -0500 Message-ID: <40a1c444c4b131c7bc99af850e355296@mail.gmail.com> To: Ivo Sedlacek , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/eIFCBtmV1WACQazgA35F9NF0RiU Subject: Re: [sipcore] 503 response with Retry-After header field - request for clarification X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 17:15:51 -0000 Hi, Yes; as mentioned within RFC 5390, "RFC 3261 is unclear on the scope of a 503" and it can lead to unintentional underutilization. RFC 3263 section 4.3 is the main reason why I disagree with attempting to apply the scope to a URI or its hostname. That interpretation would allow advancing upon receiving a 503; however the Retry-After would cause the rest of the list to be skipped. > -----Original Message----- > From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] > Sent: Monday, December 01, 2014 11:08 AM > To: Brett Tate; sipcore@ietf.org > Subject: RE: [sipcore] 503 response with Retry-After header field - request > for clarification > > > It is unclear about "server" being 1) IP address where sent request, 2) > source IP address of received response, and/or 3) something else. > > I thought "server" is: > - entire URI (not just IP address and port) in the top Route header field of > the request, if there is a Route header field in the request; and > - entire Request-URI (not just IP address and port) of the request, if there > is no Route header field in the request. > > Kind regards > > Ivo Sedlacek > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett Tate > Sent: 1. prosince 2014 15:19 > To: sipcore@ietf.org > Subject: Re: [sipcore] 503 response with Retry-After header field - request > for clarification > > > If you send a BYE to the same thing that sent you a 503 for any other > > reason, before the Retry-After has expired, you are violating > > protocol. > > Yes; it is a violation of the RFC 3261 section 21.5.4 SHOULD NOT. > > "A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt > to forward the request to an alternate server. It SHOULD NOT forward any > other requests to that server for the duration specified in the Retry-After > header field, if present." > > RFC 5390 presents some reasons (directly or indirectly) why you might want to > violate the SHOULD NOT. For instance, you might consider the 503 with Retry- > After mechanism to be too insecure to trust that you really should not send > any requests to a particular server for the next hour, day, or year. > > Similarly as mentioned within RFC 5390 section 5.2, RFC 3261 is unclear > concerning "server" in relation to the scope of the 503. It is unclear about > "server" being 1) IP address where sent request, 2) source IP address of > received response, and/or 3) something else. And based upon draft-ietf- > sipcore-dns-dual-stack's intention to cause trying both IPv4 and IPv6 > addresses, I'd love to hear the proposal about how you avoid attempting the > same server twice when a 503 is received. > > Thanks, > Brett > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Dec 1 10:17:38 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A305F1A87BA for ; Mon, 1 Dec 2014 10:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMZ0X1itON5s for ; Mon, 1 Dec 2014 10:17:30 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195451A87D9 for ; Mon, 1 Dec 2014 10:16:55 -0800 (PST) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-03v.sys.comcast.net with comcast id NJFl1p00557bBgG01JGu7U; Mon, 01 Dec 2014 18:16:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-13v.sys.comcast.net with comcast id NJGt1p00K3Ge9ey01JGtiQ; Mon, 01 Dec 2014 18:16:54 +0000 Message-ID: <547CB095.6060306@alum.mit.edu> Date: Mon, 01 Dec 2014 13:16:53 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127A5796@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127A5FFC@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127A5FFC@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1417457814; bh=TqD0/X5vBg6DBnEWFGan96zX2j9x/A9fUPGFsiHzqMg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=wYlHbTvDiC3zl6mbYFSB977GBFNKykqnLpJhlrN5NoTkLpJTf8GHrnIGQLpZ9ZNMl Jxe0WhA3v5lVTS2qLF6c4lIPS2xu6R5VEvyzNZM/m0mJ/Tn8VCWamio+rk+lJlRAfq VeqtE3usuWyIp0eU8fn1pE8/40PpE/JHzTUFAC50bV5y39caSMULmrKwxJu6NqdZrF H5rmtA6nXZxHTa9g82iQNGl+BxCLSgwPKuGGLhskwU7akhYx0QnIrhhpiJt4hDgec7 Zk23OaalN5qbHBaUD5/hsLfeVMktgFAbjyhl1RmW36t9w3IYG/2C2SCah/3+8bK5jX j2vbFAte1j+AQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/cQDxSOz6bUyXSTqimPWmJWrJ8v0 Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 18:17:33 -0000 On 11/28/14 10:28 AM, Ivo Sedlacek wrote: > Hello, > > I think Andrew's proposed statement can be replaced by the statement already existing in the draft, i.e. > ============= > 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. > ============= > and extended as follows: > ============= > If a user agent can be certain that no implicit subscription will be > created as a result of sending a REFER request (such as by requiring > an extension that disallows any such subscription > [I-D.ietf-sipcore-refer-explicit-subscription] >>>or by RFC4488 together with configuration / application logic in specific environment ensuring that implicit subscription is not created<<<), the REFER request > MAY be sent within an existing dialog. > ============= What criteria do you use to be *certain*? Some agreement of compliance to some specification seems to be required. I gather that what you have in mind is that both ends have been verified to conform to particular versions of the IMS specification. Do you ever really know that for certain in the presence of gateways to foreign devices? Thanks, Paul > Kind regards > > Ivo Sedlacek > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo Sedlacek > Sent: 28. listopadu 2014 8:38 > To: Andrew Allen; sipcore@ietf.org > Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt > > Hello, > > I disagree with proposed statement: > > "Only > when using the explicit subscription mechanism to require that > a subscription not be created MAY the REFER request be sent > within an existing dialog." > > There are existing means how the UA can be sure that implicit subscription will not be created - they rely on media feature tag and RFC4488, but work neverthless. > > Therefore, I see the proposed statement as unnecessary restrictive. RFC6665 statement is sufficient. > > Kind regards > > Ivo Sedlacek > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew Allen > Sent: 28. listopadu 2014 2:04 > To: sipcore@ietf.org > Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt > > Robert > > Thanks for getting the WG version of the draft out. > > The main issue for me with the draft is the criteria for how the UA knows that it will not end up with an explicit subscription. Currently the draft is vague about that. > > Some deployments don't currently have the potential to create an implicit subscription because of something defined outside of the SIP protocol ensures that they only perform a subset of the defined behavior in RFCs 3515, 6665 and 4488 i.e. by defining that the UAC always includes refersub=false and by defining that the UAS always accepts that request to not create a subscription with the only way for a UAC to determine that the UAS will behave that way is because it (maybe) received a media-feature tag or feature capability indicator that it knows by means outside the SIP protocol (from some other SDOs specification or it's a proprietary implementation where a single vendor defines both ends) that this will be the behavior. > > I think we should clearly decide whether this fulfils the criteria for a UAC to determine definitively that no implicit subscription will be created and hence allows the UAC to send the Refer on an existing dialog or not. > > My own preference is not to have this qualify as a way for a UAC to be certain as this makes SIP protocol behavior dependent on some higher layer application semantic creating a tight coupling between the application and the SIP protocol stack making it difficult to reuse off the shelf SIP stacks for you application. It should be a protocol issue (defined in RFCs) not an application issue as to whether a request is sent on the same or a different dialog. > > I am also concerned that this kind of thing makes it more likely that the UAS in these cases ends up being only a partial implementation of the protocol (e.g. It doesn't even implement receiving a Refer out of dialog and cannot send a Notify even if a UAC did not include Refersub = false). I think the discussion we had in Dispatch in Hawaii shows that future interoperability problems are caused when only partial implementations of the protocol are done and assumptions about the behavior in perpetuity of the UAC are made. > > My preference is that refer-clarifications should only allow refer-explicit-subscription mechanism as a means for UAC to determine that its ok to send the Refer on an existing dialog and that we make refer-clarifications dependent on refer-explicit-subscription. If you want to send on an existing dialog then you use the refer-explicit-subscription mechanism and Require nosub otherwise you follow the RFC 6665 behavior and if you have a GRUU as the target then you send outside the existing dialog. That is clear and deterministic. > > So my proposal is to change the following text in section 4 from : > > If a user agent can be certain that no implicit subscription will be > created as a result of sending a REFER request (such as by requiring > an extension that disallows any such subscription > [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request > MAY be sent within an existing dialog. Such a REFER will be > constructed with its Contact header field populated with the dialog's > Local URI as specified in section 12 of [RFC3261]. > > To > > A user agent can be certain that no implicit subscription will be > created as a result of sending a REFER request by using the > extension in [I-D.ietf-sipcore-refer-explicit-subscription] to > require the UAS not to create an implicit subscription. Only > when using the explicit subscription mechanism to require that > a subscription not be created MAY the REFER request 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]. > > > Andrew > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Friday, November 21, 2014 6:19 PM > To: i-d-announce@ietf.org > Cc: sipcore@ietf.org > Subject: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. > > Title : Clarifications for the use of REFER with RFC6665 > Authors : Robert Sparks > Adam Roach > Filename : draft-ietf-sipcore-refer-clarifications-00.txt > Pages : 6 > Date : 2014-11-21 > > Abstract: > The SIP REFER method relies on the SIP-Specific Event Notification > Framework. That framework was revised by RFC6665. This document > highlights the implications of the requirement changes in RFC6665, > and updates the definition of the REFER method, RFC3515, to clarify > and disambiguate the impact of those changes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarifications/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sipcore-refer-clarifications-00 > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Mon Dec 1 12:51:07 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D2E1A90C4 for ; Mon, 1 Dec 2014 12:51:05 -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 0SyB0SXYKhBR for ; Mon, 1 Dec 2014 12:51: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 E54DA1A90C0 for ; Mon, 1 Dec 2014 12:51:01 -0800 (PST) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB1Kp1sT010987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 1 Dec 2014 14:51:01 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <547CD4B0.6090308@nostrum.com> Date: Mon, 01 Dec 2014 14:50:56 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127A5796@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127A5FFC@ESESSMB301.ericsson.se> <547CB095.6060306@alum.mit.edu> In-Reply-To: <547CB095.6060306@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/4c1R-ZqkdjG2DuY7OfjBvsBsVFk Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 20:51:05 -0000 On 12/1/14 12:16 PM, Paul Kyzivat wrote: > On 11/28/14 10:28 AM, Ivo Sedlacek wrote: >> Hello, >> >> I think Andrew's proposed statement can be replaced by the statement >> already existing in the draft, i.e. >> ============= >> 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. >> ============= >> and extended as follows: >> ============= >> If a user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request (such as by requiring >> an extension that disallows any such subscription >> [I-D.ietf-sipcore-refer-explicit-subscription] >>>or by RFC4488 >> together with configuration / application logic in specific >> environment ensuring that implicit subscription is not created<<<), >> the REFER request >> MAY be sent within an existing dialog. >> ============= > > What criteria do you use to be *certain*? > > Some agreement of compliance to some specification seems to be required. > > I gather that what you have in mind is that both ends have been > verified to conform to particular versions of the IMS specification. > Do you ever really know that for certain in the presence of gateways > to foreign devices? To amplify this point: What you propose is exactly like saying "You don't have to implement congestion control in your TCP stack if you're only going to use TCP in an environment where the applications have agreed to never cause congestion". And it's not ok for an Internet standard to say things like that, because it won't work with things on the Internet. To _get_ it to work on the Internet, you'd have to signal compliance somehow. > > Thanks, > Paul > >> Kind regards >> >> Ivo Sedlacek >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo >> Sedlacek >> Sent: 28. listopadu 2014 8:38 >> To: Andrew Allen; sipcore@ietf.org >> Subject: Re: [sipcore] I-D Action: >> draft-ietf-sipcore-refer-clarifications-00.txt >> >> Hello, >> >> I disagree with proposed statement: >> >> "Only >> when using the explicit subscription mechanism to require that >> a subscription not be created MAY the REFER request be sent >> within an existing dialog." >> >> There are existing means how the UA can be sure that implicit >> subscription will not be created - they rely on media feature tag and >> RFC4488, but work neverthless. >> >> Therefore, I see the proposed statement as unnecessary restrictive. >> RFC6665 statement is sufficient. >> >> Kind regards >> >> Ivo Sedlacek >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew >> Allen >> Sent: 28. listopadu 2014 2:04 >> To: sipcore@ietf.org >> Subject: Re: [sipcore] I-D Action: >> draft-ietf-sipcore-refer-clarifications-00.txt >> >> Robert >> >> Thanks for getting the WG version of the draft out. >> >> The main issue for me with the draft is the criteria for how the UA >> knows that it will not end up with an explicit subscription. >> Currently the draft is vague about that. >> >> Some deployments don't currently have the potential to create an >> implicit subscription because of something defined outside of the SIP >> protocol ensures that they only perform a subset of the defined >> behavior in RFCs 3515, 6665 and 4488 i.e. by defining that the UAC >> always includes refersub=false and by defining that the UAS always >> accepts that request to not create a subscription with the only way >> for a UAC to determine that the UAS will behave that way is because >> it (maybe) received a media-feature tag or feature capability >> indicator that it knows by means outside the SIP protocol (from some >> other SDOs specification or it's a proprietary implementation where a >> single vendor defines both ends) that this will be the behavior. >> >> I think we should clearly decide whether this fulfils the criteria >> for a UAC to determine definitively that no implicit subscription >> will be created and hence allows the UAC to send the Refer on an >> existing dialog or not. >> >> My own preference is not to have this qualify as a way for a UAC to >> be certain as this makes SIP protocol behavior dependent on some >> higher layer application semantic creating a tight coupling between >> the application and the SIP protocol stack making it difficult to >> reuse off the shelf SIP stacks for you application. It should be a >> protocol issue (defined in RFCs) not an application issue as to >> whether a request is sent on the same or a different dialog. >> >> I am also concerned that this kind of thing makes it more likely that >> the UAS in these cases ends up being only a partial implementation of >> the protocol (e.g. It doesn't even implement receiving a Refer out of >> dialog and cannot send a Notify even if a UAC did not include >> Refersub = false). I think the discussion we had in Dispatch in >> Hawaii shows that future interoperability problems are caused when >> only partial implementations of the protocol are done and assumptions >> about the behavior in perpetuity of the UAC are made. >> >> My preference is that refer-clarifications should only allow >> refer-explicit-subscription mechanism as a means for UAC to determine >> that its ok to send the Refer on an existing dialog and that we make >> refer-clarifications dependent on refer-explicit-subscription. If you >> want to send on an existing dialog then you use the >> refer-explicit-subscription mechanism and Require nosub otherwise you >> follow the RFC 6665 behavior and if you have a GRUU as the target >> then you send outside the existing dialog. That is clear and >> deterministic. >> >> So my proposal is to change the following text in section 4 from : >> >> If a user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request (such as by requiring >> an extension that disallows any such subscription >> [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request >> MAY be sent within an existing dialog. Such a REFER will be >> constructed with its Contact header field populated with the >> dialog's >> Local URI as specified in section 12 of [RFC3261]. >> >> To >> >> A user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request by using the >> extension in [I-D.ietf-sipcore-refer-explicit-subscription] to >> require the UAS not to create an implicit subscription. Only >> when using the explicit subscription mechanism to require that >> a subscription not be created MAY the REFER request 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]. >> >> >> Andrew >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Friday, November 21, 2014 6:19 PM >> To: i-d-announce@ietf.org >> Cc: sipcore@ietf.org >> Subject: [sipcore] I-D Action: >> draft-ietf-sipcore-refer-clarifications-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Session Initiation Protocol Core >> Working Group of the IETF. >> >> Title : Clarifications for the use of REFER with >> RFC6665 >> Authors : Robert Sparks >> Adam Roach >> Filename : draft-ietf-sipcore-refer-clarifications-00.txt >> Pages : 6 >> Date : 2014-11-21 >> >> Abstract: >> The SIP REFER method relies on the SIP-Specific Event Notification >> Framework. That framework was revised by RFC6665. This document >> highlights the implications of the requirement changes in RFC6665, >> and updates the definition of the REFER method, RFC3515, to clarify >> and disambiguate the impact of those changes. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarifications/ >> >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-sipcore-refer-clarifications-00 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Dec 1 13:00:11 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FEF1A9109 for ; Mon, 1 Dec 2014 13:00:09 -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 mX1ohrL7V3Vt for ; Mon, 1 Dec 2014 13:00:07 -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 6E6D71A90FC for ; Mon, 1 Dec 2014 13:00:07 -0800 (PST) Received: from unnumerable.local ([173.64.248.98]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB1L06In011895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 1 Dec 2014 15:00:06 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [173.64.248.98] claimed to be unnumerable.local Message-ID: <547CD6D1.6040005@nostrum.com> Date: Mon, 01 Dec 2014 15:00:01 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Zd7PbFNIyoSyQeV6F4_HWZrWkCw Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 21:00:09 -0000 Hi Andrew - I understand your reasoning, but the text you propose would have to be changed if we ever standardized any _other_ way to be sure there is no implicit subscription created. The text in the draft allows the standards to be extended, and does not leave the case that you are concerned about open. RjS On 11/27/14 7:04 PM, Andrew Allen wrote: > Robert > > Thanks for getting the WG version of the draft out. > > The main issue for me with the draft is the criteria for how the UA knows that it will not end up with an explicit subscription. Currently the draft is vague about that. > > Some deployments don't currently have the potential to create an implicit subscription because of something defined outside of the SIP protocol ensures that they only perform a subset of the defined behavior in RFCs 3515, 6665 and 4488 i.e. by defining that the UAC always includes refersub=false and by defining that the UAS always accepts that request to not create a subscription with the only way for a UAC to determine that the UAS will behave that way is because it (maybe) received a media-feature tag or feature capability indicator that it knows by means outside the SIP protocol (from some other SDOs specification or it's a proprietary implementation where a single vendor defines both ends) that this will be the behavior. > > I think we should clearly decide whether this fulfils the criteria for a UAC to determine definitively that no implicit subscription will be created and hence allows the UAC to send the Refer on an existing dialog or not. > > My own preference is not to have this qualify as a way for a UAC to be certain as this makes SIP protocol behavior dependent on some higher layer application semantic creating a tight coupling between the application and the SIP protocol stack making it difficult to reuse off the shelf SIP stacks for you application. It should be a protocol issue (defined in RFCs) not an application issue as to whether a request is sent on the same or a different dialog. > > I am also concerned that this kind of thing makes it more likely that the UAS in these cases ends up being only a partial implementation of the protocol (e.g. It doesn't even implement receiving a Refer out of dialog and cannot send a Notify even if a UAC did not include Refersub = false). I think the discussion we had in Dispatch in Hawaii shows that future interoperability problems are caused when only partial implementations of the protocol are done and assumptions about the behavior in perpetuity of the UAC are made. > > My preference is that refer-clarifications should only allow refer-explicit-subscription mechanism as a means for UAC to determine that its ok to send the Refer on an existing dialog and that we make refer-clarifications dependent on refer-explicit-subscription. If you want to send on an existing dialog then you use the refer-explicit-subscription mechanism and Require nosub otherwise you follow the RFC 6665 behavior and if you have a GRUU as the target then you send outside the existing dialog. That is clear and deterministic. > > So my proposal is to change the following text in section 4 from : > > If a user agent can be certain that no implicit subscription will be > created as a result of sending a REFER request (such as by requiring > an extension that disallows any such subscription > [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request > MAY be sent within an existing dialog. Such a REFER will be > constructed with its Contact header field populated with the dialog's > Local URI as specified in section 12 of [RFC3261]. > > To > > A user agent can be certain that no implicit subscription will be > created as a result of sending a REFER request by using the > extension in [I-D.ietf-sipcore-refer-explicit-subscription] to > require the UAS not to create an implicit subscription. Only > when using the explicit subscription mechanism to require that > a subscription not be created MAY the REFER request 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]. > > > Andrew > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Friday, November 21, 2014 6:19 PM > To: i-d-announce@ietf.org > Cc: sipcore@ietf.org > Subject: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. > > Title : Clarifications for the use of REFER with RFC6665 > Authors : Robert Sparks > Adam Roach > Filename : draft-ietf-sipcore-refer-clarifications-00.txt > Pages : 6 > Date : 2014-11-21 > > Abstract: > The SIP REFER method relies on the SIP-Specific Event Notification > Framework. That framework was revised by RFC6665. This document > highlights the implications of the requirement changes in RFC6665, > and updates the definition of the REFER method, RFC3515, to clarify > and disambiguate the impact of those changes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarifications/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sipcore-refer-clarifications-00 > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Dec 1 13:05:59 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E411A913A for ; Mon, 1 Dec 2014 13:05:55 -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 M3rDTYW2ioMl for ; Mon, 1 Dec 2014 13:05:52 -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 3A0D21A9136 for ; Mon, 1 Dec 2014 13:05:47 -0800 (PST) Received: from Orochi.local ([12.130.116.9]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id sB1L5YFD012465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Dec 2014 15:05:36 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [12.130.116.9] claimed to be Orochi.local Message-ID: <547CD80E.7000808@nostrum.com> Date: Mon, 01 Dec 2014 13:05:18 -0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Paul Kyzivat , sipcore@ietf.org References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127A5796@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127A5FFC@ESESSMB301.ericsson.se> <547CB095.6060306@alum.mit.edu> In-Reply-To: <547CB095.6060306@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/I-5ge1yo1Krk3_kaam0TsgEYeMI Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 21:05:56 -0000 On 12/1/14 10:16, Paul Kyzivat wrote: > On 11/28/14 10:28 AM, Ivo Sedlacek wrote: >> Hello, >> >> I think Andrew's proposed statement can be replaced by the statement >> already existing in the draft, i.e. >> ============= >> 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. >> ============= >> and extended as follows: >> ============= >> If a user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request (such as by requiring >> an extension that disallows any such subscription >> [I-D.ietf-sipcore-refer-explicit-subscription] >>>or by RFC4488 >> together with configuration / application logic in specific >> environment ensuring that implicit subscription is not created<<<), >> the REFER request >> MAY be sent within an existing dialog. >> ============= > > What criteria do you use to be *certain*? > > Some agreement of compliance to some specification seems to be required. > > I gather that what you have in mind is that both ends have been > verified to conform to particular versions of the IMS specification. > Do you ever really know that for certain in the presence of gateways > to foreign devices? Right; this is the real problem. The assumption that this is somehow "safe" to do because of some unsignaled, un-negotiated hidden agreement is extremely fragile and way outside the various extension mechanisms that SIP makes use of. Walled gardens grow doors. You don't want things to break in spectacular and undiagnosable ways when they do. I'm sad that some networks have decided to ignore the exact parts of specs that were designed to foster interop and prevent these surprise behaviors, and I see dangerous precedent in codifying this misbehavior as proposed above. Walled gardens grow doors faster than you're probably willing to believe. I'm frankly astonished by how quickly IMS has turned its eyes to WebRTC, asking for special accommodation for features particular to 3GPP specifications (cf. AMR). That only goes so far: you won't readily see JavaScript SIP stacks conforming to this hidden, unnegotiated agreement that presumably exists in IMS (but not elsewhere). It's an honest-to-goodness protocol fork, an engineered incompatibility. Walled gardens grow doors. It's time to start cleaning up the IMS garden to match SIP behavior, rather than handing out indulgences for its past sins. You're trying to fix this in the wrong SDO. /a From nobody Mon Dec 1 15:19:08 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6291A1ACDE7 for ; Mon, 1 Dec 2014 15:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUyVpcQPTE8h for ; Mon, 1 Dec 2014 15:18:54 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFFA1ACDBB for ; Mon, 1 Dec 2014 15:18:49 -0800 (PST) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 01 Dec 2014 18:18:36 -0500 Received: from XCT112CNC.rim.net (10.65.161.212) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.3.174.1; Mon, 1 Dec 2014 18:18:35 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT112CNC.rim.net ([::1]) with mapi id 14.03.0174.001; Mon, 1 Dec 2014 18:18:35 -0500 From: Andrew Allen To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQBeGiwaMk5ORsmEyvUhfkEzOyiJxzzZqwgAfN/4D//9BzIA== Date: Mon, 1 Dec 2014 23:18:34 +0000 Message-ID: References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <547CD6D1.6040005@nostrum.com> In-Reply-To: <547CD6D1.6040005@nostrum.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Z5w1cC-h-rpLFT2R2foa5oPbKeE Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 23:19:04 -0000 Robert My concern is that Ivo and Peter who represent two major vendors of SIP bas= ed network equipment have a different interpretation to what the current te= xt means. Doesn't the update process allow us to address that concern in t= he event that we come up with another mechanism to guarantee that no implic= it subscription is created? Alternatively I would propose we modify the text in question as follows to = take the future extension possibility into account: A user agent can be certain that no implicit subscription will be created as a result of sending a REFER request by using the extension in [I-D.ietf-sipcore-refer-explicit-subscription] to=20 require the UAS not to create an implicit subscription. Only=20 when using the explicit subscription mechanism to require that a subscription not be created or using a future specified mechanism=20 defined in a standards track RFC that guarantees no implicit=20 subscription will be created MAY the REFER request be sent within an existing dialog. Such a REFER will be constructed with=20 its Contact header field populated with the dialog's Local URI as=20 specified in section 12 of [RFC3261]. Andrew -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert Sparks Sent: Monday, December 01, 2014 4:00 PM To: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hi Andrew - I understand your reasoning, but the text you propose would have to be chan= ged if we ever standardized any _other_ way to be sure there is no implicit= subscription created. The text in the draft allows the standards to be extended, and does not lea= ve the case that you are concerned about open. RjS On 11/27/14 7:04 PM, Andrew Allen wrote: > Robert > > Thanks for getting the WG version of the draft out. > > The main issue for me with the draft is the criteria for how the UA knows= that it will not end up with an explicit subscription. Currently the draft= is vague about that. > > Some deployments don't currently have the potential to create an implicit= subscription because of something defined outside of the SIP protocol ensu= res that they only perform a subset of the defined behavior in RFCs 3515, 6= 665 and 4488 i.e. by defining that the UAC always includes refersub=3Dfalse= and by defining that the UAS always accepts that request to not create a s= ubscription with the only way for a UAC to determine that the UAS will beha= ve that way is because it (maybe) received a media-feature tag or feature c= apability indicator that it knows by means outside the SIP protocol (from s= ome other SDOs specification or it's a proprietary implementation where a s= ingle vendor defines both ends) that this will be the behavior. > > I think we should clearly decide whether this fulfils the criteria for a = UAC to determine definitively that no implicit subscription will be created= and hence allows the UAC to send the Refer on an existing dialog or not. > > My own preference is not to have this qualify as a way for a UAC to be ce= rtain as this makes SIP protocol behavior dependent on some higher layer ap= plication semantic creating a tight coupling between the application and th= e SIP protocol stack making it difficult to reuse off the shelf SIP stacks = for you application. It should be a protocol issue (defined in RFCs) not an= application issue as to whether a request is sent on the same or a differe= nt dialog. > > I am also concerned that this kind of thing makes it more likely that the= UAS in these cases ends up being only a partial implementation of the prot= ocol (e.g. It doesn't even implement receiving a Refer out of dialog and ca= nnot send a Notify even if a UAC did not include Refersub =3D false). I thi= nk the discussion we had in Dispatch in Hawaii shows that future interopera= bility problems are caused when only partial implementations of the protoco= l are done and assumptions about the behavior in perpetuity of the UAC are = made. > > My preference is that refer-clarifications should only allow refer-explic= it-subscription mechanism as a means for UAC to determine that its ok to se= nd the Refer on an existing dialog and that we make refer-clarifications de= pendent on refer-explicit-subscription. If you want to send on an existing = dialog then you use the refer-explicit-subscription mechanism and Require n= osub otherwise you follow the RFC 6665 behavior and if you have a GRUU as t= he target then you send outside the existing dialog. That is clear and det= erministic. > > So my proposal is to change the following text in section 4 from : > > If a user agent can be certain that no implicit subscription will be > created as a result of sending a REFER request (such as by requiring > an extension that disallows any such subscription > [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request > MAY be sent within an existing dialog. Such a REFER will be > constructed with its Contact header field populated with the dialog's > Local URI as specified in section 12 of [RFC3261]. > > To > > A user agent can be certain that no implicit subscription will be > created as a result of sending a REFER request by using the > extension in [I-D.ietf-sipcore-refer-explicit-subscription] to > require the UAS not to create an implicit subscription. Only > when using the explicit subscription mechanism to require that > a subscription not be created MAY the REFER request 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]. > > > Andrew > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > internet-drafts@ietf.org > Sent: Friday, November 21, 2014 6:19 PM > To: i-d-announce@ietf.org > Cc: sipcore@ietf.org > Subject: [sipcore] I-D Action:=20 > draft-ietf-sipcore-refer-clarifications-00.txt > > > 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-00.txt > Pages : 6 > Date : 2014-11-21 > > Abstract: > The SIP REFER method relies on the SIP-Specific Event Notification > Framework. That framework was revised by RFC6665. This document > highlights the implications of the requirement changes in RFC6665, > and updates the definition of the REFER method, RFC3515, to clarify > and disambiguate the impact of those changes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarificatio > ns/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sipcore-refer-clarifications-00 > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Dec 2 01:55:53 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFAB41A00E0 for ; Tue, 2 Dec 2014 01:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCs_LNcJK_Pw for ; Tue, 2 Dec 2014 01:55:49 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37AAC1A1A4C for ; Tue, 2 Dec 2014 01:55:49 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sB29ti3D026312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Dec 2014 09:55:44 GMT Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sB29tggb026230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 10:55:43 +0100 Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 2 Dec 2014 10:55:42 +0100 Received: from DEMUMBX003.nsn-intra.net ([169.254.2.85]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 10:55:42 +0100 From: "Leis, Peter (NSN - DE/Munich)" To: ext Adam Roach , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQDZL7waMk5ORsmEyvUhfkEzOyiJx7KRsAgADlXrA= Date: Tue, 2 Dec 2014 09:55:42 +0000 Message-ID: <059F3547244B7F4DB728757635C2DC4B15DB21A7@DEMUMBX003.nsn-intra.net> 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> In-Reply-To: <547CD80E.7000808@nostrum.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3959 X-purgate-ID: 151667::1417514144-0000658F-06A16A1A/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/wtsQucJQfYuiWELD0cOfEDQdZzA 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, 02 Dec 2014 09:55:52 -0000 Hi, The specific environment is described in 3GPP TS 24.237. For the specific c= ase, both ends of the signaling comply to this spec, both ends of the signa= ling are network nodes. These network nodes either reside in the same netwo= rk, or reside in different networks, and in this case there would be some s= ort of agreement between the operators.=20 At the time when the solution in 24.237 was designed (pointed at in Ivo's p= roposal), there was no IETF solution available. So I guess it would be grea= t if the draft does not make the existing solution invalid. Regards Peter -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Adam Roach Sent: Monday, December 01, 2014 10:05 PM To: Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt On 12/1/14 10:16, Paul Kyzivat wrote: > On 11/28/14 10:28 AM, Ivo Sedlacek wrote: >> Hello, >> >> I think Andrew's proposed statement can be replaced by the statement=20 >> already existing in the draft, i.e. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> If a user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request (such as by requiring >> an extension that disallows any such subscription >> [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request >> MAY be sent within an existing dialog. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> and extended as follows: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> If a user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request (such as by requiring >> an extension that disallows any such subscription >> [I-D.ietf-sipcore-refer-explicit-subscription] >>>or by RFC4488=20 >> together with configuration / application logic in specific=20 >> environment ensuring that implicit subscription is not created<<<),=20 >> the REFER request >> MAY be sent within an existing dialog. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > What criteria do you use to be *certain*? > > Some agreement of compliance to some specification seems to be required. > > I gather that what you have in mind is that both ends have been=20 > verified to conform to particular versions of the IMS specification.=20 > Do you ever really know that for certain in the presence of gateways=20 > to foreign devices? Right; this is the real problem. The assumption that this is somehow=20 "safe" to do because of some unsignaled, un-negotiated hidden agreement=20 is extremely fragile and way outside the various extension mechanisms=20 that SIP makes use of. Walled gardens grow doors. You don't want things to break in spectacular=20 and undiagnosable ways when they do. I'm sad that some networks have=20 decided to ignore the exact parts of specs that were designed to foster=20 interop and prevent these surprise behaviors, and I see dangerous=20 precedent in codifying this misbehavior as proposed above. Walled gardens grow doors faster than you're probably willing to=20 believe. I'm frankly astonished by how quickly IMS has turned its eyes=20 to WebRTC, asking for special accommodation for features particular to=20 3GPP specifications (cf. AMR). That only goes so far: you won't readily=20 see JavaScript SIP stacks conforming to this hidden, unnegotiated=20 agreement that presumably exists in IMS (but not elsewhere). It's an=20 honest-to-goodness protocol fork, an engineered incompatibility. Walled gardens grow doors. It's time to start cleaning up the IMS garden=20 to match SIP behavior, rather than handing out indulgences for its past=20 sins. You're trying to fix this in the wrong SDO. /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Dec 2 02:39:30 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA071A1A7A for ; Tue, 2 Dec 2014 02:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tR7yEtHJiYLR for ; Tue, 2 Dec 2014 02:39:25 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B849E1A1A75 for ; Tue, 2 Dec 2014 02:39:24 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-51-547d96daaa41 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 38.E1.04076.AD69D745; Tue, 2 Dec 2014 11:39:22 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.89]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 11:39:22 +0100 From: Ivo Sedlacek To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQDZMdZAj7dUN0V0+4uMx83fMm0px8GRmw Date: Tue, 2 Dec 2014 10:39:21 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127B4030@ESESSMB301.ericsson.se> References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127A5796@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127A5FFC@ESESSMB301.ericsson.se> <547CB095.6060306@alum.mit.edu> In-Reply-To: <547CB095.6060306@alum.mit.edu> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje6tabUhBt/eGFis2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG9oUr2Qv2+1X8eNnL3sD4za6LkZNDQsBE YsLGd6wQtpjEhXvr2boYuTiEBI4wShz+eBYsISSwiFFi128jEJtNQE9i4pYjYHERgUCJq0sm MIPYwgLBEq83d7JAxEMkZq7fwQhhG0ksuP6eDcRmEVCRuDOhAayGV8BXovvaPkaI+auYJPpW xYHYnAI6Es/br4HVMArISlz90wtWwywgLnHryXwmiEMFJJbsOc8MYYtKvHz8D+oBRYmdZ9uZ Iep1JBbs/sQGYWtLLFv4mhlir6DEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyilG0OLW4ODfd yEgvtSgzubg4P08vL7VkEyMwTg5u+W21g/Hgc8dDjAIcjEo8vB8+1YQIsSaWFVfmHmKU5mBR EuddeG5esJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG3kf5bx/EH2H9FH9NRWVrZeaOH3X7 3Ccz2d/kCQ+Jjw/52WvCemE/ww/bd4Ir5141ndzI/mbjJLt5ERsMzlauKqs5kMyeZq7/svcx e8ALnwvms9zqji/WeTiRM6Yq0ft6k/id7h2xO3dzbfrHOuHk2aP/2dSZNjGurVeI/PFAvVt5 g0wxY1mzEktxRqKhFnNRcSIAsqNazHQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/TGH8LgbfA0JDZJzMVYQzmRUMuvg 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, 02 Dec 2014 10:39:28 -0000 > What criteria do you use to be *certain*? 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.= =20 - the REFER with norefersub is sent within the dialog *ONLY* if the UAC of = initial INVITE request indicated the media feature tag and support of noref= ersub in the initial INVITE request. - description of the feature associated with the media feature tag guarante= es that recipient of the REFER with norefersub will accept the REFER withou= t creating an implicit subscription. Works. Kind regards Ivo Sedlacek -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 1. prosince 2014 19:17 To: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt On 11/28/14 10:28 AM, Ivo Sedlacek wrote: > Hello, > > I think Andrew's proposed statement can be replaced by the statement alre= ady existing in the draft, i.e. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > If a user agent can be certain that no implicit subscription will be > created as a result of sending a REFER request (such as by requiring > an extension that disallows any such subscription > [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request > MAY be sent within an existing dialog. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > and extended as follows: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > If a user agent can be certain that no implicit subscription will be > created as a result of sending a REFER request (such as by requiring > an extension that disallows any such subscription > [I-D.ietf-sipcore-refer-explicit-subscription] >>>or by RFC4488 toget= her with configuration / application logic in specific environment ensurin= g that implicit subscription is not created<<<), the REFER request > MAY be sent within an existing dialog. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D What criteria do you use to be *certain*? Some agreement of compliance to some specification seems to be required. I gather that what you have in mind is that both ends have been verified to= conform to particular versions of the IMS specification. Do you ever reall= y know that for certain in the presence of gateways to foreign devices? Thanks, Paul > Kind regards > > Ivo Sedlacek > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo=20 > Sedlacek > Sent: 28. listopadu 2014 8:38 > To: Andrew Allen; sipcore@ietf.org > Subject: Re: [sipcore] I-D Action:=20 > draft-ietf-sipcore-refer-clarifications-00.txt > > Hello, > > I disagree with proposed statement: > > "Only > when using the explicit subscription mechanism to require that > a subscription not be created MAY the REFER request be sent > within an existing dialog." > > There are existing means how the UA can be sure that implicit subscriptio= n will not be created - they rely on media feature tag and RFC4488, but wor= k neverthless. > > Therefore, I see the proposed statement as unnecessary restrictive. RFC66= 65 statement is sufficient. > > Kind regards > > Ivo Sedlacek > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew=20 > Allen > Sent: 28. listopadu 2014 2:04 > To: sipcore@ietf.org > Subject: Re: [sipcore] I-D Action:=20 > draft-ietf-sipcore-refer-clarifications-00.txt > > Robert > > Thanks for getting the WG version of the draft out. > > The main issue for me with the draft is the criteria for how the UA knows= that it will not end up with an explicit subscription. Currently the draft= is vague about that. > > Some deployments don't currently have the potential to create an implicit= subscription because of something defined outside of the SIP protocol ensu= res that they only perform a subset of the defined behavior in RFCs 3515, 6= 665 and 4488 i.e. by defining that the UAC always includes refersub=3Dfalse= and by defining that the UAS always accepts that request to not create a s= ubscription with the only way for a UAC to determine that the UAS will beha= ve that way is because it (maybe) received a media-feature tag or feature c= apability indicator that it knows by means outside the SIP protocol (from s= ome other SDOs specification or it's a proprietary implementation where a s= ingle vendor defines both ends) that this will be the behavior. > > I think we should clearly decide whether this fulfils the criteria for a = UAC to determine definitively that no implicit subscription will be created= and hence allows the UAC to send the Refer on an existing dialog or not. > > My own preference is not to have this qualify as a way for a UAC to be ce= rtain as this makes SIP protocol behavior dependent on some higher layer ap= plication semantic creating a tight coupling between the application and th= e SIP protocol stack making it difficult to reuse off the shelf SIP stacks = for you application. It should be a protocol issue (defined in RFCs) not an= application issue as to whether a request is sent on the same or a differe= nt dialog. > > I am also concerned that this kind of thing makes it more likely that the= UAS in these cases ends up being only a partial implementation of the prot= ocol (e.g. It doesn't even implement receiving a Refer out of dialog and ca= nnot send a Notify even if a UAC did not include Refersub =3D false). I thi= nk the discussion we had in Dispatch in Hawaii shows that future interopera= bility problems are caused when only partial implementations of the protoco= l are done and assumptions about the behavior in perpetuity of the UAC are = made. > > My preference is that refer-clarifications should only allow refer-explic= it-subscription mechanism as a means for UAC to determine that its ok to se= nd the Refer on an existing dialog and that we make refer-clarifications de= pendent on refer-explicit-subscription. If you want to send on an existing = dialog then you use the refer-explicit-subscription mechanism and Require n= osub otherwise you follow the RFC 6665 behavior and if you have a GRUU as t= he target then you send outside the existing dialog. That is clear and det= erministic. > > So my proposal is to change the following text in section 4 from : > > If a user agent can be certain that no implicit subscription will be > created as a result of sending a REFER request (such as by requiring > an extension that disallows any such subscription > [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request > MAY be sent within an existing dialog. Such a REFER will be > constructed with its Contact header field populated with the dialog's > Local URI as specified in section 12 of [RFC3261]. > > To > > A user agent can be certain that no implicit subscription will be > created as a result of sending a REFER request by using the > extension in [I-D.ietf-sipcore-refer-explicit-subscription] to > require the UAS not to create an implicit subscription. Only > when using the explicit subscription mechanism to require that > a subscription not be created MAY the REFER request 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]. > > > Andrew > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > internet-drafts@ietf.org > Sent: Friday, November 21, 2014 6:19 PM > To: i-d-announce@ietf.org > Cc: sipcore@ietf.org > Subject: [sipcore] I-D Action:=20 > draft-ietf-sipcore-refer-clarifications-00.txt > > > 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-00.txt > Pages : 6 > Date : 2014-11-21 > > Abstract: > The SIP REFER method relies on the SIP-Specific Event Notification > Framework. That framework was revised by RFC6665. This document > highlights the implications of the requirement changes in RFC6665, > and updates the definition of the REFER method, RFC3515, to clarify > and disambiguate the impact of those changes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarificatio > ns/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sipcore-refer-clarifications-00 > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Dec 2 03:09:26 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCD51A1A92 for ; Tue, 2 Dec 2014 03:09:23 -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 FzJ1oyV_1PpU for ; Tue, 2 Dec 2014 03:09:21 -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 8BC711A1A91 for ; Tue, 2 Dec 2014 03:09:20 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-19-547d9ddd06e0 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BD.79.24955.DDD9D745; Tue, 2 Dec 2014 12:09:18 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 12:09:17 +0100 From: Christer Holmberg To: Adam Roach , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQBeGiFbV1ztW9cUOimw2I9kop/5x1Mf8AgABuBICAAINygIAE5fuAgAAvDgCAAPsE8A== Date: Tue, 2 Dec 2014 11:09:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D56E3AB@ESESSMB209.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> In-Reply-To: <547CD80E.7000808@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvje69ubUhBt/W8Fns+buI3WLFhgOs Fl9/bGJzYPb4+/4Dk8eSJT+ZPGbtfMISwBzFZZOSmpNZllqkb5fAlTFjySrWgulyFdM3XGBu YHwg0cXIySEhYCKx/flDJghbTOLCvfVsXYxcHEICRxglHkyeD+UsZpToudXD3sXIwcEmYCHR /U8bpEFEoEDi+ZxmZhBbWCBY4vXmThaIeIjEzPU7GCHsMImWZZ/BalgEVCS2rF8IZvMK+Eo8 /7mSGWL+SSaJXf2rWEESnALaEnO+vmQDsRmBLvp+ag3YdcwC4hK3nsyHulRAYsme88wQtqjE y8f/WCFsJYkfGy6xQNTrSdyYOoUNwtaWWLbwNdRiQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKA kWUVo2hxanFSbrqRsV5qUWZycXF+nl5easkmRmD0HNzyW3UH4+U3jocYBTgYlXh4P3yqCRFi TSwrrsw9xCjNwaIkzrvw3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwS1S8+zbvuL/Nh 2rGvP7xub2Jm09o0pXCqJK9K23yZ16qrdQzCF5Xnb13d02/w+oyRy43yi/eXMus8b/7rLne7 iXN9/70LgTOVhYqO/Dz15XbUkk+TFW4u0mhS/zM5tO1fd+WhH6FLeFPUX2tdunnRTNLmZ3v8 hpKjb7ZuZthj11py93pTiM9KJZbijERDLeai4kQAciyg8H8CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/P29-wfNWcy5iXBZ5DVCSjhUHpJk 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, 02 Dec 2014 11:09:23 -0000 Hi Adam, Regarding WebRTC, 3GPP does not mandate SIP JavaScript stacks to support IM= S SIP extensions and "hidden, unnegotiated agreements" in order to access I= MS. In fact, 3GPP doesn't even mandate usage of SIP, it has has taken the s= ame signaling-protocol-is-outside-the-scope approach as IETF. And, the use-cases we are discussing in this thread would never impact a Ja= vaScript application. They are related to procedures for=A0handover=A0of a = call between IMS and circuit switched network. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach Sent: 1. joulukuuta 2014 23:05 To: Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt On 12/1/14 10:16, Paul Kyzivat wrote: > On 11/28/14 10:28 AM, Ivo Sedlacek wrote: >> Hello, >> >> I think Andrew's proposed statement can be replaced by the statement=20 >> already existing in the draft, i.e. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> If a user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request (such as by requiring >> an extension that disallows any such subscription >> [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request >> MAY be sent within an existing dialog. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> and extended as follows: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> If a user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request (such as by requiring >> an extension that disallows any such subscription >> [I-D.ietf-sipcore-refer-explicit-subscription] >>>or by RFC4488=20 >> together with configuration / application logic in specific=20 >> environment ensuring that implicit subscription is not created<<<),=20 >> the REFER request >> MAY be sent within an existing dialog. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > What criteria do you use to be *certain*? > > Some agreement of compliance to some specification seems to be required. > > I gather that what you have in mind is that both ends have been=20 > verified to conform to particular versions of the IMS specification. > Do you ever really know that for certain in the presence of gateways=20 > to foreign devices? Right; this is the real problem. The assumption that this is somehow "safe"= to do because of some unsignaled, un-negotiated hidden agreement is extrem= ely fragile and way outside the various extension mechanisms that SIP makes= use of. Walled gardens grow doors. You don't want things to break in spectacular an= d undiagnosable ways when they do. I'm sad that some networks have decided = to ignore the exact parts of specs that were designed to foster interop and= prevent these surprise behaviors, and I see dangerous precedent in codifyi= ng this misbehavior as proposed above. Walled gardens grow doors faster than you're probably willing to believe. I= 'm frankly astonished by how quickly IMS has turned its eyes to WebRTC, ask= ing for special accommodation for features particular to 3GPP specification= s (cf. AMR). That only goes so far: you won't readily see JavaScript SIP st= acks conforming to this hidden, unnegotiated agreement that presumably exis= ts in IMS (but not elsewhere). It's an honest-to-goodness protocol fork, an= engineered incompatibility. Walled gardens grow doors. It's time to start cleaning up the IMS garden to= match SIP behavior, rather than handing out indulgences for its past sins. You're trying to fix this in the wrong SDO. /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Dec 2 12:35:23 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099AB1A7014 for ; Tue, 2 Dec 2014 12:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.08 X-Spam-Level: X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ig9ndDz4iVkm for ; Tue, 2 Dec 2014 12:35:18 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB46F1A7017 for ; Tue, 2 Dec 2014 12:35:17 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id r5so10123871qcx.13 for ; Tue, 02 Dec 2014 12:35:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=wngP7cSGxtqUcGhWd0ytx2vw2mH0or+zKWvgUO5NiVg=; b=aTgZzu85Mm18I5W2HkX4SXBvY7+KQx2x9enuUem+gBOfOwiZh2HDEkRpJBxbtFl5qy JyHH90ocg1OwRp/PHuZTEbNWhb3aFtFHJYb7sssUbK40de8IloRPeEcToWLVywWWt4ni cBlA/ETsRafpG4WZP/2q7h5uHdLd9YsPb+zmX+8iZDTI7xjjQujwdZOriqEKIoJZIQzY idwHgO5h6jXNmihPXjVklZc6lCVWkasoSfO+FCCvu3KS2G43KdgfU8yqMpBwGTzQvJJ6 4UHTSkRO5Tn6tKKiH3TWK7INqVbAfWGXLBfCkk57c2FI/osHcijRoG2m5Cv0V2gp6ssB qPTw== X-Gm-Message-State: ALoCoQk2m7i7cWIX3Wuo+p3tob1dJUC/5eX29wUYtWckWk0EYvaW7WyxtGRuss42w6Xh4EBdXJCH X-Received: by 10.224.114.133 with SMTP id e5mr1751159qaq.48.1417552517161; Tue, 02 Dec 2014 12:35:17 -0800 (PST) From: Brett Tate References: <546CF80D.4010005@nostrum.com> In-Reply-To: <546CF80D.4010005@nostrum.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE9J1r/dlzYpT7BBHeyZoYj59zMngJ52cKInY62ckA= Date: Tue, 2 Dec 2014 15:35:11 -0500 Message-ID: <838cc9cbef8fcdf18d0744f67b5ce69c@mail.gmail.com> To: draft-sparks-sipcore-refer-clarifications@tools.ietf.org, sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/ZRLMJFVZ6OR9J_DMBPypFYcKHdY Subject: Re: [sipcore] draft-sparks-sipcore-refer-clarifications-05: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 20:35:20 -0000 Hi, Thanks for the response; reply is inline. >> Is there a reason why not relaxing the requirement >> for REFER notifiers which only send NOTIFY with >> Subscription-State terminated? > > Such a thing would be very unusual It is not unusual. RFC 3515 explicitly discusses it. "Note that agents accepting REFER and not wishing to hold subscription state can terminate the subscription with this initial NOTIFY." "A minimal, but complete, implementation can respond with a single NOTIFY containing either the body: SIP/2.0 100 Trying" > But even if you could guarantee such unique conditions, > there is always the possibility that the NOTIFY could > be answered with a 503/Retry-After, or any other response > indicating that the NOTIFY needs to be reconditioned and > submitted again, during which time there is dialog reusage. As far as I know, RFC 6665 indicates that the additional dialog usage has not been created. >> For instance, RFC 6665 section 4.4.1 indicates that the >> NOTIFY does not create a dialog usage. >> >> "Dialogs usages are created upon completion of a NOTIFY transaction >> for a new subscription, unless the NOTIFY request contains a >> "Subscription-State" of "terminated."" > > Sigh. I should have argued harder for "created and immediately > destroyed" when we were working on 6665 instead settling on > this text, because of the possibility pointed to above of > getting a non-200 response that indicates something should be > changed (or delayed) and the request resubmitted. Concerning sigh, me too. If I had known that the mandatory NOTIFY would eventually lead to mandatory GRUU, I might have argued harder to remove the mandate during the switch from BYE Also to REFER. And sigh again because the issues raised by draft-kaplan-dispatch-gruu-problematic still exist. From nobody Wed Dec 3 00:23:38 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3A01A0110 for ; Wed, 3 Dec 2014 00:23:35 -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 mSRLk1kHJfGj for ; Wed, 3 Dec 2014 00:23: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 1B5421A00F1 for ; Wed, 3 Dec 2014 00:23:32 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-91-547ec8835b4a Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C1.E8.29772.388CE745; Wed, 3 Dec 2014 09:23:31 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.89]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 09:23:31 +0100 From: Ivo Sedlacek To: Brett Tate , "sipcore@ietf.org" Thread-Topic: [sipcore] 503 response with Retry-After header field - request for clarification Thread-Index: AQEgzkc0BWk9xbXBIc7ssa2HwqHocQGiIiNNAhxFTrIB5BjiqZ2sWYzQgAKYuOA= Date: Wed, 3 Dec 2014 08:23:29 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127B4BA8@ESESSMB301.ericsson.se> References: <39B5E4D390E9BD4890E2B31079006101127A29FB@ESESSMB301.ericsson.se> <5475504F.3070400@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127B36DB@ESESSMB301.ericsson.se> <40a1c444c4b131c7bc99af850e355296@mail.gmail.com> In-Reply-To: <40a1c444c4b131c7bc99af850e355296@mail.gmail.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+NgFrrLLMWRmVeSWpSXmKPExsUyM+JvjW7ziboQg2MnZC2a5/9jtPj6YxOb A5PHj9uBHkuW/GQKYIrisklJzcksSy3St0vgynh2sIe9YIJmxeYDN9gaGDs0uhg5OCQETCTa j8Z1MXICmWISF+6tZwOxhQSOMEq0TLbuYuQCshcxSmz48hAswSagJzFxyxFWkF4RAW+J48tT QMLCAvES67quMIPYIgIJErs3rmKEsP0k3u/tYgGxWQRUJCYemwQW5xXwlfh4qI8NYv4sJolv 9+eBJTgF7CS6Nq1hArEZBWQlrv7pBYszC4hL3HoynwniUAGJJXvOM0PYohIvH/9jhbAVJa5O X84EchuzgKbE+l36EK2KElO6H7JD7BWUODnzCcsERtFZSKbOQuiYhaRjFpKOBYwsqxhFi1OL k3LTjYz0Uosyk4uL8/P08lJLNjEC4+Pglt8GOxhfPnc8xCjAwajEw7uhpi5EiDWxrLgy9xCj NAeLkjjvwnPzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwGopf1f9nZSmxaPGOnYe+Vp89 XqHXX+R698jB9kudSqc+i7277ionvYtpwRPmSd8OJ37ZMXltUf6+ssuCGku4Shrbbx9tvLav N9M6nNNs482PXzRrL9c2OGwIORNfOXPerE8bRDt4ghmFnQ5mR5kWnlX63l98M+TQ5CvHKy81 /StbrRjque6YsRJLcUaioRZzUXEiAOuxjY1wAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/QkMQ8xe9L0oHEXn7lG8yIGlks6I Subject: Re: [sipcore] 503 response with Retry-After header field - request for clarification X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 08:23:35 -0000 SGVsbG8sDQoNCkkgd2FzIG5vdCBhd2FyZSBvZiBSRkMgNTM5MCBhbmQgb2YgUkZDIDMyNjMgc2Vj dGlvbiA0LjMuIFRoYW5rcyBmb3IgcG9pbnRpbmcgdGhlbSBvdXQuDQoNCkp1c3QgdG8gZG91Ymxl LWNoZWNrIC0gInRoYXQgc2VydmVyIiBpbiBSRkMzMjYxIHNlY3Rpb24gMjEuNS40IHN0YXRlbWVu dCBiZWxvdyBpcyB0aGUgSVAgYWRkcmVzcyBvZiB0aGUgbmV4dCBob3AgdG8gd2hpY2ggU0lQIHJl cXVlc3Qgd2FzIHNlbnQgYW5kIGZyb20gd2hpY2ggNTAzIHJlc3BvbnNlIHdhcyByZWNlaXZlZC4g Q29ycmVjdD8NCi0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJdCBTSE9VTEQgTk9UDQogICBmb3J3YXJk IGFueSBvdGhlciByZXF1ZXN0cyB0byBfX3RoYXQgc2VydmVyX18gZm9yIHRoZSBkdXJhdGlvbiBz cGVjaWZpZWQNCiAgIGluIHRoZSBSZXRyeS1BZnRlciBoZWFkZXIgZmllbGQsIGlmIHByZXNlbnQu DQotLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpLaW5kIHJlZ2FyZHMNCg0KSXZvIFNlZGxhY2VrDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCcmV0dCBUYXRlIFttYWlsdG86YnJl dHRAYnJvYWRzb2Z0LmNvbV0gDQpTZW50OiAxLiBwcm9zaW5jZSAyMDE0IDE4OjE2DQpUbzogSXZv IFNlZGxhY2VrOyBzaXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW3NpcGNvcmVdIDUwMyBy ZXNwb25zZSB3aXRoIFJldHJ5LUFmdGVyIGhlYWRlciBmaWVsZCAtIHJlcXVlc3QgZm9yIGNsYXJp ZmljYXRpb24NCg0KSGksDQoNClllczsgYXMgbWVudGlvbmVkIHdpdGhpbiBSRkMgNTM5MCwgIlJG QyAzMjYxIGlzIHVuY2xlYXIgb24gdGhlIHNjb3BlIG9mIGEgNTAzIiBhbmQgaXQgY2FuIGxlYWQg dG8gdW5pbnRlbnRpb25hbCB1bmRlcnV0aWxpemF0aW9uLg0KDQpSRkMgMzI2MyBzZWN0aW9uIDQu MyBpcyB0aGUgbWFpbiByZWFzb24gd2h5IEkgZGlzYWdyZWUgd2l0aCBhdHRlbXB0aW5nIHRvIGFw cGx5IHRoZSBzY29wZSB0byBhIFVSSSBvciBpdHMgaG9zdG5hbWUuICBUaGF0IGludGVycHJldGF0 aW9uIHdvdWxkIGFsbG93IGFkdmFuY2luZyB1cG9uIHJlY2VpdmluZyBhIDUwMzsgaG93ZXZlciB0 aGUgUmV0cnktQWZ0ZXIgd291bGQgY2F1c2UgdGhlIHJlc3Qgb2YgdGhlIGxpc3QgdG8gYmUgc2tp cHBlZC4NCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEl2byBTZWRs YWNlayBbbWFpbHRvOml2by5zZWRsYWNla0Blcmljc3Nvbi5jb21dDQo+IFNlbnQ6IE1vbmRheSwg RGVjZW1iZXIgMDEsIDIwMTQgMTE6MDggQU0NCj4gVG86IEJyZXR0IFRhdGU7IHNpcGNvcmVAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtzaXBjb3JlXSA1MDMgcmVzcG9uc2Ugd2l0aCBSZXRyeS1B ZnRlciBoZWFkZXIgZmllbGQgLQ0KcmVxdWVzdA0KPiBmb3IgY2xhcmlmaWNhdGlvbg0KPg0KPiA+ IEl0IGlzIHVuY2xlYXIgYWJvdXQgInNlcnZlciIgYmVpbmcgMSkgSVAgYWRkcmVzcyB3aGVyZSBz ZW50IHJlcXVlc3QsDQoyKQ0KPiBzb3VyY2UgSVAgYWRkcmVzcyBvZiByZWNlaXZlZCByZXNwb25z ZSwgYW5kL29yIDMpIHNvbWV0aGluZyBlbHNlLg0KPg0KPiBJIHRob3VnaHQgInNlcnZlciIgaXM6 DQo+IC0gZW50aXJlIFVSSSAobm90IGp1c3QgSVAgYWRkcmVzcyBhbmQgcG9ydCkgaW4gdGhlIHRv cCBSb3V0ZSBoZWFkZXINCmZpZWxkIG9mDQo+IHRoZSByZXF1ZXN0LCBpZiB0aGVyZSBpcyBhIFJv dXRlIGhlYWRlciBmaWVsZCBpbiB0aGUgcmVxdWVzdDsgYW5kDQo+IC0gZW50aXJlIFJlcXVlc3Qt VVJJIChub3QganVzdCBJUCBhZGRyZXNzIGFuZCBwb3J0KSBvZiB0aGUgcmVxdWVzdCwgaWYNCnRo ZXJlDQo+IGlzIG5vIFJvdXRlIGhlYWRlciBmaWVsZCBpbiB0aGUgcmVxdWVzdC4NCj4NCj4gS2lu ZCByZWdhcmRzDQo+DQo+IEl2byBTZWRsYWNlaw0KPg0KPiBUaGlzIENvbW11bmljYXRpb24gaXMg Q29uZmlkZW50aWFsLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24NCnRoZQ0KPiBi YXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdCB3d3cuZXJpY3Nzb24uY29tL2VtYWlsX2Rpc2Ns YWltZXINCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2lwY29yZSBb bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyZXR0IA0KPiBU YXRlDQo+IFNlbnQ6IDEuIHByb3NpbmNlIDIwMTQgMTU6MTkNCj4gVG86IHNpcGNvcmVAaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSA1MDMgcmVzcG9uc2Ugd2l0aCBSZXRyeS1BZnRl ciBoZWFkZXIgZmllbGQgLQ0KcmVxdWVzdA0KPiBmb3IgY2xhcmlmaWNhdGlvbg0KPg0KPiA+IElm IHlvdSBzZW5kIGEgQllFIHRvIHRoZSBzYW1lIHRoaW5nIHRoYXQgc2VudCB5b3UgYSA1MDMgZm9y IGFueSANCj4gPiBvdGhlciByZWFzb24sIGJlZm9yZSB0aGUgUmV0cnktQWZ0ZXIgaGFzIGV4cGly ZWQsIHlvdSBhcmUgdmlvbGF0aW5nIA0KPiA+IHByb3RvY29sLg0KPg0KPiBZZXM7IGl0IGlzIGEg dmlvbGF0aW9uIG9mIHRoZSBSRkMgMzI2MSBzZWN0aW9uIDIxLjUuNCBTSE9VTEQgTk9ULg0KPg0K PiAiQSBjbGllbnQgKHByb3h5IG9yIFVBQykgcmVjZWl2aW5nIGEgNTAzIChTZXJ2aWNlIFVuYXZh aWxhYmxlKSBTSE9VTEQNCmF0dGVtcHQNCj4gdG8gZm9yd2FyZCB0aGUgcmVxdWVzdCB0byBhbiBh bHRlcm5hdGUgc2VydmVyLiAgSXQgU0hPVUxEIE5PVCBmb3J3YXJkDQphbnkNCj4gb3RoZXIgcmVx dWVzdHMgdG8gdGhhdCBzZXJ2ZXIgZm9yIHRoZSBkdXJhdGlvbiBzcGVjaWZpZWQgaW4gdGhlDQpS ZXRyeS1BZnRlcg0KPiBoZWFkZXIgZmllbGQsIGlmIHByZXNlbnQuIg0KPg0KPiBSRkMgNTM5MCBw cmVzZW50cyBzb21lIHJlYXNvbnMgKGRpcmVjdGx5IG9yIGluZGlyZWN0bHkpIHdoeSB5b3UgbWln aHQNCndhbnQgdG8NCj4gdmlvbGF0ZSB0aGUgU0hPVUxEIE5PVC4gIEZvciBpbnN0YW5jZSwgeW91 IG1pZ2h0IGNvbnNpZGVyIHRoZSA1MDMgd2l0aA0KUmV0cnktDQo+IEFmdGVyIG1lY2hhbmlzbSB0 byBiZSB0b28gaW5zZWN1cmUgdG8gdHJ1c3QgdGhhdCB5b3UgcmVhbGx5IHNob3VsZCBub3QNCnNl bmQNCj4gYW55IHJlcXVlc3RzIHRvIGEgcGFydGljdWxhciBzZXJ2ZXIgZm9yIHRoZSBuZXh0IGhv dXIsIGRheSwgb3IgeWVhci4NCj4NCj4gU2ltaWxhcmx5IGFzIG1lbnRpb25lZCB3aXRoaW4gUkZD IDUzOTAgc2VjdGlvbiA1LjIsIFJGQyAzMjYxIGlzIA0KPiB1bmNsZWFyIGNvbmNlcm5pbmcgInNl cnZlciIgaW4gcmVsYXRpb24gdG8gdGhlIHNjb3BlIG9mIHRoZSA1MDMuICBJdCANCj4gaXMgdW5j bGVhcg0KYWJvdXQNCj4gInNlcnZlciIgYmVpbmcgMSkgSVAgYWRkcmVzcyB3aGVyZSBzZW50IHJl cXVlc3QsIDIpIHNvdXJjZSBJUCBhZGRyZXNzIA0KPiBvZiByZWNlaXZlZCByZXNwb25zZSwgYW5k L29yIDMpIHNvbWV0aGluZyBlbHNlLiAgQW5kIGJhc2VkIHVwb24gDQo+IGRyYWZ0LWlldGYtIHNp cGNvcmUtZG5zLWR1YWwtc3RhY2sncyBpbnRlbnRpb24gdG8gY2F1c2UgdHJ5aW5nIGJvdGggDQo+ IElQdjQgYW5kIElQdjYgYWRkcmVzc2VzLCBJJ2QgbG92ZSB0byBoZWFyIHRoZSBwcm9wb3NhbCBh Ym91dCBob3cgeW91IA0KPiBhdm9pZCBhdHRlbXB0aW5nDQp0aGUNCj4gc2FtZSBzZXJ2ZXIgdHdp Y2Ugd2hlbiBhIDUwMyBpcyByZWNlaXZlZC4NCj4NCj4gVGhhbmtzLA0KPiBCcmV0dA0KPg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzaXBjb3Jl IG1haWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K From nobody Wed Dec 3 04:33:37 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1734D1A1ADF for ; Wed, 3 Dec 2014 04:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A53qig8xKatx for ; Wed, 3 Dec 2014 04:33:32 -0800 (PST) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDDA91A1A27 for ; Wed, 3 Dec 2014 04:33:31 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id v10so10371342qac.35 for ; Wed, 03 Dec 2014 04:33:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=f2+rn04HoyRobezzK3iVtmh2nl7KAKrpbSl9xYlHQmo=; b=SYO878/9h4/c32locaJUUeA8qe8HZOKNgCRtiv26wo+WZmSCmJE+zPjIqko7bV6bxO WI0P1+KMdrtQ9zG/yEkH2JN6FZauHl+D/Cn5ZhI+EgIefSwBoGmZnwxUgl+50azO5tNR rYnu1/OgqoyLzdDt9wopL+Eq9WWPcBGnpa0mDDPmY2PN0GFr6PUmJev/KVfMXylDZrBA UrYIUNieZdXBPHPVbdariGMH1Tf01aEPP8zwvIZQ/cqpRLIdcDz3jvXwnNZB2UJabWlE OMyoDCS7QdQRKcY54/SreNjFgn4Wy1U023xixRq86DHozkTOfjHNdaeQhpEHI7bTTiCU 0vvg== X-Gm-Message-State: ALoCoQmFEsBuodBJcNooLoFJsYvc+PlxtUPMCmxPfuhteJg+KJ/DWFKc2HcN3fwO5S6wmV3/+z2G X-Received: by 10.224.136.194 with SMTP id s2mr7914824qat.82.1417610011119; Wed, 03 Dec 2014 04:33:31 -0800 (PST) From: Brett Tate References: <39B5E4D390E9BD4890E2B31079006101127A29FB@ESESSMB301.ericsson.se> <5475504F.3070400@nostrum.com> <39B5E4D390E9BD4890E2B31079006101127B36DB@ESESSMB301.ericsson.se> <40a1c444c4b131c7bc99af850e355296@mail.gmail.com> <39B5E4D390E9BD4890E2B31079006101127B4BA8@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127B4BA8@ESESSMB301.ericsson.se> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEgzkc0BWk9xbXBIc7ssa2HwqHocQGiIiNNAhxFTrIB5BjiqQLHNTn2AXQTurOdjVfogA== Date: Wed, 3 Dec 2014 07:33:30 -0500 Message-ID: To: Ivo Sedlacek , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/TPW8b2Hwo4R5FcvLAYIOPMltEfM Subject: Re: [sipcore] 503 response with Retry-After header field - request for clarification X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 12:33:34 -0000 Hi, As far as I know, the IETF has not clarified what "server" means within the RFC 3261 snippet. RFC 5390 did not clarify it. Maybe it was to motivate everyone to start using the soc working group mechanisms such as RFC 7339. "5.2. Underutilization Interestingly, there are also examples of deployments where the network capacity was greatly reduced as a consequence of the overload mechanism. Consider again Figure 1. Unfortunately, RFC 3261 is unclear on the scope of a 503. When it is received by P1, does the proxy cease sending requests to that IP address? To the hostname? To the URI? Some implementations have chosen the hostname as the scope. When the hostname for a URI points to an SRV record in the DNS, which, in turn, maps to a cluster of downstream servers (S1, S2, and S3 in the example), a 503 response from a single one of them will make the proxy believe that the entire cluster is overloaded. Consequently, proxy P1 will cease sending any traffic to any element in the cluster, even though there are elements in the cluster that are underutilized." > -----Original Message----- > From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] > Sent: Wednesday, December 03, 2014 3:23 AM > To: Brett Tate; sipcore@ietf.org > Subject: RE: [sipcore] 503 response with Retry-After header field - > request > for clarification > > Hello, > > I was not aware of RFC 5390 and of RFC 3263 section 4.3. Thanks for > pointing > them out. > > Just to double-check - "that server" in RFC3261 section 21.5.4 statement > below is the IP address of the next hop to which SIP request was sent and > from which 503 response was received. Correct? > -------------------- > It SHOULD NOT > forward any other requests to __that server__ for the duration > specified > in the Retry-After header field, if present. > -------------------- > > Kind regards > > Ivo Sedlacek > > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: 1. prosince 2014 18:16 > To: Ivo Sedlacek; sipcore@ietf.org > Subject: RE: [sipcore] 503 response with Retry-After header field - > request > for clarification > > Hi, > > Yes; as mentioned within RFC 5390, "RFC 3261 is unclear on the scope of a > 503" and it can lead to unintentional underutilization. > > RFC 3263 section 4.3 is the main reason why I disagree with attempting to > apply the scope to a URI or its hostname. That interpretation would allow > advancing upon receiving a 503; however the Retry-After would cause the > rest > of the list to be skipped. > > > > -----Original Message----- > > From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] > > Sent: Monday, December 01, 2014 11:08 AM > > To: Brett Tate; sipcore@ietf.org > > Subject: RE: [sipcore] 503 response with Retry-After header field - > request > > for clarification > > > > > It is unclear about "server" being 1) IP address where sent request, > 2) > > source IP address of received response, and/or 3) something else. > > > > I thought "server" is: > > - entire URI (not just IP address and port) in the top Route header > field of > > the request, if there is a Route header field in the request; and > > - entire Request-URI (not just IP address and port) of the request, if > there > > is no Route header field in the request. > > > > Kind regards > > > > Ivo Sedlacek > > > > This Communication is Confidential. We only send and receive email on > the > > basis of the terms set out at www.ericsson.com/email_disclaimer > > > > -----Original Message----- > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett > > Tate > > Sent: 1. prosince 2014 15:19 > > To: sipcore@ietf.org > > Subject: Re: [sipcore] 503 response with Retry-After header field - > request > > for clarification > > > > > If you send a BYE to the same thing that sent you a 503 for any > > > other reason, before the Retry-After has expired, you are violating > > > protocol. > > > > Yes; it is a violation of the RFC 3261 section 21.5.4 SHOULD NOT. > > > > "A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD > attempt > > to forward the request to an alternate server. It SHOULD NOT forward > any > > other requests to that server for the duration specified in the > Retry-After > > header field, if present." > > > > RFC 5390 presents some reasons (directly or indirectly) why you might > want to > > violate the SHOULD NOT. For instance, you might consider the 503 with > Retry- > > After mechanism to be too insecure to trust that you really should not > send > > any requests to a particular server for the next hour, day, or year. > > > > Similarly as mentioned within RFC 5390 section 5.2, RFC 3261 is > > unclear concerning "server" in relation to the scope of the 503. It > > is unclear > about > > "server" being 1) IP address where sent request, 2) source IP address > > of received response, and/or 3) something else. And based upon > > draft-ietf- sipcore-dns-dual-stack's intention to cause trying both > > IPv4 and IPv6 addresses, I'd love to hear the proposal about how you > > avoid attempting > the > > same server twice when a 503 is received. > > > > Thanks, > > Brett From nobody Wed Dec 3 05:49:26 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E298B1A1B05 for ; Wed, 3 Dec 2014 05:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqirU3-cd-_a for ; Wed, 3 Dec 2014 05:49:24 -0800 (PST) Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D42F01A1B2A for ; Wed, 3 Dec 2014 05:49:16 -0800 (PST) Received: by mail-qg0-f49.google.com with SMTP id a108so10927657qge.36 for ; Wed, 03 Dec 2014 05:49:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:content-type; bh=+SXMEvf99vznwnnmPfPbG3zzhSwkhIqHA7G3XpTvZQo=; b=HapgMj+CMKGBc+qIuSpmlCucW/+zl8NBOdv1wTB6/fgIpyzQZ+OOmAFeAu7W6kutSu cdwD26QAfyvonzHnAC6v/H9utnfE4zIeFNaCqT1o99TmWOavhqmR79e5Y326bnl3LJzT dpt0SG0c5mcnPs5oTNOXqVPHTTMbql6zLrszswC1tQ5wx1TbTmbfYh837uXXyX837xKS FCesl6e0v5LkVuUN/KErehAT4jM7iNWx2xvNSdrsWqyrgl2Y3+fNu7jp0ii2/HVmvOvR F8vjrf1hoJF5Ug38gCF8g7nGFuYuzu6YOxmZe5MoEhcgONjER1zmis+/SogdtL3bInnk 9n+g== X-Gm-Message-State: ALoCoQkoBnrbPWNRaUnppQ4+aBOWcQb3PlZUTIHA/59w67/eUFnIIH+8PNPAA9JaoGpRfmq2+aWe X-Received: by 10.140.38.102 with SMTP id s93mr8036346qgs.18.1417614556043; Wed, 03 Dec 2014 05:49:16 -0800 (PST) From: Brett Tate 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> In-Reply-To: <547CD80E.7000808@nostrum.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJgU36F+MKMlHklPEpKaWTRgg/iWQI7wCCDAZy/jfMB7/4JHQHLTExTAtbXEvabCf+wQA== Date: Wed, 3 Dec 2014 08:49:15 -0500 Message-ID: <626a813a1caddac1740dc3d0e6342dc7@mail.gmail.com> To: Adam Roach , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/3nalY1yWbUnnJKZKc81cR1o-zQA 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, 03 Dec 2014 13:49:26 -0000 > Walled gardens grow doors. You don't want things to break > in spectacular and undiagnosable ways when they do. Draft-kaplan-dispatch-gruu-problematic highlights some of the spectacular ways things can break when using GRUU. For instance when generating a GRUU, how do you know that it is globally routable by every device which can receive it? Concerning RFC 6665, did the working group intentionally decide to make it so notifiers could not exist within a walled garden without somehow becoming globally routable? Thanks, Brett From nobody Wed Dec 3 11:21:33 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C8E1A1EEE for ; Wed, 3 Dec 2014 11:21:29 -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 WsK74G4nsIpR for ; Wed, 3 Dec 2014 11:21:26 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id A556D1A1AA7 for ; Wed, 3 Dec 2014 11:21:26 -0800 (PST) Received: from xct108cnc.rim.net ([10.65.161.208]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 03 Dec 2014 14:21:21 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT108CNC.rim.net ([fe80::8dc1:9551:6ed8:c618%17]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 14:21:21 -0500 From: Andrew Allen To: "Leis, Peter (NSN - DE/Munich)" , ext Adam Roach , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQBeGiwaMk5ORsmEyvUhfkEzOyiJxzzZqwgAHi0uCAAIN8oIAFOh2AgAAvDgCAANc/AIABlYpA Date: Wed, 3 Dec 2014 19:21:20 +0000 Message-ID: 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> In-Reply-To: <059F3547244B7F4DB728757635C2DC4B15DB21A7@DEMUMBX003.nsn-intra.net> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/BQh05onDlVZ0o1L8hRofTEL6BoM 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, 03 Dec 2014 19:21:29 -0000 Maybe the way out of this rat hole is to discuss in the text and allow lega= cy application usages (similar to the legacy usages for INFO). So SIP stac= ks could be considered RFC 6665 compliant with legacy application usages us= ing RFC 4488 and feature tags identifying application specific behavior tha= t ensures that dialog reuse does not occur but that we deprecate such usage= s for any new applications that are developed and insist on the use of [I-D= .ietf-sipcore-refer-explicit-subscription] going forward.=20 =09 As Christer said: The only reason these "special environment" use-cases exist to begin with i= s because previously there was no "pure" protocol mechanism for preventing = implicit subscriptions. And, as they have existed for a while already, and = have been implemented, they will not suddenly go away just because we now h= ave [I-D.ietf-sipcore-refer-explicit-subscription]. Neither will they go aw= ay just because we now have drafts clarifying some RFCs.=20 BUT, because we now DO have a "pure" protocol mechanism [I-D.ietf-sipcore-r= efer-explicit-subscription] for preventing implicit subscriptions, I assume= there will be no NEW "special environment" use-cases in future - people WI= LL use [I-D.ietf-sipcore-refer-explicit-subscription] :) Is that something we could all agree on as a compromise? Andrew -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Leis, Peter (N= SN - DE/Munich) Sent: Tuesday, December 02, 2014 4:56 AM To: ext Adam Roach; Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hi, The specific environment is described in 3GPP TS 24.237. For the specific c= ase, both ends of the signaling comply to this spec, both ends of the signa= ling are network nodes. These network nodes either reside in the same netwo= rk, or reside in different networks, and in this case there would be some s= ort of agreement between the operators.=20 At the time when the solution in 24.237 was designed (pointed at in Ivo's p= roposal), there was no IETF solution available. So I guess it would be grea= t if the draft does not make the existing solution invalid. Regards Peter -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Adam Roach Sent: Monday, December 01, 2014 10:05 PM To: Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt On 12/1/14 10:16, Paul Kyzivat wrote: > On 11/28/14 10:28 AM, Ivo Sedlacek wrote: >> Hello, >> >> I think Andrew's proposed statement can be replaced by the statement=20 >> already existing in the draft, i.e. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> If a user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request (such as by requiring >> an extension that disallows any such subscription >> [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request >> MAY be sent within an existing dialog. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> and extended as follows: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> If a user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request (such as by requiring >> an extension that disallows any such subscription >> [I-D.ietf-sipcore-refer-explicit-subscription] >>>or by RFC4488=20 >> together with configuration / application logic in specific=20 >> environment ensuring that implicit subscription is not created<<<),=20 >> the REFER request >> MAY be sent within an existing dialog. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > What criteria do you use to be *certain*? > > Some agreement of compliance to some specification seems to be required. > > I gather that what you have in mind is that both ends have been=20 > verified to conform to particular versions of the IMS specification. > Do you ever really know that for certain in the presence of gateways=20 > to foreign devices? Right; this is the real problem. The assumption that this is somehow "safe"= to do because of some unsignaled, un-negotiated hidden agreement is extrem= ely fragile and way outside the various extension mechanisms that SIP makes= use of. Walled gardens grow doors. You don't want things to break in spectacular an= d undiagnosable ways when they do. I'm sad that some networks have decided = to ignore the exact parts of specs that were designed to foster interop and= prevent these surprise behaviors, and I see dangerous precedent in codifyi= ng this misbehavior as proposed above. Walled gardens grow doors faster than you're probably willing to believe. I= 'm frankly astonished by how quickly IMS has turned its eyes to WebRTC, ask= ing for special accommodation for features particular to 3GPP specification= s (cf. AMR). That only goes so far: you won't readily see JavaScript SIP st= acks conforming to this hidden, unnegotiated agreement that presumably exis= ts in IMS (but not elsewhere). It's an honest-to-goodness protocol fork, an= engineered incompatibility. Walled gardens grow doors. It's time to start cleaning up the IMS garden to= match SIP behavior, rather than handing out indulgences for its past sins. You're trying to fix this in the wrong SDO. /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Dec 3 11:27:33 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C19A1A1EEE for ; Wed, 3 Dec 2014 11:27: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 161aYs9cKQbC for ; Wed, 3 Dec 2014 11:27:28 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9C91A1BF5 for ; Wed, 3 Dec 2014 11:27:28 -0800 (PST) Received: from xct106cnc.rim.net ([10.65.161.206]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 03 Dec 2014 14:27:27 -0500 Received: from XCT112CNC.rim.net (10.65.161.212) by XCT106CNC.rim.net (10.65.161.206) with Microsoft SMTP Server (TLS) id 14.3.210.2; Wed, 3 Dec 2014 14:27:27 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT112CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Wed, 3 Dec 2014 14:27:27 -0500 From: Andrew Allen To: Brett Tate , "draft-sparks-sipcore-refer-clarifications@tools.ietf.org" , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-sparks-sipcore-refer-clarifications-05: comments Thread-Index: Ac/9E8AR1A33V2yxS3W3NSzKRX717QHSlWOAAo7SyYAAG8Bo4A== Date: Wed, 3 Dec 2014 19:27:26 +0000 Message-ID: References: <546CF80D.4010005@nostrum.com> <838cc9cbef8fcdf18d0744f67b5ce69c@mail.gmail.com> In-Reply-To: <838cc9cbef8fcdf18d0744f67b5ce69c@mail.gmail.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/P75mRD6iJVr_0sy87gqVn7KKuog Subject: Re: [sipcore] draft-sparks-sipcore-refer-clarifications-05: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 19:27:30 -0000 Brett We should focus next on solving the issues identified in draft-kaplan-dispa= tch-gruu-problematic. Andrew -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett Tate Sent: Tuesday, December 02, 2014 3:35 PM To: draft-sparks-sipcore-refer-clarifications@tools.ietf.org; sipcore@ietf.= org Subject: Re: [sipcore] draft-sparks-sipcore-refer-clarifications-05: commen= ts Hi, Thanks for the response; reply is inline. >> Is there a reason why not relaxing the requirement for REFER=20 >> notifiers which only send NOTIFY with Subscription-State terminated? > > Such a thing would be very unusual It is not unusual. RFC 3515 explicitly discusses it. "Note that agents accepting REFER and not wishing to hold subscription sta= te can terminate the subscription with this initial NOTIFY." "A minimal, but complete, implementation can respond with a single NOTIFY = containing either the body: SIP/2.0 100 Trying" > But even if you could guarantee such unique conditions, there is=20 > always the possibility that the NOTIFY could be answered with a=20 > 503/Retry-After, or any other response indicating that the NOTIFY=20 > needs to be reconditioned and submitted again, during which time there=20 > is dialog reusage. As far as I know, RFC 6665 indicates that the additional dialog usage has n= ot been created. >> For instance, RFC 6665 section 4.4.1 indicates that the NOTIFY does=20 >> not create a dialog usage. >> >> "Dialogs usages are created upon completion of a NOTIFY transaction >> for a new subscription, unless the NOTIFY request contains a >> "Subscription-State" of "terminated."" > > Sigh. I should have argued harder for "created and immediately=20 > destroyed" when we were working on 6665 instead settling on this text,=20 > because of the possibility pointed to above of getting a non-200=20 > response that indicates something should be changed (or delayed) and=20 > the request resubmitted. Concerning sigh, me too. If I had known that the mandatory NOTIFY would ev= entually lead to mandatory GRUU, I might have argued harder to remove the m= andate during the switch from BYE Also to REFER. And sigh again because the issues raised by draft-kaplan-dispatch-gruu-prob= lematic still exist. _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Dec 3 14:51:59 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1AE1A6F3C for ; Wed, 3 Dec 2014 14:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 dzVW_8OhU3xp for ; Wed, 3 Dec 2014 14:51:47 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B798C1A6F01 for ; Wed, 3 Dec 2014 14:51:46 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 273B74F6FB9CE; Wed, 3 Dec 2014 22:51:39 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sB3Mph4L005120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Dec 2014 23:51:44 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.25]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 23:51:43 +0100 From: "DRAGE, Keith (Keith)" To: "Olle E. Johansson" , Simon Perreault Thread-Topic: [sipcore] Review of draft-ietf-sipcore-dns-dual-stack-01 Thread-Index: AQHQC/RCz7YU2Wk/30q0JsLpxQoNxZx4CVGAgAYeacA= Date: Wed, 3 Dec 2014 22:51:42 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B28BCD4@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <9A8678A7-6527-467C-B914-86F7241E34C4@edvina.net> In-Reply-To: <9A8678A7-6527-467C-B914-86F7241E34C4@edvina.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B28BCD4FR712WXCHMBA11zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/4WzGgD2qTrd08zp2RvIlGFXI7T4 Cc: "sipcore@ietf.org" , "draft-ietf-sipcore-dns-dual-stack@tools.ietf.org" Subject: Re: [sipcore] Review of draft-ietf-sipcore-dns-dual-stack-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 22:51:53 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B28BCD4FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding the SHOULD in 4.1 I think what needs to happen here is to make it= clearer that it is a quote from RFC 2872, as normatively referenced by RFC= 3263, and presumably therefore not a new requirement. Or have I missed something. Keith ________________________________ From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Olle E. Johans= son Sent: 29 November 2014 21:11 To: Simon Perreault Cc: sipcore@ietf.org; Olle E Johansson; draft-ietf-sipcore-dns-dual-stack@t= ools.ietf.org Subject: Re: [sipcore] Review of draft-ietf-sipcore-dns-dual-stack-01 On 29 Nov 2014, at 17:47, Simon Perreault > wrote: All, In Honolulu I agreed to review this draft. Here's my review! Simon Major =3D=3D=3D=3D=3D - It's not clear to me whether Section 4.1 advocates parallel connections o= r not. Is Happy Eyeballs to be applied or not? Or are we not recommending o= ne way or another? This needs to be made more explicit. We tried to avoid that to prepare for another draft that talks about the co= nnections. This draft focuses on making both the IPv4 and IPv6 candidates available. - The guidance in Section 4.2 could benefit from stronger normative languag= e: When indicating address family preference through SRV, IPv4-only and/ or IPv6-only clients should be prepared to handle SRV record sets that don't resolve into an ip address in the address family used by that client. In such a case, the client should simply proceed to the next priority and try the hostnames in the alternate address family. Suggestion: s/should/MUST/g Agree. And please remove the "and try the hostnames in the alternate address famil= y." part, which makes no sense (a hostname cannot be "in an address family"= ). Minor =3D=3D=3D=3D=3D - Should this draft formally update RFC 3263? At one point it did, but the wg - especially Cullen Jennings - did not acce= pt it. I personally still think it's needed. - In section 1, has this been resolved? [[TODO: Sync with Vijay Gurbani on impacts of this draft to RFC 6157, especially relative to the additional requirement that DNS be populated such that a certain address family is preferred.]] It's been in planning for a long time - we have a set date in december now. - Please remove normative language from section 1 (i.e., the SHOULD in the = last paragraph). - Section 4.1: Happy Eyeballs [RFC6555] has proven= that looking up the "A or AAAA record" is not an effective practice for dual-stack clients and that it can add significant connection delay and greatly degrade user experience. It is not Happy Eyeballs which has proven that, it is experience with dual-= stack. Suggestion: "Experience with dual-stack has proven that...". - Section 4.1: The dual-stack client SHOULD perform an A and AAAA record lookup of the domain name and add the respective IPv4/IPv6 addresses to the list of IP addresses to be contacted. Suggested rewording: "A dual-stack client SHOULD perform A and AAAA record = lookups of the domain name and add all resulting IPv4 and/or IPv6 addresses= to the list of IP addresses to be contacted." THe normative language here is actually RFC 2782 - DNS SRV. Maybe we should= avoid "should" here. Nits =3D=3D=3D - In the abstract, add a reference to the Happy Eyeballs RFC. - Section 4.1: Once the transport protocol has been determined, the procedure for discovering an ip address s/ip/IP/ Thank you very much for your review! We'll update the draft. /O _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_949EF20990823C4C85C18D59AA11AD8B28BCD4FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Regarding the SHOULD in 4.1 I thi= nk what needs to happen here is to make it clearer that it is a quote from = RFC 2872, as normatively referenced by RFC 3263, and presumably therefore not a new requirement.
 
Or have I missed something.
 
Keith

From: sipcore [mailto:sipcore-bounc= es@ietf.org] On Behalf Of Olle E. Johansson
Sent: 29 November 2014 21:11
To: Simon Perreault
Cc: sipcore@ietf.org; Olle E Johansson; draft-ietf-sipcore-dns-dual-= stack@tools.ietf.org
Subject: Re: [sipcore] Review of draft-ietf-sipcore-dns-dual-stack-0= 1


On 29 Nov 2014, at 17:47, Simon Perreault <sperreault@jive.com> wrote:

All,

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

Simon



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

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

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

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

Suggestion: s/should/MUST/g
Agree.

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


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

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

- In section 1, has this been resolved?

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


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

- Section 4.1:

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

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

- Section 4.1:

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

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


Nits
=3D=3D=3D

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

- Section 4.1:

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

s/ip/IP/

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

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

--_000_949EF20990823C4C85C18D59AA11AD8B28BCD4FR712WXCHMBA11zeu_-- From nobody Wed Dec 3 23:57:24 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022F21A880E for ; Wed, 3 Dec 2014 23:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfdIryzfgHZl for ; Wed, 3 Dec 2014 23:57:17 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 4480F1A88DD for ; Wed, 3 Dec 2014 23:57:15 -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 DF02293C2A3; Thu, 4 Dec 2014 07:56:30 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_DD132545-487D-44F2-8FD6-7BB1A5389CD2" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Olle E. Johansson" In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B28BCD4@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 4 Dec 2014 08:57:13 +0100 Message-Id: <17960B77-D25A-4135-844E-51FCEDFC51D0@edvina.net> References: <9A8678A7-6527-467C-B914-86F7241E34C4@edvina.net> <949EF20990823C4C85C18D59AA11AD8B28BCD4@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/ZP7i-FLDgRWm4Kk-DHRUSVL1eOs Cc: "sipcore@ietf.org" , Olle E Johansson , "draft-ietf-sipcore-dns-dual-stack@tools.ietf.org" Subject: Re: [sipcore] Review of draft-ietf-sipcore-dns-dual-stack-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2014 07:57:23 -0000 --Apple-Mail=_DD132545-487D-44F2-8FD6-7BB1A5389CD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 03 Dec 2014, at 23:51, DRAGE, Keith (Keith) = wrote: > Regarding the SHOULD in 4.1 I think what needs to happen here is to = make it clearer that it is a quote from RFC 2872, as normatively = referenced by RFC 3263, and presumably therefore not a new requirement. The problem is that 3263 is very hard to parse here as it says "A or = AAAA" in so many places, something that has been copied to a lot of other documents, including the MSRP RFC. Did RFC 3263 modify = RFC 2872 or is the normative reference to 2872 overriding all this text?=20 For a developer without knowledge of RFC parsing it's very hard to = figure this out. If you're tasked with developing a SIP stack, I think you want to follow 3263 and you end up with a bad = solution. In order to avoid confusion, this draft intends to make it very clear = that 2872 is the one to follow. We can make that clearer. Thank you for your feedback, Keith! /O > Or have I missed something. > =20 > Keith >=20 > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Olle E. = Johansson > Sent: 29 November 2014 21:11 > To: Simon Perreault > Cc: sipcore@ietf.org; Olle E Johansson; = draft-ietf-sipcore-dns-dual-stack@tools.ietf.org > Subject: Re: [sipcore] Review of draft-ietf-sipcore-dns-dual-stack-01 >=20 >=20 > On 29 Nov 2014, at 17:47, Simon Perreault wrote: >=20 >> All, >>=20 >> In Honolulu I agreed to review this draft. Here's my review! >>=20 >> Simon >>=20 >>=20 >>=20 >> Major >> =3D=3D=3D=3D=3D >>=20 >> - It's not clear to me whether Section 4.1 advocates parallel = connections or not. Is Happy Eyeballs to be applied or not? Or are we = not recommending one way or another? This needs to be made more = explicit. > We tried to avoid that to prepare for another draft that talks about = the connections. This draft focuses on making > both the IPv4 and IPv6 candidates available. >>=20 >> - The guidance in Section 4.2 could benefit from stronger normative = language: >>=20 >> When indicating address family preference through SRV, IPv4-only = and/ >> or IPv6-only clients should be prepared to handle SRV record sets >> that don't resolve into an ip address in the address family used = by >> that client. In such a case, the client should simply proceed to = the >> next priority and try the hostnames in the alternate address = family. >>=20 >> Suggestion: s/should/MUST/g > Agree. >>=20 >> And please remove the "and try the hostnames in the alternate address = family." part, which makes no sense (a hostname cannot be "in an address = family"). >>=20 >>=20 >> Minor >> =3D=3D=3D=3D=3D >>=20 >> - Should this draft formally update RFC 3263? > At one point it did, but the wg - especially Cullen Jennings - did not = accept it. I personally still think it's needed. >>=20 >> - In section 1, has this been resolved? >>=20 >> [[TODO: Sync with Vijay Gurbani on impacts of this draft to RFC = 6157, >> especially relative to the additional requirement that DNS be >> populated such that a certain address family is preferred.]] > It's been in planning for a long time - we have a set date in december = now. >=20 >>=20 >> - Please remove normative language from section 1 (i.e., the SHOULD = in the last paragraph). >>=20 >> - Section 4.1: >>=20 >> Happy Eyeballs [RFC6555] has proven that looking up the "A or AAAA >> record" is not an effective practice for dual-stack clients and = that >> it can add significant connection delay and greatly degrade user >> experience. >>=20 >> It is not Happy Eyeballs which has proven that, it is experience with = dual-stack. Suggestion: "Experience with dual-stack has proven that...". >>=20 >> - Section 4.1: >>=20 >> The dual-stack client SHOULD perform an A and AAAA record = lookup >> of the domain name and add the respective IPv4/IPv6 addresses = to >> the list of IP addresses to be contacted. >>=20 >> Suggested rewording: "A dual-stack client SHOULD perform A and AAAA = record lookups of the domain name and add all resulting IPv4 and/or IPv6 = addresses to the list of IP addresses to be contacted." > THe normative language here is actually RFC 2782 - DNS SRV. Maybe we = should avoid "should" here. >>=20 >>=20 >> Nits >> =3D=3D=3D >>=20 >> - In the abstract, add a reference to the Happy Eyeballs RFC. >>=20 >> - Section 4.1: >>=20 >> Once the transport protocol has been determined, the procedure for >> discovering an ip address >>=20 >> s/ip/IP/ >=20 > Thank you very much for your review! We'll update the draft. >=20 > /O >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 --Apple-Mail=_DD132545-487D-44F2-8FD6-7BB1A5389CD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 03 Dec 2014, at 23:51, DRAGE, Keith = (Keith) <keith.drage@alcatel-lucent.= com> wrote:

Regarding the SHOULD in 4.1 = I think what needs to happen here is to make it clearer that it is a = quote from RFC 2872, as normatively referenced by RFC 3263, and presumably therefore not a new = requirement.
The problem is that = 3263 is very hard to parse here as it says "A or AAAA" in so many = places, something that has been copied
to a lot of other = documents, including the MSRP RFC. Did RFC 3263 modify RFC 2872 or is = the normative reference to 2872
overriding all this = text? 

For a developer without knowledge = of RFC parsing it's very hard to figure this out. If you're tasked with = developing
a SIP stack, I think you want to follow 3263 and = you end up with a bad solution.

In order to = avoid confusion, this draft intends to make it very clear that 2872 is = the one to follow. We can make that = clearer.

Thank you for your feedback, = Keith!

/O


Or have I missed = something.
 
Keith

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Olle E. Johansson
Sent: 29 November 2014 21:11
To: Simon Perreault
Cc: sipcore@ietf.org; = Olle E Johansson; draft-iet= f-sipcore-dns-dual-stack@tools.ietf.org
Subject: Re: [sipcore] Review of = draft-ietf-sipcore-dns-dual-stack-01


On 29 Nov 2014, at 17:47, Simon Perreault <sperreault@jive.com> = wrote:

All,

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

Simon



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

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

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

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

Suggestion: s/should/MUST/g
Agree.

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


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

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

- In section 1, has this been resolved?

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


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

- Section 4.1:

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

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

- Section 4.1:

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

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


Nits
=3D=3D=3D

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

- Section 4.1:

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

s/ip/IP/

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

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


= --Apple-Mail=_DD132545-487D-44F2-8FD6-7BB1A5389CD2-- From nobody Thu Dec 4 02:17:18 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517241A0137 for ; Thu, 4 Dec 2014 02:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eepZeRj7PfJ7 for ; Thu, 4 Dec 2014 02:17:15 -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 252FF1A0164 for ; Thu, 4 Dec 2014 02:17:13 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-ed-548034a7b298 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A4.71.24955.7A430845; Thu, 4 Dec 2014 11:17:12 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 11:17:11 +0100 From: Christer Holmberg To: Andrew Allen , "Leis, Peter (NSN - DE/Munich)" , ext Adam Roach , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQBeGiFbV1ztW9cUOimw2I9kop/5x1Mf8AgABuBICAAINygIAE5fuAgAAvDgCAANc/AIACMF4AgAEKyRA= Date: Thu, 4 Dec 2014 10:17:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D578385@ESESSMB209.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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM+Jvje4Kk4YQg4mnmCzuz9vKaLHn7yJ2 i2XntzFbrNhwgNXi649NbA6sHn/ff2DymNWwlt1jyZKfQNbOJyweP9dfZQ9gjeKySUnNySxL LdK3S+DKWP7pIVPBL4OKufv3MzUw7tDoYuTgkBAwkXi8uaaLkRPIFJO4cG89WxcjF4eQwBFG icff/zBBOIsZJdrmXmEBaWATsJDo/qcNEhcRuMQocaXlLCtIt7BAsMTrzZ0sILaIQIjEzPU7 GCHsJInpe7eB1bAIqEj0Nk5iApnDK+ArsXSzOsT8c8wSp2/fYAaJcwp4StyYog5Szgh00PdT a5hAbGYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf6wQvyhJTNuaBlGuI7Fg9yc2CFtbYtnC12Dl vAKCEidnPmGZwCg6C8nUWUhaZiFpmYWkZQEjyypG0eLU4qTcdCNjvdSizOTi4vw8vbzUkk2M wPg6uOW36g7Gy28cDzEKcDAq8fAanKsPEWJNLCuuzD3EKM3BoiTOu/DcvGAhgfTEktTs1NSC 1KL4otKc1OJDjEwcnFINjG3vK99kT45ge7Lp8TvGjbcvucevM7qZ8PiHgKK/1cLmNM7W2Rx7 PvlP+/Z0c/P5VRYrA7hPP+WZlrQvgOv6my2LHwXqqrfOdvL+FX8hV/dU8z2Tg+1bP/MGr3sf sS13qsB9V5VEudz5z2NvTdny5oHACcVf7fZnr7VxMv37euSjrol+3bltq3yUWIozEg21mIuK EwFKx4AWkAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/gSvc6aNpmeqgS_LMVpkVKu0gbz8 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, 04 Dec 2014 10:17:17 -0000 Hi, I support Andrew's suggestion. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew Allen Sent: 3. joulukuuta 2014 21:21 To: Leis, Peter (NSN - DE/Munich); ext Adam Roach; Paul Kyzivat; sipcore@ie= tf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Maybe the way out of this rat hole is to discuss in the text and allow lega= cy application usages (similar to the legacy usages for INFO). So SIP stac= ks could be considered RFC 6665 compliant with legacy application usages us= ing RFC 4488 and feature tags identifying application specific behavior tha= t ensures that dialog reuse does not occur but that we deprecate such usage= s for any new applications that are developed and insist on the use of [I-D= .ietf-sipcore-refer-explicit-subscription] going forward.=20 =09 As Christer said: The only reason these "special environment" use-cases exist to begin with i= s because previously there was no "pure" protocol mechanism for preventing = implicit subscriptions. And, as they have existed for a while already, and = have been implemented, they will not suddenly go away just because we now h= ave [I-D.ietf-sipcore-refer-explicit-subscription]. Neither will they go aw= ay just because we now have drafts clarifying some RFCs.=20 BUT, because we now DO have a "pure" protocol mechanism [I-D.ietf-sipcore-r= efer-explicit-subscription] for preventing implicit subscriptions, I assume= there will be no NEW "special environment" use-cases in future - people WI= LL use [I-D.ietf-sipcore-refer-explicit-subscription] :) Is that something we could all agree on as a compromise? Andrew -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Leis, Peter (N= SN - DE/Munich) Sent: Tuesday, December 02, 2014 4:56 AM To: ext Adam Roach; Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hi, The specific environment is described in 3GPP TS 24.237. For the specific c= ase, both ends of the signaling comply to this spec, both ends of the signa= ling are network nodes. These network nodes either reside in the same netwo= rk, or reside in different networks, and in this case there would be some s= ort of agreement between the operators.=20 At the time when the solution in 24.237 was designed (pointed at in Ivo's p= roposal), there was no IETF solution available. So I guess it would be grea= t if the draft does not make the existing solution invalid. Regards Peter -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Adam Roach Sent: Monday, December 01, 2014 10:05 PM To: Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt On 12/1/14 10:16, Paul Kyzivat wrote: > On 11/28/14 10:28 AM, Ivo Sedlacek wrote: >> Hello, >> >> I think Andrew's proposed statement can be replaced by the statement=20 >> already existing in the draft, i.e. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> If a user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request (such as by requiring >> an extension that disallows any such subscription >> [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request >> MAY be sent within an existing dialog. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> and extended as follows: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> If a user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request (such as by requiring >> an extension that disallows any such subscription >> [I-D.ietf-sipcore-refer-explicit-subscription] >>>or by RFC4488=20 >> together with configuration / application logic in specific=20 >> environment ensuring that implicit subscription is not created<<<),=20 >> the REFER request >> MAY be sent within an existing dialog. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > What criteria do you use to be *certain*? > > Some agreement of compliance to some specification seems to be required. > > I gather that what you have in mind is that both ends have been=20 > verified to conform to particular versions of the IMS specification. > Do you ever really know that for certain in the presence of gateways=20 > to foreign devices? Right; this is the real problem. The assumption that this is somehow "safe"= to do because of some unsignaled, un-negotiated hidden agreement is extrem= ely fragile and way outside the various extension mechanisms that SIP makes= use of. Walled gardens grow doors. You don't want things to break in spectacular an= d undiagnosable ways when they do. I'm sad that some networks have decided = to ignore the exact parts of specs that were designed to foster interop and= prevent these surprise behaviors, and I see dangerous precedent in codifyi= ng this misbehavior as proposed above. Walled gardens grow doors faster than you're probably willing to believe. I= 'm frankly astonished by how quickly IMS has turned its eyes to WebRTC, ask= ing for special accommodation for features particular to 3GPP specification= s (cf. AMR). That only goes so far: you won't readily see JavaScript SIP st= acks conforming to this hidden, unnegotiated agreement that presumably exis= ts in IMS (but not elsewhere). It's an honest-to-goodness protocol fork, an= engineered incompatibility. Walled gardens grow doors. It's time to start cleaning up the IMS garden to= match SIP behavior, rather than handing out indulgences for its past sins. You're trying to fix this in the wrong SDO. /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Dec 4 05:16:47 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBF271A1A23 for ; Thu, 4 Dec 2014 05:16:35 -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 TfL4lAvOz2T0 for ; Thu, 4 Dec 2014 05:16:26 -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 5BCB91A1A54 for ; Thu, 4 Dec 2014 05:16:03 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-4e-54805e91f1d5 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 64.CC.04076.19E50845; Thu, 4 Dec 2014 14:16:01 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 14:16:00 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: Allow semantics Thread-Index: AdAPw62Tjql+FzwKRlGZDOPC6tiwAQ== Date: Thu, 4 Dec 2014 13:16:00 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D578A28@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_7594FB04B1934943A5C02806D1A2204B1D578A28ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyM+Jvje7EuIYQgykvpS2+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDXrtjEVNOpXfHtS0MD4XqOLkZNDQsBE4tmsTawQtpjEhXvr 2boYuTiEBI4wStyasosRwlnMKNH+FCTDwcEmYCHR/U8bpEFEQFNi+bet7CC2sICExOTlv5kh 4rISE/s+Qtl6Er2/dzCBtLIIqEgcXFUDYvIK+EpM3R8BUsEItPb7qTVMIDazgLjErSfzmSDO EZBYsuc8M4QtKvHy8T9WkFYJASWJaVvTIMrzJTb+62EDsXkFBCVOznzCMoFRaBaSSbOQlM1C UgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMYoWpxYX56YbGemlFmUmFxfn5+nlpZZs YgTGwsEtv612MB587niIUYCDUYmH1+BcfYgQa2JZcWXuIUZpDhYlcd6F5+YFCwmkJ5akZqem FqQWxReV5qQWH2Jk4uCUamAUurzT6t2mS1Mzt01OtN5zb/ELZn/9aWwx+gZGqzyOXM3iVjX3 ZhGWuli1ZRfHgsmOS2LXKC56uSN3inOSIr/k5jW85+u3W8jsrT1pmj+Zd7XpoVJf+Z9hft+F ZO4fyf+y1+2srM+aI3NSrGXYluQ/49fq2qRm7LRNI65TYmr347XdD+RfCS5WYinOSDTUYi4q TgQA6LbpBGYCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/zMnQT3J9qzQuuT8_st5s2sClv4Q Subject: [sipcore] Allow semantics 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, 04 Dec 2014 13:16:36 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D578A28ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Section 13.2.1 of RFC 3261 says: "An Allow header field (Section 20.5) SHOULD be present in the INVITE. It indicates what methods can be invoked within a dialog, o= n the UA sending the INVITE, for the duration of the dialog." Section 20.5 of RFC 3261 says: "The Allow header field lists the set of methods supported by the UA generating the message. ... Example: Allow: INVITE, ACK, OPTIONS, CANCEL, BYE" Section 4.1.1 of RFC 6665 says: "The presence of "SUBSCRIBE" in the "Allow" header field of any request or response indicates support for SIP events;" It is unclear whether the Allow header field e.g. in an INVITE request indi= cates the methods supported within that dialog, or whether it indicates the= methods supported by the UA in general. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D578A28ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Section 13.2.1 of RFC 3261 says:

 

“An Allow header = field (Section 20.5) SHOULD be present in the INVITE.

         &nb= sp;      It indicates what methods can be invoked = within a dialog, on the UA

         &nb= sp;      sending the INVITE, for the duration of t= he dialog.”

 

 

Section 20.5 of RFC 3261 says:

 

“The Allow header= field lists the set of methods supported by the UA

         &nb= sp;      generating the message.

 

        &nbs= p;       …

 

         &nb= sp;      Example:

 

         &nb= sp;            =           Allow: INVITE, ACK, = OPTIONS, CANCEL, BYE”

 

 

Section 4.1.1 of RFC 6665 says:

 

“The presence of = "SUBSCRIBE" in the "Allow" header field of any

         &nb= sp;      request or response indicates support for= SIP events;”

 

 

It is unclear whether the Allow header field e.g. in= an INVITE request indicates the methods supported within that dialog, or w= hether it indicates the methods supported by the UA in general.<= /p>

 

Regards,

 

Christer

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D578A28ESESSMB209erics_-- From nobody Thu Dec 4 08:41:51 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1291AD4DF for ; Thu, 4 Dec 2014 08:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTOdisBvzElj for ; Thu, 4 Dec 2014 08:41:46 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76F051AD4B7 for ; Thu, 4 Dec 2014 08:41:46 -0800 (PST) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-11v.sys.comcast.net with comcast id PUgH1p0012VvR6D01Uhlm4; Thu, 04 Dec 2014 16:41:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-19v.sys.comcast.net with comcast id PUhl1p00C3Ge9ey01UhlDb; Thu, 04 Dec 2014 16:41:45 +0000 Message-ID: <54808EC9.6070202@alum.mit.edu> Date: Thu, 04 Dec 2014 11:41:45 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D578A28@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D578A28@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1417711305; bh=5S0rdpJdesSsoz5bO4gO0PUk0pCXCRzDjaY6ApqBUis=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eVhGHn9cfc9i/3xuaJB2dbljYPJOCG1HzrNgQc9WUO+CSVkx4j0nO0x+vwIOX+joM q24k3yIfCXFW8Af/II58NgfG2c5xrqFndldUjmSPd6qsPcucc6dkqqlZQul2tnNtfv b0SqCuyLFibIwUN+0QO+iZDFZmlUNYSrdLHxLL5Kwjo7w//OD0PFIgEwkt8VG9WRBp jnOwS9lvzbukBSFlzttHKXIwNTLOCdWogjXgSUkt3N3v+VMQu4xnif3m3oznCgri8A UZA1PtrDqxCsS4wtpHXimzMrwx63OFU/3mUG1zUsATKaAGCmsGmfysUar5N7dsSnSp fzSJLpK3SVE+w== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/wt8RIi4UJxqgGheqaXoBN3h0RlY Subject: Re: [sipcore] Allow semantics 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, 04 Dec 2014 16:41:47 -0000 On 12/4/14 8:16 AM, Christer Holmberg wrote: > Hi, > > Section 13.2.1 of RFC 3261 says: > > “An Allow header field (Section 20.5) SHOULD be present in the INVITE. > > It indicates what methods can be invoked within a > dialog, on the UA > > sending the INVITE, for the duration of the dialog.” > > Section 20.5 of RFC 3261 says: > > “The Allow header field lists the set of methods supported by the UA > > generating the message. > > … > > Example: > > Allow: INVITE, ACK, OPTIONS, CANCEL, BYE” > > Section 4.1.1 of RFC 6665 says: > > “The presence of "SUBSCRIBE" in the "Allow" header field of any > > request or response indicates support for SIP events;” > > It is unclear whether the Allow header field e.g. in an INVITE request > indicates the methods supported within that dialog, or whether it > indicates the methods supported by the UA in general. This ambiguity exists for a number of similar header fields: - Accept - Accept-Encoding - Accept-Language - Allow - Require - Supported - Unsupported For instance, what does Allow mean in out-of-dialog OPTIONS? In general there can be nuances in support for these things that can't be expressed in these header fields. (For instance, supported only in-dialog, supported only in particular dialog usages, supported for some users but not others, etc.) Do you think we could find sufficient interest for a task to firm this up? Thanks, Paul From nobody Thu Dec 4 08:54:38 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB671AD4AE for ; Thu, 4 Dec 2014 08:54: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 t6-WTJ-9GXNl for ; Thu, 4 Dec 2014 08:54:34 -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 461831AD4B7 for ; Thu, 4 Dec 2014 08:54:34 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-4f-548091c84d06 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C6.5B.24955.8C190845; Thu, 4 Dec 2014 17:54:32 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 17:54:32 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Allow semantics Thread-Index: AdAPw62Tjql+FzwKRlGZDOPC6tiwAQAFSEyAAAJSOhA= Date: Thu, 4 Dec 2014 16:54:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D57A6FA@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D578A28@ESESSMB209.ericsson.se> <54808EC9.6070202@alum.mit.edu> In-Reply-To: <54808EC9.6070202@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje6JiQ0hBq/2KFqs2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAldGz4Em5oITghUP5r1ja2D8wdPFyMkhIWAi 8XNuKwuELSZx4d56ti5GLg4hgSOMEgdWHoZyFjNKLOk+B1TFwcEmYCHR/U8bpEFEIFDi6pIJ zCC2sICaxM49Kxkh4uoS5z/dZIGwrST6f39hA7FZBFQkpv17AxbnFfCV+LmzE6xXSCBfYumm 12A1nAI6EkevXgOrYQQ66PupNUwgNrOAuMStJ/OZIA4VkFiy5zwzhC0q8fLxP1YIW0micckT Voh6HYkFuz+xQdjaEssWvmaG2CsocXLmE5YJjKKzkIydhaRlFpKWWUhaFjCyrGIULU4tTspN NzLWSy3KTC4uzs/Ty0st2cQIjJODW36r7mC8/MbxEKMAB6MSD6/BufoQIdbEsuLK3EOM0hws SuK8C8/NCxYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAOFncL6RtnXy03eUO98snbLwZDiaZ snmwKqXKPtk17UC52v1DpcufdnFt/eL1c4bqxFzDiex7G1eGMXwpOrE+XSfpysPH+bWfN6jb WG2yfOPvuXix4fszj+LaA9Y6xoV/rJi+0UmIu2xtmmBD/8kpOblTCxa1VwWplMVmlt9am8Xd 6bD8f9lfJZbijERDLeai4kQAe2S7AnQCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Ti8ks2dRv2knKE_a6tOGAZ-F9Ik Subject: Re: [sipcore] Allow semantics 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, 04 Dec 2014 16:54:36 -0000 Hi, >> Section 13.2.1 of RFC 3261 says: >> >> "An Allow header field (Section 20.5) SHOULD be present in the INVITE. >> >> It indicates what methods can be invoked within a=20 >> dialog, on the UA sending the INVITE, for the duration = of the dialog." >> >> Section 20.5 of RFC 3261 says: >> >> "The Allow header field lists the set of methods supported by the UA >> generating the message. >> >> ... >> >> Example: >> >> Allow: INVITE, ACK, OPTIONS, CANCEL, BY= E" >> >> Section 4.1.1 of RFC 6665 says: >> >> "The presence of "SUBSCRIBE" in the "Allow" header field of any >> >> request or response indicates support for SIP events;" >> >> It is unclear whether the Allow header field e.g. in an INVITE request=20 >> indicates the methods supported within that dialog, or whether it=20 >> indicates the methods supported by the UA in general. > > This ambiguity exists for a number of similar header fields: > - Accept > - Accept-Encoding > - Accept-Language > - Allow > - Require > - Supported > - Unsupported > > For instance, what does Allow mean in out-of-dialog OPTIONS? > > In general there can be nuances in support for these things that can't be= expressed in these header=20 > fields. (For instance, supported only in-dialog, supported only in partic= ular dialog usages, supported for some users but not others, etc.) I agree. When it comes to option-tags, I think each option-tag definition n= eeds to define the scope - AND whether the presence in a Require header fie= ld means "MUST support" or "MUST support AND enable". For feature-caps, we did define the scope in the RFC (e.g. a feature-cap ca= rried in an INVITE request only indicate support for a feature within the s= cope of the dialog). > Do you think we could find sufficient interest for a task to firm this up= ? I would for sure be interested. And, I think we have to do it. I get these = kind of questions on a rather frequent basis, and I assume people in other = companies do too - and there is no guarantee we give the same answer :) Regards, Christer From nobody Thu Dec 4 09:00:08 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073121AD4B8 for ; Thu, 4 Dec 2014 08:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aK_Zqnc0Yf4d for ; Thu, 4 Dec 2014 08:59:45 -0800 (PST) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [69.252.207.44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 947DD1A1EFC for ; Thu, 4 Dec 2014 08:59:45 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-12v.sys.comcast.net with comcast id PUy91p0072JGN3p01UzkFp; Thu, 04 Dec 2014 16:59:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-10v.sys.comcast.net with comcast id PUzj1p00f3Ge9ey01UzjNG; Thu, 04 Dec 2014 16:59:44 +0000 Message-ID: <548092FF.6000204@alum.mit.edu> Date: Thu, 04 Dec 2014 11:59:43 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Christer Holmberg , "sipcore@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D578A28@ESESSMB209.ericsson.se> <54808EC9.6070202@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D57A6FA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D57A6FA@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1417712384; bh=F39MPyrhfygizp4DHupMxqnx8VTqVjJE41puKsiPUzk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=k2LoZvTQfulDsLN18CqyNF5EBDHEqWCJWFtiu1rDcAokwtrXzhsbLwN9Jh9X9n4VB Wh+TgMruR9fopcWAwvCEnyEGWF/QNWo+svtC85VKHPYl/RbhTvPY8O8LDP2BC0NE17 cfTBpxIgTCBznBGfq17NWO1a4auKDlQKYS11QpLCmOR87YHM+3j6NAipX+DjY28BVD +UTKn5ckLkeIzn+LjC84gDDUqrzz0hue+M/Iy0NDOeHnpE2fNYyfcAUlT+81Xutva6 44/P9wroteg2DI0Mdczczr/RRoKSCDtbtrLIDgsKjh7jv1DvKcHmod9YKQeXOoqGX1 D0P1pabZxbZ8A== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/5gS3O4NHFJ4oimo3z2_qdqDjOYI Subject: Re: [sipcore] Allow semantics 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, 04 Dec 2014 16:59:47 -0000 On 12/4/14 11:54 AM, Christer Holmberg wrote: >>> It is unclear whether the Allow header field e.g. in an INVITE request >>> indicates the methods supported within that dialog, or whether it >>> indicates the methods supported by the UA in general. >> >> This ambiguity exists for a number of similar header fields: >> - Accept >> - Accept-Encoding >> - Accept-Language >> - Allow >> - Require >> - Supported >> - Unsupported >> >> For instance, what does Allow mean in out-of-dialog OPTIONS? >> >> In general there can be nuances in support for these things that can't be expressed in these header >> fields. (For instance, supported only in-dialog, supported only in particular dialog usages, supported for some users but not others, etc.) > > I agree. When it comes to option-tags, I think each option-tag definition needs to define the scope - AND whether the presence in a Require header field means "MUST support" or "MUST support AND enable". > > For feature-caps, we did define the scope in the RFC (e.g. a feature-cap carried in an INVITE request only indicate support for a feature within the scope of the dialog). > >> Do you think we could find sufficient interest for a task to firm this up? > > I would for sure be interested. And, I think we have to do it. I get these kind of questions on a rather frequent basis, and I assume people in other companies do too - and there is no guarantee we give the same answer :) Others who are interested in working on this: please speak up. Thanks, Paul From nobody Thu Dec 4 18:26:47 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836861A87E1 for ; Thu, 4 Dec 2014 18:26:45 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "From" X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiMuhQEeIShJ for ; Thu, 4 Dec 2014 18:26:44 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65F871A6EE5 for ; Thu, 4 Dec 2014 18:26:42 -0800 (PST) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-06v.sys.comcast.net with comcast id PeSZ1p0042Bo0NV01eSi2u; Fri, 05 Dec 2014 02:26:42 +0000 Received: from hobgoblin.ariadne.com ([174.61.171.170]) by resomta-ch2-05v.sys.comcast.net with comcast id PeSg1p00X3gwEm601eShEb; Fri, 05 Dec 2014 02:26:42 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id sB52Qekb022988; Thu, 4 Dec 2014 21:26:40 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id sB52Qeu6022987; Thu, 4 Dec 2014 21:26:40 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) From: worley@alum.mit.edu (Dale R. Worley) To: Paul Kyzivat In-Reply-To: <54808EC9.6070202@alum.mit.edu> (pkyzivat@alum.mit.edu) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 04 Dec 2014 21:26:40 -0500 Message-ID: <87iohqbzmn.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1417746402; bh=NSD0jSWXunc7v3Y4L5+T7bBImuPhkFV2GmD17H8zuDA=; h=Received:Received:Received:Received:From:From:To:Subject:Date: Message-ID:MIME-Version:Content-Type; b=CuoZn557+4cX+Gprew16f71nyyNYQu8ck8gnXo59r6BWZv8rwSt+IKOWOZHjAKCKZ CyzkTc7+xJiYdJbDh00dt1WQcpPZbiX2/3WLyQ/fO2vGHfaR3yxZPLMfdkxF3fOK3i Ynlpz4Diuv1BaVJchVQ9ryBXrXUWyGJNjE2BSV7FASVGmz8GwpmP5dnHdborMbGIbe xq6Af+5SdwDY43bi/IsnVdKdgatiB32VaZ21BdtanM+YSkuudgaXjAoKHqOQ9lxZfi TaEHTg4tn2nrehWiVMbGKYQTv5SaDSUchuKhecRcMuE4KV2ZnCRxDPC7wZgNyYeDNf 9CZpu6lb30DdQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/HXax1fr7sOamI6N5Fpxqg1XxX9o Cc: sipcore@ietf.org Subject: Re: [sipcore] Allow semantics 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, 05 Dec 2014 02:26:45 -0000 Paul Kyzivat writes: > This ambiguity exists for a number of similar header fields: > - Accept > - Accept-Encoding > - Accept-Language > - Allow > - Require > - Supported > - Unsupported (The Unsupported header is only used in the 420 response to indicate the Require option-tag that was objected to.) > For instance, what does Allow mean in out-of-dialog OPTIONS? > > In general there can be nuances in support for these things that can't > be expressed in these header fields. (For instance, supported only > in-dialog, supported only in particular dialog usages, supported for > some users but not others, etc.) > > Do you think we could find sufficient interest for a task to firm this up? There was a long discussion of this issue some time ago. The result of the discussion was that this sort of specification is inherently inexact, because "whether XYZ is supported" can vary from request to request within a dialog -- there is no way to know in advance that each request will be processed through the same set of proxies, and that the relevant context for processing each request at the UAS will be the same. A UA sending a request must be prepared for any particular aspect of its request to be not-supported. Dale From nobody Thu Dec 4 20:12:36 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C6C1AC3B3 for ; Thu, 4 Dec 2014 20:12:34 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "From" X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTZmWXqQRMmz for ; Thu, 4 Dec 2014 20:12:33 -0800 (PST) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E551AC3AA for ; Thu, 4 Dec 2014 20:12:32 -0800 (PST) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-02v.sys.comcast.net with comcast id PgCY1p00129Cfhx01gCY5E; Fri, 05 Dec 2014 04:12:32 +0000 Received: from hobgoblin.ariadne.com ([174.61.171.170]) by resomta-ch2-03v.sys.comcast.net with comcast id PgCW1p00E3gwEm601gCX0p; Fri, 05 Dec 2014 04:12:31 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id sB54CTVg004232; Thu, 4 Dec 2014 23:12:29 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id sB54CTAL004231; Thu, 4 Dec 2014 23:12:29 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) From: worley@alum.mit.edu (Dale R. Worley) To: Ivo Sedlacek In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127B36DB@ESESSMB301.ericsson.se> (ivo.sedlacek@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 04 Dec 2014 23:12:29 -0500 Message-ID: <877fy6buqa.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1417752752; bh=OxT0QWc4cvGnHOYiqHNRXEku8R0/vibwUIcDYykOKZQ=; h=Received:Received:Received:Received:From:From:To:Subject:Date: Message-ID:MIME-Version:Content-Type; b=wna/Rl4Kj6s9PlJD+z8m5C7Kef60GmrvxlmgZ89WeC327vWjb0dT4K/FdtnHQHJPU YETT4FrpJeYyYj9/BQkV3OjxbdMOBY3kZd0g5Bts/Hi2G2p4zkaK0OYGxrtkKlSoUG G8BA68FBQA7xai90FGekqZJkbt6m+Kj1ppbplOpPTmuwPeGy5buJfs0YdvqsNUd1fj uIDOkuHUGjMcWsnD9ckwzPFVhRXuLGd0QpdwV3t/ldScLe4iqdWU9R+IPXkeB8InJy fzgUwne7qTmc/39vc269jGpCE/MaH0TO4Op0+A0HKh7gTVIm36TA3AfW0gRyF/FDUv rQPPN+LOHIUsA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/vF59n8sDkukvueIjgghsN6v-RHk Cc: sipcore@ietf.org Subject: Re: [sipcore] 503 response with Retry-After header field - request for clarification X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 04:12:34 -0000 Ivo Sedlacek writes: >> It is unclear about "server" being 1) IP address where sent request, 2) source IP address of received response, and/or 3) something else. > > I thought "server" is: > - entire URI (not just IP address and port) in the top Route header field of the request, if there is a Route header field in the request; and > - entire Request-URI (not just IP address and port) of the request, if there is no Route header field in the request. I've not used 503 in implementations. But I would expect that its principal use is to cause the UAC to choose a different target (address/port/protocol) out of the set of targets that the URI resolves to. In order to make that work, the implementation must "blacklist" only a single target, not the targeted URI. Dale From nobody Thu Dec 4 21:09:32 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C6B1AC40A for ; Thu, 4 Dec 2014 21:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcgBWKgRCrOr for ; Thu, 4 Dec 2014 21:09:26 -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 B785A1AC3F9 for ; Thu, 4 Dec 2014 21:09:25 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-ff-54813e03742f Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 20.B7.04076.30E31845; Fri, 5 Dec 2014 06:09:23 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 06:09:23 +0100 From: Christer Holmberg To: "Dale R. Worley" , Paul Kyzivat Thread-Topic: [sipcore] Allow semantics Thread-Index: AQHQEDLmjql+FzwKRlGZDOPC6tiwAZyAct79 Date: Fri, 5 Dec 2014 05:09:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D57B94F@ESESSMB209.ericsson.se> References: <54808EC9.6070202@alum.mit.edu> (pkyzivat@alum.mit.edu),<87iohqbzmn.fsf@hobgoblin.ariadne.com> In-Reply-To: <87iohqbzmn.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D57B94FESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42KZGfG3RpfZrjHEoOGdscWKDQdYLb7+2MRm 8fJEmQOzx9/3H5g8Ju//yuyxZMlPpgDmKC6blNSczLLUIn27BK6MN4s2MhX80q2Y03CCvYFx oXoXIyeHhICJxPXNT1kgbDGJC/fWs3UxcnEICRxhlLjUN5kdwlnMKPFk+U6gDAcHm4CFRPc/ bZAGEYFAiW1dp1lBbGYBTYlHO/cygdjCAmoSO/esZISoUZc4/+kmC4RtJPHs53lmEJtFQEVi 0s1bbCA2r4CvxPT/08F6hQRyJOatPwpWzylgLPFofiNYDSPQcd9PrWGC2CUu0fRlJSvE0QIS S/ZAzJQQEJV4+fgf1D35EmfWnGaHmC8ocXLmE5YJjCKzkLTPQlI2C0kZRNxA4sv721C2tsSy ha+ZIWx9ie73p5mQxRcwsq9iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECIy0g1t+W+1gPPjc 8RCjAAejEg/vBvnGECHWxLLiytxDjNIcLErivAvPzQsWEkhPLEnNTk0tSC2KLyrNSS0+xMjE wSnVwDhR5L/NjHiXd29MVxrU71cQ2h2W3f5acfKr0ISoJomP9/8tOiWf/2Yud1FYhFBA/llb PuaiNJXaH0d5uRf8NTjJuPl4g4L62cd/N11Q+NXdeeRj8e/SsNLDrzUypx22MOKPn6GTufjv 1ydbTa4fWTp/0XLLxMXHdubqRh5kWHdJLCPh1SWN1+xKLMUZiYZazEXFiQDmSSxzlQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/NOQSMQdoxQbQQr3nL-pOJxbU5xY Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Allow semantics 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, 05 Dec 2014 05:09:28 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D57B94FESESSMB209erics_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Hi Dale, When a UA inserts information in a request, it should be clear what the sco= pe of the information is. Regards, Christer Sent from my Windows Phone ________________________________ From: Dale R. Worley Sent: =FD05/=FD12/=FD2014 04:26 To: Paul Kyzivat Cc: sipcore@ietf.org Subject: Re: [sipcore] Allow semantics Paul Kyzivat writes: > This ambiguity exists for a number of similar header fields: > - Accept > - Accept-Encoding > - Accept-Language > - Allow > - Require > - Supported > - Unsupported (The Unsupported header is only used in the 420 response to indicate the Require option-tag that was objected to.) > For instance, what does Allow mean in out-of-dialog OPTIONS? > > In general there can be nuances in support for these things that can't > be expressed in these header fields. (For instance, supported only > in-dialog, supported only in particular dialog usages, supported for > some users but not others, etc.) > > Do you think we could find sufficient interest for a task to firm this up= ? There was a long discussion of this issue some time ago. The result of the discussion was that this sort of specification is inherently inexact, because "whether XYZ is supported" can vary from request to request within a dialog -- there is no way to know in advance that each request will be processed through the same set of proxies, and that the relevant context for processing each request at the UAS will be the same. A UA sending a request must be prepared for any particular aspect of its request to be not-supported. Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_7594FB04B1934943A5C02806D1A2204B1D57B94FESESSMB209erics_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Hi Dale,

When a UA inserts information in a request, it should be clear what the sco= pe of the information is.

Regards,

Christer

Sent from my Windows Phone
From: Dale R. Worley
Sent: =FD05= /=FD12/=FD2014 04:26
To: Paul Kyzivat
Cc: sipcore@ietf.org
Subject: Re: [= sipcore] Allow semantics

Paul Kyzivat <pkyzivat@alum.mit.edu> writes:=
> This ambiguity exists for a number of similar header fields:
> - Accept
> - Accept-Encoding
> - Accept-Language
> - Allow
> - Require
> - Supported
> - Unsupported

(The Unsupported header is only used in the 420 response to indicate the Require option-tag that was objected to.)

> For instance, what does Allow mean in out-of-dialog OPTIONS?
>
> In general there can be nuances in support for these things that can't=
> be expressed in these header fields. (For instance, supported only > in-dialog, supported only in particular dialog usages, supported for <= br> > some users but not others, etc.)
>
> Do you think we could find sufficient interest for a task to firm this= up?

There was a long discussion of this issue some time ago.  The result o= f
the discussion was that this sort of specification is inherently
inexact, because "whether XYZ is supported" can vary from request= to
request within a dialog -- there is no way to know in advance that each
request will be processed through the same set of proxies, and that the
relevant context for processing each request at the UAS will be the
same.

A UA sending a request must be prepared for any particular aspect of its request to be not-supported.

Dale

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore
 --_000_7594FB04B1934943A5C02806D1A2204B1D57B94FESESSMB209erics_-- From nobody Fri Dec 5 00:07:56 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583BE1A00F0 for ; Fri, 5 Dec 2014 00:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_bTXJgC82j2 for ; Fri, 5 Dec 2014 00:07:44 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 268151AC44D for ; Fri, 5 Dec 2014 00:07:43 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sB587WYw012262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 5 Dec 2014 08:07:32 GMT Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sB587PPK007883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Dec 2014 09:07:27 +0100 Received: from DEMUMBX003.nsn-intra.net ([169.254.2.85]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 09:07:26 +0100 From: "Leis, Peter (NSN - DE/Munich)" To: ext Christer Holmberg , Andrew Allen , ext Adam Roach , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQDZL7waMk5ORsmEyvUhfkEzOyiJx1Mf8AgABuBICAAINygIAE5fuAgAAvDgCAANc/AIACMF4AgAEKyRCAAV7P8A== Date: Fri, 5 Dec 2014 08:07:25 +0000 Message-ID: <059F3547244B7F4DB728757635C2DC4B15DB3190@DEMUMBX003.nsn-intra.net> 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> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D578385@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6680 X-purgate-ID: 151667::1417766852-0000658F-8C96ADC7/0/0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/BQAcLAuEgrlhPBOxLIqZyny5U8c 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, 05 Dec 2014 08:07:50 -0000 Hi, The compromise described by Andrew would work for me. Regards Peter -----Original Message----- From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Thursday, December 04, 2014 11:17 AM To: Andrew Allen; Leis, Peter (NSN - DE/Munich); ext Adam Roach; Paul Kyziv= at; sipcore@ietf.org Subject: RE: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hi, I support Andrew's suggestion. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew Allen Sent: 3. joulukuuta 2014 21:21 To: Leis, Peter (NSN - DE/Munich); ext Adam Roach; Paul Kyzivat; sipcore@ie= tf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Maybe the way out of this rat hole is to discuss in the text and allow lega= cy application usages (similar to the legacy usages for INFO). So SIP stac= ks could be considered RFC 6665 compliant with legacy application usages us= ing RFC 4488 and feature tags identifying application specific behavior tha= t ensures that dialog reuse does not occur but that we deprecate such usage= s for any new applications that are developed and insist on the use of [I-D= .ietf-sipcore-refer-explicit-subscription] going forward.=20 =09 As Christer said: The only reason these "special environment" use-cases exist to begin with i= s because previously there was no "pure" protocol mechanism for preventing = implicit subscriptions. And, as they have existed for a while already, and = have been implemented, they will not suddenly go away just because we now h= ave [I-D.ietf-sipcore-refer-explicit-subscription]. Neither will they go aw= ay just because we now have drafts clarifying some RFCs.=20 BUT, because we now DO have a "pure" protocol mechanism [I-D.ietf-sipcore-r= efer-explicit-subscription] for preventing implicit subscriptions, I assume= there will be no NEW "special environment" use-cases in future - people WI= LL use [I-D.ietf-sipcore-refer-explicit-subscription] :) Is that something we could all agree on as a compromise? Andrew -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Leis, Peter (N= SN - DE/Munich) Sent: Tuesday, December 02, 2014 4:56 AM To: ext Adam Roach; Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hi, The specific environment is described in 3GPP TS 24.237. For the specific c= ase, both ends of the signaling comply to this spec, both ends of the signa= ling are network nodes. These network nodes either reside in the same netwo= rk, or reside in different networks, and in this case there would be some s= ort of agreement between the operators.=20 At the time when the solution in 24.237 was designed (pointed at in Ivo's p= roposal), there was no IETF solution available. So I guess it would be grea= t if the draft does not make the existing solution invalid. Regards Peter -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Adam Roach Sent: Monday, December 01, 2014 10:05 PM To: Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt On 12/1/14 10:16, Paul Kyzivat wrote: > On 11/28/14 10:28 AM, Ivo Sedlacek wrote: >> Hello, >> >> I think Andrew's proposed statement can be replaced by the statement=20 >> already existing in the draft, i.e. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> If a user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request (such as by requiring >> an extension that disallows any such subscription >> [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request >> MAY be sent within an existing dialog. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> and extended as follows: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> If a user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request (such as by requiring >> an extension that disallows any such subscription >> [I-D.ietf-sipcore-refer-explicit-subscription] >>>or by RFC4488=20 >> together with configuration / application logic in specific=20 >> environment ensuring that implicit subscription is not created<<<),=20 >> the REFER request >> MAY be sent within an existing dialog. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > What criteria do you use to be *certain*? > > Some agreement of compliance to some specification seems to be required. > > I gather that what you have in mind is that both ends have been=20 > verified to conform to particular versions of the IMS specification. > Do you ever really know that for certain in the presence of gateways=20 > to foreign devices? Right; this is the real problem. The assumption that this is somehow "safe"= to do because of some unsignaled, un-negotiated hidden agreement is extrem= ely fragile and way outside the various extension mechanisms that SIP makes= use of. Walled gardens grow doors. You don't want things to break in spectacular an= d undiagnosable ways when they do. I'm sad that some networks have decided = to ignore the exact parts of specs that were designed to foster interop and= prevent these surprise behaviors, and I see dangerous precedent in codifyi= ng this misbehavior as proposed above. Walled gardens grow doors faster than you're probably willing to believe. I= 'm frankly astonished by how quickly IMS has turned its eyes to WebRTC, ask= ing for special accommodation for features particular to 3GPP specification= s (cf. AMR). That only goes so far: you won't readily see JavaScript SIP st= acks conforming to this hidden, unnegotiated agreement that presumably exis= ts in IMS (but not elsewhere). It's an honest-to-goodness protocol fork, an= engineered incompatibility. Walled gardens grow doors. It's time to start cleaning up the IMS garden to= match SIP behavior, rather than handing out indulgences for its past sins. You're trying to fix this in the wrong SDO. /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Dec 5 02:14:02 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E318B1A00FC for ; Fri, 5 Dec 2014 02:14:00 -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 F4BWuBSigzZB for ; Fri, 5 Dec 2014 02:13: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 C4A031A8961 for ; Fri, 5 Dec 2014 02:13:57 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-96-54818563587a Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3C.16.29772.36581845; Fri, 5 Dec 2014 11:13:55 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.89]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 11:13:55 +0100 From: Ivo Sedlacek To: "Leis, Peter (NSN - DE/Munich)" , Christer Holmberg , Andrew Allen , "ext Adam Roach" , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQDZL7waMk5ORsmEyvUhfkEzOyiJx1Mf8AgABuBICAAINygIAE5fuAgAAvDgCAANc/AIACMF4AgAEKyRCAAV7P8IAAIzpw Date: Fri, 5 Dec 2014 10:13:54 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127B7ECC@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> In-Reply-To: <059F3547244B7F4DB728757635C2DC4B15DB3190@DEMUMBX003.nsn-intra.net> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM+JvjW5Ka2OIgY3F/XlbGS32/F3EbrHs /DZmixUbDrBafP2xic2B1ePv+w9MHrMa1rJ7LFnyE8ja+YTF4+f6q+wBrFFcNimpOZllqUX6 dglcGb1rVjEX7LasaJo6ia2B8Zx+FyMnh4SAicT3TUeYIGwxiQv31rN1MXJxCAkcYZTYuWEn C4SziFHi4JajbCBVbAJ6EhO3HGEFsUUEupgkmiZqgNjCAsESrzd3skDEQyRmrt/BCGHnScyd u40ZxGYRUJGYffok2BxeAV+JLZsXQG27wSLRevceWBGnQIDEphlHwU5iFJCVuPqnF2wQs4C4 xK0n86FOFZBYsuc8M4QtKvHy8T9WCFtRYufZdmaIeh2JBbs/sUHY2hLLFr5mhlgsKHFy5hOW CYyis5CMnYWkZRaSlllIWhYwsqxiFC1OLU7KTTcy0kstykwuLs7P08tLLdnECIyxg1t+G+xg fPnc8RCjAAejEg/vRvnGECHWxLLiytxDjNIcLErivAvPzQsWEkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwKgUzvLvhYptqmx/q/qyBetDeTO6U/vyM9a4zjylI9YkxtF7ICy09ZHKzwf+7HsV mW5/0xeM2eYwS/bBu6ly5W/nhnVOz3lqdclX8/+8u+HpjhKljqW+J8NTzndt7j1ouajV+sza pCPWszcY65yclFLzcOm3lol383ninh1P+Nkz94AwhztvtBJLcUaioRZzUXEiAKecgpOSAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/y5IYSFuHijf2bS7foQA4KxkDm_E 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, 05 Dec 2014 10:14:01 -0000 This compromise would work for me too. Kind regards Ivo 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 Leis, Peter (N= SN - DE/Munich) Sent: 5. prosince 2014 9:07 To: Christer Holmberg; Andrew Allen; ext Adam Roach; Paul Kyzivat; sipcore@= ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hi, The compromise described by Andrew would work for me. Regards Peter -----Original Message----- From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Thursday, December 04, 2014 11:17 AM To: Andrew Allen; Leis, Peter (NSN - DE/Munich); ext Adam Roach; Paul Kyziv= at; sipcore@ietf.org Subject: RE: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hi, I support Andrew's suggestion. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew Allen Sent: 3. joulukuuta 2014 21:21 To: Leis, Peter (NSN - DE/Munich); ext Adam Roach; Paul Kyzivat; sipcore@ie= tf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Maybe the way out of this rat hole is to discuss in the text and allow lega= cy application usages (similar to the legacy usages for INFO). So SIP stac= ks could be considered RFC 6665 compliant with legacy application usages us= ing RFC 4488 and feature tags identifying application specific behavior tha= t ensures that dialog reuse does not occur but that we deprecate such usage= s for any new applications that are developed and insist on the use of [I-D= .ietf-sipcore-refer-explicit-subscription] going forward.=20 =09 As Christer said: The only reason these "special environment" use-cases exist to begin with i= s because previously there was no "pure" protocol mechanism for preventing = implicit subscriptions. And, as they have existed for a while already, and = have been implemented, they will not suddenly go away just because we now h= ave [I-D.ietf-sipcore-refer-explicit-subscription]. Neither will they go aw= ay just because we now have drafts clarifying some RFCs.=20 BUT, because we now DO have a "pure" protocol mechanism [I-D.ietf-sipcore-r= efer-explicit-subscription] for preventing implicit subscriptions, I assume= there will be no NEW "special environment" use-cases in future - people WI= LL use [I-D.ietf-sipcore-refer-explicit-subscription] :) Is that something we could all agree on as a compromise? Andrew -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Leis, Peter (N= SN - DE/Munich) Sent: Tuesday, December 02, 2014 4:56 AM To: ext Adam Roach; Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hi, The specific environment is described in 3GPP TS 24.237. For the specific c= ase, both ends of the signaling comply to this spec, both ends of the signa= ling are network nodes. These network nodes either reside in the same netwo= rk, or reside in different networks, and in this case there would be some s= ort of agreement between the operators.=20 At the time when the solution in 24.237 was designed (pointed at in Ivo's p= roposal), there was no IETF solution available. So I guess it would be grea= t if the draft does not make the existing solution invalid. Regards Peter -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Adam Roach Sent: Monday, December 01, 2014 10:05 PM To: Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt On 12/1/14 10:16, Paul Kyzivat wrote: > On 11/28/14 10:28 AM, Ivo Sedlacek wrote: >> Hello, >> >> I think Andrew's proposed statement can be replaced by the statement=20 >> already existing in the draft, i.e. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> If a user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request (such as by requiring >> an extension that disallows any such subscription >> [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request >> MAY be sent within an existing dialog. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> and extended as follows: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> If a user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request (such as by requiring >> an extension that disallows any such subscription >> [I-D.ietf-sipcore-refer-explicit-subscription] >>>or by RFC4488=20 >> together with configuration / application logic in specific=20 >> environment ensuring that implicit subscription is not created<<<),=20 >> the REFER request >> MAY be sent within an existing dialog. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > What criteria do you use to be *certain*? > > Some agreement of compliance to some specification seems to be required. > > I gather that what you have in mind is that both ends have been=20 > verified to conform to particular versions of the IMS specification. > Do you ever really know that for certain in the presence of gateways=20 > to foreign devices? Right; this is the real problem. The assumption that this is somehow "safe"= to do because of some unsignaled, un-negotiated hidden agreement is extrem= ely fragile and way outside the various extension mechanisms that SIP makes= use of. Walled gardens grow doors. You don't want things to break in spectacular an= d undiagnosable ways when they do. I'm sad that some networks have decided = to ignore the exact parts of specs that were designed to foster interop and= prevent these surprise behaviors, and I see dangerous precedent in codifyi= ng this misbehavior as proposed above. Walled gardens grow doors faster than you're probably willing to believe. I= 'm frankly astonished by how quickly IMS has turned its eyes to WebRTC, ask= ing for special accommodation for features particular to 3GPP specification= s (cf. AMR). That only goes so far: you won't readily see JavaScript SIP st= acks conforming to this hidden, unnegotiated agreement that presumably exis= ts in IMS (but not elsewhere). It's an honest-to-goodness protocol fork, an= engineered incompatibility. Walled gardens grow doors. It's time to start cleaning up the IMS garden to= match SIP behavior, rather than handing out indulgences for its past sins. You're trying to fix this in the wrong SDO. /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Dec 5 04:51:48 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1FD1ACE6A for ; Fri, 5 Dec 2014 04:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 cUTHSD7nFgmr for ; Fri, 5 Dec 2014 04:51:45 -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 02C501ACE69 for ; Fri, 5 Dec 2014 04:51:44 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-95-5481aa5ea7ad Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FC.82.24955.E5AA1845; Fri, 5 Dec 2014 13:51:43 +0100 (CET) Received: from ESESSMB305.ericsson.se ([169.254.5.251]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 13:51:42 +0100 From: =?iso-8859-1?Q?J=F6rgen_Axell?= To: "sipcore@ietf.org" Thread-Topic: RFC 7044 issues Thread-Index: AdAQieJCXKODzM1rQqesYuUK8hDakw== Date: Fri, 5 Dec 2014 12:51:42 +0000 Message-ID: <5AEA7B339C0B944BB33A6939249264AD1A1F04F3@ESESSMB305.ericsson.se> Accept-Language: sv-SE, 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_5AEA7B339C0B944BB33A6939249264AD1A1F04F3ESESSMB305erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+JvjW78qsYQgy+NvBZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRvv9uIIp2RVtm66yNDBOje1i5OSQEDCRmPD8PRuELSZx4d56 IJuLQ0jgCKPElBP/WUASQgKLGSW+nDUCsdkEHCWu/vvDDmKLCGhKLP+2FcwWFpCQuPG1nQki Liux5dYuZghbT6L95XMwm0VARWJh/0qwZbwCvhI7jh1hBLEZgervf78HtotZQFzi1pP5TBAH CUgs2XOeGcIWlXj5+B8rhK0o8fHVPkaI+nyJzbM2M0HMFJQ4OfMJywRGoVlIRs1CUjYLSRlE XE/ixtQpbBC2tsSyha+ZIWxdiRn/DrEgiy9gZF/FKFqcWpyUm25krJdalJlcXJyfp5eXWrKJ ERgRB7f8Vt3BePmN4yFGAQ5GJR7eDfKNIUKsiWXFlbmHGKU5WJTEeReemxcsJJCeWJKanZpa kFoUX1Sak1p8iJGJg1OqgdE4+9oLnxD1/6r8DqIulnKS1Yv5llgtEVe/ESy1gUunb+aD7q5G +4oS3s0VHlmJe9KCpmdunnz27f6s3RZX5p3QZ5R7485i5qd46rpGMscpST1PC1/jjbPnMc8t 9F6bEVmx9eytoMO+gYuM+yXuaE7eaRD+qS1/5sOP+1WPlvkGhiU/a706Q4mlOCPRUIu5qDgR AGX407xpAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/G62poGlfBRxzgMQGxqAZtwVVAB4 Subject: [sipcore] RFC 7044 issues 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, 05 Dec 2014 12:51:47 -0000 --_000_5AEA7B339C0B944BB33A6939249264AD1A1F04F3ESESSMB305erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I am having some difficulty when reading RFC 7044. Is it mandated that a SI= P entity supporting History-Info always inserts a hi-entry? As an example, = in IMS there is an application server handling a diversion service on behal= f of UE-B. For communication forwarding busy, we would have a simplified fl= ow as below. Is the hi-entry with the np-parameter mandated by RFC 7044? If= so, would it be allowed to have index set to 1.1.1 instead of 1.2 for the = diverted INVITE to UE-C? UE-A AS-B = UE-B UE-C ---------------INVITE UE-B----> History-Info:;index=3D1 INVITE UE-B------= ---------> History-Info: :;index=3D1, = ;index=3D1.1,np=3D1 <---------------= --486 (Busy) INVITE UE-C------= ---------------------------------> History-Info:;index=3D1, = ;Reason:sip; cause=3D486;index=3D1.1,np=3D1 = ;index=3D1.2,mp=3D1.1 Another issue with the RFC is rule 2 in section 10.3. In particular the tex= t "as prescribed for basic forwarding" is confusing as basic forwarding is = not defined anywhere. I suspect this text is a remnant from rule 1 in secti= on 4.3.3.1.3 in RFC 4244 which used Basic Forwarding in a more defining man= ner. My guess is that the "basic forwarding" text in RFC 7044 should be a r= eference pointing to the text just above the rules in section 10.3. Can any= one confirm? Regards, J=F6rgen Dr. J=D6RGEN AXELL Senior specialist Business Unit Cloud and IP Ericsson Kistav=E4gen 25 164 80 Stockholm, Sweden Phone +46 10 719 4450 Mobile +46 70 519 4450 Jorgen.Axell@ericsson.com www.ericsson.com Legal entity: Ericsson AB, registered office in Kista. This Communication i= s Confidential. We only send and receive email on the basis of the terms se= t out at www.ericsson.com/email_disclaimer --_000_5AEA7B339C0B944BB33A6939249264AD1A1F04F3ESESSMB305erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

I am having some difficulty when reading RFC 7044. I= s it mandated that a SIP entity supporting History-Info always inserts a hi= -entry? As an example, in IMS there is an application server handling a div= ersion service on behalf of UE-B. For communication forwarding busy, we would have a simplified flow as belo= w. Is the hi-entry with the np-parameter mandated by RFC 7044? If so, would= it be allowed to have index set to 1.1.1 instead of 1.2 for the diverted I= NVITE to UE-C?

 

UE-A   =             &nb= sp;            =             &nb= sp;  AS-B          &= nbsp;            &nb= sp;            =      UE-B       = ;            &n= bsp;        UE-C

---------------INVITE = UE-B---->

   &nbs= p;            &= nbsp;        History-Info:<URI-B>;= index=3D1

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    INVITE UE-B--------------->

   &nbs= p;             =             &nb= sp;            =             &nb= sp;   History-Info: :<URI-B>;index=3D1,

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;       <URI-B>;index=3D1.1,np=3D1

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     <-----------------486 (Busy)

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    INVITE UE-C--------------------------------------->=

   &nbs= p;             =             &nb= sp;            =             &nb= sp;   History-Info:<URI-B>;index=3D1,

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     <URI-B>;Reason:sip; cause=3D486;index=3D1.= 1,np=3D1

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     <URI-C;cause=3D486>;index=3D1.2,mp=3D1.1

 

Another issue with the RFC is rule 2 in section 10.3= . In particular the text "as prescribed for basic forwarding" is confusing as basic forwarding is not defined anywhere. I suspect this text is a remnant from rule 1 in section 4.3.3.1.3 in RFC 4= 244 which used Basic Forwarding in a more defining manner. My guess is that= the "basic forwarding" text in RFC 7044 should be a reference po= inting to the text just above the rules in section 10.3. Can anyone confirm?

 

Regards,

J=F6rgen

 

Dr. J=D6RGEN AXELL
Senior specialist
Business Unit Cloud and IP


Ericsson
Kistav=E4gen 25
164 80 Stockholm, Sweden
Phone +46 10 719 4450
Mobile +46 70 519 4450
Jorgen.Axell@ericsson.com
www.ericsson.com

&nbs= p;

L= egal entity: Ericsson AB, registered office in Kista. This Communication is= Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer

 

--_000_5AEA7B339C0B944BB33A6939249264AD1A1F04F3ESESSMB305erics_-- From nobody Fri Dec 5 16:04:46 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFEA1ADF24 for ; Fri, 5 Dec 2014 16:04: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 NgRSQ0KDBVsW for ; Fri, 5 Dec 2014 16:04:40 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id EAD1D1ADF27 for ; Fri, 5 Dec 2014 16:04:38 -0800 (PST) Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 05 Dec 2014 19:04:32 -0500 Received: from XCT116CNC.rim.net (10.65.161.216) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.210.2; Fri, 5 Dec 2014 19:04:31 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0210.002; Fri, 5 Dec 2014 19:04:31 -0500 From: Andrew Allen To: Ivo Sedlacek , "Leis, Peter (NSN - DE/Munich)" , Christer Holmberg , ext Adam Roach , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQBeGiwaMk5ORsmEyvUhfkEzOyiJxzzZqwgAHi0uCAAIN8oIAFOh2AgAAvDgCAANc/AIABlYpAgAGVIYCAAW4TgIAAI1cAgACSjaA= Date: Sat, 6 Dec 2014 00:04:30 +0000 Message-ID: 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> In-Reply-To: <39B5E4D390E9BD4890E2B31079006101127B7ECC@ESESSMB301.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/MSftg_zx0IAqB_yAT5QWkTGA-7A 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: Sat, 06 Dec 2014 00:04:44 -0000 Robert, Adam and all Can you live with this as a compromise? Basically document and accept that there are existing applications which us= e RFC4488 and feature tags to indicate that the UAS will accept the UAC req= uest not to create a subscription. But deprecate this behavior for new appl= ications going forward and require for future applications the use of [I-D.= ietf-sipcore-refer-explicit-subscription] in order to reuse then existing d= ialog. Andrew=20 -----Original Message----- From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com]=20 Sent: Friday, December 05, 2014 5:14 AM To: Leis, Peter (NSN - DE/Munich); Christer Holmberg; Andrew Allen; ext Ada= m Roach; Paul Kyzivat; sipcore@ietf.org Subject: RE: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt This compromise would work for me too. Kind regards Ivo 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 Leis, Peter (N= SN - DE/Munich) Sent: 5. prosince 2014 9:07 To: Christer Holmberg; Andrew Allen; ext Adam Roach; Paul Kyzivat; sipcore@= ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hi, The compromise described by Andrew would work for me. Regards Peter -----Original Message----- From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Thursday, December 04, 2014 11:17 AM To: Andrew Allen; Leis, Peter (NSN - DE/Munich); ext Adam Roach; Paul Kyziv= at; sipcore@ietf.org Subject: RE: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hi, I support Andrew's suggestion. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew Allen Sent: 3. joulukuuta 2014 21:21 To: Leis, Peter (NSN - DE/Munich); ext Adam Roach; Paul Kyzivat; sipcore@ie= tf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Maybe the way out of this rat hole is to discuss in the text and allow lega= cy application usages (similar to the legacy usages for INFO). So SIP stac= ks could be considered RFC 6665 compliant with legacy application usages us= ing RFC 4488 and feature tags identifying application specific behavior tha= t ensures that dialog reuse does not occur but that we deprecate such usage= s for any new applications that are developed and insist on the use of [I-D= .ietf-sipcore-refer-explicit-subscription] going forward.=20 =09 As Christer said: The only reason these "special environment" use-cases exist to begin with i= s because previously there was no "pure" protocol mechanism for preventing = implicit subscriptions. And, as they have existed for a while already, and = have been implemented, they will not suddenly go away just because we now h= ave [I-D.ietf-sipcore-refer-explicit-subscription]. Neither will they go aw= ay just because we now have drafts clarifying some RFCs.=20 BUT, because we now DO have a "pure" protocol mechanism [I-D.ietf-sipcore-r= efer-explicit-subscription] for preventing implicit subscriptions, I assume= there will be no NEW "special environment" use-cases in future - people WI= LL use [I-D.ietf-sipcore-refer-explicit-subscription] :) Is that something we could all agree on as a compromise? Andrew -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Leis, Peter (N= SN - DE/Munich) Sent: Tuesday, December 02, 2014 4:56 AM To: ext Adam Roach; Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hi, The specific environment is described in 3GPP TS 24.237. For the specific c= ase, both ends of the signaling comply to this spec, both ends of the signa= ling are network nodes. These network nodes either reside in the same netwo= rk, or reside in different networks, and in this case there would be some s= ort of agreement between the operators.=20 At the time when the solution in 24.237 was designed (pointed at in Ivo's p= roposal), there was no IETF solution available. So I guess it would be grea= t if the draft does not make the existing solution invalid. Regards Peter -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Adam Roach Sent: Monday, December 01, 2014 10:05 PM To: Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt On 12/1/14 10:16, Paul Kyzivat wrote: > On 11/28/14 10:28 AM, Ivo Sedlacek wrote: >> Hello, >> >> I think Andrew's proposed statement can be replaced by the statement=20 >> already existing in the draft, i.e. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> If a user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request (such as by requiring >> an extension that disallows any such subscription >> [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request >> MAY be sent within an existing dialog. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> and extended as follows: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> If a user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request (such as by requiring >> an extension that disallows any such subscription >> [I-D.ietf-sipcore-refer-explicit-subscription] >>>or by RFC4488=20 >> together with configuration / application logic in specific=20 >> environment ensuring that implicit subscription is not created<<<),=20 >> the REFER request >> MAY be sent within an existing dialog. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > What criteria do you use to be *certain*? > > Some agreement of compliance to some specification seems to be required. > > I gather that what you have in mind is that both ends have been=20 > verified to conform to particular versions of the IMS specification. > Do you ever really know that for certain in the presence of gateways=20 > to foreign devices? Right; this is the real problem. The assumption that this is somehow "safe"= to do because of some unsignaled, un-negotiated hidden agreement is extrem= ely fragile and way outside the various extension mechanisms that SIP makes= use of. Walled gardens grow doors. You don't want things to break in spectacular an= d undiagnosable ways when they do. I'm sad that some networks have decided = to ignore the exact parts of specs that were designed to foster interop and= prevent these surprise behaviors, and I see dangerous precedent in codifyi= ng this misbehavior as proposed above. Walled gardens grow doors faster than you're probably willing to believe. I= 'm frankly astonished by how quickly IMS has turned its eyes to WebRTC, ask= ing for special accommodation for features particular to 3GPP specification= s (cf. AMR). That only goes so far: you won't readily see JavaScript SIP st= acks conforming to this hidden, unnegotiated agreement that presumably exis= ts in IMS (but not elsewhere). It's an honest-to-goodness protocol fork, an= engineered incompatibility. Walled gardens grow doors. It's time to start cleaning up the IMS garden to= match SIP behavior, rather than handing out indulgences for its past sins. You're trying to fix this in the wrong SDO. /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Dec 10 01:45:23 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553691A1B80 for ; Wed, 10 Dec 2014 01:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.499 X-Spam-Level: **** X-Spam-Status: No, score=4.499 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FSL_HELO_FAKE=3.799, 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 nBB-SFzGoND6 for ; Wed, 10 Dec 2014 01:45:12 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADFEC1A1B5F for ; Wed, 10 Dec 2014 01:45:12 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id p10so2442133pdj.41 for ; Wed, 10 Dec 2014 01:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:mime-version:content-type :content-transfer-encoding:in-reply-to:references:message-id; bh=s9KElqGIUgQPrdtHm9vEWojWFHDmj5UYg0xyaV1CbhU=; b=RNVdSk0GCbQId24a6UHRlQFwuMZr+L7tzVitpx5f8BhVpBOqagMx2jzaynzySNnrFg 6KXW6djZoNbLICqIyrnO+sfNOErbJMJyEmUD9mOEepIePEO579auqp5dMk1bQwhmwZdB GXqkaZx+a68g2hJh0exl7kaePl0bk86YQMj8YJT1o+Y38EBJ45bcuStGJLshR5/iVnJW EclbSJBAPLXIxKMbDcUuhOBxJaN0plFeAP3iZgqnH7Vc9obl4eMUwL5JbVS8mCTjNkiR uj9WyQS0hbPE2B4uDt4lbTT3t6xvS7wpbMowO7IjWJ7NeJmxKl4Q/c8BoPAH+ZAzT+nl +t0Q== X-Received: by 10.68.69.1 with SMTP id a1mr5510985pbu.162.1418204712019; Wed, 10 Dec 2014 01:45:12 -0800 (PST) Received: from gmail.com (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by mx.google.com with ESMTPSA id bb3sm3724633pbc.15.2014.12.10.01.45.10 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 10 Dec 2014 01:45:11 -0800 (PST) From: OKUMURA Shinji To: sipcore@ietf.org Date: Wed, 10 Dec 2014 18:45:06 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: HidemaruMail 6.01 (WinNT,601) In-Reply-To: <5AEA7B339C0B944BB33A6939249264AD1A1F04F3@ESESSMB305.ericsson.se> References: <5AEA7B339C0B944BB33A6939249264AD1A1F04F3@ESESSMB305.ericsson.se> Message-Id: X-Antivirus: avast! (VPS 141210-0, 2014/12/10), Outbound message X-Antivirus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/AaF1I7qS39O5zbi4pImkkas_258 Cc: jorgen.axell@ericsson.com Subject: Re: [sipcore] RFC 7044 issues 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, 10 Dec 2014 09:45:20 -0000 Hi, >I am having some difficulty when reading RFC 7044. Is it mandated that a S= IP >entity supporting History-Info always inserts a hi-entry? 9.2. Sending a Request with History-Info When sending a request, a SIP entity MUST include all the hi-entries from the cache that was created per Section 9.1. In addition, the SIP entity MUST add a new hi-entry to the outgoing request, but the as mentioned above, a SIP entity MUST add a new hi-entry. > As an example, in >IMS there is an application server handling a diversion service on behalf = of >UE-B. For communication forwarding busy, we would have a simplified flow a= s >below. Is the hi-entry with the np-parameter mandated by RFC 7044? 9.2. Sending a Request with History-Info rc/mp/np: The SIP entity MUST include an "rc", "mp", or "np" header field parameter in the hi-entry, if applicable, per the procedures in Section 10.4. as mentioned above, an application server MUST include a hi-target-param in the hi-entry. > If so, >would it be allowed to have index set to 1.1.1 instead of 1.2 for the >diverted INVITE to UE-C? 10.3. Indexing in the History-Info Header Field Each dot reflects a SIP forwarding hop. The nonnegative integer following each dot reflects the order in which a request was retargeted at the hop. each dot means a SIP proxy and hi-indices describe a request's forwarding p= ath. therefore 3rd hi-index MUST be 1.2. But whether the mp-param is 1.1 or 1 depends on an implementation of AS. Shinji >UE-A AS-B UE-B UE-= C >INVITE UE-B---------------> >History-Info:;index=3D1 > INVITE UE-B--------------------> > History-Info:;index=3D1, > ;index=3D1.1,np=3D1 > <---------------------486 (Busy) > INVITE UE-C--------------------------------> > History-Info:;index=3D1, > ;Reason:sip; cause=3D486;in= dex=3D1.1,np=3D1 > ;index=3D1.2,mp= =3D1.1 > >Another issue with the RFC is rule 2 in section 10.3. In particular the te= xt >"as prescribed for basic forwarding" is confusing as basic forwarding is n= ot >defined anywhere. I suspect this text is a remnant from rule 1 in section = 4.3. >3.1.3 in RFC 4244 which used Basic Forwarding in a more defining manner. M= y >guess is that the "basic forwarding" text in RFC 7044 should be a referenc= e >pointing to the text just above the rules in section 10.3. Can anyone >confirm? --- =E3=81=93=E3=81=AEE=E3=83=A1=E3=83=BC=E3=83=AB=E3=81=AF=E3=82=A2=E3=83=90= =E3=82=B9=E3=83=88 =E3=82=A2=E3=83=B3=E3=83=81=E3=82=A6=E3=82=A4=E3=83=AB= =E3=82=B9=E3=81=AB=E3=82=88=E3=82=8A=E3=82=A6=E3=82=A4=E3=83=AB=E3=82=B9=E3= =82=B9=E3=82=AD=E3=83=A3=E3=83=B3=E3=81=95=E3=82=8C=E3=81=A6=E3=81=84=E3=81= =BE=E3=81=99=E3=80=82 http://www.avast.com From nobody Wed Dec 10 08:14:58 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09281A7030 for ; Wed, 10 Dec 2014 08:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.465 X-Spam-Level: X-Spam-Status: No, score=0.465 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ymNPiFp0QVd for ; Wed, 10 Dec 2014 08:14:54 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 889F11A026A for ; Wed, 10 Dec 2014 08:14:54 -0800 (PST) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-08v.sys.comcast.net with comcast id RsDa1p0042TL4Rh01sEtVE; Wed, 10 Dec 2014 16:14:53 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-17v.sys.comcast.net with comcast id RsEs1p00T1KKtkw01sEsrh; Wed, 10 Dec 2014 16:14:53 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id sBAGEpjI008182; Wed, 10 Dec 2014 11:14:51 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id sBAGEpD5008180; Wed, 10 Dec 2014 11:14:51 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: =?utf-8?Q?J=C3=B6rgen?= Axell In-Reply-To: <5AEA7B339C0B944BB33A6939249264AD1A1F04F3@ESESSMB305.ericsson.se> (jorgen.axell@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 10 Dec 2014 11:14:51 -0500 Message-ID: <87wq5z7a84.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418228093; bh=YxKyCIHSvqSIdl/sIOKla/4qj/I0WPK1lDumAz/98LU=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:MIME-Version:Content-Type; b=NEitO1wfzbOA97m0DRtH/Dzr9r/oFxGaXMV2MCir7CMnCADg1DgE+CE0G+2Je7eb6 MVJ6EZ4eF2r1idNDdG8ZeP1VmUloV7g1ZJClVTwuh7sAqAA+UAbLuSQrYlPrDFFLf0 d6xQaBHEg6FglgMZK/qH9C3zvmXKXzzV8lFPxFXxgjvXVlWkoRy9SRmctqtNPTtMmw CLw05OaLeU6UiZm7D6DKuf/nXIHxnhyWVw/Ysmi1Wjnp0KJ1xCCOuspzHYEjSDXcZG 6NhgF3+Ki4Nu4Ak89p1j7BCs97xtmFZjUBYhdsOGvHGEdQUUPeRvcuYEUO12adqwhT orlB3ulpoN+MA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/jAXb6dadfV9w4UHcJ6p5kk_ZMUs Cc: sipcore@ietf.org Subject: Re: [sipcore] RFC 7044 issues 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, 10 Dec 2014 16:14:55 -0000 J=C3=B6rgen Axell writes: > I am having some difficulty when reading RFC 7044. Is it mandated that > a SIP entity supporting History-Info always inserts a hi-entry? Yes -- Inserting hi-entry is what is meant by "supporting History-Info". > If so, would it be allowed to have index set to > 1.1.1 instead of 1.2 for the diverted INVITE to UE-C? No, 1.2 is required, because "INVITE UE-C" is a fork of the first "INVITE UE-B". The index values mirror the sets of Via headers, which I have inserted below. The second and third requests copy the Via headers of the first request, hence their index values are the index value of the first request, with one more integer appended. > UE-A AS-B = UE-B UE-C > ---------------INVITE UE-B----> Via: SIP/2.0/UDP UE-A;branch=3Dz9hG4bKnashds8 > History-Info:;index=3D1 > INVITE UE-B---------------> Via: SIP/2.0/UDP UE-B;bran= ch=3Dz9hG4bK77ef4c2312983.1 Via: SIP/2.0/UDP UE-A;bran= ch=3Dz9hG4bKnashds8 > History-Info: :;ind= ex=3D1, > ;ind= ex=3D1.1,np=3D1 > <--= ---------------486 (Busy) > INVITE UE-C---------------= ------------------------> Via: SIP/2.0/UDP UE-B;bran= ch=3Dz9hG4bK77ef4c2312543.23 Via: SIP/2.0/UDP UE-A;bran= ch=3Dz9hG4bKnashds8 > History-Info:;index= =3D1, > ;Reaso= n:sip; cause=3D486;index=3D1.1,np=3D1 Of course, the previous entry should be: = ;index=3D1.1,np=3D1, > ;index=3D1.2,mp=3D1.1 Dale From nobody Thu Dec 11 00:54:09 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96A11ACD20 for ; Thu, 11 Dec 2014 00:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 B6QnodDcXCap for ; Thu, 11 Dec 2014 00:54:05 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D191ACD1E for ; Thu, 11 Dec 2014 00:54:05 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 74C343B45B2; Thu, 11 Dec 2014 09:54:03 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 4F2DC15805B; Thu, 11 Dec 2014 09:54:00 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Thu, 11 Dec 2014 09:54:00 +0100 From: To: =?iso-8859-1?Q?J=F6rgen_Axell?= , "sipcore@ietf.org" Thread-Topic: RFC 7044 issues Thread-Index: AdAQieJCXKODzM1rQqesYuUK8hDakwEkyOcA Date: Thu, 11 Dec 2014 08:53:59 +0000 Message-ID: <6202_1418288040_54895BA8_6202_16138_1_8B970F90C584EA4E97D5BAAC9172DBB8142C91C6@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <5AEA7B339C0B944BB33A6939249264AD1A1F04F3@ESESSMB305.ericsson.se> In-Reply-To: <5AEA7B339C0B944BB33A6939249264AD1A1F04F3@ESESSMB305.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.11.42723 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/gAH6EtNzDMhODpztzcM3b3fq1LI Subject: Re: [sipcore] RFC 7044 issues 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, 11 Dec 2014 08:54:07 -0000 Hi, > Is it mandated that a SIP entity supporting History-Info always inserts a= hi-entry? Yes > If so, would it be allowed to have index set to 1.1.1 instead of 1.2 for = the diverted INVITE to UE-C? Yes, IMO a new ".1" level is adapted to this situation for the following re= asons: a) It is a clear application of the RFC4244 Basic Forwarding rule which rec= ommends a new index level in case of forwarding and for backward compatibil= ity reasons...=20 b) UE-C is not a fork of UE-B, it is a clear different target that is not u= nder AS-B's responsibility. Outgoing leg from AS-B towards UE-C is an origi= nating-CDIV leg. Then, it is a forwarding hop and the text to be applied fr= om RFC7044 is "For each forward hop (i.e., each new level of indexing), the= last integers of the hi-indexes of the new requests MUST be generated star= ting at 1 and incrementing by 1 for each additional request."=20 BR, Marianne De=A0: sipcore [mailto:sipcore-bounces@ietf.org] De la part de J=F6rgen Axe= ll Envoy=E9=A0: vendredi 5 d=E9cembre 2014 13:52 =C0=A0: sipcore@ietf.org Objet=A0: [sipcore] RFC 7044 issues Hello, I am having some difficulty when reading RFC 7044. Is it mandated that a SI= P entity supporting History-Info always inserts a hi-entry? As an example, = in IMS there is an application server handling a diversion service on behal= f of UE-B. For communication forwarding busy, we would have a simplified fl= ow as below. Is the hi-entry with the np-parameter mandated by RFC 7044? If= so, would it be allowed to have index set to 1.1.1 instead of 1.2 for the = diverted INVITE to UE-C? UE-A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 AS-B=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0UE-B=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 UE-C ---------------INVITE UE-B----> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Hi= story-Info:;index=3D1 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 INVITE UE-B---------------> =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0History-Info: :;index=3D1, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ;index=3D1.1,np=3D1 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 <-----------------486 (Busy) =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 INVITE UE-C---------------------------------------> =A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0History-Info:;index=3D1, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 ;Reason:sip; cause=3D486;index=3D1.1,np=3D1 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 ;index=3D1.2,mp=3D1.1 Another issue with the RFC is rule 2 in section 10.3. In particular the tex= t "as prescribed for basic forwarding" is confusing as basic forwarding is = not defined anywhere. I suspect this text is a remnant from rule 1 in secti= on 4.3.3.1.3 in RFC 4244 which used Basic Forwarding in a more defining man= ner. My guess is that the "basic forwarding" text in RFC 7044 should be a r= eference pointing to the text just above the rules in section 10.3. Can any= one confirm? Regards, J=F6rgen Dr. J=D6RGEN AXELL Senior specialist=20 Business Unit Cloud and IP Ericsson Kistav=E4gen 25 164 80 Stockholm, Sweden Phone +46 10 719 4450 Mobile +46 70 519 4450 Jorgen.Axell@ericsson.com www.ericsson.com=20 Legal entity: Ericsson AB, registered office in Kista. This Communication i= s Confidential. We only send and receive email on the basis of the terms se= t out at www.ericsson.com/email_disclaimer=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Dec 11 21:06:32 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B12B1A88A5 for ; Thu, 11 Dec 2014 21:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.799 X-Spam-Level: * X-Spam-Status: No, score=1.799 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, FSL_HELO_FAKE=3.799, 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 hXie4rejJsqO for ; Thu, 11 Dec 2014 21:06:29 -0800 (PST) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E5071A88A1 for ; Thu, 11 Dec 2014 21:06:29 -0800 (PST) Received: by mail-pd0-f169.google.com with SMTP id z10so6450525pdj.14 for ; Thu, 11 Dec 2014 21:06:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:mime-version:content-type :content-transfer-encoding:in-reply-to:references:message-id; bh=4fqhUvOHNreqc4RW04hPsMnU7vclzLu7YaD7l5a/fGk=; b=fEWvbXXCzQVqAUKpAhEGNkzPWOk9oo7j8z7roHdQUYCDLw2sOZWkU7TsA2HL8S/T39 XbK8J4H0bt/GlMfTi63EIyoJ/lpjfxQDFj0KsWvI+ikceSKSNlFXJSOJHbAJdDti1l9z JE4FuwzcNCCGJWgfI+Hf90KJQMU816vzyTImPdVYqpzu8qn5V0wfHtmeAnyF5btmfhfL nYSSAtrKffY6Z0eBtcm/ZhC5b0NWvnGAT8xQdhYNID3BdyY4fq0zx3aOCqZUY7nmZY+c 6qSy5vkVq9fLviLrOYbad9U62Y+DTWr0ZrSUB75BPKLeXfGOfOrW523u/n9d0p4h8Lb6 ANuw== X-Received: by 10.70.88.164 with SMTP id bh4mr23419012pdb.96.1418360787780; Thu, 11 Dec 2014 21:06:27 -0800 (PST) Received: from gmail.com (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by mx.google.com with ESMTPSA id is2sm297165pbb.4.2014.12.11.21.06.26 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 11 Dec 2014 21:06:27 -0800 (PST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Fri, 12 Dec 2014 14:06:18 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: HidemaruMail 6.01 (WinNT,601) In-Reply-To: <6202_1418288040_54895BA8_6202_16138_1_8B970F90C584EA4E97D5BAAC9172DBB8142C91C6@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <5AEA7B339C0B944BB33A6939249264AD1A1F04F3@ESESSMB305.ericsson.se> <6202_1418288040_54895BA8_6202_16138_1_8B970F90C584EA4E97D5BAAC9172DBB8142C91C6@PEXCVZYM12.corporate.adroot.infra.ftgroup> Message-Id: <4D015C95CF0B4ietf.shinji@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/kAbKjbCh5vFWYcOKvDCQMk1Q53M Cc: =?utf-8?B?SsO2cmdlbg==?= Axell Subject: Re: [sipcore] RFC 7044 issues 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, 12 Dec 2014 05:06:30 -0000 Hi, >> Is it mandated that a SIP entity supporting History-Info always inserts a >> hi-entry? >Yes > >> If so, would it be allowed to have index set to 1.1.1 instead of 1.2 for >> the diverted INVITE to UE-C? > >Yes, IMO a new ".1" level is adapted to this situation for the following >reasons: >a) It is a clear application of the RFC4244 Basic Forwarding rule which >recommends a new index level in case of forwarding and for backward >compatibility reasons... >b) UE-C is not a fork of UE-B, it is a clear different target that is not >under AS-B's responsibility. Outgoing leg from AS-B towards UE-C is an >originating-CDIV leg. Then, it is a forwarding hop and the text to be applied >from RFC7044 is "For each forward hop (i.e., each new level of indexing), the >last integers of the hi-indexes of the new requests MUST be generated >starting at 1 and incrementing by 1 for each additional request." This scenario is a sequential fork, and indexing by RFC7044 doesn't differ much from RFC4244. plz confirm Appendix A of RFC4244. http://tools.ietf.org/html/rfc4244#appendix-A shinji From nobody Fri Dec 12 01:34:01 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BC11AC435 for ; Fri, 12 Dec 2014 01:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 pYxhx9E2hHYt for ; Fri, 12 Dec 2014 01:33:57 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C6E51A19E5 for ; Fri, 12 Dec 2014 01:33:57 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 92AB822C9EE; Fri, 12 Dec 2014 10:33:55 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 7576335C269; Fri, 12 Dec 2014 10:33:55 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Fri, 12 Dec 2014 10:33:54 +0100 From: To: OKUMURA Shinji , "sipcore@ietf.org" Thread-Topic: [sipcore] RFC 7044 issues Thread-Index: AdAQieJCXKODzM1rQqesYuUK8hDakwEkyOcAACj9PgAACybEEA== Date: Fri, 12 Dec 2014 09:33:54 +0000 Message-ID: <1747_1418376835_548AB683_1747_684_1_8B970F90C584EA4E97D5BAAC9172DBB8142C95DF@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <5AEA7B339C0B944BB33A6939249264AD1A1F04F3@ESESSMB305.ericsson.se> <6202_1418288040_54895BA8_6202_16138_1_8B970F90C584EA4E97D5BAAC9172DBB8142C91C6@PEXCVZYM12.corporate.adroot.infra.ftgroup> <4D015C95CF0B4ietf.shinji@gmail.com> In-Reply-To: <4D015C95CF0B4ietf.shinji@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.21.125720 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/JmTeW4N3B2R4bX6mCTSJ02E8At4 Cc: =?utf-8?B?SsO2cmdlbiBBeGVsbA==?= Subject: Re: [sipcore] RFC 7044 issues 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, 12 Dec 2014 09:33:59 -0000 SGkgU2hpbmppLA0KDQpNeSBhbnN3ZXIgaW5saW5lIFtNTV0NCg0KQlIsDQpNYXJpYW5uZQ0KDQot LS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IE9LVU1VUkEgU2hpbmppIFttYWlsdG86 aWV0Zi5zaGluamlAZ21haWwuY29tXSANCkVudm95w6nCoDogdmVuZHJlZGkgMTIgZMOpY2VtYnJl IDIwMTQgMDY6MDYNCsOAwqA6IHNpcGNvcmVAaWV0Zi5vcmcNCkNjwqA6IE1PSEFMSSBNYXJpYW5u ZSBJTVQvT0xOOyBKw7ZyZ2VuIEF4ZWxsDQpPYmpldMKgOiBSZTogW3NpcGNvcmVdIFJGQyA3MDQ0 IGlzc3Vlcw0KDQpIaSwNCg0KPj4gSXMgaXQgbWFuZGF0ZWQgdGhhdCBhIFNJUCBlbnRpdHkgc3Vw cG9ydGluZyBIaXN0b3J5LUluZm8gYWx3YXlzIA0KPj4gaW5zZXJ0cyBhIGhpLWVudHJ5Pw0KPlll cw0KPg0KPj4gSWYgc28sIHdvdWxkIGl0IGJlIGFsbG93ZWQgdG8gaGF2ZSBpbmRleCBzZXQgdG8g MS4xLjEgaW5zdGVhZCBvZiAxLjIgDQo+PiBmb3IgdGhlIGRpdmVydGVkIElOVklURSB0byBVRS1D Pw0KPg0KPlllcywgSU1PIGEgbmV3ICIuMSIgbGV2ZWwgaXMgYWRhcHRlZCB0byB0aGlzIHNpdHVh dGlvbiBmb3IgdGhlIA0KPmZvbGxvd2luZw0KPnJlYXNvbnM6DQo+YSkgSXQgaXMgYSBjbGVhciBh cHBsaWNhdGlvbiBvZiB0aGUgUkZDNDI0NCBCYXNpYyBGb3J3YXJkaW5nIHJ1bGUgd2hpY2ggDQo+ cmVjb21tZW5kcyBhIG5ldyBpbmRleCBsZXZlbCBpbiBjYXNlIG9mIGZvcndhcmRpbmcgYW5kIGZv ciBiYWNrd2FyZCANCj5jb21wYXRpYmlsaXR5IHJlYXNvbnMuLi4NCj5iKSBVRS1DIGlzIG5vdCBh IGZvcmsgb2YgVUUtQiwgaXQgaXMgYSBjbGVhciBkaWZmZXJlbnQgdGFyZ2V0IHRoYXQgaXMgDQo+ bm90IHVuZGVyIEFTLUIncyByZXNwb25zaWJpbGl0eS4gT3V0Z29pbmcgbGVnIGZyb20gQVMtQiB0 b3dhcmRzIFVFLUMgaXMgDQo+YW4gb3JpZ2luYXRpbmctQ0RJViBsZWcuIFRoZW4sIGl0IGlzIGEg Zm9yd2FyZGluZyBob3AgYW5kIHRoZSB0ZXh0IHRvIA0KPmJlIGFwcGxpZWQgZnJvbSBSRkM3MDQ0 IGlzICJGb3IgZWFjaCBmb3J3YXJkIGhvcCAoaS5lLiwgZWFjaCBuZXcgbGV2ZWwgDQo+b2YgaW5k ZXhpbmcpLCB0aGUgbGFzdCBpbnRlZ2VycyBvZiB0aGUgaGktaW5kZXhlcyBvZiB0aGUgbmV3IHJl cXVlc3RzIA0KPk1VU1QgYmUgZ2VuZXJhdGVkIHN0YXJ0aW5nIGF0IDEgYW5kIGluY3JlbWVudGlu ZyBieSAxIGZvciBlYWNoIGFkZGl0aW9uYWwgcmVxdWVzdC4iDQoNClRoaXMgc2NlbmFyaW8gaXMg YSBzZXF1ZW50aWFsIGZvcmssIGFuZCBpbmRleGluZyBieSBSRkM3MDQ0IGRvZXNuJ3QgZGlmZmVy IG11Y2ggZnJvbSBSRkM0MjQ0Lg0KcGx6IGNvbmZpcm0gQXBwZW5kaXggQSBvZiBSRkM0MjQ0Lg0K aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDI0NCNhcHBlbmRpeC1BDQoNCltNTV0gVGhp cyBzY2VuYXJpbyAod2l0aCBhbiBBUykgaXMgYSBiYXNpYyBmb3J3YXJkaW5nIHJ1bGUgZnJvbSBS RkM0MjQ0IHdoaWNoIGlzIG1lbnRpb25lZCBidXQgbm8gbG9uZ2VyIGRlc2NyaWJlZCBpbiBSRkM3 MDQ0IChhcyBKw7ZyZ2VuIHBvaW50ZWQpOg0KW01NXSBbMS4gQmFzaWMgRm9yd2FyZGluZzogIElu IHRoZSBjYXNlIG9mIGEgUmVxdWVzdCB0aGF0IGlzIGJlaW5nIGZvcndhcmRlZCwgdGhlIGluZGV4 IGlzIGRldGVybWluZWQgYnkgYWRkaW5nIGFub3RoZXIgbGV2ZWwgb2YgaW5kZXhpbmcgc2luY2Ug dGhlIGRlcHRoL2xlbmd0aCBvZiB0aGUgYnJhbmNoIGlzIGluY3JlYXNpbmcuIAlUbyBhY2NvbXBs aXNoIHRoaXMsIHRoZSBwcm94eSByZWFkcyB0aGUgdmFsdWUgZnJvbSB0aGUgSGlzdG9yeS1JbmZv IGhlYWRlciBpbiB0aGUgcmVjZWl2ZWQgcmVxdWVzdCwgaWYgYXZhaWxhYmxlLCBhbmQgYWRkcyBh bm90aGVyIGxldmVsIG9mIGluZGV4aW5nIGJ5IGFwcGVuZGluZyB0aGUgZG90IGRlbGltaXRlciAJ Zm9sbG93ZWQgYnkgYW4gaW5pdGlhbCBpbmRleCBmb3IgdGhlIG5ldyBsZXZlbCBSRUNPTU1FTkRF RCB0byBiZSAxLiBGb3IgZXhhbXBsZSwgaWYgdGhlIGluZGV4IGluIHRoZSBsYXN0IEhpc3Rvcnkt SW5mbyBoZWFkZXIgZmllbGQgaW4gdGhlIHJlY2VpdmVkIHJlcXVlc3QgaXMgMS4xLCB0aGlzIHBy b3h5IHdvdWxkIAlpbml0aWFsaXplIGl0cyBpbmRleCB0byAxLjEuMSBhbmQgZm9yd2FyZCB0aGUg cmVxdWVzdC5dDQpTaGluamkNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9p bnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91 IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9y bWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1 c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRl IHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVy ZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2Rp ZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Fri Dec 12 02:11:23 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4C31ACC7F for ; Fri, 12 Dec 2014 02:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.799 X-Spam-Level: * X-Spam-Status: No, score=1.799 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, FSL_HELO_FAKE=3.799, 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 SQ9c-5N2M1mS for ; Fri, 12 Dec 2014 02:11:20 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DA931A1AF2 for ; Fri, 12 Dec 2014 02:11:20 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id lf10so6329902pab.5 for ; Fri, 12 Dec 2014 02:11:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:mime-version:content-type :content-transfer-encoding:in-reply-to:references:message-id; bh=CPTBncS2/f6co4XK0DQWbAIjae5V4ZxD260xcXELOWk=; b=wwz0+s9bni7bxZ3wefS+c8JxrTevj+teJLTuKfLsuApYpAhmnzFjwUKdGMK7Uc0r+i 9xeQ/QQ3Pnx4imtlpup8LkXD5Mx2pUxdOkV8qhWsj5WKdhGE1ewIIaimb9jpCvkuffiF ZpVhxt2V+awE8zdTlKj+l04KTMG7pPwqYis7IJYoM+MxBtkmazWaI5uLkk7U5pd2qTlL xNf/X/BbGwMwY09m/ncJn5CEWiv7QipRZBHP7EifX72Wlz5fjzeFLyyM32J2vABV1Ccz BsozG36STmpQ0gHW2i/2/FKB9X1hVv3REBEQTpPAoPHZOWjazwxfIgbmHNCWucpnP1Al uznQ== X-Received: by 10.68.190.103 with SMTP id gp7mr25447689pbc.55.1418379079415; Fri, 12 Dec 2014 02:11:19 -0800 (PST) Received: from gmail.com (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by mx.google.com with ESMTPSA id kl7sm1143708pdb.10.2014.12.12.02.11.17 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 12 Dec 2014 02:11:18 -0800 (PST) From: OKUMURA Shinji To: "sipcore@ietf.org" Date: Fri, 12 Dec 2014 19:11:09 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: HidemaruMail 6.01 (WinNT,601) In-Reply-To: <1747_1418376835_548AB683_1747_684_1_8B970F90C584EA4E97D5BAAC9172DBB8142C95DF@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <5AEA7B339C0B944BB33A6939249264AD1A1F04F3@ESESSMB305.ericsson.se> <6202_1418288040_54895BA8_6202_16138_1_8B970F90C584EA4E97D5BAAC9172DBB8142C91C6@PEXCVZYM12.corporate.adroot.infra.ftgroup> <4D015C95CF0B4ietf.shinji@gmail.com> <1747_1418376835_548AB683_1747_684_1_8B970F90C584EA4E97D5BAAC9172DBB8142C95DF@PEXCVZYM12.corporate.adroot.infra.ftgroup> Message-Id: <6D015F3F363CDietf.shinji@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/eaC7AMa46FCfTqm118cpvO6sT4Q Cc: =?utf-8?B?SsO2cmdlbg==?= Axell Subject: Re: [sipcore] RFC 7044 issues 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, 12 Dec 2014 10:11:21 -0000 Hi Marianne, IIUC this scenario is not "1. Basic Forwarding" but "4. Retargeting based upon a Response". >Hi Shinji, > >My answer inline [MM] > >BR, >Marianne > >-----Message d'origine----- >De : OKUMURA Shinji [mailto:ietf.shinji@gmail.com] >Envoyé : vendredi 12 décembre 2014 06:06 >À : sipcore@ietf.org >Cc : MOHALI Marianne IMT/OLN; Jörgen Axell >Objet : Re: [sipcore] RFC 7044 issues > >Hi, > >>> Is it mandated that a SIP entity supporting History-Info always >>> inserts a hi-entry? >>Yes >> >>> If so, would it be allowed to have index set to 1.1.1 instead of 1.2 >>> for the diverted INVITE to UE-C? >> >>Yes, IMO a new ".1" level is adapted to this situation for the >>following >>reasons: >>a) It is a clear application of the RFC4244 Basic Forwarding rule which >>recommends a new index level in case of forwarding and for backward >>compatibility reasons... >>b) UE-C is not a fork of UE-B, it is a clear different target that is >>not under AS-B's responsibility. Outgoing leg from AS-B towards UE-C is >>an originating-CDIV leg. Then, it is a forwarding hop and the text to >>be applied from RFC7044 is "For each forward hop (i.e., each new level >>of indexing), the last integers of the hi-indexes of the new requests >>MUST be generated starting at 1 and incrementing by 1 for each additional >>request." > >This scenario is a sequential fork, and indexing by RFC7044 doesn't differ >much from RFC4244. >plz confirm Appendix A of RFC4244. >http://tools.ietf.org/html/rfc4244#appendix-A > >[MM] This scenario (with an AS) is a basic forwarding rule from RFC4244 which >is mentioned but no longer described in RFC7044 (as Jörgen pointed): >[MM] [1. Basic Forwarding: In the case of a Request that is being forwarded, >the index is determined by adding another level of indexing since the depth/ >length of the branch is increasing. To accomplish this, the proxy reads >the value from the History-Info header in the received request, if available, >and adds another level of indexing by appending the dot delimiter followed >by an initial index for the new level RECOMMENDED to be 1. For example, if >the index in the last History-Info header field in the received request is 1. >1, this proxy would initialize its index to 1.1.1 and forward the >request.] From nobody Fri Dec 12 03:11:30 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC281A8725 for ; Fri, 12 Dec 2014 03:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 yl8AkLanwGpt for ; Fri, 12 Dec 2014 03:11:24 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94FF1A1A73 for ; Fri, 12 Dec 2014 03:11:23 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 34BF6324658; Fri, 12 Dec 2014 12:11:22 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 0120523811E; Fri, 12 Dec 2014 12:11:22 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Fri, 12 Dec 2014 12:11:21 +0100 From: To: OKUMURA Shinji , "sipcore@ietf.org" Thread-Topic: [sipcore] RFC 7044 issues Thread-Index: AdAQieJCXKODzM1rQqesYuUK8hDakwEkyOcAACj9PgAACybEEP//+/aA///sRNA= Date: Fri, 12 Dec 2014 11:11:20 +0000 Message-ID: <11540_1418382682_548ACD5A_11540_377_1_8B970F90C584EA4E97D5BAAC9172DBB8142C964D@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <5AEA7B339C0B944BB33A6939249264AD1A1F04F3@ESESSMB305.ericsson.se> <6202_1418288040_54895BA8_6202_16138_1_8B970F90C584EA4E97D5BAAC9172DBB8142C91C6@PEXCVZYM12.corporate.adroot.infra.ftgroup> <4D015C95CF0B4ietf.shinji@gmail.com> <1747_1418376835_548AB683_1747_684_1_8B970F90C584EA4E97D5BAAC9172DBB8142C95DF@PEXCVZYM12.corporate.adroot.infra.ftgroup> <6D015F3F363CDietf.shinji@gmail.com> In-Reply-To: <6D015F3F363CDietf.shinji@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.11.21.125720 Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/f57miQ8ytbzcyaAKEpux3WKLKRU Cc: =?utf-8?B?SsO2cmdlbiBBeGVsbA==?= Subject: Re: [sipcore] RFC 7044 issues 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, 12 Dec 2014 11:11:27 -0000 SSB3b3VsZCBzYXkgdGhhdCB0aGlzIHNjZW5hcmlvIGlzIGEgYmFzaWMgZm9yd2FyZGluZyBiYXNl ZCB1cG9uIGEgcmVzcG9uc2UgOi0pIA0KSW4gdGhlIGNhbGwgZm9yd2FyZGluZyBidXN5IGV4YW1w bGUgcHJlc2VudGVkIGJ5IErDtnJnZW4sIGl0IGNvdWxkbid0IGJlIG9ubHkgY29uc2lkZXJlZCB0 aGF0IHRoZSBjYWxsIGZvcndhcmRpbmcgaXMgZHVlIHRvIHRoZSBTSVAgcmVzcG9uc2UgNDg2LiBJ biB0aGUgc2lnbmFsaW5nIHBhdGggdGhlcmUgaXMgYW4gQVMgdGhhdCBkZWNpZGVkIHRvIGRvIHRo ZSByZXRhcmdldGluZyBhZnRlciBzb21lIGNoZWNraW5nLCBhZGRzIGEgbmV3IGhpLWVudHJ5IHdp dGggdGhlIGNhdXNlIFVSSSBwYXJhbWV0ZXIsIGEgcHJpdmFjeS4uLiBJdCBpcyBtb3JlIHRoZSBy dWxlIDIgb2YgUkZDNzA0NCB0byBiZSBhcHBsaWVkICJSZXRhcmdldGluZyB3aXRoaW4gYSBwcm9j ZXNzaW5nIGVudGl0eSAtIGZpcnN0IGluc3RhbmNlOiBGb3IgdGhlIGZpcnN0IGluc3RhbmNlIG9m IHJldGFyZ2V0aW5nIHdpdGhpbiBhIHByb2Nlc3NpbmcgZW50aXR5LCB0aGUgU0lQIGVudGl0eSBN VVNUIGNhbGN1bGF0ZSB0aGUgaGktaW5kZXggYXMgcHJlc2NyaWJlZCBmb3IgYmFzaWMgZm9yd2Fy ZGluZy4iIA0KDQpIb3dldmVyLCBJIGFncmVlIHRoYXQgaXQgaXMgbm90IGNsZWFyIHdoaWNoIHJ1 bGUgc2hvdWxkIGJlIGFwcGxpZWQgd2hlbiBib3RoIGNhbiBiZSBjb25zaWRlcmVkIChydWxlcyAy IGFuZCA0KS4gDQoNCkJSLA0KTWFyaWFubmUNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0t DQpEZcKgOiBPS1VNVVJBIFNoaW5qaSBbbWFpbHRvOmlldGYuc2hpbmppQGdtYWlsLmNvbV0gDQpF bnZvecOpwqA6IHZlbmRyZWRpIDEyIGTDqWNlbWJyZSAyMDE0IDExOjExDQrDgMKgOiBzaXBjb3Jl QGlldGYub3JnDQpDY8KgOiBNT0hBTEkgTWFyaWFubmUgSU1UL09MTjsgSsO2cmdlbiBBeGVsbA0K T2JqZXTCoDogUkU6IFtzaXBjb3JlXSBSRkMgNzA0NCBpc3N1ZXMNCg0KSGkgTWFyaWFubmUsDQoN CklJVUMgdGhpcyBzY2VuYXJpbyBpcyBub3QgIjEuIEJhc2ljIEZvcndhcmRpbmciIGJ1dCAiNC4g UmV0YXJnZXRpbmcgYmFzZWQgdXBvbiBhIFJlc3BvbnNlIi4NCg0KPkhpIFNoaW5qaSwNCj4NCj5N eSBhbnN3ZXIgaW5saW5lIFtNTV0NCj4NCj5CUiwNCj5NYXJpYW5uZQ0KPg0KPi0tLS0tTWVzc2Fn ZSBkJ29yaWdpbmUtLS0tLQ0KPkRlIDogT0tVTVVSQSBTaGluamkgW21haWx0bzppZXRmLnNoaW5q aUBnbWFpbC5jb21dIEVudm95w6kgOiB2ZW5kcmVkaSAxMiANCj5kw6ljZW1icmUgMjAxNCAwNjow NiDDgCA6IHNpcGNvcmVAaWV0Zi5vcmcgQ2MgOiBNT0hBTEkgTWFyaWFubmUgSU1UL09MTjsgDQo+ SsO2cmdlbiBBeGVsbCBPYmpldCA6IFJlOiBbc2lwY29yZV0gUkZDIDcwNDQgaXNzdWVzDQo+DQo+ SGksDQo+DQo+Pj4gSXMgaXQgbWFuZGF0ZWQgdGhhdCBhIFNJUCBlbnRpdHkgc3VwcG9ydGluZyBI aXN0b3J5LUluZm8gYWx3YXlzIA0KPj4+IGluc2VydHMgYSBoaS1lbnRyeT8NCj4+WWVzDQo+Pg0K Pj4+IElmIHNvLCB3b3VsZCBpdCBiZSBhbGxvd2VkIHRvIGhhdmUgaW5kZXggc2V0IHRvIDEuMS4x IGluc3RlYWQgb2YgMS4yIA0KPj4+IGZvciB0aGUgZGl2ZXJ0ZWQgSU5WSVRFIHRvIFVFLUM/DQo+ Pg0KPj5ZZXMsIElNTyBhIG5ldyAiLjEiIGxldmVsIGlzIGFkYXB0ZWQgdG8gdGhpcyBzaXR1YXRp b24gZm9yIHRoZSANCj4+Zm9sbG93aW5nDQo+PnJlYXNvbnM6DQo+PmEpIEl0IGlzIGEgY2xlYXIg YXBwbGljYXRpb24gb2YgdGhlIFJGQzQyNDQgQmFzaWMgRm9yd2FyZGluZyBydWxlIA0KPj53aGlj aCByZWNvbW1lbmRzIGEgbmV3IGluZGV4IGxldmVsIGluIGNhc2Ugb2YgZm9yd2FyZGluZyBhbmQg Zm9yIA0KPj5iYWNrd2FyZCBjb21wYXRpYmlsaXR5IHJlYXNvbnMuLi4NCj4+YikgVUUtQyBpcyBu b3QgYSBmb3JrIG9mIFVFLUIsIGl0IGlzIGEgY2xlYXIgZGlmZmVyZW50IHRhcmdldCB0aGF0IGlz IA0KPj5ub3QgdW5kZXIgQVMtQidzIHJlc3BvbnNpYmlsaXR5LiBPdXRnb2luZyBsZWcgZnJvbSBB Uy1CIHRvd2FyZHMgVUUtQyANCj4+aXMgYW4gb3JpZ2luYXRpbmctQ0RJViBsZWcuIFRoZW4sIGl0 IGlzIGEgZm9yd2FyZGluZyBob3AgYW5kIHRoZSB0ZXh0IA0KPj50byBiZSBhcHBsaWVkIGZyb20g UkZDNzA0NCBpcyAiRm9yIGVhY2ggZm9yd2FyZCBob3AgKGkuZS4sIGVhY2ggbmV3IA0KPj5sZXZl bCBvZiBpbmRleGluZyksIHRoZSBsYXN0IGludGVnZXJzIG9mIHRoZSBoaS1pbmRleGVzIG9mIHRo ZSBuZXcgDQo+PnJlcXVlc3RzIE1VU1QgYmUgZ2VuZXJhdGVkIHN0YXJ0aW5nIGF0IDEgYW5kIGlu Y3JlbWVudGluZyBieSAxIGZvciANCj4+ZWFjaCBhZGRpdGlvbmFsIHJlcXVlc3QuIg0KPg0KPlRo aXMgc2NlbmFyaW8gaXMgYSBzZXF1ZW50aWFsIGZvcmssIGFuZCBpbmRleGluZyBieSBSRkM3MDQ0 IGRvZXNuJ3QgDQo+ZGlmZmVyIG11Y2ggZnJvbSBSRkM0MjQ0Lg0KPnBseiBjb25maXJtIEFwcGVu ZGl4IEEgb2YgUkZDNDI0NC4NCj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MjQ0I2Fw cGVuZGl4LUENCj4NCj5bTU1dIFRoaXMgc2NlbmFyaW8gKHdpdGggYW4gQVMpIGlzIGEgYmFzaWMg Zm9yd2FyZGluZyBydWxlIGZyb20gUkZDNDI0NCANCj53aGljaCBpcyBtZW50aW9uZWQgYnV0IG5v IGxvbmdlciBkZXNjcmliZWQgaW4gUkZDNzA0NCAoYXMgSsO2cmdlbiBwb2ludGVkKToNCj5bTU1d IFsxLiBCYXNpYyBGb3J3YXJkaW5nOiAgSW4gdGhlIGNhc2Ugb2YgYSBSZXF1ZXN0IHRoYXQgaXMg YmVpbmcgDQo+Zm9yd2FyZGVkLCB0aGUgaW5kZXggaXMgZGV0ZXJtaW5lZCBieSBhZGRpbmcgYW5v dGhlciBsZXZlbCBvZiBpbmRleGluZyBzaW5jZSB0aGUgZGVwdGgvDQo+bGVuZ3RoIG9mIHRoZSBi cmFuY2ggaXMgaW5jcmVhc2luZy4gCVRvIGFjY29tcGxpc2ggdGhpcywgdGhlIHByb3h5IHJlYWRz IA0KPnRoZSB2YWx1ZSBmcm9tIHRoZSBIaXN0b3J5LUluZm8gaGVhZGVyIGluIHRoZSByZWNlaXZl ZCByZXF1ZXN0LCBpZiBhdmFpbGFibGUsIA0KPmFuZCBhZGRzIGFub3RoZXIgbGV2ZWwgb2YgaW5k ZXhpbmcgYnkgYXBwZW5kaW5nIHRoZSBkb3QgZGVsaW1pdGVyIAlmb2xsb3dlZCANCj5ieSBhbiBp bml0aWFsIGluZGV4IGZvciB0aGUgbmV3IGxldmVsIFJFQ09NTUVOREVEIHRvIGJlIDEuIEZvciBl eGFtcGxlLCANCj5pZiB0aGUgaW5kZXggaW4gdGhlIGxhc3QgSGlzdG9yeS1JbmZvIGhlYWRlciBm aWVsZCBpbiB0aGUgcmVjZWl2ZWQgcmVxdWVzdCBpcyAxLg0KPjEsIHRoaXMgcHJveHkgd291bGQg CWluaXRpYWxpemUgaXRzIGluZGV4IHRvIDEuMS4xIGFuZCBmb3J3YXJkIHRoZSANCj5yZXF1ZXN0 Ll0NCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl dCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMg c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1 ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu c2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRh bnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk IGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3 aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBu b3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBv ciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Mon Dec 15 06:13:29 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F201A1B54 for ; Mon, 15 Dec 2014 06:13:28 -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 jKS7rUxWjmQc for ; Mon, 15 Dec 2014 06:13:26 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC3D1A1B38 for ; Mon, 15 Dec 2014 06:13:25 -0800 (PST) Received: from [192.168.8.100] (37.250.153.143.bredband.tre.se [37.250.153.143]) by smtp7.webway.se (Postfix) with ESMTPA id 582D193C2A1; Mon, 15 Dec 2014 14:12:27 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Dec 2014 15:13:23 +0100 Message-Id: To: SIPCORE Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/H8OibiH0Ljdq9FbroIAIxnLj33E Cc: Olle E Johansson Subject: [sipcore] RFC 3263 NAPTR Rules 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, 15 Dec 2014 14:13:28 -0000 Hello!=20 In a discussion about NAPTR today I ended up confusing myself and = reading the RFC did not make me less confused. Section 4.1 says: "If the server supports multiple transport protocols, there will be multiple NAPTR records, each with a different service value." Later the same section says: "If a SIP proxy, redirect server, or registrar is to be contacted through the lookup of NAPTR records, there MUST be at least three records - one with a "SIP+D2T" service field, one with a "SIP+D2U" service field, and one with a "SIPS+D2T" service field." These doesn't work together. The first part says "IF" but the second = says "MUST". Does this allow me to publish a NAPTR record set only with TLS? If I MUST publish three NAPTR records - how can I say "this is my record = and I don't want you to connect using this transport" /O= From nobody Mon Dec 15 07:46:49 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513451A6FFD for ; Mon, 15 Dec 2014 07:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rm0ZtCyQa6SU for ; Mon, 15 Dec 2014 07:46:45 -0800 (PST) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ADA61A1BE0 for ; Mon, 15 Dec 2014 07:46:44 -0800 (PST) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-04v.sys.comcast.net with comcast id Trlo1p0062Udklx01rmkNf; Mon, 15 Dec 2014 15:46:44 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-18v.sys.comcast.net with comcast id Trmg1p00W1KKtkw01rmgXk; Mon, 15 Dec 2014 15:46:44 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id sBFFkdWk011178; Mon, 15 Dec 2014 10:46:39 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id sBFFkaDt011176; Mon, 15 Dec 2014 10:46:36 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Olle E. Johansson" In-Reply-To: (oej@edvina.net) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 15 Dec 2014 10:46:36 -0500 Message-ID: <87vblcsyoz.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418658404; bh=lrSODqUKw+91386SNCi52f8astaH1cgdivAoFM6ziDo=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:MIME-Version:Content-Type; b=fG/fug9ol8LU7IU4SfngoMa1xk9ZxO6so6FIksTneemLA9+uCNm9QrEWcO3X7nxtZ tB6cWl6jO9QjcfYJKVPEWduhHVBJCUXObF6kOoeVf382U3EAtOAzoTYZ09ADAV4vja unWHyNieuxcxvJI48khJB1/PDJPVVwz4ckP8ZJgOP//2/1DTEzuVUMLvJwknU6Bcga Ppk2ChnSJhZdjCmZlEqvDKbIOWxZY94yAwI3AnjOMc9vh/RgOcLLDXfNfUrQ/TmIZ0 dhsInKxJSAujJ5vJV3RK93rzaO4J+ioUw0cAF7wbkyBVeCFkxGweQQjj3QhC8vPriy JfnTgnQItPgvA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/9vTO9yT82MbMOJnwrQsaGQQJtGM Cc: sipcore@ietf.org Subject: Re: [sipcore] RFC 3263 NAPTR Rules 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, 15 Dec 2014 15:46:47 -0000 "Olle E. Johansson" writes: > If I MUST publish three NAPTR records - how can I say "this is my > record and I don't want you to connect using this transport" Are you allowed to do that? Aren't SIP servers required to listen on both UDP and TCP? This may be modified by RFC 5630 (revised use of SIPS), though. Dale From nobody Mon Dec 15 10:13:02 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9107E1A8720 for ; Mon, 15 Dec 2014 10:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 exg8D0Hkg71o for ; Mon, 15 Dec 2014 10:12:58 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 09D8A1A86F8 for ; Mon, 15 Dec 2014 10:12:57 -0800 (PST) Received: from [192.168.52.145] (scandic818.host.songnetworks.se [212.214.188.142]) by smtp7.webway.se (Postfix) with ESMTPA id 1584693C2A1; Mon, 15 Dec 2014 18:11:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Olle E. Johansson" In-Reply-To: <87vblcsyoz.fsf@hobgoblin.ariadne.com> Date: Mon, 15 Dec 2014 19:12:55 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <87vblcsyoz.fsf@hobgoblin.ariadne.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/GOVMZc_Vi83YebYdXpGnCQz7mNs Cc: sipcore@ietf.org, Olle E Johansson Subject: Re: [sipcore] RFC 3263 NAPTR Rules 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, 15 Dec 2014 18:13:00 -0000 On 15 Dec 2014, at 16:46, Dale R. Worley wrote: > "Olle E. Johansson" writes: >> If I MUST publish three NAPTR records - how can I say "this is my >> record and I don't want you to connect using this transport" > > Are you allowed to do that? Aren't SIP servers required to listen on > both UDP and TCP? Yes, but in NAPTR I show how I *want* to be connected to :-) > > This may be modified by RFC 5630 (revised use of SIPS), though. The word "NAPTR" is not mentioned in that document. Nor is "DNS". SIP/TLS is the only NAPTR record I want to publish. /O From nobody Mon Dec 15 15:32:14 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAE91A9005 for ; Mon, 15 Dec 2014 15:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBqTovfOlvhC for ; Mon, 15 Dec 2014 15:32:02 -0800 (PST) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6211A8FD3 for ; Mon, 15 Dec 2014 15:32:02 -0800 (PST) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-01v.sys.comcast.net with comcast id TzWm1p0032Udklx01zY1hL; Mon, 15 Dec 2014 23:32:01 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-18v.sys.comcast.net with comcast id TzY01p00B1KKtkw01zY0p4; Mon, 15 Dec 2014 23:32:01 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id sBFNVxp8005518; Mon, 15 Dec 2014 18:31:59 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id sBFNVxIt005515; Mon, 15 Dec 2014 18:31:59 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D57B94F@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 15 Dec 2014 18:31:59 -0500 Message-ID: <877fxsqykw.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418686321; bh=Xovg888nEqi1dm2uH35/uR1gkr4aVQztXXEy2HpejiI=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=GS673hyCqoVIS4I1Qx4I6Yd8dAa6ZoVY7yuG5Kk8c+bm0LZuQ+iQ/8a2hrcwrEvBA lUiofPv/fxy4fQsFN90FBSZXZQnfwpSoVRIFsN4G4H4F4MXehiQCSnNC10VrjkmZju WPW6oZqYpnss9F/aXXt/FxIqLefiPq4SXJE85QZQ8suhpLuK6TzfNETm1RxYujxqRp jSSSZ9y7/4ORHOXc1TnY4JU/eXgAmL+SNw8YbN9RQIdTNLFDw9m06nBx7Aki46ce2r PMeflpFA51yNo6bEZcTlSQ2QyONJ6txs6Yr7BUhL1ho/PVp/sUTGONlOBrUFd6jZht PLUEOc7LXeOUQ== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/spzYtgcUpdS4mz1h1ltRSLr66nc Cc: sipcore@ietf.org Subject: Re: [sipcore] Allow semantics 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, 15 Dec 2014 23:32:04 -0000 Christer Holmberg writes: > When a UA inserts information in a request, it should be clear what > the scope of the information is. My memory of the discussion was that it's conclusion is "It isn't clear what the scope of the information is, and it's probably impossible to make it so." Dale From nobody Wed Dec 17 00:20:33 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18E51A3BA5 for ; Wed, 17 Dec 2014 00:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.848 X-Spam-Level: ** X-Spam-Status: No, score=2.848 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, SPF_PASS=-0.001, URIBL_DBL_ABUSE_BOTCC=2.5] 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 TqKt0MHeH_jC for ; Wed, 17 Dec 2014 00:20:19 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1461A1BBC for ; Wed, 17 Dec 2014 00:20:18 -0800 (PST) Received: from [192.168.8.100] (2.71.209.109.mobile.tre.se [2.71.209.109]) by smtp7.webway.se (Postfix) with ESMTPA id 9C87D93DE5C; Wed, 17 Dec 2014 08:19:16 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Olle E. Johansson" In-Reply-To: Date: Wed, 17 Dec 2014 09:20:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <137ADE3E-B2C2-47E1-A24F-B0E8FB57C88E@edvina.net> References: To: SIPCORE X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/IQOjIJykgHEMdrgz_4rsQ3k13CU Cc: Olle E Johansson Subject: Re: [sipcore] RFC 3263 NAPTR Rules 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, 17 Dec 2014 08:20:22 -0000 On 15 Dec 2014, at 15:13, Olle E. Johansson wrote: > Hello!=20 > In a discussion about NAPTR today I ended up confusing myself and = reading the RFC did not make me less confused. >=20 > Section 4.1 says: >=20 > "If the server supports > multiple transport protocols, there will be multiple NAPTR records, > each with a different service value." >=20 > Later the same section says: >=20 > "If a SIP proxy, redirect server, or registrar is to be contacted > through the lookup of NAPTR records, there MUST be at least three > records - one with a "SIP+D2T" service field, one with a "SIP+D2U" > service field, and one with a "SIPS+D2T" service field." >=20 >=20 > These doesn't work together. The first part says "IF" but the second = says "MUST". >=20 > Does this allow me to publish a NAPTR record set only with TLS? >=20 > If I MUST publish three NAPTR records - how can I say "this is my = record and I don't want you to connect using this transport" Seems like we need to clear this up somewhere.=20 In addition to the above issues we now have a situation where a server = may support WebSocket transport, but a NAPTR record for that transport does not make sense. That may be in the WebSocket RFC = though. /O= From nobody Wed Dec 17 04:37:57 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8075D1A89E7 for ; Wed, 17 Dec 2014 04:37:56 -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 GH0Q9L0OCqUW for ; Wed, 17 Dec 2014 04:37:53 -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 088361A89AE for ; Wed, 17 Dec 2014 04:37:52 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-c4-5491791e765a Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 98.32.04076.E1971945; Wed, 17 Dec 2014 13:37:50 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0195.001; Wed, 17 Dec 2014 13:37:50 +0100 From: Christer Holmberg To: Andrew Allen , Ivo Sedlacek , "Leis, Peter (NSN - DE/Munich)" , ext Adam Roach , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQBeGiFbV1ztW9cUOimw2I9kop/5x1Mf8AgABuBICAAINygIAE5fuAgAAvDgCAANc/AIACMF4AgAEKyRCAAV2XgIAAI1YAgADoEgCAEizAQA== Date: Wed, 17 Dec 2014 12:37:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.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> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3RleucmKIwe6lphb3521ltNjzdxG7 xbLz25gtVmw4wGrx9ccmNgdWj7/vPzB5zGpYy+6xZMlPIGvnExaPn+uvsgewRnHZpKTmZJal FunbJXBl3D3whrHgg1PF4bMbmBsYd5l3MXJySAiYSJyYd4MRwhaTuHBvPVsXIxeHkMARRonz C1pYIJwljBL/vx0HquLgYBOwkOj+pw0SFxH4B1T06BErSLewQLDE682dLCC2iECIxMz1Oxgh 7DqJx2d+M4PYLAKqEnNefQCzeQV8JW7uPMIIseA2q0TfjtOsIAs4BTwl7q0RAKlhBLro+6k1 TCA2s4C4xK0n85kgLhWQWLLnPDOELSrx8vE/VghbUaL9aQMjRL2OxILdn9ggbG2JZQtfQ+0V lDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBEbZ wS2/rXYwHnzueIhRgINRiYd3w8cJIUKsiWXFlbmHGKU5WJTEeReemxcsJJCeWJKanZpakFoU X1Sak1p8iJGJg1OqgTFh79Ub+/9fvXugQvxGWvm7ic5TW6alb3rqvPuhs/dhh6Djmz114/Yx VtcqOQotv5E9PfKqyx95/S9fX92LnftyU82h5519Yi17IvjLD32s5J0929Z3fnJZ0uS17zg9 szKqbVi9vv+9/ft53rPqb91lxVwb1y5+57hyc8qfnb5HN3zdsdBE+1eKEktxRqKhFnNRcSIA XWEhz5MCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/j_rS6rrx1k89vCQGMeyD8gnVqRE 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, 17 Dec 2014 12:37:56 -0000 Hi, Are people ok with Andrew's suggestion? Regards, Christer -----Original Message----- From: Andrew Allen [mailto:aallen@blackberry.com]=20 Sent: 6. joulukuuta 2014 2:05 To: Ivo Sedlacek; Leis, Peter (NSN - DE/Munich); Christer Holmberg; ext Ada= m Roach; Paul Kyzivat; sipcore@ietf.org Subject: RE: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Robert, Adam and all Can you live with this as a compromise? Basically document and accept that there are existing applications which us= e RFC4488 and feature tags to indicate that the UAS will accept the UAC req= uest not to create a subscription. But deprecate this behavior for new appl= ications going forward and require for future applications the use of [I-D.= ietf-sipcore-refer-explicit-subscription] in order to reuse then existing d= ialog. Andrew=20 -----Original Message----- From: Ivo Sedlacek [mailto:ivo.sedlacek@ericsson.com] Sent: Friday, December 05, 2014 5:14 AM To: Leis, Peter (NSN - DE/Munich); Christer Holmberg; Andrew Allen; ext Ada= m Roach; Paul Kyzivat; sipcore@ietf.org Subject: RE: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt This compromise would work for me too. Kind regards Ivo 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 Leis, Peter (N= SN - DE/Munich) Sent: 5. prosince 2014 9:07 To: Christer Holmberg; Andrew Allen; ext Adam Roach; Paul Kyzivat; sipcore@= ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hi, The compromise described by Andrew would work for me. Regards Peter -----Original Message----- From: ext Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Thursday, December 04, 2014 11:17 AM To: Andrew Allen; Leis, Peter (NSN - DE/Munich); ext Adam Roach; Paul Kyziv= at; sipcore@ietf.org Subject: RE: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hi, I support Andrew's suggestion. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew Allen Sent: 3. joulukuuta 2014 21:21 To: Leis, Peter (NSN - DE/Munich); ext Adam Roach; Paul Kyzivat; sipcore@ie= tf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Maybe the way out of this rat hole is to discuss in the text and allow lega= cy application usages (similar to the legacy usages for INFO). So SIP stac= ks could be considered RFC 6665 compliant with legacy application usages us= ing RFC 4488 and feature tags identifying application specific behavior tha= t ensures that dialog reuse does not occur but that we deprecate such usage= s for any new applications that are developed and insist on the use of [I-D= .ietf-sipcore-refer-explicit-subscription] going forward.=20 =09 As Christer said: The only reason these "special environment" use-cases exist to begin with i= s because previously there was no "pure" protocol mechanism for preventing = implicit subscriptions. And, as they have existed for a while already, and = have been implemented, they will not suddenly go away just because we now h= ave [I-D.ietf-sipcore-refer-explicit-subscription]. Neither will they go aw= ay just because we now have drafts clarifying some RFCs.=20 BUT, because we now DO have a "pure" protocol mechanism [I-D.ietf-sipcore-r= efer-explicit-subscription] for preventing implicit subscriptions, I assume= there will be no NEW "special environment" use-cases in future - people WI= LL use [I-D.ietf-sipcore-refer-explicit-subscription] :) Is that something we could all agree on as a compromise? Andrew -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Leis, Peter (N= SN - DE/Munich) Sent: Tuesday, December 02, 2014 4:56 AM To: ext Adam Roach; Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt Hi, The specific environment is described in 3GPP TS 24.237. For the specific c= ase, both ends of the signaling comply to this spec, both ends of the signa= ling are network nodes. These network nodes either reside in the same netwo= rk, or reside in different networks, and in this case there would be some s= ort of agreement between the operators.=20 At the time when the solution in 24.237 was designed (pointed at in Ivo's p= roposal), there was no IETF solution available. So I guess it would be grea= t if the draft does not make the existing solution invalid. Regards Peter -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Adam Roach Sent: Monday, December 01, 2014 10:05 PM To: Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt On 12/1/14 10:16, Paul Kyzivat wrote: > On 11/28/14 10:28 AM, Ivo Sedlacek wrote: >> Hello, >> >> I think Andrew's proposed statement can be replaced by the statement=20 >> already existing in the draft, i.e. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> If a user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request (such as by requiring >> an extension that disallows any such subscription >> [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request >> MAY be sent within an existing dialog. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> and extended as follows: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> If a user agent can be certain that no implicit subscription will be >> created as a result of sending a REFER request (such as by requiring >> an extension that disallows any such subscription >> [I-D.ietf-sipcore-refer-explicit-subscription] >>>or by RFC4488=20 >> together with configuration / application logic in specific=20 >> environment ensuring that implicit subscription is not created<<<),=20 >> the REFER request >> MAY be sent within an existing dialog. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > What criteria do you use to be *certain*? > > Some agreement of compliance to some specification seems to be required. > > I gather that what you have in mind is that both ends have been=20 > verified to conform to particular versions of the IMS specification. > Do you ever really know that for certain in the presence of gateways=20 > to foreign devices? Right; this is the real problem. The assumption that this is somehow "safe"= to do because of some unsignaled, un-negotiated hidden agreement is extrem= ely fragile and way outside the various extension mechanisms that SIP makes= use of. Walled gardens grow doors. You don't want things to break in spectacular an= d undiagnosable ways when they do. I'm sad that some networks have decided = to ignore the exact parts of specs that were designed to foster interop and= prevent these surprise behaviors, and I see dangerous precedent in codifyi= ng this misbehavior as proposed above. Walled gardens grow doors faster than you're probably willing to believe. I= 'm frankly astonished by how quickly IMS has turned its eyes to WebRTC, ask= ing for special accommodation for features particular to 3GPP specification= s (cf. AMR). That only goes so far: you won't readily see JavaScript SIP st= acks conforming to this hidden, unnegotiated agreement that presumably exis= ts in IMS (but not elsewhere). It's an honest-to-goodness protocol fork, an= engineered incompatibility. Walled gardens grow doors. It's time to start cleaning up the IMS garden to= match SIP behavior, rather than handing out indulgences for its past sins. You're trying to fix this in the wrong SDO. /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Dec 18 08:22:23 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DC21A90FC for ; Thu, 18 Dec 2014 08:22: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 XowTtq_Syu4p for ; Thu, 18 Dec 2014 08:22:12 -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 A2C021A90F7 for ; Thu, 18 Dec 2014 08:22:09 -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 sBIGM16E015723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2014 10:22:02 -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: <5492FF29.3070206@nostrum.com> Date: Thu, 18 Dec 2014 10:22:01 -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: Christer Holmberg , Andrew Allen , Ivo Sedlacek , "Leis, Peter (NSN - DE/Munich)" , Paul Kyzivat , "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> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5F971D@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/hhX3aT6NEWLkBuPRt6A70rZ7ybA 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, 18 Dec 2014 16:22:16 -0000 On 12/17/14 06:37, Christer Holmberg wrote: > 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. /a From nobody Thu Dec 18 08:57:26 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22971A8ADF for ; Thu, 18 Dec 2014 08:57:22 -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 CbgcWnZ9YCbm for ; Thu, 18 Dec 2014 08:57:20 -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 DB5C11A8AB4 for ; Thu, 18 Dec 2014 08:57:19 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-e0-5493076d1cec Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 35.FB.29772.D6703945; Thu, 18 Dec 2014 17:57:17 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 17:57:17 +0100 From: Christer Holmberg To: Adam Roach , Andrew Allen , "Ivo Sedlacek" , "Leis, Peter (NSN - DE/Munich)" , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQBeGiFbV1ztW9cUOimw2I9kop/5x1Mf8AgABuBICAAINygIAE5fuAgAAvDgCAANc/AIACMF4AgAEKyRCAAV2XgIAAI1YAgADoEgCAEizAQIABwFeAgAAZMiA= Date: Thu, 18 Dec 2014 16:57:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D604C5C@ESESSMB209.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> In-Reply-To: <5492FF29.3070206@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3RjeXfXKIQeseG4v787YyWuz5u4jd Ytn5bcwWKzYcYLX4+mMTmwOrx9/3H5g8ZjWsZfdYsuQnkLXzCYvHz/VX2QNYo7hsUlJzMstS i/TtErgyzl+4xl6wibvi2oKFTA2MPdxdjJwcEgImEit2bGSDsMUkLtxbD2RzcQgJHGGU2LZh ESOEs4RRYk7TZpYuRg4ONgELie5/2iBxEYE/jBL73x1kBOkWFgiWeL25kwXEFhEIkZi5fgcj RFEXo8TXuzfBilgEVCXe3NgCto5XwFfi4IsHUOsOsEncOvoWLMEpoC3Rvvkx2CRGoJu+n1rD BGIzC4hL3HoynwniVgGJJXvOM0PYohIvH/9jhbCVJBqXPGEFuZRZQFNi/S59iFZFiSndD9kh 9gpKnJz5hGUCo+gsJFNnIXTMQtIxC0nHAkaWVYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiB UXZwy2+DHYwvnzseYhTgYFTi4TVwnhQixJpYVlyZe4hRmoNFSZx34bl5wUIC6YklqdmpqQWp RfFFpTmpxYcYmTg4pRoYJcwSZQM5y+8svSmkcEYmt+dTg42MQMelxDn7/7YVz8pjfWwbml7U 8F7HRnx/LuPMi873Vkkvv/FBTGDO9eBP2lUBnJwxD100VrRxTnY9oBqTVDjj6G3xs//uumtU bNz87AHzk501UmvtkrPDu+Od2/7EMnRkHhD52i6Tc+n3mqPNzmkLD25XYinOSDTUYi4qTgQA PLjqVJMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/Jkv81NmQ7XD4aA3GSoZQJfZlhXI 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, 18 Dec 2014 16:57:23 -0000 SGksDQoNCj4+IENhbiB5b3UgbGl2ZSB3aXRoIHRoaXMgYXMgYSBjb21wcm9taXNlPw0KPj4NCj4+ IEJhc2ljYWxseSBkb2N1bWVudCBhbmQgYWNjZXB0IHRoYXQgdGhlcmUgYXJlIGV4aXN0aW5nIGFw cGxpY2F0aW9ucyB3aGljaCB1c2UgUkZDNDQ4OCBhbmQgDQo+PiBmZWF0dXJlIHRhZ3MgdG8gaW5k aWNhdGUgdGhhdCB0aGUgVUFTIHdpbGwgYWNjZXB0IHRoZSBVQUMgcmVxdWVzdCBub3QgdG8gY3Jl YXRlIGEgc3Vic2NyaXB0aW9uLiANCj4+IEJ1dCBkZXByZWNhdGUgdGhpcyBiZWhhdmlvciBmb3Ig bmV3IGFwcGxpY2F0aW9ucyBnb2luZyBmb3J3YXJkIGFuZCByZXF1aXJlIGZvciBmdXR1cmUgYXBw bGljYXRpb25zDQo+PiB0aGUgdXNlIG9mIFtJLUQuaWV0Zi1zaXBjb3JlLXJlZmVyLWV4cGxpY2l0 LXN1YnNjcmlwdGlvbl0gaW4gb3JkZXIgdG8gcmV1c2UgdGhlbiBleGlzdGluZyBkaWFsb2cuDQo+ DQo+IEknbSBub3QgaW4gbG92ZSB3aXRoIGl0LCBidXQgSSBjYW4gbGl2ZSB3aXRoIGl0LiBJJ20g c3RpbGwgYXBwcmVoZW5zaXZlIGFib3V0IHRoZSBwcmVjZWRlbnQgb2YgY29uZG9uaW5nIA0KPiBv dXQtb2Ytc3BlYyBiZWhhdmlvciBhZnRlciB0aGUgZmFjdCwgYW5kIHdvdWxkIHByZWZlciBzb21l dGhpbmcgdGhhdCBkcml2ZXMgM0dQUCB0byBpbmNvcnBvcmF0ZSANCj4gbW9yZSBjb21wbGlhbnQg YmVoYXZpb3IgaW4gZnV0dXJlIHJldmlzaW9ucy4gQnV0IGlmIGV2ZXJ5b25lIGVsc2UgaXMgaGFw cHkgd2l0aCB0aGlzIGdlbmVyYWwgcHJpbmNpcGxlLCBJJ2xsIHN0YXkgb3V0IG9mIHRoZSB3YXku DQoNCkkgYXBwcmVjaWF0ZSB0aGF0IHlvdSBjYW4gbGl2ZSB3aXRoIHRoZSBjb21wcm9taXNlLg0K DQpBbmQsIGFnYWluLCBhcyB3ZSBub3cgd2lsbCBoYXZlIGFuIElFVEYgbWVjaGFuaXNtLCBJIGFt IHN1cmUgM0dQUCB3aWxsIHVzZSBpdCBpbiBhbnkgZnV0dXJlIHVzZS1jYXNlcy4gQXQgbGVhc3Qg SSB3b3VsZCBwdXNoIGZvciBpdCwgYW5kIEkgc2VlIG5vIHJlYXNvbiB3aHkgb3RoZXJzIHdvdWxk bid0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQo= From nobody Thu Dec 18 14:46:11 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E791A8795 for ; Thu, 18 Dec 2014 14:46:09 -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 O_KYfEBh8P87 for ; Thu, 18 Dec 2014 14:46: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 53E1B1A878B for ; Thu, 18 Dec 2014 14:46: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 sBIMk7YZ056749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 18 Dec 2014 16:46:07 -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: <5493592A.3080302@nostrum.com> Date: Thu, 18 Dec 2014 16:46:02 -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: <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> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D604C5C@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/PsupA60UIo83cVToxusk4HrAFkk 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, 18 Dec 2014 22:46:10 -0000 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 From nobody Fri Dec 19 04:51:11 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5A01A9130 for ; Fri, 19 Dec 2014 04:51:09 -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 Xjux35Mdkop0 for ; Fri, 19 Dec 2014 04:51:07 -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 59F5A1A9108 for ; Fri, 19 Dec 2014 04:51:06 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-8b-54941f37a4f9 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9C.A1.04076.73F14945; Fri, 19 Dec 2014 13:51:04 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 13:51:03 +0100 From: Christer Holmberg To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQBeGiFbV1ztW9cUOimw2I9kop/5x1Mf8AgABuBICAAINygIAE5fuAgAAvDgCAANc/AIACMF4AgAEKyRCAAV2XgIAAI1YAgADoEgCAEizAQIABwFeAgAAZMiCAAFIZAIAA+ddQ Date: Fri, 19 Dec 2014 12:51:02 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D60C1C0@ESESSMB209.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> In-Reply-To: <5493592A.3080302@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvja6F/JQQg33XOCyuzWlks/j6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJUxe81htoLfChXtLx6yNzD+lepi5OSQEDCR WL/zJxuELSZx4d56MFtI4AijxP+5/l2MXED2EkaJP/1zmbsYOTjYBCwkuv9pg9SICARKLJy0 hAXEFhYIlni9uZMFIh4iMXP9DkaQXhGBaYwST+83g/WyCKhKPG8PBqnhFfCVeN58hBFi/lJ2 iQenXjCDJDgFtCUurLrPCGIzAh30/dQaJhCbWUBc4taT+UwQhwpILNlznhnCFpV4+fgfK4St KHF1+nKoeh2JBbs/sUHY2hLLFr5mhlgsKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiFC1O LS7OTTcy0kstykwuLs7P08tLLdnECIyTg1t+W+1gPPjc8RCjAAejEg/vhimTQ4RYE8uKK3MP MUpzsCiJ8y48Ny9YSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6PKhma13fyNuREGDEoNHzlf y+Rr6DuHlX96Vp2hff3YJ4FeK5fu2TyHDjFeFniXs63xvPVbUVn3e/9D1m3Wm11w/MuKO0lp lxZf+taXce2VQ/LGWXa1fIZxy+JMDz/hqnt5N8E0qjZx9rwV0zbrVm3P+bBXq5TbRMdvhv7q 8p1s5lqrBZZ4bVNiKc5INNRiLipOBABphKV5dAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/46fJ0a675hus6KlBWP8CbOQVuwU 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, 19 Dec 2014 12:51:09 -0000 Hi Robert, In general, the text looks good, and I also very much appreciate the fact t= hat you are willing to work on a compromise. A couple of comments, though. Q1: I don't think the statement regarding failed interoperability is correc= t (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 implem= entations in the specialized environments mentioned above." 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..."). 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-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 will = fail to interoperate with standard implementations outside those environmen= ts. The extensions in [I-D.ietf-sipcore-refer-explicit-subscription] provid= e 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=20 >>> 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=20 >>> require for future applications the use of [I-D.ietf-sipcore-refer-expl= icit-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 incorpora= te more compliant behavior in future revisions. But if everyone else is hap= py 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 us= e it in any future use-cases. At least I would push for it, and I see no re= ason 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 Fri Dec 19 06:12:19 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF331A8897 for ; Fri, 19 Dec 2014 06:12:09 -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 JvybQ46JKrSX for ; Fri, 19 Dec 2014 06:12:07 -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 1C1CF1A8875 for ; Fri, 19 Dec 2014 06:12:07 -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 sBJEC24V038786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 19 Dec 2014 08:12: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: <5494322D.4050801@nostrum.com> Date: Fri, 19 Dec 2014 08:11: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/PBo9sXyGdSwapqdg30udu-_ykMY 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, 19 Dec 2014 14:12:10 -0000 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. I went looking for that explanation to refresh my memory, but couldn't find it quickly. Can you provide a pointer? > 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." > > 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..."). > > 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 Sat Dec 20 06:09:17 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2DC1A9149 for ; Sat, 20 Dec 2014 06:09:15 -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 w9-1cgdTF1_s for ; Sat, 20 Dec 2014 06:09:14 -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 B453A1A1AC6 for ; Sat, 20 Dec 2014 06:09:13 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-fe-54958307d923 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 76.F0.29772.70385945; Sat, 20 Dec 2014 15:09:11 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0195.001; Sat, 20 Dec 2014 15:09:11 +0100 From: Christer Holmberg To: Robert Sparks , "sipcore@ietf.org" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQBeGiFbV1ztW9cUOimw2I9kop/5x1Mf8AgABuBICAAINygIAE5fuAgAAvDgCAANc/AIACMF4AgAEKyRCAAV2XgIAAI1YAgADoEgCAEizAQIABwFeAgAAZMiCAAFIZAIAA+ddQgAAI3ICAAaIJUA== Date: Sat, 20 Dec 2014 14:09:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D61085D@ESESSMB209.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> <5494322D.4050801@nostrum.com> In-Reply-To: <5494322D.4050801@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+JvjS5789QQg0dtZhbX5jSyWXz9sYnN gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4MpY3JpccIWl4tLT++wNjFeYuxg5OSQETCTu 97xmgbDFJC7cW8/WxcjFISRwhFGiY80rNpCEkMASRon2JUANHBxsAhYS3f+0QcIiAoESCyct AesVFgiWeL25kwUiHiIxc/0ORgh7GaPE33mVIDaLgKrEjnv97CA2r4CvxPI9M1khdnVxSBxZ 1MwKkuAU0JbYs3IpWDMj0EHfT61hArGZBcQlbj2ZzwRxqIDEkj3noR4QlXj5+B8rhK0ksWL7 JUaIeh2JBbs/sUHY2hLLFr5mhlgsKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiFC1OLU7K TTcy0kstykwuLs7P08tLLdnECIySg1t+G+xgfPnc8RCjAAejEg9vgdzUECHWxLLiytxDjNIc LErivAvPzQsWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwFh7cDvPlI0Hsz84+Z11unqR78Ye 79Qrv187Hr+517yeddbMSw9+/L3fpSmqlDxHJsD4VIm1WoNZXXvj3SAen/h7Zz+Kx1X8Szx/ WVd23n+BCr1/wam7fyyfmDVDivtR8smerxOfeRd+au3LOhuyrmHVmqlxSw/YX4sKzJjHf3PS CR7OlN//TzxQYinOSDTUYi4qTgQAzvEFnHMCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/pcWAQwGh_V1M-Cho9_k8ctNl6S8 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: Sat, 20 Dec 2014 14:09:15 -0000 Hi, >> In general, the text looks good, and I also very much appreciate the fac= t that you are=20 >> willing to work on a compromise. A couple of comments, though. >> >> Q1: I don't think the statement regarding failed interoperability is cor= rect (Ivo has previously explained=20 >> how it would work), so I suggest to remove that. > > I went looking for that explanation to refresh my memory, but couldn't fi= nd it quickly. Can you provide a pointer? I'll look for it, or Ivo can provide the pointer himself (unless he has lef= t for xmas vacation). Regards, Christer From nobody Sun Dec 21 23:54:44 2014 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647E71A888A for ; Sun, 21 Dec 2014 23:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dHDEKnCI_i2 for ; Sun, 21 Dec 2014 23:54:39 -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 3B23D1A0178 for ; Sun, 21 Dec 2014 23:54:38 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-9c-5497ce3cc357 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 67.81.04231.C3EC7945; Mon, 22 Dec 2014 08:54:36 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.90]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0195.001; Mon, 22 Dec 2014 08:54:35 +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: AQHQG5XOzFpS4G8yfkele2rH2P47lpybQFBQ Date: Mon, 22 Dec 2014 07:54:35 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127CEA71@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> <5494322D.4050801@nostrum.com> In-Reply-To: <5494322D.4050801@nostrum.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/mixed; boundary="_002_39B5E4D390E9BD4890E2B31079006101127CEA71ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSfUhTURjGO/feXa8y6bhmvqwPatk/amZaVFLRB4l/FBRJ2YfWqGuZumLX rKDAnBJqK63Mdmm55pSa0SKtVmqYyCIS+8KPTCtpZrqiKKyJOnL3GK3/fg/nue97zvNcjlbc YlVcujab12k1mWo2iDEmj59YsKKtPCnG+GrOso4rp9hlw5477Goq0WodoRLFBy5mE7UjaMU+ PjM9h9ctXLUn6MB7sVN22JqHjum9hbJcVJBVhAI5wIvhdX+PjPB0ePHOzhahIE6BWxCYvl5C RFQiGBk2Sy4WR0NpXYvMd6DEBQjc48+lg2l4C7hrCxkfK3ESGO0ORDgWhly/WB8zeD6M1lsl DsYboan+noxsKOKgxaKXBgXiSGi4USV9jPAsaB8zSEzjMOh2VVDkrkroe/mMJRwKgx+9k29Q g+XtzwkPN+FPh9Iz8WRXCDw1upgSpBT9Jon/XKKfi1iiwFz/gyUcCdXX3DThmVBbVojEiVvT vudbrpyXhALfRtA7cJ0m4iIFZZ5eiogLCC43fWeJqEVg7bcFEPEaQddNt4yIagq6a4onpzkR NPaNSjsV2ILg4Wis6Be/KCW7GdqtJZLHl36Lx06JfumLk+mbO7+xxBMBJqc+QJSaCIeeklxG nGyiuOMRIrtsFJy1pfpYjpfDKWc5TTgH+oYqWF9kcnwcavWcKHUVBQOnO6Qxf7v6P2FfJytB fOJkCWOwNjynzWipDYUKvCBk7Y+Ni+Z16XsF4ZA2Wstn30ETP/jjutEFDlTjXtOMMIfU8uCY wvIkhUyTIxzPakYzOEYdFmxpu7pFgfdrsvkMnj/M63brjmTyQjOiuEBVLpryfootMbvVkLLt 4E4d83Shk1/32Ksal5ni70ZQmsGjPzIKqntGPuU5Wr/8NjndAakD3xrfuE+qkttVa+/fzHDo wj7M6zdHVq6PX3LwczE11TzWGW6Y+/PjkbaE2XHyc9OGryvzQzq30Vu9GzwpCYb87caG+7uq XJEhaV1pFrtDo2aEA5pFEbRO0PwB/gu04sEDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/sipcore/EmYY-W6R9JDIImFY4UFz15teCBM 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, 22 Dec 2014 07:54:42 -0000 --_002_39B5E4D390E9BD4890E2B31079006101127CEA71ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > I went looking for that explanation to refresh my memory, but couldn't fi= nd=20 > 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.= =20 - the REFER with norefersub is sent (by the UA which acted as the UAS of th= e initial INVITE request) within the dialog *ONLY* if the UAC of initial IN= VITE request indicated the media feature tag and support of norefersub in t= he initial INVITE request. - description of the feature associated with the media feature tag guarante= es that recipient of the REFER with norefersub will accept the REFER withou= t creating an implicit subscription. The original mail with the short description is attached. =09 Kind regards Ivo Sedlacek --_002_39B5E4D390E9BD4890E2B31079006101127CEA71ESESSMB301erics_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Mon, 22 Dec 2014 07:54:33 GMT"; modification-date="Mon, 22 Dec 2014 07:54:33 GMT" Received: from sesbmg11.ericsson.net (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.76) with Microsoft SMTP Server id 14.3.195.1; Tue, 2 Dec 2014 11:39:33 +0100 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by sesbmg11.ericsson.net (Symantec Mail Security) with SMTP id 10.3E.03834.4E69D745; Tue, 2 Dec 2014 11:39:33 +0100 (CET) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9225F1A1A7A; Tue, 2 Dec 2014 02:39:30 -0800 (PST) Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA071A1A7A for ; Tue, 2 Dec 2014 02:39:28 -0800 (PST) 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 tR7yEtHJiYLR for ; Tue, 2 Dec 2014 02:39:25 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B849E1A1A75 for ; Tue, 2 Dec 2014 02:39:24 -0800 (PST) Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 38.E1.04076.AD69D745; Tue, 2 Dec 2014 11:39:22 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.89]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 11:39:22 +0100 From: Ivo Sedlacek To: Paul Kyzivat , "sipcore@ietf.org" Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-00.txt Thread-Index: AQHQDZMdZAj7dUN0V0+4uMx83fMm0px8GRmw Sender: sipcore Date: Tue, 2 Dec 2014 10:39:21 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101127B4030@ESESSMB301.ericsson.se> References: <20141121231918.10664.22029.idtracker@ietfa.amsl.com> <39B5E4D390E9BD4890E2B31079006101127A5796@ESESSMB301.ericsson.se> <39B5E4D390E9BD4890E2B31079006101127A5FFC@ESESSMB301.ericsson.se> <547CB095.6060306@alum.mit.edu> List-Help: List-Subscribe: , List-Unsubscribe: , In-Reply-To: <547CB095.6060306@alum.mit.edu> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Exchange-Organization-AuthSource: ESESSHC019.ericsson.se X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: x-brightmail-tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje6tabUhBt/eGFis2HCA1eLrj01s Dkwef99/YPJYsuQnUwBTFJdNSmpOZllqkb5dAlfG9oUr2Qv2+1X8eNnL3sD4za6LkZNDQsBE YsLGd6wQtpjEhXvr2boYuTiEBI4wShz+eBYsISSwiFFi128jEJtNQE9i4pYjYHERgUCJq0sm MIPYwgLBEq83d7JAxEMkZq7fwQhhG0ksuP6eDcRmEVCRuDOhAayGV8BXovvaPkaI+auYJPpW xYHYnAI6Es/br4HVMArISlz90wtWwywgLnHryXwmiEMFJJbsOc8MYYtKvHz8D+oBRYmdZ9uZ Iep1JBbs/sQGYWtLLFv4mhlir6DEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyilG0OLW4ODfd yEgvtSgzubg4P08vL7VkEyMwTg5u+W21g/Hgc8dDjAIcjEo8vB8+1YQIsSaWFVfmHmKU5mBR EuddeG5esJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZG3kf5bx/EH2H9FH9NRWVrZeaOH3X7 3Ccz2d/kCQ+Jjw/52WvCemE/ww/bd4Ir5141ndzI/mbjJLt5ERsMzlauKqs5kMyeZq7/svcx e8ALnwvms9zqji/WeTiRM6Yq0ft6k/id7h2xO3dzbfrHOuHk2aP/2dSZNjGurVeI/PFAvVt5 g0wxY1mzEktxRqKhFnNRcSIAsqNazHQCAAA= x-auditid: c1b4fb39-f79586d000000efa-2b-547d96e32488 x-originating-ip: [153.88.183.16] x-virus-scanned: amavisd-new at amsl.com list-id: SIP Core Working Group x-mailman-version: 2.1.15 delivered-to: sipcore@ietfa.amsl.com x-beenthere: sipcore@ietf.org x-original-to: sipcore@ietfa.amsl.com list-post: x-spam-flag: NO list-archive: errors-to: sipcore-bounces@ietf.org dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1417516770; bh=hLq/JGP6KhJZeyXfZY6Is4gkc1C7Mu72XQ1ggV5tR9k=; h=From:To:Date:Message-ID:References:In-Reply-To:MIME-Version: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=hp+d4e3qGQy0KuGlABkQHLazlfciRmDiyPrAK1SIEjNe3PoouxoUc2RMTPAvjuBr2 25xY++k2fQssp7bZ/WQIWtfg1m7oIvokDhfhZ7UdmCkUMYeUYmR11bg6eb28svCCc0 iycRoHqMBuvmTOT3D3Tx9+3d+w2dMel0s88+94Nk= 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 x-spam-score: -4.201 Content-Type: text/plain; charset="us-ascii" Content-ID: <7261C7E41A04FF4983390C4E21535A4D@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 > What criteria do you use to be *certain*? 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 within the dialog *ONLY* if the UAC of = initial INVITE request indicated the media feature tag and support of noref= ersub in the initial INVITE request. - description of the feature associated with the media feature tag guarante= es that recipient of the REFER with norefersub will accept the REFER withou= t creating an implicit subscription. Works. Kind regards Ivo Sedlacek -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 1. prosince 2014 19:17 To: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-refer-clarifications-= 00.txt On 11/28/14 10:28 AM, Ivo Sedlacek wrote: > Hello, > > I think Andrew's proposed statement can be replaced by the statement alre= ady existing in the draft, i.e. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > If a user agent can be certain that no implicit subscription will be > created as a result of sending a REFER request (such as by requiring > an extension that disallows any such subscription > [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request > MAY be sent within an existing dialog. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > and extended as follows: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > If a user agent can be certain that no implicit subscription will be > created as a result of sending a REFER request (such as by requiring > an extension that disallows any such subscription > [I-D.ietf-sipcore-refer-explicit-subscription] >>>or by RFC4488 toget= her with configuration / application logic in specific environment ensurin= g that implicit subscription is not created<<<), the REFER request > MAY be sent within an existing dialog. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D What criteria do you use to be *certain*? Some agreement of compliance to some specification seems to be required. I gather that what you have in mind is that both ends have been verified to= conform to particular versions of the IMS specification. Do you ever reall= y know that for certain in the presence of gateways to foreign devices? Thanks, Paul > Kind regards > > Ivo Sedlacek > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Ivo > Sedlacek > Sent: 28. listopadu 2014 8:38 > To: Andrew Allen; sipcore@ietf.org > Subject: Re: [sipcore] I-D Action: > draft-ietf-sipcore-refer-clarifications-00.txt > > Hello, > > I disagree with proposed statement: > > "Only > when using the explicit subscription mechanism to require that > a subscription not be created MAY the REFER request be sent > within an existing dialog." > > There are existing means how the UA can be sure that implicit subscriptio= n will not be created - they rely on media feature tag and RFC4488, but wor= k neverthless. > > Therefore, I see the proposed statement as unnecessary restrictive. RFC66= 65 statement is sufficient. > > Kind regards > > Ivo Sedlacek > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew > Allen > Sent: 28. listopadu 2014 2:04 > To: sipcore@ietf.org > Subject: Re: [sipcore] I-D Action: > draft-ietf-sipcore-refer-clarifications-00.txt > > Robert > > Thanks for getting the WG version of the draft out. > > The main issue for me with the draft is the criteria for how the UA knows= that it will not end up with an explicit subscription. Currently the draft= is vague about that. > > Some deployments don't currently have the potential to create an implicit= subscription because of something defined outside of the SIP protocol ensu= res that they only perform a subset of the defined behavior in RFCs 3515, 6= 665 and 4488 i.e. by defining that the UAC always includes refersub=3Dfalse= and by defining that the UAS always accepts that request to not create a s= ubscription with the only way for a UAC to determine that the UAS will beha= ve that way is because it (maybe) received a media-feature tag or feature c= apability indicator that it knows by means outside the SIP protocol (from s= ome other SDOs specification or it's a proprietary implementation where a s= ingle vendor defines both ends) that this will be the behavior. > > I think we should clearly decide whether this fulfils the criteria for a = UAC to determine definitively that no implicit subscription will be created= and hence allows the UAC to send the Refer on an existing dialog or not. > > My own preference is not to have this qualify as a way for a UAC to be ce= rtain as this makes SIP protocol behavior dependent on some higher layer ap= plication semantic creating a tight coupling between the application and th= e SIP protocol stack making it difficult to reuse off the shelf SIP stacks = for you application. It should be a protocol issue (defined in RFCs) not an= application issue as to whether a request is sent on the same or a differe= nt dialog. > > I am also concerned that this kind of thing makes it more likely that the= UAS in these cases ends up being only a partial implementation of the prot= ocol (e.g. It doesn't even implement receiving a Refer out of dialog and ca= nnot send a Notify even if a UAC did not include Refersub =3D false). I thi= nk the discussion we had in Dispatch in Hawaii shows that future interopera= bility problems are caused when only partial implementations of the protoco= l are done and assumptions about the behavior in perpetuity of the UAC are = made. > > My preference is that refer-clarifications should only allow refer-explic= it-subscription mechanism as a means for UAC to determine that its ok to se= nd the Refer on an existing dialog and that we make refer-clarifications de= pendent on refer-explicit-subscription. If you want to send on an existing = dialog then you use the refer-explicit-subscription mechanism and Require n= osub otherwise you follow the RFC 6665 behavior and if you have a GRUU as t= he target then you send outside the existing dialog. That is clear and det= erministic. > > So my proposal is to change the following text in section 4 from : > > If a user agent can be certain that no implicit subscription will be > created as a result of sending a REFER request (such as by requiring > an extension that disallows any such subscription > [I-D.ietf-sipcore-refer-explicit-subscription]), the REFER request > MAY be sent within an existing dialog. Such a REFER will be > constructed with its Contact header field populated with the dialog's > Local URI as specified in section 12 of [RFC3261]. > > To > > A user agent can be certain that no implicit subscription will be > created as a result of sending a REFER request by using the > extension in [I-D.ietf-sipcore-refer-explicit-subscription] to > require the UAS not to create an implicit subscription. Only > when using the explicit subscription mechanism to require that > a subscription not be created MAY the REFER request 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]. > > > Andrew > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, November 21, 2014 6:19 PM > To: i-d-announce@ietf.org > Cc: sipcore@ietf.org > Subject: [sipcore] I-D Action: > draft-ietf-sipcore-refer-clarifications-00.txt > > > 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-00.txt > Pages : 6 > Date : 2014-11-21 > > Abstract: > The SIP REFER method relies on the SIP-Specific Event Notification > Framework. That framework was revised by RFC6665. This document > highlights the implications of the requirement changes in RFC6665, > and updates the definition of the REFER method, RFC3515, to clarify > and disambiguate the impact of those changes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-refer-clarificatio > ns/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sipcore-refer-clarifications-00 > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ 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 --_002_39B5E4D390E9BD4890E2B31079006101127CEA71ESESSMB301erics_--