From pkyzivat@alum.mit.edu Wed Oct 5 08:28:46 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4EF21F8D56 for ; Wed, 5 Oct 2011 08:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIZPh+nWsQx4 for ; Wed, 5 Oct 2011 08:28:46 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2427B21F8D51 for ; Wed, 5 Oct 2011 08:28:45 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta13.westchester.pa.mail.comcast.net with comcast id h0Cp1h00427AodY5D3Xvl7; Wed, 05 Oct 2011 15:31:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([198.202.202.21]) by omta19.westchester.pa.mail.comcast.net with comcast id h3Xi1h01v0UCeoe3f3XnLc; Wed, 05 Oct 2011 15:31:52 +0000 Message-ID: <4E8C785D.5080003@alum.mit.edu> Date: Wed, 05 Oct 2011 11:31:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 15:28:46 -0000 [as co-chair] Christer submitted draft-ietf-sipcore-proxy-feature-reqs-01 some time ago. But there has been *no* discussion on it. There had been a *little* discussion on -00, by John, Dale, and Andrew. I think -01 addressed some of those comments, but I'm pretty sure it didn't address Andrew's. Christer would like to finalize this, but I don't think its had enough discussion to justify going to WGLC. Dale and John - woujld would you please check if your concerns have been addressed in -01? Christer - can you please respond to Andrew's comments from http://www.ietf.org/mail-archive/web/sipcore/current/msg04222.html, either explaining how they are covered or why they shouldn't be? Others, please take another look at this - it seems to have fallen off the radar screen. Thanks, Paul From christer.holmberg@ericsson.com Wed Oct 5 10:27:02 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCF121F8B8A for ; Wed, 5 Oct 2011 10:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e09yjefWx6YU for ; Wed, 5 Oct 2011 10:27:01 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 09AD521F8B89 for ; Wed, 5 Oct 2011 10:27:00 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-e6-4e8c9420e7e1 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 75.BA.20773.0249C8E4; Wed, 5 Oct 2011 19:30:08 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 5 Oct 2011 19:29:55 +0200 From: Christer Holmberg To: 'Paul Kyzivat' , SIPCORE Date: Wed, 5 Oct 2011 19:29:54 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 Thread-Index: AcyDc+ycrKW0AzYxRpixtCVRtcnoWQAD8Fiw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45FD6@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> In-Reply-To: <4E8C785D.5080003@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 17:27:02 -0000 Hi,=20 >Christer - can you please respond to Andrew's comments from http://www.iet= f.org/mail-archive/web/sipcore/current/msg04222.html, >either explaining how they are covered or why they shouldn't be? At least Andrew's comment regarding service invocation was discussed in Que= bec, and the WG agreed that it outside the scope. Andrew also had some requirement proposals, and eventhough they are not in = the draft in his suggested wording, I think that the current requirements s= hould cover them. But, I hope Andrew will indicate whether that's not the c= ase :) Regards, Christer From dworley@avaya.com Thu Oct 6 11:27:37 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E37011E808B for ; Thu, 6 Oct 2011 11:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.338 X-Spam-Level: X-Spam-Status: No, score=-103.338 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsulnpdEQ3AS for ; Thu, 6 Oct 2011 11:27:36 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 828A011E8089 for ; Thu, 6 Oct 2011 11:27:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKTyjU6HCzI1/2dsb2JhbABCDqglgQWBUwEBAQEDEihPAgEIDQEoEDIlAQEEARoapSGbMIZLYQSZNYtIUw X-IronPort-AV: E=Sophos;i="4.68,497,1312171200"; d="scan'208";a="307792606" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Oct 2011 14:30:47 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 Oct 2011 14:20:50 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.202]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 6 Oct 2011 14:30:46 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat , SIPCORE Date: Thu, 6 Oct 2011 14:29:59 -0400 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 Thread-Index: AcyDc+uwn+kjCTEgTTKUFBfpzgDb+wA4gh38 Message-ID: References: <4E8C785D.5080003@alum.mit.edu> In-Reply-To: <4E8C785D.5080003@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 18:27:37 -0000 I think we can improve the wording of REQ-9, which is currently: REQ-9: If a SIP entity that does not support the proxy feature/ capability indication mechanism receives a feature support indication, it MUST act as if it hadn't received the indication. I think the wording is poor in that it is written as a requirement on proxies that do not support our mechanism. But of course, we can't place requirements on devices that do not implement the RFC. Additionally, we want the feature indication to pass through such proxies unchanged, which is not stated. I propose: REQ-9: If a SIP entity that does not support the proxy feature/ capability indication mechanism receives a feature support indication, the baseline SIP rules MUST ensure that the entity will act as if it hadn't received the indication. Additionally, the baseline SIP rules MUST ensure that the indication will pass through the entity in the same manner and to the same degree as if the entity supported the mechanism and desired not to add to or remove from the indicated feature support. The second sentence is a little vague, but it tries to cover many cases. For entities that are proxies, it means that the indication will pass through the proxy transparently. For entities that are UAs, I haven't thought through all the possibilities, but there may be some indications we want a UAC to "absorb" and not copy into the response, and there may be some indications we want a UAC to "turn around" by copying into the response. I've written the second sentence to cover both cases; a non-supporting UAC must not defeat the feature signaling mechanism. I think we all intuitively agree on what REQ-9 is to accomplish, but this wording makes the meaning clearer. Dale From pkyzivat@alum.mit.edu Thu Oct 6 11:43:50 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573C021F8D0A for ; Thu, 6 Oct 2011 11:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNkWQII7wlZy for ; Thu, 6 Oct 2011 11:43:49 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id AFF9B21F8D09 for ; Thu, 6 Oct 2011 11:43:49 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta09.westchester.pa.mail.comcast.net with comcast id hPVM1h0031ZXKqc59Wn1Pn; Thu, 06 Oct 2011 18:47:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta21.westchester.pa.mail.comcast.net with comcast id hWn01h0010tdiYw3hWn1mt; Thu, 06 Oct 2011 18:47:01 +0000 Message-ID: <4E8DF7A6.7010705@alum.mit.edu> Date: Thu, 06 Oct 2011 14:47:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: <4E8C785D.5080003@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 18:43:50 -0000 On 10/6/11 2:29 PM, Worley, Dale R (Dale) wrote: > I think we can improve the wording of REQ-9, which is currently: > > REQ-9: If a SIP entity that does not support the proxy feature/ > capability indication mechanism receives a feature support > indication, it MUST act as if it hadn't received the indication. > > I think the wording is poor in that it is written as a requirement on > proxies that do not support our mechanism. But of course, we can't > place requirements on devices that do not implement the RFC. I'm glad you brought this up - I was about to comment as well. > Additionally, we want the feature indication to pass through such > proxies unchanged, which is not stated. Yes. "act as if it hadn't received the indication" could imply that the indication would not be passed on. > I propose: > > REQ-9: If a SIP entity that does not support the proxy feature/ > capability indication mechanism receives a feature support > indication, the baseline SIP rules MUST ensure that the entity will > act as if it hadn't received the indication. Additionally, the > baseline SIP rules MUST ensure that the indication will pass > through the entity in the same manner and to the same degree as if > the entity supported the mechanism and desired not to add to or > remove from the indicated feature support. > > The second sentence is a little vague, but it tries to cover many > cases. For entities that are proxies, it means that the indication > will pass through the proxy transparently. For entities that are UAs, > I haven't thought through all the possibilities, but there may be some > indications we want a UAC to "absorb" and not copy into the response, > and there may be some indications we want a UAC to "turn around" by > copying into the response. I've written the second sentence to cover > both cases; a non-supporting UAC must not defeat the feature signaling > mechanism. Works for me. We now have it written such that the mechanism only applies to proxies, but the language is still good. > I think we all intuitively agree on what REQ-9 is to accomplish, but this > wording makes the meaning clearer. > > Dale Thanks, Paul From dworley@avaya.com Thu Oct 6 11:44:25 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148B621F8D09 for ; Thu, 6 Oct 2011 11:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.839 X-Spam-Level: X-Spam-Status: No, score=-102.839 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eo7btgka0eOL for ; Thu, 6 Oct 2011 11:44:24 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 21A391F0C3F for ; Thu, 6 Oct 2011 11:44:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADD2jU7GmAcF/2dsb2JhbAA4Cg6oJYEFgVMBAQEBAgESKEQLAgEIDQEHIRAyJQEBBAESCAEZh1wHnUCbL4N/gkxhBJk1i0hT X-IronPort-AV: E=Sophos;i="4.68,498,1312171200"; d="scan'208";a="211674499" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 06 Oct 2011 14:47:34 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Oct 2011 14:46:35 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.202]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 6 Oct 2011 14:47:33 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat , SIPCORE Date: Thu, 6 Oct 2011 14:47:33 -0400 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 Thread-Index: AcyDc+uwn+kjCTEgTTKUFBfpzgDb+wA4ynIg Message-ID: References: <4E8C785D.5080003@alum.mit.edu> In-Reply-To: <4E8C785D.5080003@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 18:44:25 -0000 > From: Paul Kyzivat [pkyzivat@alum.mit.edu] >=20 > Dale and John - woujld would you please check if your concerns have been > addressed in -01? I don't think my concerns expressed in http://www.ietf.org/mail-archive/web/sipcore/current/msg04201.html are completely taken care of by -01, but I've discussed the remaining concern in the e-mail I just sent. Also, looking at http://www.ietf.org/mail-archive/web/sipcore/current/msg04195.html, I see the following discussion between John Elwell and Christer (edited for formatting): >Christer Holmberg writes: >> John Elwell writes: >>> 1) There is a requirement for a proxy to be able to >>> indicate support for a capability to other proxies >>> in the path of a dialog forming transaction and to >>> the two endpoints of that transaction. >> >> [JRE] I don't think this makes it clear whether the indication of >> support is intended to mean: >> a) there is a proxy somewhere on the path that supports this feature; or >> b) a particular proxy (as identified somehow) supports this feature. >>=20 >> Section 4 of the draft, although not entirely clear, seems to hint >> at b) because of the mechanisms it suggests, whereas Robert's >> text leaves it completely open. I think we need to nail down >> this aspect of the requirement better. > >The intention is b). I'll look how to clarify it. This seems to discuss the concept that the proxy-feature indication will not only allow a device in the signaling path to determine the *availability* of a particular feature in one direction or the other of the signaling path, but also in some manner identify *which* proxy provides the feature. If I am correct, this is related to Andrew's desire that the indication can tell how to address the providing device directly. As far as I can tell, draft-ietf-sipcore-proxy-feature-reqs-01 does not require this sort of identification. If this is a desired requirement, we need to add a requirement statement for it. Dale From christer.holmberg@ericsson.com Thu Oct 6 13:07:36 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4BD11E80D0 for ; Thu, 6 Oct 2011 13:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lv13TgxgUPbE for ; Thu, 6 Oct 2011 13:07:30 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5A22711E80BD for ; Thu, 6 Oct 2011 13:07:30 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-1f-4e8e0b413549 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.115.96]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 91.45.20773.14B0E8E4; Thu, 6 Oct 2011 22:10:41 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 6 Oct 2011 22:10:39 +0200 From: Christer Holmberg To: 'Paul Kyzivat' , "Worley, Dale R (Dale)" Date: Thu, 6 Oct 2011 22:10:38 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - REQ-9 Thread-Index: AcyEWFhD3UVdHHN8SjG0p1Aj+wJfNwACzDng Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45FE3@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8DF7A6.7010705@alum.mit.edu> In-Reply-To: <4E8DF7A6.7010705@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - REQ-9 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 20:07:36 -0000 =20 Hi, >> I think we can improve the wording of REQ-9, which is currently: >> >> REQ-9: If a SIP entity that does not support the proxy feature/ >> capability indication mechanism receives a feature support >> indication, it MUST act as if it hadn't received the indication. >> >> I think the wording is poor in that it is written as a requirement on=20 >> proxies that do not support our mechanism. But of course, we can't=20 >> place requirements on devices that do not implement the RFC. > >I'm glad you brought this up - I was about to comment as well. > >> Additionally, we want the feature indication to pass through such=20 >> proxies unchanged, which is not stated. > >Yes. "act as if it hadn't received the indication" could imply that the in= dication would not be passed on. > >> I propose: >> >> REQ-9: If a SIP entity that does not support the proxy feature/ >> capability indication mechanism receives a feature support >> indication, the baseline SIP rules MUST ensure that the entity will >> act as if it hadn't received the indication. Additionally, the >> baseline SIP rules MUST ensure that the indication will pass >> through the entity in the same manner and to the same degree as if >> the entity supported the mechanism and desired not to add to or >> remove from the indicated feature support. >> >> The second sentence is a little vague, but it tries to cover many=20 >> cases. For entities that are proxies, it means that the indication=20 >> will pass through the proxy transparently. For entities that are UAs,=20 >> I haven't thought through all the possibilities, but there may be some=20 >> indications we want a UAC to "absorb" and not copy into the response,=20 >> and there may be some indications we want a UAC to "turn around" by=20 >> copying into the response. I've written the second sentence to cover=20 >> both cases; a non-supporting UAC must not defeat the feature signaling=20 >> mechanism. > >Works for me. We now have it written such that the mechanism only applies = to proxies, but the language is still good. The suggested text looks fine to me too. Regards, Christer From pkyzivat@alum.mit.edu Thu Oct 6 13:15:57 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6662221F8DA3 for ; Thu, 6 Oct 2011 13:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqFOjkqQGKfq for ; Thu, 6 Oct 2011 13:15:57 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id BCAF521F8DA0 for ; Thu, 6 Oct 2011 13:15:56 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta01.westchester.pa.mail.comcast.net with comcast id hYGc1h0070bG4ec51YK9yk; Thu, 06 Oct 2011 20:19:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta03.westchester.pa.mail.comcast.net with comcast id hYK71h00h0tdiYw3PYK8GL; Thu, 06 Oct 2011 20:19:08 +0000 Message-ID: <4E8E0D3E.6060704@alum.mit.edu> Date: Thu, 06 Oct 2011 16:19:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: <4E8C785D.5080003@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 20:15:57 -0000 On 10/6/11 2:47 PM, Worley, Dale R (Dale) wrote: >> From: Paul Kyzivat [pkyzivat@alum.mit.edu] >> >> Dale and John - woujld would you please check if your concerns have been >> addressed in -01? > > I don't think my concerns expressed in > http://www.ietf.org/mail-archive/web/sipcore/current/msg04201.html are > completely taken care of by -01, but I've discussed the remaining > concern in the e-mail I just sent. > > Also, looking at > http://www.ietf.org/mail-archive/web/sipcore/current/msg04195.html, I > see the following discussion between John Elwell and Christer (edited > for formatting): > >> Christer Holmberg writes: >>> John Elwell writes: >>>> 1) There is a requirement for a proxy to be able to >>>> indicate support for a capability to other proxies >>>> in the path of a dialog forming transaction and to >>>> the two endpoints of that transaction. >>> >>> [JRE] I don't think this makes it clear whether the indication of >>> support is intended to mean: >>> a) there is a proxy somewhere on the path that supports this feature; or >>> b) a particular proxy (as identified somehow) supports this feature. >>> >>> Section 4 of the draft, although not entirely clear, seems to hint >>> at b) because of the mechanisms it suggests, whereas Robert's >>> text leaves it completely open. I think we need to nail down >>> this aspect of the requirement better. >> >> The intention is b). I'll look how to clarify it. > > This seems to discuss the concept that the proxy-feature indication > will not only allow a device in the signaling path to determine the > *availability* of a particular feature in one direction or the other > of the signaling path, but also in some manner identify *which* proxy > provides the feature. Certainly the mechanism proposed by Christer had this property. Christer - do you consider that an essential property, or just something incidental to the mechanism? If its essential, then it should be called out specifically. Thanks, Paul > If I am correct, this is related to Andrew's desire that the > indication can tell how to address the providing device directly. > > As far as I can tell, draft-ietf-sipcore-proxy-feature-reqs-01 does > not require this sort of identification. If this is a desired > requirement, we need to add a requirement statement for it. > > Dale > From christer.holmberg@ericsson.com Thu Oct 6 13:42:25 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4EF21F8C04 for ; Thu, 6 Oct 2011 13:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mznmk4GK+RsM for ; Thu, 6 Oct 2011 13:42:24 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 41F4E21F8BB3 for ; Thu, 6 Oct 2011 13:42:24 -0700 (PDT) X-AuditID: c1b4fb3d-b7b1aae000001146-41-4e8e2f8b77b7 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 4E.E1.04422.B8F2E8E4; Fri, 7 Oct 2011 00:45:31 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 6 Oct 2011 22:45:35 +0200 From: Christer Holmberg To: 'Paul Kyzivat' , "Worley, Dale R (Dale)" Date: Thu, 6 Oct 2011 22:45:34 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AcyEZTdld2iYVdTkS1y/8KIl3lbI0QAAUX6g Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu> In-Reply-To: <4E8E0D3E.6060704@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 20:42:25 -0000 Hi,=20 >> Also, looking at >> http://www.ietf.org/mail-archive/web/sipcore/current/msg04195.html, I=20 >> see the following discussion between John Elwell and Christer (edited=20 >> for formatting): >> >>> Christer Holmberg writes: >>>> John Elwell writes: >>>>> 1) There is a requirement for a proxy to be able to >>>>> indicate support for a capability to other proxies >>>>> in the path of a dialog forming transaction and to >>>>> the two endpoints of that transaction. >>>> >>>> [JRE] I don't think this makes it clear whether the indication of=20 >>>> support is intended to mean: >>>> a) there is a proxy somewhere on the path that supports this=20 >>>> feature; or >>>> b) a particular proxy (as identified somehow) supports this feature. >>>> >>>> Section 4 of the draft, although not entirely clear, seems to hint=20 >>>>> at b) because of the mechanisms it suggests, whereas Robert's text=20 >>>> leaves it completely open. I think we need to nail down this aspect=20 >>>> of the requirement better. >>> >>> The intention is b). I'll look how to clarify it. >> >> This seems to discuss the concept that the proxy-feature indication=20 >> will not only allow a device in the signaling path to determine the >> *availability* of a particular feature in one direction or the other=20 >> of the signaling path, but also in some manner identify *which* proxy=20 >> provides the feature. > >Certainly the mechanism proposed by Christer had this property. Correct. >Christer - do you consider that an essential property, or just something i= ncidental to the mechanism? If its essential, then it should be called out = specifically. It is essential. I thought it was clear in the requirements ("It MUST be po= ssible for a SIP proxy to indicate"), but I agree should be explicitly call= ed out. What about modifying REQ-1 in the following way: REQ-1: It MUST be possible for a SIP proxy to indicate, and convey to other SIP entities in the signalling path of a registration request, support of a particular feature/capability by that particular SIP proxy. Similar modificiatons would be done for REQ-2 and REQ-3. I don't think the = modification is needed for the other requirements, but please correct me if= you disagree. Regards, Christer From christer.holmberg@ericsson.com Thu Oct 6 13:55:31 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6BA121F8C1A for ; Thu, 6 Oct 2011 13:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5WgSVHrgsEo for ; Thu, 6 Oct 2011 13:55:31 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 27CBE21F8C17 for ; Thu, 6 Oct 2011 13:55:30 -0700 (PDT) X-AuditID: c1b4fb3d-b7b1aae000001146-bd-4e8e329e2e54 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.115.90]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 42.22.04422.E923E8E4; Fri, 7 Oct 2011 00:58:38 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 6 Oct 2011 22:57:57 +0200 From: Christer Holmberg To: "'Worley, Dale R (Dale)'" , Paul Kyzivat , SIPCORE Date: Thu, 6 Oct 2011 22:57:56 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - Dale's comment on REQ-4 Thread-Index: AcyDc+uwn+kjCTEgTTKUFBfpzgDb+wA4ynIgAASBkFA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45FE7@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - Dale's comment on REQ-4 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 20:55:31 -0000 Hi,=20 >> Dale and John - woujld would you please check if your concerns have=20 >> been addressed in -01? > >I don't think my concerns expressed in >http://www.ietf.org/mail-archive/web/sipcore/current/msg04201.html are com= pletely taken care of by -01, but I've discussed the remaining concern in t= he e-mail I just sent. I did propose a way forward regarding your concerns, and since you didn't c= ome back I thought you were ok with them, and I implemented them :) Note, though, that REQ-4 in -00 has became REQ-5 in -01, due to the decisio= n (based on comments from Robert) to split REQ-4 into two spearate requirem= ents. Regards, Christer= From dworley@avaya.com Thu Oct 6 14:03:24 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F08821F8CD1 for ; Thu, 6 Oct 2011 14:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.335 X-Spam-Level: X-Spam-Status: No, score=-103.335 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltX7QsYFnfEj for ; Thu, 6 Oct 2011 14:03:23 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 82C1C21F8C1E for ; Thu, 6 Oct 2011 14:03:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAsWjk6HCzI1/2dsb2JhbAA4Cg6oJYEFgVMBAQEBAgESKD8FCwIBCA0IIQULMiUBAQQBDQUIGodcnT+bHoN/gkxhBJk1i0hT X-IronPort-AV: E=Sophos;i="4.68,498,1312171200"; d="scan'208";a="307818901" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Oct 2011 17:06:31 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 Oct 2011 16:56:33 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.202]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Thu, 6 Oct 2011 17:06:31 -0400 From: "Worley, Dale R (Dale)" To: Christer Holmberg , 'Paul Kyzivat' Date: Thu, 6 Oct 2011 17:06:31 -0400 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AcyEZTdld2iYVdTkS1y/8KIl3lbI0QAAUX6gAAEepoU= Message-ID: References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 21:03:24 -0000 > From: Christer Holmberg [christer.holmberg@ericsson.com] >=20 > >Christer - do you consider that an essential property, or just > >something incidental to the mechanism? If its essential, then it > >should be called out specifically. >=20 > It is essential. I thought it was clear in the requirements ("It MUST > be possible for a SIP proxy to indicate"), but I agree should be > explicitly called out. The text is "It MUST be possible for a SIP proxy to indicate ... support of ...". The difficulty lies in the implied subject of the action "support". If one said "... to indicate that it supports ...", it is clear that the indication includes the identify of the proxy that does the supporting. If one said "... to indicate that a feature is supported", it would suggest that the indication did not identify the proxy that does the supporting. But in any case, since this is an important requirement we should state it directly. > What about modifying REQ-1 in the following way: >=20 > REQ-1: It MUST be possible for a SIP proxy to indicate, and conve= y to > other SIP entities in the signalling path of a registration reque= st, > support of a particular feature/capability by that particula= r > SIP proxy. >=20 > Similar modificiatons would be done for REQ-2 and REQ-3. I don't think > the modification is needed for the other requirements, but please > correct me if you disagree. I'm sure that you want to make the same modification to REQ-2, as this is a case that is disjoint from the case of REQ-1, the mechanism in dialog-forming requests may differ from that in REGISTERs. I don't think the modification is needed in REQ-3, as that is an additional requirement on the cases of REQ-1 and REQ-2. Dale From christer.holmberg@ericsson.com Fri Oct 7 02:49:47 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496F121F8B72 for ; Fri, 7 Oct 2011 02:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vm0OwpC-YlPh for ; Fri, 7 Oct 2011 02:49:46 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7C40621F8B66 for ; Fri, 7 Oct 2011 02:49:46 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-4b-4e8ecbfae83e Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DD.E3.13753.AFBCE8E4; Fri, 7 Oct 2011 11:52:58 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Fri, 7 Oct 2011 11:52:58 +0200 From: Christer Holmberg To: "Worley, Dale R (Dale)" , 'Paul Kyzivat' Date: Fri, 7 Oct 2011 11:52:56 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AcyEZTdld2iYVdTkS1y/8KIl3lbI0QAAUX6gAAEepoUAGrY5EA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522340DC994@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 09:49:47 -0000 Hi,=20 >>> Christer - do you consider that an essential property, or just=20 >>> something incidental to the mechanism? If its essential, then it=20 >>> should be called out specifically. >>=20 >> It is essential. I thought it was clear in the requirements=20 >> ("It MUST be possible for a SIP proxy to indicate"), but I agree should = be=20 >> explicitly called out. >=20 > The text is "It MUST be possible for a SIP proxy to indicate ... > support of ...". The difficulty lies in the implied subject=20 > of the action "support". If one said "... to indicate that=20 > it supports ...", it is clear that the indication includes=20 > the identify of the proxy that does the supporting. If one=20 > said "... to indicate that a feature is supported", it would=20 > suggest that the indication did not identify the proxy that=20 > does the supporting. >=20 > But in any case, since this is an important requirement we=20 > should state it directly. >=20 >> What about modifying REQ-1 in the following way: >>=20 >> REQ-1: It MUST be possible for a SIP proxy to=20 >> indicate, and convey to other SIP entities in the signalling pat= h of a=20 >> registration request, support of a particular feature/capability= by=20 >> that particular SIP proxy. >>=20 >> Similar modificiatons would be done for REQ-2 and REQ-3. I=20 >> don't think the modification is needed for the other requirements, but p= lease=20 >> correct me if you disagree. >=20 > I'm sure that you want to make the same modification to=20 > REQ-2, as this is a case that is disjoint from the case of=20 > REQ-1, the mechanism in dialog-forming requests may differ=20 > from that in REGISTERs. I don't think the modification is=20 > needed in REQ-3, as that is an additional requirement on the=20 > cases of REQ-1 and REQ-2. Ok. So, the suggestion is to modify REQ-1 and REQ-2, by appending the new t= ext to the end. Regards, Christer From dworley@avaya.com Fri Oct 7 10:52:20 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8C021F854E for ; Fri, 7 Oct 2011 10:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.335 X-Spam-Level: X-Spam-Status: No, score=-103.335 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwIFY9aBKIJU for ; Fri, 7 Oct 2011 10:52:19 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6F46E21F8546 for ; Fri, 7 Oct 2011 10:52:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHE8j07GmAcF/2dsb2JhbAA6Cqg+gQWBUwEBAQECARIoPwULAgEIDQghBQsyJQEBBA4FCBqHXJxtm06EBIJMYQSZNowd X-IronPort-AV: E=Sophos;i="4.68,503,1312171200"; d="scan'208";a="271704280" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 07 Oct 2011 13:55:30 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Oct 2011 13:54:27 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Fri, 7 Oct 2011 13:55:29 -0400 From: "Worley, Dale R (Dale)" To: Christer Holmberg Date: Fri, 7 Oct 2011 13:55:29 -0400 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AcyEZTdld2iYVdTkS1y/8KIl3lbI0QAAUX6gACzASXU= Message-ID: References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 17:52:20 -0000 > From: Christer Holmberg [christer.holmberg@ericsson.com] >=20 > >> This seems to discuss the concept that the proxy-feature indication > >> will not only allow a device in the signaling path to determine the > >> *availability* of a particular feature in one direction or the other > >> of the signaling path, but also in some manner identify *which* proxy > >> provides the feature. > > > >Christer - do you consider that an essential property, or just > >something incidental to the mechanism? If its essential, then it > >should be called out specifically. >=20 > It is essential. I thought it was clear in the requirements ("It MUST > be possible for a SIP proxy to indicate"), but I agree should be > explicitly called out. I've just re-read the use cases (sections 1.1 and following) and none of them call out the need for this identification facility. Cases 1.1, 1.2.1, and 1.2.2 only require "... determine whether ...". Case 1.3 is not clear; the specific requirements of that use case are not clear. I believe it would be very helpful to update one or more of the use cases to show clearly the need for identifying which proxy provides a feature, or to add a new use case that does so. Also, use case 1.3 should be edited to clarify the specific requirements it places on the mechanism. Also, I think the use cases (sections 1.1 and following) should be separated from the Introduction and placed into their own section. Dale From pkyzivat@alum.mit.edu Fri Oct 7 11:19:08 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23CF021F8B21 for ; Fri, 7 Oct 2011 11:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSETLR3vaeUI for ; Fri, 7 Oct 2011 11:19:07 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 4993321F8B26 for ; Fri, 7 Oct 2011 11:19:07 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta13.westchester.pa.mail.comcast.net with comcast id ht9H1h0071ZXKqc5DuNN6N; Fri, 07 Oct 2011 18:22:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta21.westchester.pa.mail.comcast.net with comcast id huNM1h00R0tdiYw3huNMS3; Fri, 07 Oct 2011 18:22:21 +0000 Message-ID: <4E8F435B.3030801@alum.mit.edu> Date: Fri, 07 Oct 2011 14:22:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: sipcore@ietf.org References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 18:19:08 -0000 Inline On 10/7/11 1:55 PM, Worley, Dale R (Dale) wrote: >> From: Christer Holmberg [christer.holmberg@ericsson.com] >> >>>> This seems to discuss the concept that the proxy-feature indication >>>> will not only allow a device in the signaling path to determine the >>>> *availability* of a particular feature in one direction or the other >>>> of the signaling path, but also in some manner identify *which* proxy >>>> provides the feature. >>> >>> Christer - do you consider that an essential property, or just >>> something incidental to the mechanism? If its essential, then it >>> should be called out specifically. >> >> It is essential. I thought it was clear in the requirements ("It MUST >> be possible for a SIP proxy to indicate"), but I agree should be >> explicitly called out. > > I've just re-read the use cases (sections 1.1 and following) and none > of them call out the need for this identification facility. Cases > 1.1, 1.2.1, and 1.2.2 only require "... determine whether ...". Case > 1.3 is not clear; the specific requirements of that use case are not > clear. > > I believe it would be very helpful to update one or more of the use > cases to show clearly the need for identifying which proxy provides a > feature, or to add a new use case that does so. I'm trying to sort out what the concerns are about this. One might be for some server on the path to determine whether this functionality is present upstream from it, or downstream of it. Having the feature associated with a particular element in the path is one way to accomplish that, maybe the easiest way, but not the only way. Another is that there is *really* a need to know *which* server has the functionality. I can only think of a couple of reasons why: - there is need to send a request to it (which relates to Andrew's earlier proposals) - there is a need to validate it based on other properties of its entry in the route We should sort out which of these are the real requirements. Thanks, Paul > Also, use case 1.3 should be edited to clarify the specific > requirements it places on the mechanism. > > Also, I think the use cases (sections 1.1 and following) should be > separated from the Introduction and placed into their own section. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From ivo.sedlacek@ericsson.com Tue Oct 11 02:58:57 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B10E21F8D30 for ; Tue, 11 Oct 2011 02:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYzrMbJU+WhG for ; Tue, 11 Oct 2011 02:58:56 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B6DD821F8CF0 for ; Tue, 11 Oct 2011 02:58:55 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-43-4e94135ee34a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FE.9D.20773.E53149E4; Tue, 11 Oct 2011 11:58:54 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([153.88.115.178]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 11 Oct 2011 11:58:54 +0200 From: Ivo Sedlacek To: "sipcore@ietf.org" Date: Tue, 11 Oct 2011 11:58:53 +0200 Thread-Topic: RFC5628 - notifier setting up "cseq" attribute Thread-Index: AcyH9Hc+Zadzf/2BT0aPWrjiLFykCQAAfbAg Message-ID: <3A324A65CCACC64289667DFAC0B88E12183EF5E46F@ESESSCMS0360.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3A324A65CCACC64289667DFAC0B88E12183EF5E46FESESSCMS0360e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] RFC5628 - notifier setting up "cseq" attribute X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 09:58:57 -0000 --_000_3A324A65CCACC64289667DFAC0B88E12183EF5E46FESESSCMS0360e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, RFC5628 states in section 5: ------- If the notifier includes the element, it MUST populate the element with the most recently assigned temporary GRUU that is associated with the instance ID and AOR of the registered contact. >>>It MUST also populate ___the element___ with a "cseq" attribute corresponding to the first (oldest) currently active temporary GRUU that is associated with the instance ID and AOR of the registered contact. The value of the "cseq" attribute is set to the value of the CSeq header field of the REGISTER request that caused that first temporary GRUU to be assigned. <<< ------- My question relates to the marked sentences above (between >>> and <<<). Does ___the element___ in the 1st marked sentence refer to: A) the element (defined in RFC5628); or B) the element (defined in RFC3680)? If A) is the answer, then the marked sentences seem to be incorrect as "cse= q" attribute is not defined in the element in the XML schema in= RFC5628 section 9. Most likely "cseq" attribute should be replaced with "f= irst-cseq" attribute. If B) is the answer, then RFC5628 seems to contradict RFC3680 since: - RFC3680 states: ---- The optional "callid" attribute contains the current Call-ID carried in the REGISTER that was last used to update this contact, and the opti= onal "cseq" attribute contains the last CSeq value present in a REGIS= TER request that updated this contact value. --- - the 2nd marked sentence states: ---- The value of the "cseq" attribute is set to the value of the CSeq header field of the REGISTER request that caused that f= irst temporary GRUU to be assigned. ---- Thanks for clarification. Kind regards Ivo Sedlacek Ericsson Technology and Portfolio Management, Terminal Standardization Sweden Office: +46 10 711 9382 Fax: +46 10 713 5929 ivo.sedlacek@ericsson.com www.ericsson.com [http://www.ericsson.com/shared/images/Email.gif] This communication is confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer --_000_3A324A65CCACC64289667DFAC0B88E12183EF5E46FESESSCMS0360e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
RFC5628 states in section 5:<= /DIV>
-------
   If the notifier includes the= =20 <temp-gruu> element, it MUST populate
   the element wit= h the=20 most recently assigned temporary GRUU that is
   associated wi= th=20 the instance ID and AOR of the registered contact.
   >>>It MUST also populate ___the element___ with a=20 "cseq" attribute
   corresponding to the first (oldest) curren= tly=20 active temporary GRUU
   that is associated with the instance = ID=20 and AOR of the registered
   contact. Th= e=20 value of the "cseq" attribute is set to the value of
   the CS= eq=20 header field of the REGISTER request that caused that first
  = =20 temporary GRUU to be assigned. <<<
-------
 
My questi= on relates=20 to the marked sentences above (between >>> and=20 <<<).
 
Does ___the=20 element___ in the 1st marked= =20 sentence refer to:
A) the=20 <temp-gruu> element (defined in RFC5628); or
B) the=20 <contact> element (defined in RFC3680)?
 
 
 
If A) is = the answer,=20 then the marked sentences seem to be incorrect as "cseq" attribute is = not=20 defined in the <temp-gruu> element in the XML schema in RFC5628 secti= on 9.=20 Most likely "cseq" attribute should be replaced with "first-cseq"=20 attribute.
 
If B) is = the answer,=20 then RFC5628 seems to contradict RFC3680 since:
- RFC3680= =20 states:
       =20 ----
        The=20 optional
        =   =20 "callid" attribute contains the current Call-ID carried in the
        =   =20 REGISTER that was last used to update this contact, and the optional
        =   =20 "cseq" attribute contains the last CSeq value present in a=20 REGISTER
        =   =20 request that updated this contact value.
       =20 ---
- the&nbs= p;2nd=20 marked sentence states:
       =20 ----
        The v= alue of=20 the "cseq" attribute is set to the value of
        =   =20 the CSeq header field of the REGISTER request that caused that first
=         =   =20 temporary GRUU to be assigned.
       =20 ----
 
Thanks fo= r=20 clarification.
 
Kind=20 regards
 

Ivo Sedlacek= =20


Ericsson
T= echnology=20 and Portfolio Management, Terminal Standardization
Sweden
Office: +4= 6 10=20 711 9382
Fax: +46 10 713=20 5929
ivo.sedlacek@ericsson.com
www.ericsson.com


3D"Ericsson



This=20 communication is confidential. We only send and receive email on the basis = of=20 the term set out at www.ericsson.com/email_di= sclaimer=20

 
--_000_3A324A65CCACC64289667DFAC0B88E12183EF5E46FESESSCMS0360e_-- From christer.holmberg@ericsson.com Tue Oct 11 03:22:56 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E3D21F8CCA for ; Tue, 11 Oct 2011 03:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNBmUT0V1GxM for ; Tue, 11 Oct 2011 03:22:55 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9B87421F8C08 for ; Tue, 11 Oct 2011 03:22:55 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-25-4e9418fe5f19 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A7.9B.13753.EF8149E4; Tue, 11 Oct 2011 12:22:54 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 11 Oct 2011 12:22:54 +0200 From: Christer Holmberg To: SIPCORE Date: Tue, 11 Oct 2011 12:22:51 +0200 Thread-Topic: Accept in 18x Thread-Index: AcyH/7tN17MfetCrREuG2Zoo0oAJyw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522341206CF@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A058522341206CFESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Accept in 18x X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 10:22:56 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A058522341206CFESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, At the ongoing 3GPP meeting, the question has came up why RFC 3261 does not= allow the Accept header field in 18x provisional responses (for INVITEs, 3= 261 only allows it for 2xx and 415). Is there a technical reason for not allowing it in 18x, or is it just becau= se nobody seemed a need for it at the time? Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A058522341206CFESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
At the ongoing 3GPP meeting, the question has came up= why RFC 3261 does not allow the Accept header field in 18x provisional res= ponses (for INVITEs, 3261 only allows it for 2xx and 415).
 
Is there a technical reason for not allowing it in 18= x, or is it just because nobody seemed a need for it at the time?
 
Regards,
 
Christer
 
 --_000_7F2072F1E0DE894DA4B517B93C6A058522341206CFESESSCMS0356e_-- From dworley@avaya.com Tue Oct 11 07:44:50 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC7F21F8DD2 for ; Tue, 11 Oct 2011 07:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-Yz0egtWFUv for ; Tue, 11 Oct 2011 07:44:50 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFD321F8DD0 for ; Tue, 11 Oct 2011 07:44:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHxVlE6HCzI1/2dsb2JhbABDqCiBBYFTAQEBAQIBEihECwIBCA0IIRAyJQEBBAESCBqHXJ1Fm3KGa2EEmTyMJw X-IronPort-AV: E=Sophos;i="4.68,523,1312171200"; d="scan'208";a="308481530" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Oct 2011 10:44:49 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Oct 2011 10:34:41 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.202]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 11 Oct 2011 10:44:48 -0400 From: "Worley, Dale R (Dale)" To: Christer Holmberg , SIPCORE Date: Tue, 11 Oct 2011 10:41:41 -0400 Thread-Topic: Accept in 18x Thread-Index: AcyH/7tN17MfetCrREuG2Zoo0oAJywAJCgHx Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A058522341206CF@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341206CF@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Accept in 18x X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 14:44:50 -0000 > From: Christer Holmberg [christer.holmberg@ericsson.com] >=20 > At the ongoing 3GPP meeting, the question has came up why RFC 3261 > does not allow the Accept header field in 18x provisional responses > (for INVITEs, 3261 only allows it for 2xx and 415). >=20 > Is there a technical reason for not allowing it in 18x, or is it just > because nobody seemed a need for it at the time? My guess is that Accept in 1xx was not seen as useful because (1) 1xx isn't reliable, and (2) the UAC won't send any further requests until 2xx is sent by the UAS (and the 2xx can carry Accept). Dale From BPenfield@acmepacket.com Tue Oct 11 08:55:17 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D380A21F8EC9 for ; Tue, 11 Oct 2011 08:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlkTgAKSnn-y for ; Tue, 11 Oct 2011 08:55:17 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 457A621F8EC4 for ; Tue, 11 Oct 2011 08:55:17 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 11 Oct 2011 11:55:13 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 11 Oct 2011 11:55:13 -0400 From: Bob Penfield To: "Worley, Dale R (Dale)" , Christer Holmberg , SIPCORE Thread-Topic: Accept in 18x Thread-Index: AcyH/7tN17MfetCrREuG2Zoo0oAJywAJCgHxAAGlZFA= Date: Tue, 11 Oct 2011 15:55:12 +0000 Message-ID: <2BC1CD824C2D4F47A6F6EC2705F4F4D803DD4E@Mail1.acmepacket.com> References: <7F2072F1E0DE894DA4B517B93C6A058522341206CF@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: Re: [sipcore] Accept in 18x X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 15:55:18 -0000 A UAC is allowed to send a BYE on an early dialog created by an unreliable = 1xx. I think it might just be an oversight. cheers, (-:bob -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Worley, Dale R (Dale) Sent: Tuesday, October 11, 2011 10:42 AM To: Christer Holmberg; SIPCORE Subject: Re: [sipcore] Accept in 18x > From: Christer Holmberg [christer.holmberg@ericsson.com] >=20 > At the ongoing 3GPP meeting, the question has came up why RFC 3261 > does not allow the Accept header field in 18x provisional responses > (for INVITEs, 3261 only allows it for 2xx and 415). >=20 > Is there a technical reason for not allowing it in 18x, or is it just > because nobody seemed a need for it at the time? My guess is that Accept in 1xx was not seen as useful because (1) 1xx isn't reliable, and (2) the UAC won't send any further requests until 2xx is sent by the UAS (and the 2xx can carry Accept). Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From kpfleming@digium.com Tue Oct 11 08:57:57 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866B821F8ED4 for ; Tue, 11 Oct 2011 08:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.053 X-Spam-Level: X-Spam-Status: No, score=-105.053 tagged_above=-999 required=5 tests=[AWL=1.546, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGcN6ZqMV9Cz for ; Tue, 11 Oct 2011 08:57:57 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0041121F8ED2 for ; Tue, 11 Oct 2011 08:57:56 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1RDeiJ-0007F0-SE for sipcore@ietf.org; Tue, 11 Oct 2011 10:57:55 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id D1A2CD82A3 for ; Tue, 11 Oct 2011 10:57:55 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fGnRKCNtYXW for ; Tue, 11 Oct 2011 10:57:55 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 39488D8024 for ; Tue, 11 Oct 2011 10:57:55 -0500 (CDT) Message-ID: <4E946782.5050508@digium.com> Date: Tue, 11 Oct 2011 10:57:54 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: sipcore@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A058522341206CF@ESESSCMS0356.eemea.ericsson.se> <2BC1CD824C2D4F47A6F6EC2705F4F4D803DD4E@Mail1.acmepacket.com> In-Reply-To: <2BC1CD824C2D4F47A6F6EC2705F4F4D803DD4E@Mail1.acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Accept in 18x X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 15:57:57 -0000 On 10/11/2011 10:55 AM, Bob Penfield wrote: > A UAC is allowed to send a BYE on an early dialog created by an unreliable 1xx. I think it might just be an oversight. Also UPDATE requests are allowed, IIRC. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From christer.holmberg@ericsson.com Tue Oct 11 09:59:41 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC8021F8E4D for ; Tue, 11 Oct 2011 09:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yKnwKn4zqF1 for ; Tue, 11 Oct 2011 09:59:40 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C96E821F8DF0 for ; Tue, 11 Oct 2011 09:59:37 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-09-4e9475f8e066 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DF.71.20773.8F5749E4; Tue, 11 Oct 2011 18:59:36 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 11 Oct 2011 18:59:36 +0200 From: Christer Holmberg To: "Kevin P. Fleming" , "sipcore@ietf.org" Date: Tue, 11 Oct 2011 18:59:33 +0200 Thread-Topic: [sipcore] Accept in 18x Thread-Index: AcyILo0Gxf/pOlYnQfOZqRNMl5wdVgACClSQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852234120AA4@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058522341206CF@ESESSCMS0356.eemea.ericsson.se> <2BC1CD824C2D4F47A6F6EC2705F4F4D803DD4E@Mail1.acmepacket.com> <4E946782.5050508@digium.com> In-Reply-To: <4E946782.5050508@digium.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Accept in 18x X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 16:59:41 -0000 Hi, Note that the Accept header field is used to indciate the supported message= body MIME types, not the supported SIP methods. So, if there are no technical reasons, and 3GPP would like to specify the u= sage of Accept in a provisional response, would an errata to 3261 be needed= (in order to be alligned with 3261)? However,=20 Regards, Christer=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Kevin P. Fleming > Sent: 11. lokakuuta 2011 18:58 > To: sipcore@ietf.org > Subject: Re: [sipcore] Accept in 18x >=20 > On 10/11/2011 10:55 AM, Bob Penfield wrote: > > A UAC is allowed to send a BYE on an early dialog created=20 > by an unreliable 1xx. I think it might just be an oversight. >=20 > Also UPDATE requests are allowed, IIRC. >=20 > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > Jabber: kfleming@digium.com | SIP: kpfleming@digium.com |=20 > Skype: kpfleming > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us=20 > out at www.digium.com & www.asterisk.org=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From dworley@avaya.com Tue Oct 11 13:17:35 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8F221F8B19 for ; Tue, 11 Oct 2011 13:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeMwg5st+Ilp for ; Tue, 11 Oct 2011 13:17:34 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1C48D21F8B16 for ; Tue, 11 Oct 2011 13:17:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EADajlE6HCzI1/2dsb2JhbABDqCyBBYFTAQEBAQIBEihECwIBCA0IIRAyJQEBBAESCBqHXJxAm2eGa2EEmTyMJw X-IronPort-AV: E=Sophos;i="4.68,525,1312171200"; d="scan'208";a="212387335" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 11 Oct 2011 16:17:33 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Oct 2011 16:07:25 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Tue, 11 Oct 2011 16:17:32 -0400 From: "Worley, Dale R (Dale)" To: Christer Holmberg , "Kevin P. Fleming" , "sipcore@ietf.org" Date: Tue, 11 Oct 2011 16:14:04 -0400 Thread-Topic: [sipcore] Accept in 18x Thread-Index: AcyILo0Gxf/pOlYnQfOZqRNMl5wdVgACClSQAAbnDgk= Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A058522341206CF@ESESSCMS0356.eemea.ericsson.se> <2BC1CD824C2D4F47A6F6EC2705F4F4D803DD4E@Mail1.acmepacket.com> <4E946782.5050508@digium.com>, <7F2072F1E0DE894DA4B517B93C6A05852234120AA4@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852234120AA4@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Accept in 18x X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 20:17:35 -0000 > From: Christer Holmberg [christer.holmberg@ericsson.com] >=20 > So, if there are no technical reasons, and 3GPP would like to specify > the usage of Accept in a provisional response, would an errata to 3261 > be needed (in order to be alligned with 3261)? It looks like Accept was not specified for 1xx because there was no practical use for it at the time 3261 was written. As far as I can tell, the only place where 3261 says that Accept isn't allowed in 1xx responses is in the giant table of "which headers are allowed in which messages". But I believe we've agreed to discontinue the normative status of that table, which would mean that wouldn't need to amend 3261 to maintain formal compliance. In practice, no UA should malfunction due to the unexpected presence of Accept in a 1xx response. So it seems to me that 3GPP can go ahead with using Accept in 1xx without worrying about updating 3261. Dale From iesg-secretary@ietf.org Tue Oct 11 14:31:40 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD0421F8DFE; Tue, 11 Oct 2011 14:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+VTG9YAJMy9; Tue, 11 Oct 2011 14:31:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DA721F8E01; Tue, 11 Oct 2011 14:31:40 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111011213140.17631.77786.idtracker@ietfa.amsl.com> Date: Tue, 11 Oct 2011 14:31:40 -0700 Cc: sipcore mailing list , sipcore chair , RFC Editor Subject: [sipcore] Protocol Action: 'Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control' to Proposed Standard (draft-ietf-sipcore-event-rate-control-09.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 21:31:41 -0000 The IESG has approved the following document: - 'Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control' (draft-ietf-sipcore-event-rate-control-09.txt) as a Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sipcore-event-rate-control/ Technical Summary This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. Working Group Summary Many working group members tended to express mild confusion or bewilderment upon first encountering the behavior described in section 5 (minimum notification rate). It is worth noting that this is the exact behavior that is required by the GEOPRIV work. This confusion is typically ameliorated when they are presented with use cases similar to those being considered by GEOPRIV. Document Quality Martin Thompson provided significant input to the document on behalf of the GEOPRIV working group, who is an immediate customer for this document. Brian Rosen identified the suitability of this mechanism in satisfying GEOPRIV's requirements, and made the initial proposal for the minimum rate mechanism for that purpose. From keith.drage@alcatel-lucent.com Tue Oct 11 21:43:13 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501D721F8BB2 for ; Tue, 11 Oct 2011 21:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+zOCdBCGvCr for ; Tue, 11 Oct 2011 21:43:12 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 92E7421F8BAB for ; Tue, 11 Oct 2011 21:43:11 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p9C4gwH3013960 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 12 Oct 2011 06:43:03 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 12 Oct 2011 06:43:02 +0200 From: "DRAGE, Keith (Keith)" To: "Worley, Dale R (Dale)" , Christer Holmberg , "Kevin P. Fleming" , "sipcore@ietf.org" Date: Wed, 12 Oct 2011 06:40:49 +0200 Thread-Topic: [sipcore] Accept in 18x Thread-Index: AcyILo0Gxf/pOlYnQfOZqRNMl5wdVgACClSQAAbnDgkADyHuIA== Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A058522341206CF@ESESSCMS0356.eemea.ericsson.se> <2BC1CD824C2D4F47A6F6EC2705F4F4D803DD4E@Mail1.acmepacket.com> <4E946782.5050508@digium.com>, <7F2072F1E0DE894DA4B517B93C6A05852234120AA4@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [sipcore] Accept in 18x X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 04:43:13 -0000 Its fine saying that, but that means you have to work out what the semantic= s are when it is included in a 18x. A 18x only creates an early dialog. So does sending Accept in a 18x only ap= ply for an early dialog, or does it apply for the remainder of the full dia= log.=20 Also note there are other headers specified the same way. If this understan= ding applies to Accept, does it also apply to other headers. Keith > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Worley, Dale R (Dale) > Sent: 11 October 2011 21:14 > To: Christer Holmberg; Kevin P. Fleming; sipcore@ietf.org > Subject: Re: [sipcore] Accept in 18x >=20 > > From: Christer Holmberg [christer.holmberg@ericsson.com] > > > > So, if there are no technical reasons, and 3GPP would like to specify > > the usage of Accept in a provisional response, would an errata to 3261 > > be needed (in order to be alligned with 3261)? >=20 > It looks like Accept was not specified for 1xx because there was no > practical use for it at the time 3261 was written. >=20 > As far as I can tell, the only place where 3261 says that Accept isn't > allowed in 1xx responses is in the giant table of "which headers are > allowed in which messages". But I believe we've agreed to discontinue > the normative status of that table, which would mean that wouldn't > need to amend 3261 to maintain formal compliance. >=20 > In practice, no UA should malfunction due to the unexpected presence > of Accept in a 1xx response. >=20 > So it seems to me that 3GPP can go ahead with using Accept in 1xx > without worrying about updating 3261. >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From HKaplan@acmepacket.com Thu Oct 13 12:26:52 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B1921F8AEA for ; Thu, 13 Oct 2011 12:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2N71n1dCBUL for ; Thu, 13 Oct 2011 12:26:52 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAB821F8A56 for ; Thu, 13 Oct 2011 12:26:51 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 13 Oct 2011 15:26:50 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 13 Oct 2011 15:26:50 -0400 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMid4N7VYX33eXSky4RVe9eKSGOw== Date: Thu, 13 Oct 2011 19:26:49 +0000 Message-ID: <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> In-Reply-To: <4E8F435B.3030801@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: <92F34A578B9D654A81B1B5D359B40978@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 19:26:52 -0000 On Oct 7, 2011, at 2:22 PM, Paul Kyzivat wrote: > I'm trying to sort out what the concerns are about this. >=20 > One might be for some server on the path to determine whether this functi= onality is present upstream from it, or downstream of it. Having the featur= e associated with a particular element in the path is one way to accomplish= that, maybe the easiest way, but not the only way. >=20 > Another is that there is *really* a need to know *which* server has the f= unctionality. I can only think of a couple of reasons why: > - there is need to send a request to it > (which relates to Andrew's earlier proposals) > - there is a need to validate it based on other properties > of its entry in the route >=20 > We should sort out which of these are the real requirements. The problem with trying to learn which particular server supports feature X= is that the identification of a particular server often doesn't get convey= ed beyond the local SIP domain. SBCs, for example, have a popular feature = called "Topology Hiding" which involves removing things like Record-Routes,= Via, etc. Beyond the security/privacy reasons, it's also one of the thing= s that often keep SIP messages small enough to use UDP without fragmentatio= n. Because of that, even though SBCs could be made to pass on the feature capa= bility information of other servers, I seriously doubt they'd do so by keep= ing the Record-Routes intact nor even by encrypting the Record-Route URIs. = They'd probably just copy the feature info into the SBC's own contact/rec= ord-route/path/whatever. That would mean (1) you couldn't know which parti= cular server supported that feature, and (2) the feature would only apply f= or that specific dialog. -hadriel From pkyzivat@alum.mit.edu Thu Oct 13 12:28:54 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D729B21F8B11 for ; Thu, 13 Oct 2011 12:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0L5MvLov+DUr for ; Thu, 13 Oct 2011 12:28:53 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 905F221F8B32 for ; Thu, 13 Oct 2011 12:28:53 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta06.westchester.pa.mail.comcast.net with comcast id kKM91h00227AodY56KUuyU; Thu, 13 Oct 2011 19:28:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta19.westchester.pa.mail.comcast.net with comcast id kKUt1h00r0tdiYw3fKUtao; Thu, 13 Oct 2011 19:28:54 +0000 Message-ID: <4E973BF5.8010107@alum.mit.edu> Date: Thu, 13 Oct 2011 15:28:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <3A324A65CCACC64289667DFAC0B88E12183EF5E46F@ESESSCMS0360.eemea.ericsson.se> In-Reply-To: <3A324A65CCACC64289667DFAC0B88E12183EF5E46F@ESESSCMS0360.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] RFC5628 - notifier setting up "cseq" attribute X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 19:28:54 -0000 Ivo, This does seem to be a bug in 5628. Thanks for identifying it. On 10/11/11 5:58 AM, Ivo Sedlacek wrote: > Hello, > RFC5628 states in section 5: > ------- > If the notifier includes the element, it MUST populate > the element with the most recently assigned temporary GRUU that is > associated with the instance ID and AOR of the registered contact. > *>>>It MUST also populate ___the element___ with a "cseq" attribute > corresponding to the first (oldest) currently active temporary GRUU > that is associated with the instance ID and AOR of the registered > contact.* *The value of the "cseq" attribute is set to the value of > the CSeq header field of the REGISTER request that caused that first > temporary GRUU to be assigned. *<<< > ------- > My question relates to the marked sentences above (between >>> and <<<). > Does ___the element___ in the 1st marked sentence refer to: > A) the element (defined in RFC5628); or > B) the element (defined in RFC3680)? It means (A). > If A) is the answer, then the marked sentences seem to be incorrect as > "cseq" attribute is not defined in the element in the XML > schema in RFC5628 section 9. Most likely "cseq" attribute should be > replaced with "first-cseq" attribute. Yes, I agree. > If B) is the answer, then RFC5628 seems to contradict RFC3680 since: > - RFC3680 states: > ---- > The optional > "callid" attribute contains the current Call-ID carried in the > REGISTER that was last used to update this contact, and the optional > "cseq" attribute contains the _last CSeq value present in a REGISTER > __request that updated this contact value_. > --- > - the 2nd marked sentence states: > ---- > The value of the "cseq" attribute is set to the value of > the _CSeq header field of the REGISTER request that caused that first > temporary GRUU to be assigned_. > ---- Again, this ought to be "first-cseq". Thanks, Paul > Thanks for clarification. > Kind regards > > *Ivo Sedlacek ** > * > > > Ericsson > Technology and Portfolio Management, Terminal Standardization > Sweden > Office: +46 10 711 9382 > Fax: +46 10 713 5929 > ivo.sedlacek@ericsson.com > www.ericsson.com > > > Ericsson logo > > > > This communication is confidential. We only send and receive email on > the basis of the term set out at www.ericsson.com/email_disclaimer > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Thu Oct 13 12:45:57 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F34421F84B8 for ; Thu, 13 Oct 2011 12:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCND326zQAmV for ; Thu, 13 Oct 2011 12:45:55 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCD921F84B5 for ; Thu, 13 Oct 2011 12:45:55 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta12.westchester.pa.mail.comcast.net with comcast id kJJj1h00127AodY5CKlvGt; Thu, 13 Oct 2011 19:45:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta19.westchester.pa.mail.comcast.net with comcast id kKlv1h00U0tdiYw3fKlvx7; Thu, 13 Oct 2011 19:45:55 +0000 Message-ID: <4E973FF2.3040302@alum.mit.edu> Date: Thu, 13 Oct 2011 15:45:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <3A324A65CCACC64289667DFAC0B88E12183EF5E46F@ESESSCMS0360.eemea.ericsson.se> <4E973BF5.8010107@alum.mit.edu> In-Reply-To: <4E973BF5.8010107@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] RFC5628 - notifier setting up "cseq" attribute X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 19:45:57 -0000 Ivo - I filed an errata on this. Thanks again, Paul On 10/13/11 3:28 PM, Paul Kyzivat wrote: > Ivo, > > This does seem to be a bug in 5628. Thanks for identifying it. > > On 10/11/11 5:58 AM, Ivo Sedlacek wrote: >> Hello, >> RFC5628 states in section 5: >> ------- >> If the notifier includes the element, it MUST populate >> the element with the most recently assigned temporary GRUU that is >> associated with the instance ID and AOR of the registered contact. >> *>>>It MUST also populate ___the element___ with a "cseq" attribute >> corresponding to the first (oldest) currently active temporary GRUU >> that is associated with the instance ID and AOR of the registered >> contact.* *The value of the "cseq" attribute is set to the value of >> the CSeq header field of the REGISTER request that caused that first >> temporary GRUU to be assigned. *<<< >> ------- >> My question relates to the marked sentences above (between >>> and <<<). >> Does ___the element___ in the 1st marked sentence refer to: >> A) the element (defined in RFC5628); or >> B) the element (defined in RFC3680)? > > It means (A). > >> If A) is the answer, then the marked sentences seem to be incorrect as >> "cseq" attribute is not defined in the element in the XML >> schema in RFC5628 section 9. Most likely "cseq" attribute should be >> replaced with "first-cseq" attribute. > > Yes, I agree. > >> If B) is the answer, then RFC5628 seems to contradict RFC3680 since: >> - RFC3680 states: >> ---- >> The optional >> "callid" attribute contains the current Call-ID carried in the >> REGISTER that was last used to update this contact, and the optional >> "cseq" attribute contains the _last CSeq value present in a REGISTER >> __request that updated this contact value_. >> --- >> - the 2nd marked sentence states: >> ---- >> The value of the "cseq" attribute is set to the value of >> the _CSeq header field of the REGISTER request that caused that first >> temporary GRUU to be assigned_. >> ---- > > Again, this ought to be "first-cseq". > > > Thanks, > Paul > >> Thanks for clarification. >> Kind regards >> >> *Ivo Sedlacek ** >> * >> >> >> Ericsson >> Technology and Portfolio Management, Terminal Standardization >> Sweden >> Office: +46 10 711 9382 >> Fax: +46 10 713 5929 >> ivo.sedlacek@ericsson.com >> www.ericsson.com >> >> >> Ericsson logo >> >> >> >> This communication is confidential. We only send and receive email on >> the basis of the term set out at www.ericsson.com/email_disclaimer >> >> >> >> >> _______________________________________________ >> 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 pkyzivat@alum.mit.edu Thu Oct 13 13:03:42 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB36A21F8B42 for ; Thu, 13 Oct 2011 13:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.317 X-Spam-Level: X-Spam-Status: No, score=-2.317 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3WIdKHFRYEp for ; Thu, 13 Oct 2011 13:03:41 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 4A76721F8B3A for ; Thu, 13 Oct 2011 13:03:41 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta12.westchester.pa.mail.comcast.net with comcast id kKAD1h0041uE5Es5CL3h1e; Thu, 13 Oct 2011 20:03:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta16.westchester.pa.mail.comcast.net with comcast id kL3h1h0120tdiYw3cL3hFo; Thu, 13 Oct 2011 20:03:41 +0000 Message-ID: <4E97441C.7070306@alum.mit.edu> Date: Thu, 13 Oct 2011 16:03:40 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> In-Reply-To: <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 20:03:42 -0000 On 10/13/11 3:26 PM, Hadriel Kaplan wrote: > > On Oct 7, 2011, at 2:22 PM, Paul Kyzivat wrote: > >> I'm trying to sort out what the concerns are about this. >> >> One might be for some server on the path to determine whether this functionality is present upstream from it, or downstream of it. Having the feature associated with a particular element in the path is one way to accomplish that, maybe the easiest way, but not the only way. >> >> Another is that there is *really* a need to know *which* server has the functionality. I can only think of a couple of reasons why: >> - there is need to send a request to it >> (which relates to Andrew's earlier proposals) >> - there is a need to validate it based on other properties >> of its entry in the route >> >> We should sort out which of these are the real requirements. > > > The problem with trying to learn which particular server supports feature X is that the identification of a particular server often doesn't get conveyed beyond the local SIP domain. SBCs, for example, have a popular feature called "Topology Hiding" which involves removing things like Record-Routes, Via, etc. Beyond the security/privacy reasons, it's also one of the things that often keep SIP messages small enough to use UDP without fragmentation. > > Because of that, even though SBCs could be made to pass on the feature capability information of other servers, I seriously doubt they'd do so by keeping the Record-Routes intact nor even by encrypting the Record-Route URIs. They'd probably just copy the feature info into the SBC's own contact/record-route/path/whatever. That would mean (1) you couldn't know which particular server supported that feature, and (2) the feature would only apply for that specific dialog. Once again we find ourselves designing around the unspecified behavior of the SBC. :-( If the feature is associated with a particular element, and then the behavior you describe is applied, the feature would still be at the proper place in the revised record-route, which would be sufficient for determining if it was upstream or downstream of some other element still visible in the record-route. But if its necessary to identify the precise server, then the SBC will probably break it. We probably need to hear what Christer thinks about this. It may turn out that all the interesting stuff happens all on one side of an SBC, and so doesn't get masked. Thanks, Paul From ibc@aliax.net Thu Oct 13 13:10:34 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0852A21F8B47 for ; Thu, 13 Oct 2011 13:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSE1J2GsMc4q for ; Thu, 13 Oct 2011 13:10:33 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 77CD021F8B8F for ; Thu, 13 Oct 2011 13:10:33 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so509965vcb.31 for ; Thu, 13 Oct 2011 13:10:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.184.11 with SMTP id ci11mr429025vcb.76.1318536630752; Thu, 13 Oct 2011 13:10:30 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Thu, 13 Oct 2011 13:10:30 -0700 (PDT) In-Reply-To: <4E97441C.7070306@alum.mit.edu> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> Date: Thu, 13 Oct 2011 22:10:30 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 20:10:34 -0000 2011/10/13 Paul Kyzivat : > Once again we find ourselves designing around the unspecified behavior of > the SBC. :-( What is a SBC? I cannot find it into the 200 RFC's related to SIP. :) --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Thu Oct 13 13:16:21 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B849921F86A4 for ; Thu, 13 Oct 2011 13:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MpT6O6SGpnn for ; Thu, 13 Oct 2011 13:16:21 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 447AE21F863E for ; Thu, 13 Oct 2011 13:16:21 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 13 Oct 2011 16:16:18 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 13 Oct 2011 16:16:18 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMieT2GtNXhTNPvEerT7cRB5m+UQ== Date: Thu, 13 Oct 2011 20:16:17 +0000 Message-ID: References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <087548E59FD5BC4F92129E70F3BA4FFC@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 20:16:21 -0000 Then you haven't read RFC 5853. :) -hadriel On Oct 13, 2011, at 4:10 PM, I=F1aki Baz Castillo wrote: > 2011/10/13 Paul Kyzivat : >> Once again we find ourselves designing around the unspecified behavior o= f >> the SBC. :-( >=20 > What is a SBC? I cannot find it into the 200 RFC's related to SIP. :) >=20 > --=20 > I=F1aki Baz Castillo > From oej@edvina.net Thu Oct 13 13:17:08 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF7721F8AFF for ; Thu, 13 Oct 2011 13:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.056 X-Spam-Level: X-Spam-Status: No, score=-1.056 tagged_above=-999 required=5 tests=[AWL=0.666, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWESfjlR6n9G for ; Thu, 13 Oct 2011 13:17:08 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 39ED521F8AFD for ; Thu, 13 Oct 2011 13:17:08 -0700 (PDT) Received: from [192.168.40.76] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 7B47F754BCE6; Thu, 13 Oct 2011 20:17:04 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Thu, 13 Oct 2011 22:17:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <74E8C64A-0389-4CF9-BA81-E2995368B4A9@edvina.net> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1244.3) Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 20:17:08 -0000 13 okt 2011 kl. 22:10 skrev I=F1aki Baz Castillo: > 2011/10/13 Paul Kyzivat : >> Once again we find ourselves designing around the unspecified = behavior of >> the SBC. :-( >=20 > What is a SBC? I cannot find it into the 200 RFC's related to SIP. :) Sorry, I=F1aki,=20 There is one. http://tools.ietf.org/html/rfc5853 /O ;-)= From ibc@aliax.net Thu Oct 13 13:24:36 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B1D21F8B95 for ; Thu, 13 Oct 2011 13:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSB5P5rQLF+x for ; Thu, 13 Oct 2011 13:24:36 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 26B8921F8B19 for ; Thu, 13 Oct 2011 13:24:36 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so526274vcb.31 for ; Thu, 13 Oct 2011 13:24:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.90.206 with SMTP id by14mr5672944vdb.18.1318537470804; Thu, 13 Oct 2011 13:24:30 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Thu, 13 Oct 2011 13:24:30 -0700 (PDT) In-Reply-To: References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> Date: Thu, 13 Oct 2011 22:24:30 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 20:24:36 -0000 2011/10/13 Hadriel Kaplan : > Then you haven't read RFC 5853. > :) That's a RFC that talks about devices specified nowhere, instead of being devices based on a RFC :) --=20 I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Thu Oct 13 13:24:36 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E302D21F8B17 for ; Thu, 13 Oct 2011 13:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbfLLhi0mqwQ for ; Thu, 13 Oct 2011 13:24:36 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2774F21F8B22 for ; Thu, 13 Oct 2011 13:24:36 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta07.westchester.pa.mail.comcast.net with comcast id kHTW1h0061ei1Bg57LQV1A; Thu, 13 Oct 2011 20:24:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta24.westchester.pa.mail.comcast.net with comcast id kLQR1h0370tdiYw3kLQS2i; Thu, 13 Oct 2011 20:24:29 +0000 Message-ID: <4E9748F9.3030404@alum.mit.edu> Date: Thu, 13 Oct 2011 16:24:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A058522341206CF@ESESSCMS0356.eemea.ericsson.se> <2BC1CD824C2D4F47A6F6EC2705F4F4D803DD4E@Mail1.acmepacket.com> <4E946782.5050508@digium.com>, <7F2072F1E0DE894DA4B517B93C6A05852234120AA4@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Accept in 18x X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 20:24:37 -0000 I'm inclined to agree that this was an error in 3261, and that Accept-* should be ok in all 1xx responses. The argument that the result won't be useful until after a 2xx is generally negated when reliable provisionals are used. On 10/12/11 12:40 AM, DRAGE, Keith (Keith) wrote: > Its fine saying that, but that means you have to work out what the semantics are when it is included in a 18x. > > A 18x only creates an early dialog. So does sending Accept in a 18x only apply for an early dialog, or does it apply for the remainder of the full dialog. Well, pretty much everything that is established in an early dialog still holds if the dialog becomes a final one. OTOH, the exact scope of applicability of Accept-* is pretty much undefined. It can change arbitrarily at almost any time. IMO it would be good to file an errata on this. Thanks, Paul > Also note there are other headers specified the same way. If this understanding applies to Accept, does it also apply to other headers. > > > > Keith > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf >> Of Worley, Dale R (Dale) >> Sent: 11 October 2011 21:14 >> To: Christer Holmberg; Kevin P. Fleming; sipcore@ietf.org >> Subject: Re: [sipcore] Accept in 18x >> >>> From: Christer Holmberg [christer.holmberg@ericsson.com] >>> >>> So, if there are no technical reasons, and 3GPP would like to specify >>> the usage of Accept in a provisional response, would an errata to 3261 >>> be needed (in order to be alligned with 3261)? >> >> It looks like Accept was not specified for 1xx because there was no >> practical use for it at the time 3261 was written. >> >> As far as I can tell, the only place where 3261 says that Accept isn't >> allowed in 1xx responses is in the giant table of "which headers are >> allowed in which messages". But I believe we've agreed to discontinue >> the normative status of that table, which would mean that wouldn't >> need to amend 3261 to maintain formal compliance. >> >> In practice, no UA should malfunction due to the unexpected presence >> of Accept in a 1xx response. >> >> So it seems to me that 3GPP can go ahead with using Accept in 1xx >> without worrying about updating 3261. >> >> Dale >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From HKaplan@acmepacket.com Thu Oct 13 13:28:19 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110D021F8ACC for ; Thu, 13 Oct 2011 13:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUv1iCrQ-a+B for ; Thu, 13 Oct 2011 13:28:18 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 85C1C21F8A64 for ; Thu, 13 Oct 2011 13:28:18 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 13 Oct 2011 16:28:16 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 13 Oct 2011 16:28:15 -0400 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMieaisxgTVF+wS0uuMc0o2Be+Mg== Date: Thu, 13 Oct 2011 20:28:14 +0000 Message-ID: <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> In-Reply-To: <4E97441C.7070306@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 20:28:19 -0000 On Oct 13, 2011, at 4:03 PM, Paul Kyzivat wrote: > Once again we find ourselves designing around the unspecified behavior of= the SBC. :-( That behavior is documented in RFC 5853, section 3.1.1. But it doesn't really matter. Forget about it being an SBC - let's just ta= lk about B2BUAs. A SIP B2BUA is, in its ultimate/full form, the logical en= d of one SIP scope and the beginning of another. There is nothing requirin= g the UAS side of a B2BUA to copy the received set of Record-Routes to the = UAC side of itself. Some do, some don't. -hadriel =20 From gilad@voxisoft.com Thu Oct 13 14:03:25 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D353521F8B37 for ; Thu, 13 Oct 2011 14:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a57MYuvTsn5 for ; Thu, 13 Oct 2011 14:03:25 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 90C8B21F8713 for ; Thu, 13 Oct 2011 14:03:18 -0700 (PDT) Received: by bkbzv3 with SMTP id zv3so2196152bkb.31 for ; Thu, 13 Oct 2011 14:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voxisoft.com; s=google; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:importance:x-mailer:x-mimeole; bh=qHxw0mIHvr8rW7FpEr6HgnS9oblyq0aYlw81G0gL8lE=; b=enwYasPmAPXsfswtuWYZdRPlr/92zJWncWQTRNNifrmkKh2escbibRZlJZzGw2HLIf FhqZyeVdBbvJk2mJuLGL8Je/IhwpmM1xPsnLzEJNUK7sN9m0BSzBcYMYiSkEVLdZ/uNs BJMbIH9LxPwprlZqaNmNxROPtKHQX0iK3IqHM= Received: by 10.204.134.25 with SMTP id h25mr4416008bkt.2.1318539797520; Thu, 13 Oct 2011 14:03:17 -0700 (PDT) Received: from gsmlaptop (bzq-79-179-8-12.red.bezeqint.net. [79.179.8.12]) by mx.google.com with ESMTPS id k6sm5168993bkv.8.2011.10.13.14.02.52 (version=SSLv3 cipher=OTHER); Thu, 13 Oct 2011 14:03:16 -0700 (PDT) Message-ID: <9C61F387F162415684E546188DB938F5@gsmlaptop> From: "Gilad Shaham" To: "Paul Kyzivat" , "Hadriel Kaplan" References: <4E8C785D.5080003@alum.mit.edu><4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se><4E8F435B.3030801@alum.mit.edu><8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> In-Reply-To: <4E97441C.7070306@alum.mit.edu> Date: Thu, 13 Oct 2011 23:01:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 21:03:25 -0000 Topology hiding which removes the record-route headers inherently means the other side does not obtain any information on the network, thus it shouldn't be possible to identify which server supports which feature since the existence of the server should not indicated in the first place. Requiring SBCs to convey the relevant information in their own contact/record-route/path makes sense in that scenario. What I'm saying is that this may be a non-issue from this RFC perspective even if SBC is involved, thus, if I'm right, there no need to design around the SBC behavior. -----Original Message----- From: Paul Kyzivat Sent: Thursday, October 13, 2011 10:03 PM To: Hadriel Kaplan Cc: Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature On 10/13/11 3:26 PM, Hadriel Kaplan wrote: > > On Oct 7, 2011, at 2:22 PM, Paul Kyzivat wrote: > >> I'm trying to sort out what the concerns are about this. >> >> One might be for some server on the path to determine whether this >> functionality is present upstream from it, or downstream of it. Having >> the feature associated with a particular element in the path is one way >> to accomplish that, maybe the easiest way, but not the only way. >> >> Another is that there is *really* a need to know *which* server has the >> functionality. I can only think of a couple of reasons why: >> - there is need to send a request to it >> (which relates to Andrew's earlier proposals) >> - there is a need to validate it based on other properties >> of its entry in the route >> >> We should sort out which of these are the real requirements. > > > The problem with trying to learn which particular server supports feature > X is that the identification of a particular server often doesn't get > conveyed beyond the local SIP domain. SBCs, for example, have a popular > feature called "Topology Hiding" which involves removing things like > Record-Routes, Via, etc. Beyond the security/privacy reasons, it's also > one of the things that often keep SIP messages small enough to use UDP > without fragmentation. > > Because of that, even though SBCs could be made to pass on the feature > capability information of other servers, I seriously doubt they'd do so by > keeping the Record-Routes intact nor even by encrypting the Record-Route > URIs. They'd probably just copy the feature info into the SBC's own > contact/record-route/path/whatever. That would mean (1) you couldn't know > which particular server supported that feature, and (2) the feature would > only apply for that specific dialog. Once again we find ourselves designing around the unspecified behavior of the SBC. :-( If the feature is associated with a particular element, and then the behavior you describe is applied, the feature would still be at the proper place in the revised record-route, which would be sufficient for determining if it was upstream or downstream of some other element still visible in the record-route. But if its necessary to identify the precise server, then the SBC will probably break it. We probably need to hear what Christer thinks about this. It may turn out that all the interesting stuff happens all on one side of an SBC, and so doesn't get masked. Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Thu Oct 13 14:06:51 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40DFF21F8A64 for ; Thu, 13 Oct 2011 14:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrFAx7l8mPHo for ; Thu, 13 Oct 2011 14:06:50 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 88E9221F8AC3 for ; Thu, 13 Oct 2011 14:06:50 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta14.westchester.pa.mail.comcast.net with comcast id kHyf1h0071ZXKqc5EM6rX1; Thu, 13 Oct 2011 21:06:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta21.westchester.pa.mail.comcast.net with comcast id kM6q1h01P0tdiYw3hM6qLJ; Thu, 13 Oct 2011 21:06:51 +0000 Message-ID: <4E9752E8.5000508@alum.mit.edu> Date: Thu, 13 Oct 2011 17:06:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> In-Reply-To: <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 21:06:51 -0000 On 10/13/11 4:28 PM, Hadriel Kaplan wrote: > > On Oct 13, 2011, at 4:03 PM, Paul Kyzivat wrote: > >> Once again we find ourselves designing around the unspecified behavior of the SBC. :-( > > That behavior is documented in RFC 5853, section 3.1.1. > > But it doesn't really matter. Forget about it being an SBC - let's just talk about B2BUAs. A SIP B2BUA is, in its ultimate/full form, the logical end of one SIP scope and the beginning of another. There is nothing requiring the UAS side of a B2BUA to copy the received set of Record-Routes to the UAC side of itself. Some do, some don't. Actually, as the draft is now written it only applies to proxies. As long as there are no B2BUAs in the path then its irrelevant. And for some B2BUAs it doesn't matter. For instance, with a conference focus, each connection to the focus in independent. Presumably nobody would expect to have this stuff propagate across a focus to the other participants. The place it matters is if there are B2BUAs on the signaling path that want to be viewed as roughly equivalent to proxies. From a normative perspective they need to behave as UAs, not proxies. Again, lets see what Christer and others that have a need for this think. Thanks, Paul From pkyzivat@alum.mit.edu Thu Oct 13 14:23:37 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CD621F8B95 for ; Thu, 13 Oct 2011 14:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPB2j5tgN3ga for ; Thu, 13 Oct 2011 14:23:36 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id D44A821F8A56 for ; Thu, 13 Oct 2011 14:23:35 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta07.westchester.pa.mail.comcast.net with comcast id kL3B1h02r1c6gX857MPc0M; Thu, 13 Oct 2011 21:23:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta23.westchester.pa.mail.comcast.net with comcast id kMPb1h00V0tdiYw3jMPbF1; Thu, 13 Oct 2011 21:23:36 +0000 Message-ID: <4E9756D5.2090302@alum.mit.edu> Date: Thu, 13 Oct 2011 17:23:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Olle E. Johansson" References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <74E8C64A-0389-4CF9-BA81-E2995368B4A9@edvina.net> In-Reply-To: <74E8C64A-0389-4CF9-BA81-E2995368B4A9@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 21:23:37 -0000 On 10/13/11 4:17 PM, Olle E. Johansson wrote: > > 13 okt 2011 kl. 22:10 skrev Iñaki Baz Castillo: > >> 2011/10/13 Paul Kyzivat: >>> Once again we find ourselves designing around the unspecified behavior of >>> the SBC. :-( >> >> What is a SBC? I cannot find it into the 200 RFC's related to SIP. :) > > Sorry, Iñaki, > > There is one. > > http://tools.ietf.org/html/rfc5853 > > /O ;-) I don't want to get into a pissing match here. SBCs are a fact of life, like NATs. But 5853 is not a *specification* of behavior. Its a description of some observed behavior based on a limited sample set as of April 2010 or before. AFAIK it was never intended as something to be used by implementers to decide what kinds of usage will and won't work in the presence of SBCs. Its been stated many times that the exact behavior of many SBCs is highly dependent on configuration by those deploying them in a particular network. So what will and won't work depends more upon the tastes of your SP than it does on the SBC vendors. Thanks, Paul From dworley@avaya.com Fri Oct 14 12:37:15 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD4F21F8D4C for ; Fri, 14 Oct 2011 12:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.319 X-Spam-Level: X-Spam-Status: No, score=-103.319 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SccUv89Cu3bz for ; Fri, 14 Oct 2011 12:37:14 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 474AA21F8D3A for ; Fri, 14 Oct 2011 12:37:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcHAI+OmE7GmAcF/2dsb2JhbABDqGd+B4FuAQEBAQMSKC0iAgEIDQUkBQsyFw4CBBsao2qbWIcYYQSZPowq X-IronPort-AV: E=Sophos;i="4.69,348,1315195200"; d="scan'208";a="272783621" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Oct 2011 15:37:11 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Oct 2011 15:35:44 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.202]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 14 Oct 2011 15:37:10 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Fri, 14 Oct 2011 15:37:11 -0400 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMid4N7VYX33eXSky4RVe9eKSGO5V8O/a4 Message-ID: References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu>, <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> In-Reply-To: <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 19:37:15 -0000 A little consideration of the philosophy of SIP raises warning flags regarding any feature which carries information regarding *which* upstream or downstream element performs a particular function, as opposed to a feature which carries information about *whether* *some* upstream or downstream element performs a particular function. On the whole, SIP does a good job of hiding upstream and downstream complexities, and its structure tends to prevent implementers from building horrible code that depends on particular arrangements of upstream/downstream elements. The result is a remarkably high level of interoperability. In particular, this architecture makes it possible to build SBCs with a reasonable amount of effort, because an SBC does not have to pass through any detailed information about "what is on the other side". In our situation, we should have a strong bias against a mechanism that specifies which proxy provides a particular function. Perhaps the use cases really do require that, in which case we should provide that. But we should examine the use cases very carefully to see if we can avoid it. Dale From pkyzivat@alum.mit.edu Fri Oct 14 14:01:32 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5460821F8CDC for ; Fri, 14 Oct 2011 14:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fg25c9Td0QDl for ; Fri, 14 Oct 2011 14:01:31 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id C49FE21F8B2D for ; Fri, 14 Oct 2011 14:01:31 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta01.westchester.pa.mail.comcast.net with comcast id kjxo1h0051c6gX851l1YBW; Fri, 14 Oct 2011 21:01:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta23.westchester.pa.mail.comcast.net with comcast id kl1X1h00n0tdiYw3jl1X90; Fri, 14 Oct 2011 21:01:31 +0000 Message-ID: <4E98A329.3040502@alum.mit.edu> Date: Fri, 14 Oct 2011 17:01:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu>, <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 21:01:32 -0000 I'm refraining from expressing too much of an opinion of what this should do, since I'm not the one that feels a need for this. I'm focusing on ensuring that we don't do something that violates general principles, and that is done well. So I would really like to hear from those that feel a need to say more about what it is they need. The mechanism Christer proposed *did* specify which proxy has the feature. But that doesn't mean its necessary to know that. Thanks, Paul On 10/14/11 3:37 PM, Worley, Dale R (Dale) wrote: > A little consideration of the philosophy of SIP raises warning flags > regarding any feature which carries information regarding *which* > upstream or downstream element performs a particular function, as > opposed to a feature which carries information about *whether* *some* > upstream or downstream element performs a particular function. On the > whole, SIP does a good job of hiding upstream and downstream > complexities, and its structure tends to prevent implementers from > building horrible code that depends on particular arrangements of > upstream/downstream elements. The result is a remarkably high level > of interoperability. In particular, this architecture makes it > possible to build SBCs with a reasonable amount of effort, because an > SBC does not have to pass through any detailed information about "what > is on the other side". > > In our situation, we should have a strong bias against a mechanism > that specifies which proxy provides a particular function. Perhaps > the use cases really do require that, in which case we should provide > that. But we should examine the use cases very carefully to see if we > can avoid it. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Sun Oct 16 06:35:38 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1279A21F8A6F for ; Sun, 16 Oct 2011 06:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DEmQywtG5PC for ; Sun, 16 Oct 2011 06:35:37 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 39C8121F87FC for ; Sun, 16 Oct 2011 06:35:36 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f6-4e9adda7a65d Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A3.9B.20773.7ADDA9E4; Sun, 16 Oct 2011 15:35:35 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Sun, 16 Oct 2011 15:35:35 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Date: Sun, 16 Oct 2011 15:35:33 +0200 Thread-Topic: [sipcore] Accept in 18x Thread-Index: AcyJ5iOsp0oepPI5Reetocm3Bf5OqQBMcLfg Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522341AE6C0@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058522341206CF@ESESSCMS0356.eemea.ericsson.se> <2BC1CD824C2D4F47A6F6EC2705F4F4D803DD4E@Mail1.acmepacket.com> <4E946782.5050508@digium.com>, <7F2072F1E0DE894DA4B517B93C6A05852234120AA4@ESESSCMS0356.eemea.ericsson.se> <4E9748F9.3030404@alum.mit.edu> In-Reply-To: <4E9748F9.3030404@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Accept in 18x X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 13:35:38 -0000 Hi, Do we have text explicitly saying that a Contact received in a provisional = response is valid after 200 OK (unless you receive a Contact in the 200 OK,= of course)? Regards, Christer=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 13. lokakuuta 2011 23:24 > To: sipcore@ietf.org > Subject: Re: [sipcore] Accept in 18x >=20 > I'm inclined to agree that this was an error in 3261, and=20 > that Accept-* should be ok in all 1xx responses. >=20 > The argument that the result won't be useful until after a=20 > 2xx is generally negated when reliable provisionals are used. >=20 > On 10/12/11 12:40 AM, DRAGE, Keith (Keith) wrote: > > Its fine saying that, but that means you have to work out=20 > what the semantics are when it is included in a 18x. > > > > A 18x only creates an early dialog. So does sending Accept=20 > in a 18x only apply for an early dialog, or does it apply for=20 > the remainder of the full dialog. >=20 > Well, pretty much everything that is established in an early=20 > dialog still holds if the dialog becomes a final one. >=20 > OTOH, the exact scope of applicability of Accept-* is pretty=20 > much undefined. It can change arbitrarily at almost any time. >=20 > IMO it would be good to file an errata on this. >=20 > Thanks, > Paul >=20 > > Also note there are other headers specified the same way.=20 > If this understanding applies to Accept, does it also apply=20 > to other headers. > > > > > > > > Keith > > > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On=20 > >> Behalf Of Worley, Dale R (Dale) > >> Sent: 11 October 2011 21:14 > >> To: Christer Holmberg; Kevin P. Fleming; sipcore@ietf.org > >> Subject: Re: [sipcore] Accept in 18x > >> > >>> From: Christer Holmberg [christer.holmberg@ericsson.com] > >>> > >>> So, if there are no technical reasons, and 3GPP would like to=20 > >>> specify the usage of Accept in a provisional response, would an=20 > >>> errata to 3261 be needed (in order to be alligned with 3261)? > >> > >> It looks like Accept was not specified for 1xx because=20 > there was no=20 > >> practical use for it at the time 3261 was written. > >> > >> As far as I can tell, the only place where 3261 says that Accept=20 > >> isn't allowed in 1xx responses is in the giant table of "which=20 > >> headers are allowed in which messages". But I believe=20 > we've agreed=20 > >> to discontinue the normative status of that table, which=20 > would mean=20 > >> that wouldn't need to amend 3261 to maintain formal compliance. > >> > >> In practice, no UA should malfunction due to the=20 > unexpected presence=20 > >> of Accept in a 1xx response. > >> > >> So it seems to me that 3GPP can go ahead with using Accept in 1xx=20 > >> without worrying about updating 3261. > >> > >> Dale > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Sun Oct 16 06:41:34 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E78421F8713 for ; Sun, 16 Oct 2011 06:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9X5LLpLu3jR for ; Sun, 16 Oct 2011 06:41:33 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 126FA21F86FF for ; Sun, 16 Oct 2011 06:41:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-d6-4e9adf0b52cd Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 53.3A.13753.B0FDA9E4; Sun, 16 Oct 2011 15:41:32 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Sun, 16 Oct 2011 15:41:31 +0200 From: Christer Holmberg To: Paul Kyzivat , Hadriel Kaplan Date: Sun, 16 Oct 2011 15:41:29 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AcyJ7AlK024niTf4Rgmv0/IVgmPzhABLreCw Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> In-Reply-To: <4E9752E8.5000508@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 13:41:34 -0000 Hi, >>> Once again we find ourselves designing around the unspecified=20 >>> behavior of the SBC. :-( >> >> That behavior is documented in RFC 5853, section 3.1.1. >> >> But it doesn't really matter. Forget about it being an SBC=20 >> - let's just talk about B2BUAs. A SIP B2BUA is, in its=20 >> ultimate/full form, the logical end of one SIP scope and the=20 >> beginning of another. There is nothing requiring the UAS=20 >> side of a B2BUA to copy the received set of Record-Routes to=20 >> the UAC side of itself. Some do, some don't. >=20 > Actually, as the draft is now written it only applies to proxies. > As long as there are no B2BUAs in the path then its irrelevant. It's not as easy as that, I'm afraid. Many of the B2BUAs out there are "hybrid", i.e. they also contain pure prox= y behavior. For example, they may insert themselves in a Record-Route, rath= er than modifying the Contact. And, eventhough what Hadriel says is true, SBCs that do topology hiding wil= l have to become more "intelligent", in order not to break services that re= ly e.g. on information in the Record-Route headers. Also, there are services that rely on the fact that the Contact always poin= t to the UE. > And for some B2BUAs it doesn't matter. For instance, with a=20 > conference focus, each connection to the focus in=20 > independent. Presumably nobody would expect to have this=20 > stuff propagate across a focus to the other participants. >=20 > The place it matters is if there are B2BUAs on the signaling=20 > path that want to be viewed as roughly equivalent to proxies.=20 > From a normative perspective they need to behave as UAs, not proxies. >=20 > Again, lets see what Christer and others that have a need for=20 > this think. I've spent the whole week at a 3GPP meeting (where we DO know what an SBC i= s, btw :), but I'll get back on the use-case/requirement issue asap. Regards, Christer From pkyzivat@alum.mit.edu Sun Oct 16 08:52:10 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7E921F8A4E for ; Sun, 16 Oct 2011 08:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8sIPX8J+pQU for ; Sun, 16 Oct 2011 08:52:09 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 4140C21F8505 for ; Sun, 16 Oct 2011 08:52:09 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta13.westchester.pa.mail.comcast.net with comcast id lSj31h00927AodY5DTs9ox; Sun, 16 Oct 2011 15:52:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta19.westchester.pa.mail.comcast.net with comcast id lTs81h00J0tdiYw3fTs80P; Sun, 16 Oct 2011 15:52:09 +0000 Message-ID: <4E9AFDA5.3010402@alum.mit.edu> Date: Sun, 16 Oct 2011 11:52:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A058522341206CF@ESESSCMS0356.eemea.ericsson.se> <2BC1CD824C2D4F47A6F6EC2705F4F4D803DD4E@Mail1.acmepacket.com> <4E946782.5050508@digium.com>, <7F2072F1E0DE894DA4B517B93C6A05852234120AA4@ESESSCMS0356.eemea.ericsson.se> <4E9748F9.3030404@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C0@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341AE6C0@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Accept in 18x X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 15:52:10 -0000 On 10/16/11 9:35 AM, Christer Holmberg wrote: > > Hi, > > Do we have text explicitly saying that a Contact received in a provisional response is valid after 200 OK (unless you receive a Contact in the 200 OK, of course)? This is a change in subject from the original question. What are you looking for? Valid for *what*? Obviously its impossible to send a PRACK or an UPDATE on an early dialog without having received a contact. In fact, I think we have agreed that you don't have an early dialog unless you got a contact in a provisional. Thanks, Paul > Regards, > > Christer > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 13. lokakuuta 2011 23:24 >> To: sipcore@ietf.org >> Subject: Re: [sipcore] Accept in 18x >> >> I'm inclined to agree that this was an error in 3261, and >> that Accept-* should be ok in all 1xx responses. >> >> The argument that the result won't be useful until after a >> 2xx is generally negated when reliable provisionals are used. >> >> On 10/12/11 12:40 AM, DRAGE, Keith (Keith) wrote: >>> Its fine saying that, but that means you have to work out >> what the semantics are when it is included in a 18x. >>> >>> A 18x only creates an early dialog. So does sending Accept >> in a 18x only apply for an early dialog, or does it apply for >> the remainder of the full dialog. >> >> Well, pretty much everything that is established in an early >> dialog still holds if the dialog becomes a final one. >> >> OTOH, the exact scope of applicability of Accept-* is pretty >> much undefined. It can change arbitrarily at almost any time. >> >> IMO it would be good to file an errata on this. >> >> Thanks, >> Paul >> >>> Also note there are other headers specified the same way. >> If this understanding applies to Accept, does it also apply >> to other headers. >>> >>> >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On >>>> Behalf Of Worley, Dale R (Dale) >>>> Sent: 11 October 2011 21:14 >>>> To: Christer Holmberg; Kevin P. Fleming; sipcore@ietf.org >>>> Subject: Re: [sipcore] Accept in 18x >>>> >>>>> From: Christer Holmberg [christer.holmberg@ericsson.com] >>>>> >>>>> So, if there are no technical reasons, and 3GPP would like to >>>>> specify the usage of Accept in a provisional response, would an >>>>> errata to 3261 be needed (in order to be alligned with 3261)? >>>> >>>> It looks like Accept was not specified for 1xx because >> there was no >>>> practical use for it at the time 3261 was written. >>>> >>>> As far as I can tell, the only place where 3261 says that Accept >>>> isn't allowed in 1xx responses is in the giant table of "which >>>> headers are allowed in which messages". But I believe >> we've agreed >>>> to discontinue the normative status of that table, which >> would mean >>>> that wouldn't need to amend 3261 to maintain formal compliance. >>>> >>>> In practice, no UA should malfunction due to the >> unexpected presence >>>> of Accept in a 1xx response. >>>> >>>> So it seems to me that 3GPP can go ahead with using Accept in 1xx >>>> without worrying about updating 3261. >>>> >>>> Dale >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From christer.holmberg@ericsson.com Mon Oct 17 00:04:41 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5314D21F8B2D for ; Mon, 17 Oct 2011 00:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93MnhjfUjiyg for ; Mon, 17 Oct 2011 00:04:40 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2371121F8B27 for ; Mon, 17 Oct 2011 00:04:39 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-29-4e9bd3867712 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id FF.35.13753.683DB9E4; Mon, 17 Oct 2011 09:04:38 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 17 Oct 2011 09:04:38 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Mon, 17 Oct 2011 09:04:37 +0200 Thread-Topic: [sipcore] Accept in 18x Thread-Index: AcyMG4/+TICtDgVWQ7WEL5qhK3+kQgAfyndA Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522341AE78E@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058522341206CF@ESESSCMS0356.eemea.ericsson.se> <2BC1CD824C2D4F47A6F6EC2705F4F4D803DD4E@Mail1.acmepacket.com> <4E946782.5050508@digium.com>, <7F2072F1E0DE894DA4B517B93C6A05852234120AA4@ESESSCMS0356.eemea.ericsson.se> <4E9748F9.3030404@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C0@ESESSCMS0356.eemea.ericsson.se> <4E9AFDA5.3010402@alum.mit.edu> In-Reply-To: <4E9AFDA5.3010402@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Accept in 18x X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 07:04:41 -0000 Hi,=20 >> Do we have text explicitly saying that a Contact received=20 >> in a provisional response is valid after 200 OK (unless you=20 >> receive a Contact in the 200 OK, of course)? >=20 > This is a change in subject from the original question. >=20 > What are you looking for? Valid for *what*? >=20 > Obviously its impossible to send a PRACK or an UPDATE on an=20 > early dialog without having received a contact. In fact, I=20 > think we have agreed that you don't have an early dialog=20 > unless you got a contact in a provisional. That's not what I meant. The question was: if I receive a Contact in a 18x, is the Contact VALUE als= o valid after I have received the 200 OK? Obviously, if it's not, I can't send any in-dialog requests (including the = ACK) after I've received the 200 OK.=20 Regards, Christer > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: 13. lokakuuta 2011 23:24 > >> To: sipcore@ietf.org > >> Subject: Re: [sipcore] Accept in 18x > >> > >> I'm inclined to agree that this was an error in 3261, and that=20 > >> Accept-* should be ok in all 1xx responses. > >> > >> The argument that the result won't be useful until after a 2xx is=20 > >> generally negated when reliable provisionals are used. > >> > >> On 10/12/11 12:40 AM, DRAGE, Keith (Keith) wrote: > >>> Its fine saying that, but that means you have to work out > >> what the semantics are when it is included in a 18x. > >>> > >>> A 18x only creates an early dialog. So does sending Accept > >> in a 18x only apply for an early dialog, or does it apply for the=20 > >> remainder of the full dialog. > >> > >> Well, pretty much everything that is established in an=20 > early dialog=20 > >> still holds if the dialog becomes a final one. > >> > >> OTOH, the exact scope of applicability of Accept-* is pretty much=20 > >> undefined. It can change arbitrarily at almost any time. > >> > >> IMO it would be good to file an errata on this. > >> > >> Thanks, > >> Paul > >> > >>> Also note there are other headers specified the same way. > >> If this understanding applies to Accept, does it also=20 > apply to other=20 > >> headers. > >>> > >>> > >>> > >>> Keith > >>> > >>>> -----Original Message----- > >>>> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On > >>>> Behalf Of Worley, Dale R (Dale) > >>>> Sent: 11 October 2011 21:14 > >>>> To: Christer Holmberg; Kevin P. Fleming; sipcore@ietf.org > >>>> Subject: Re: [sipcore] Accept in 18x > >>>> > >>>>> From: Christer Holmberg [christer.holmberg@ericsson.com] > >>>>> > >>>>> So, if there are no technical reasons, and 3GPP would like to=20 > >>>>> specify the usage of Accept in a provisional response, would an=20 > >>>>> errata to 3261 be needed (in order to be alligned with 3261)? > >>>> > >>>> It looks like Accept was not specified for 1xx because > >> there was no > >>>> practical use for it at the time 3261 was written. > >>>> > >>>> As far as I can tell, the only place where 3261 says that Accept=20 > >>>> isn't allowed in 1xx responses is in the giant table of "which=20 > >>>> headers are allowed in which messages". But I believe > >> we've agreed > >>>> to discontinue the normative status of that table, which > >> would mean > >>>> that wouldn't need to amend 3261 to maintain formal compliance. > >>>> > >>>> In practice, no UA should malfunction due to the > >> unexpected presence > >>>> of Accept in a 1xx response. > >>>> > >>>> So it seems to me that 3GPP can go ahead with using=20 > Accept in 1xx=20 > >>>> without worrying about updating 3261. > >>>> > >>>> Dale > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> >=20 > = From pkyzivat@alum.mit.edu Mon Oct 17 07:04:44 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A426721F8B83 for ; Mon, 17 Oct 2011 07:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3uq35OB7+1b for ; Mon, 17 Oct 2011 07:04:44 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id C516621F87F0 for ; Mon, 17 Oct 2011 07:04:43 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta09.westchester.pa.mail.comcast.net with comcast id lq061h0011HzFnQ59q4koP; Mon, 17 Oct 2011 14:04:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta14.westchester.pa.mail.comcast.net with comcast id lq4j1h01a0tdiYw3aq4joN; Mon, 17 Oct 2011 14:04:44 +0000 Message-ID: <4E9C35F9.1020607@alum.mit.edu> Date: Mon, 17 Oct 2011 10:04:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A058522341206CF@ESESSCMS0356.eemea.ericsson.se> <2BC1CD824C2D4F47A6F6EC2705F4F4D803DD4E@Mail1.acmepacket.com> <4E946782.5050508@digium.com>, <7F2072F1E0DE894DA4B517B93C6A05852234120AA4@ESESSCMS0356.eemea.ericsson.se> <4E9748F9.3030404@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C0@ESESSCMS0356.eemea.ericsson.se> <4E9AFDA5.3010402@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE78E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341AE78E@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Accept in 18x X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 14:04:44 -0000 On 10/17/11 3:04 AM, Christer Holmberg wrote: > > Hi, > >>> Do we have text explicitly saying that a Contact received >>> in a provisional response is valid after 200 OK (unless you >>> receive a Contact in the 200 OK, of course)? >> >> This is a change in subject from the original question. >> >> What are you looking for? Valid for *what*? >> >> Obviously its impossible to send a PRACK or an UPDATE on an >> early dialog without having received a contact. In fact, I >> think we have agreed that you don't have an early dialog >> unless you got a contact in a provisional. > > That's not what I meant. > > The question was: if I receive a Contact in a 18x, is the Contact VALUE also valid after I have received the 200 OK? > > Obviously, if it's not, I can't send any in-dialog requests (including the ACK) after I've received the 200 OK. Well, there should also be a Contact in the 2xx, and typically it would have the same value as the one in the 1xx for the same dialog. Your question is only interesting if the two values are different. IIRC, 3261 specifies that the remote contact address is part of the dialog state. And the remote contact is allowed to change. So each time you get a new value it should supersede the prior value in the dialog state, and then be used for subsequent in-dialog requests. Thanks, Paul > Regards, > > Christer > > > >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: 13. lokakuuta 2011 23:24 >>>> To: sipcore@ietf.org >>>> Subject: Re: [sipcore] Accept in 18x >>>> >>>> I'm inclined to agree that this was an error in 3261, and that >>>> Accept-* should be ok in all 1xx responses. >>>> >>>> The argument that the result won't be useful until after a 2xx is >>>> generally negated when reliable provisionals are used. >>>> >>>> On 10/12/11 12:40 AM, DRAGE, Keith (Keith) wrote: >>>>> Its fine saying that, but that means you have to work out >>>> what the semantics are when it is included in a 18x. >>>>> >>>>> A 18x only creates an early dialog. So does sending Accept >>>> in a 18x only apply for an early dialog, or does it apply for the >>>> remainder of the full dialog. >>>> >>>> Well, pretty much everything that is established in an >> early dialog >>>> still holds if the dialog becomes a final one. >>>> >>>> OTOH, the exact scope of applicability of Accept-* is pretty much >>>> undefined. It can change arbitrarily at almost any time. >>>> >>>> IMO it would be good to file an errata on this. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Also note there are other headers specified the same way. >>>> If this understanding applies to Accept, does it also >> apply to other >>>> headers. >>>>> >>>>> >>>>> >>>>> Keith >>>>> >>>>>> -----Original Message----- >>>>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On >>>>>> Behalf Of Worley, Dale R (Dale) >>>>>> Sent: 11 October 2011 21:14 >>>>>> To: Christer Holmberg; Kevin P. Fleming; sipcore@ietf.org >>>>>> Subject: Re: [sipcore] Accept in 18x >>>>>> >>>>>>> From: Christer Holmberg [christer.holmberg@ericsson.com] >>>>>>> >>>>>>> So, if there are no technical reasons, and 3GPP would like to >>>>>>> specify the usage of Accept in a provisional response, would an >>>>>>> errata to 3261 be needed (in order to be alligned with 3261)? >>>>>> >>>>>> It looks like Accept was not specified for 1xx because >>>> there was no >>>>>> practical use for it at the time 3261 was written. >>>>>> >>>>>> As far as I can tell, the only place where 3261 says that Accept >>>>>> isn't allowed in 1xx responses is in the giant table of "which >>>>>> headers are allowed in which messages". But I believe >>>> we've agreed >>>>>> to discontinue the normative status of that table, which >>>> would mean >>>>>> that wouldn't need to amend 3261 to maintain formal compliance. >>>>>> >>>>>> In practice, no UA should malfunction due to the >>>> unexpected presence >>>>>> of Accept in a 1xx response. >>>>>> >>>>>> So it seems to me that 3GPP can go ahead with using >> Accept in 1xx >>>>>> without worrying about updating 3261. >>>>>> >>>>>> Dale >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >> >> From pkyzivat@alum.mit.edu Mon Oct 17 08:51:10 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C983621F8CE4 for ; Mon, 17 Oct 2011 08:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1x9dbvIugPD for ; Mon, 17 Oct 2011 08:51:10 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 02BAF21F8CB8 for ; Mon, 17 Oct 2011 08:51:09 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta15.westchester.pa.mail.comcast.net with comcast id lo1a1h0041swQuc5FrrAYw; Mon, 17 Oct 2011 15:51:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta15.westchester.pa.mail.comcast.net with comcast id lrr91h01H0tdiYw3brrARb; Mon, 17 Oct 2011 15:51:10 +0000 Message-ID: <4E9C4EEB.3080205@alum.mit.edu> Date: Mon, 17 Oct 2011 11:51:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 15:51:10 -0000 On 10/16/11 9:41 AM, Christer Holmberg wrote: > > Hi, > >>>> Once again we find ourselves designing around the unspecified >>>> behavior of the SBC. :-( >>> >>> That behavior is documented in RFC 5853, section 3.1.1. >>> >>> But it doesn't really matter. Forget about it being an SBC >>> - let's just talk about B2BUAs. A SIP B2BUA is, in its >>> ultimate/full form, the logical end of one SIP scope and the >>> beginning of another. There is nothing requiring the UAS >>> side of a B2BUA to copy the received set of Record-Routes to >>> the UAC side of itself. Some do, some don't. >> >> Actually, as the draft is now written it only applies to proxies. >> As long as there are no B2BUAs in the path then its irrelevant. > > It's not as easy as that, I'm afraid. > > Many of the B2BUAs out there are "hybrid", > i.e. they also contain pure proxy behavior. > For example, they may insert themselves in a Record-Route, > rather than modifying the Contact. Well, if proxy-feature is applicable to boxes that are "hybrid" in that sense, then either their behavior is only being specified when they are acting as a proxy, or else we will need some way to defining their relation to this new functionality when they are *not* acting as proxies. IOW, maybe this spec defines the behavior for a pure proxy, and the new work Hadriel is suggesting would be used to specify how a B2BUA would behave. > And, eventhough what Hadriel says is true, SBCs that do topology hiding will have to become more "intelligent", in order not to break services that rely e.g. on information in the Record-Route headers. topology hiding isn't limited to B2BUAs. Proxies can do it too, to a limited extent. But if proxy-feature is to work in the face of topology-hiding, then presumably that needs to be kept in mind when working out the mechanism. > Also, there are services that rely on the fact that the Contact always point to the UE. Sure. (That's why we have gruu.) But we seem to be getting far afield. I'm not certain what relevance that has to this discussion. >> And for some B2BUAs it doesn't matter. For instance, with a >> conference focus, each connection to the focus in >> independent. Presumably nobody would expect to have this >> stuff propagate across a focus to the other participants. >> >> The place it matters is if there are B2BUAs on the signaling >> path that want to be viewed as roughly equivalent to proxies. >> From a normative perspective they need to behave as UAs, not proxies. >> >> Again, lets see what Christer and others that have a need for >> this think. > > I've spent the whole week at a 3GPP meeting (where we DO know what an SBC is, btw :), but I'll get back on the use-case/requirement issue asap. Fine. We'll look forward to your clarification after you have a chance to get caught up. Thanks, Paul From HKaplan@acmepacket.com Mon Oct 17 09:56:34 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A1521F8BC5 for ; Mon, 17 Oct 2011 09:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APY-5N8J46Qt for ; Mon, 17 Oct 2011 09:56:33 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7D55B21F8678 for ; Mon, 17 Oct 2011 09:56:33 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 17 Oct 2011 12:56:32 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 17 Oct 2011 12:56:32 -0400 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMjO24Gv9cx+n+8E2LbjAxRdWALQ== Date: Mon, 17 Oct 2011 16:56:31 +0000 Message-ID: References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <4E9C4EEB.3080205@alum.mit.edu> In-Reply-To: <4E9C4EEB.3080205@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <53EDCE25A34CF449BDFD720A1FCFF854@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 16:56:34 -0000 On Oct 17, 2011, at 11:51 AM, Paul Kyzivat wrote: >=20 > Well, if proxy-feature is applicable to boxes that are "hybrid" in that s= ense, then either their behavior is only being specified when they are acti= ng as a proxy, or else we will need some way to defining their relation to = this new functionality when they are *not* acting as proxies. Technically, the "features" being indicated are when the Proxy stops behavi= ng as a Proxy and starts behaving as a B2BUA. They are B2BUA features bein= g indicated by a device while it is performing a Proxy role, to indicate it= can behave in a B2BUA role for feature X some time later. > IOW, maybe this spec defines the behavior for a pure proxy, and the new w= ork Hadriel is suggesting would be used to specify how a B2BUA would behave= . Well... the first deliverable I had in the STRAW charter was this: 1) A document defining the requirements for B2BUAs to identify specific fea= tures/capabilities support. And what I meant by that was in fact based on draft-holmberg-sipcore-proxy-= feature-02. I'm not actually sure why proxy-features is in SIPCORE, but I guess it does= n't matter so I'll remove the deliverable from STRAW. -hadriel From pkyzivat@alum.mit.edu Mon Oct 17 10:41:10 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1131421F8569 for ; Mon, 17 Oct 2011 10:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwtg6juE5DR7 for ; Mon, 17 Oct 2011 10:41:09 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB5621F8558 for ; Mon, 17 Oct 2011 10:41:09 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta06.westchester.pa.mail.comcast.net with comcast id ltTV1h0031HzFnQ56th8uD; Mon, 17 Oct 2011 17:41:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta14.westchester.pa.mail.comcast.net with comcast id lth81h00a0tdiYw3ath8fA; Mon, 17 Oct 2011 17:41:08 +0000 Message-ID: <4E9C68B1.2080102@alum.mit.edu> Date: Mon, 17 Oct 2011 13:41:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <4E9C4EEB.3080205@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 17:41:10 -0000 On 10/17/11 12:56 PM, Hadriel Kaplan wrote: > > On Oct 17, 2011, at 11:51 AM, Paul Kyzivat wrote: >> >> Well, if proxy-feature is applicable to boxes that are "hybrid" in that sense, then either their behavior is only being specified when they are acting as a proxy, or else we will need some way to defining their relation to this new functionality when they are *not* acting as proxies. > > Technically, the "features" being indicated are when the Proxy stops behaving as a Proxy and starts behaving as a B2BUA. They are B2BUA features being indicated by a device while it is performing a Proxy role, to indicate it can behave in a B2BUA role for feature X some time later. Interesting. I guess the use cases Christer has presented do have that property. I don't know if we should assume that all do. It is an interesting sort of distinction. >> IOW, maybe this spec defines the behavior for a pure proxy, and the new work Hadriel is suggesting would be used to specify how a B2BUA would behave. > > Well... the first deliverable I had in the STRAW charter was this: > 1) A document defining the requirements for B2BUAs to identify specific features/capabilities support. > > And what I meant by that was in fact based on draft-holmberg-sipcore-proxy-feature-02. I didn't realize you meant that linkage. > I'm not actually sure why proxy-features is in SIPCORE, but I guess it doesn't matter so I'll remove the deliverable from STRAW. IMO its in sipcore because as initially presented (with the mechanism) it was a core change. If it turns out that it would be better addressed in a different WG, *I* have no problem handing off responsibility. For instance, if the work needs to do some significant work to define what a proxy-feature is, and if that is related to a b2bua-feature. Thanks, Paul From christer.holmberg@ericsson.com Tue Oct 18 00:16:52 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C591F0C79 for ; Tue, 18 Oct 2011 00:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4k-+9qobghw for ; Tue, 18 Oct 2011 00:16:51 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 83B5B1F0C72 for ; Tue, 18 Oct 2011 00:16:51 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-73-4e9d27bf0802 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 81.4E.13753.FB72D9E4; Tue, 18 Oct 2011 09:16:16 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 18 Oct 2011 09:16:15 +0200 From: Christer Holmberg To: Paul Kyzivat , Hadriel Kaplan Date: Tue, 18 Oct 2011 09:16:13 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AcyM8/Rh0aWDNtvlR6+oyEweICG9JgAb+j1A Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522341AEF1D@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <4E9C4EEB.3080205@alum.mit.edu> <4E9C68B1.2080102@alum.mit.edu> In-Reply-To: <4E9C68B1.2080102@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 07:16:52 -0000 Hi, In draft-holmberg it was quite obvious. It's about an entity, acting as a p= roxy (ie does not insert Contact), indicating support of features (in Recor= d-Route etc). So, the question is how to get that into proper requirements text. I hope w= e are not going to spend too much time on that, because I think it's rather= obvious what people want. >>> Well, if proxy-feature is applicable to boxes that are=20 >>> "hybrid" in that sense, then either their behavior is only=20 >>> being specified when they are acting as a proxy, or else we=20 >>> will need some way to defining their relation to this new=20 >>> functionality when they are *not* acting as proxies. >> >> Technically, the "features" being indicated are when the=20 >> Proxy stops behaving as a Proxy and starts behaving as a=20 >> B2BUA. They are B2BUA features being indicated by a device=20 >> while it is performing a Proxy role, to indicate it can=20 >> behave in a B2BUA role for feature X some time later. >=20 > Interesting. I guess the use cases Christer has presented do=20 > have that property. I don't know if we should assume that all=20 > do. It is an interesting sort of distinction. I do agree that the current use-cases give such indication. It's about enti= ties not being pure proxies, but acting as proxies when it comes to inserti= ng themselves in the signaling path. I think it is quite clear in draft-holmberg. But, since we are not allowed = to talk about protocol mechanisms in the requirements draft, the question i= s how to write it down in a generic way :) >>> IOW, maybe this spec defines the behavior for a pure=20 >>> proxy, and the new work Hadriel is suggesting would be used=20 >>> to specify how a B2BUA would behave. >> >> Well... the first deliverable I had in the STRAW charter was this: >> 1) A document defining the requirements for B2BUAs to=20 >> identify specific features/capabilities support. >> >> And what I meant by that was in fact based on=20 >> draft-holmberg-sipcore-proxy-feature-02. >=20 > I didn't realize you meant that linkage. >=20 >> I'm not actually sure why proxy-features is in SIPCORE, but=20 >> I guess it doesn't matter so I'll remove the deliverable from STRAW. >=20 > IMO its in sipcore because as initially presented (with the=20 > mechanism) it was a core change. >=20 > If it turns out that it would be better addressed in a=20 > different WG, *I* have no problem handing off responsibility.=20 > For instance, if the work needs to do some significant work=20 > to define what a proxy-feature is, and if that is related to=20 > a b2bua-feature. Maybe we need to add some wording (separate, or as part of some of the requ= irements), which clarifies that we are not talking about pure proxies, but = about entities that act as proxies (instead of UAs) when they indicate supp= ort of features. Regards, Christer From christer.holmberg@ericsson.com Tue Oct 18 00:20:06 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0C021F84F9 for ; Tue, 18 Oct 2011 00:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCqcYcK4wDIK for ; Tue, 18 Oct 2011 00:20:05 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9D49F21F8445 for ; Tue, 18 Oct 2011 00:20:04 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-e3-4e9d28a38e03 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 83.1F.13753.3A82D9E4; Tue, 18 Oct 2011 09:20:03 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 18 Oct 2011 09:20:03 +0200 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , Hadriel Kaplan Date: Tue, 18 Oct 2011 09:20:02 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AcyM8/Rh0aWDNtvlR6+oyEweICG9JgAb+j1AAACaUZA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522341AEF2F@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <4E9C4EEB.3080205@alum.mit.edu> <4E9C68B1.2080102@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AEF1D@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341AEF1D@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 07:20:06 -0000 A small copy paste error. The first "In draft-holmberg it was obvious..." s= hould be removed :) > >>> Well, if proxy-feature is applicable to boxes that are=20 > "hybrid" in=20 > >>> that sense, then either their behavior is only being=20 > specified when=20 > >>> they are acting as a proxy, or else we will need some way to=20 > >>> defining their relation to this new functionality when they are=20 > >>> *not* acting as proxies. > >> > >> Technically, the "features" being indicated are when the=20 > Proxy stops=20 > >> behaving as a Proxy and starts behaving as a B2BUA. They=20 > are B2BUA=20 > >> features being indicated by a device while it is=20 > performing a Proxy=20 > >> role, to indicate it can behave in a B2BUA role for feature X some=20 > >> time later. > >=20 > > Interesting. I guess the use cases Christer has presented=20 > do have that=20 > > property. I don't know if we should assume that all do. It is an=20 > > interesting sort of distinction. >=20 > I do agree that the current use-cases give such indication.=20 > It's about entities not being pure proxies, but acting as=20 > proxies when it comes to inserting themselves in the signaling path. >=20 > I think it is quite clear in draft-holmberg. But, since we=20 > are not allowed to talk about protocol mechanisms in the=20 > requirements draft, the question is how to write it down in a=20 > generic way :) >=20 > >>> IOW, maybe this spec defines the behavior for a pure=20 > proxy, and the=20 > >>> new work Hadriel is suggesting would be used to specify=20 > how a B2BUA=20 > >>> would behave. > >> > >> Well... the first deliverable I had in the STRAW charter was this: > >> 1) A document defining the requirements for B2BUAs to identify=20 > >> specific features/capabilities support. > >> > >> And what I meant by that was in fact based on=20 > >> draft-holmberg-sipcore-proxy-feature-02. > >=20 > > I didn't realize you meant that linkage. > >=20 > >> I'm not actually sure why proxy-features is in SIPCORE,=20 > but I guess=20 > >> it doesn't matter so I'll remove the deliverable from STRAW. > >=20 > > IMO its in sipcore because as initially presented (with the > > mechanism) it was a core change. > >=20 > > If it turns out that it would be better addressed in a=20 > different WG,=20 > > *I* have no problem handing off responsibility. > > For instance, if the work needs to do some significant work=20 > to define=20 > > what a proxy-feature is, and if that is related to a b2bua-feature. >=20 > Maybe we need to add some wording (separate, or as part of=20 > some of the requirements), which clarifies that we are not=20 > talking about pure proxies, but about entities that act as=20 > proxies (instead of UAs) when they indicate support of features. >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From HKaplan@acmepacket.com Tue Oct 18 07:07:09 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99CF21F8B85 for ; Tue, 18 Oct 2011 07:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfAsKUWEMhxn for ; Tue, 18 Oct 2011 07:07:09 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5F321F8B78 for ; Tue, 18 Oct 2011 07:07:09 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 18 Oct 2011 10:07:07 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Tue, 18 Oct 2011 10:07:07 -0400 From: Hadriel Kaplan To: Christer Holmberg Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMjZ84qi7JUsCxu0OyIMB4JjCd8A== Date: Tue, 18 Oct 2011 14:07:06 +0000 Message-ID: <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 14:07:10 -0000 On Oct 16, 2011, at 9:41 AM, Christer Holmberg wrote: > And, eventhough what Hadriel says is true, SBCs that do topology hiding w= ill have to become more "intelligent", in order not to break services that = rely e.g. on information in the Record-Route headers. That's not realistic. The issue here isn't whether or not SBCs can pass th= rough Record-Route headers, or even be implemented as Proxy-B2BUAs. Of cou= rse they can. In fact, just speaking for my own company's SBCs, I don't ev= en need to change any code or upgrade anything to pass through Record-Route= s - you could configure it to do that right now. The problem is no one in their right mind would do so. SBC's don't remove = Record-Route because they're lazy vendors - on the contrary it would make o= ur lives simpler. SBCs do it because (1) their customers have security gro= ups who demand it, and (2) it makes things work better. > Also, there are services that rely on the fact that the Contact always po= int to the UE. If by that you mean that there are service that rely on knowing the UE's re= al IP Address:port of the Contact, that's not true. I know of only two ven= dors who actually need to know the UE's real IP Address:port, and dozens of= vendors who do not. If instead you mean that they need to know a unique Contact URI per UE, suc= h that they can use it in an out-of-dialog to reach the same UE for example= , that's true but not germane to the issue at hand. (SBC's solve that probl= em without leaking Record-Routes to UE's - the two issues are not related) -hadriel From dworley@avaya.com Tue Oct 18 10:47:01 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0EF21F8B14 for ; Tue, 18 Oct 2011 10:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.946 X-Spam-Level: X-Spam-Status: No, score=-102.946 tagged_above=-999 required=5 tests=[AWL=-0.347, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rDseHXRZSuT for ; Tue, 18 Oct 2011 10:47:00 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id C00E721F8C1E for ; Tue, 18 Oct 2011 10:47:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEIAH66nU7GmAcF/2dsb2JhbABBA6hufgeBdRIoLiMBFSlCJwQbGp5QhA+cBIUGgjRhBJlGjCk X-IronPort-AV: E=Sophos;i="4.69,366,1315195200"; d="scan'208";a="213490681" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 18 Oct 2011 13:46:58 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Oct 2011 13:45:19 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Tue, 18 Oct 2011 13:46:58 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Tue, 18 Oct 2011 13:44:31 -0400 Thread-Topic: Testing the network -- 2070 and 2090 Thread-Index: AQHMjb3uG/JdNovUt0u3wpheBbyylA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] Testing the network -- 2070 and 2090 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 17:47:01 -0000 For better testing of the network, I want to use my scstrial.ca phone on Avaya conference calls. To make dialing these tolerable, I want to forward 2070 to 1-720-356-2070 and 2090 to 1-720-356-2090. 2070 is free, but 2090 is currently assigned to John Dilullo, but he may not be using it, as his phone isn't registered right now. Am I hot or not??? Dale From dworley@avaya.com Tue Oct 18 10:49:09 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DEC21F8C0B for ; Tue, 18 Oct 2011 10:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.376 X-Spam-Level: X-Spam-Status: No, score=-103.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPcOOdlanncS for ; Tue, 18 Oct 2011 10:49:09 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id B139321F8B88 for ; Tue, 18 Oct 2011 10:49:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMIAO+6nU7GmAcF/2dsb2JhbABEqG5+B4FuAQEBAQIBEihECwIBCA0IIRAyJQIEEwgah16bBJwEhzphBJlGjCk X-IronPort-AV: E=Sophos;i="4.69,366,1315195200"; d="scan'208";a="273282956" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 Oct 2011 13:49:06 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Oct 2011 13:47:26 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Tue, 18 Oct 2011 13:49:06 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Tue, 18 Oct 2011 13:48:09 -0400 Thread-Topic: Testing the network -- 2070 and 2090 Thread-Index: AQHMjb3uG/JdNovUt0u3wpheBbyylJWCYLar Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Testing the network -- 2070 and 2090 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 17:49:09 -0000 > From: Worley, Dale R (Dale) [dworley@avaya.com] >=20 > Am I hot or not??? Apparently "not", because I entirely mis-addressed that message. Apologies, Dale From adam@nostrum.com Tue Oct 18 13:42:19 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEFA21F8CA9 for ; Tue, 18 Oct 2011 13:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qU9WX0BCP10c for ; Tue, 18 Oct 2011 13:42:19 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 087BD21F8B54 for ; Tue, 18 Oct 2011 13:42:18 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p9IKgHLo006122 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 18 Oct 2011 15:42:18 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4E9DE4A9.3090705@nostrum.com> Date: Tue, 18 Oct 2011 15:42:17 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <4E57A714.4060107@alum.mit.edu> <22C96E56-B6C8-4482-9A31-5C60525C6622@acmepacket.com> In-Reply-To: <22C96E56-B6C8-4482-9A31-5C60525C6622@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: Re: [sipcore] 202 response in draft-ietf-sipcore-rfc3265bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 20:42:19 -0000 On 8/31/11 9:51 AM, Hadriel Kaplan wrote: > > I recommend that be changed to this, assuming it's correct: > This document does not specify the use of the 202 response code in > conjunction with the SUBSCRIBE or NOTIFY methods. Previous versions > of the SIP Events Framework assigned specific semantics to the 202 > response code. Due to response handling in forking cases, a UAC may > not have received the response as a 202, and thus it could never have > been guaranteed to be received. Furthermore, there was no actual use > difference for the 202 compared to a 200, given a NOTIFY is sent after > the subscription is processed and it conveys the correct state. Since > it was found that implementations were handling 202 differently from 200, > the 202 response is being deprecated to make it clear there is no such > difference and they should not be handled differently. > > Implementations conformant with the current > specification MUST treat an incoming 202 response as identical to a > 200 response, and MUST NOT generate 202 response codes to SUBSCRIBE > or NOTIFY requests. > I like the additional text, and think it's an improvement. I've done a tiny bit of wordsmithing, and have added it to the -04 version of the document. Given that this is the only last call comment received, I'll submit -04 with this change, and ask Paul to request publication shortly. /a From christer.holmberg@ericsson.com Wed Oct 19 03:26:30 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA1221F8A91 for ; Wed, 19 Oct 2011 03:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.427 X-Spam-Level: X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCNgr1eC-tYh for ; Wed, 19 Oct 2011 03:26:30 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id E02B921F8AA8 for ; Wed, 19 Oct 2011 03:26:29 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-50-4e9ea5d405a5 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 97.C8.13753.4D5AE9E4; Wed, 19 Oct 2011 12:26:29 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 19 Oct 2011 12:26:28 +0200 From: Christer Holmberg To: Hadriel Kaplan Date: Wed, 19 Oct 2011 12:26:26 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMjZ84qi7JUsCxu0OyIMB4JjCd8JWDb09Q Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> In-Reply-To: <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 10:26:30 -0000 Hi,=20 >> And, eventhough what Hadriel says is true, SBCs that do=20 >> topology hiding will have to become more "intelligent", in=20 >> order not to break services that rely e.g. on information in=20 >> the Record-Route headers. >=20 > That's not realistic. The issue here isn't whether or not=20 > SBCs can pass through Record-Route headers, or even be=20 > implemented as Proxy-B2BUAs. Of course they can. In fact,=20 > just speaking for my own company's SBCs, I don't even need to=20 > change any code or upgrade anything to pass through=20 > Record-Routes - you could configure it to do that right now. >=20 > The problem is no one in their right mind would do so. SBC's=20 > don't remove Record-Route because they're lazy vendors - on=20 > the contrary it would make our lives simpler. SBCs do it=20 > because (1) their customers have security groups who demand=20 > it, and (2) it makes things work better. Sure. But, assuming that the security requirement is to not provide address infor= mation, the SBC would have to change that part of the Record-Route, but sti= ll pass the capability information - instead of simply removing the whole R= ecord-Route, including information that doesn't need to (or, even shouldn't= , because it would break services) be removed. Of course the SBC (or the one controlling it) can choose to simply remove t= he whole Record-Route, even if it would not be needed, but I don't think we= should have to take that into consideration when working on a protocol mec= hanism for proxy-feature. >> Also, there are services that rely on the fact that the=20 >> Contact always point to the UE. >=20 > If by that you mean that there are service that rely on=20 > knowing the UE's real IP Address:port of the Contact, that's=20 > not true. I know of only two vendors who actually need to=20 > know the UE's real IP Address:port, and dozens of vendors who do not. >=20 > If instead you mean that they need to know a unique Contact=20 > URI per UE, such that they can use it in an out-of-dialog to=20 > reach the same UE for example, that's true but not germane to=20 > the issue at hand. (SBC's solve that problem without leaking=20 > Record-Routes to UE's - the two issues are not related) What I mean is that feature tags in the Contact (no matter whether it conta= ins the real IP address:port of the UE, or some value created by an SBC) de= scribe capabilities of the UE. So, an SBC can not modify the Contact in ord= er to provide information about *its* capabilities. Instead it would provid= e that information in its Record-Route (assuming it would use the draft-hol= mberg mechanism). Regards, Christer From brett@broadsoft.com Wed Oct 19 03:32:14 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4E321F8B45 for ; Wed, 19 Oct 2011 03:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOfv8y6Vt43A for ; Wed, 19 Oct 2011 03:32:13 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.201]) by ietfa.amsl.com (Postfix) with ESMTP id A536321F8AD1 for ; Wed, 19 Oct 2011 03:32:13 -0700 (PDT) Received: from casumhub01.citservers.local (172.16.98.57) by FW01.citservers.local (172.16.98.3) with Microsoft SMTP Server (TLS) id 8.1.436.0; Wed, 19 Oct 2011 03:34:02 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Wed, 19 Oct 2011 03:34:02 -0700 From: Brett Tate To: Adam Roach , "sipcore@ietf.org" Date: Wed, 19 Oct 2011 03:32:10 -0700 Thread-Topic: [sipcore] 202 response in draft-ietf-sipcore-rfc3265bis-03 Thread-Index: AcyN1rJpUIQiBl/sSpKpHiFPbI355QAcyV/w Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C09B1A9B1@EXMBXCLUS01.citservers.local> References: <4E57A714.4060107@alum.mit.edu> <22C96E56-B6C8-4482-9A31-5C60525C6622@acmepacket.com> <4E9DE4A9.3090705@nostrum.com> In-Reply-To: <4E9DE4A9.3090705@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] 202 response in draft-ietf-sipcore-rfc3265bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 10:32:14 -0000 > I like the additional text, and think it's an improvement. I've done a > tiny bit of wordsmithing, and have added it to the -04 version of the > document. >=20 > Given that this is the only last call comment received, I'll submit -04 > with this change, and ask Paul to request publication shortly. You also received the following comments/questions. http://www.ietf.org/mail-archive/web/sipcore/current/msg04264.html Concerning the following draft-ietf-sipcore-rfc3265bis-03 section 4.1.2.2 s= nippet indicating subscriber "MUST consider the subscription terminated", t= he draft should potentially better indicate that the MUST does not preempt = the RFC 5057 notes (such as for 482 and 483) which indicate situations wher= e the dialog would not be terminated. Section 4.1.2.2: "If a SUBSCRIBE request to refresh a subscription receives= a 404, 405, 410, 416, 480-485, 489, 501, or 604 response, the subscriber M= UST consider the subscription terminated. (See [RFC5057] for further detai= ls and notes about the effect of error codes on dialogs and usages within d= ialog, such as subscriptions)." Do the RFC 5057 notes for 482 edge condition still apply? It indicates an = RFC 3263 advancing situation which might trigger a 482 response and allow t= he subscription to remain. If the RFC 5057 notes for 482 edge condition st= ill apply, is it adequately indicated within the above snippet? Thanks, Brett From HKaplan@acmepacket.com Wed Oct 19 08:13:44 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A503421F8C5D for ; Wed, 19 Oct 2011 08:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7d18TTAwJ7Z for ; Wed, 19 Oct 2011 08:13:44 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id F341821F8C1E for ; Wed, 19 Oct 2011 08:13:43 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 19 Oct 2011 11:13:40 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 19 Oct 2011 11:13:41 -0400 From: Hadriel Kaplan To: Christer Holmberg Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMjnGunvPLq4xYOUGRWtY9AbmBqA== Date: Wed, 19 Oct 2011 15:13:39 +0000 Message-ID: <136491ED-390C-4A36-AE7C-06F89170EDFB@acmepacket.com> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 15:13:44 -0000 On Oct 19, 2011, at 6:26 AM, Christer Holmberg wrote: > But, assuming that the security requirement is to not provide address inf= ormation, the SBC would have to change that part of the Record-Route, but s= till pass the capability information - instead of simply removing the whole= Record-Route, including information that doesn't need to (or, even shouldn= 't, because it would break services) be removed. I think we might be viewing this new mechanism in different ways. If this is only about enabling a couple specific features only within a sin= gle 3GPP IMS core, or perhaps even with UEs and only their local 3GPP IMS d= omain, then sure the single IMS operator can try passing through their IMS = core's Record-Routes (encrypted or not, whichever) and seeing if there are = any issues, fixing everything, etc. If, on the other hand, this is a generic mechanism that should work across = domains - including from an Enterprise to their provider through a transit = provider to another provider to another Enterprise, etc. - then what you're= talking about isn't feasible. It's not just about hiding/encrypting the R= ecord-Route URI addresses, it's about making SIP actually work. The proble= m with UDP transport is message size, and especially getting SIP responses = back. And one of the side-effects of removing Record-Routes is you decreas= e the response size and things actually work better. (Some might say it's j= ust delaying the inevitable, but that's another topic=85 :) So no, I don't see this as just a security vs. services decision. I see it= as a service vs. service decision as well. That's not good. Regardless, there is no use-case that seems to actually need to know *which= * particular SIP host supports feature X. There's only the need to know th= at *some* host in the dialog can do X. One could, for example, just put X = into the Supported header, or a header like it. Think about it from a deployment perspective. Lots of B2BUAs "remove" Reco= rd-Routes, not just SBCs. Do you think it's likely that all B2BUAs across = operators be changed to stop removing them so that this new mechanism can w= ork? Or do you think it's more likely that the B2BUAs be changed to allow = just a new header-X or Supported:X through?=20 -hadriel From Internet-Drafts@ietf.org Wed Oct 19 09:16:00 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCA321F86A1; Wed, 19 Oct 2011 09:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ik1CbnYBPo3p; Wed, 19 Oct 2011 09:16:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB5421F8610; Wed, 19 Oct 2011 09:16:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111019161501.12398.25748.idtracker@ietfa.amsl.com> Date: Wed, 19 Oct 2011 09:15:01 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D ACTION:draft-ietf-sipcore-rfc3265bis-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 16:16:00 -0000 --NextPart 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 : SIP-Specific Event Notification Author(s) : A. Roach Filename : draft-ietf-sipcore-rfc3265bis-04.txt Pages : 52 Date : 2011-10-19 This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-rfc3265bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-10-19090529.I-D@ietf.org> --NextPart-- From pkyzivat@alum.mit.edu Wed Oct 19 09:17:27 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1768C21F8CD1 for ; Wed, 19 Oct 2011 09:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz3rVhAVNZNB for ; Wed, 19 Oct 2011 09:17:26 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id 59B1F21F8CD3 for ; Wed, 19 Oct 2011 09:17:26 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta01.westchester.pa.mail.comcast.net with comcast id mfQr1h00627AodY51gHStF; Wed, 19 Oct 2011 16:17:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta19.westchester.pa.mail.comcast.net with comcast id mgHS1h01M0tdiYw3fgHSVP; Wed, 19 Oct 2011 16:17:26 +0000 Message-ID: <4E9EF814.4070908@alum.mit.edu> Date: Wed, 19 Oct 2011 12:17:24 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 16:17:27 -0000 Thanks Christer. This is starting to get at the heart of things. Now, suppose that an SBC wants to hide some R-Rs that contain proxy-features, and it is also going to replace the Contact with a unique of of its own construction. It could conceivably transfer feature tags from the removed R-Rs to its own R-R. That could mean combining feature tags from two or more R-Rs into a single R-R. Does that work for you? What if two different R-Rs had the *same* feature tag, but each with a different value? Or, would it be ok to transfer the feature tags from the removed R-Rs to the new Contact address? (The above is about the mechanism you had proposed, not the requirements. But maybe we need to talk at that level to understand the issues.) Thanks, Paul On 10/19/11 6:26 AM, Christer Holmberg wrote: > > Hi, > >>> And, eventhough what Hadriel says is true, SBCs that do >>> topology hiding will have to become more "intelligent", in >>> order not to break services that rely e.g. on information in >>> the Record-Route headers. >> >> That's not realistic. The issue here isn't whether or not >> SBCs can pass through Record-Route headers, or even be >> implemented as Proxy-B2BUAs. Of course they can. In fact, >> just speaking for my own company's SBCs, I don't even need to >> change any code or upgrade anything to pass through >> Record-Routes - you could configure it to do that right now. >> >> The problem is no one in their right mind would do so. SBC's >> don't remove Record-Route because they're lazy vendors - on >> the contrary it would make our lives simpler. SBCs do it >> because (1) their customers have security groups who demand >> it, and (2) it makes things work better. > > Sure. > > But, assuming that the security requirement is to not provide address information, the SBC would have to change that part of the Record-Route, but still pass the capability information - instead of simply removing the whole Record-Route, including information that doesn't need to (or, even shouldn't, because it would break services) be removed. > > Of course the SBC (or the one controlling it) can choose to simply remove the whole Record-Route, even if it would not be needed, but I don't think we should have to take that into consideration when working on a protocol mechanism for proxy-feature. > >>> Also, there are services that rely on the fact that the >>> Contact always point to the UE. >> >> If by that you mean that there are service that rely on >> knowing the UE's real IP Address:port of the Contact, that's >> not true. I know of only two vendors who actually need to >> know the UE's real IP Address:port, and dozens of vendors who do not. >> >> If instead you mean that they need to know a unique Contact >> URI per UE, such that they can use it in an out-of-dialog to >> reach the same UE for example, that's true but not germane to >> the issue at hand. (SBC's solve that problem without leaking >> Record-Routes to UE's - the two issues are not related) > > What I mean is that feature tags in the Contact (no matter whether it contains the real IP address:port of the UE, or some value created by an SBC) describe capabilities of the UE. So, an SBC can not modify the Contact in order to provide information about *its* capabilities. Instead it would provide that information in its Record-Route (assuming it would use the draft-holmberg mechanism). > > Regards, > > Christer > > From christer.holmberg@ericsson.com Wed Oct 19 10:19:33 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E4D11E80B6 for ; Wed, 19 Oct 2011 10:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.141 X-Spam-Level: X-Spam-Status: No, score=-6.141 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8E18gN6VdGjk for ; Wed, 19 Oct 2011 10:19:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC6821F8BA7 for ; Wed, 19 Oct 2011 10:19:32 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-dc-4e9f06a3786f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D7.FD.20773.3A60F9E4; Wed, 19 Oct 2011 19:19:31 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 19 Oct 2011 19:19:31 +0200 From: Christer Holmberg To: Hadriel Kaplan Date: Wed, 19 Oct 2011 19:19:30 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMjnGunvPLq4xYOUGRWtY9AbmBqJWD5e6k Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F9@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <136491ED-390C-4A36-AE7C-06F89170EDFB@acmepacket.com> In-Reply-To: <136491ED-390C-4A36-AE7C-06F89170EDFB@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 17:19:33 -0000 Hi, >> But, assuming that the security requirement is to not provide address in= formation, the SBC would have to change that part of the Record-Route, but = still pass=20 >> the capability information - instead of simply removing the whole Record= -Route, including information that doesn't need to (or, even shouldn't, bec= ause it=20 >> would break services) be removed. > > I think we might be viewing this new mechanism in different ways. > If this is only about enabling a couple specific features only within a s= ingle 3GPP IMS core, or perhaps even with UEs and only their local 3GPP IMS= domain,=20 > then sure the single IMS operator can try passing through their IMS core'= s Record-Routes (encrypted or not, whichever) and seeing if there are any i= ssues, fixing everything, etc. > > If, on the other hand, this is a generic mechanism that should work acros= s domains - It is. > including from an Enterprise to their provider through a transit provider= to another provider to another Enterprise, etc. - then what you're talking= about isn't feasible.=20 > It's not just about hiding/encrypting the Record-Route URI addresses, it'= s about making SIP actually work. The problem with UDP transport is messag= e size, and=20 > especially getting SIP responses back. And one of the side-effects of re= moving Record-Routes is you decrease the response size and things actually = work better. > (Some might say it's just delaying the inevitable, but that's another top= ic=85 :) I think SIP messages are becomming too big to leave the UAC over UDP to sta= rt with - before any Record-Route has been added :) >So no, I don't see this as just a security vs. services decision. I see i= t as a service vs. service decision as well. >That's not good. > >Regardless, there is no use-case that seems to actually need to know *whic= h* particular SIP host supports feature X. There's only the need to know t= hat *some* host in the dialog can do X. =20 Please see my other reply to Paul. >One could, for example, just put X into the Supported header, or a header = like it. We would need something like Proxy-Supported. >Think about it from a deployment perspective. Lots of B2BUAs "remove" Rec= ord-Routes, not just SBCs. Do you think it's likely that all B2BUAs across= operators be changed to stop >removing them so that this new mechanism can work? Or do you think it's m= ore likely that the B2BUAs be changed to allow just a new header-X or Suppo= rted:X through? To use the words of a person that we both know, representing a big operator= : "SBCs will remove and change whatever we tell them to." :) Seriously, we can always consider a new header field. But, for now I would = like to get the requirements settled, so we can start working on the mechan= ism, and discuss such new header field. Regards, Christer= From christer.holmberg@ericsson.com Wed Oct 19 10:21:22 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167E321F8BF9 for ; Wed, 19 Oct 2011 10:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LTX-z+wdsKA for ; Wed, 19 Oct 2011 10:21:21 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id EDA6921F8BF8 for ; Wed, 19 Oct 2011 10:21:20 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-1b-4e9f070f65af Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A2.3E.20773.F070F9E4; Wed, 19 Oct 2011 19:21:20 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 19 Oct 2011 19:21:19 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Wed, 19 Oct 2011 19:21:18 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AcyOepf4oA202otaSiyFotfU1xeqzgAAb4ST Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> In-Reply-To: <4E9EF814.4070908@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 17:21:22 -0000 Hi, >Thanks Christer. This is starting to get at the heart of things. > >Now, suppose that an SBC wants to hide some R-Rs that contain >proxy-features, and it is also going to replace the Contact with a >unique of of its own construction. > >It could conceivably transfer feature tags from the removed R-Rs to its >own R-R. That could mean combining feature tags from two or more R-Rs >into a single R-R. Does that work for you? It would work in cases where it doesn't matter which proxy provides a featu= re, or how support of features are spread out between different proxies. Fo= r the currently documented (in the drat) use-cases it might work. Havin said that, there is a new 3GPP use-case, which was agreed last week (= it will be described in the next version of the draft), where it is not eno= ugh to indicate that features X and Y are supported by SOME entities in the= network - it must be possible to indicate that features X and Y are suppor= ted by the SAME entity. It doesn't necessarily mean that it must be possibl= e to indicate WHICH entity supports features X and Y, though, just to indic= ate that X and Y are supported by the same entity. So, having a single R-R = header where you just collect and list feature tags taken from multiple R-R= headers would not work. Also, a 3GPP application server can indicate support of services. And, even= though nothing is currently specified, I think that there very likely could= be use-cases where the S-CSCF needs to know WHICH application servers supp= ort specific services, and in which order, e.g. to making routing decission= s etc. >Or, would it be ok to transfer the feature tags from the removed R-Rs to t= he new Contact address? Not in cases where the Contact is assumed to contain capabilities supported= by the UA. Also remember that, based on previous discussions about draft-holmberg, a f= eature tag specification would need to specify what the meaning of a featur= e tag is when used in different header fields, and that meaning could very = well be different for Contact and Record-Route - or the feature tag might n= ot even be specified to be used with Contact. Regards, Christer On 10/19/11 6:26 AM, Christer Holmberg wrote: > > Hi, > >>> And, eventhough what Hadriel says is true, SBCs that do >>> topology hiding will have to become more "intelligent", in >>> order not to break services that rely e.g. on information in >>> the Record-Route headers. >> >> That's not realistic. The issue here isn't whether or not >> SBCs can pass through Record-Route headers, or even be >> implemented as Proxy-B2BUAs. Of course they can. In fact, >> just speaking for my own company's SBCs, I don't even need to >> change any code or upgrade anything to pass through >> Record-Routes - you could configure it to do that right now. >> >> The problem is no one in their right mind would do so. SBC's >> don't remove Record-Route because they're lazy vendors - on >> the contrary it would make our lives simpler. SBCs do it >> because (1) their customers have security groups who demand >> it, and (2) it makes things work better. > > Sure. > > But, assuming that the security requirement is to not provide address inf= ormation, the SBC would have to change that part of the Record-Route, but s= till pass the capability information - instead of simply removing the whole= Record-Route, including information that doesn't need to (or, even shouldn= 't, because it would break services) be removed. > > Of course the SBC (or the one controlling it) can choose to simply remove= the whole Record-Route, even if it would not be needed, but I don't think = we should have to take that into consideration when working on a protocol m= echanism for proxy-feature. > >>> Also, there are services that rely on the fact that the >>> Contact always point to the UE. >> >> If by that you mean that there are service that rely on >> knowing the UE's real IP Address:port of the Contact, that's >> not true. I know of only two vendors who actually need to >> know the UE's real IP Address:port, and dozens of vendors who do not. >> >> If instead you mean that they need to know a unique Contact >> URI per UE, such that they can use it in an out-of-dialog to >> reach the same UE for example, that's true but not germane to >> the issue at hand. (SBC's solve that problem without leaking >> Record-Routes to UE's - the two issues are not related) > > What I mean is that feature tags in the Contact (no matter whether it con= tains the real IP address:port of the UE, or some value created by an SBC) = describe capabilities of the UE. So, an SBC can not modify the Contact in o= rder to provide information about *its* capabilities. Instead it would prov= ide that information in its Record-Route (assuming it would use the draft-h= olmberg mechanism). > > Regards, > > Christer > >= From dworley@avaya.com Wed Oct 19 11:11:13 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C695A21F8C48 for ; Wed, 19 Oct 2011 11:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.3 X-Spam-Level: X-Spam-Status: No, score=-103.3 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbSaKPkQIrDD for ; Wed, 19 Oct 2011 11:11:13 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 2F34921F8C09 for ; Wed, 19 Oct 2011 11:11:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHcRn06HCzI1/2dsb2JhbABEDqhrgQWBbgEBAQECARIoPwULAgEIDQghBQsyJQEBBAENBQgah16aMJtphzphBJlHi1dT X-IronPort-AV: E=Sophos;i="4.69,373,1315195200"; d="scan'208";a="309964305" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 19 Oct 2011 14:11:12 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 19 Oct 2011 14:00:47 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 19 Oct 2011 14:11:11 -0400 From: "Worley, Dale R (Dale)" To: Christer Holmberg , Paul Kyzivat Date: Wed, 19 Oct 2011 14:08:54 -0400 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AcyOepf4oA202otaSiyFotfU1xeqzgAAb4STAAN0/D4= Message-ID: References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 18:11:13 -0000 > From: Christer Holmberg [christer.holmberg@ericsson.com] >=20 > Having said that, there is a new 3GPP use-case, which was agreed last > week (it will be described in the next version of the draft), where it > is not enough to indicate that features X and Y are supported by SOME > entities in the network - it must be possible to indicate that > features X and Y are supported by the SAME entity. It doesn't > necessarily mean that it must be possible to indicate WHICH entity > supports features X and Y, though, just to indicate that X and Y are > supported by the same entity. So, having a single R-R header where you > just collect and list feature tags taken from multiple R-R headers > would not work. But you could define a separate feature designation for the combination. So a proxy could insert the feature designation "pirates", or the designation "ninjas", but if it supported both, it would insert 3 designations, "pirates", "ninjas", and "pirates-and-ninjas-together". > Also, a 3GPP application server can indicate support of services. And, > eventhough nothing is currently specified, I think that there very > likely could be use-cases where the S-CSCF needs to know WHICH > application servers support specific services, and in which order, > e.g. to making routing decissions etc. Yes, that is what we want to see an example of. Dale From christer.holmberg@ericsson.com Wed Oct 19 11:34:12 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F42B11E80AF for ; Wed, 19 Oct 2011 11:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+x25IxkroRN for ; Wed, 19 Oct 2011 11:34:12 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7685611E808F for ; Wed, 19 Oct 2011 11:34:11 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-c5-4e9f181c3f74 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F7.D0.13753.C181F9E4; Wed, 19 Oct 2011 20:34:04 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 19 Oct 2011 20:34:04 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Wed, 19 Oct 2011 20:32:29 +0200 Thread-Topic: [sipcore] Accept in 18x Thread-Index: AcyM1bjmCidcBm22TNybVRrBo/+RcwBt7y7/ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233C3B800@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058522341206CF@ESESSCMS0356.eemea.ericsson.se> <2BC1CD824C2D4F47A6F6EC2705F4F4D803DD4E@Mail1.acmepacket.com> <4E946782.5050508@digium.com>, <7F2072F1E0DE894DA4B517B93C6A05852234120AA4@ESESSCMS0356.eemea.ericsson.se> <4E9748F9.3030404@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C0@ESESSCMS0356.eemea.ericsson.se> <4E9AFDA5.3010402@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE78E@ESESSCMS0356.eemea.ericsson.se>, <4E9C35F9.1020607@alum.mit.edu> In-Reply-To: <4E9C35F9.1020607@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Accept in 18x X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 18:34:12 -0000 Hi, >>>> Do we have text explicitly saying that a Contact received >>>> in a provisional response is valid after 200 OK (unless you >>>> receive a Contact in the 200 OK, of course)? >>> >>> This is a change in subject from the original question. >>> >>> What are you looking for? Valid for *what*? >>> >>> Obviously its impossible to send a PRACK or an UPDATE on an >>> early dialog without having received a contact. In fact, I >>> think we have agreed that you don't have an early dialog >>> unless you got a contact in a provisional. >> >> That's not what I meant. >> >> The question was: if I receive a Contact in a 18x, is the Contact VALUE = also valid after I have received the 200 OK? >> >> Obviously, if it's not, I can't send any in-dialog requests (including t= he ACK) after I've received the 200 OK. > >Well, there should also be a Contact in the 2xx, and typically it would >have the same value as the one in the 1xx for the same dialog. Your >question is only interesting if the two values are different. They could even be different in two different 1xx responses. >IIRC, 3261 specifies that the remote contact address is part of the >dialog state. And the remote contact is allowed to change. So each time >you get a new value it should supersede the prior value in the dialog >state, and then be used for subsequent in-dialog requests. Could we simply say the same thing for Accept - that it is part of the dial= og state? Regards, Christer > Regards, > > Christer > > > >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: 13. lokakuuta 2011 23:24 >>>> To: sipcore@ietf.org >>>> Subject: Re: [sipcore] Accept in 18x >>>> >>>> I'm inclined to agree that this was an error in 3261, and that >>>> Accept-* should be ok in all 1xx responses. >>>> >>>> The argument that the result won't be useful until after a 2xx is >>>> generally negated when reliable provisionals are used. >>>> >>>> On 10/12/11 12:40 AM, DRAGE, Keith (Keith) wrote: >>>>> Its fine saying that, but that means you have to work out >>>> what the semantics are when it is included in a 18x. >>>>> >>>>> A 18x only creates an early dialog. So does sending Accept >>>> in a 18x only apply for an early dialog, or does it apply for the >>>> remainder of the full dialog. >>>> >>>> Well, pretty much everything that is established in an >> early dialog >>>> still holds if the dialog becomes a final one. >>>> >>>> OTOH, the exact scope of applicability of Accept-* is pretty much >>>> undefined. It can change arbitrarily at almost any time. >>>> >>>> IMO it would be good to file an errata on this. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Also note there are other headers specified the same way. >>>> If this understanding applies to Accept, does it also >> apply to other >>>> headers. >>>>> >>>>> >>>>> >>>>> Keith >>>>> >>>>>> -----Original Message----- >>>>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On >>>>>> Behalf Of Worley, Dale R (Dale) >>>>>> Sent: 11 October 2011 21:14 >>>>>> To: Christer Holmberg; Kevin P. Fleming; sipcore@ietf.org >>>>>> Subject: Re: [sipcore] Accept in 18x >>>>>> >>>>>>> From: Christer Holmberg [christer.holmberg@ericsson.com] >>>>>>> >>>>>>> So, if there are no technical reasons, and 3GPP would like to >>>>>>> specify the usage of Accept in a provisional response, would an >>>>>>> errata to 3261 be needed (in order to be alligned with 3261)? >>>>>> >>>>>> It looks like Accept was not specified for 1xx because >>>> there was no >>>>>> practical use for it at the time 3261 was written. >>>>>> >>>>>> As far as I can tell, the only place where 3261 says that Accept >>>>>> isn't allowed in 1xx responses is in the giant table of "which >>>>>> headers are allowed in which messages". But I believe >>>> we've agreed >>>>>> to discontinue the normative status of that table, which >>>> would mean >>>>>> that wouldn't need to amend 3261 to maintain formal compliance. >>>>>> >>>>>> In practice, no UA should malfunction due to the >>>> unexpected presence >>>>>> of Accept in a 1xx response. >>>>>> >>>>>> So it seems to me that 3GPP can go ahead with using >> Accept in 1xx >>>>>> without worrying about updating 3261. >>>>>> >>>>>> Dale >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >> >>= From pkyzivat@alum.mit.edu Wed Oct 19 11:53:52 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196D321F8B77 for ; Wed, 19 Oct 2011 11:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0mwSWF5l1Kh for ; Wed, 19 Oct 2011 11:53:51 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 3381021F8A69 for ; Wed, 19 Oct 2011 11:53:51 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta15.westchester.pa.mail.comcast.net with comcast id mhZY1h0091wpRvQ5FitrNw; Wed, 19 Oct 2011 18:53:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta18.westchester.pa.mail.comcast.net with comcast id mitq1h01x0tdiYw3eitrez; Wed, 19 Oct 2011 18:53:51 +0000 Message-ID: <4E9F1CBD.5020206@alum.mit.edu> Date: Wed, 19 Oct 2011 14:53:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 18:53:52 -0000 The more we ask the more we do tease out unstated requirements. :-) Its important to identify these in order to justify your preferred mechanism over alternatives. Hadriel has raised the issue of middleboxes that attempt to reduce the size of messages to conform to UDP size limits, and the possibility that this would break your preferred mechanism. That is not an issue we normally address - with the expectation that TCP is used to solve that problem. Maybe we will at some point not only start writing specs for how B2BUAs can avoid breaking things, but also how to design new functionality so that it is not broken by B2BUAs. But we aren't really set up to do that now. So if it is to be addressed, it will probably have to be done informally. I won't object to *some* discussion of the issue, but I don't see how we could end up with any normative language about it. Thanks, Paul On 10/19/11 1:21 PM, Christer Holmberg wrote: > Hi, > >> Thanks Christer. This is starting to get at the heart of things. >> >> Now, suppose that an SBC wants to hide some R-Rs that contain >> proxy-features, and it is also going to replace the Contact with a >> unique of of its own construction. >> >> It could conceivably transfer feature tags from the removed R-Rs to its >> own R-R. That could mean combining feature tags from two or more R-Rs >> into a single R-R. Does that work for you? > > It would work in cases where it doesn't matter which proxy provides a feature, or how support of features are spread out between different proxies. For the currently documented (in the drat) use-cases it might work. > > Havin said that, there is a new 3GPP use-case, which was agreed last week (it will be described in the next version of the draft), where it is not enough to indicate that features X and Y are supported by SOME entities in the network - it must be possible to indicate that features X and Y are supported by the SAME entity. It doesn't necessarily mean that it must be possible to indicate WHICH entity supports features X and Y, though, just to indicate that X and Y are supported by the same entity. So, having a single R-R header where you just collect and list feature tags taken from multiple R-R headers would not work. > > Also, a 3GPP application server can indicate support of services. And, eventhough nothing is currently specified, I think that there very likely could be use-cases where the S-CSCF needs to know WHICH application servers support specific services, and in which order, e.g. to making routing decissions etc. > >> Or, would it be ok to transfer the feature tags from the removed R-Rs to the new Contact address? > > Not in cases where the Contact is assumed to contain capabilities supported by the UA. > > Also remember that, based on previous discussions about draft-holmberg, a feature tag specification would need to specify what the meaning of a feature tag is when used in different header fields, and that meaning could very well be different for Contact and Record-Route - or the feature tag might not even be specified to be used with Contact. > > Regards, > > Christer > > > > > On 10/19/11 6:26 AM, Christer Holmberg wrote: >> >> Hi, >> >>>> And, eventhough what Hadriel says is true, SBCs that do >>>> topology hiding will have to become more "intelligent", in >>>> order not to break services that rely e.g. on information in >>>> the Record-Route headers. >>> >>> That's not realistic. The issue here isn't whether or not >>> SBCs can pass through Record-Route headers, or even be >>> implemented as Proxy-B2BUAs. Of course they can. In fact, >>> just speaking for my own company's SBCs, I don't even need to >>> change any code or upgrade anything to pass through >>> Record-Routes - you could configure it to do that right now. >>> >>> The problem is no one in their right mind would do so. SBC's >>> don't remove Record-Route because they're lazy vendors - on >>> the contrary it would make our lives simpler. SBCs do it >>> because (1) their customers have security groups who demand >>> it, and (2) it makes things work better. >> >> Sure. >> >> But, assuming that the security requirement is to not provide address information, the SBC would have to change that part of the Record-Route, but still pass the capability information - instead of simply removing the whole Record-Route, including information that doesn't need to (or, even shouldn't, because it would break services) be removed. >> >> Of course the SBC (or the one controlling it) can choose to simply remove the whole Record-Route, even if it would not be needed, but I don't think we should have to take that into consideration when working on a protocol mechanism for proxy-feature. >> >>>> Also, there are services that rely on the fact that the >>>> Contact always point to the UE. >>> >>> If by that you mean that there are service that rely on >>> knowing the UE's real IP Address:port of the Contact, that's >>> not true. I know of only two vendors who actually need to >>> know the UE's real IP Address:port, and dozens of vendors who do not. >>> >>> If instead you mean that they need to know a unique Contact >>> URI per UE, such that they can use it in an out-of-dialog to >>> reach the same UE for example, that's true but not germane to >>> the issue at hand. (SBC's solve that problem without leaking >>> Record-Routes to UE's - the two issues are not related) >> >> What I mean is that feature tags in the Contact (no matter whether it contains the real IP address:port of the UE, or some value created by an SBC) describe capabilities of the UE. So, an SBC can not modify the Contact in order to provide information about *its* capabilities. Instead it would provide that information in its Record-Route (assuming it would use the draft-holmberg mechanism). >> >> Regards, >> >> Christer >> >> From pkyzivat@alum.mit.edu Wed Oct 19 12:01:51 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC3921F85B9 for ; Wed, 19 Oct 2011 12:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlV7YcJK7Jzn for ; Wed, 19 Oct 2011 12:01:51 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id D877421F8C09 for ; Wed, 19 Oct 2011 12:01:50 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta13.westchester.pa.mail.comcast.net with comcast id mj1i1h0020mv7h05Dj1il3; Wed, 19 Oct 2011 19:01:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta11.westchester.pa.mail.comcast.net with comcast id mj1h1h01q0tdiYw3Xj1hCD; Wed, 19 Oct 2011 19:01:42 +0000 Message-ID: <4E9F1E93.50102@alum.mit.edu> Date: Wed, 19 Oct 2011 15:01:39 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A058522341206CF@ESESSCMS0356.eemea.ericsson.se> <2BC1CD824C2D4F47A6F6EC2705F4F4D803DD4E@Mail1.acmepacket.com> <4E946782.5050508@digium.com>, <7F2072F1E0DE894DA4B517B93C6A05852234120AA4@ESESSCMS0356.eemea.ericsson.se> <4E9748F9.3030404@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C0@ESESSCMS0356.eemea.ericsson.se> <4E9AFDA5.3010402@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE78E@ESESSCMS0356.eemea.ericsson.se>, <4E9C35F9.1020607@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B800@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233C3B800@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Accept in 18x X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 19:01:51 -0000 Comment at end On 10/19/11 2:32 PM, Christer Holmberg wrote: > Hi, > >>>>> Do we have text explicitly saying that a Contact received >>>>> in a provisional response is valid after 200 OK (unless you >>>>> receive a Contact in the 200 OK, of course)? >>>> >>>> This is a change in subject from the original question. >>>> >>>> What are you looking for? Valid for *what*? >>>> >>>> Obviously its impossible to send a PRACK or an UPDATE on an >>>> early dialog without having received a contact. In fact, I >>>> think we have agreed that you don't have an early dialog >>>> unless you got a contact in a provisional. >>> >>> That's not what I meant. >>> >>> The question was: if I receive a Contact in a 18x, is the Contact VALUE also valid after I have received the 200 OK? >>> >>> Obviously, if it's not, I can't send any in-dialog requests (including the ACK) after I've received the 200 OK. >> >> Well, there should also be a Contact in the 2xx, and typically it would >> have the same value as the one in the 1xx for the same dialog. Your >> question is only interesting if the two values are different. > > They could even be different in two different 1xx responses. > >> IIRC, 3261 specifies that the remote contact address is part of the >> dialog state. And the remote contact is allowed to change. So each time >> you get a new value it should supersede the prior value in the dialog >> state, and then be used for subsequent in-dialog requests. > > Could we simply say the same thing for Accept - that it is part of the dialog state? There is no such requirement now, so that would be a change that isn't backward compatible. Accept, and its definition, was inherited from HTTP. In HTTP I believe the scope of validity of ACCEPT is limited to the response to the message. In the past I have commented that we have a number of properties such as this whose scope is not well defined. In general I think you must treat these as *hints*, while being prepared to discover that they subsequently cease to be valid. Like many things, its hard for a 3pcc controller to assure the preservation of such state on one of its dialogs, because there may be a transfer on the "other side" to a device with different properties. Thanks, Paul From HKaplan@acmepacket.com Wed Oct 19 14:02:39 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1551F0C4D for ; Wed, 19 Oct 2011 14:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjDQeJCB9lte for ; Wed, 19 Oct 2011 14:02:35 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9D11F0C4B for ; Wed, 19 Oct 2011 14:02:35 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 19 Oct 2011 17:02:33 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 19 Oct 2011 17:02:33 -0400 From: Hadriel Kaplan To: Christer Holmberg Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMjqJrTJ4dal/J3E6UBxTqp/RbhQ== Date: Wed, 19 Oct 2011 21:02:33 +0000 Message-ID: <8059C2A7-49EB-40FF-B3C5-6037EB81403C@acmepacket.com> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <136491ED-390C-4A36-AE7C-06F89170EDFB@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F9@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F9@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="Windows-1252" Content-ID: <88541635A83BC3429563ABD8D02545D4@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 21:02:39 -0000 On Oct 19, 2011, at 1:19 PM, Christer Holmberg wrote: >> One could, for example, just put X into the Supported header, or a heade= r like it. >=20 > We would need something like Proxy-Supported. They're NOT proxies, but ya the name doesn't matter much. =20 How about "Feature-Caps"? Too obvious? :) > To use the words of a person that we both know, representing a big operat= or: "SBCs will remove and change whatever we tell them to." :) Of course, and then we'll listen to their Ops folks when they call support = with problem tickets. I'd rather avoid that last part. I see too much Wir= eshark as is. Mucking with Record-Route is like playing with fire. Its kinda like your "Target" URI header idea a few years ago. It may not b= e as all-encompassing as History-Info or as elegant as JDR's loose-route, b= ut it would have been easier to implement, safer, and faster. -hadriel From HKaplan@acmepacket.com Wed Oct 19 14:02:53 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189471F0C56 for ; Wed, 19 Oct 2011 14:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.804 X-Spam-Level: X-Spam-Status: No, score=-1.804 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_33=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wjz6aoGa3-PL for ; Wed, 19 Oct 2011 14:02:52 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 80C2B1F0C55 for ; Wed, 19 Oct 2011 14:02:52 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 19 Oct 2011 17:02:51 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Wed, 19 Oct 2011 17:02:51 -0400 From: Hadriel Kaplan To: Christer Holmberg Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMjqJ2TJ4dal/J3E6UBxTqp/RbhQ== Date: Wed, 19 Oct 2011 21:02:51 +0000 Message-ID: References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 21:02:53 -0000 On Oct 19, 2011, at 1:21 PM, Christer Holmberg wrote: > Havin said that, there is a new 3GPP use-case, which was agreed last week= (it will be described in the next version of the draft), where it is not e= nough to indicate that features X and Y are supported by SOME entities in t= he network - it must be possible to indicate that features X and Y are supp= orted by the SAME entity. It doesn't necessarily mean that it must be possi= ble to indicate WHICH entity supports features X and Y, though, just to ind= icate that X and Y are supported by the same entity. So, having a single R-= R header where you just collect and list feature tags taken from multiple R= -R headers would not work. That's easy=85 Feature-Caps: foo, bar, foo+bar >=20 > Also, a 3GPP application server can indicate support of services. And, ev= enthough nothing is currently specified, I think that there very likely cou= ld be use-cases where the S-CSCF needs to know WHICH application servers su= pport specific services, and in which order, e.g. to making routing decissi= ons etc. OK, then why would we want to indicate that in a header used for dialog rou= te-sets? Record-Route has a very specific purpose, to be used for the in-dialog rout= e-set. And despite all examples in RFCs to the contrary, its URI is freque= ntly an IP:host rather than a hostname. That's probably because devices wa= nt in-dialog requests coming in on the same instance/blade/interface that c= reated the dialog, for a bunch of reasons. But a feature capability, espec= ially one that would be useful for routing to for all-time, doesn't necessa= rily have that property. I.e., it's just as likely you'd want to indicate = your whole App-Server system/cluster can do that feature, rather than the p= articular interface you're using for in-dialog request routing. As an aside, one wonders how we got along for so many years with just Suppo= rted/Required/Proxy-Require option tags which did not need to identify whic= h particular URI supported the option. ;) -hadriel From adam@nostrum.com Wed Oct 19 15:16:06 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDA811E8096 for ; Wed, 19 Oct 2011 15:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3ujLK5F-mYh for ; Wed, 19 Oct 2011 15:16:05 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A0D3F21F8586 for ; Wed, 19 Oct 2011 15:16:05 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p9JMG2MN000102 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 19 Oct 2011 17:16:03 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4E9F4C22.5060401@nostrum.com> Date: Wed, 19 Oct 2011 17:16:02 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Brett Tate References: <4E57A714.4060107@alum.mit.edu> <22C96E56-B6C8-4482-9A31-5C60525C6622@acmepacket.com> <4E9DE4A9.3090705@nostrum.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C09B1A9B1@EXMBXCLUS01.citservers.local> In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C09B1A9B1@EXMBXCLUS01.citservers.local> Content-Type: multipart/alternative; boundary="------------070600050308080402050603" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] 202 response in draft-ietf-sipcore-rfc3265bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 22:16:06 -0000 This is a multi-part message in MIME format. --------------070600050308080402050603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/19/11 5:32 AM, Brett Tate wrote: >> I like the additional text, and think it's an improvement. I've done a >> tiny bit of wordsmithing, and have added it to the -04 version of the >> document. >> >> Given that this is the only last call comment received, I'll submit -04 >> with this change, and ask Paul to request publication shortly. > You also received the following comments/questions. Sorry! I missed this when I searched through the archives. > > http://www.ietf.org/mail-archive/web/sipcore/current/msg04264.html > > Concerning the following draft-ietf-sipcore-rfc3265bis-03 section 4.1.2.2 snippet indicating subscriber "MUST consider the subscription terminated", the draft should potentially better indicate that the MUST does not preempt the RFC 5057 notes (such as for 482 and 483) which indicate situations where the dialog would not be terminated. I guess they do apply, so we probably ought to give them some consideration. I'd hate to reiterate all the relevant notes in this document, since most of them are pretty baroque, and would only serve to confuse the topic under discussion. How about: If a SUBSCRIBE request to refresh a subscription receives a 404, 405, 410, 416, 480-485, 489, 501, or 604 response, the subscriber MUST consider the subscription terminated unless extenuating circumstances exist that would otherwise keep the dialog alive. See [RFC5057 ] for further details and notes about the effect of error codes on dialogs and usages within dialog, such as subscriptions. /a --------------070600050308080402050603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/19/11 5:32 AM, Brett Tate wrote: 
I like the additional text, and think it's an improvement. I've done a
tiny bit of wordsmithing, and have added it to the -04 version of the
document.

Given that this is the only last call comment received, I'll submit -04
with this change, and ask Paul to request publication shortly.

You also received the following comments/questions.

Sorry! I missed this when I searched through the archives.


http://www.ietf.org/mail-archive/web/sipcore/current/msg04264.html

Concerning the following draft-ietf-sipcore-rfc3265bis-03 section 4.1.2.2 snippet indicating subscriber "MUST consider the subscription terminated", the draft should potentially better indicate that the MUST does not preempt the RFC 5057 notes (such as for 482 and 483) which indicate situations where the dialog would not be terminated.

I guess they do apply, so we probably ought to give them some consideration. I'd hate to reiterate all the relevant notes in this document, since most of them are pretty baroque, and would only serve to confuse the topic under discussion. How about:

   If a SUBSCRIBE request to refresh a subscription receives a 404, 405,
   410, 416, 480-485, 489, 501, or 604 response, the subscriber MUST
   consider the subscription terminated unless extenuating circumstances
   exist that would otherwise keep the dialog alive. See [RFC5057] for
   further details and notes about the effect of error codes on dialogs
   and usages within dialog, such as subscriptions.

/a
--------------070600050308080402050603-- From keith.drage@alcatel-lucent.com Wed Oct 19 16:52:28 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EC921F845A for ; Wed, 19 Oct 2011 16:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.849 X-Spam-Level: X-Spam-Status: No, score=-105.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdMD34cbsx22 for ; Wed, 19 Oct 2011 16:52:28 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id B873121F844D for ; Wed, 19 Oct 2011 16:52:27 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p9JNqMCZ032767 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Oct 2011 01:52:22 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 20 Oct 2011 01:52:22 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , Christer Holmberg Date: Thu, 20 Oct 2011 01:52:18 +0200 Thread-Topic: [sipcore] Accept in 18x Thread-Index: AcyOkZZMEmCWdeBnRV+f5tRRBdBa9wAKFQiQ Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A058522341206CF@ESESSCMS0356.eemea.ericsson.se> <2BC1CD824C2D4F47A6F6EC2705F4F4D803DD4E@Mail1.acmepacket.com> <4E946782.5050508@digium.com>, <7F2072F1E0DE894DA4B517B93C6A05852234120AA4@ESESSCMS0356.eemea.ericsson.se> <4E9748F9.3030404@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C0@ESESSCMS0356.eemea.ericsson.se> <4E9AFDA5.3010402@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE78E@ESESSCMS0356.eemea.ericsson.se>, <4E9C35F9.1020607@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B800@ESESSCMS0356.eemea.ericsson.se> <4E9F1E93.50102@alum.mit.edu> In-Reply-To: <4E9F1E93.50102@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Accept in 18x X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 23:52:28 -0000 I am fast coming to the conclusion that rather than an errata, this issue w= ould be best dealt with by a quick internet draft. I see it not as intended= original functionality that somehow failed to get documented, but more as = an extension. An i-d would help us sort out what the procedures are really meant to be. Keith > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Paul Kyzivat > Sent: 19 October 2011 20:02 > To: Christer Holmberg > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Accept in 18x >=20 > Comment at end >=20 > On 10/19/11 2:32 PM, Christer Holmberg wrote: > > Hi, > > > >>>>> Do we have text explicitly saying that a Contact received > >>>>> in a provisional response is valid after 200 OK (unless you > >>>>> receive a Contact in the 200 OK, of course)? > >>>> > >>>> This is a change in subject from the original question. > >>>> > >>>> What are you looking for? Valid for *what*? > >>>> > >>>> Obviously its impossible to send a PRACK or an UPDATE on an > >>>> early dialog without having received a contact. In fact, I > >>>> think we have agreed that you don't have an early dialog > >>>> unless you got a contact in a provisional. > >>> > >>> That's not what I meant. > >>> > >>> The question was: if I receive a Contact in a 18x, is the Contact > VALUE also valid after I have received the 200 OK? > >>> > >>> Obviously, if it's not, I can't send any in-dialog requests (includin= g > the ACK) after I've received the 200 OK. > >> > >> Well, there should also be a Contact in the 2xx, and typically it woul= d > >> have the same value as the one in the 1xx for the same dialog. Your > >> question is only interesting if the two values are different. > > > > They could even be different in two different 1xx responses. > > > >> IIRC, 3261 specifies that the remote contact address is part of the > >> dialog state. And the remote contact is allowed to change. So each tim= e > >> you get a new value it should supersede the prior value in the dialog > >> state, and then be used for subsequent in-dialog requests. > > > > Could we simply say the same thing for Accept - that it is part of the > dialog state? >=20 > There is no such requirement now, so that would be a change that isn't > backward compatible. >=20 > Accept, and its definition, was inherited from HTTP. In HTTP I believe > the scope of validity of ACCEPT is limited to the response to the message= . >=20 > In the past I have commented that we have a number of properties such as > this whose scope is not well defined. In general I think you must treat > these as *hints*, while being prepared to discover that they > subsequently cease to be valid. >=20 > Like many things, its hard for a 3pcc controller to assure the > preservation of such state on one of its dialogs, because there may be a > transfer on the "other side" to a device with different properties. >=20 > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Thu Oct 20 05:07:30 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1AF921F8AF9 for ; Thu, 20 Oct 2011 05:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.824 X-Spam-Level: X-Spam-Status: No, score=-5.824 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im4IaeLNj48P for ; Thu, 20 Oct 2011 05:07:30 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C8AFF21F8AF0 for ; Thu, 20 Oct 2011 05:07:29 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-36-4ea00f000b21 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C9.46.20773.00F00AE4; Thu, 20 Oct 2011 14:07:28 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 20 Oct 2011 14:07:27 +0200 From: Christer Holmberg To: Hadriel Kaplan Date: Thu, 20 Oct 2011 14:07:26 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMjqJ2TJ4dal/J3E6UBxTqp/RbhZWFGchA Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 12:07:30 -0000 Hi, >>> One could, for example, just put X into the Supported header, or a head= er like it. >>=20 >> We would need something like Proxy-Supported. > > They're NOT proxies, but ya the name doesn't matter much. =20 > How about "Feature-Caps"? Too obvious? :) I would be ok with that :) >> Havin said that, there is a new 3GPP use-case, which was=20 >> agreed last week (it will be described in the next version of=20 >> the draft), where it is not enough to indicate that features=20 >> X and Y are supported by SOME entities in the network - it=20 >> must be possible to indicate that features X and Y are=20 >> supported by the SAME entity. It doesn't necessarily mean=20 >> that it must be possible to indicate WHICH entity supports=20 >> features X and Y, though, just to indicate that X and Y are=20 >> supported by the same entity. So, having a single R-R header=20 >> where you just collect and list feature tags taken from=20 >> multiple R-R headers would not work. >=20 >=20 > That's easy... > Feature-Caps: foo, bar, foo+bar Correct. The key is being able to use '+', in order to show that features a= re supported by the same entity. >> Also, a 3GPP application server can indicate support of=20 >> services. And, eventhough nothing is currently specified, I=20 >> think that there very likely could be use-cases where the=20 >> S-CSCF needs to know WHICH application servers support=20 >> specific services, and in which order, e.g. to making routing=20 >> decissions etc. >=20 > OK, then why would we want to indicate that in a header used=20 > for dialog route-sets? > > Record-Route has a very specific purpose, to be used for the=20 > in-dialog route-set. And despite all examples in RFCs to the=20 > contrary, its URI is frequently an IP:host rather than a=20 > hostname. That's probably because devices want in-dialog=20 > requests coming in on the same instance/blade/interface that=20 > created the dialog, for a bunch of reasons. But a feature=20 > capability, especially one that would be useful for routing=20 > to for all-time, doesn't necessarily have that property. =20 > > I.e., it's just as likely you'd want to indicate your whole=20 > App-Server system/cluster can do that feature, rather than=20 > the particular interface you're using for in-dialog request routing. In the current use-cases, when the feature support is indicated in INVITE/R= ecord-Route, the support only applies to the specific session established. = Ie it is NOT a generic capability support indication. But, as we have discussed before, the feature tag definition needs to defin= e the scope when support of a feature is indicated in INVITE, REGSTER etc. Regards, Christer From christer.holmberg@ericsson.com Thu Oct 20 05:08:08 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492E421F8B29 for ; Thu, 20 Oct 2011 05:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.395 X-Spam-Level: X-Spam-Status: No, score=-6.395 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpse2oWc+jlR for ; Thu, 20 Oct 2011 05:08:07 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1849421F8B18 for ; Thu, 20 Oct 2011 05:08:06 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-84-4ea00f25d026 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7E.72.13753.52F00AE4; Thu, 20 Oct 2011 14:08:05 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 20 Oct 2011 14:08:05 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Thu, 20 Oct 2011 14:08:03 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AcyOkHGZ16f3OJGiQ2ar+9vsljmfIQAigJkw Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522341F50AC@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <4E9F1CBD.5020206@alum.mit.edu> In-Reply-To: <4E9F1CBD.5020206@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 12:08:08 -0000 Hi,=20 > The more we ask the more we do tease out unstated requirements. :-) >=20 > Its important to identify these in order to justify your=20 > preferred mechanism over alternatives. I am not trying to justify the usage of Record-Route (if that's what you me= an by 'preferred mechanism').=20 I am fine e.g. using a new header field (if that's what you mean by 'altern= atives'), if people prefer that :) Regards, Christer > On 10/19/11 1:21 PM, Christer Holmberg wrote: > > Hi, > > > >> Thanks Christer. This is starting to get at the heart of things. > >> > >> Now, suppose that an SBC wants to hide some R-Rs that contain=20 > >> proxy-features, and it is also going to replace the Contact with a=20 > >> unique of of its own construction. > >> > >> It could conceivably transfer feature tags from the=20 > removed R-Rs to=20 > >> its own R-R. That could mean combining feature tags from=20 > two or more=20 > >> R-Rs into a single R-R. Does that work for you? > > > > It would work in cases where it doesn't matter which proxy=20 > provides a feature, or how support of features are spread out=20 > between different proxies. For the currently documented (in=20 > the drat) use-cases it might work. > > > > Havin said that, there is a new 3GPP use-case, which was=20 > agreed last week (it will be described in the next version of=20 > the draft), where it is not enough to indicate that features=20 > X and Y are supported by SOME entities in the network - it=20 > must be possible to indicate that features X and Y are=20 > supported by the SAME entity. It doesn't necessarily mean=20 > that it must be possible to indicate WHICH entity supports=20 > features X and Y, though, just to indicate that X and Y are=20 > supported by the same entity. So, having a single R-R header=20 > where you just collect and list feature tags taken from=20 > multiple R-R headers would not work. > > > > Also, a 3GPP application server can indicate support of=20 > services. And, eventhough nothing is currently specified, I=20 > think that there very likely could be use-cases where the=20 > S-CSCF needs to know WHICH application servers support=20 > specific services, and in which order, e.g. to making routing=20 > decissions etc. > > > >> Or, would it be ok to transfer the feature tags from the=20 > removed R-Rs to the new Contact address? > > > > Not in cases where the Contact is assumed to contain=20 > capabilities supported by the UA. > > > > Also remember that, based on previous discussions about=20 > draft-holmberg, a feature tag specification would need to=20 > specify what the meaning of a feature tag is when used in=20 > different header fields, and that meaning could very well be=20 > different for Contact and Record-Route - or the feature tag=20 > might not even be specified to be used with Contact. > > > > Regards, > > > > Christer > > > > > > > > > > On 10/19/11 6:26 AM, Christer Holmberg wrote: > >> > >> Hi, > >> > >>>> And, eventhough what Hadriel says is true, SBCs that do topology=20 > >>>> hiding will have to become more "intelligent", in order not to=20 > >>>> break services that rely e.g. on information in the Record-Route=20 > >>>> headers. > >>> > >>> That's not realistic. The issue here isn't whether or=20 > not SBCs can=20 > >>> pass through Record-Route headers, or even be implemented as=20 > >>> Proxy-B2BUAs. Of course they can. In fact, just speaking for my=20 > >>> own company's SBCs, I don't even need to change any code=20 > or upgrade=20 > >>> anything to pass through Record-Routes - you could=20 > configure it to=20 > >>> do that right now. > >>> > >>> The problem is no one in their right mind would do so. =20 > SBC's don't=20 > >>> remove Record-Route because they're lazy vendors - on the=20 > contrary=20 > >>> it would make our lives simpler. SBCs do it because (1) their=20 > >>> customers have security groups who demand it, and (2) it makes=20 > >>> things work better. > >> > >> Sure. > >> > >> But, assuming that the security requirement is to not=20 > provide address information, the SBC would have to change=20 > that part of the Record-Route, but still pass the capability=20 > information - instead of simply removing the whole=20 > Record-Route, including information that doesn't need to (or,=20 > even shouldn't, because it would break services) be removed. > >> > >> Of course the SBC (or the one controlling it) can choose=20 > to simply remove the whole Record-Route, even if it would not=20 > be needed, but I don't think we should have to take that into=20 > consideration when working on a protocol mechanism for proxy-feature. > >> > >>>> Also, there are services that rely on the fact that the Contact=20 > >>>> always point to the UE. > >>> > >>> If by that you mean that there are service that rely on=20 > knowing the=20 > >>> UE's real IP Address:port of the Contact, that's not=20 > true. I know=20 > >>> of only two vendors who actually need to know the UE's real IP=20 > >>> Address:port, and dozens of vendors who do not. > >>> > >>> If instead you mean that they need to know a unique=20 > Contact URI per=20 > >>> UE, such that they can use it in an out-of-dialog to=20 > reach the same=20 > >>> UE for example, that's true but not germane to the issue at hand.=20 > >>> (SBC's solve that problem without leaking Record-Routes to UE's -=20 > >>> the two issues are not related) > >> > >> What I mean is that feature tags in the Contact (no matter=20 > whether it contains the real IP address:port of the UE, or=20 > some value created by an SBC) describe capabilities of the=20 > UE. So, an SBC can not modify the Contact in order to provide=20 > information about *its* capabilities. Instead it would=20 > provide that information in its Record-Route (assuming it=20 > would use the draft-holmberg mechanism). > >> > >> Regards, > >> > >> Christer > >> > >> >=20 > = From brett@broadsoft.com Thu Oct 20 06:24:26 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBBC21F8B91 for ; Thu, 20 Oct 2011 06:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OJ3jinSPyJ5 for ; Thu, 20 Oct 2011 06:24:22 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpedge01.chinookhosting.com [173.225.22.201]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB4521F8B8F for ; Thu, 20 Oct 2011 06:24:13 -0700 (PDT) Received: from casumhub01.citservers.local (172.16.98.57) by FW01.citservers.local (172.16.98.3) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 20 Oct 2011 06:25:39 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Thu, 20 Oct 2011 06:25:39 -0700 From: Brett Tate To: Adam Roach Date: Thu, 20 Oct 2011 06:23:45 -0700 Thread-Topic: [sipcore] 202 response in draft-ietf-sipcore-rfc3265bis-03 Thread-Index: AcyOrPRqCKxXKwGZRRaF2NvCGmcgHgAfYvUQ Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C10043134@EXMBXCLUS01.citservers.local> References: <4E57A714.4060107@alum.mit.edu> <22C96E56-B6C8-4482-9A31-5C60525C6622@acmepacket.com> <4E9DE4A9.3090705@nostrum.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C09B1A9B1@EXMBXCLUS01.citservers.local> <4E9F4C22.5060401@nostrum.com> In-Reply-To: <4E9F4C22.5060401@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7FF1E5E16911C54BB2D57D4C4A2ED35A0C10043134EXMBXCLUS01ci_" MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] 202 response in draft-ietf-sipcore-rfc3265bis-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 13:24:26 -0000 --_000_7FF1E5E16911C54BB2D57D4C4A2ED35A0C10043134EXMBXCLUS01ci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The proposed change addresses my concern and questions. Thanks, Brett From: Adam Roach [mailto:adam@nostrum.com] Sent: Wednesday, October 19, 2011 6:16 PM To: Brett Tate Cc: sipcore@ietf.org Subject: Re: [sipcore] 202 response in draft-ietf-sipcore-rfc3265bis-03 On 10/19/11 5:32 AM, Brett Tate wrote: I like the additional text, and think it's an improvement. I've done a tiny bit of wordsmithing, and have added it to the -04 version of the document. Given that this is the only last call comment received, I'll submit -04 with this change, and ask Paul to request publication shortly. You also received the following comments/questions. Sorry! I missed this when I searched through the archives. http://www.ietf.org/mail-archive/web/sipcore/current/msg04264.html Concerning the following draft-ietf-sipcore-rfc3265bis-03 section 4.1.2.2 s= nippet indicating subscriber "MUST consider the subscription terminated", t= he draft should potentially better indicate that the MUST does not preempt = the RFC 5057 notes (such as for 482 and 483) which indicate situations wher= e the dialog would not be terminated. I guess they do apply, so we probably ought to give them some consideration= . I'd hate to reiterate all the relevant notes in this document, since most= of them are pretty baroque, and would only serve to confuse the topic unde= r discussion. How about: If a SUBSCRIBE request to refresh a subscription receives a 404, 405, 410, 416, 480-485, 489, 501, or 604 response, the subscriber MUST consider the subscription terminated unless extenuating circumstances exist that would otherwise keep the dialog alive. See [RFC5057] for further details and notes about the effect of error codes on dialogs and usages within dialog, such as subscriptions. /a --_000_7FF1E5E16911C54BB2D57D4C4A2ED35A0C10043134EXMBXCLUS01ci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= The proposed change addresses my concern and questions.

 

Thanks,

Brett

 <= /span>

From: Adam Roach [mailto:adam@nostrum.com]
Sent: Wednes= day, October 19, 2011 6:16 PM
To: Brett Tate
Cc: sipcor= e@ietf.org
Subject: Re: [sipcore] 202 response in draft-ietf-sipc= ore-rfc3265bis-03

 

On 10/19/11 5:32 AM, Brett Tate wrot= e: 

I like the additional text, and think it's an improvement. I've done=
 a
tiny bit of wordsmithing, and have added it to the =
-04 version of the
document.
 
Given that this is the only last call comment recei=
ved, I'll submit -04
with this change, and ask Paul to=
 request publication shortly.
 =

You also received the following comments/questions.


Sorry! I missed this when I searched thr= ough the archives.


 
 
http://www.ietf.org/mail-archive/web/sip=
core/current/msg04264.html
 
= 
Concerning the following draft-ietf-sipcore-rfc3265bis-03 section 4.1.=
2.2 snippet indicating subscriber "MUST consider the subscription term=
inated", the draft should potentially better indicate that the MUST do=
es not preempt the RFC 5057 notes (such as for 482 and 483) which indicate =
situations where the dialog would not be terminated.


I guess they do apply, so= we probably ought to give them some consideration. I'd hate to reiterate a= ll the relevant notes in this document, since most of them are pretty baroq= ue, and would only serve to confuse the topic under discussion. How about:<= o:p>

   If a SUBSCRIBE request to refresh a subscri=
ption receives a 404, 405,
   410, 416, 480-=
485, 489, 501, or 604 response, the subscriber MUST
&n=
bsp;  consider the subscription terminated unless extenuating circumst=
ances
   exist that would otherwise keep the=
 dialog alive. See [RFC=
5057] for
   further details and notes a=
bout the effect of error codes on dialogs
  =
 and usages within dialog, such as subscriptions.


/a

= --_000_7FF1E5E16911C54BB2D57D4C4A2ED35A0C10043134EXMBXCLUS01ci_-- From oej@edvina.net Thu Oct 20 07:23:00 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C56621F8BA7 for ; Thu, 20 Oct 2011 07:22:59 -0700 (PDT) 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=[AWL=0.698, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDMuQ7PFZCne for ; Thu, 20 Oct 2011 07:22:59 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id BD31F21F8BEC for ; Thu, 20 Oct 2011 07:22:58 -0700 (PDT) Received: from [192.168.20.63] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp7.webway.se (Postfix) with ESMTPA id F2932754BCD5; Thu, 20 Oct 2011 14:22:53 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Oct 2011 16:22:55 +0200 To: " SIPCORE" Message-Id: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:23:00 -0000 Hi! Coming in rather late in the discussion, I don't know if I missed the = topic of security. Having read RFC 3265 and some of the event specs, like mwi and dialog, = the security sections lack a lot and in some cases are texts that are = impossible for a developer to create running code from. I think we need to write better text in 3265 biz for developers of event = packages to clarify requirements. Like * If you specify TLS usage, be very clear on certificate matching * If you specify S/MIME, be very clear on certificate matching and usage Also, require some message flows. One of these, I don't remember which one, requires S/MIME for = confidentiality without specifying anything else. If I need to encrypt, how do I get the presence server certificate? Or = does the presence server need the keys for the target URI? Just a few thoughts, but I may be too late. /O= From pkyzivat@alum.mit.edu Thu Oct 20 07:44:10 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2851921F8BA8 for ; Thu, 20 Oct 2011 07:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Rjvltl7RBlp for ; Thu, 20 Oct 2011 07:44:09 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id F174421F8B98 for ; Thu, 20 Oct 2011 07:44:08 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id n10k1h0011c6gX8532k7rR; Thu, 20 Oct 2011 14:44:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta23.westchester.pa.mail.comcast.net with comcast id n2k61h00Z0tdiYw3j2k6U9; Thu, 20 Oct 2011 14:44:07 +0000 Message-ID: <4EA033B3.1030705@alum.mit.edu> Date: Thu, 20 Oct 2011 10:44:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <7F2072F1E0DE894DA4B517B93C6A058522341206CF@ESESSCMS0356.eemea.ericsson.se> <2BC1CD824C2D4F47A6F6EC2705F4F4D803DD4E@Mail1.acmepacket.com> <4E946782.5050508@digium.com>, <7F2072F1E0DE894DA4B517B93C6A05852234120AA4@ESESSCMS0356.eemea.ericsson.se> <4E9748F9.3030404@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C0@ESESSCMS0356.eemea.ericsson.se> <4E9AFDA5.3010402@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE78E@ESESSCMS0356.eemea.ericsson.se>, <4E9C35F9.1020607@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B800@ESESSCMS0356.eemea.ericsson.se> <4E9F1E93.50102@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Accept in 18x X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:44:10 -0000 On 10/19/11 7:52 PM, DRAGE, Keith (Keith) wrote: > I am fast coming to the conclusion that rather than an errata, this issue would be best dealt with by a quick internet draft. I see it not as intended original functionality that somehow failed to get documented, but more as an extension. > > An i-d would help us sort out what the procedures are really meant to be. Keith, Are you talking about "Accept in 18x"? Or are you talking about Accept as dialog state? We could handle Accept in 18x either as an errata or as a draft issued as a clarification/extension. I expect there is more controversy over how to document it than there is about the legitimacy of doing so. IMO its unlikely that this would cause any backward compatibility issues. Accept as dialog state is more controversial. It could cause backward compatibility problems if some UAs started considering a previously received Accept as a *contract* that had to be honored until changed. Can someone explain to me what is driving this inquiry? Is there some specific usage that needs this? Thanks, Paul > Keith > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: 19 October 2011 20:02 >> To: Christer Holmberg >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Accept in 18x >> >> Comment at end >> >> On 10/19/11 2:32 PM, Christer Holmberg wrote: >>> Hi, >>> >>>>>>> Do we have text explicitly saying that a Contact received >>>>>>> in a provisional response is valid after 200 OK (unless you >>>>>>> receive a Contact in the 200 OK, of course)? >>>>>> >>>>>> This is a change in subject from the original question. >>>>>> >>>>>> What are you looking for? Valid for *what*? >>>>>> >>>>>> Obviously its impossible to send a PRACK or an UPDATE on an >>>>>> early dialog without having received a contact. In fact, I >>>>>> think we have agreed that you don't have an early dialog >>>>>> unless you got a contact in a provisional. >>>>> >>>>> That's not what I meant. >>>>> >>>>> The question was: if I receive a Contact in a 18x, is the Contact >> VALUE also valid after I have received the 200 OK? >>>>> >>>>> Obviously, if it's not, I can't send any in-dialog requests (including >> the ACK) after I've received the 200 OK. >>>> >>>> Well, there should also be a Contact in the 2xx, and typically it would >>>> have the same value as the one in the 1xx for the same dialog. Your >>>> question is only interesting if the two values are different. >>> >>> They could even be different in two different 1xx responses. >>> >>>> IIRC, 3261 specifies that the remote contact address is part of the >>>> dialog state. And the remote contact is allowed to change. So each time >>>> you get a new value it should supersede the prior value in the dialog >>>> state, and then be used for subsequent in-dialog requests. >>> >>> Could we simply say the same thing for Accept - that it is part of the >> dialog state? >> >> There is no such requirement now, so that would be a change that isn't >> backward compatible. >> >> Accept, and its definition, was inherited from HTTP. In HTTP I believe >> the scope of validity of ACCEPT is limited to the response to the message. >> >> In the past I have commented that we have a number of properties such as >> this whose scope is not well defined. In general I think you must treat >> these as *hints*, while being prepared to discover that they >> subsequently cease to be valid. >> >> Like many things, its hard for a 3pcc controller to assure the >> preservation of such state on one of its dialogs, because there may be a >> transfer on the "other side" to a device with different properties. >> >> Thanks, >> Paul >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@alum.mit.edu Thu Oct 20 07:55:12 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904EF21F8BBE for ; Thu, 20 Oct 2011 07:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKTuvuAJaYGg for ; Thu, 20 Oct 2011 07:55:11 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id A6D6921F8BA4 for ; Thu, 20 Oct 2011 07:55:11 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta04.westchester.pa.mail.comcast.net with comcast id n2iT1h00F1GhbT8542vCC5; Thu, 20 Oct 2011 14:55:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta07.westchester.pa.mail.comcast.net with comcast id n2vB1h00u0tdiYw3T2vBos; Thu, 20 Oct 2011 14:55:12 +0000 Message-ID: <4EA0364D.4030901@alum.mit.edu> Date: Thu, 20 Oct 2011 10:55:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <4E9F1CBD.5020206@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341F50AC@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341F50AC@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:55:12 -0000 On 10/20/11 8:08 AM, Christer Holmberg wrote: > > Hi, > >> The more we ask the more we do tease out unstated requirements. :-) >> >> Its important to identify these in order to justify your >> preferred mechanism over alternatives. > > I am not trying to justify the usage of Record-Route (if that's what you mean by 'preferred mechanism'). > > I am fine e.g. using a new header field (if that's what you mean by 'alternatives'), if people prefer that :) We are making progress, because we can now debate the pros/cons of different mechanisms. Thanks, Paul > Regards, > > Christer > > > > > > > >> On 10/19/11 1:21 PM, Christer Holmberg wrote: >>> Hi, >>> >>>> Thanks Christer. This is starting to get at the heart of things. >>>> >>>> Now, suppose that an SBC wants to hide some R-Rs that contain >>>> proxy-features, and it is also going to replace the Contact with a >>>> unique of of its own construction. >>>> >>>> It could conceivably transfer feature tags from the >> removed R-Rs to >>>> its own R-R. That could mean combining feature tags from >> two or more >>>> R-Rs into a single R-R. Does that work for you? >>> >>> It would work in cases where it doesn't matter which proxy >> provides a feature, or how support of features are spread out >> between different proxies. For the currently documented (in >> the drat) use-cases it might work. >>> >>> Havin said that, there is a new 3GPP use-case, which was >> agreed last week (it will be described in the next version of >> the draft), where it is not enough to indicate that features >> X and Y are supported by SOME entities in the network - it >> must be possible to indicate that features X and Y are >> supported by the SAME entity. It doesn't necessarily mean >> that it must be possible to indicate WHICH entity supports >> features X and Y, though, just to indicate that X and Y are >> supported by the same entity. So, having a single R-R header >> where you just collect and list feature tags taken from >> multiple R-R headers would not work. >>> >>> Also, a 3GPP application server can indicate support of >> services. And, eventhough nothing is currently specified, I >> think that there very likely could be use-cases where the >> S-CSCF needs to know WHICH application servers support >> specific services, and in which order, e.g. to making routing >> decissions etc. >>> >>>> Or, would it be ok to transfer the feature tags from the >> removed R-Rs to the new Contact address? >>> >>> Not in cases where the Contact is assumed to contain >> capabilities supported by the UA. >>> >>> Also remember that, based on previous discussions about >> draft-holmberg, a feature tag specification would need to >> specify what the meaning of a feature tag is when used in >> different header fields, and that meaning could very well be >> different for Contact and Record-Route - or the feature tag >> might not even be specified to be used with Contact. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> On 10/19/11 6:26 AM, Christer Holmberg wrote: >>>> >>>> Hi, >>>> >>>>>> And, eventhough what Hadriel says is true, SBCs that do topology >>>>>> hiding will have to become more "intelligent", in order not to >>>>>> break services that rely e.g. on information in the Record-Route >>>>>> headers. >>>>> >>>>> That's not realistic. The issue here isn't whether or >> not SBCs can >>>>> pass through Record-Route headers, or even be implemented as >>>>> Proxy-B2BUAs. Of course they can. In fact, just speaking for my >>>>> own company's SBCs, I don't even need to change any code >> or upgrade >>>>> anything to pass through Record-Routes - you could >> configure it to >>>>> do that right now. >>>>> >>>>> The problem is no one in their right mind would do so. >> SBC's don't >>>>> remove Record-Route because they're lazy vendors - on the >> contrary >>>>> it would make our lives simpler. SBCs do it because (1) their >>>>> customers have security groups who demand it, and (2) it makes >>>>> things work better. >>>> >>>> Sure. >>>> >>>> But, assuming that the security requirement is to not >> provide address information, the SBC would have to change >> that part of the Record-Route, but still pass the capability >> information - instead of simply removing the whole >> Record-Route, including information that doesn't need to (or, >> even shouldn't, because it would break services) be removed. >>>> >>>> Of course the SBC (or the one controlling it) can choose >> to simply remove the whole Record-Route, even if it would not >> be needed, but I don't think we should have to take that into >> consideration when working on a protocol mechanism for proxy-feature. >>>> >>>>>> Also, there are services that rely on the fact that the Contact >>>>>> always point to the UE. >>>>> >>>>> If by that you mean that there are service that rely on >> knowing the >>>>> UE's real IP Address:port of the Contact, that's not >> true. I know >>>>> of only two vendors who actually need to know the UE's real IP >>>>> Address:port, and dozens of vendors who do not. >>>>> >>>>> If instead you mean that they need to know a unique >> Contact URI per >>>>> UE, such that they can use it in an out-of-dialog to >> reach the same >>>>> UE for example, that's true but not germane to the issue at hand. >>>>> (SBC's solve that problem without leaking Record-Routes to UE's - >>>>> the two issues are not related) >>>> >>>> What I mean is that feature tags in the Contact (no matter >> whether it contains the real IP address:port of the UE, or >> some value created by an SBC) describe capabilities of the >> UE. So, an SBC can not modify the Contact in order to provide >> information about *its* capabilities. Instead it would >> provide that information in its Record-Route (assuming it >> would use the draft-holmberg mechanism). >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >> >> From pkyzivat@alum.mit.edu Thu Oct 20 08:06:47 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D97E21F8B87 for ; Thu, 20 Oct 2011 08:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[AWL=-3.050, BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_24=0.6, J_CHICKENPOX_33=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hzIeuaU0UJU for ; Thu, 20 Oct 2011 08:06:47 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id D74AE21F8B65 for ; Thu, 20 Oct 2011 08:06:46 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta01.westchester.pa.mail.comcast.net with comcast id n2m81h0040bG4ec5136nxn; Thu, 20 Oct 2011 15:06:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta03.westchester.pa.mail.comcast.net with comcast id n36m1h01Y0tdiYw3P36mBn; Thu, 20 Oct 2011 15:06:47 +0000 Message-ID: <4EA03904.1010704@alum.mit.edu> Date: Thu, 20 Oct 2011 11:06:44 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:06:47 -0000 On 10/20/11 8:07 AM, Christer Holmberg wrote: > > Hi, > >>>> One could, for example, just put X into the Supported header, or a header like it. >>> >>> We would need something like Proxy-Supported. >> >> They're NOT proxies, but ya the name doesn't matter much. >> How about "Feature-Caps"? Too obvious? :) > > I would be ok with that :) > > >>> Havin said that, there is a new 3GPP use-case, which was >>> agreed last week (it will be described in the next version of >>> the draft), where it is not enough to indicate that features >>> X and Y are supported by SOME entities in the network - it >>> must be possible to indicate that features X and Y are >>> supported by the SAME entity. It doesn't necessarily mean >>> that it must be possible to indicate WHICH entity supports >>> features X and Y, though, just to indicate that X and Y are >>> supported by the same entity. So, having a single R-R header >>> where you just collect and list feature tags taken from >>> multiple R-R headers would not work. >> >> >> That's easy... >> Feature-Caps: foo, bar, foo+bar > > Correct. The key is being able to use '+', in order to show that features are supported by the same entity. I *think* that hadriel had meant that if you wanted to be able to report that a single device had both foo and bar, you would define a new feature that was the sum of the other two, and then perhaps give it the name "foo+bar". But, if we are defining a new header, I suppose it would indeed be possible to define "+" to be an operator indicating that. >>> Also, a 3GPP application server can indicate support of >>> services. And, eventhough nothing is currently specified, I >>> think that there very likely could be use-cases where the >>> S-CSCF needs to know WHICH application servers support >>> specific services, and in which order, e.g. to making routing >>> decissions etc. >> >> OK, then why would we want to indicate that in a header used >> for dialog route-sets? >> >> Record-Route has a very specific purpose, to be used for the >> in-dialog route-set. And despite all examples in RFCs to the >> contrary, its URI is frequently an IP:host rather than a >> hostname. That's probably because devices want in-dialog >> requests coming in on the same instance/blade/interface that >> created the dialog, for a bunch of reasons. But a feature >> capability, especially one that would be useful for routing >> to for all-time, doesn't necessarily have that property. >> >> I.e., it's just as likely you'd want to indicate your whole >> App-Server system/cluster can do that feature, rather than >> the particular interface you're using for in-dialog request routing. > > In the current use-cases, when the feature support is indicated in INVITE/Record-Route, the support only applies to the specific session established. Ie it is NOT a generic capability support indication. > > But, as we have discussed before, the feature tag definition needs to define the scope when support of a feature is indicated in INVITE, REGSTER etc. Do you really mean that feature "foo", when defined in REGISTER could have one scope (say, for all usage of the registered contact for the duration of the registration), while feature "bar" when defined in REGISTER could have some different scope? That would make it difficult to develop any generalized support for the mechanism. Or did you just mean that the mechanism would specify a particular scope for REGISTER, another for INVITE, etc. And then the registration would indicate applicability of the specific feature for use in REGISTER, INVITE, etc.? Thanks, Paul > Regards, > > Christer > > From adam@nostrum.com Thu Oct 20 08:12:00 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F1F21F8BEF for ; Thu, 20 Oct 2011 08:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7A3+dA+56SvG for ; Thu, 20 Oct 2011 08:12:00 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E548221F8BF4 for ; Thu, 20 Oct 2011 08:11:59 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p9KFBwXa024194 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 20 Oct 2011 10:11:59 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4EA03A3E.7040406@nostrum.com> Date: Thu, 20 Oct 2011 10:11:58 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> In-Reply-To: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:12:01 -0000 On 10/20/11 9:22 AM, Olle E. Johansson wrote: > Hi! > Coming in rather late in the discussion, I don't know if I missed the topic of security. Thanks. It's not too late (although I certainly would have preferred comments back during WGLC), but I think many of the issues you identify are more applicable to SIP in general than SIP Events in particular. > Having read RFC 3265 and some of the event specs, like mwi and dialog, the security sections lack a lot and in some cases are texts that are impossible for a developer to create running code from. > > I think we need to write better text in 3265 biz for developers of event packages to clarify requirements. > > Like > > * If you specify TLS usage, be very clear on certificate matching > * If you specify S/MIME, be very clear on certificate matching and usage These, for example, are both general SIP problems. TLS certificate matching is as much an issue for INVITE as it is for SUBSCRIBE. This is also true for S/MIME. As you know, RFC5630 takes on the issue of TLS handling in SIP, albeit with some of the issues you and Iñaki have raised on first-hop handling. I would argue that these should be addressed in an RFC5630bis, not as a hasty addendum to SIP Events. As far as I know, there has been no effort to explicitly address the issue of S/MIME handling in SIP, although an effort similar in scope to RFC5630 would probably be appropriate, if we're seeing real-world problems in this area. > Also, require some message flows. Section 5.4.12 calls out a SHOULD-level normative requirement to do so. What would you suggest we change in that section? > One of these, I don't remember which one, requires S/MIME for confidentiality without specifying anything else. > If I need to encrypt, how do I get the presence server certificate? Or does the presence server need the keys for > the target URI? Presence is covered by RFC3856, which appears to be pretty clear on which certs to use. Section 6.7 calls out: > For reasons of privacy, it will frequently be necessary to encrypt > the contents of the notifications. This can be accomplished using > S/MIME. The encryption can be performed using the key of the > subscriber as identified in the From field of the SUBSCRIBE request. > Similarly, integrity of the notifications is important to > subscribers. As such, the contents of the notifications MAY provide > authentication and message integrity using S/MIME. Since the NOTIFY > is generated by the presence server, which may not have access to the > key of the user represented by the presentity, it will frequently be > the case that the NOTIFY is signed by a third party. It is > RECOMMENDED that the signature be by an authority over the domain of > the presentity. In other words, for a user pres:user@example.com, > the signator of the NOTIFY SHOULD be the authority for example.com. Turning back to RFC 3265 in particular -- I'm okay with adding some very lightweight text along the lines of: > 5.4.14 Confidentiality, Authentication, and Integrity > > Event packages will typically convey information that requires > some level of security protection. This may include protecting > the information from eavesdropping, confirming the source of the > information, and/or ensuring that the information has not been > changed in transit. [RFC3261], as updated by [RFC5630], specifies > the use of S/MIME and TLS for these purposes. > > Event packages that specify the use of S/MIME, TLS, or other > security technologies MUST include a description of the goals of > such a security mechanism (in terms of the three properties of > confidentiality, integrity, and authentication). Such event > packages also MUST clearly indicate which certificates are used > for the security mechanism, how they are acquired, and how > implementations verify matching certificates. > /a From ibc@aliax.net Thu Oct 20 08:21:58 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33E321F8BE8 for ; Thu, 20 Oct 2011 08:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYbdt3IvdN6u for ; Thu, 20 Oct 2011 08:21:57 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4F29E21F8BCD for ; Thu, 20 Oct 2011 08:21:57 -0700 (PDT) Received: by vws5 with SMTP id 5so2559051vws.31 for ; Thu, 20 Oct 2011 08:21:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.166 with SMTP id m6mr11104611vdv.18.1319124116700; Thu, 20 Oct 2011 08:21:56 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Thu, 20 Oct 2011 08:21:56 -0700 (PDT) In-Reply-To: <4EA03A3E.7040406@nostrum.com> References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> Date: Thu, 20 Oct 2011 17:21:56 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Adam Roach Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:21:58 -0000 2011/10/20 Adam Roach : > Turning back to RFC 3265 in particular -- I'm okay with adding some very > lightweight text along the lines of: > >> 5.4.14 Confidentiality, Authentication, and Integrity >> >> =C2=A0Event packages will typically convey information that requires >> =C2=A0some level of security protection. This may include protecting >> =C2=A0the information from eavesdropping, confirming the source of the >> =C2=A0information, and/or ensuring that the information has not been >> =C2=A0changed in transit. [RFC3261], as updated by [RFC5630], specifies >> =C2=A0the use of S/MIME and TLS for these purposes. >> >> =C2=A0Event packages that specify the use of S/MIME, TLS, or other >> =C2=A0security technologies MUST include a description of the goals of >> =C2=A0such a security mechanism (in terms of the three properties of >> =C2=A0confidentiality, integrity, and authentication). Such event >> =C2=A0packages also MUST clearly indicate which certificates are used >> =C2=A0for the security mechanism, how they are acquired, and how >> =C2=A0implementations verify matching certificates. Hi Adam, IMHO all the security mechanism in SIP are fully unclear, difficult to implement and hard to understand and interoperate, so adding the text "this spec may use TLS or S/MIME" in every SIP RFC is not a solution at all, because nobody undertands the core mechanism of such security. As previously recognized in this maillist, RFC 5630 is not a fix of the security for SIP, but an attempt of clarification, and it does not get it due to existing *bugs* in the security specs (clarifying a bug is never a solution). So we need something more, something radical and aggresive. Trying to add patches over the existing security specs is a no-go. Olle and me have some issues in mind (related to TLS and SIPS usage) for which there is no solution, they are bugs in the spec. We don't need patches, we need a complete re-work. And taking into account that nobody uses security in SIP (or uses it in an own way without following the standards) we can break current specs and do something from scratch, trying to avoid all the existing bugs and issues. Regards. --=20 I=C3=B1aki Baz Castillo From vkg@bell-labs.com Thu Oct 20 08:28:46 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F4621F8C0D for ; Thu, 20 Oct 2011 08:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.45 X-Spam-Level: X-Spam-Status: No, score=-106.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ga3GZDqZ-HrH for ; Thu, 20 Oct 2011 08:28:41 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 62EBA21F8C13 for ; Thu, 20 Oct 2011 08:28:38 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p9KFSXiA020712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 20 Oct 2011 10:28:33 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p9KFSXHC020965 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 20 Oct 2011 10:28:33 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p9KFSWN1011974 for ; Thu, 20 Oct 2011 10:28:33 -0500 (CDT) Message-ID: <4EA03ECB.5030209@bell-labs.com> Date: Thu, 20 Oct 2011 10:31:23 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> In-Reply-To: <4EA03A3E.7040406@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:28:46 -0000 On 10/20/2011 10:11 AM, Adam Roach wrote: >> Like >> >> * If you specify TLS usage, be very clear on certificate matching >> * If you specify S/MIME, be very clear on certificate matching and usage > > These, for example, are both general SIP problems. TLS certificate > matching is as much an issue for INVITE as it is for SUBSCRIBE. This is > also true for S/MIME. As you know, RFC5630 takes on the issue of TLS > handling in SIP, albeit with some of the issues you and Iñaki have > raised on first-hop handling. I would argue that these should be > addressed in an RFC5630bis, not as a hasty addendum to SIP Events. Note that rfc5922 has much more to say on the contents of the X.509 certificates and matching identities in the certificate, etc. than rfc5630 does. Insofar as determining whether or not a certificate is valid for SIP usage or to determine which identity to match, I suspect that rfc5922 will help. If there are any ambiguities in rfc5922 on these fronts, then we can, of course, rectify them. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From vkg@bell-labs.com Thu Oct 20 08:32:48 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE3A21F8C37 for ; Thu, 20 Oct 2011 08:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.475 X-Spam-Level: X-Spam-Status: No, score=-106.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rb1YwdmbaPmS for ; Thu, 20 Oct 2011 08:32:47 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id ADF9821F8C1E for ; Thu, 20 Oct 2011 08:32:47 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p9KFWlSj002092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 20 Oct 2011 10:32:47 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p9KFWkSn031471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 20 Oct 2011 10:32:47 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p9KFWkhI016818 for ; Thu, 20 Oct 2011 10:32:46 -0500 (CDT) Message-ID: <4EA03FC9.9030203@bell-labs.com> Date: Thu, 20 Oct 2011 10:35:37 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:32:48 -0000 On 10/20/2011 10:21 AM, Iñaki Baz Castillo wrote: > So we need something more, something radical and aggresive. Trying to > add patches over the existing security specs is a no-go. Olle and me > have some issues in mind (related to TLS and SIPS usage) for which > there is no solution, they are bugs in the spec. Please take a look at rfc5922, and to a lesser extent, rfc5924 to see if it is able to answer any of your questions related to the contents of X.509 certificates and how to determine their usage for SIP. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From adam@nostrum.com Thu Oct 20 08:51:44 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9049021F8C71 for ; Thu, 20 Oct 2011 08:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efPpLxXQDKnb for ; Thu, 20 Oct 2011 08:51:44 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 18ACF21F8C89 for ; Thu, 20 Oct 2011 08:51:43 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p9KFpgrU029016 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 20 Oct 2011 10:51:42 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4EA0438E.6050403@nostrum.com> Date: Thu, 20 Oct 2011 10:51:42 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:51:44 -0000 On 10/20/11 10:21 AM, Iñaki Baz Castillo wrote: > 2011/10/20 Adam Roach: >> Turning back to RFC 3265 in particular -- I'm okay with adding some very >> lightweight text along the lines of: >> >>> 5.4.14 Confidentiality, Authentication, and Integrity >>> >>> Event packages will typically convey information that requires >>> some level of security protection. This may include protecting >>> the information from eavesdropping, confirming the source of the >>> information, and/or ensuring that the information has not been >>> changed in transit. [RFC3261], as updated by [RFC5630], specifies >>> the use of S/MIME and TLS for these purposes. >>> >>> Event packages that specify the use of S/MIME, TLS, or other >>> security technologies MUST include a description of the goals of >>> such a security mechanism (in terms of the three properties of >>> confidentiality, integrity, and authentication). Such event >>> packages also MUST clearly indicate which certificates are used >>> for the security mechanism, how they are acquired, and how >>> implementations verify matching certificates. > Hi Adam, IMHO all the security mechanism in SIP are fully unclear, > difficult to implement and hard to understand and interoperate, so > adding the text "this spec may use TLS or S/MIME" in every SIP RFC is > not a solution at all, because nobody undertands the core mechanism of > such security. > > As previously recognized in this maillist, RFC 5630 is not a fix of > the security for SIP, but an attempt of clarification, and it does not > get it due to existing *bugs* in the security specs (clarifying a bug > is never a solution). > > So we need something more, something radical and aggresive. Trying to > add patches over the existing security specs is a no-go. Olle and me > have some issues in mind (related to TLS and SIPS usage) for which > there is no solution, they are bugs in the spec. We don't need > patches, we need a complete re-work. And taking into account that > nobody uses security in SIP (or uses it in an own way without > following the standards) we can break current specs and do something > from scratch, trying to avoid all the existing bugs and issues. > Send text. /a From ibc@aliax.net Thu Oct 20 08:59:33 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641DE21F8CC4 for ; Thu, 20 Oct 2011 08:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqAimrwVMMYT for ; Thu, 20 Oct 2011 08:59:33 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D83FA21F8C98 for ; Thu, 20 Oct 2011 08:59:32 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3119380vcb.31 for ; Thu, 20 Oct 2011 08:59:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.34 with SMTP id e2mr11086210vdj.52.1319126372373; Thu, 20 Oct 2011 08:59:32 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Thu, 20 Oct 2011 08:59:32 -0700 (PDT) In-Reply-To: <4EA0438E.6050403@nostrum.com> References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> <4EA0438E.6050403@nostrum.com> Date: Thu, 20 Oct 2011 17:59:32 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Adam Roach Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:59:33 -0000 2011/10/20 Adam Roach : > Send text. Just wait :) Regards. --=20 I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Thu Oct 20 09:15:21 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DFC21F8CFC for ; Thu, 20 Oct 2011 09:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McEEVcG85AxY for ; Thu, 20 Oct 2011 09:15:21 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id D996621F8CC1 for ; Thu, 20 Oct 2011 09:15:16 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta15.westchester.pa.mail.comcast.net with comcast id n2yi1h00C1c6gX85F4FHpe; Thu, 20 Oct 2011 16:15:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta23.westchester.pa.mail.comcast.net with comcast id n4FG1h0360tdiYw3j4FHcB; Thu, 20 Oct 2011 16:15:17 +0000 Message-ID: <4EA04913.10106@alum.mit.edu> Date: Thu, 20 Oct 2011 12:15:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> <4EA03ECB.5030209@bell-labs.com> In-Reply-To: <4EA03ECB.5030209@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:15:21 -0000 I agree with Adam and Vijay here. I'm not surprised if you are finding things unclear. It certainly isn't the first time. But please identify the source of the ambiguity, and if possible send text. Or if you don't know what text to propose, please spell out the difficulties you have had is as much detail as you can. We have attempted to address the security issues in the past. What you see is what we were able to figure out at the time given perceived constraints. But its been awhile. Now there may be better insight, and/or a different understanding of the constraints. Thanks, Paul On 10/20/11 11:31 AM, Vijay K. Gurbani wrote: > On 10/20/2011 10:11 AM, Adam Roach wrote: >>> Like >>> >>> * If you specify TLS usage, be very clear on certificate matching >>> * If you specify S/MIME, be very clear on certificate matching and usage >> >> These, for example, are both general SIP problems. TLS certificate >> matching is as much an issue for INVITE as it is for SUBSCRIBE. This is >> also true for S/MIME. As you know, RFC5630 takes on the issue of TLS >> handling in SIP, albeit with some of the issues you and Iñaki have >> raised on first-hop handling. I would argue that these should be >> addressed in an RFC5630bis, not as a hasty addendum to SIP Events. > > Note that rfc5922 has much more to say on the contents of the X.509 > certificates and matching identities in the certificate, etc. > than rfc5630 does. > > Insofar as determining whether or not a certificate is valid for SIP > usage or to determine which identity to match, I suspect that rfc5922 > will help. If there are any ambiguities in rfc5922 on these fronts, > then we can, of course, rectify them. > > Thanks, > > - vijay From ibc@aliax.net Thu Oct 20 09:18:07 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AF221F8C70 for ; Thu, 20 Oct 2011 09:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3OV9uxh0YKy for ; Thu, 20 Oct 2011 09:18:06 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B8F4E21F8C88 for ; Thu, 20 Oct 2011 09:18:06 -0700 (PDT) Received: by vws5 with SMTP id 5so2625216vws.31 for ; Thu, 20 Oct 2011 09:18:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.13.1 with SMTP id d1mr246020obc.74.1319127486034; Thu, 20 Oct 2011 09:18:06 -0700 (PDT) Received: by 10.182.144.9 with HTTP; Thu, 20 Oct 2011 09:18:05 -0700 (PDT) In-Reply-To: <4EA04913.10106@alum.mit.edu> References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> <4EA03ECB.5030209@bell-labs.com> <4EA04913.10106@alum.mit.edu> Date: Thu, 20 Oct 2011 18:18:05 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:18:07 -0000 2011/10/20 Paul Kyzivat : > I agree with Adam and Vijay here. > > I'm not surprised if you are finding things unclear. It certainly isn't t= he > first time. But please identify the source of the ambiguity, and if possi= ble > send text. Or if you don't know what text to propose, please spell out th= e > difficulties you have had is as much detail as you can. > > We have attempted to address the security issues in the past. What you se= e > is what we were able to figure out at the time given perceived constraint= s. > But its been awhile. Now there may be better insight, and/or a different > understanding of the constraints. Hi Paul, let me (and Olle) some time to write a text describing issues on the security specs (including those that I consider bugs rather than difficulties). Thanks a lot. --=20 I=C3=B1aki Baz Castillo From keith.drage@alcatel-lucent.com Thu Oct 20 09:40:44 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A08521F8B9C for ; Thu, 20 Oct 2011 09:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.799 X-Spam-Level: X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99oXYGjfdmCY for ; Thu, 20 Oct 2011 09:40:42 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8E80F21F850E for ; Thu, 20 Oct 2011 09:40:42 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p9KGeYKT014648 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 20 Oct 2011 18:40:36 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 20 Oct 2011 18:40:36 +0200 From: "DRAGE, Keith (Keith)" To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Paul Kyzivat Date: Thu, 20 Oct 2011 18:40:31 +0200 Thread-Topic: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 Thread-Index: AcyPQ+UZN8pMOAsrRt2DRr1H17sxhgAAjcAQ Message-ID: References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> <4EA03ECB.5030209@bell-labs.com> <4EA04913.10106@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:40:44 -0000 But I agree with Adam's initial comment. RFC 3265bis is not the place to ma= ke these clarifications, at least in as far as you have identified issues a= t the moment. Essentially you are talking a general SIP problem that requires updates to = RFC 3261 (even if it is only the addition of references).=20 RFC 3265 doesn't invent the problem of carrying bodies, RFC 3261 does. So the fix here is to take over where RFC 5630 left off. What you need to d= o is an i-d to provide appropriate updates to RFC 3261 that address require= d changes in the text of RFC 3261. Put the change in 3265bis and you will create something specific for event = packages that misses all the other body usages in PUBLISH, REFER, MESSAGE, = INVITE, INFO, etc. Keith > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of I=F1aki Baz Castillo > Sent: 20 October 2011 17:18 > To: Paul Kyzivat > Cc: sipcore@ietf.org > Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 >=20 > 2011/10/20 Paul Kyzivat : > > I agree with Adam and Vijay here. > > > > I'm not surprised if you are finding things unclear. It certainly isn't > the > > first time. But please identify the source of the ambiguity, and if > possible > > send text. Or if you don't know what text to propose, please spell out > the > > difficulties you have had is as much detail as you can. > > > > We have attempted to address the security issues in the past. What you > see > > is what we were able to figure out at the time given perceived > constraints. > > But its been awhile. Now there may be better insight, and/or a differen= t > > understanding of the constraints. >=20 > Hi Paul, let me (and Olle) some time to write a text describing issues > on the security specs (including those that I consider bugs rather > than difficulties). >=20 > Thanks a lot. >=20 >=20 > -- > I=F1aki Baz Castillo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From HKaplan@acmepacket.com Thu Oct 20 10:24:30 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA7621F8C59 for ; Thu, 20 Oct 2011 10:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.134 X-Spam-Level: X-Spam-Status: No, score=0.134 tagged_above=-999 required=5 tests=[AWL=-2.494, BAYES_00=-2.599, GB_SUMOF=5, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlm8j2OzWEj7 for ; Thu, 20 Oct 2011 10:24:30 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2A97821F8C55 for ; Thu, 20 Oct 2011 10:24:27 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 20 Oct 2011 13:24:26 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 20 Oct 2011 13:24:26 -0400 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMj00dyOSIjaFSp0KtBQMggFLR9A== Date: Thu, 20 Oct 2011 17:24:25 +0000 Message-ID: References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> In-Reply-To: <4EA03904.1010704@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8FA04ADED679044F96F22C9ED492BCAA@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 17:24:30 -0000 On Oct 20, 2011, at 11:06 AM, Paul Kyzivat wrote: > I *think* that hadriel had meant that if you wanted to be able to report = that a single device had both foo and bar, you would define a new feature t= hat was the sum of the other two, and then perhaps give it the name "foo+ba= r". Nope, I actually meant the "foo" and "bar" would be feature tokens, and a "= +" between feature tokens would mean you do both features.=20 -hadriel From christer.holmberg@ericsson.com Thu Oct 20 10:42:19 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1316E21F8BCD for ; Thu, 20 Oct 2011 10:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.294 X-Spam-Level: X-Spam-Status: No, score=-3.294 tagged_above=-999 required=5 tests=[AWL=-3.122, BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_24=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPoMELOocuze for ; Thu, 20 Oct 2011 10:42:18 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id F0AD521F8B84 for ; Thu, 20 Oct 2011 10:42:17 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-88-4ea05d78d640 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C1.4B.13753.87D50AE4; Thu, 20 Oct 2011 19:42:17 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 20 Oct 2011 19:42:16 +0200 From: Christer Holmberg To: 'Paul Kyzivat' Date: Thu, 20 Oct 2011 19:42:15 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AcyPOeNXeyH/kjapQCGDsY7txgzrpQAEQ5sg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> In-Reply-To: <4EA03904.1010704@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 17:42:19 -0000 Hi,=20 >>>>> One could, for example, just put X into the Supported header, or a he= ader like it. >>>> >>>> We would need something like Proxy-Supported. >>> >>> They're NOT proxies, but ya the name doesn't matter much. >>> How about "Feature-Caps"? Too obvious? :) >> >> I would be ok with that :) >> >> >>>> Havin said that, there is a new 3GPP use-case, which was agreed last=20 >>>> week (it will be described in the next version of the draft), where=20 >>>> it is not enough to indicate that features X and Y are supported by=20 >>>> SOME entities in the network - it must be possible to indicate that=20 >>>> features X and Y are supported by the SAME entity. It doesn't=20 >>>> necessarily mean that it must be possible to indicate WHICH entity=20 >>>> supports features X and Y, though, just to indicate that X and Y are=20 >>>> supported by the same entity. So, having a single R-R header where=20 >>>> you just collect and list feature tags taken from multiple R-R=20 >>>> headers would not work. >>> >>> >>> That's easy... >>> Feature-Caps: foo, bar, foo+bar >> >> Correct. The key is being able to use '+', in order to show that feature= s are supported by the same entity. >' >I *think* that hadriel had meant that if you wanted to be able to report t= hat a single device had both foo and=20 >bar, you would define a new feature that was the sum of the other two, and= then perhaps give it the name "foo+bar". I think that would be strange, and I am not sure whether it would work. Ass= uming we are using feature tags, and have an IANA registry, we=20 would have to register every possible feature tag combination, as each comb= ination technically would be a unique feature tag :) >But, if we are defining a new header, I suppose it would indeed be possibl= e to define "+" to be an=20 >operator indicating that. I would actually suggest that we use the same syntax as we do e.g. for Acce= pt-Contact, where feature tag=20 values would be separated by ';' instead of '+'. So, we would get something like: Feature-Caps: foo, bar, foo;bar >>>> Also, a 3GPP application server can indicate support of services.=20 >>>> And, eventhough nothing is currently specified, I think that there=20 >>>> very likely could be use-cases where the S-CSCF needs to know WHICH=20 >>>> application servers support specific services, and in which order,=20 >>>> e.g. to making routing decissions etc. >>>> >>>> OK, then why would we want to indicate that in a header used for=20 >>>> dialog route-sets? >>> >>> Record-Route has a very specific purpose, to be used for the=20 >>> in-dialog route-set. And despite all examples in RFCs to the=20 >>> contrary, its URI is frequently an IP:host rather than a hostname. =20 >>> That's probably because devices want in-dialog requests coming in on=20 >>> the same instance/blade/interface that created the dialog, for a=20 >>> bunch of reasons. But a feature capability, especially one that=20 >>> would be useful for routing to for all-time, doesn't necessarily have=20 >>> that property. >>> >>> I.e., it's just as likely you'd want to indicate your whole=20 >>> App-Server system/cluster can do that feature, rather than the=20 >>> particular interface you're using for in-dialog request routing. >> >> In the current use-cases, when the feature support is indicated in INVIT= E/Record-Route, the=20 >> support only applies to the specific session established. Ie it is NOT a= generic capability=20 >> support indication. >> >> But, as we have discussed before, the feature tag definition needs to de= fine the scope when=20 >> support of a feature is indicated in INVITE, REGSTER etc. > > Do you really mean that feature "foo", when defined in REGISTER could hav= e one scope (say, for all=20 > usage of the registered contact for the duration of the registration), wh= ile feature "bar" when defined=20 > in REGISTER could have some different scope? > > That would make it difficult to develop any generalized support for the m= echanism. My *personal* preference would be to NOT do that, but instead specify that = the scope of a feature tag in REGISTER is always the specific registration. >Or did you just mean that the mechanism would specify a particular scope f= or REGISTER, another for INVITE, etc. And=20 >then the registration would indicate applicability of the specific feature= for use in REGISTER, INVITE, etc.? That would be my preference, yes. So, when indicated in INVITE, the feature is only valid for that dialog. But, the actual USAGE of the feature must of course be described in the fea= ture tag definition, and eventhough the feature is only valid for a specifi= c dialog, there is at least one use-case (see below) where the information = is used when establishing another dialog. Use-case: In one of the use-cases an AS indicates that, for a given dialog,= it provides SCC AS functionality. So, eventhough the SCC functionality onl= y applies for that dialog, the information is then used when another dialog= is established, in order to do handover for the dialog for which SCC funct= ionality was indicated.=20 Regards, Christer From christer.holmberg@ericsson.com Thu Oct 20 10:42:49 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E8D21F8B84 for ; Thu, 20 Oct 2011 10:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.764 X-Spam-Level: X-Spam-Status: No, score=-3.764 tagged_above=-999 required=5 tests=[AWL=-2.392, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQu82oEdBINH for ; Thu, 20 Oct 2011 10:42:48 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 43DDE21F8B87 for ; Thu, 20 Oct 2011 10:42:48 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-bd-4ea05d97b223 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 2B.4B.13753.79D50AE4; Thu, 20 Oct 2011 19:42:47 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 20 Oct 2011 19:42:47 +0200 From: Christer Holmberg To: 'Hadriel Kaplan' , Paul Kyzivat Date: Thu, 20 Oct 2011 19:42:46 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMj00dyOSIjaFSp0KtBQMggFLR9JWFfIAg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45FEC@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 17:42:49 -0000 Hi,=20 >> I *think* that hadriel had meant that if you wanted to be able to report= that a single device had both foo and bar,=20 >> you would define a new feature that was the sum of the other two, and th= en perhaps give it the name "foo+bar". > > Nope, I actually meant the "foo" and "bar" would be feature tokens, and a= "+" between feature tokens would mean you do both features.=20 I commented this in my other reply: instead of "+", I would suggest using "= ;" instead, similar to Accept-Contact. Regards, Christer From christer.holmberg@ericsson.com Thu Oct 20 11:01:53 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D2E21F8BA8 for ; Thu, 20 Oct 2011 11:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.132 X-Spam-Level: X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 400bVzZ25b-u for ; Thu, 20 Oct 2011 11:01:52 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6F63C21F8B7E for ; Thu, 20 Oct 2011 11:01:52 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-0e-4ea0620f81c5 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 69.21.20773.F0260AE4; Thu, 20 Oct 2011 20:01:51 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 20 Oct 2011 20:01:50 +0200 From: Christer Holmberg To: "'DRAGE, Keith (Keith)'" , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Paul Kyzivat Date: Thu, 20 Oct 2011 20:01:50 +0200 Thread-Topic: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 Thread-Index: AcyPQ+UZN8pMOAsrRt2DRr1H17sxhgAAjcAQAAMH7rA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45FED@ESESSCMS0356.eemea.ericsson.se> References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> <4EA03ECB.5030209@bell-labs.com> <4EA04913.10106@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 18:01:53 -0000 Hi, I agree with Keith and Adam. Unless the problem is specific to the SUB/NOT mechanism, I think it should = be solved somewhere else. Regards, Christer=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of DRAGE, Keith (Keith) Sent: 20. lokakuuta 2011 19:41 To: I=F1aki Baz Castillo; Paul Kyzivat Cc: sipcore@ietf.org Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 But I agree with Adam's initial comment. RFC 3265bis is not the place to ma= ke these clarifications, at least in as far as you have identified issues a= t the moment. Essentially you are talking a general SIP problem that requires updates to = RFC 3261 (even if it is only the addition of references).=20 RFC 3265 doesn't invent the problem of carrying bodies, RFC 3261 does. So the fix here is to take over where RFC 5630 left off. What you need to d= o is an i-d to provide appropriate updates to RFC 3261 that address require= d changes in the text of RFC 3261. Put the change in 3265bis and you will create something specific for event = packages that misses all the other body usages in PUBLISH, REFER, MESSAGE, = INVITE, INFO, etc. Keith > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > Behalf Of I=F1aki Baz Castillo > Sent: 20 October 2011 17:18 > To: Paul Kyzivat > Cc: sipcore@ietf.org > Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 >=20 > 2011/10/20 Paul Kyzivat : > > I agree with Adam and Vijay here. > > > > I'm not surprised if you are finding things unclear. It certainly=20 > > isn't > the > > first time. But please identify the source of the ambiguity, and if > possible > > send text. Or if you don't know what text to propose, please spell=20 > > out > the > > difficulties you have had is as much detail as you can. > > > > We have attempted to address the security issues in the past. What=20 > > you > see > > is what we were able to figure out at the time given perceived > constraints. > > But its been awhile. Now there may be better insight, and/or a=20 > > different understanding of the constraints. >=20 > Hi Paul, let me (and Olle) some time to write a text describing issues=20 > on the security specs (including those that I consider bugs rather=20 > than difficulties). >=20 > Thanks a lot. >=20 >=20 > -- > I=F1aki Baz Castillo > > _______________________________________________ > 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 ibc@aliax.net Thu Oct 20 11:18:25 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BDF21F8B81 for ; Thu, 20 Oct 2011 11:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qMT6kesAGM5 for ; Thu, 20 Oct 2011 11:18:25 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 437FE21F8B4C for ; Thu, 20 Oct 2011 11:18:25 -0700 (PDT) Received: by vws5 with SMTP id 5so2779497vws.31 for ; Thu, 20 Oct 2011 11:18:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.73.36 with SMTP id i4mr361632obv.24.1319134704612; Thu, 20 Oct 2011 11:18:24 -0700 (PDT) Received: by 10.182.144.9 with HTTP; Thu, 20 Oct 2011 11:18:24 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233D45FED@ESESSCMS0356.eemea.ericsson.se> References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> <4EA03ECB.5030209@bell-labs.com> <4EA04913.10106@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FED@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 20 Oct 2011 20:18:24 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "sipcore@ietf.org" Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 18:18:25 -0000 2011/10/20 Christer Holmberg : > Unless the problem is specific to the SUB/NOT mechanism, I think it shoul= d be solved somewhere else. I agree. But I would like to clarify whether we all confirm that "the problem exists" or not. Some weeks ago, I open a thread in IETF SIP in which there were comments asserting that trying to make SIPS is unfeasible "even if you do everything by the book": http://www.ietf.org/mail-archive/web/sip/current/msg27887.html But my impression after reading responses in current thread is that "there are not issues". So I think: All the people use ;transport=3Dtls, including big vendors, regardless "tls" is not a valid URI ;transport value. And no one wants to deal with SIPS schema, or just treats it as if it was SIP schema. IMHO there *are* issues. Anyhow there will be soon a text listing the existing issues in SIP securit= y. Regards. --=20 I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Thu Oct 20 11:22:43 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C7721F8BB3 for ; Thu, 20 Oct 2011 11:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.829 X-Spam-Level: X-Spam-Status: No, score=0.829 tagged_above=-999 required=5 tests=[AWL=-2.999, BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_24=0.6, J_CHICKENPOX_33=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cjdyxQ6+iHC for ; Thu, 20 Oct 2011 11:22:40 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 61B5111E809A for ; Thu, 20 Oct 2011 11:22:40 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta14.westchester.pa.mail.comcast.net with comcast id n62d1h0080cZkys5E6NdWB; Thu, 20 Oct 2011 18:22:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta10.westchester.pa.mail.comcast.net with comcast id n6Nd1h0070tdiYw3W6NdVr; Thu, 20 Oct 2011 18:22:37 +0000 Message-ID: <4EA066EB.40701@alum.mit.edu> Date: Thu, 20 Oct 2011 14:22:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 18:22:43 -0000 Inline On 10/20/11 1:42 PM, Christer Holmberg wrote: > > Hi, > >>>>>> One could, for example, just put X into the Supported header, or a header like it. >>>>> >>>>> We would need something like Proxy-Supported. >>>> >>>> They're NOT proxies, but ya the name doesn't matter much. >>>> How about "Feature-Caps"? Too obvious? :) >>> >>> I would be ok with that :) >>> >>> >>>>> Havin said that, there is a new 3GPP use-case, which was agreed last >>>>> week (it will be described in the next version of the draft), where >>>>> it is not enough to indicate that features X and Y are supported by >>>>> SOME entities in the network - it must be possible to indicate that >>>>> features X and Y are supported by the SAME entity. It doesn't >>>>> necessarily mean that it must be possible to indicate WHICH entity >>>>> supports features X and Y, though, just to indicate that X and Y are >>>>> supported by the same entity. So, having a single R-R header where >>>>> you just collect and list feature tags taken from multiple R-R >>>>> headers would not work. >>>> >>>> >>>> That's easy... >>>> Feature-Caps: foo, bar, foo+bar >>> >>> Correct. The key is being able to use '+', in order to show that features are supported by the same entity. >> ' >> I *think* that hadriel had meant that if you wanted to be able to report that a single device had both foo and >> bar, you would define a new feature that was the sum of the other two, and then perhaps give it the name "foo+bar". > > I think that would be strange, and I am not sure whether it would work. Assuming we are using feature tags, and have an IANA registry, we > would have to register every possible feature tag combination, as each combination technically would be a unique feature tag :) > >> But, if we are defining a new header, I suppose it would indeed be possible to define "+" to be an >> operator indicating that. > > I would actually suggest that we use the same syntax as we do e.g. for Accept-Contact, where feature tag > values would be separated by ';' instead of '+'. > > So, we would get something like: Feature-Caps: foo, bar, foo;bar OK, this was all my misunderstanding. Since the intent is to dynamically compose them, the rest is syntactic nits. Using ";" would seem to be a path of least resistance. But I'm still struggling to understand why its necessary to know two features are in the same proxy or different proxies. And in the above, is ordering significant? (Does the example mean that a proxy with foo comes before a proxy with bar, which comes before a proxy with foo and bar? And for Hadriel: in your experience dealing with SBC customers, would that convey too much topology info, that you might be asked to suppress? >>>>> Also, a 3GPP application server can indicate support of services. >>>>> And, eventhough nothing is currently specified, I think that there >>>>> very likely could be use-cases where the S-CSCF needs to know WHICH >>>>> application servers support specific services, and in which order, >>>>> e.g. to making routing decissions etc. >>>>> >>>>> OK, then why would we want to indicate that in a header used for >>>>> dialog route-sets? >>>> >>>> Record-Route has a very specific purpose, to be used for the >>>> in-dialog route-set. And despite all examples in RFCs to the >>>> contrary, its URI is frequently an IP:host rather than a hostname. >>>> That's probably because devices want in-dialog requests coming in on >>>> the same instance/blade/interface that created the dialog, for a >>>> bunch of reasons. But a feature capability, especially one that >>>> would be useful for routing to for all-time, doesn't necessarily have >>>> that property. >>>> >>>> I.e., it's just as likely you'd want to indicate your whole >>>> App-Server system/cluster can do that feature, rather than the >>>> particular interface you're using for in-dialog request routing. >>> >>> In the current use-cases, when the feature support is indicated in INVITE/Record-Route, the >>> support only applies to the specific session established. Ie it is NOT a generic capability >>> support indication. >>> >>> But, as we have discussed before, the feature tag definition needs to define the scope when >>> support of a feature is indicated in INVITE, REGSTER etc. >> >> Do you really mean that feature "foo", when defined in REGISTER could have one scope (say, for all >> usage of the registered contact for the duration of the registration), while feature "bar" when defined >> in REGISTER could have some different scope? >> >> That would make it difficult to develop any generalized support for the mechanism. > > My *personal* preference would be to NOT do that, but instead specify that the scope of a feature tag in REGISTER is always the specific registration. OK, good. >> Or did you just mean that the mechanism would specify a particular scope for REGISTER, another for INVITE, etc. And >> then the registration would indicate applicability of the specific feature for use in REGISTER, INVITE, etc.? > > That would be my preference, yes. > > So, when indicated in INVITE, the feature is only valid for that dialog. > > But, the actual USAGE of the feature must of course be described in the feature tag definition, and even though the feature is only valid for a specific dialog, there is at least one use-case (see below) where the information is used when establishing another dialog. > > Use-case: In one of the use-cases an AS indicates that, for a given dialog, it provides SCC AS functionality. So, eventhough the SCC functionality only applies for that dialog, the information is then used when another dialog is established, in order to do handover for the dialog for which SCC functionality was indicated. I'm not sure I understand. I *think* you are saying that the SCC function provides the capability, within the dialog where it is indicated, to establish another dialog if this one fails. That doesn't seem like a special case to me. Whether that new dialog also has the SCC feature is a separate question. Thanks, Paul From oej@edvina.net Thu Oct 20 12:00:27 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D171F0CB0 for ; Thu, 20 Oct 2011 12:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDLrrZnHNGCc for ; Thu, 20 Oct 2011 12:00:26 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4381F0C76 for ; Thu, 20 Oct 2011 12:00:21 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 9235C754BCD5; Thu, 20 Oct 2011 19:00:18 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <4EA03A3E.7040406@nostrum.com> Date: Thu, 20 Oct 2011 21:00:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1251.1) Cc: sipcore@ietf.org Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 19:00:27 -0000 20 okt 2011 kl. 17:11 skrev Adam Roach: >=20 > On 10/20/11 9:22 AM, Olle E. Johansson wrote: >> Hi! >> Coming in rather late in the discussion, I don't know if I missed the = topic of security. >=20 > Thanks. It's not too late (although I certainly would have preferred = comments back during WGLC), but I think many of the issues you identify = are more applicable to SIP in general than SIP Events in particular. Well, we need to approach all RFCs an be more specific than now. I've = been spending a few weeks going through quite a lot of=20 RFCs and it's impossible to develop code from this framework. I took = this chance to jump on one piece of the puzzle and try to raise the bar. >=20 >> Having read RFC 3265 and some of the event specs, like mwi and = dialog, the security sections lack a lot and in some cases are texts = that are impossible for a developer to create running code from. >>=20 >> I think we need to write better text in 3265 biz for developers of = event packages to clarify requirements. >>=20 >> Like >>=20 >> * If you specify TLS usage, be very clear on certificate matching >> * If you specify S/MIME, be very clear on certificate matching and = usage >=20 > These, for example, are both general SIP problems. TLS certificate = matching is as much an issue for INVITE as it is for SUBSCRIBE. Absolutely. But there are cases where PUBLISH/SUBSCRIBE/NOTIFY = applications has special requirements and invents new stuff, like the PUBLISH in certificate handling that = bypasses SIP outbound and ob proxys to certify the server. If one comes up with that kind of requirements in the event = framework one needs to be very specific. Yes this applies to all SIP RFCs, but that's not an excuse to = not write it on the nose of this particular reader too :-) > This is also true for S/MIME. As you know, RFC5630 takes on the issue = of TLS handling in SIP, albeit with some of the issues you and I=F1aki = have raised on first-hop handling. I would argue that these should be = addressed in an RFC5630bis, not as a hasty addendum to SIP Events. Agree that it's a different story. Nevertheless, after reading all the = poorly specified documents I would like to raise the bar a bit, and since it is missing from other documents and this is kind of "how to = write an event package" I personally find it important to include these instructions here. >=20 > As far as I know, there has been no effort to explicitly address the = issue of S/MIME handling in SIP, although an effort similar in scope to = RFC5630 would probably be appropriate, if we're seeing real-world = problems in this area. After reading the RFCs, I understand why we have no real-word problems = in the area of S/MIME. I agree that we need to address that separately. But we should not let any more event packages just add a line saying "If = you need confidentiality use S/MIME". That is not helpful for anyone, = and=20 doesn't really work unless we are very clear which certificate's public = key to use for encryption. In subscribe/notify we have the issue where = we=20 can have p2p subscriptions, or subscriptions handled by a server that = gets updates by PUBLISH. Your quote below, that I missed and need to = recheck, addresses this issue. >=20 >=20 >> Also, require some message flows. >=20 > Section 5.4.12 calls out a SHOULD-level normative requirement to do = so. What would you suggest we change in that section? I'll check again. >=20 >> One of these, I don't remember which one, requires S/MIME for = confidentiality without specifying anything else. >> If I need to encrypt, how do I get the presence server certificate? = Or does the presence server need the keys for >> the target URI? >=20 > Presence is covered by RFC3856, which appears to be pretty clear on = which certs to use. Section 6.7 calls out: >=20 >> For reasons of privacy, it will frequently be necessary to encrypt >> the contents of the notifications. This can be accomplished using >> S/MIME. The encryption can be performed using the key of the >> subscriber as identified in the =46rom field of the SUBSCRIBE = request. >> Similarly, integrity of the notifications is important to >> subscribers. As such, the contents of the notifications MAY = provide >> authentication and message integrity using S/MIME. Since the = NOTIFY >> is generated by the presence server, which may not have access to = the >> key of the user represented by the presentity, it will frequently = be >> the case that the NOTIFY is signed by a third party. It is >> RECOMMENDED that the signature be by an authority over the domain = of >> the presentity. In other words, for a user pres:user@example.com, >> the signator of the NOTIFY SHOULD be the authority for example.com. THis is a good text, but only applies to the presence event package. I = was using "presence" in a more generic context, for any subscribe/notify event package. This should be used also for = other event packages and maybe imported as a generic example into this draft. >=20 > Turning back to RFC 3265 in particular -- I'm okay with adding some = very lightweight text along the lines of: >=20 >> 5.4.14 Confidentiality, Authentication, and Integrity >>=20 >> Event packages will typically convey information that requires >> some level of security protection. This may include protecting >> the information from eavesdropping, confirming the source of the >> information, and/or ensuring that the information has not been >> changed in transit. [RFC3261], as updated by [RFC5630], specifies >> the use of S/MIME and TLS for these purposes. >>=20 >> Event packages that specify the use of S/MIME, TLS, or other >> security technologies MUST include a description of the goals of >> such a security mechanism (in terms of the three properties of >> confidentiality, integrity, and authentication). Such event >> packages also MUST clearly indicate which certificates are used >> for the security mechanism, how they are acquired, and how >> implementations verify matching certificates. >>=20 >=20 Sounds like an improvement. I'll spend some more time going through this on my flight to SIPit and = during SIPit next week. Thanks for listening! /O= From oej@edvina.net Thu Oct 20 12:10:44 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9F021F84F8 for ; Thu, 20 Oct 2011 12:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZsHYOSHLGBV for ; Thu, 20 Oct 2011 12:10:43 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id B625F21F84C3 for ; Thu, 20 Oct 2011 12:10:43 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id CB315754BCD5; Thu, 20 Oct 2011 19:09:16 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <4EA03ECB.5030209@bell-labs.com> Date: Thu, 20 Oct 2011 21:09:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <23069CE8-4FEC-4561-A33B-9D9699F1B25D@edvina.net> References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> <4EA03ECB.5030209@bell-labs.com> To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.1251.1) Cc: sipcore@ietf.org Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 19:10:44 -0000 20 okt 2011 kl. 17:31 skrev Vijay K. Gurbani: > On 10/20/2011 10:11 AM, Adam Roach wrote: >>> Like >>>=20 >>> * If you specify TLS usage, be very clear on certificate matching >>> * If you specify S/MIME, be very clear on certificate matching and = usage >>=20 >> These, for example, are both general SIP problems. TLS certificate >> matching is as much an issue for INVITE as it is for SUBSCRIBE. This = is >> also true for S/MIME. As you know, RFC5630 takes on the issue of TLS >> handling in SIP, albeit with some of the issues you and I=F1aki have >> raised on first-hop handling. I would argue that these should be >> addressed in an RFC5630bis, not as a hasty addendum to SIP Events. >=20 > Note that rfc5922 has much more to say on the contents of the X.509 > certificates and matching identities in the certificate, etc. > than rfc5630 does. RFC 5922 was a huge improvement. It focused on server domain certs and we need to continue and take a look at the user agent certificates and the S/MIME infrastructure. I am trying to write a "hitchhiker's = overview" of this as a starting point.=20 Going through RFCs a developer gets very different messages about requirements on SIP UA certificates for TLS, S/MIME, UA-driven Identity = and MSRP. I would like us to clarify this in a way that we did SIPS and domain = certs. This discussion is of course a separate issue from RFC3265bis. >=20 > Insofar as determining whether or not a certificate is valid for SIP > usage or to determine which identity to match, I suspect that rfc5922 > will help. If there are any ambiguities in rfc5922 on these fronts, > then we can, of course, rectify them. Agree. There are many good drafts around that pinpoint issues with both TLS and other security issues, so there has been a lot of good work done in this area that we need to move forward on.=20 The main problem is lack of customer requirements. Regardless I see=20 more and more TLS and SRTP around, so something is changing out there.=20= For those of us that still believe in open Internet federation e-mail = style, we need the security framework to build trust for this way of thinking. Thanks for your feedback, Vijay! /O= From oej@edvina.net Thu Oct 20 12:11:19 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932481F0C38 for ; Thu, 20 Oct 2011 12:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sTgi+CeR-Ki for ; Thu, 20 Oct 2011 12:11:19 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF411F0C36 for ; Thu, 20 Oct 2011 12:11:19 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id 10D64754BCE6; Thu, 20 Oct 2011 19:10:28 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: <4EA03FC9.9030203@bell-labs.com> Date: Thu, 20 Oct 2011 21:10:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9B2AA0FA-5383-4584-A3E2-B4B83AAD96B8@edvina.net> References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> <4EA03FC9.9030203@bell-labs.com> To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.1251.1) Cc: sipcore@ietf.org Subject: Re: [sipcore] RFC 5924 - SIP EKU for TLS (new topic) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 19:11:19 -0000 20 okt 2011 kl. 17:35 skrev Vijay K. Gurbani: > On 10/20/2011 10:21 AM, I=F1aki Baz Castillo wrote: >> So we need something more, something radical and aggresive. Trying to >> add patches over the existing security specs is a no-go. Olle and me >> have some issues in mind (related to TLS and SIPS usage) for which >> there is no solution, they are bugs in the spec. >=20 > Please take a look at rfc5922, and to a lesser extent, rfc5924 to > see if it is able to answer any of your questions related to the > contents of X.509 certificates and how to determine their usage for > SIP. On the topic of RFC 5924 I wonder why this is classed experimental? /O= From christer.holmberg@ericsson.com Thu Oct 20 12:12:02 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521ED21F8ABD for ; Thu, 20 Oct 2011 12:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.075 X-Spam-Level: X-Spam-Status: No, score=-3.075 tagged_above=-999 required=5 tests=[AWL=-2.902, BAYES_00=-2.599, GB_SUMOF=5, J_CHICKENPOX_24=0.6, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5seQzPmRYJ4 for ; Thu, 20 Oct 2011 12:12:01 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 21EEA21F8532 for ; Thu, 20 Oct 2011 12:12:00 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-07-4ea072682fe1 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id CB.D6.20773.86270AE4; Thu, 20 Oct 2011 21:11:37 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 20 Oct 2011 21:11:36 +0200 From: Christer Holmberg To: 'Paul Kyzivat' Date: Thu, 20 Oct 2011 21:11:35 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AcyPVT7+lUvac+BrThGDhP/Ai/j+fAAAy1Tg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45FEF@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> In-Reply-To: <4EA066EB.40701@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 19:12:02 -0000 Hi,=20 >>>>>>> One could, for example, just put X into the Supported header, or a = header like it. >>>>>> >>>>>> We would need something like Proxy-Supported. >>>>> >>>>> They're NOT proxies, but ya the name doesn't matter much. >>>>> How about "Feature-Caps"? Too obvious? :) >>>> >>>> I would be ok with that :) >>>> >>>> >>>>>> Havin said that, there is a new 3GPP use-case, which was agreed=20 >>>>>> last week (it will be described in the next version of the draft),=20 >>>>>> where it is not enough to indicate that features X and Y are=20 >>>>>> supported by SOME entities in the network - it must be possible to=20 >>>>>> indicate that features X and Y are supported by the SAME entity.=20 >>>>>> It doesn't necessarily mean that it must be possible to indicate=20 >>>>>> WHICH entity supports features X and Y, though, just to indicate=20 >>>>>> that X and Y are supported by the same entity. So, having a single=20 >>>>>> R-R header where you just collect and list feature tags taken from=20 >>>>>> multiple R-R headers would not work. >>>>> >>>>> >>>>> That's easy... >>>>> Feature-Caps: foo, bar, foo+bar >>>> >>>> Correct. The key is being able to use '+', in order to show that featu= res are supported by the same entity. >>> ' >>> I *think* that hadriel had meant that if you wanted to be able to=20 >>> report that a single device had both foo and bar, you would define a ne= w feature that was the sum of the other two, and then perhaps give it the n= ame "foo+bar". >> >> I think that would be strange, and I am not sure whether it would=20 >> work. Assuming we are using feature tags, and have an IANA registry,=20 >> we would have to register every possible feature tag combination, as=20 >> each combination technically would be a unique feature tag :) >> >>> But, if we are defining a new header, I suppose it would indeed be=20 >>> possible to define "+" to be an operator indicating that. >> >> I would actually suggest that we use the same syntax as we do e.g. for=20 >> Accept-Contact, where feature tag values would be separated by ';' inste= ad of '+'. >> >> So, we would get something like: Feature-Caps: foo, bar, foo;bar > >OK, this was all my misunderstanding. Since the intent is to dynamically c= ompose them, the rest is syntactic nits. Using ";" would seem to be a path = of least resistance. > >But I'm still struggling to understand why its necessary to know two featu= res are in the same proxy or different proxies. I am going to submit a use-case where it needs to be seen that the features= are supported by the same proxy. >And in the above, is ordering significant? (Does the example mean that a p= roxy with foo comes before a proxy with bar, which comes before a proxy wit= h foo and bar? In the current use-cases I think the ordering is not significant, because t= here is only one "proxy" inserting feature tag(s) in the first place. But, in general I see no reason why the mechanism would not allow to indica= te that features are provided by the same proxy, and that features are list= ed in order. The mechanism we are discussing allows it, it doesn't really c= ause much additional complexity, and we would not have to define a new mech= anism in future if there comes use-cases where same-proxy and/or order is n= eeded. >>>>>> Also, a 3GPP application server can indicate support of services. >>>>>> And, eventhough nothing is currently specified, I think that there=20 >>>>>> very likely could be use-cases where the S-CSCF needs to know=20 >>>>>> WHICH application servers support specific services, and in which=20 >>>>>> order, e.g. to making routing decissions etc. >>>>>> >>>>>> OK, then why would we want to indicate that in a header used for=20 >>>>>> dialog route-sets? >>>>> >>>>> Record-Route has a very specific purpose, to be used for the=20 >>>>> in-dialog route-set. And despite all examples in RFCs to the=20 >>>>> contrary, its URI is frequently an IP:host rather than a hostname. >>>>> That's probably because devices want in-dialog requests coming in=20 >>>>> on the same instance/blade/interface that created the dialog, for a=20 >>>>> bunch of reasons. But a feature capability, especially one that=20 >>>>> would be useful for routing to for all-time, doesn't necessarily=20 >>>>> have that property. >>>>> >>>>> I.e., it's just as likely you'd want to indicate your whole=20 >>>>> App-Server system/cluster can do that feature, rather than the=20 >>>>> particular interface you're using for in-dialog request routing. >>>> >>>> In the current use-cases, when the feature support is indicated in=20 >>>> INVITE/Record-Route, the support only applies to the specific=20 >>>> session established. Ie it is NOT a generic capability support indicat= ion. >>>> >>>> But, as we have discussed before, the feature tag definition needs=20 >>>> to define the scope when support of a feature is indicated in INVITE, = REGSTER etc. >>> >>> Do you really mean that feature "foo", when defined in REGISTER could=20 >>> have one scope (say, for all usage of the registered contact for the=20 >>> duration of the registration), while feature "bar" when defined in REGI= STER could have some different scope? >>> >>> That would make it difficult to develop any generalized support for the= mechanism. >> >> My *personal* preference would be to NOT do that, but instead specify th= at the scope of a feature tag in REGISTER is always the specific registrati= on. > >OK, good. > >>> Or did you just mean that the mechanism would specify a particular=20 >>> scope for REGISTER, another for INVITE, etc. And then the registration = would indicate applicability of the specific feature for use in REGISTER, I= NVITE, etc.? >> >> That would be my preference, yes. >> >> So, when indicated in INVITE, the feature is only valid for that dialog. >> >> But, the actual USAGE of the feature must of course be described in the = feature tag definition, and even though=20 >> the feature is only valid for a specific dialog, there is at least one u= se-case (see below) where the=20 >> information is used when establishing another dialog. >> >> Use-case: In one of the use-cases an AS indicates that, for a given dial= og, it provides SCC AS functionality. So,=20 >> eventhough the SCC functionality only applies for that dialog, the infor= mation is then used when another dialog=20 >> is established, in order to do handover for the dialog for which SCC fun= ctionality was indicated. > > I'm not sure I understand. I *think* you are saying that the SCC function= provides the capability, within the dialog=20 > where it is indicated, to establish another dialog if this one fails. Tha= t doesn't seem like a special case to me.=20 > Whether that new dialog also has the SCC feature is a separate question. The SCC feature tag indicates that, for the specific dialog, the AS provide= s functionality in order to do handover. Using that information, the network knows that handover can be provided to = the specific session. And, when handover occurs another dialog is then crea= ted. So, the other dialog is created based on the fact that SCC functionali= ty is provided for the original dialog, but it does not mean that SCC is pr= ovided for the new dialog. SCC is still only provided to the original dialo= g, and the new dialog is only used to provide the SCC functionaltiy for the= original dialog. So, eventhough a feature only applies to a given dialog, the feature itself= can trigger out-of-dialog actions when executed. So, it should be alligned= with the scope we've discussed. Regards, Christer From oej@edvina.net Thu Oct 20 12:16:54 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25D11F0C36 for ; Thu, 20 Oct 2011 12:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rT35pmNxMxyc for ; Thu, 20 Oct 2011 12:16:54 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2CB1F0C34 for ; Thu, 20 Oct 2011 12:16:53 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id D30BB754BCD5; Thu, 20 Oct 2011 19:16:14 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_C8DF2874-D094-4594-BC0D-86FBFE7D104B" From: "Olle E. Johansson" In-Reply-To: <4EA04913.10106@alum.mit.edu> Date: Thu, 20 Oct 2011 21:16:24 +0200 Message-Id: <290A4107-F1D3-480D-B82D-9CF765C67437@edvina.net> References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> <4EA03ECB.5030209@bell-labs.com> <4EA04913.10106@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1251.1) Cc: sipcore@ietf.org Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 19:16:54 -0000 --Apple-Mail=_C8DF2874-D094-4594-BC0D-86FBFE7D104B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 20 okt 2011 kl. 18:15 skrev Paul Kyzivat: > I agree with Adam and Vijay here. I can't say I disagree. I am just looking for a bit more clear = instructions for writers of event packages than what we had before. >=20 > I'm not surprised if you are finding things unclear. It certainly = isn't the first time. But please identify the source of the ambiguity, = and if possible send text. Or if you don't know what text to propose, = please spell out the difficulties you have had is as much detail as you = can. Will try. Have never contributed text to RFCs so be nice :-) >=20 > We have attempted to address the security issues in the past. What you = see is what we were able to figure out at the time given perceived = constraints. But its been awhile. Now there may be better insight, = and/or a different understanding of the constraints. There's a huge difference between the nine year old RFC 3261 and the new = RFCs. I clearly see a new security framework coming together, but there = are still bits and pieces to complete and dots to connect. It may also = be time to start considering how DNSsec/DANE can contribute. I ranted a bit about just Subscribe/Notify RFCs and security in my blog = and tried to formulate my thoughts a few days ago, before jumping in on = this topic in this mailing list... http://www.voip-forum.com/ietf/2011-10/sip-security-mess/ /O >=20 > Thanks, > Paul >=20 > On 10/20/11 11:31 AM, Vijay K. Gurbani wrote: >> On 10/20/2011 10:11 AM, Adam Roach wrote: >>>> Like >>>>=20 >>>> * If you specify TLS usage, be very clear on certificate matching >>>> * If you specify S/MIME, be very clear on certificate matching and = usage >>>=20 >>> These, for example, are both general SIP problems. TLS certificate >>> matching is as much an issue for INVITE as it is for SUBSCRIBE. This = is >>> also true for S/MIME. As you know, RFC5630 takes on the issue of TLS >>> handling in SIP, albeit with some of the issues you and I=F1aki have >>> raised on first-hop handling. I would argue that these should be >>> addressed in an RFC5630bis, not as a hasty addendum to SIP Events. >>=20 >> Note that rfc5922 has much more to say on the contents of the X.509 >> certificates and matching identities in the certificate, etc. >> than rfc5630 does. >>=20 >> Insofar as determining whether or not a certificate is valid for SIP >> usage or to determine which identity to match, I suspect that rfc5922 >> will help. If there are any ambiguities in rfc5922 on these fronts, >> then we can, of course, rectify them. >>=20 >> Thanks, >>=20 >> - vijay >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden --Apple-Mail=_C8DF2874-D094-4594-BC0D-86FBFE7D104B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
I = agree with Adam and Vijay here.
I can't say I = disagree. I am just looking for a bit more clear instructions for = writers of event packages than what we had = before.


I'm not = surprised if you are finding things unclear. It certainly isn't the = first time. But please identify the source of the ambiguity, and if = possible send text. Or if you don't know what text to propose, please = spell out the difficulties you have had is as much detail as you = can.
Will try. Have never contributed text to RFCs = so be nice :-)


We have = attempted to address the security issues in the past. What you see is = what we were able to figure out at the time given perceived constraints. = But its been awhile. Now there may be better insight, and/or a different = understanding of the constraints.
There's a huge = difference between the nine year old RFC 3261 and the new RFCs. I = clearly see a new security framework coming together, but there are = still bits and pieces to complete and dots to connect. It may also be = time to start considering how DNSsec/DANE can = contribute.

I ranted a bit about just = Subscribe/Notify RFCs and security in my blog and tried to formulate my = thoughts a few days ago, before jumping in on this topic in this mailing = list...


/O

= Thanks,
Paul

On 10/20/11 11:31 AM, = Vijay K. Gurbani wrote:
On 10/20/2011 10:11 = AM, Adam Roach wrote:
Like

* If = you specify TLS usage, be very clear on certificate = matching
* If = you specify S/MIME, be very clear on certificate matching and = usage

These, for example, are both = general SIP problems. TLS = certificate
matching is as much an issue for = INVITE as it is for SUBSCRIBE. This = is
also true for S/MIME. As you know, RFC5630 takes on the = issue of TLS
handling in SIP, albeit with = some of the issues you and I=F1aki = have
raised on first-hop handling. I would argue that these = should be
addressed in an RFC5630bis, not = as a hasty addendum to SIP = Events.

Note that = rfc5922 has much more to say on the contents of the = X.509
certificates and = matching identities in the certificate, etc.
than rfc5630 does.

Insofar as = determining whether or not a certificate is valid for = SIP
usage or to determine = which identity to match, I suspect that = rfc5922
will help. If there = are any ambiguities in rfc5922 on these = fronts,
then we can, of = course, rectify them.

Thanks,

- = vijay

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

---
oej@edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 = 96 40 20, Sweden



= --Apple-Mail=_C8DF2874-D094-4594-BC0D-86FBFE7D104B-- From oej@edvina.net Thu Oct 20 12:36:18 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A631F0C4A for ; Thu, 20 Oct 2011 12:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0neiX3tRiHy for ; Thu, 20 Oct 2011 12:36:18 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 51F1E1F0C3D for ; Thu, 20 Oct 2011 12:36:16 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id A3285754BCD5; Thu, 20 Oct 2011 19:36:13 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_08EAB282-AB62-4FC1-83CA-E771D30614FB" From: "Olle E. Johansson" In-Reply-To: Date: Thu, 20 Oct 2011 21:36:23 +0200 Message-Id: <33FB4167-E95C-4A65-863D-67945C35C084@edvina.net> References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> <4EA03ECB.5030209@bell-labs.com> <4EA04913.10106@alum.mit.edu> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1251.1) Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "sipcore@ietf.org" Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 19:36:19 -0000 --Apple-Mail=_08EAB282-AB62-4FC1-83CA-E771D30614FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 20 okt 2011 kl. 18:40 skrev DRAGE, Keith (Keith): > But I agree with Adam's initial comment. RFC 3265bis is not the place = to make these clarifications, at least in as far as you have identified = issues at the moment. >=20 > Essentially you are talking a general SIP problem that requires = updates to RFC 3261 (even if it is only the addition of references).=20 IN a large part yes, but as I've tried to explain in previous responses = there's a specific issue in regards to Subscribe/notify that I don't want to see in new event packages. I'll try to clarify this, = based on Adam's text. >=20 > RFC 3265 doesn't invent the problem of carrying bodies, RFC 3261 does. Absolutely. The problem here is not that. In this case, it is unclear = what the other party is when you want confidentiality. Adam's quote from = the Presence event package had seen this, I missed that in dialog-info. = We propably need to make that text a more generic example and merge it. = Or not. I'll make up my mind at some point. >=20 > So the fix here is to take over where RFC 5630 left off. What you need = to do is an i-d to provide appropriate updates to RFC 3261 that address = required changes in the text of RFC 3261. Fully agree that we need to take over where 5630 left off. But I am kind = of stubborn in that we need to raise the requirements on authors of = event packages so that we'll get better quality in terms of security in = these. Right now my feeling is that some, but not all, authors thought = "oops, I need to add security before publishing this document, let's = just say that they can use TLS and/or S/MIME if they want to." We can do = better and have done better :-) >=20 > Put the change in 3265bis and you will create something specific for = event packages that misses all the other body usages in PUBLISH, REFER, = MESSAGE, INVITE, INFO, etc. We need to be careful so that we pinpoint the exact issue we want to = avoid in this particular document. Then roll up the old sleaves and get = to work in the direction you, Paul, Adam and Vijay has outlined in this = discussion. :-) /O >=20 > Keith >=20 >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On = Behalf >> Of I=F1aki Baz Castillo >> Sent: 20 October 2011 17:18 >> To: Paul Kyzivat >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 >>=20 >> 2011/10/20 Paul Kyzivat : >>> I agree with Adam and Vijay here. >>>=20 >>> I'm not surprised if you are finding things unclear. It certainly = isn't >> the >>> first time. But please identify the source of the ambiguity, and if >> possible >>> send text. Or if you don't know what text to propose, please spell = out >> the >>> difficulties you have had is as much detail as you can. >>>=20 >>> We have attempted to address the security issues in the past. What = you >> see >>> is what we were able to figure out at the time given perceived >> constraints. >>> But its been awhile. Now there may be better insight, and/or a = different >>> understanding of the constraints. >>=20 >> Hi Paul, let me (and Olle) some time to write a text describing = issues >> on the security specs (including those that I consider bugs rather >> than difficulties). >>=20 >> Thanks a lot. >>=20 >>=20 >> -- >> I=F1aki Baz Castillo >> >> _______________________________________________ >> 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 --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden --Apple-Mail=_08EAB282-AB62-4FC1-83CA-E771D30614FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
But I agree with Adam's initial comment. RFC 3265bis = is not the place to make these clarifications, at least in as far as you = have identified issues at the moment.

Essentially you are talking = a general SIP problem that requires updates to RFC 3261 (even if it is = only the addition of references).
IN a large part = yes, but as I've tried to explain in previous responses there's a = specific issue in regards to Subscribe/notify that
I don't = want to see in new event packages. I'll try to clarify this, based on = Adam's text.


RFC 3265 = doesn't invent the problem of carrying bodies, RFC 3261 = does.
Absolutely. The problem here is not that. In = this case, it is unclear what the other party is when you want = confidentiality. Adam's quote from the Presence event package had seen = this, I missed that in dialog-info. We propably need to make that text a = more generic example and merge it. Or not. I'll make up my mind at some = point.


So the fix here = is to take over where RFC 5630 left off. What you need to do is an i-d = to provide appropriate updates to RFC 3261 that address required changes = in the text of RFC 3261.
Fully agree that we need = to take over where 5630 left off. But I am kind of stubborn in that we = need to raise the requirements on authors of event packages so that = we'll get better quality in terms of security in these. Right now my = feeling is that some, but not all, authors thought "oops, I need to add = security before publishing this document, let's just say that they can = use TLS and/or S/MIME if they want to." We can do better and have done = better :-)

Put the change in = 3265bis and you will create something specific for event packages that = misses all the other body usages in PUBLISH, REFER, MESSAGE, INVITE, = INFO, etc.
We need to be careful so that we = pinpoint the exact issue we want to avoid in this particular document. = Then roll up the old sleaves and get to work in the direction you, Paul, = Adam and Vijay has outlined in this discussion. = :-)

/O

Keith

-----Original Message-----
From: sipcore-bounces@ietf.org = [mailto:sipcore-bounces@ietf.org] On Behalf
Of I=F1aki Baz Castillo
Sent: 20 October 2011 17:18
To: Paul Kyzivat
Cc: sipcore@ietf.org
Subject: Re: [sipcore] security and = draft-ietf-sipcore-rfc3265bis-04

2011/10/20 Paul = Kyzivat <pkyzivat@alum.mit.edu>:
I agree = with Adam and Vijay here.

I'm not surprised if you are = finding things unclear. It certainly = isn't
the
first time. But please identify the source of the = ambiguity, and if
possible
send text. Or if you don't know = what text to propose, please spell = out
the
difficulties you have had is as much detail as you = can.

We have attempted to address the = security issues in the past. What = you
see
is what we were able to figure out at the time given = perceived
constraints.
But its been awhile. Now there = may be better insight, and/or a = different
understanding of the = constraints.

Hi Paul, let me = (and Olle) some time to write a text describing = issues
on the security specs = (including those that I consider bugs rather
than difficulties).

Thanks a = lot.


--
I=F1aki Baz = Castillo
<ibc@aliax.net>
_______________________________________________
sipcore mailing = list
sipcore@ietf.org
https://www.ietf.or= g/mailman/listinfo/sipcore
___________________________= ____________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore

---
* Olle E = Johansson - oej@edvina.net
* Cell phone = +46 70 593 68 51, Office +46 8 96 40 20, Sweden



= --Apple-Mail=_08EAB282-AB62-4FC1-83CA-E771D30614FB-- From vkg@bell-labs.com Thu Oct 20 12:36:21 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889D21F0C56 for ; Thu, 20 Oct 2011 12:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.493 X-Spam-Level: X-Spam-Status: No, score=-106.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBC7PbKcS7n1 for ; Thu, 20 Oct 2011 12:36:20 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id AA7B21F0C4A for ; Thu, 20 Oct 2011 12:36:19 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p9KJaIwC020155 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 20 Oct 2011 14:36:19 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p9KJaIrv001554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 20 Oct 2011 14:36:18 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p9KJaIdc025916 for ; Thu, 20 Oct 2011 14:36:18 -0500 (CDT) Message-ID: <4EA078DD.3050802@bell-labs.com> Date: Thu, 20 Oct 2011 14:39:09 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: SIPCORE References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> <4EA03FC9.9030203@bell-labs.com> <9B2AA0FA-5383-4584-A3E2-B4B83AAD96B8@edvina.net> In-Reply-To: <9B2AA0FA-5383-4584-A3E2-B4B83AAD96B8@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [sipcore] RFC 5924 - SIP EKU for TLS (new topic) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 19:36:21 -0000 On 10/20/2011 02:10 PM, Olle E. Johansson wrote: > On the topic of RFC 5924 I wonder why this is classed experimental? You are asking me to dredge up memories that I have successfully suppressed, and even repressed, for the last few years ;-) Well, let me see ... IIRC, no one disagreed that using the EKU to signal that the private key holder is a SIP proxy (versus a SIP end point) is generally a good thing. What caused the EKU draft (rfc5924) to go the experimental route was that there was operational overhead involved with adding the EKU extension to certificates. The IESG felt that previous EKU extensions (such as rfc4334) did not see widespread deployment, and that the additional complexity it involves provides limited benefit. Furthermore, because one of the operational concerns of rfc5922 was to allow using existing certificates for SIP usage, it is apparent that already existing certificates would not have the SIP EKU usage specified. Therefore, to avoid the interoperability storm that was sure to arise, it was deemed best to make rfc5924 (the EKU draft) experimental to move the main draft (rfc5922) ahead. Hope this helps. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From oej@edvina.net Thu Oct 20 12:39:57 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6EF1F0C3D for ; Thu, 20 Oct 2011 12:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t39VSGsH17SX for ; Thu, 20 Oct 2011 12:39:57 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id D6E381F0C4D for ; Thu, 20 Oct 2011 12:39:56 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id B635D754BCD5; Thu, 20 Oct 2011 19:39:54 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <4EA078DD.3050802@bell-labs.com> Date: Thu, 20 Oct 2011 21:40:04 +0200 Content-Transfer-Encoding: 7bit Message-Id: <965756E2-5F7C-4660-8892-4C287E711083@edvina.net> References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> <4EA03FC9.9030203@bell-labs.com> <9B2AA0FA-5383-4584-A3E2-B4B83AAD96B8@edvina.net> <4EA078DD.3050802@bell-labs.com> To: "Vijay K. Gurbani" X-Mailer: Apple Mail (2.1251.1) Cc: SIPCORE Subject: Re: [sipcore] RFC 5924 - SIP EKU for TLS (new topic) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 19:39:57 -0000 20 okt 2011 kl. 21:39 skrev Vijay K. Gurbani: > On 10/20/2011 02:10 PM, Olle E. Johansson wrote: >> On the topic of RFC 5924 I wonder why this is classed experimental? > > You are asking me to dredge up memories that I have successfully > suppressed, and even repressed, for the last few years ;-) he he. My humble apologies for causing this pain :-) > > Well, let me see ... IIRC, no one disagreed that using the EKU to > signal that the private key holder is a SIP proxy (versus a SIP > end point) is generally a good thing. > > What caused the EKU draft (rfc5924) to go the experimental route > was that there was operational overhead involved with adding the > EKU extension to certificates. The IESG felt that previous EKU > extensions (such as rfc4334) did not see widespread deployment, > and that the additional complexity it involves provides limited > benefit. > > Furthermore, because one of the operational concerns of rfc5922 > was to allow using existing certificates for SIP usage, it > is apparent that already existing certificates would not have > the SIP EKU usage specified. Therefore, to avoid the interoperability > storm that was sure to arise, it was deemed best to make rfc5924 > (the EKU draft) experimental to move the main draft (rfc5922) ahead. > > Hope this helps. Yes, it makes me see what happened. In trying to get the different bits and pieces together, history helps some time. Thank you, Vijay! /O From christer.holmberg@ericsson.com Thu Oct 20 12:50:19 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7A31F0C34 for ; Thu, 20 Oct 2011 12:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugP7V0zulsho for ; Thu, 20 Oct 2011 12:50:18 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6E61721F8A64 for ; Thu, 20 Oct 2011 12:50:18 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-c9-4ea07b797240 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CB.86.13753.97B70AE4; Thu, 20 Oct 2011 21:50:17 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 20 Oct 2011 21:50:17 +0200 From: Christer Holmberg To: 'Paul Kyzivat' , "DRAGE, Keith (Keith)" Date: Thu, 20 Oct 2011 21:50:15 +0200 Thread-Topic: [sipcore] Accept in 18x Thread-Index: AcyPNrh5aK0MQMsXQNKsg5vw7KuViAAKVIDQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233D45FF1@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058522341206CF@ESESSCMS0356.eemea.ericsson.se> <2BC1CD824C2D4F47A6F6EC2705F4F4D803DD4E@Mail1.acmepacket.com> <4E946782.5050508@digium.com>, <7F2072F1E0DE894DA4B517B93C6A05852234120AA4@ESESSCMS0356.eemea.ericsson.se> <4E9748F9.3030404@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C0@ESESSCMS0356.eemea.ericsson.se> <4E9AFDA5.3010402@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE78E@ESESSCMS0356.eemea.ericsson.se>, <4E9C35F9.1020607@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B800@ESESSCMS0356.eemea.ericsson.se> <4E9F1E93.50102@alum.mit.edu> <4EA033B3.1030705@alum.mit.edu> In-Reply-To: <4EA033B3.1030705@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Accept in 18x X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 19:50:20 -0000 Hi,=20 >>> I am fast coming to the conclusion that rather than an errata, this iss= ue would=20 >>> be best dealt with by a quick internet draft. I see it not as intended = original=20 >>> functionality that somehow failed to get documented, but more as an ext= ension. >> >> An i-d would help us sort out what the procedures are really meant to be= . > > Keith, > > Are you talking about "Accept in 18x"? Or are you talking about Accept as= dialog state? > > We could handle Accept in 18x either as an errata or as a draft issued as= a clarification/extension.=20 > I expect there is more controversy over how to document it than there is = about the legitimacy of=20 > doing so. IMO its unlikely that this would cause any backward compatibili= ty issues. > > Accept as dialog state is more controversial. It could cause backward com= patibility problems if some=20 > UAs started considering a previously received Accept as a *contract* that= had to be honored until changed. > > Can someone explain to me what is driving this inquiry? Is there some spe= cific usage that needs this? I believe the issue was raised for a use-case where an Info Package (with a= n associated MIME) is used during the early dialog. Now, with Info Packages you will of course receive the Recv-Info header fie= ld, which indirectly indicates that the receiver supports any MIME associat= ed with the Info Package. However, the INFO RFC does say that one must also= explicitly indicate the supported MIMEs in Accept. But, in theory this applies to any MIME that one wants to use during the ea= rly dialog. ...including SDP, I guess. Because, eventhough no-Accept means support of S= DP, one could say that you can't claim no-Accept for an 18x since Accept is= not even defined for 18x :) But, the SDP case is not a real-life problem, as far as I know. Regards, Christer >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 >> Behalf Of Paul Kyzivat >> Sent: 19 October 2011 20:02 >> To: Christer Holmberg >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Accept in 18x >> >> Comment at end >> >> On 10/19/11 2:32 PM, Christer Holmberg wrote: >>> Hi, >>> >>>>>>> Do we have text explicitly saying that a Contact received in a=20 >>>>>>> provisional response is valid after 200 OK (unless you receive a=20 >>>>>>> Contact in the 200 OK, of course)? >>>>>> >>>>>> This is a change in subject from the original question. >>>>>> >>>>>> What are you looking for? Valid for *what*? >>>>>> >>>>>> Obviously its impossible to send a PRACK or an UPDATE on an early=20 >>>>>> dialog without having received a contact. In fact, I think we=20 >>>>>> have agreed that you don't have an early dialog unless you got a=20 >>>>>> contact in a provisional. >>>>> >>>>> That's not what I meant. >>>>> >>>>> The question was: if I receive a Contact in a 18x, is the Contact >> VALUE also valid after I have received the 200 OK? >>>>> >>>>> Obviously, if it's not, I can't send any in-dialog requests=20 >>>>> (including >> the ACK) after I've received the 200 OK. >>>> >>>> Well, there should also be a Contact in the 2xx, and typically it=20 >>>> would have the same value as the one in the 1xx for the same=20 >>>> dialog. Your question is only interesting if the two values are differ= ent. >>> >>> They could even be different in two different 1xx responses. >>> >>>> IIRC, 3261 specifies that the remote contact address is part of the=20 >>>> dialog state. And the remote contact is allowed to change. So each=20 >>>> time you get a new value it should supersede the prior value in the=20 >>>> dialog state, and then be used for subsequent in-dialog requests. >>> >>> Could we simply say the same thing for Accept - that it is part of=20 >>> the >> dialog state? >> >> There is no such requirement now, so that would be a change that=20 >> isn't backward compatible. >> >> Accept, and its definition, was inherited from HTTP. In HTTP I=20 >> believe the scope of validity of ACCEPT is limited to the response to th= e message. >> >> In the past I have commented that we have a number of properties such=20 >> as this whose scope is not well defined. In general I think you must=20 >> treat these as *hints*, while being prepared to discover that they=20 >> subsequently cease to be valid. >> >> Like many things, its hard for a 3pcc controller to assure the=20 >> preservation of such state on one of its dialogs, because there may=20 >> be a transfer on the "other side" to a device with different properties. >> >> Thanks, >> Paul >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > From ibc@aliax.net Thu Oct 20 13:06:00 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF471F0C43 for ; Thu, 20 Oct 2011 13:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9j7yqGFumZ0p for ; Thu, 20 Oct 2011 13:05:59 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 362861F0C34 for ; Thu, 20 Oct 2011 13:05:59 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3385653vcb.31 for ; Thu, 20 Oct 2011 13:05:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.34 with SMTP id e2mr11817578vdj.52.1319141158489; Thu, 20 Oct 2011 13:05:58 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Thu, 20 Oct 2011 13:05:58 -0700 (PDT) In-Reply-To: References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> Date: Thu, 20 Oct 2011 22:05:58 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Olle E. Johansson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 20:06:00 -0000 2011/10/20 Olle E. Johansson : > After reading the RFCs, I understand why we have no real-word problems in= the area of S/MIME. If you are really saying that "we have NO real-word problems in the area of S/MIME" I do know the response: Because nobody uses S/MIME in SIP. :) The same applies to SIPS schema. This is "Security by NO-Usage". I think we can/should do it better. --=20 I=C3=B1aki Baz Castillo From oej@edvina.net Thu Oct 20 13:18:08 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA3921F86FF for ; Thu, 20 Oct 2011 13:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0EqTSB2SU2u for ; Thu, 20 Oct 2011 13:18:07 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id 6D53F21F86EE for ; Thu, 20 Oct 2011 13:18:07 -0700 (PDT) Received: from [192.168.40.24] (ns.webway.se [87.96.134.125]) by smtp7.webway.se (Postfix) with ESMTPA id A6790754BCD5; Thu, 20 Oct 2011 20:18:04 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: "Olle E. Johansson" In-Reply-To: Date: Thu, 20 Oct 2011 22:18:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <25A32509-3D8F-4ACD-B334-739B8DB0E867@edvina.net> References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1251.1) Cc: sipcore@ietf.org Subject: Re: [sipcore] S/MIME (new topic) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 20:18:08 -0000 20 okt 2011 kl. 22:05 skrev I=F1aki Baz Castillo: > 2011/10/20 Olle E. Johansson : >> After reading the RFCs, I understand why we have no real-word = problems in the area of S/MIME. >=20 > If you are really saying that "we have NO real-word problems in the > area of S/MIME" I do know the response: >=20 > Because nobody uses S/MIME in SIP. :) I am not sure that this is true. In our part of the world, I agree. But = as there are implementations out there, someone must have asked for it. Maybe it was just check-box = items. What I meant was that as a developer, I get very few guide lines for = S/MIME usage and they are not really agreeing with each other or with other usages of a SIP UA = certificate. I would like to try to clarify this and it seems like many voices in this group agrees with that. I am really happy to hear = that. (Now, I did not expect anything else :-) ) >=20 > The same applies to SIPS schema. This is "Security by NO-Usage". I > think we can/should do it better. Regarding SIPS I think that's a long and interesting discussion, but = off-topic for now. I think Keith Drage earlier clarified that there are = still a lot of issues to clear up after the SIPS clarification RFC in = regards to general usage of TLS in sip, such as answering "why is = ;transport=3Dtls deprecated in RFC 3261?" and "where did it come from = anyway, since it doesn't show up in RFC 2543"?=20 We have a lot to do, and there are a lot of good drafts discussing this = topic, drafts that hasn't been pushed forward to RFC status, which = indicates to me that a lot of brain power has been put on this topic. = Now that we have a very different SIP framework compared with RFC 3261, = I think we should at some point toss the whole issue up in the air and = see what comes down when you look at SIP outbound, connection reuse, = identity and gruu's and much more on top of good ol' RFC 3261. But one = thing at a time. /O= From pkyzivat@alum.mit.edu Thu Oct 20 13:18:28 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9AC1F0C53 for ; Thu, 20 Oct 2011 13:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EP1IBGcjO6zi for ; Thu, 20 Oct 2011 13:18:28 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id C3AB71F0C3D for ; Thu, 20 Oct 2011 13:18:27 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta04.westchester.pa.mail.comcast.net with comcast id n8Gj1h0020bG4ec548JUd2; Thu, 20 Oct 2011 20:18:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta03.westchester.pa.mail.comcast.net with comcast id n8JT1h01t0tdiYw3P8JTB6; Thu, 20 Oct 2011 20:18:28 +0000 Message-ID: <4EA08210.2000501@alum.mit.edu> Date: Thu, 20 Oct 2011 16:18:24 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Olle E. Johansson" References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> <4EA03ECB.5030209@bell-labs.com> <4EA04913.10106@alum.mit.edu> <290A4107-F1D3-480D-B82D-9CF765C67437@edvina.net> In-Reply-To: <290A4107-F1D3-480D-B82D-9CF765C67437@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 20:18:28 -0000 On 10/20/11 3:16 PM, Olle E. Johansson wrote: > > 20 okt 2011 kl. 18:15 skrev Paul Kyzivat: > >> I agree with Adam and Vijay here. > I can't say I disagree. I am just looking for a bit more clear > instructions for writers of event packages than what we had before. > >> >> I'm not surprised if you are finding things unclear. It certainly >> isn't the first time. But please identify the source of the ambiguity, >> and if possible send text. Or if you don't know what text to propose, >> please spell out the difficulties you have had is as much detail as >> you can. > Will try. Have never contributed text to RFCs so be nice :-) We have been known to be nice, on a few occasions. :-) Usually I start out nice and get less nice as frustration builds. >> We have attempted to address the security issues in the past. What you >> see is what we were able to figure out at the time given perceived >> constraints. But its been awhile. Now there may be better insight, >> and/or a different understanding of the constraints. > There's a huge difference between the nine year old RFC 3261 and the new > RFCs. I clearly see a new security framework coming together, but there > are still bits and pieces to complete and dots to connect. It may also > be time to start considering how DNSsec/DANE can contribute. > > I ranted a bit about just Subscribe/Notify RFCs and security in my blog > and tried to formulate my thoughts a few days ago, before jumping in on > this topic in this mailing list... > > http://www.voip-forum.com/ietf/2011-10/sip-security-mess/ Good stuff. You just need to introduce it into the conversation here. Thanks, Paul > /O >> >> Thanks, >> Paul >> >> On 10/20/11 11:31 AM, Vijay K. Gurbani wrote: >>> On 10/20/2011 10:11 AM, Adam Roach wrote: >>>>> Like >>>>> >>>>> * If you specify TLS usage, be very clear on certificate matching >>>>> * If you specify S/MIME, be very clear on certificate matching and >>>>> usage >>>> >>>> These, for example, are both general SIP problems. TLS certificate >>>> matching is as much an issue for INVITE as it is for SUBSCRIBE. This is >>>> also true for S/MIME. As you know, RFC5630 takes on the issue of TLS >>>> handling in SIP, albeit with some of the issues you and Iñaki have >>>> raised on first-hop handling. I would argue that these should be >>>> addressed in an RFC5630bis, not as a hasty addendum to SIP Events. >>> >>> Note that rfc5922 has much more to say on the contents of the X.509 >>> certificates and matching identities in the certificate, etc. >>> than rfc5630 does. >>> >>> Insofar as determining whether or not a certificate is valid for SIP >>> usage or to determine which identity to match, I suspect that rfc5922 >>> will help. If there are any ambiguities in rfc5922 on these fronts, >>> then we can, of course, rectify them. >>> >>> Thanks, >>> >>> - vijay >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > --- > * Olle E Johansson - oej@edvina.net > * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden > > > From pkyzivat@alum.mit.edu Thu Oct 20 13:32:56 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE94211E80AB for ; Thu, 20 Oct 2011 13:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d77cQkvxiqI1 for ; Thu, 20 Oct 2011 13:32:55 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id B309D11E8090 for ; Thu, 20 Oct 2011 13:32:55 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta10.westchester.pa.mail.comcast.net with comcast id n8Ck1h0091YDfWL5A8YwlN; Thu, 20 Oct 2011 20:32:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta20.westchester.pa.mail.comcast.net with comcast id n8Yv1h00c0tdiYw3g8Yv19; Thu, 20 Oct 2011 20:32:56 +0000 Message-ID: <4EA08575.3020903@alum.mit.edu> Date: Thu, 20 Oct 2011 16:32:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A058522341206CF@ESESSCMS0356.eemea.ericsson.se> <2BC1CD824C2D4F47A6F6EC2705F4F4D803DD4E@Mail1.acmepacket.com> <4E946782.5050508@digium.com>, <7F2072F1E0DE894DA4B517B93C6A05852234120AA4@ESESSCMS0356.eemea.ericsson.se> <4E9748F9.3030404@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C0@ESESSCMS0356.eemea.ericsson.se> <4E9AFDA5.3010402@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE78E@ESESSCMS0356.eemea.ericsson.se>, <4E9C35F9.1020607@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B800@ESESSCMS0356.eemea.ericsson.se> <4E9F1E93.50102@alum.mit.edu> <4EA033B3.1030705@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FF1@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233D45FF1@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Accept in 18x X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 20:32:56 -0000 On 10/20/11 3:50 PM, Christer Holmberg wrote: > > Hi, > >>>> I am fast coming to the conclusion that rather than an errata, this issue would >>>> be best dealt with by a quick internet draft. I see it not as intended original >>>> functionality that somehow failed to get documented, but more as an extension. >>> >>> An i-d would help us sort out what the procedures are really meant to be. >> >> Keith, >> >> Are you talking about "Accept in 18x"? Or are you talking about Accept as dialog state? >> >> We could handle Accept in 18x either as an errata or as a draft issued as a clarification/extension. >> I expect there is more controversy over how to document it than there is about the legitimacy of >> doing so. IMO its unlikely that this would cause any backward compatibility issues. >> >> Accept as dialog state is more controversial. It could cause backward compatibility problems if some >> UAs started considering a previously received Accept as a *contract* that had to be honored until changed. >> >> Can someone explain to me what is driving this inquiry? Is there some specific usage that needs this? > > I believe the issue was raised for a use-case where an Info Package (with an associated MIME) is used during the early dialog. > > Now, with Info Packages you will of course receive the Recv-Info header field, which indirectly indicates that the receiver supports any MIME associated with the Info Package. However, the INFO RFC does say that one must also explicitly indicate the supported MIMEs in Accept. It is allowed to send a mime-type for which no Accept has been received. And of course it is also allowed to reject one you receive but don't accept. The critical usage is just in a transaction, to indicate in a request what you can take in a response, since you can't reject a response. All the other usages are just optimizations. > But, in theory this applies to any MIME that one wants to use during the early dialog. > > ...including SDP, I guess. Because, eventhough no-Accept means support of SDP, one could say that you can't claim no-Accept for an 18x since Accept is not even defined for 18x :) > > But, the SDP case is not a real-life problem, as far as I know. Same comments above apply. I guess this would become a real issue if the UAS for the INVITE wanted to say Accept:application/SDPng to encourage the UAC to send offers using SDPng rather than SDP. But we don't have to worry about that. Thanks, Paul > Regards, > > Christer > > > >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: 19 October 2011 20:02 >>> To: Christer Holmberg >>> Cc: sipcore@ietf.org >>> Subject: Re: [sipcore] Accept in 18x >>> >>> Comment at end >>> >>> On 10/19/11 2:32 PM, Christer Holmberg wrote: >>>> Hi, >>>> >>>>>>>> Do we have text explicitly saying that a Contact received in a >>>>>>>> provisional response is valid after 200 OK (unless you receive a >>>>>>>> Contact in the 200 OK, of course)? >>>>>>> >>>>>>> This is a change in subject from the original question. >>>>>>> >>>>>>> What are you looking for? Valid for *what*? >>>>>>> >>>>>>> Obviously its impossible to send a PRACK or an UPDATE on an early >>>>>>> dialog without having received a contact. In fact, I think we >>>>>>> have agreed that you don't have an early dialog unless you got a >>>>>>> contact in a provisional. >>>>>> >>>>>> That's not what I meant. >>>>>> >>>>>> The question was: if I receive a Contact in a 18x, is the Contact >>> VALUE also valid after I have received the 200 OK? >>>>>> >>>>>> Obviously, if it's not, I can't send any in-dialog requests >>>>>> (including >>> the ACK) after I've received the 200 OK. >>>>> >>>>> Well, there should also be a Contact in the 2xx, and typically it >>>>> would have the same value as the one in the 1xx for the same >>>>> dialog. Your question is only interesting if the two values are different. >>>> >>>> They could even be different in two different 1xx responses. >>>> >>>>> IIRC, 3261 specifies that the remote contact address is part of the >>>>> dialog state. And the remote contact is allowed to change. So each >>>>> time you get a new value it should supersede the prior value in the >>>>> dialog state, and then be used for subsequent in-dialog requests. >>>> >>>> Could we simply say the same thing for Accept - that it is part of >>>> the >>> dialog state? >>> >>> There is no such requirement now, so that would be a change that >>> isn't backward compatible. >>> >>> Accept, and its definition, was inherited from HTTP. In HTTP I >>> believe the scope of validity of ACCEPT is limited to the response to the message. >>> >>> In the past I have commented that we have a number of properties such >>> as this whose scope is not well defined. In general I think you must >>> treat these as *hints*, while being prepared to discover that they >>> subsequently cease to be valid. >>> >>> Like many things, its hard for a 3pcc controller to assure the >>> preservation of such state on one of its dialogs, because there may >>> be a transfer on the "other side" to a device with different properties. >>> >>> Thanks, >>> Paul >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> > > From vkg@bell-labs.com Thu Oct 20 13:56:39 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5019721F8557 for ; Thu, 20 Oct 2011 13:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.506 X-Spam-Level: X-Spam-Status: No, score=-106.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gq8pJUlIom3C for ; Thu, 20 Oct 2011 13:56:38 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 92A2221F84DD for ; Thu, 20 Oct 2011 13:56:38 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p9KKuYXJ023498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Oct 2011 15:56:34 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p9KKuXLV007964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Oct 2011 15:56:34 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p9KKuXuQ001314; Thu, 20 Oct 2011 15:56:33 -0500 (CDT) Message-ID: <4EA08BAC.1090401@bell-labs.com> Date: Thu, 20 Oct 2011 15:59:24 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: "Olle E. Johansson" References: <5529C16A-5CE4-4837-A790-5D4CCD94997C@edvina.net> <4EA03A3E.7040406@nostrum.com> <4EA03FC9.9030203@bell-labs.com> <9B2AA0FA-5383-4584-A3E2-B4B83AAD96B8@edvina.net> <4EA078DD.3050802@bell-labs.com> <965756E2-5F7C-4660-8892-4C287E711083@edvina.net> In-Reply-To: <965756E2-5F7C-4660-8892-4C287E711083@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: SIPCORE Subject: Re: [sipcore] RFC 5924 - SIP EKU for TLS (new topic) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 20:56:39 -0000 On 10/20/2011 02:40 PM, Olle E. Johansson wrote: [...] > Yes, it makes me see what happened. In trying to get the different bits > and pieces together, history helps some time. > Thank you, Vijay! In 2005-2006 timeframe when I had started to put TLS in my SIP stack, I encountered many gotchas and dead-ends on how to interpret the standard (at that time, only rfc3261). Back then, there were precious few public resources on SIP's use of TLS and X.509 certificates. The TLS module in Cullen's resiprocate server was an excellent first order resource to turn to. I attempted to codify some ambiguities as I encountered them in a draft; see [1] on the chance that some of this may be of interest to you as you dig deeper. A lot of the work in [1] was spawned off in different directions. The URI promotion was discussed, in part, in rfc5630; the authoritative proxy/mutual authentication/TLS site certificate work morphed into rfc5922 and rfc5924; the test cases in the Appendix ended up as Section 6 in rfc6216, the need for end-to-end security was discussed in [2], etc. Some of the meeting minutes, slides, and discussions from 2006 around the [1] and rfc5630 may also help you. They are archived on the IETF website. Hope all of this institutional memory serves you well as you plough ahead. [1] http://tools.ietf.org/html/draft-gurbani-sip-tls-use-00 [2] http://tools.ietf.org/html/draft-gurbani-sip-sipsec-01 Good luck! - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From HKaplan@acmepacket.com Thu Oct 20 15:07:05 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F0D11E80A4 for ; Thu, 20 Oct 2011 15:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oz6YNBAUpshJ for ; Thu, 20 Oct 2011 15:07:05 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5F811E8085 for ; Thu, 20 Oct 2011 15:07:05 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 20 Oct 2011 18:07:03 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 20 Oct 2011 18:07:04 -0400 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMj3SZReKwQTs3pUuTHfmHoA+xbQ== Date: Thu, 20 Oct 2011 22:07:03 +0000 Message-ID: <105D3FF9-483F-431D-B080-8399DB324682@acmepacket.com> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> In-Reply-To: <4EA066EB.40701@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <012D9F731F405D4BBBBB0AFAAD06EA55@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 22:07:06 -0000 On Oct 20, 2011, at 2:22 PM, Paul Kyzivat wrote: > And for Hadriel: in your experience dealing with SBC customers, would tha= t convey too much topology info, that you might be asked to suppress? I don't think so. It doesn't tell you who the nodes are, how many there ar= e, nor where they're at; and from a policy perspective it's easy to add/rem= ove for both blacklist and whitelist policy models. It's similar to the Supported header. But the difficulty with the Supporte= d header for all B2BUAs, which we should probably discuss out for this Feat= ure-Caps header, is that B2BUAs can't just blindly pass/copy Supported opti= on-tags through because they wouldn't know if the extension indicated by so= me random new option-tag would actually work "through" them. -hadriel From pkyzivat@alum.mit.edu Thu Oct 20 17:07:19 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF1F21F8B1A for ; Thu, 20 Oct 2011 17:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDkSNjqVpwum for ; Thu, 20 Oct 2011 17:07:19 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id E608E21F8B18 for ; Thu, 20 Oct 2011 17:07:18 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta05.westchester.pa.mail.comcast.net with comcast id nC3C1h0051uE5Es55C7KDZ; Fri, 21 Oct 2011 00:07:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta16.westchester.pa.mail.comcast.net with comcast id nC7J1h03D0tdiYw3cC7JcG; Fri, 21 Oct 2011 00:07:19 +0000 Message-ID: <4EA0B7B5.4060304@alum.mit.edu> Date: Thu, 20 Oct 2011 20:07:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E8C785D.5080003@alum.mit.edu> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <105D3FF9-483F-431D-B080-8399DB324682@acmepacket.com> In-Reply-To: <105D3FF9-483F-431D-B080-8399DB324682@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 00:07:19 -0000 On 10/20/11 6:07 PM, Hadriel Kaplan wrote: > > On Oct 20, 2011, at 2:22 PM, Paul Kyzivat wrote: >> And for Hadriel: in your experience dealing with SBC customers, would that convey too much topology info, that you might be asked to suppress? > > I don't think so. It doesn't tell you who the nodes are, how many there are, nor where they're at; and from a policy perspective it's easy to add/remove for both blacklist and whitelist policy models. It does put a lower bound on the number of proxies are on the path. If that was an unusually large number it might communicate something. But in practice maybe it won't be a large number even if there are a lot of proxies. Its also possible that the *pattern" of entries would communicate something about the topology of the deployment - perhaps indicate the specific equipment being used with some high probability. I personally don't care. ISTM that topology hiding is carrying paranoia to extremes. But obviously some do care. > It's similar to the Supported header. But the difficulty with the Supported header for all B2BUAs, which we should probably discuss out for this Feature-Caps header, is that B2BUAs can't just blindly pass/copy Supported option-tags through because they wouldn't know if the extension indicated by some random new option-tag would actually work "through" them. And the same sorts of difficulties may apply. Thanks, Paul From christer.holmberg@ericsson.com Fri Oct 21 02:22:01 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485CC21F8B9C for ; Fri, 21 Oct 2011 02:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.082 X-Spam-Level: X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QTA6ySuox-e for ; Fri, 21 Oct 2011 02:22:00 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 70FA221F8B85 for ; Fri, 21 Oct 2011 02:22:00 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-7d-4ea139b7b9c6 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A1.6F.20773.7B931AE4; Fri, 21 Oct 2011 11:21:59 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 21 Oct 2011 11:21:59 +0200 From: Christer Holmberg To: Paul Kyzivat , Hadriel Kaplan Date: Fri, 21 Oct 2011 11:21:58 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AcyPhWZU9/AzETclRoOhokxANRsSGwATFQ0A Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852234235BA5@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <105D3FF9-483F-431D-B080-8399DB324682@acmepacket.com> <4EA0B7B5.4060304@alum.mit.edu> In-Reply-To: <4EA0B7B5.4060304@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 09:22:01 -0000 Hi,=20 >>> And for Hadriel: in your experience dealing with SBC=20 >>> customers, would that convey too much topology info, that you=20 >>> might be asked to suppress? >> >> I don't think so. It doesn't tell you who the nodes are,=20 >> how many there are, nor where they're at; and from a policy=20 >> perspective it's easy to add/remove for both blacklist and=20 >> whitelist policy models. >=20 > It does put a lower bound on the number of proxies are on the path. > If that was an unusually large number it might communicate something. > But in practice maybe it won't be a large number even if=20 > there are a lot of proxies. >=20 > Its also possible that the *pattern" of entries would=20 > communicate something about the topology of the deployment -=20 > perhaps indicate the specific equipment being used with some=20 > high probability. >=20 > I personally don't care. ISTM that topology hiding is=20 > carrying paranoia to extremes. But obviously some do care. > >> It's similar to the Supported header. But the difficulty=20 >> with the Supported header for all B2BUAs, which we should=20 >> probably discuss out for this Feature-Caps header, is that=20 >> B2BUAs can't just blindly pass/copy Supported option-tags=20 >> through because they wouldn't know if the extension indicated=20 >> by some random new option-tag would actually work "through" them. >=20 > And the same sorts of difficulties may apply. An SBC can do whatever - and nothing we do can prevent that. However, my take of this discussion is that a new header would have a bigge= r chance of "surviving" than e.g. Record-Route, so can I start updating the= draft-holmberg draft based on such assumption? I think we have a pretty good idea on what we want to do, and I think the r= equirements are in pretty good shape, so I don't it would bring much value = in spending much more time on those. I also know that people will start to implement at least some of the 3GPP u= se-cases, so also from that perspective I think we need to show the path we= 're taking (eventhough nobody of course can expect all the details to be se= ttled from day one). Regards, Christer From HKaplan@acmepacket.com Fri Oct 21 02:47:17 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9591A21F8B47 for ; Fri, 21 Oct 2011 02:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E21SAhMtJihl for ; Fri, 21 Oct 2011 02:47:17 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9F621F8726 for ; Fri, 21 Oct 2011 02:47:16 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 21 Oct 2011 05:47:16 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 21 Oct 2011 05:47:16 -0400 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMj9Zp7e9HbN+JaEiDTL72Mu+SxA== Date: Fri, 21 Oct 2011 09:47:15 +0000 Message-ID: References: <4E8C785D.5080003@alum.mit.edu> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <105D3FF9-483F-431D-B080-8399DB324682@acmepacket.com> <4EA0B7B5.4060304@alum.mit.edu> In-Reply-To: <4EA0B7B5.4060304@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <13EFE265B7CDB94FA3C5BA6FBE64F8C2@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 09:47:17 -0000 On Oct 20, 2011, at 8:07 PM, Paul Kyzivat wrote: > It does put a lower bound on the number of proxies are on the path. Nope, just one node could have inserted every capability. And duplicates c= ould be removed, if the mechanism has them added. > Its also possible that the *pattern" of entries would communicate somethi= ng about the topology of the deployment - perhaps indicate the specific equ= ipment being used with some high probability. If that became a concern their list ordering could be randomized, but it's = never been an issue in Supported header.=20 > I personally don't care. ISTM that topology hiding is carrying paranoia t= o extremes. But obviously some do care. Yeah, there's topology hiding and then there's crazy topology hiding. Some= people even want Max-Forwards reset to 70 simply to hide the number of hop= s a request went through. -hadriel From internet-drafts@ietf.org Fri Oct 21 04:29:04 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C3A21F8B57; Fri, 21 Oct 2011 04:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xw4GQnY7bOy9; Fri, 21 Oct 2011 04:29:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7DD21F8B3F; Fri, 21 Oct 2011 04:29:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111021112903.30194.99185.idtracker@ietfa.amsl.com> Date: Fri, 21 Oct 2011 04:29:03 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-reqs-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 11:29:04 -0000 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 Work= ing Group of the IETF. Title : Requirements for indication of features supported by a S= IP proxy Author(s) : Christer Holmberg Ivo Sedlacek Filename : draft-ietf-sipcore-proxy-feature-reqs-02.txt Pages : 8 Date : 2011-10-21 The Session Initiation Protocol (SIP) "Caller Preferences" ext= ension defined in RFC 3840 provides a mechanism that allows a SIP message to convey information relating to the originator's supported features/ capabilities. This document defines requirements for a mechanism that would allow SIP proxies to convey information relating to the proxy's supported features/capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-proxy-feature-reqs-0= 2.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-proxy-feature-reqs-02= .txt From christer.holmberg@ericsson.com Fri Oct 21 04:32:14 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C62721F8BA8 for ; Fri, 21 Oct 2011 04:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.041 X-Spam-Level: X-Spam-Status: No, score=-6.041 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExhawvkQsbHp for ; Fri, 21 Oct 2011 04:32:13 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 56E9C21F8BA6 for ; Fri, 21 Oct 2011 04:32:13 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-71-4ea1583c9f28 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DE.4B.20773.C3851AE4; Fri, 21 Oct 2011 13:32:12 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 21 Oct 2011 13:32:12 +0200 From: Christer Holmberg To: "" Date: Fri, 21 Oct 2011 13:32:10 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-proxy-feature-reqs-02 [was: draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature] Thread-Index: AcyPhWZU9/AzETclRoOhokxANRsSGwATFQ0AAATDjAA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852234235CF7@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <105D3FF9-483F-431D-B080-8399DB324682@acmepacket.com> <4EA0B7B5.4060304@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852234235BA5@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852234235BA5@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-reqs-02 [was: draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 11:32:14 -0000 =20 Hi, I've submitted a new version (-02) of the proxy-feature reqs draft. It now contains a new use-case (section 1.2.3), where the SCC AS needs to d= etermine that features are supported by the SAME proxy. Based on that, I've also added a new requirement (new REQ-12), reflecting t= hat. Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 21. lokakuuta 2011 12:22 > To: Paul Kyzivat; Hadriel Kaplan > Cc: > Subject: Re: [sipcore]=20 > draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH=20 > proxy provides the feature >=20 >=20 > Hi,=20 >=20 > >>> And for Hadriel: in your experience dealing with SBC customers,=20 > >>> would that convey too much topology info, that you might=20 > be asked to=20 > >>> suppress? > >> > >> I don't think so. It doesn't tell you who the nodes are, how many=20 > >> there are, nor where they're at; and from a policy=20 > perspective it's=20 > >> easy to add/remove for both blacklist and whitelist policy models. > >=20 > > It does put a lower bound on the number of proxies are on the path. > > If that was an unusually large number it might communicate=20 > something. > > But in practice maybe it won't be a large number even if=20 > there are a=20 > > lot of proxies. > >=20 > > Its also possible that the *pattern" of entries would communicate=20 > > something about the topology of the deployment - perhaps=20 > indicate the=20 > > specific equipment being used with some high probability. > >=20 > > I personally don't care. ISTM that topology hiding is carrying=20 > > paranoia to extremes. But obviously some do care. > > > >> It's similar to the Supported header. But the difficulty with the=20 > >> Supported header for all B2BUAs, which we should probably=20 > discuss out=20 > >> for this Feature-Caps header, is that B2BUAs can't just blindly=20 > >> pass/copy Supported option-tags through because they=20 > wouldn't know if=20 > >> the extension indicated by some random new option-tag=20 > would actually=20 > >> work "through" them. > >=20 > > And the same sorts of difficulties may apply. >=20 > An SBC can do whatever - and nothing we do can prevent that. >=20 > However, my take of this discussion is that a new header=20 > would have a bigger chance of "surviving" than e.g.=20 > Record-Route, so can I start updating the draft-holmberg=20 > draft based on such assumption? >=20 > I think we have a pretty good idea on what we want to do, and=20 > I think the requirements are in pretty good shape, so I don't=20 > it would bring much value in spending much more time on those. >=20 > I also know that people will start to implement at least some=20 > of the 3GPP use-cases, so also from that perspective I think=20 > we need to show the path we're taking (eventhough nobody of=20 > course can expect all the details to be settled from day one). >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From pkyzivat@alum.mit.edu Fri Oct 21 07:17:15 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37EEA11E80C3 for ; Fri, 21 Oct 2011 07:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y69JsbgP8IT6 for ; Fri, 21 Oct 2011 07:17:13 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8701B11E80C0 for ; Fri, 21 Oct 2011 07:17:13 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta03.westchester.pa.mail.comcast.net with comcast id nS711h00D1uE5Es53SHDRA; Fri, 21 Oct 2011 14:17:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta16.westchester.pa.mail.comcast.net with comcast id nSHD1h00Z0tdiYw3cSHDx7; Fri, 21 Oct 2011 14:17:13 +0000 Message-ID: <4EA17EE7.4020809@alum.mit.edu> Date: Fri, 21 Oct 2011 10:17:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4E8C785D.5080003@alum.mit.edu> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <105D3FF9-483F-431D-B080-8399DB324682@acmepacket.com> <4EA0B7B5.4060304@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852234235BA5@ESESSCMS0356.eemea.ericsson.se > In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852234235BA5@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 14:17:15 -0000 On 10/21/11 5:21 AM, Christer Holmberg wrote: > > Hi, > >>>> And for Hadriel: in your experience dealing with SBC >>>> customers, would that convey too much topology info, that you >>>> might be asked to suppress? >>> >>> I don't think so. It doesn't tell you who the nodes are, >>> how many there are, nor where they're at; and from a policy >>> perspective it's easy to add/remove for both blacklist and >>> whitelist policy models. >> >> It does put a lower bound on the number of proxies are on the path. >> If that was an unusually large number it might communicate something. >> But in practice maybe it won't be a large number even if >> there are a lot of proxies. >> >> Its also possible that the *pattern" of entries would >> communicate something about the topology of the deployment - >> perhaps indicate the specific equipment being used with some >> high probability. >> >> I personally don't care. ISTM that topology hiding is >> carrying paranoia to extremes. But obviously some do care. >> >>> It's similar to the Supported header. But the difficulty >>> with the Supported header for all B2BUAs, which we should >>> probably discuss out for this Feature-Caps header, is that >>> B2BUAs can't just blindly pass/copy Supported option-tags >>> through because they wouldn't know if the extension indicated >>> by some random new option-tag would actually work "through" them. >> >> And the same sorts of difficulties may apply. > > An SBC can do whatever - and nothing we do can prevent that. > > However, my take of this discussion is that a new header would have a bigger chance of "surviving" than e.g. Record-Route, so can I start updating the draft-holmberg draft based on such assumption? > I think we have a pretty good idea on what we want to do, and I think the requirements are in pretty good shape, so I don't it would bring much value in spending much more time on those. You were going to provide a use case for your requirement to detect when two features are supported by the same server. I still find that mystifying. I also think we still should discuss what namespace these "features" come from. You had originally proposed that these be feature tags as defined in 3840, but with a twist that the meaning of features be different for proxies than for UAs. I guess the reason for proposing feature tags was that the mechanism for them already exists, and a certain similarity of attaching them to a URI. That was already a bit of a stretch because the semantics were a bit different. With the new mechanism being defined its a bit more of a stretch. Also, the syntax of values for feature tags is coupled to the callerpref matching algorithm. I have heard no suggestion of a matching algorithm for proxy features. (Though your concern for detecting the shared appearance of multiple features might imply one.) So, I'd like to see some discussion of the namespace and value space for proxy features. > I also know that people will start to implement at least some of the 3GPP use-cases, so also from that perspective I think we need to show the path we're taking (eventhough nobody of course can expect all the details to be settled from day one). People can start trial implementations whenever they want. Whether they are close to a final implementation won't be known until the end. Thanks, Paul From adam@nostrum.com Fri Oct 21 08:30:14 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884EB11E80A6 for ; Fri, 21 Oct 2011 08:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K24cMOTXvwXA for ; Fri, 21 Oct 2011 08:30:14 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB9C11E80A0 for ; Fri, 21 Oct 2011 08:30:13 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p9LFUCGk008452 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 21 Oct 2011 10:30:13 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4EA19004.60607@nostrum.com> Date: Fri, 21 Oct 2011 10:30:12 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se> <136491ED-390C-4A36-AE7C-06F89170EDFB@acmepacket.com> In-Reply-To: <136491ED-390C-4A36-AE7C-06F89170EDFB@acmepacket.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 15:30:14 -0000 On 10/19/11 10:13 AM, Hadriel Kaplan wrote: > The problem with UDP transport is message size, and especially getting SIP responses back. At some point, I have to imagine that people will start waking up to the absurd "don't do that then" quality of this problem. TCP isn't rocket science. /a From dworley@avaya.com Fri Oct 21 10:48:00 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CADA1F0C91 for ; Fri, 21 Oct 2011 10:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.329 X-Spam-Level: X-Spam-Status: No, score=-103.329 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COmtn15nJfq9 for ; Fri, 21 Oct 2011 10:47:59 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5451F0C8C for ; Fri, 21 Oct 2011 10:47:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOetoU7GmAcF/2dsb2JhbAA5CqkfgQWBbgEBAQECARIoRAsCAQgNCCEFCzIlAQEEARIIGodemEmbS4URgk5hBJlMjCs X-IronPort-AV: E=Sophos;i="4.69,387,1315195200"; d="scan'208";a="310404637" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Oct 2011 13:47:58 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Oct 2011 13:46:08 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Fri, 21 Oct 2011 13:47:57 -0400 From: "Worley, Dale R (Dale)" To: Christer Holmberg , "" Date: Fri, 21 Oct 2011 13:46:25 -0400 Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-reqs-02 [was: draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature] Thread-Index: AcyPhWZU9/AzETclRoOhokxANRsSGwATFQ0AAATDjAAADSRzBA== Message-ID: References: <4E8C785D.5080003@alum.mit.edu> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <105D3FF9-483F-431D-B080-8399DB324682@acmepacket.com> <4EA0B7B5.4060304@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852234235BA5@ESESSCMS0356.eemea.ericsson.se>, <7F2072F1E0DE894DA4B517B93C6A05852234235CF7@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852234235CF7@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-reqs-02 [was: draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 17:48:00 -0000 > From: Christer Holmberg [christer.holmberg@ericsson.com] >=20 > I've submitted a new version (-02) of the proxy-feature reqs draft. >=20 > It now contains a new use-case (section 1.2.3), where the SCC AS needs > to determine that features are supported by the SAME proxy. I assume that we are abandoning the concept that the mechanism must specifically identify which proxy supports each feature, since there is no new requirement for that. Dale From HKaplan@acmepacket.com Fri Oct 21 21:42:54 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC30E21F86A1 for ; Fri, 21 Oct 2011 21:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGY6bCusSoFc for ; Fri, 21 Oct 2011 21:42:54 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id AFAFF21F87E2 for ; Fri, 21 Oct 2011 21:42:52 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 22 Oct 2011 00:42:50 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sat, 22 Oct 2011 00:42:50 -0400 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMkHUNF0DiGgsizk+Lh/KPuzVSjQ== Date: Sat, 22 Oct 2011 04:42:49 +0000 Message-ID: <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> In-Reply-To: <4EA066EB.40701@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <442F164F162F764287BAD720866DE023@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 04:42:55 -0000 On Oct 20, 2011, at 2:22 PM, Paul Kyzivat wrote: >> I would actually suggest that we use the same syntax as we do e.g. for A= ccept-Contact, where feature tag >> values would be separated by ';' instead of '+'. >>=20 >> So, we would get something like: Feature-Caps: foo, bar, foo;bar >=20 > OK, this was all my misunderstanding. Since the intent is to dynamically = compose them, the rest is syntactic nits. Using ";" would seem to be a path= of least resistance. I know we're like waaay in the syntactic nits here, but I don't think just = a ";" would be right either. It made sense in Accept-Contact because the b= ase header value is "*" and every feature-tag is a header parameter. That = not only made sense per the rules of header fields and their parameters, bu= t also made it easier for people who write code that operates on header pie= ces using those conventions easier. (ie, lets you write header.getParam("fo= o") without having to also check if it was in the non-param portion) =20 Unless you're saying "foo;bar" is not the same as "bar;foo"? In other words, instead of this: Feature-Caps: foo Feature-Caps: foo;bar Feature-Caps: bar;foo We should probably do this: Feature-Caps: *;foo Feature-Caps: *;foo;bar Feature-Caps: *;bar;foo It looks ugly, but it's more logical methinks. -hadriel From christer.holmberg@ericsson.com Sat Oct 22 08:50:42 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29F521F86D0 for ; Sat, 22 Oct 2011 08:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.051 X-Spam-Level: X-Spam-Status: No, score=-6.051 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYU1xv0EA8vG for ; Sat, 22 Oct 2011 08:50:42 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9488821F86A0 for ; Sat, 22 Oct 2011 08:50:40 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a3-4ea2e64a483f Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 04.88.20773.A46E2AE4; Sat, 22 Oct 2011 17:50:34 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Sat, 22 Oct 2011 17:50:34 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Sat, 22 Oct 2011 17:50:33 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AcyP/CGxNdT4vi3NTrKLLUeV1OgMsgA0+6ol Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233C3B809@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <105D3FF9-483F-431D-B080-8399DB324682@acmepacket.com> <4EA0B7B5.4060304@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852234235BA5@ESESSCMS0356.eemea.ericsson.se>, <4EA17EE7.4020809@alum.mit.edu> In-Reply-To: <4EA17EE7.4020809@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 15:50:42 -0000 Hi, >>>>> And for Hadriel: in your experience dealing with SBC >>>>> customers, would that convey too much topology info, that you >>>>> might be asked to suppress? >>>> >>>> I don't think so. It doesn't tell you who the nodes are, >>>> how many there are, nor where they're at; and from a policy >>>> perspective it's easy to add/remove for both blacklist and >>>> whitelist policy models. >>> >>> It does put a lower bound on the number of proxies are on the path. >>> If that was an unusually large number it might communicate something. >>> But in practice maybe it won't be a large number even if >>> there are a lot of proxies. >>> >>> Its also possible that the *pattern" of entries would >>> communicate something about the topology of the deployment - >>> perhaps indicate the specific equipment being used with some >>> high probability. >>> >>> I personally don't care. ISTM that topology hiding is >>> carrying paranoia to extremes. But obviously some do care. >>> >>>> It's similar to the Supported header. But the difficulty >>>> with the Supported header for all B2BUAs, which we should >>>> probably discuss out for this Feature-Caps header, is that >>>> B2BUAs can't just blindly pass/copy Supported option-tags >>>> through because they wouldn't know if the extension indicated >>>> by some random new option-tag would actually work "through" them. >>> >>> And the same sorts of difficulties may apply. >> >> An SBC can do whatever - and nothing we do can prevent that. >> >> However, my take of this discussion is that a new header would have a bi= gger chance of "surviving" than e.g. Record-Route, so can I start updating = the draft-holmberg draft based on such assumption? > >> I think we have a pretty good idea on what we want to do, and I think th= e requirements are in pretty good shape, so I don't it would bring much val= ue in spending much more time on those. > >You were going to provide a use case for your requirement to detect when >two features are supported by the same server. I still find that mystifyin= g. See the new version (-03) of the draft. >I also think we still should discuss what namespace these "features" >come from. You had originally proposed that these be feature tags as >defined in 3840, but with a twist that the meaning of features be >different for proxies than for UAs. I guess the reason for proposing >feature tags was that the mechanism for them already exists, and a >certain similarity of attaching them to a URI. The feature tag concept is not defined in RFC 3840. RFC 3840 defines a SIP = specific feature tag syntax, and how SIP UAs use feature tags to indicate c= apabilities. The new mechanism would define how SIP "proxies" use feature tag to indicat= e capabilties. But, I agree that the semantics may vary depending on whether a UA or a "pr= oxy" inserts the feature tag, and the feature tag specification would have = to handle that. >That was already a bit of a stretch because the semantics were a bit >different. With the new mechanism being defined its a bit more of a >stretch. Also, the syntax of values for feature tags is coupled to the >callerpref matching algorithm. I have heard no suggestion of a matching >algorithm for proxy features. (Though your concern for detecting the >shared appearance of multiple features might imply one.) I am not sure I understand how the syntax is coupled to the callerpref mach= ing mechanism. And, even if it is, I see no reason why we can't use the same syntax for pr= oxies - even if we would not use them for matching. >>So, I'd like to see some discussion of the namespace and value space for = proxy features. I personally see no reason why feature tags wouldn't work, and why we would= need to define a new way of indicating feature support. >> I also know that people will start to implement at least some of the 3GP= P use-cases, so also from that perspective I think we=20 >> need to show the path we're taking (eventhough nobody of course can expe= ct all the details to be settled from day one). > >People can start trial implementations whenever they want. Whether they >are close to a final implementation won't be known until the end. SDOs, currently mainly 3GPP, are also defining features using the mechanism= . Anyway, my point is that I personally think we are at a stage where we can = start work on the protocol mechanism. Of course there will be lots of detai= ls that we have to sort out along the road, but that is part of our normal = work in IETF :) Regards, Christer From christer.holmberg@ericsson.com Sat Oct 22 08:51:32 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C078E21F877F for ; Sat, 22 Oct 2011 08:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.061 X-Spam-Level: X-Spam-Status: No, score=-6.061 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LPGLYTG5125 for ; Sat, 22 Oct 2011 08:51:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1868021F86D0 for ; Sat, 22 Oct 2011 08:51:31 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f4-4ea2e683b859 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 04.98.20773.386E2AE4; Sat, 22 Oct 2011 17:51:31 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Sat, 22 Oct 2011 17:51:30 +0200 From: Christer Holmberg To: "Worley, Dale R (Dale)" , "" Date: Sat, 22 Oct 2011 17:50:39 +0200 Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-reqs-02 [was: draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature] Thread-Index: AcyPhWZU9/AzETclRoOhokxANRsSGwATFQ0AAATDjAAADSRzBAAuPiGQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233C3B80A@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <105D3FF9-483F-431D-B080-8399DB324682@acmepacket.com> <4EA0B7B5.4060304@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852234235BA5@ESESSCMS0356.eemea.ericsson.se>, <7F2072F1E0DE894DA4B517B93C6A05852234235CF7@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-reqs-02 [was: draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 15:51:32 -0000 Hi, >> I've submitted a new version (-02) of the proxy-feature reqs draft. >> >> It now contains a new use-case (section 1.2.3), where the SCC AS needs >> to determine that features are supported by the SAME proxy. > >I assume that we are abandoning the concept that the mechanism must >specifically identify which proxy supports each feature, since there >is no new requirement for that. Yes. Regards, Christer From christer.holmberg@ericsson.com Sat Oct 22 08:56:26 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A290021F84CF for ; Sat, 22 Oct 2011 08:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.77 X-Spam-Level: X-Spam-Status: No, score=-5.77 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWURXwCtREnj for ; Sat, 22 Oct 2011 08:56:26 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B794A21F8551 for ; Sat, 22 Oct 2011 08:56:25 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-83-4ea2e7a7dd5e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 2B.F4.13753.7A7E2AE4; Sat, 22 Oct 2011 17:56:23 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Sat, 22 Oct 2011 17:56:23 +0200 From: Christer Holmberg To: Hadriel Kaplan , Paul Kyzivat Date: Sat, 22 Oct 2011 17:52:37 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMkHUNF0DiGgsizk+Lh/KPuzVSjZWIhEgK Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233C3B80B@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu>, <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com> In-Reply-To: <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 15:56:26 -0000 Hi, >>> I would actually suggest that we use the same syntax as we do e.g. for = Accept-Contact, where feature tag >>> values would be separated by ';' instead of '+'. >>> >>> So, we would get something like: Feature-Caps: foo, bar, foo;bar >> >> OK, this was all my misunderstanding. Since the intent is to dynamically= compose them, the rest is syntactic nits. Using ";" would seem to be a pat= h of least resistance. > >I know we're like waaay in the syntactic nits here, but I don't think just= a ";" would be right either. It made sense in Accept-Contact because the = base header value is "*" and every >feature-tag is a header parameter. That not only made sense per the rules= of header fields and their parameters, but also made it easier for people = who write code that operates=20 >on header pieces using those conventions easier. (ie, lets you write heade= r.getParam("foo") without having to also check if it was in the non-param p= ortion) > >Unless you're saying "foo;bar" is not the same as "bar;foo"? I am not saying that. >In other words, instead of this: >Feature-Caps: foo >Feature-Caps: foo;bar >Feature-Caps: bar;foo > >We should probably do this: >Feature-Caps: *;foo >Feature-Caps: *;foo;bar >Feature-Caps: *;bar;foo > >It looks ugly, but it's more logical methinks. I don't see why that would be needed. UAs don't do that when indicating cap= abilities in Contact either. Regards, Christer From HKaplan@acmepacket.com Sat Oct 22 09:32:49 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5FB21F8677 for ; Sat, 22 Oct 2011 09:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Mz8sSHdRxaV for ; Sat, 22 Oct 2011 09:32:48 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8048621F85A4 for ; Sat, 22 Oct 2011 09:32:48 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 22 Oct 2011 12:32:45 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sat, 22 Oct 2011 12:32:45 -0400 From: Hadriel Kaplan To: Christer Holmberg Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMkNg5Q2kXed98CkOsmz1XdDQ5rg== Date: Sat, 22 Oct 2011 16:32:44 +0000 Message-ID: References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu>, <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233C3B80B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233C3B80B@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <2ABAEFABB489DD45B13137CCFFA3F48A@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 16:32:49 -0000 On Oct 22, 2011, at 11:52 AM, Christer Holmberg wrote: >> In other words, instead of this: >> Feature-Caps: foo >> Feature-Caps: foo;bar >> Feature-Caps: bar;foo >>=20 >> We should probably do this: >> Feature-Caps: *;foo >> Feature-Caps: *;foo;bar >> Feature-Caps: *;bar;foo >>=20 >> It looks ugly, but it's more logical methinks. >=20 > I don't see why that would be needed. UAs don't do that when indicating c= apabilities in Contact either. Because in the Contact they're already _always_ header-parameters. I.e., this: Contact: sip:u3@h.example.com;audio;actor=3D"msg-taker";methods=3D"INVIT= E";video;q=3D0.3 The base value of the header field is the URI "sip:u3@h.example.com", where= as all the capabilities are parameters of the Contact header field, some wi= th param values, some just the param names/tokens. Doing "Feature-Caps: foo;bar" would mean the header base value would be "fo= o" whereas "bar" would be a header param, while "Feature-Caps: bar;foo" wou= ld mean the base value would be "bar" while the param is "foo". Thus they = wouldn't compare equally from a SIP comparison operation perspective, even = though semantically we mean them to be the same. But here's also a good reason: if we ever did need to extend Feature-Caps t= o indicate which node supported the feature, we could change the "*" value = to be a URI or addr-spec. So you can think of the "*" as the current heade= r value meaning *one or more nodes* in this SIP message routing path suppor= t the Feature-Caps extension mechanism with the parameters of this header, = whereas if we do a URI/addr-spec later it means *this specific node* in thi= s SIP message routing path supports the Feature-Caps extension mechanism wi= th the parameters of this header. -hadriel From christer.holmberg@ericsson.com Sun Oct 23 01:54:43 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE56121F8B22 for ; Sun, 23 Oct 2011 01:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.77 X-Spam-Level: X-Spam-Status: No, score=-5.77 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRHzM06mmH0O for ; Sun, 23 Oct 2011 01:54:43 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFC321F8B2A for ; Sun, 23 Oct 2011 01:54:42 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ef-4ea3d6512843 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BD.0F.20773.156D3AE4; Sun, 23 Oct 2011 10:54:42 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sun, 23 Oct 2011 10:54:41 +0200 From: Christer Holmberg To: Hadriel Kaplan Date: Sun, 23 Oct 2011 10:52:13 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AQHMkNg5Q2kXed98CkOsmz1XdDQ5rpWJoG0c Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233C3B80D@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu>, <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233C3B80B@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 08:54:44 -0000 Hi Hadriel, >>> In other words, instead of this: >>> Feature-Caps: foo >>> Feature-Caps: foo;bar >>> Feature-Caps: bar;foo >>> >>> We should probably do this: >>> Feature-Caps: *;foo >>> Feature-Caps: *;foo;bar >>> Feature-Caps: *;bar;foo >>> >>> It looks ugly, but it's more logical methinks. >> >> I don't see why that would be needed. UAs don't do that when indicating = capabilities in Contact either. > >Because in the Contact they're already _always_ header-parameters. > >I.e., this: >Contact: sip:u3@h.example.com;audio;actor=3D"msg-taker";methods=3D"INVITE"= ;video;q=3D0.3 > >The base value of the header field is the URI "sip:u3@h.example.com", wher= eas all the capabilities are parameters of the Contact header field,=20 >some with param values, some just the param names/tokens. > >Doing "Feature-Caps: foo;bar" would mean the header base value would be "f= oo" whereas "bar" would be a header param, while "Feature-Caps: bar;foo"=20 >would mean the base value would be "bar" while the param is "foo". Thus t= hey wouldn't compare equally from a SIP comparison operation perspective, e= ven=20 >though semantically we mean them to be the same. Aaah... now I understand what you mean. I guess you are right. >But here's also a good reason: if we ever did need to extend Feature-Caps = to indicate which node supported the feature, we could change the "*" value= =20 >to be a URI or addr-spec. So you can think of the "*" as the current head= er value meaning *one or more nodes* in this SIP message routing path suppo= rt >the Feature-Caps extension mechanism with the parameters of this header, w= hereas if we do a URI/addr-spec later it means *this specific node* in this= SIP=20 >message routing path supports the Feature-Caps extension mechanism with th= e parameters of this header. Sounds like a good idea. Regards, Christer From christer.holmberg@ericsson.com Tue Oct 25 06:22:39 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D11E21F8B09 for ; Tue, 25 Oct 2011 06:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+WV+HeSYX4j for ; Tue, 25 Oct 2011 06:22:38 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 46B9221F8AE9 for ; Tue, 25 Oct 2011 06:22:38 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-03-4ea6b81d17b8 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9C.5A.13753.D18B6AE4; Tue, 25 Oct 2011 15:22:37 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Tue, 25 Oct 2011 15:22:37 +0200 From: Christer Holmberg To: "" Date: Tue, 25 Oct 2011 15:22:35 +0200 Thread-Topic: draft-ietf-sipcore-proxy-feature-reqs-01 - New header field and direction Thread-Index: AQHMkNg5Q2kXed98CkOsmz1XdDQ5rpWJoG0cgANuOBA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585223428C7C6@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu>, <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233C3B80B@ESESSCMS0356.eemea.ericsson.se>, <7F2072F1E0DE894DA4B517B93C6A05852233C3B80D@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233C3B80D@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - New header field and direction X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 13:22:39 -0000 =20 Hi, Another very good advantage of using a new header field would be that we wi= ll could solve the directionality issue, ie whether a supported feature onl= y applies towards downstream entities, upstream entities, or both. The problem with Record-Route is that the header fields, including all valu= es, are copied from the request into the response by the UAS. But, with a new header field it would be possible to use it independently i= n requests and responses, as the header would NOT be copied from the reques= t intot the response. Ie a "proxy" could indicate support of features in SIP requests and/or SIP = responses, depending on in which direction the support indication applies. Regards, Christer From keith.drage@alcatel-lucent.com Tue Oct 25 06:52:27 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD8821F8B3C for ; Tue, 25 Oct 2011 06:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.965 X-Spam-Level: X-Spam-Status: No, score=-105.965 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fNeXPCipRQi for ; Tue, 25 Oct 2011 06:52:26 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF7E21F8B27 for ; Tue, 25 Oct 2011 06:52:26 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p9PDqMDB021168 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 25 Oct 2011 15:52:23 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 25 Oct 2011 15:52:23 +0200 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , "" Date: Tue, 25 Oct 2011 15:52:20 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - New header field and direction Thread-Index: AQHMkNg5Q2kXed98CkOsmz1XdDQ5rpWJoG0cgANuOBCAAAhZ4A== Message-ID: References: <4E8C785D.5080003@alum.mit.edu> <4E8E0D3E.6060704@alum.mit.edu>, <7F2072F1E0DE894DA4B517B93C6A05852233D45FE6@ESESSCMS0356.eemea.ericsson.se> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu>, <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233C3B80B@ESESSCMS0356.eemea.ericsson.se>, <7F2072F1E0DE894DA4B517B93C6A05852233C3B80D@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585223428C7C6@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585223428C7C6@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - New header field and direction X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 13:52:27 -0000 I assume we are still talking about a URI parameter, i.e. the data relates = primarily to the URI in which it is attached, rather than to the header fie= ld in which it appears. I guess if we invented a new header field to carry such URIs, two questions= would have to be answered: 1) What happens if the new URI parameter is still attached to one of the ol= d header fields, e.g. an implementation receives a Record-Route header fiel= d with the new URI parameter indicating supported features attached to it. 2) We have existing URI parameters attached to existing header fields. For = example "sigcomp-id". What does a recipient do when it receives these exist= ing URI parameters attached to URIs in the new header field. Regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Christer Holmberg > Sent: 25 October 2011 14:23 > To: > Subject: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - New header > field and direction >=20 >=20 > Hi, >=20 > Another very good advantage of using a new header field would be that we > will could solve the directionality issue, ie whether a supported feature > only applies towards downstream entities, upstream entities, or both. >=20 > The problem with Record-Route is that the header fields, including all > values, are copied from the request into the response by the UAS. >=20 > But, with a new header field it would be possible to use it independently > in requests and responses, as the header would NOT be copied from the > request intot the response. >=20 > Ie a "proxy" could indicate support of features in SIP requests and/or SI= P > responses, depending on in which direction the support indication applies= . >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Tue Oct 25 07:12:45 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D3721F877F for ; Tue, 25 Oct 2011 07:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aCe5SmWF0QA for ; Tue, 25 Oct 2011 07:12:44 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 870E021F8770 for ; Tue, 25 Oct 2011 07:12:44 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA11.westchester.pa.mail.comcast.net with comcast id p2431h0040cZkys5B2ClXU; Tue, 25 Oct 2011 14:12:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta10.westchester.pa.mail.comcast.net with comcast id p2Ck1h0070tdiYw3W2CkJC; Tue, 25 Oct 2011 14:12:45 +0000 Message-ID: <4EA6C3DA.6000605@alum.mit.edu> Date: Tue, 25 Oct 2011 10:12:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E8C785D.5080003@alum.mit.edu> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com> In-Reply-To: <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 14:12:45 -0000 In my reply I was assuming that this new header contained no URI - every field contains one or more feature caps. I realize that is inconsistent with what was done in 3841. The history of 3841 was that Accept-Contact originally allowed an optional URI, which was matched against candidate contacts. Eventually the draft evolved to where we abandoned that, but retained the header syntax, but only in the wildcard form, not with an explicit URI. We can argue the pros/cons of following the syntax of Accept-Contact if you wish. But using "+" as a separator won't work if we are using the feature tag notation used in 3840. Some of those tags contain a leading "+" character. Thanks, Paul On 10/22/11 12:42 AM, Hadriel Kaplan wrote: > > On Oct 20, 2011, at 2:22 PM, Paul Kyzivat wrote: > >>> I would actually suggest that we use the same syntax as we do e.g. for Accept-Contact, where feature tag >>> values would be separated by ';' instead of '+'. >>> >>> So, we would get something like: Feature-Caps: foo, bar, foo;bar >> >> OK, this was all my misunderstanding. Since the intent is to dynamically compose them, the rest is syntactic nits. Using ";" would seem to be a path of least resistance. > > I know we're like waaay in the syntactic nits here, but I don't think just a ";" would be right either. It made sense in Accept-Contact because the base header value is "*" and every feature-tag is a header parameter. That not only made sense per the rules of header fields and their parameters, but also made it easier for people who write code that operates on header pieces using those conventions easier. (ie, lets you write header.getParam("foo") without having to also check if it was in the non-param portion) > > Unless you're saying "foo;bar" is not the same as "bar;foo"? > > In other words, instead of this: > Feature-Caps: foo > Feature-Caps: foo;bar > Feature-Caps: bar;foo > > We should probably do this: > Feature-Caps: *;foo > Feature-Caps: *;foo;bar > Feature-Caps: *;bar;foo > > It looks ugly, but it's more logical methinks. > > -hadriel > > From pkyzivat@alum.mit.edu Tue Oct 25 07:17:20 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6DC21F8ADC for ; Tue, 25 Oct 2011 07:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CumOnDobaSI1 for ; Tue, 25 Oct 2011 07:17:20 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4155E21F8A69 for ; Tue, 25 Oct 2011 07:17:20 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta06.westchester.pa.mail.comcast.net with comcast id p2431h0010cZkys562HLz2; Tue, 25 Oct 2011 14:17:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta10.westchester.pa.mail.comcast.net with comcast id p2HL1h00q0tdiYw3W2HL3m; Tue, 25 Oct 2011 14:17:20 +0000 Message-ID: <4EA6C4EE.4000502@alum.mit.edu> Date: Tue, 25 Oct 2011 10:17:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <4E8C785D.5080003@alum.mit.edu> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu>, <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233C3B80B@ESESSCMS0356.eemea.ericsson.se>, <7F2072F1E0DE894DA4B517B93C6A05852233C3B80D@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585223428C7C6@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - New header field and direction X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 14:17:21 -0000 On 10/25/11 9:52 AM, DRAGE, Keith (Keith) wrote: > I assume we are still talking about a URI parameter, i.e. the data relates primarily to the URI in which it is attached, rather than to the header field in which it appears. I don't think so. AFAIK we are talking about a header field parameter. That is what the feature tags on Contact and Accept-Contact are, and those have been used as the analogy. Thanks, Paul > I guess if we invented a new header field to carry such URIs, two questions would have to be answered: > > 1) What happens if the new URI parameter is still attached to one of the old header fields, e.g. an implementation receives a Record-Route header field with the new URI parameter indicating supported features attached to it. > > 2) We have existing URI parameters attached to existing header fields. For example "sigcomp-id". What does a recipient do when it receives these existing URI parameters attached to URIs in the new header field. > > Regards > > Keith > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf >> Of Christer Holmberg >> Sent: 25 October 2011 14:23 >> To: >> Subject: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - New header >> field and direction >> >> >> Hi, >> >> Another very good advantage of using a new header field would be that we >> will could solve the directionality issue, ie whether a supported feature >> only applies towards downstream entities, upstream entities, or both. >> >> The problem with Record-Route is that the header fields, including all >> values, are copied from the request into the response by the UAS. >> >> But, with a new header field it would be possible to use it independently >> in requests and responses, as the header would NOT be copied from the >> request intot the response. >> >> Ie a "proxy" could indicate support of features in SIP requests and/or SIP >> responses, depending on in which direction the support indication applies. >> >> 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 christer.holmberg@ericsson.com Tue Oct 25 12:51:53 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933FE1F0C40 for ; Tue, 25 Oct 2011 12:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.809 X-Spam-Level: X-Spam-Status: No, score=-5.809 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srW4EqgbEzSQ for ; Tue, 25 Oct 2011 12:51:52 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 79EAD1F0C57 for ; Tue, 25 Oct 2011 12:51:52 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-07-4ea713572bda Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 21.3E.20773.75317AE4; Tue, 25 Oct 2011 21:51:51 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 25 Oct 2011 21:51:51 +0200 From: Christer Holmberg To: Paul Kyzivat , Hadriel Kaplan Date: Tue, 25 Oct 2011 21:47:36 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AcyTICyPuowDq3TXQzOivOkZq0gVNAALsWcv Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> In-Reply-To: <4EA6C3DA.6000605@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 19:51:53 -0000 Hi, >In my reply I was assuming that this new header contained no URI - every >field contains one or more feature caps. > >I realize that is inconsistent with what was done in 3841. The history >of 3841 was that Accept-Contact originally allowed an optional URI, >which was matched against candidate contacts. Eventually the draft >evolved to where we abandoned that, but retained the header syntax, but >only in the wildcard form, not with an explicit URI. > >We can argue the pros/cons of following the syntax of Accept-Contact if >you wish. I have no problem using the RFC 3840 syntax. But, as Hadriel indicated in another e-mail, maybe it would be a good idea = to allow an URI, instead of "*", IF there will be a future use-case where o= ne would need to indicate WHICH proxy provides the feature(s). >But using "+" as a separator won't work if we are using the feature tag >notation used in 3840. Some of those tags contain a leading "+" character. Correct. Regards, Christer l On 10/22/11 12:42 AM, Hadriel Kaplan wrote: > > On Oct 20, 2011, at 2:22 PM, Paul Kyzivat wrote: > >>> I would actually suggest that we use the same syntax as we do e.g. for = Accept-Contact, where feature tag >>> values would be separated by ';' instead of '+'. >>> >>> So, we would get something like: Feature-Caps: foo, bar, foo;bar >> >> OK, this was all my misunderstanding. Since the intent is to dynamically= compose them, the rest is syntactic nits. Using ";" would seem to be a pat= h of least resistance. > > I know we're like waaay in the syntactic nits here, but I don't think jus= t a ";" would be right either. It made sense in Accept-Contact because the= base header value is "*" and every feature-tag is a header parameter. Tha= t not only made sense per the rules of header fields and their parameters, = but also made it easier for people who write code that operates on header p= ieces using those conventions easier. (ie, lets you write header.getParam("= foo") without having to also check if it was in the non-param portion) > > Unless you're saying "foo;bar" is not the same as "bar;foo"? > > In other words, instead of this: > Feature-Caps: foo > Feature-Caps: foo;bar > Feature-Caps: bar;foo > > We should probably do this: > Feature-Caps: *;foo > Feature-Caps: *;foo;bar > Feature-Caps: *;bar;foo > > It looks ugly, but it's more logical methinks. > > -hadriel > > From pkyzivat@alum.mit.edu Tue Oct 25 18:16:21 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABF021F8A71 for ; Tue, 25 Oct 2011 18:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ivOxcRi7Xnn for ; Tue, 25 Oct 2011 18:16:20 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 5544D21F8A6C for ; Tue, 25 Oct 2011 18:16:20 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta15.westchester.pa.mail.comcast.net with comcast id pC3F1h00A1swQuc5FDGLYE; Wed, 26 Oct 2011 01:16:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta15.westchester.pa.mail.comcast.net with comcast id pDGL1h0050tdiYw3bDGLx8; Wed, 26 Oct 2011 01:16:20 +0000 Message-ID: <4EA75F61.8090409@alum.mit.edu> Date: Tue, 25 Oct 2011 21:16:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4E8C785D.5080003@alum.mit.edu> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se > In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 01:16:21 -0000 On 10/25/11 3:47 PM, Christer Holmberg wrote: > > Hi, > >> In my reply I was assuming that this new header contained no URI - every >> field contains one or more feature caps. >> >> I realize that is inconsistent with what was done in 3841. The history >> of 3841 was that Accept-Contact originally allowed an optional URI, >> which was matched against candidate contacts. Eventually the draft >> evolved to where we abandoned that, but retained the header syntax, but >> only in the wildcard form, not with an explicit URI. >> >> We can argue the pros/cons of following the syntax of Accept-Contact if >> you wish. > > I have no problem using the RFC 3840 syntax. > > But, as Hadriel indicated in another e-mail, maybe it would be a good idea to allow an URI, instead of "*", IF there will be a future use-case where one would need to indicate WHICH proxy provides the feature(s). I am very reluctant to define this as allowing a URI without also doing the work of defining precisely what the presence of the URI means, how it may be used, etc. I suspect arriving at that definition might be contentious. Thanks, Paul >> But using "+" as a separator won't work if we are using the feature tag >> notation used in 3840. Some of those tags contain a leading "+" character. > > Correct. > > Regards, > > Christer > > > l > > On 10/22/11 12:42 AM, Hadriel Kaplan wrote: >> >> On Oct 20, 2011, at 2:22 PM, Paul Kyzivat wrote: >> >>>> I would actually suggest that we use the same syntax as we do e.g. for Accept-Contact, where feature tag >>>> values would be separated by ';' instead of '+'. >>>> >>>> So, we would get something like: Feature-Caps: foo, bar, foo;bar >>> >>> OK, this was all my misunderstanding. Since the intent is to dynamically compose them, the rest is syntactic nits. Using ";" would seem to be a path of least resistance. >> >> I know we're like waaay in the syntactic nits here, but I don't think just a ";" would be right either. It made sense in Accept-Contact because the base header value is "*" and every feature-tag is a header parameter. That not only made sense per the rules of header fields and their parameters, but also made it easier for people who write code that operates on header pieces using those conventions easier. (ie, lets you write header.getParam("foo") without having to also check if it was in the non-param portion) >> >> Unless you're saying "foo;bar" is not the same as "bar;foo"? >> >> In other words, instead of this: >> Feature-Caps: foo >> Feature-Caps: foo;bar >> Feature-Caps: bar;foo >> >> We should probably do this: >> Feature-Caps: *;foo >> Feature-Caps: *;foo;bar >> Feature-Caps: *;bar;foo >> >> It looks ugly, but it's more logical methinks. >> >> -hadriel >> >> > > From christer.holmberg@ericsson.com Tue Oct 25 23:54:45 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9AB21F85D1 for ; Tue, 25 Oct 2011 23:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.808 X-Spam-Level: X-Spam-Status: No, score=-5.808 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWxXInP1Jo4z for ; Tue, 25 Oct 2011 23:54:45 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BD1E421F85AA for ; Tue, 25 Oct 2011 23:54:41 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-c3-4ea7aeaf376c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 80.B7.20773.FAEA7AE4; Wed, 26 Oct 2011 08:54:40 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 26 Oct 2011 08:54:39 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Wed, 26 Oct 2011 08:54:38 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AcyTfN7UHSx8E06lTxiCSp8KJOsiwgALmLUQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> In-Reply-To: <4EA75F61.8090409@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 06:54:45 -0000 Hi,=20 >>> In my reply I was assuming that this new header contained no URI -=20 >>> every field contains one or more feature caps. >>> >>> I realize that is inconsistent with what was done in 3841. The=20 >>> history of 3841 was that Accept-Contact originally allowed an=20 >>> optional URI, which was matched against candidate contacts.=20 >>> Eventually the draft evolved to where we abandoned that,=20 >>> but retained the header syntax, but only in the wildcard form, not with= =20 >>> an explicit URI. >>> >>> We can argue the pros/cons of following the syntax of=20 >>> Accept-Contact if you wish. >> >> I have no problem using the RFC 3840 syntax. >> >> But, as Hadriel indicated in another e-mail, maybe it would=20 >> be a good idea to allow an URI, instead of "*", IF there will=20 >> be a future use-case where one would need to indicate WHICH=20 >> proxy provides the feature(s). >=20 > I am very reluctant to define this as allowing a URI without=20 > also doing the work of defining precisely what the presence=20 > of the URI means, how it may be used, etc. In most cases I think it would be used simply as some kind of an identifier= , e.g. if there is a need to identity in which domain a feature is provided= , rather than something used for routing.=20 Also, we would need to say that one MUST NOT the URI e.g. to route in-dialo= g requests, or otherwise modify the dialog route set, eventhough the URI va= lue of course may be identical to a URI in a Record-Route. I do agree that we need to do a little more thinking about it, but I don't = think we should exclude the possibility at this point :) Regards, Christer >=20 > I suspect arriving at that definition might be contentious. >=20 > Thanks, > Paul >=20 > >> But using "+" as a separator won't work if we are using=20 > the feature=20 > >> tag notation used in 3840. Some of those tags contain a=20 > leading "+" character. > > > > Correct. > > > > Regards, > > > > Christer > > > > > > l > > > > On 10/22/11 12:42 AM, Hadriel Kaplan wrote: > >> > >> On Oct 20, 2011, at 2:22 PM, Paul Kyzivat wrote: > >> > >>>> I would actually suggest that we use the same syntax as=20 > we do e.g.=20 > >>>> for Accept-Contact, where feature tag values would be=20 > separated by ';' instead of '+'. > >>>> > >>>> So, we would get something like: Feature-Caps: foo, bar, foo;bar > >>> > >>> OK, this was all my misunderstanding. Since the intent is=20 > to dynamically compose them, the rest is syntactic nits.=20 > Using ";" would seem to be a path of least resistance. > >> > >> I know we're like waaay in the syntactic nits here, but I=20 > don't think=20 > >> just a ";" would be right either. It made sense in Accept-Contact=20 > >> because the base header value is "*" and every feature-tag is a=20 > >> header parameter. That not only made sense per the rules=20 > of header=20 > >> fields and their parameters, but also made it easier for=20 > people who=20 > >> write code that operates on header pieces using those conventions=20 > >> easier. (ie, lets you write header.getParam("foo") without=20 > having to=20 > >> also check if it was in the non-param portion) > >> > >> Unless you're saying "foo;bar" is not the same as "bar;foo"? > >> > >> In other words, instead of this: > >> Feature-Caps: foo > >> Feature-Caps: foo;bar > >> Feature-Caps: bar;foo > >> > >> We should probably do this: > >> Feature-Caps: *;foo > >> Feature-Caps: *;foo;bar > >> Feature-Caps: *;bar;foo > >> > >> It looks ugly, but it's more logical methinks. > >> > >> -hadriel > >> > >> > > > > >=20 > = From pkyzivat@alum.mit.edu Wed Oct 26 05:50:50 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E65D21F8AFA for ; Wed, 26 Oct 2011 05:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aG0gW2Xf6nEL for ; Wed, 26 Oct 2011 05:50:49 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1C121F8ADE for ; Wed, 26 Oct 2011 05:50:48 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta13.westchester.pa.mail.comcast.net with comcast id pPrW1h0011ap0As5DQqpbJ; Wed, 26 Oct 2011 12:50:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta22.westchester.pa.mail.comcast.net with comcast id pQqo1h00j0tdiYw3iQqpDE; Wed, 26 Oct 2011 12:50:49 +0000 Message-ID: <4EA80227.1090206@alum.mit.edu> Date: Wed, 26 Oct 2011 08:50:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4E8C785D.5080003@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 12:50:50 -0000 On 10/26/11 2:54 AM, Christer Holmberg wrote: > > Hi, > >>>> In my reply I was assuming that this new header contained no URI - >>>> every field contains one or more feature caps. >>>> >>>> I realize that is inconsistent with what was done in 3841. The >>>> history of 3841 was that Accept-Contact originally allowed an >>>> optional URI, which was matched against candidate contacts. >>>> Eventually the draft evolved to where we abandoned that, >>>> but retained the header syntax, but only in the wildcard form, not with >>>> an explicit URI. >>>> >>>> We can argue the pros/cons of following the syntax of >>>> Accept-Contact if you wish. >>> >>> I have no problem using the RFC 3840 syntax. >>> >>> But, as Hadriel indicated in another e-mail, maybe it would >>> be a good idea to allow an URI, instead of "*", IF there will >>> be a future use-case where one would need to indicate WHICH >>> proxy provides the feature(s). >> >> I am very reluctant to define this as allowing a URI without >> also doing the work of defining precisely what the presence >> of the URI means, how it may be used, etc. > > In most cases I think it would be used simply as some kind of an identifier, e.g. if there is a need to identity in which domain a feature is provided, rather than something used for routing. > > Also, we would need to say that one MUST NOT the URI e.g. to route in-dialog requests, or otherwise modify the dialog route set, eventhough the URI value of course may be identical to a URI in a Record-Route. Yes, that is the issue - what does it mean and how it (may / may not) be used. > I do agree that we need to do a little more thinking about it, but I don't think we should exclude the possibility at this point :) I'm just saying that including it will at least draw out the discussions further. Thanks, Paul > Regards, > > Christer > > > >> >> I suspect arriving at that definition might be contentious. >> >> Thanks, >> Paul >> >>>> But using "+" as a separator won't work if we are using >> the feature >>>> tag notation used in 3840. Some of those tags contain a >> leading "+" character. >>> >>> Correct. >>> >>> Regards, >>> >>> Christer >>> >>> >>> l >>> >>> On 10/22/11 12:42 AM, Hadriel Kaplan wrote: >>>> >>>> On Oct 20, 2011, at 2:22 PM, Paul Kyzivat wrote: >>>> >>>>>> I would actually suggest that we use the same syntax as >> we do e.g. >>>>>> for Accept-Contact, where feature tag values would be >> separated by ';' instead of '+'. >>>>>> >>>>>> So, we would get something like: Feature-Caps: foo, bar, foo;bar >>>>> >>>>> OK, this was all my misunderstanding. Since the intent is >> to dynamically compose them, the rest is syntactic nits. >> Using ";" would seem to be a path of least resistance. >>>> >>>> I know we're like waaay in the syntactic nits here, but I >> don't think >>>> just a ";" would be right either. It made sense in Accept-Contact >>>> because the base header value is "*" and every feature-tag is a >>>> header parameter. That not only made sense per the rules >> of header >>>> fields and their parameters, but also made it easier for >> people who >>>> write code that operates on header pieces using those conventions >>>> easier. (ie, lets you write header.getParam("foo") without >> having to >>>> also check if it was in the non-param portion) >>>> >>>> Unless you're saying "foo;bar" is not the same as "bar;foo"? >>>> >>>> In other words, instead of this: >>>> Feature-Caps: foo >>>> Feature-Caps: foo;bar >>>> Feature-Caps: bar;foo >>>> >>>> We should probably do this: >>>> Feature-Caps: *;foo >>>> Feature-Caps: *;foo;bar >>>> Feature-Caps: *;bar;foo >>>> >>>> It looks ugly, but it's more logical methinks. >>>> >>>> -hadriel >>>> >>>> >>> >>> >> >> From christer.holmberg@ericsson.com Wed Oct 26 10:27:36 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6D521F8AF5 for ; Wed, 26 Oct 2011 10:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.807 X-Spam-Level: X-Spam-Status: No, score=-5.807 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVAxSVI3DX89 for ; Wed, 26 Oct 2011 10:27:35 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 37BDE21F8A58 for ; Wed, 26 Oct 2011 10:27:35 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-7b-4ea8430545cd Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AD.02.13753.50348AE4; Wed, 26 Oct 2011 19:27:34 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 26 Oct 2011 19:27:33 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Wed, 26 Oct 2011 19:27:32 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AcyT3eNYfUWkTQyiTqCvmhBjXDA4GAAJN4/1 Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233C3B820@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se>, <4EA80227.1090206@alum.mit.edu> In-Reply-To: <4EA80227.1090206@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 17:27:36 -0000 Hi, >>>>> In my reply I was assuming that this new header contained no URI - >>>>> every field contains one or more feature caps. >>>>> >>>>> I realize that is inconsistent with what was done in 3841. The >>>>> history of 3841 was that Accept-Contact originally allowed an >>>>> optional URI, which was matched against candidate contacts. >>>>> Eventually the draft evolved to where we abandoned that, >>>>> but retained the header syntax, but only in the wildcard form, not wi= th >>>>> an explicit URI. >>>>> >>>>> We can argue the pros/cons of following the syntax of >>>>> Accept-Contact if you wish. >>>> >>>> I have no problem using the RFC 3840 syntax. >>>> >>>> But, as Hadriel indicated in another e-mail, maybe it would >>>> be a good idea to allow an URI, instead of "*", IF there will >>>> be a future use-case where one would need to indicate WHICH >>>> proxy provides the feature(s). >>> >>> I am very reluctant to define this as allowing a URI without >>> also doing the work of defining precisely what the presence >>> of the URI means, how it may be used, etc. >> >> In most cases I think it would be used simply as some kind of an identif= ier, e.g. if there is a need to identity in which domain a feature is provi= ded, rather than something used for routing. >> >> Also, we would need to say that one MUST NOT the URI e.g. to route in-di= alog requests, or otherwise modify the dialog route set, eventhough the URI= value of course may be identical to a URI in a Record-Route. > > Yes, that is the issue - what does it mean and how it (may / may not) be = used. > >> I do agree that we need to do a little more thinking about it, but I don= 't think we should exclude the possibility at this point :) > > I'm just saying that including it will at least draw out the discussions = further. Yes. However, I did had some discussions about whether "*" is an appropriate val= ue (in the common case where a URI is not needed).=20 AFAIK, for Accept-Contact "*" means "any URI", but I don't think that we ar= e saying that "anyone supports the feature". Instead we are talking more about "no URI", meaning that "someone supports = the feature". So, instead of re-defining the meaning of "*" when used in Fe= ature-Caps, maybe e.g. a "-" value would be more appropriate? Example: Feature-Caps: -;foo;bar On a high level, however, I haven't heard any objections of using a new hea= der field (on the contrary, our discusions seem to more and more point in t= he direction towards a new header field), so my suggestion is that we make = a working assumption of using a new header field.=20 I will then submit a draft accordingly, and we can start sorting out the de= tails and issues (including those we have already been discussing). Regards, Christer =20 > Regards, > > Christer > > > >> >> I suspect arriving at that definition might be contentious. >> >> Thanks, >> Paul >> >>>> But using "+" as a separator won't work if we are using >> the feature >>>> tag notation used in 3840. Some of those tags contain a >> leading "+" character. >>> >>> Correct. >>> >>> Regards, >>> >>> Christer >>> >>> >>> l >>> >>> On 10/22/11 12:42 AM, Hadriel Kaplan wrote: >>>> >>>> On Oct 20, 2011, at 2:22 PM, Paul Kyzivat wrote: >>>> >>>>>> I would actually suggest that we use the same syntax as >> we do e.g. >>>>>> for Accept-Contact, where feature tag values would be >> separated by ';' instead of '+'. >>>>>> >>>>>> So, we would get something like: Feature-Caps: foo, bar, foo;bar >>>>> >>>>> OK, this was all my misunderstanding. Since the intent is >> to dynamically compose them, the rest is syntactic nits. >> Using ";" would seem to be a path of least resistance. >>>> >>>> I know we're like waaay in the syntactic nits here, but I >> don't think >>>> just a ";" would be right either. It made sense in Accept-Contact >>>> because the base header value is "*" and every feature-tag is a >>>> header parameter. That not only made sense per the rules >> of header >>>> fields and their parameters, but also made it easier for >> people who >>>> write code that operates on header pieces using those conventions >>>> easier. (ie, lets you write header.getParam("foo") without >> having to >>>> also check if it was in the non-param portion) >>>> >>>> Unless you're saying "foo;bar" is not the same as "bar;foo"? >>>> >>>> In other words, instead of this: >>>> Feature-Caps: foo >>>> Feature-Caps: foo;bar >>>> Feature-Caps: bar;foo >>>> >>>> We should probably do this: >>>> Feature-Caps: *;foo >>>> Feature-Caps: *;foo;bar >>>> Feature-Caps: *;bar;foo >>>> >>>> It looks ugly, but it's more logical methinks. >>>> >>>> -hadriel >>>> >>>> >>> >>> >> >> From pkyzivat@alum.mit.edu Wed Oct 26 11:50:56 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB70F1F0C3C for ; Wed, 26 Oct 2011 11:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.329 X-Spam-Level: X-Spam-Status: No, score=-0.329 tagged_above=-999 required=5 tests=[AWL=-1.815, BAYES_00=-2.599, FRT_PROFIT1=3.858, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4b6eXKtQXVG for ; Wed, 26 Oct 2011 11:50:56 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3C11F0C57 for ; Wed, 26 Oct 2011 11:50:55 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta13.westchester.pa.mail.comcast.net with comcast id pWeU1h0051c6gX85DWqtz9; Wed, 26 Oct 2011 18:50:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta23.westchester.pa.mail.comcast.net with comcast id pWqs1h0270tdiYw3jWqtZT; Wed, 26 Oct 2011 18:50:53 +0000 Message-ID: <4EA8568B.3040701@alum.mit.edu> Date: Wed, 26 Oct 2011 14:50:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4E8C785D.5080003@alum.mit.edu> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se>, <4EA80227.1090206@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B820@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233C3B820@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 18:50:57 -0000 On 10/26/11 1:27 PM, Christer Holmberg wrote: > > Hi, > >>>>>> In my reply I was assuming that this new header contained no URI - >>>>>> every field contains one or more feature caps. >>>>>> >>>>>> I realize that is inconsistent with what was done in 3841. The >>>>>> history of 3841 was that Accept-Contact originally allowed an >>>>>> optional URI, which was matched against candidate contacts. >>>>>> Eventually the draft evolved to where we abandoned that, >>>>>> but retained the header syntax, but only in the wildcard form, not with >>>>>> an explicit URI. >>>>>> >>>>>> We can argue the pros/cons of following the syntax of >>>>>> Accept-Contact if you wish. >>>>> >>>>> I have no problem using the RFC 3840 syntax. >>>>> >>>>> But, as Hadriel indicated in another e-mail, maybe it would >>>>> be a good idea to allow an URI, instead of "*", IF there will >>>>> be a future use-case where one would need to indicate WHICH >>>>> proxy provides the feature(s). >>>> >>>> I am very reluctant to define this as allowing a URI without >>>> also doing the work of defining precisely what the presence >>>> of the URI means, how it may be used, etc. >>> >>> In most cases I think it would be used simply as some kind of an identifier, e.g. if there is a need to identity in which domain a feature is provided, rather than something used for routing. >>> >>> Also, we would need to say that one MUST NOT the URI e.g. to route in-dialog requests, or otherwise modify the dialog route set, eventhough the URI value of course may be identical to a URI in a Record-Route. >> >> Yes, that is the issue - what does it mean and how it (may / may not) be used. >> >>> I do agree that we need to do a little more thinking about it, but I don't think we should exclude the possibility at this point :) >> >> I'm just saying that including it will at least draw out the discussions further. > > Yes. > > However, I did had some discussions about whether "*" is an appropriate value (in the common case where a URI is not needed). > > AFAIK, for Accept-Contact "*" means "any URI", but I don't think that we are saying that "anyone supports the feature". At one time "*" meant "any URI". But it was changed so that "*" is the only value you can use there - there is no URI matching based on that value - so it doesn't really mean anything in that context. There is precedent for the "*" meaning "any URI" from the Contact in REGISTER. So it plausible to assume it should mean the same in other similar usages. > Instead we are talking more about "no URI", meaning that "someone supports the feature". So, instead of re-defining the meaning of "*" when used in Feature-Caps, maybe e.g. a "-" value would be more appropriate? > > Example: > > Feature-Caps: -;foo;bar If you are simply looking for a syntactic mechanism, I would suggest simply leaving the field empty, as in Feature-Caps: ;foo;bar But that doesn't address what it means if there *is* a URI. Either the intent is to assign a real meaning now, or to future-proof the syntax against a future extension that defines it. There is some work to do even if the goal is only to future-proof it. Syntactically it will need to allow a optional URI, which is easy to define. Semantically it will need to specify that nothing conforming to "this" spec may put a value there, and that anything interpreting such a header that *does* have a value will ignore the URI. Then a future extension would be free to define both the conditions for including the URI, and the appropriate interpretation of it, but would have to account for those following the older spec that would ignore it. > On a high level, however, I haven't heard any objections of using a new header field (on the contrary, our discusions seem to more and more point in the direction towards a new header field), so my suggestion is that we make a working assumption of using a new header field. I have no objection to that change. It avoids the complexities that come with overloading Record-Route/Route/etc. > I will then submit a draft accordingly, and we can start sorting out the details and issues (including those we have already been discussing). ok. Thanks, Paul From christer.holmberg@ericsson.com Wed Oct 26 12:59:01 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2ADC21F84E1 for ; Wed, 26 Oct 2011 12:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.183 X-Spam-Level: X-Spam-Status: No, score=-4.183 tagged_above=-999 required=5 tests=[AWL=-1.669, BAYES_00=-2.599, FRT_PROFIT1=3.858, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaaumJAMx9Ca for ; Wed, 26 Oct 2011 12:59:01 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id CA53021F84D8 for ; Wed, 26 Oct 2011 12:59:00 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-b1-4ea86683199c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F8.3C.13753.38668AE4; Wed, 26 Oct 2011 21:58:59 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 26 Oct 2011 21:58:59 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Wed, 26 Oct 2011 21:58:58 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AcyUEDBYr8XrSJ5pQieVC7WU0MfOiQABi0Kb Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233C3B825@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se>, <4EA80227.1090206@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B820@ESESSCMS0356.eemea.ericsson.se>, <4EA8568B.3040701@alum.mit.edu> In-Reply-To: <4EA8568B.3040701@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 19:59:02 -0000 Hi, >>>>>>> In my reply I was assuming that this new header contained no URI - >>>>>>> every field contains one or more feature caps. >>>>>>> >>>>>>> I realize that is inconsistent with what was done in 3841. The >>>>>>> history of 3841 was that Accept-Contact originally allowed an >>>>>>> optional URI, which was matched against candidate contacts. >>>>>>> Eventually the draft evolved to where we abandoned that, >>>>>>> but retained the header syntax, but only in the wildcard form, not = with >>>>>>> an explicit URI. >>>>>>> >>>>>>> We can argue the pros/cons of following the syntax of >>>>>>> Accept-Contact if you wish. >>>>>> >>>>>> I have no problem using the RFC 3840 syntax. >>>>>> >>>>>> But, as Hadriel indicated in another e-mail, maybe it would >>>>>> be a good idea to allow an URI, instead of "*", IF there will >>>>>> be a future use-case where one would need to indicate WHICH >>>>>> proxy provides the feature(s). >>>>> >>>>> I am very reluctant to define this as allowing a URI without >>>>> also doing the work of defining precisely what the presence >>>>> of the URI means, how it may be used, etc. >>>> >>>> In most cases I think it would be used simply as some kind of an ident= ifier, e.g. if there is a need to identity in which domain a feature is pro= vided, rather than something used for routing. >>>> >>>> Also, we would need to say that one MUST NOT the URI e.g. to route in-= dialog requests, or otherwise modify the dialog route set, eventhough the U= RI value of course may be identical to a URI in a Record-Route. >>> >>> Yes, that is the issue - what does it mean and how it (may / may not) b= e used. >>> >>>> I do agree that we need to do a little more thinking about it, but I d= on't think we should exclude the possibility at this point :) >>>> >>> I'm just saying that including it will at least draw out the discussion= s further. >> >> Yes. >> >> However, I did had some discussions about whether "*" is an appropriate = value (in the common case where a URI is not needed). >> >> AFAIK, for Accept-Contact "*" means "any URI", but I don't think that we= are saying that "anyone supports the feature". > > At one time "*" meant "any URI". But it was changed so that "*" is the > only value you can use there - there is no URI matching based on that > value - so it doesn't really mean anything in that context. > >There is precedent for the "*" meaning "any URI" from the Contact in >REGISTER. So it plausible to assume it should mean the same in other >similar usages. I was going to mention the Contact usage also, but it seems like I forgot. >> Instead we are talking more about "no URI", meaning that "someone suppor= ts the feature". So, instead of re-defining the meaning of "*" when used in= Feature-Caps, maybe e.g. a "-" value would be more appropriate? >> >> Example: >> >> Feature-Caps: -;foo;bar > > If you are simply looking for a syntactic mechanism, I would suggest > simply leaving the field empty, as in > > Feature-Caps: ;foo;bar Ok. I don't have any strong opinion, as long as there is no confusion of th= e meaning. > But that doesn't address what it means if there *is* a URI. > Either the intent is to assign a real meaning now, or to future-proof > the syntax against a future extension that defines it. > > There is some work to do even if the goal is only to future-proof it. > Syntactically it will need to allow a optional URI, which is easy to > define. Semantically it will need to specify that nothing conforming to > "this" spec may put a value there, and that anything interpreting such a > header that *does* have a value will ignore the URI. Then a future > extension would be free to define both the conditions for including the > URI, and the appropriate interpretation of it, but would have to account > for those following the older spec that would ignore it. An easy approach could be the following: We specify that a URI is informative, and *ONLY* indicates the entity, or t= he domain, that supports the feature(s). Nothing more, nothing less :) (I believe there could e.g. be roaming/interconnect/transit scenarios where= it would be useful to know in which domain a feature is supported.) But, any additional information, which only applies to a specific feature t= ag(s), would have to be defined and provided as a feature tag parameter. Regards, Christer= From pkyzivat@alum.mit.edu Wed Oct 26 13:27:18 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164F221F8B53 for ; Wed, 26 Oct 2011 13:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[AWL=-1.786, BAYES_00=-2.599, FRT_PROFIT1=3.858, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvmmRntXZJPN for ; Wed, 26 Oct 2011 13:27:17 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 563F021F8B52 for ; Wed, 26 Oct 2011 13:27:17 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta06.westchester.pa.mail.comcast.net with comcast id pV1j1h0091vXlb856YTAor; Wed, 26 Oct 2011 20:27:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta17.westchester.pa.mail.comcast.net with comcast id pYT91h02g0tdiYw3dYTA2s; Wed, 26 Oct 2011 20:27:10 +0000 Message-ID: <4EA86D1B.80600@alum.mit.edu> Date: Wed, 26 Oct 2011 16:27:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4E8C785D.5080003@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se>, <4EA80227.1090206@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B820@ESESSCMS0356.eemea.ericsson.se>, <4EA8568B.3040701@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B825@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233C3B825@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 20:27:18 -0000 On 10/26/11 3:58 PM, Christer Holmberg wrote: >>> However, I did had some discussions about whether "*" is an appropriate value (in the common case where a URI is not needed). >>> >>> AFAIK, for Accept-Contact "*" means "any URI", but I don't think that we are saying that "anyone supports the feature". >> >> At one time "*" meant "any URI". But it was changed so that "*" is the >> only value you can use there - there is no URI matching based on that >> value - so it doesn't really mean anything in that context. >> >> There is precedent for the "*" meaning "any URI" from the Contact in >> REGISTER. So it plausible to assume it should mean the same in other >> similar usages. > > I was going to mention the Contact usage also, but it seems like I forgot. > >>> Instead we are talking more about "no URI", meaning that "someone supports the feature". So, instead of re-defining the meaning of "*" when used in Feature-Caps, maybe e.g. a "-" value would be more appropriate? >>> >>> Example: >>> >>> Feature-Caps: -;foo;bar >> >> If you are simply looking for a syntactic mechanism, I would suggest >> simply leaving the field empty, as in >> >> Feature-Caps: ;foo;bar > > Ok. I don't have any strong opinion, as long as there is no confusion of the meaning. > >> But that doesn't address what it means if there *is* a URI. >> Either the intent is to assign a real meaning now, or to future-proof >> the syntax against a future extension that defines it. >> >> There is some work to do even if the goal is only to future-proof it. >> Syntactically it will need to allow a optional URI, which is easy to >> define. Semantically it will need to specify that nothing conforming to >> "this" spec may put a value there, and that anything interpreting such a >> header that *does* have a value will ignore the URI. Then a future >> extension would be free to define both the conditions for including the >> URI, and the appropriate interpretation of it, but would have to account >> for those following the older spec that would ignore it. > > An easy approach could be the following: > > We specify that a URI is informative, and *ONLY* indicates the entity, or the domain, that supports the feature(s). Nothing more, nothing less :) > > (I believe there could e.g. be roaming/interconnect/transit scenarios where it would be useful to know in which domain a feature is supported.) > > But, any additional information, which only applies to a specific feature tag(s), would have to be defined and provided as a feature tag parameter. I find the above a bad idea. First, there is a question of whether this is an arbitrary URI, or always a sip URI. For an arbitrary URI it is very obscure. For now I'll assume its only a sip/sips URI. Its very weird to say "here is a sip URI, but its only significance is in the domain. It strongly encourages people to do more with it. And defining its significance on a per-feature-tag basis creates a heap of confusion. (For feature foo you can get info by subscribing to an event package, for feature bar you can send data to it with MESSAGE, for feature baz you can meaningfully send an INVITE.) And its more confusing when you associate multiple features with the same URI. If you want to parameterize features, then I think you are better off to do so by defining the values they can take on. Thanks, Paul From pkyzivat@alum.mit.edu Wed Oct 26 13:44:57 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52EBF21F8B80 for ; Wed, 26 Oct 2011 13:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7LhMHfpgqLn for ; Wed, 26 Oct 2011 13:44:56 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 69A0521F8B81 for ; Wed, 26 Oct 2011 13:44:56 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta06.westchester.pa.mail.comcast.net with comcast id pY2j1h00H0mv7h056Ykwzj; Wed, 26 Oct 2011 20:44:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta11.westchester.pa.mail.comcast.net with comcast id pYkv1h00L0tdiYw3XYkwLz; Wed, 26 Oct 2011 20:44:56 +0000 Message-ID: <4EA87146.1010909@alum.mit.edu> Date: Wed, 26 Oct 2011 16:44:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4E8C785D.5080003@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <105D3FF9-483F-431D-B080-8399DB324682@acmepacket.com> <4EA0B7B5.4060304@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852234235BA5@ESESSCMS0356.eemea.ericsson.se>, <4EA17EE7.4020809@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B809@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233C3B809@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 20:44:57 -0000 On 10/22/11 11:50 AM, Christer Holmberg wrote: > > Hi, > >>>>>> And for Hadriel: in your experience dealing with SBC >>>>>> customers, would that convey too much topology info, that you >>>>>> might be asked to suppress? >>>>> >>>>> I don't think so. It doesn't tell you who the nodes are, >>>>> how many there are, nor where they're at; and from a policy >>>>> perspective it's easy to add/remove for both blacklist and >>>>> whitelist policy models. >>>> >>>> It does put a lower bound on the number of proxies are on the path. >>>> If that was an unusually large number it might communicate something. >>>> But in practice maybe it won't be a large number even if >>>> there are a lot of proxies. >>>> >>>> Its also possible that the *pattern" of entries would >>>> communicate something about the topology of the deployment - >>>> perhaps indicate the specific equipment being used with some >>>> high probability. >>>> >>>> I personally don't care. ISTM that topology hiding is >>>> carrying paranoia to extremes. But obviously some do care. >>>> >>>>> It's similar to the Supported header. But the difficulty >>>>> with the Supported header for all B2BUAs, which we should >>>>> probably discuss out for this Feature-Caps header, is that >>>>> B2BUAs can't just blindly pass/copy Supported option-tags >>>>> through because they wouldn't know if the extension indicated >>>>> by some random new option-tag would actually work "through" them. >>>> >>>> And the same sorts of difficulties may apply. >>> >>> An SBC can do whatever - and nothing we do can prevent that. >>> >>> However, my take of this discussion is that a new header would have a bigger chance of "surviving" than e.g. Record-Route, so can I start updating the draft-holmberg draft based on such assumption? >> >>> I think we have a pretty good idea on what we want to do, and I think the requirements are in pretty good shape, so I don't it would bring much value in spending much more time on those. >> >> You were going to provide a use case for your requirement to detect when >> two features are supported by the same server. I still find that mystifying. > > See the new version (-03) of the draft. > >> I also think we still should discuss what namespace these "features" >> come from. You had originally proposed that these be feature tags as >> defined in 3840, but with a twist that the meaning of features be >> different for proxies than for UAs. I guess the reason for proposing >> feature tags was that the mechanism for them already exists, and a >> certain similarity of attaching them to a URI. > > The feature tag concept is not defined in RFC 3840. RFC 3840 defines a SIP specific feature tag syntax, and how SIP UAs use feature tags to indicate capabilities. Yes, 3840 borrowed the underlying feature tag mechanism and registry. (IMO it was a poor fit, but its too late to argue over it.) For practical purposes the registry of sip features is distinct. (They all start with "sip." except for some grandfathered ones.) And as you say, the syntax for representing them is modified. All of this was built around the need to provide a way of "matching" preferences against capabilities. > The new mechanism would define how SIP "proxies" use feature tag to indicate capabilties. AFAIK you have no intent to extend 3841 to do matching on proxy-features. (Or do you?) If not, there is no need for a representation that supports the matching mechanics of 3841. (Which is already far too arcane.) > But, I agree that the semantics may vary depending on whether a UA or a "proxy" inserts the feature tag, and the feature tag specification would have to handle that. If we use the existing feature tag registry for this new use, either the namespace will need to be changed (e.g. use something other than "sip." as a prefix), or else feature tag specifications that follow 3840 will only apply to UAs, and those that follow this new draft will only apply to proxies, or will contain separate sub-specifications for UA and proxy behavior. So in reality there will be different namespaces for UAs and proxies. And in practice there will probably be distinct names as well. So the only advantage of using the feature tag type and registry is to avoid defining a new registry. >> That was already a bit of a stretch because the semantics were a bit >> different. With the new mechanism being defined its a bit more of a >> stretch. Also, the syntax of values for feature tags is coupled to the >> callerpref matching algorithm. I have heard no suggestion of a matching >> algorithm for proxy features. (Though your concern for detecting the >> shared appearance of multiple features might imply one.) > > I am not sure I understand how the syntax is coupled to the callerpref maching mechanism. See above. The syntax of values is defined so that it can be mapped onto feature tag predicates, so that those can be used to define matching in 3841. Thanks, Paul > And, even if it is, I see no reason why we can't use the same syntax for proxies - even if we would not use them for matching. > > >>> So, I'd like to see some discussion of the namespace and value space for proxy features. > > I personally see no reason why feature tags wouldn't work, and why we would need to define a new way of indicating feature support. > > >>> I also know that people will start to implement at least some of the 3GPP use-cases, so also from that perspective I think we >>> need to show the path we're taking (eventhough nobody of course can expect all the details to be settled from day one). >> >> People can start trial implementations whenever they want. Whether they >> are close to a final implementation won't be known until the end. > > SDOs, currently mainly 3GPP, are also defining features using the mechanism. > > Anyway, my point is that I personally think we are at a stage where we can start work on the protocol mechanism. Of course there will be lots of details that we have to sort out along the road, but that is part of our normal work in IETF :) > > > Regards, > > Christer > > > From christer.holmberg@ericsson.com Wed Oct 26 13:49:15 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B0F1F0C3E for ; Wed, 26 Oct 2011 13:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.156 X-Spam-Level: X-Spam-Status: No, score=-4.156 tagged_above=-999 required=5 tests=[AWL=-1.642, BAYES_00=-2.599, FRT_PROFIT1=3.858, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFMDnYN0VzbV for ; Wed, 26 Oct 2011 13:49:14 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEED1F0C3D for ; Wed, 26 Oct 2011 13:49:14 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-9d-4ea872490d0d Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C1.9F.20773.94278AE4; Wed, 26 Oct 2011 22:49:13 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 26 Oct 2011 22:49:12 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Wed, 26 Oct 2011 22:49:12 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature Thread-Index: AcyUHaO4PM4aSs0gQPKVSOeYL9Nn9wAAS+aa Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233C3B82C@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se>, <4EA80227.1090206@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B820@ESESSCMS0356.eemea.ericsson.se>, <4EA8568B.3040701@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B825@ESESSCMS0356.eemea.ericsson.se>, <4EA86D1B.80600@alum.mit.edu> In-Reply-To: <4EA86D1B.80600@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 20:49:15 -0000 Hi, >>> But that doesn't address what it means if there *is* a URI. >>> Either the intent is to assign a real meaning now, or to future-proof >>> the syntax against a future extension that defines it. >>> >>> There is some work to do even if the goal is only to future-proof it. >>> Syntactically it will need to allow a optional URI, which is easy to >>> define. Semantically it will need to specify that nothing conforming to >>> "this" spec may put a value there, and that anything interpreting such = a >>> header that *does* have a value will ignore the URI. Then a future >>> extension would be free to define both the conditions for including the >>> URI, and the appropriate interpretation of it, but would have to accoun= t >>> for those following the older spec that would ignore it. >> >> An easy approach could be the following: >> >> We specify that a URI is informative, and *ONLY* indicates the entity, o= r the domain, that supports the feature(s). Nothing more, nothing less :) >> >> (I believe there could e.g. be roaming/interconnect/transit scenarios wh= ere it would be useful to know in which domain a feature is supported.) >> >> But, any additional information, which only applies to a specific featur= e tag(s), would have to be defined and provided as a feature tag parameter. > > I find the above a bad idea. > > First, there is a question of whether this is an arbitrary URI, or > always a sip URI. For an arbitrary URI it is very obscure. For now I'll > assume its only a sip/sips URI. > > Its very weird to say "here is a sip URI, but its only significance is > in the domain. It strongly encourages people to do more with it. I didn't mean that it's only significant within the domain. I meant that th= e URI informs which domain supports the features. > And defining its significance on a per-feature-tag basis creates a heap o= f confusion. > > (For feature foo you can get info by subscribing to an event package, for= feature bar you can send data to it with MESSAGE, for > feature baz you can meaningfully send an INVITE.) And its more confusing = when you associate multiple features with the same URI. I agree.=20 I was more thinking about whether operator policies etc could be based on i= n which domain features are supported, but that feature tag specifications = MUST NOT define any additional feature tag specific meaning (e.g. whether i= t can be used for sending a MESSAGE requests). As you also suggest below, s= uch information would have to be provided using feature tag parameters. > If you want to parameterize features, then I think you are better off to = do so by defining the values they can take on. I totally agree. The URI would only provide general information about the e= ntity/domain that indicated support of the features, but it would not provi= de any additional feature specific information. Regards, Christer From christer.holmberg@ericsson.com Wed Oct 26 14:04:21 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F10111E808A for ; Wed, 26 Oct 2011 14:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.05 X-Spam-Level: X-Spam-Status: No, score=-6.05 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qXiEkygjixC for ; Wed, 26 Oct 2011 14:04:15 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C61C111E80B7 for ; Wed, 26 Oct 2011 14:04:14 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-64-4ea875cd1d4d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D3.50.13753.DC578AE4; Wed, 26 Oct 2011 23:04:13 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 26 Oct 2011 23:04:13 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Wed, 26 Oct 2011 23:04:12 +0200 Thread-Topic: Feature-Caps: feature tag syntax [was: draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature] Thread-Index: AQHMlCLQASUlQk5+3kaSK9jxfb6r7A== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852233C3B82D@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: [sipcore] Feature-Caps: feature tag syntax [was: draft-ietf-sipcore-proxy-feature-reqs-01 - A proxy vs WHICH proxy provides the feature] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 21:04:21 -0000 Hi, >>> I also think we still should discuss what namespace these "features" >>> come from. You had originally proposed that these be feature tags as >>> defined in 3840, but with a twist that the meaning of features be >>> different for proxies than for UAs. I guess the reason for proposing >>> feature tags was that the mechanism for them already exists, and a >>> certain similarity of attaching them to a URI. >> >> The feature tag concept is not defined in RFC 3840. RFC 3840 defines a S= IP specific feature tag syntax, and how SIP UAs use feature tags to indicat= e capabilities. > > Yes, 3840 borrowed the underlying feature tag mechanism and registry. > (IMO it was a poor fit, but its too late to argue over it.) > For practical purposes the registry of sip features is distinct. (They > all start with "sip." except for some grandfathered ones.) > And as you say, the syntax for representing them is modified. > > All of this was built around the need to provide a way of "matching" > preferences against capabilities. > >> The new mechanism would define how SIP "proxies" use feature tag to indi= cate capabilties. > > AFAIK you have no intent to extend 3841 to do matching on > proxy-features. (Or do you?) > > If not, there is no need for a representation that supports the matching > mechanics of 3841. (Which is already far too arcane.) The intention is not to extend 3841. I think the current draft says that, but if it doesn't I will add text to c= larify it. >> But, I agree that the semantics may vary depending on whether a UA or a = "proxy" inserts the feature tag, and the=20 >> feature tag specification would have to handle that. > > If we use the existing feature tag registry for this new use, either the > namespace will need to be changed (e.g. use something other than "sip." > as a prefix), or else feature tag specifications that follow 3840 will > only apply to UAs, and those that follow this new draft will only apply > to proxies, or will contain separate sub-specifications for UA and proxy > behavior. So in reality there will be different namespaces for UAs and > proxies. And in practice there will probably be distinct names as well. > > So the only advantage of using the feature tag type and registry is to > avoid defining a new registry. > >>> That was already a bit of a stretch because the semantics were a bit >>> different. With the new mechanism being defined its a bit more of a >>> stretch. Also, the syntax of values for feature tags is coupled to the >>> callerpref matching algorithm. I have heard no suggestion of a matching >>> algorithm for proxy features. (Though your concern for detecting the >>> shared appearance of multiple features might imply one.) >> >> I am not sure I understand how the syntax is coupled to the callerpref m= aching mechanism. > > See above. The syntax of values is defined so that it can be mapped onto > feature tag predicates, so that those can be used to define matching in > 3841. That may be true, but I don't see a reason why we should invent something n= ew just because of that. I don't think it would be "overkill" to use the ex= isting syntax, even if we won't use it for matching. The syntax has a very = good tree structure, which I think is very clear and useful. Also, if I define a feature that can be supported both by a UA and a "proxy= ", I think it's good if I can use the same feature tag syntax and value - E= VEN if I may have to register them in separate registries. Then, whether we'll need "*" or not I guess depends on the outcome of the o= ther discussion, but that is more related to the header field syntax rather= than the feature tag syntax. Regards, Christer From christer.holmberg@ericsson.com Fri Oct 28 03:09:54 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B6B21F891D for ; Fri, 28 Oct 2011 03:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPrCiDmhyHb0 for ; Fri, 28 Oct 2011 03:09:54 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B2F5B21F84C1 for ; Fri, 28 Oct 2011 03:09:53 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-0f-4eaa7f70a185 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5B.24.13753.07F7AAE4; Fri, 28 Oct 2011 12:09:52 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 28 Oct 2011 12:09:37 +0200 From: Christer Holmberg To: "" , Paul Kyzivat Date: Fri, 28 Oct 2011 12:09:35 +0200 Thread-Topic: Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) Thread-Index: AcyTfN7UHSx8E06lTxiCSp8KJOsiwgALmLUQAGtZLlA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522342DDA7E@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 10:09:54 -0000 =20 Hi, I've submitted a new version (-03) of draft-holmberg-sipcore-proxy-feature,= which suggests a solution based on the proxy feature requirements. The MAJOR CHANGE, based on the list discussions, is that the mechanism now = uses a new header field, Feature-Caps, rather than existing header fields (= Record-Route, Path etc). I did not include the "SIP-URI alternative" at this point. We will also have to think about the "proxy" terminology, as it has been in= dicated that entities using the mechanism might not be pure proxies. But, I= don't think that should prevent us from moving forward the the mechanism a= s such. Thanks to everyone who has provided feedback and input! Regards, Christer From ibc@aliax.net Fri Oct 28 05:29:44 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA5321F8548 for ; Fri, 28 Oct 2011 05:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQ2qE-g1k7k4 for ; Fri, 28 Oct 2011 05:29:43 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 89AA821F84CF for ; Fri, 28 Oct 2011 05:29:43 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3951501vcb.31 for ; Fri, 28 Oct 2011 05:29:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.210.137 with SMTP id gk9mr413752vcb.131.1319804982425; Fri, 28 Oct 2011 05:29:42 -0700 (PDT) Received: by 10.220.159.134 with HTTP; Fri, 28 Oct 2011 05:29:42 -0700 (PDT) Date: Fri, 28 Oct 2011 14:29:42 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 12:29:44 -0000 Hi all, A draft describing a mechanism for usage of WebSocket protocol as a new transport between SIP entities was submitted to rtcweb WG on 13 Sep 2011. However the discussions on that list seemed to conclude that the draft was interesting but outside the scope of rtcweb. Since the draft describes a new transport for SIP it makes more sense to propose it in SIPCORE WG. Therefore we ask the SIPCORE WG to discuss whether the proposed draft could fit well in this WG. There are some aspects of the draft that will be addressed in a new revision (as mandating Outbound support given the nature of the WebSocket protocol). The first revision of the draft can be found at: http://datatracker.ietf.org/doc/draft-ibc-rtcweb-sip-websocket/ --------------------------------Abstract =C2=A0 This document specifies a WebSocket subprotocol for a new transport in SIP (Session Initiation Protocol). =C2=A0The WebSocket protocol enables two-way realtime communication between clients (typically web-based applications) and servers. =C2=A0The main goal of this specification is to integrate the SIP protocol within web applications.------------------------------ This new SIP transport could fit well within a RTCweb architecture (since RTCweb does not mandate the in-the-wire protocol nor the format of the messages exchanged between RTCweb clients and servers). This is just an use case, a future revision of the draft could incorporate more use cases. A presentation of the proposed specification (including a video with running code) can be found at: http://sip-on-the-web.aliax.net/ -------------------------------Introduction =C2=A0 The aim of this presentation is to show the SIP protocol working within a web browser and interoperating with any SIP network. =C2=A0 After some slides describing the used technology there is a signaling flowchart and a video showing a real implementation.------------------------------- Please let us know whether this draft would fit well in SIPCORE or may be we would do better by proposing it in DISPATCH. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Oct 28 05:42:43 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8792121F8B8B for ; Fri, 28 Oct 2011 05:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzgn6H2nFO66 for ; Fri, 28 Oct 2011 05:42:42 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6C021F8B7F for ; Fri, 28 Oct 2011 05:42:42 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3964966vcb.31 for ; Fri, 28 Oct 2011 05:42:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.107.81 with SMTP id a17mr407548vcp.96.1319805760590; Fri, 28 Oct 2011 05:42:40 -0700 (PDT) Received: by 10.220.159.134 with HTTP; Fri, 28 Oct 2011 05:42:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Oct 2011 14:42:40 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 12:42:43 -0000 Hi, let me resend the the mail since I had a problem with my text editor: A draft describing a mechanism for usage of WebSocket protocol as a new transport between SIP entities was submitted to rtcweb WG on 13 Sep 2011. However the discussions on that list seemed to conclude that the draft was interesting but outside the scope of rtcweb. Since the draft describes a new transport for SIP it makes more sense to propose it in SIPCORE WG. Therefore we ask the SIPCORE WG to discuss whether the proposed draft could fit well in this WG. There are some aspects of the draft that will be addressed in a new revision (as mandating Outbound support given the nature of the WebSocket protocol). The first revision of the draft can be found at: http://datatracker.ietf.org/doc/draft-ibc-rtcweb-sip-websocket/ -------------------------------- Abstract =C2=A0This document specifies a WebSocket subprotocol for a new transport in SIP (Session Initiation Protocol). =C2=A0The WebSocket protocol enable= s two-way realtime communication between clients (typically web-based applications) and servers. =C2=A0The main goal of this specification is t= o integrate the SIP protocol within web applications. ------------------------------ This new SIP transport could fit well within a RTCweb architecture (since RTCweb does not mandate the in-the-wire protocol nor the format of the messages exchanged between RTCweb clients and servers). This is just a use case, a future revision of the draft could incorporate more use cases. A presentation of the proposed specification (including a video with running code) can be found at: http://sip-on-the-web.aliax.net/ ------------------------------- Introduction The aim of this presentation is to show the SIP protocol working within a web browser and interoperating with any SIP network. =C2=A0After some slides describing the used technology there is a signaling flowchart and a video showing a real implementation. ------------------------------- Please let us know whether this draft would fit well in SIPCORE or may be we would do better by proposing it in DISPATCH. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Fri Oct 28 07:59:12 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC3C21F8B5A for ; Fri, 28 Oct 2011 07:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONk17wHuLvwK for ; Fri, 28 Oct 2011 07:59:12 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 10A0A21F8B59 for ; Fri, 28 Oct 2011 07:59:11 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 28 Oct 2011 10:59:10 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 28 Oct 2011 10:59:10 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [sipcore] Proposal for a new SIP transport (WebSocket) Thread-Index: AQHMlYIl+AMOu5OhnEeTTGJOe+Fhiw== Date: Fri, 28 Oct 2011 14:59:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 14:59:12 -0000 I think this is a really good idea and provides benefits even for SIP clien= ts which are not Javascript-based or in the browser - i.e., it's a useful t= ransport even for native SIP client applications.=20 Is there time in the SIPCORE WG meeting slot in Taipei to have this draft p= resented? Also, I think SIPCORE is the right WG. -hadriel I think SIPCORE is the right place for this. On Oct 28, 2011, at 8:42 AM, I=F1aki Baz Castillo wrote: > Hi, let me resend the the mail since I had a problem with my text editor: >=20 >=20 >=20 >=20 > A draft describing a mechanism for usage of WebSocket protocol as a > new transport between SIP entities was submitted to rtcweb WG on 13 > Sep 2011. However the discussions on that list seemed to conclude that > the draft was interesting but outside the scope of rtcweb. Since the > draft describes a new transport for SIP it makes more sense to propose > it in SIPCORE WG. Therefore we ask the SIPCORE WG to discuss whether > the proposed draft could fit well in this WG. >=20 > There are some aspects of the draft that will be addressed in a new > revision (as mandating Outbound support given the nature of the > WebSocket protocol). The first revision of the draft can be found at: >=20 > http://datatracker.ietf.org/doc/draft-ibc-rtcweb-sip-websocket/ >=20 > -------------------------------- > Abstract >=20 > This document specifies a WebSocket subprotocol for a new transport > in SIP (Session Initiation Protocol). The WebSocket protocol enables > two-way realtime communication between clients (typically web-based > applications) and servers. The main goal of this specification is to > integrate the SIP protocol within web > applications. > ------------------------------ >=20 >=20 > This new SIP transport could fit well within a RTCweb architecture > (since RTCweb does not mandate the in-the-wire protocol nor the format > of the messages exchanged between RTCweb clients and servers). This is > just a use case, a future revision of the draft could incorporate more > use cases. >=20 >=20 > A presentation of the proposed specification (including a video with > running code) can be found at: >=20 > http://sip-on-the-web.aliax.net/ >=20 > ------------------------------- > Introduction >=20 > The aim of this presentation is to show the SIP protocol working > within a web browser and interoperating with any SIP network. >=20 > After some slides describing the used technology there is a > signaling flowchart and a video showing a real implementation. > ------------------------------- >=20 >=20 > Please let us know whether this draft would fit well in SIPCORE or may > be we would do better by proposing it in DISPATCH. >=20 > Thanks a lot. >=20 >=20 > --=20 > I=F1aki Baz Castillo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From ibc@aliax.net Fri Oct 28 08:12:04 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F5421F8B3E for ; Fri, 28 Oct 2011 08:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7nDK-sUqt43B for ; Fri, 28 Oct 2011 08:12:04 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2414A21F8B1B for ; Fri, 28 Oct 2011 08:12:04 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4139086vcb.31 for ; Fri, 28 Oct 2011 08:12:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.210.137 with SMTP id gk9mr494320vcb.131.1319814721143; Fri, 28 Oct 2011 08:12:01 -0700 (PDT) Received: by 10.220.159.134 with HTTP; Fri, 28 Oct 2011 08:12:01 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Oct 2011 17:12:01 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 15:12:04 -0000 2011/10/28 Hadriel Kaplan : > I think this is a really good idea and provides benefits even for SIP cli= ents which are not Javascript-based or in the browser - i.e., it's a useful= transport even for native SIP client applications. Indeed I expect that WebSocket will be widely used by native applications in smartphones. --=20 I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Fri Oct 28 08:57:05 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5BF21F8548 for ; Fri, 28 Oct 2011 08:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBVO8JepDnU2 for ; Fri, 28 Oct 2011 08:57:05 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id C5A7921F8515 for ; Fri, 28 Oct 2011 08:57:04 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta15.westchester.pa.mail.comcast.net with comcast id qFlF1h00G0Fqzac5FFx4v5; Fri, 28 Oct 2011 15:57:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta08.westchester.pa.mail.comcast.net with comcast id qFx31h01J0tdiYw3UFx3LM; Fri, 28 Oct 2011 15:57:04 +0000 Message-ID: <4EAAD0CD.6010506@alum.mit.edu> Date: Fri, 28 Oct 2011 11:57:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 15:57:05 -0000 On 10/28/11 10:59 AM, Hadriel Kaplan wrote: > > I think this is a really good idea and provides benefits even for SIP clients which are not Javascript-based or in the browser - i.e., it's a useful transport even for native SIP client applications. > > Is there time in the SIPCORE WG meeting slot in Taipei to have this draft presented? Generally we want to condition meeting discussion on prior list discussion. So get busy discussing on the list. > Also, I think SIPCORE is the right WG. Me too. AFAIK a final decision hasn't been made of which WG, but I'm ok with discussing it on sipcore for now. Thanks, Paul > -hadriel > > > I think SIPCORE is the right place for this. > > > On Oct 28, 2011, at 8:42 AM, Iñaki Baz Castillo wrote: > >> Hi, let me resend the the mail since I had a problem with my text editor: >> >> >> >> >> A draft describing a mechanism for usage of WebSocket protocol as a >> new transport between SIP entities was submitted to rtcweb WG on 13 >> Sep 2011. However the discussions on that list seemed to conclude that >> the draft was interesting but outside the scope of rtcweb. Since the >> draft describes a new transport for SIP it makes more sense to propose >> it in SIPCORE WG. Therefore we ask the SIPCORE WG to discuss whether >> the proposed draft could fit well in this WG. >> >> There are some aspects of the draft that will be addressed in a new >> revision (as mandating Outbound support given the nature of the >> WebSocket protocol). The first revision of the draft can be found at: >> >> http://datatracker.ietf.org/doc/draft-ibc-rtcweb-sip-websocket/ >> >> -------------------------------- >> Abstract >> >> This document specifies a WebSocket subprotocol for a new transport >> in SIP (Session Initiation Protocol). The WebSocket protocol enables >> two-way realtime communication between clients (typically web-based >> applications) and servers. The main goal of this specification is to >> integrate the SIP protocol within web >> applications. >> ------------------------------ >> >> >> This new SIP transport could fit well within a RTCweb architecture >> (since RTCweb does not mandate the in-the-wire protocol nor the format >> of the messages exchanged between RTCweb clients and servers). This is >> just a use case, a future revision of the draft could incorporate more >> use cases. >> >> >> A presentation of the proposed specification (including a video with >> running code) can be found at: >> >> http://sip-on-the-web.aliax.net/ >> >> ------------------------------- >> Introduction >> >> The aim of this presentation is to show the SIP protocol working >> within a web browser and interoperating with any SIP network. >> >> After some slides describing the used technology there is a >> signaling flowchart and a video showing a real implementation. >> ------------------------------- >> >> >> Please let us know whether this draft would fit well in SIPCORE or may >> be we would do better by proposing it in DISPATCH. >> >> Thanks a lot. >> >> >> -- >> Iñaki Baz Castillo >> >> _______________________________________________ >> 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 HKaplan@acmepacket.com Fri Oct 28 13:46:44 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECA011E8082 for ; Fri, 28 Oct 2011 13:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hUMzjTbB369 for ; Fri, 28 Oct 2011 13:46:43 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8D121F853B for ; Fri, 28 Oct 2011 13:46:43 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 28 Oct 2011 16:46:41 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Fri, 28 Oct 2011 16:46:41 -0400 From: Hadriel Kaplan To: SIPCORE Chairs Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) Thread-Index: AQHMlbKxHSx8E06lTxiCSp8KJOsiwg== Date: Fri, 28 Oct 2011 20:46:40 +0000 Message-ID: References: <4E8C785D.5080003@alum.mit.edu> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522342DDA7E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522342DDA7E@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: <94F65751FBF3D74D85CC4FC88FCE6BE0@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 20:46:44 -0000 Howdy, I've read this latest draft and I propose we make this a WG item. I believ= e there has been strong consensus for this work, from even last year, but a= lso from the following email thread from the SIPCORE Chairs asking for WG c= onsensus: http://www.ietf.org/mail-archive/web/sipcore/current/msg04104.html If this needs a new charter milestone, then I propose a new milestone be ad= ded for: "A mechanism to indicate proxy/B2BUA capabilities to both endpoints and oth= er proxies/B2BUAs in the path of a SIP REGISTER transaction or a dialog-for= ming transaction". There may be some nits/details to argue over in the draft, but I think we c= an do that as a WG draft/item. As often asked for by WG Chairs when considering new milestones: I also vol= unteer to spend time/effort in contributing to the work item, and helping t= he authors by providing text if needed. -hadriel On Oct 28, 2011, at 6:09 AM, Christer Holmberg wrote: >=20 > Hi, >=20 > I've submitted a new version (-03) of draft-holmberg-sipcore-proxy-featur= e, which suggests a solution based on the proxy feature requirements. >=20 > The MAJOR CHANGE, based on the list discussions, is that the mechanism no= w uses a new header field, Feature-Caps, rather than existing header fields= (Record-Route, Path etc). >=20 > I did not include the "SIP-URI alternative" at this point. >=20 > We will also have to think about the "proxy" terminology, as it has been = indicated that entities using the mechanism might not be pure proxies. But,= I don't think that should prevent us from moving forward the the mechanism= as such. >=20 > Thanks to everyone who has provided feedback and input! >=20 > Regards, >=20 > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Sat Oct 29 08:21:09 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3A721F853E for ; Sat, 29 Oct 2011 08:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5rY7ZFRSzjv for ; Sat, 29 Oct 2011 08:21:09 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 37A9821F84E1 for ; Sat, 29 Oct 2011 08:21:08 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-e0-4eac19e2a25a Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 66.DD.13753.2E91CAE4; Sat, 29 Oct 2011 17:21:06 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.197]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Sat, 29 Oct 2011 17:21:05 +0200 From: Christer Holmberg To: Hadriel Kaplan , SIPCORE Chairs Date: Sat, 29 Oct 2011 17:19:58 +0200 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) Thread-Index: AQHMlbKxHSx8E06lTxiCSp8KJOsiwpWTcQsd Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852234CFC9FB@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522342DDA7E@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 15:21:09 -0000 Hi, > As often asked for by WG Chairs when considering new milestones: I also v= olunteer to spend time/effort in contributing to the work item, and helping= the authors by providing text if needed. I have talked to Hadriel, and he will actually become co-author of the docu= ment :) Regards, Christer On Oct 28, 2011, at 6:09 AM, Christer Holmberg wrote: > > Hi, > > I've submitted a new version (-03) of draft-holmberg-sipcore-proxy-featur= e, which suggests a solution based on the proxy feature requirements. > > The MAJOR CHANGE, based on the list discussions, is that the mechanism no= w uses a new header field, Feature-Caps, rather than existing header fields= (Record-Route, Path etc). > > I did not include the "SIP-URI alternative" at this point. > > We will also have to think about the "proxy" terminology, as it has been = indicated that entities using the mechanism might not be pure proxies. But,= I don't think that should prevent us from moving forward the the mechanism= as such. > > Thanks to everyone who has provided feedback and input! > > Regards, > > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From fluffy@cisco.com Sat Oct 29 09:22:32 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC8421F8AAC for ; Sat, 29 Oct 2011 09:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.358 X-Spam-Level: X-Spam-Status: No, score=-106.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah5Of72yxVlQ for ; Sat, 29 Oct 2011 09:22:32 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 03FEF21F8A7E for ; Sat, 29 Oct 2011 09:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3478; q=dns/txt; s=iport; t=1319905351; x=1321114951; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=9Q+2o05/etvoBMsCFDuAxiBxRCX0xOhyG27xMwr3fV4=; b=ToShdoPDYEBHDqMeUUfI7YJWQnBIeEM3ISVbB+ilasC4NOOZzyqvgGjk T2PxEjAZi2GGlRZSxpS+/Cx59dtEhlpwXlCkFxq5ceua1VoHzhxMwYwUB lJ8cifRL8FdOTWkZC+wPY2hcMO6JG693VcRBWbMG5CLVBAVH/iUxn0zn7 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAG8nrE6rRDoH/2dsb2JhbABCqWiBBYFyAQEBAQIBAQEBDwEnNAsFCwsOCiMLJzAGEwkSB4dgCJVTAZ1IiCFhBIgGjAiFLYxR X-IronPort-AV: E=Sophos;i="4.69,424,1315180800"; d="scan'208";a="10033275" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 29 Oct 2011 16:22:31 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9TGMVb0003262; Sat, 29 Oct 2011 16:22:31 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Sat, 29 Oct 2011 10:22:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6CB233EE-CBD0-4319-B46F-1483302263E0@cisco.com> References: <4E8C785D.5080003@alum.mit.edu> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson. se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522342DDA7E@ESESSCMS0356.eemea.ericsson.se> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 16:22:33 -0000 This started as something for a proxy to indicate what type of things = it could support that could show up in a Proxy-Require and allow a given = proxy to indicate to downstream things an additional Proxy-Require level = requirement. I thought that sounded like a reasonable idea but we needed = to nail down the details of what we were actually talking about.=20 Since then it has slowly morphed into the type of DWIM vs DWIS mechanism = that I thought we agreed we did not to do. Keep in mind any UA can act = as an embedded proxy and this looks like the feature scheme that I = thought was the roughly the core of the DWIM vs DWIS argument.=20 Anyways, for any mechanisms of this sort, I will be strongly apposed = unless the registration mechanism for new tags, features, options or = whatever you call them is the same as it is for sip option tags. I have = spoken at the mic several times in favor of what Christer was = presenting but it always had that property. This does not and I am = strongly opposed to it. Given the previous conversation were in the = other context, whatever consensus they may or may not have had does not = seem to apply here. If the goal is simply to change what is required to = register option tags, I'd be happy to have that conversation.=20 On Oct 28, 2011, at 2:46 PM, Hadriel Kaplan wrote: > Howdy, > I've read this latest draft and I propose we make this a WG item. I = believe there has been strong consensus for this work, from even last = year, but also from the following email thread from the SIPCORE Chairs = asking for WG consensus: > http://www.ietf.org/mail-archive/web/sipcore/current/msg04104.html >=20 > If this needs a new charter milestone, then I propose a new milestone = be added for: > "A mechanism to indicate proxy/B2BUA capabilities to both endpoints = and other proxies/B2BUAs in the path of a SIP REGISTER transaction or a = dialog-forming transaction". >=20 > There may be some nits/details to argue over in the draft, but I think = we can do that as a WG draft/item. >=20 > As often asked for by WG Chairs when considering new milestones: I = also volunteer to spend time/effort in contributing to the work item, = and helping the authors by providing text if needed. >=20 > -hadriel >=20 >=20 > On Oct 28, 2011, at 6:09 AM, Christer Holmberg wrote: >=20 >>=20 >> Hi, >>=20 >> I've submitted a new version (-03) of = draft-holmberg-sipcore-proxy-feature, which suggests a solution based on = the proxy feature requirements. >>=20 >> The MAJOR CHANGE, based on the list discussions, is that the = mechanism now uses a new header field, Feature-Caps, rather than = existing header fields (Record-Route, Path etc). >>=20 >> I did not include the "SIP-URI alternative" at this point. >>=20 >> We will also have to think about the "proxy" terminology, as it has = been indicated that entities using the mechanism might not be pure = proxies. But, I don't think that should prevent us from moving forward = the the mechanism as such. >>=20 >> Thanks to everyone who has provided feedback and input! >>=20 >> Regards, >>=20 >> Christer >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Sat Oct 29 14:15:15 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F81B21F8531 for ; Sat, 29 Oct 2011 14:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-+AhUWIJjNS for ; Sat, 29 Oct 2011 14:15:14 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE3A21F8586 for ; Sat, 29 Oct 2011 14:15:14 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-4c-4eac6ce0c8dd Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A4.C6.20773.0EC6CAE4; Sat, 29 Oct 2011 23:15:12 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.197]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Sat, 29 Oct 2011 23:15:12 +0200 From: Christer Holmberg To: Cullen Jennings , Hadriel Kaplan Date: Sat, 29 Oct 2011 23:15:12 +0200 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) Thread-Index: AQHMln/YNZfPFW5kEEmuKmV2LE+m9Q== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852234CFC9FD@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Oct 2011 21:15:15 -0000 Hi Cullen, > This started as something for a proxy to indicate what type of things it= could support that could show up in a Proxy-Require and allow a given prox= y to indicate to downstream things an additional Proxy-Require level requir= ement. I thought that sounded like a reasonable idea but we needed to=20 > nail down the details of what we were actually talking about. > > Since then it has slowly morphed into the type of DWIM vs DWIS mechanism = that I thought we agreed we did not to do. Keep in mind any UA can act as a= n embedded proxy and this looks like the feature scheme that I thought was = the roughly the core of the DWIM vs DWIS argument. The requirements clearly say (or, are supposed to say) that the proxy that = inserts the support indication must not make any assumptions that a receive= r will understand the meaning of it. It is only an "I can do this" indicati= on - NOT an "I have done this" or "I expect you to do this" indication. Tha= t has been the intention from day one :) In that way it is exactly the same as when a UA inserts a feature tag in th= e Contact header field. The proposal is to allow entities that do not inser= t a Contact header field to do the same. Nothing more - nothing less. I am happy to add whatever text is needed to make that even more clear. Regards, Christer > Anyways, for any mechanisms of this sort, I will be strongly apposed unle= ss the registration mechanism for new tags, features, options or whatever y= ou call them is the same as it is for sip option tags. I have spoken at the= mic several times in favor of what Christer was presenting but it always= =20 > had that property. This does not and I am strongly opposed to it. Given t= he previous conversation were in the other context, whatever consensus they= may or may not have had does not seem to apply here. If the goal is simply= to change what is required to register option tags, I'd be happy to=20 > have that conversation. On Oct 28, 2011, at 2:46 PM, Hadriel Kaplan wrote: > Howdy, > I've read this latest draft and I propose we make this a WG item. I beli= eve there has been strong consensus for this work, from even last year, but= also from the following email thread from the SIPCORE Chairs asking for WG= consensus: > http://www.ietf.org/mail-archive/web/sipcore/current/msg04104.html > > If this needs a new charter milestone, then I propose a new milestone be = added for: > "A mechanism to indicate proxy/B2BUA capabilities to both endpoints and o= ther proxies/B2BUAs in the path of a SIP REGISTER transaction or a dialog-f= orming transaction". > > There may be some nits/details to argue over in the draft, but I think we= can do that as a WG draft/item. > > As often asked for by WG Chairs when considering new milestones: I also v= olunteer to spend time/effort in contributing to the work item, and helping= the authors by providing text if needed. > > -hadriel > > > On Oct 28, 2011, at 6:09 AM, Christer Holmberg wrote: > >> >> Hi, >> >> I've submitted a new version (-03) of draft-holmberg-sipcore-proxy-featu= re, which suggests a solution based on the proxy feature requirements. >> >> The MAJOR CHANGE, based on the list discussions, is that the mechanism n= ow uses a new header field, Feature-Caps, rather than existing header field= s (Record-Route, Path etc). >> >> I did not include the "SIP-URI alternative" at this point. >> >> We will also have to think about the "proxy" terminology, as it has been= indicated that entities using the mechanism might not be pure proxies. But= , I don't think that should prevent us from moving forward the the mechanis= m as such. >> >> Thanks to everyone who has provided feedback and input! >> >> Regards, >> >> Christer >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From internet-drafts@ietf.org Sun Oct 30 05:22:28 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84D221F8B04; Sun, 30 Oct 2011 05:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aoV5tnG5b68; Sun, 30 Oct 2011 05:22:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8765721F8AF2; Sun, 30 Oct 2011 05:22:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111030122228.27145.41253.idtracker@ietfa.amsl.com> Date: Sun, 30 Oct 2011 05:22:28 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 12:22:29 -0000 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 Work= ing Group of the IETF. Title : An Extension to the Session Initiation Protocol (SIP) fo= r Request History Information Author(s) : Mary Barnes Francois Audet Shida Schubert Detecon International Gmbh Christer Holmberg Filename : draft-ietf-sipcore-rfc4244bis-06.txt Pages : 65 Date : 2011-10-30 This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field specific to the History-Info header field. This document obsoletes RFC 4244. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-06.txt From salvatore.loreto@ericsson.com Sun Oct 30 06:51:15 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D91421F8B21 for ; Sun, 30 Oct 2011 06:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9Kkp0edPHgc for ; Sun, 30 Oct 2011 06:51:14 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5B33D21F8B15 for ; Sun, 30 Oct 2011 06:51:14 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-e5-4ead564e024a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 04.D8.13753.E465DAE4; Sun, 30 Oct 2011 14:51:10 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Sun, 30 Oct 2011 14:51:10 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2FD9823F6 for ; Sun, 30 Oct 2011 15:51:10 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E96EF519DC for ; Sun, 30 Oct 2011 15:51:09 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9F9FC51331 for ; Sun, 30 Oct 2011 15:51:09 +0200 (EET) Message-ID: <4EAD564D.7030102@ericsson.com> Date: Sun, 30 Oct 2011 15:51:09 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 13:51:15 -0000 On 10/28/11 6:12 PM, Iñaki Baz Castillo wrote: > 2011/10/28 Hadriel Kaplan: >> I think this is a really good idea and provides benefits even for SIP clients which are not Javascript-based or in the browser - i.e., it's a useful transport even for native SIP client applications. I concur, it is a great idea. > Indeed I expect that WebSocket will be widely used by native > applications in smartphones. > I am sure WebSocket is and it will become even more a success (but I am biased here...) /Sal From shida@ntt-at.com Sun Oct 30 23:34:02 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67F421F8CB1 for ; Sun, 30 Oct 2011 23:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEJcniDQbsak for ; Sun, 30 Oct 2011 23:34:02 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 36AE621F8C91 for ; Sun, 30 Oct 2011 23:34:01 -0700 (PDT) Received: from [122.133.87.237] (port=61635 helo=[192.168.1.13]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RKlRY-00014T-EP for sipcore@ietf.org; Mon, 31 Oct 2011 01:34:00 -0500 From: Shida Schubert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 31 Oct 2011 15:33:58 +0900 References: <20111030122228.27145.41253.idtracker@ietfa.amsl.com> To: "sipcore@ietf.org WG" Message-Id: Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: fl1-122-133-87-237.tky.mesh.ad.jp ([192.168.1.13]) [122.133.87.237]:61635 X-Source-Auth: shida@agnada.com X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Subject: [sipcore] Fwd: I-D Action: draft-ietf-sipcore-rfc4244bis-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 06:34:02 -0000 Folks; Although delayed, we have updated the RFC4244bis based on the=20 feedback we received on the ML and at the last meeting.=20 =20 We think all the comments are addressed in this specification and=20 is ready for publication or another, third round of WGLC if people=20 think it is necessary.=20 Also the call-flow has been updated and as it has been previously=20 discussed we think it is ready to be accepted as a WG item if we=20 think that is the way to move it forward. If we decide to accept the=20 draft as a WG item, I think we can probably move it to WGLC right=20 away.=20 Part of the call-flow, namely the call-flow for voicemail examples=20 have been duplicated to RFC4244bis as it was requested by Cullen=20 to have explicit example of how H-I can address the problem.=20 Regards Shida Begin forwarded message: > From: internet-drafts@ietf.org > Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-06.txt > Date: October 30, 2011 9:22:28 PM GMT+09:00 > To: i-d-announce@ietf.org > Cc: sipcore@ietf.org >=20 > 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. >=20 > Title : An Extension to the Session Initiation = Protocol (SIP) for Request History Information > Author(s) : Mary Barnes > Francois Audet > Shida Schubert > Detecon International Gmbh > Christer Holmberg > Filename : draft-ietf-sipcore-rfc4244bis-06.txt > Pages : 65 > Date : 2011-10-30 >=20 > This document defines a standard mechanism for capturing the history > information associated with a Session Initiation Protocol (SIP) > request. This capability enables many enhanced services by = providing > the information as to how and why a SIP request arrives at a = specific > application or user. This document defines an optional SIP header > field, History-Info, for capturing the history information in > requests. The document also defines SIP header field parameters for > the History-Info and Contact header fields to tag the method by = which > the target of a request is determined. In addition, this > specification defines a value for the Privacy header field specific > to the History-Info header field. This document obsoletes RFC 4244. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-06.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-06.txt > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From HKaplan@acmepacket.com Mon Oct 31 10:06:48 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1273211E816F for ; Mon, 31 Oct 2011 10:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdSPBg2R4Bue for ; Mon, 31 Oct 2011 10:06:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 44EA611E815A for ; Mon, 31 Oct 2011 10:06:47 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 31 Oct 2011 13:06:46 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 31 Oct 2011 13:06:46 -0400 From: Hadriel Kaplan To: Cullen Jennings Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) Thread-Index: AQHMl+942YVeDp39cUCISHEeCNukyw== Date: Mon, 31 Oct 2011 17:06:45 +0000 Message-ID: References: <4E8C785D.5080003@alum.mit.edu> <4E8F435B.3030801@alum.mit.edu> <8DB6F79A-B64C-430E-A7CD-5B6F69489089@acmepacket.com> <4E97441C.7070306@alum.mit.edu> <4442C6CB-F4E1-4EA7-886E-06B0807EEEDA@acmepacket.com> <4E9752E8.5000508@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522342DDA7E@ESESSCMS0356.eemea.ericsson.se> <6CB233EE-CBD0-4319-B46F-1483302263E0@cisco.com> In-Reply-To: <6CB233EE-CBD0-4319-B46F-1483302263E0@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: <3FCE65F22A3D7347A03C6F4CF7DEE409@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 17:06:48 -0000 On Oct 29, 2011, at 12:22 PM, Cullen Jennings wrote: > Since then it has slowly morphed into the type of DWIM vs DWIS mechanism = that I thought we agreed we did not to do. Keep in mind any UA can act as a= n embedded proxy and this looks like the feature scheme that I thought was = the roughly the core of the DWIM vs DWIS argument.=20 >=20 > Anyways, for any mechanisms of this sort, I will be strongly apposed unle= ss the registration mechanism for new tags, features, options or whatever y= ou call them is the same as it is for sip option tags. I have spoken at the= mic several times in favor of what Christer was presenting but it always = had that property. This does not and I am strongly opposed to it. Given the= previous conversation were in the other context, whatever consensus they m= ay or may not have had does not seem to apply here. If the goal is simply t= o change what is required to register option tags, I'd be happy to have tha= t conversation.=20 Currently the draft mechanism is indicating RFC-3840-type feature-tags. As= such yes new values require RFCs published through IETF Consensus (IESG ap= proval), as opposed to standards track RFCs as required for option-tags. I= believe as a WG-draft we can choose whether tokens put into a new header a= re actual feature-tags, or some new "capability-tags" with higher RFC appro= val status required. And of course we can say what semantics such new capa= bility-tags RFCs must define and be constrained to. I don't think any of t= hose things prevent us from making it a WG draft do they? I thought being = a WG draft just meant the WG accepted the goal as a milestone, had enough p= eople willing to work on it, and thought the general direction of the draft= 's solution was right. With regards to option-tags: It was my understanding that we keep option-tags under tighter control beca= use they (1) can be used in Require/Proxy-Require and thus break SIP-level = interop badly if they're not thought through very carefully, and (2) are so= metimes used for extensions to the SIP protocol/machinery itself, such as 1= 00rel. The level of RFC required for option-tags was not due to DWIM vs. DWIS as f= ar as I know. IIRC, the DWIM vs. DWIS problem we've talked about before wa= s when a option-tag is used to not only indicate support for an extension, = but actual use of it for the current SIP Request it happens to be in. And = that problem happens for RFC 3840 feature-tags as well; for example if some= one defines a feature-tag "Foo" that means something more than just "I can = do Foo", but instead uses it to be "I will do Foo now" or "I am doing Foo" = or "You must do Foo". Clearly feature-tag values cannot be used in Require/Proxy-Require; and I d= on't believe feature-tag values extend the SIP protocol, or else we should = immediately update the RFC 3840's IANA tree to require standards track RFCs= .=20 Are you worried that people will create new feature-tag values that they th= en require be supported in their domain for SIP to work? Are you worried t= hat people will create new feature-tags which indicate extensions of the SI= P protocol itself? -hadriel From HKaplan@acmepacket.com Mon Oct 31 10:07:47 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D362B11E816F for ; Mon, 31 Oct 2011 10:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUJJ+3GdfqZs for ; Mon, 31 Oct 2011 10:07:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 543BE11E815A for ; Mon, 31 Oct 2011 10:07:47 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 31 Oct 2011 13:07:46 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 31 Oct 2011 13:07:46 -0400 From: Hadriel Kaplan To: Paul Kyzivat Thread-Topic: [sipcore] Proposal for a new SIP transport (WebSocket) Thread-Index: AQHMl++cKl+EUswSEkmV4ZLhenxoVg== Date: Mon, 31 Oct 2011 17:07:45 +0000 Message-ID: <4E2EBDE2-9128-4E6E-ACA6-E4671EA23934@acmepacket.com> References: <4EAAD0CD.6010506@alum.mit.edu> In-Reply-To: <4EAAD0CD.6010506@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 17:07:48 -0000 On Oct 28, 2011, at 11:57 AM, Paul Kyzivat wrote: > Generally we want to condition meeting discussion on prior list discussio= n. So get busy discussing on the list. OK, well I had directly emailed I=F1aki some comments on the draft. Some o= f them were nits around terminology, and re-writing the daft to be more cen= tered around Websocket being another transport type for SIP, rather than as= a Javascript-app. At a high-layer, I can't see anything preventing this from being another tr= ansport type. There're some things to decide once you get into the bits/by= tes/details, but I don't think any of them are insurmountable. But one question is if it should be a complete/first-class transport type l= ike TCP, UDP, and SCTP - i.e., just another transport that could even be us= ed between proxies. -hadriel From ibc@aliax.net Mon Oct 31 10:21:51 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D4A21F87C9 for ; Mon, 31 Oct 2011 10:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2r+clP+mGlPp for ; Mon, 31 Oct 2011 10:21:50 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9470521F85A8 for ; Mon, 31 Oct 2011 10:21:50 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so6019561vcb.31 for ; Mon, 31 Oct 2011 10:21:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.7.12 with SMTP id b12mr2589702vcb.23.1320081709882; Mon, 31 Oct 2011 10:21:49 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Mon, 31 Oct 2011 10:21:49 -0700 (PDT) In-Reply-To: <4E2EBDE2-9128-4E6E-ACA6-E4671EA23934@acmepacket.com> References: <4EAAD0CD.6010506@alum.mit.edu> <4E2EBDE2-9128-4E6E-ACA6-E4671EA23934@acmepacket.com> Date: Mon, 31 Oct 2011 18:21:49 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 17:21:51 -0000 2011/10/31 Hadriel Kaplan : > But one question is if it should be a complete/first-class transport type= like TCP, UDP, and SCTP - i.e., just another transport that could even be = used between proxies. Well, honestly I see no use case for using WebSocket transport between SIP proxies/servers. WebSocket is clearly a transport for web browsers and also for client applications. There is no advantage in using WebSocket between other SIP nodes. --=20 I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Mon Oct 31 10:46:08 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916BF1F0C8E for ; Mon, 31 Oct 2011 10:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6zXbz9pB5WX for ; Mon, 31 Oct 2011 10:46:07 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6067A1F0C67 for ; Mon, 31 Oct 2011 10:46:07 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta10.westchester.pa.mail.comcast.net with comcast id rVm21h00316LCl05AVm7zX; Mon, 31 Oct 2011 17:46:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta06.westchester.pa.mail.comcast.net with comcast id rVm71h00A0tdiYw3SVm7cy; Mon, 31 Oct 2011 17:46:07 +0000 Message-ID: <4EAEDEDD.30202@alum.mit.edu> Date: Mon, 31 Oct 2011 13:46:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <4E8C785D.5080003@alum.mit.edu> <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522342DDA7E@ESESSCMS0356.eemea.ericsson.se> <6CB233EE-CBD0-4319-B46F-1483302263E0@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 17:46:08 -0000 On 10/31/11 1:06 PM, Hadriel Kaplan wrote: > > On Oct 29, 2011, at 12:22 PM, Cullen Jennings wrote: > >> Since then it has slowly morphed into the type of DWIM vs DWIS mechanism that I thought we agreed we did not to do. Keep in mind any UA can act as an embedded proxy and this looks like the feature scheme that I thought was the roughly the core of the DWIM vs DWIS argument. >> >> Anyways, for any mechanisms of this sort, I will be strongly apposed unless the registration mechanism for new tags, features, options or whatever you call them is the same as it is for sip option tags. I have spoken at the mic several times in favor of what Christer was presenting but it always had that property. This does not and I am strongly opposed to it. Given the previous conversation were in the other context, whatever consensus they may or may not have had does not seem to apply here. If the goal is simply to change what is required to register option tags, I'd be happy to have that conversation. > > Currently the draft mechanism is indicating RFC-3840-type feature-tags. As such yes new values require RFCs published through IETF Consensus (IESG approval), as opposed to standards track RFCs as required for option-tags. I believe as a WG-draft we can choose whether tokens put into a new header are actual feature-tags, or some new "capability-tags" with higher RFC approval status required. And of course we can say what semantics such new capability-tags RFCs must define and be constrained to. I don't think any of those things prevent us from making it a WG draft do they? I thought being a WG draft just meant the WG accepted the goal as a milestone, had enough people willing to work on it, and thought the general direction of the draft's solution was right. Actually, its possible to define feature tags without any standards action. See section 3.1.3 of RFC 2506. (It allows feature tags beginning with "u." followed by a URI.) Its my impression that this is one of the things that 3gpp likes about feature tags - they can define new ones without an ietf standards action. Thanks, Paul > With regards to option-tags: > It was my understanding that we keep option-tags under tighter control because they (1) can be used in Require/Proxy-Require and thus break SIP-level interop badly if they're not thought through very carefully, and (2) are sometimes used for extensions to the SIP protocol/machinery itself, such as 100rel. > > The level of RFC required for option-tags was not due to DWIM vs. DWIS as far as I know. IIRC, the DWIM vs. DWIS problem we've talked about before was when a option-tag is used to not only indicate support for an extension, but actual use of it for the current SIP Request it happens to be in. And that problem happens for RFC 3840 feature-tags as well; for example if someone defines a feature-tag "Foo" that means something more than just "I can do Foo", but instead uses it to be "I will do Foo now" or "I am doing Foo" or "You must do Foo". > > Clearly feature-tag values cannot be used in Require/Proxy-Require; and I don't believe feature-tag values extend the SIP protocol, or else we should immediately update the RFC 3840's IANA tree to require standards track RFCs. > > Are you worried that people will create new feature-tag values that they then require be supported in their domain for SIP to work? Are you worried that people will create new feature-tags which indicate extensions of the SIP protocol itself? > > -hadriel > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@alum.mit.edu Mon Oct 31 10:51:33 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A621F0C67 for ; Mon, 31 Oct 2011 10:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtWM-ZOoCrG3 for ; Mon, 31 Oct 2011 10:51:33 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id E569E1F0C91 for ; Mon, 31 Oct 2011 10:51:32 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta03.westchester.pa.mail.comcast.net with comcast id rVrZ1h0031GhbT853VrZTY; Mon, 31 Oct 2011 17:51:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta07.westchester.pa.mail.comcast.net with comcast id rVrY1h01E0tdiYw3TVrZMT; Mon, 31 Oct 2011 17:51:33 +0000 Message-ID: <4EAEE023.6010600@alum.mit.edu> Date: Mon, 31 Oct 2011 13:51:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 17:51:34 -0000 [As individual] Iñaki, Thanks for submitting this. Its a good start. I saw a few things that need some investigation: Section 6: The requirement to use sips for the contact uri if the connection to the server is secure via wss will force all other hops to be secured too. So the server can only connect to another client that has established a wss connection with a sips contact, or to another sip server via a sips URI. This ought to be spelled out. (Its violated in an example.) The constructed contact address is not globally reachable - it can only be reached through the server. And there mention of gruus, which is a solution to that problem. How to address this needs further discussion. Section 7: When the server is trying to route requests, how can it determine which addresses correspond to a particular websocket? This is a form of connection reuse, which has been addressed by RFC 5626 (outbound) and RFC 5923. Note that there was much effort to make 5923 define connection reuse over TCP, but no safe way was found and it was abandoned.) There needs to be a careful analysis of the security aspects of reusing the connection for outbound requests. And then it will likely result in updating RFC 5630 (sip-sips) and RFC 3261 regarding sips. Section 9.2: Shows sending to a sips URI using UDP, which isn't permitted. I may have more comments later, but that's all for now. Thanks, Paul On 10/28/11 8:42 AM, Iñaki Baz Castillo wrote: > Hi, let me resend the the mail since I had a problem with my text editor: > > A draft describing a mechanism for usage of WebSocket protocol as a > new transport between SIP entities was submitted to rtcweb WG on 13 > Sep 2011. However the discussions on that list seemed to conclude that > the draft was interesting but outside the scope of rtcweb. Since the > draft describes a new transport for SIP it makes more sense to propose > it in SIPCORE WG. Therefore we ask the SIPCORE WG to discuss whether > the proposed draft could fit well in this WG. > > There are some aspects of the draft that will be addressed in a new > revision (as mandating Outbound support given the nature of the > WebSocket protocol). The first revision of the draft can be found at: > > http://datatracker.ietf.org/doc/draft-ibc-rtcweb-sip-websocket/ > > -------------------------------- > Abstract > > This document specifies a WebSocket subprotocol for a new transport > in SIP (Session Initiation Protocol). The WebSocket protocol enables > two-way realtime communication between clients (typically web-based > applications) and servers. The main goal of this specification is to > integrate the SIP protocol within web > applications. > ------------------------------ > > > This new SIP transport could fit well within a RTCweb architecture > (since RTCweb does not mandate the in-the-wire protocol nor the format > of the messages exchanged between RTCweb clients and servers). This is > just a use case, a future revision of the draft could incorporate more > use cases. > > > A presentation of the proposed specification (including a video with > running code) can be found at: > > http://sip-on-the-web.aliax.net/ > > ------------------------------- > Introduction > > The aim of this presentation is to show the SIP protocol working > within a web browser and interoperating with any SIP network. > > After some slides describing the used technology there is a > signaling flowchart and a video showing a real implementation. > ------------------------------- > > > Please let us know whether this draft would fit well in SIPCORE or may > be we would do better by proposing it in DISPATCH. > > Thanks a lot. > > From ibc@aliax.net Mon Oct 31 11:08:19 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6E321F8DA8 for ; Mon, 31 Oct 2011 11:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7+QlvoasleX for ; Mon, 31 Oct 2011 11:08:14 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A9BEF21F8DAC for ; Mon, 31 Oct 2011 11:08:09 -0700 (PDT) Received: by vws5 with SMTP id 5so6079276vws.31 for ; Mon, 31 Oct 2011 11:08:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.70 with SMTP id f6mr5291470vdj.84.1320084489141; Mon, 31 Oct 2011 11:08:09 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Mon, 31 Oct 2011 11:08:09 -0700 (PDT) In-Reply-To: <4EAEE023.6010600@alum.mit.edu> References: <4EAEE023.6010600@alum.mit.edu> Date: Mon, 31 Oct 2011 19:08:09 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 18:08:19 -0000 2011/10/31 Paul Kyzivat : > I=C3=B1aki, > > Thanks for submitting this. Its a good start. I saw a few things that nee= d > some investigation: > > Section 6: > > The requirement to use sips for the contact uri if the connection to the > server is secure via wss will force all other hops to be secured too. So = the > server can only connect to another client that has established a wss > connection with a sips contact, or to another sip server via a sips URI. > This ought to be spelled out. (Its violated in an example.) First of all let me say that I plan to remove "sips" schema from the draft (given the ammount of issues with "sips" mechanism). However, the remote peer (using SIP over UDP so "sip" scheme) never contacts a SIP node speaking "sips", but "sip". The proxy adds two Record-Route, the the UDP peer always contacts the URI in the Record-Route with "sip" schema and UDP protocol. > The constructed contact address is not globally reachable - it can only b= e > reached through the server. And there mention of gruus, which is a soluti= on > to that problem. How to address this needs further discussion. Indeed, for a new revision of the draft I plan to make Outbound mandatory for WebSocket clients so there is no need for "discovering the local IP address". I also have to add a modification to RFC 3261: When a proxy/server receives a request via WebSocket transport, it MAY choose not to add the ";received" param in the top Via. This is because WebSocket is supposed to use already existing infrastructure in which there can be certain number of HTTP or TCP load balancers between the client and HTTP/WebSocket server, so the server would write into ;received the IP of the load balancer in front of it. This would reveal the client the internal HTTP/TCP topology of the server which could be insecure. So adding ;received to Via would be a local policy decision. > Section 7: > > When the server is trying to route requests, how can it determine which > addresses correspond to a particular websocket? As said above, Outbound should be mandatory for WebSocket client and their outbound proxies (Outbound EDGE proxies). Of course, there could be no outbound proxy but a single proxy/registrar (in this case it must also implement Outbound). So for determining which addresses correspond to a particular websocket the proxy MUST perform RFC 5626 procedures (by inspecting the token flow in the Route header). My current implementation does it and works perfectly. The same as for TCP/TLS/UDP clients. > This is a form of connection > reuse, which has been addressed by RFC 5626 (outbound) and RFC 5923. Note > that there was much effort to make 5923 define connection reuse over TCP, > but no safe way was found and it was abandoned.) If I'm not wrong, we are done with Outbound. > There needs to be a careful analysis of the security aspects of reusing t= he > connection for outbound requests. And then it will likely result in updat= ing > RFC 5630 (sip-sips) and RFC 3261 regarding sips. But using Outbound is enough, am I right? This is, I've coded a strict implementation of Outbound in my proxy speaking WebSocket and I'm not aware of security concerns. > Section 9.2: > > Shows sending to a sips URI using UDP, which isn't permitted. But the top Route is "sip", so the destination of the request is a "sip" URI rather than "sips". Is it still invalid? I need clarification on this. > I may have more comments later, but that's all for now. Really thanks a lot for your comments. I will address of all them in a new revision of the draft. Regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Mon Oct 31 11:36:03 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F34D1F0C8A for ; Mon, 31 Oct 2011 11:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.244 X-Spam-Level: X-Spam-Status: No, score=-6.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hj1QiTwD0Kbs for ; Mon, 31 Oct 2011 11:36:02 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 57D9C1F0C3B for ; Mon, 31 Oct 2011 11:36:02 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-3f-4eaeea91684b Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B5.79.13753.19AEEAE4; Mon, 31 Oct 2011 19:36:01 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Mon, 31 Oct 2011 19:36:01 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Date: Mon, 31 Oct 2011 19:36:00 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) Thread-Index: AcyX9P8WCSJb5hIXS7yMQBTyp0Z2WwAAvPCZ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852235717398@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522342DDA7E@ESESSCMS0356.eemea.ericsson.se> <6CB233EE-CBD0-4319-B46F-1483302263E0@cisco.com> , <4EAEDEDD.30202@alum.mit.edu> In-Reply-To: <4EAEDEDD.30202@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 18:36:03 -0000 Hi, >> Since then it has slowly morphed into the type of DWIM vs DWIS mechanism= that I thought we agreed we did not to do. Keep in mind any UA can >> act as an embedded proxy and this looks like the feature scheme that I t= hought was the roughly the core of the DWIM vs DWIS argument. >> >> Anyways, for any mechanisms of this sort, I will be strongly apposed unl= ess the registration mechanism for new tags, features, options or whatever >> you call them is the same as it is for sip option tags. I have spoken at= the mic several times in favor of what Christer was presenting but it alw= ays had=20 >> that property. This does not and I am strongly opposed to it. Given the = previous conversation were in the other context, whatever consensus they >> may or may not have had does not seem to apply here. If the goal is simp= ly to change what is required to register option tags, I'd be happy to have= that conversation. > > Currently the draft mechanism is indicating RFC-3840-type feature-tags. = As such yes new values require RFCs published through IETF Consensus (IESG = approval), as=20 > opposed to standards track RFCs as required for option-tags. I believe a= s a WG-draft we can choose whether tokens put into a new header are actual = feature-tags, > or some new "capability-tags" with higher RFC approval status required. = And of course we can say what semantics such new capability-tags RFCs must = define and be > constrained to. I don't think any of those things prevent us from making= it a WG draft do they? I thought being a WG draft just meant the WG accep= ted the goal as a > milestone, had enough people willing to work on it, and thought the gener= al direction of the draft's solution was right. > > Actually, its possible to define feature tags without any standards > action. See section 3.1.3 of RFC 2506. (It allows feature tags beginning > with "u." followed by a URI.) > > Its my impression that this is one of the things that 3gpp likes about > feature tags - they can define new ones without an ietf standards action. There are no 3GPP defined feature tags beginning with "u", and as far as I = know 3GPP has (or, is in the progress of) registered all their feature tags= with IANA. And, as you also indicated, we can specify what information a feature tag s= pecification, and its associated IANA registration, needs to contain. Also, if you look at the use-cases behind this work, I think feature tags a= re very appropriate. We are talking about feature indications ("I can do th= is"). And, we are not talking about extensions to the SIP protocol, in which case I agree option-tags probably would be more suitable. Regards, Christer > With regards to option-tags: > It was my understanding that we keep option-tags under tighter control be= cause they (1) can be used in Require/Proxy-Require and thus break SIP-leve= l interop badly if they're not thought through very carefully, and (2) are = sometimes used for extensions to the SIP protocol/machinery itself, such as= 100rel. > > The level of RFC required for option-tags was not due to DWIM vs. DWIS as= far as I know. IIRC, the DWIM vs. DWIS problem we've talked about before = was when a option-tag is used to not only indicate support for an extension= , but actual use of it for the current SIP Request it happens to be in. An= d that problem happens for RFC 3840 feature-tags as well; for example if so= meone defines a feature-tag "Foo" that means something more than just "I ca= n do Foo", but instead uses it to be "I will do Foo now" or "I am doing Foo= " or "You must do Foo". > > Clearly feature-tag values cannot be used in Require/Proxy-Require; and I= don't believe feature-tag values extend the SIP protocol, or else we shoul= d immediately update the RFC 3840's IANA tree to require standards track RF= Cs. > > Are you worried that people will create new feature-tag values that they = then require be supported in their domain for SIP to work? Are you worried= that people will create new feature-tags which indicate extensions of the = SIP protocol itself? > > -hadriel > > _______________________________________________ > 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 HKaplan@acmepacket.com Mon Oct 31 12:01:39 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D79FE11E817C for ; Mon, 31 Oct 2011 12:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWM-Gy2zl+wt for ; Mon, 31 Oct 2011 12:01:39 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 557A01F0CD9 for ; Mon, 31 Oct 2011 12:01:34 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 31 Oct 2011 15:01:30 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 31 Oct 2011 15:01:30 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [sipcore] Proposal for a new SIP transport (WebSocket) Thread-Index: AQHMl/9/E/pvICxCE0iwgQIgSxeNpw== Date: Mon, 31 Oct 2011 19:01:29 +0000 Message-ID: <2FCEB44F-12ED-4460-987A-E4FC6E4FB48E@acmepacket.com> References: <4EAAD0CD.6010506@alum.mit.edu> <4E2EBDE2-9128-4E6E-ACA6-E4671EA23934@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 19:01:40 -0000 On Oct 31, 2011, at 1:21 PM, I=F1aki Baz Castillo wrote: > 2011/10/31 Hadriel Kaplan : >> But one question is if it should be a complete/first-class transport typ= e like TCP, UDP, and SCTP - i.e., just another transport that could even be= used between proxies. >=20 > Well, honestly I see no use case for using WebSocket transport between > SIP proxies/servers. WebSocket is clearly a transport for web browsers > and also for client applications. There is no advantage in using > WebSocket between other SIP nodes. I'm not sure I see one either, but I think I can manufacture possible use-c= ases: 1) Since websocket has an HTTP layer to create the "transport" for the appl= ication/SIP layer, you can use the HTTP digest/challenge mechanism as a tra= nsport-layer authentication scheme. For example, a proxy/B2BUA generating = a new websocket connection to another proxy can be challenged in HTTP - wit= hout confusion as to whom the challenge is for, as is sometimes the case wh= en the challenge is in a SIP response. I.e., it would be a single-hop prox= y-proxy digest/challenge mechanism. Mutual-TLS obviates the need for that = generally, but mutual-TLS isn't always available/practical. 2) Since websocket can cross even restrictive firewalls, you could use a pi= ece of proxy-ish software on your laptop like SER or Asterix or SipXecs or = whatever. I have no idea why you'd want to run those from behind a restric= tive firewall, or why you couldn't configure the firewall to let you do it,= instead of using websocket; but if you needed to, you could use websocket. But yeah those aren't very compelling. I'm ok with making it a client-spec= ific thing, similar to (and probably based on) Sip-Outbound. I just think = we need to decide, one way or the other. -hadriel From ibc@aliax.net Mon Oct 31 12:15:44 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1869421F8DB6 for ; Mon, 31 Oct 2011 12:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZleZvFBbgSi1 for ; Mon, 31 Oct 2011 12:15:43 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62F7D21F8DB2 for ; Mon, 31 Oct 2011 12:15:43 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so6143531vcb.31 for ; Mon, 31 Oct 2011 12:15:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.7.12 with SMTP id b12mr2625112vcb.23.1320088542838; Mon, 31 Oct 2011 12:15:42 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Mon, 31 Oct 2011 12:15:42 -0700 (PDT) In-Reply-To: <2FCEB44F-12ED-4460-987A-E4FC6E4FB48E@acmepacket.com> References: <4EAAD0CD.6010506@alum.mit.edu> <4E2EBDE2-9128-4E6E-ACA6-E4671EA23934@acmepacket.com> <2FCEB44F-12ED-4460-987A-E4FC6E4FB48E@acmepacket.com> Date: Mon, 31 Oct 2011 20:15:42 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 19:15:44 -0000 2011/10/31 Hadriel Kaplan : > I'm not sure I see one either, but I think I can manufacture possible use= -cases: > 1) Since websocket has an HTTP layer to create the "transport" for the ap= plication/SIP layer, you can use the HTTP digest/challenge mechanism as a t= ransport-layer authentication scheme. =C2=A0For example, a proxy/B2BUA gene= rating a new websocket connection to another proxy can be challenged in HTT= P - without confusion as to whom the challenge is for, as is sometimes the = case when the challenge is in a SIP response. =C2=A0I.e., it would be a sin= gle-hop proxy-proxy digest/challenge mechanism. =C2=A0Mutual-TLS obviates t= he need for that generally, but mutual-TLS isn't always available/practical= . Unfortunately authentication in WebSocket is not defined at transport layer (or at HTTP layer during the initial HTTP handshake). So regardless it uses HTTP for the handshake, the client will not react if it receives a HTTP 401/407 response. In fact, the WebSocket JS API does not include functions or callbacks for handling ah HTTP response other than 101. In the other side, a WebSocket HTTP handshake can contain a Cookie header (like in normal HTTP). This is supposed to be used as authentication/authorization (assuming that the web browser previously navigated a web page with same domain and got a Cookie). Any other kind of authentication must be done at application level (so within the custom WebSocket Subprotocol implemented on top of the WebSocket transport). Given this, I don't want to enter on how to authenticate a WebSocket connection. In fact, my implementation does not ask for authentication to the WebSocket client. Instead, it checks a HTTP GET query param (imagine it as a "license key") and when a SIP request arrives via WebSocket, the proxy routes it to the main proxy which asks for authentication (401/407) as usual. So I don't ask for authentication in my WebSocket capable SIP proxy. Of course, this is up to the developer/admin, and therefore I think it's better not to mention it in the draft. > 2) Since websocket can cross even restrictive firewalls, you could use a = piece of proxy-ish software on your laptop like SER or Asterix or SipXecs o= r whatever. =C2=A0I have no idea why you'd want to run those from behind a = restrictive firewall, or why you couldn't configure the firewall to let you= do it, instead of using websocket; but if you needed to, you could use web= socket. Huh... that's really freak :) > But yeah those aren't very compelling. =C2=A0I'm ok with making it a clie= nt-specific thing, similar to (and probably based on) Sip-Outbound. =C2=A0I= just think we need to decide, one way or the other. IMHO the draft should be focused on WebSocket clients (web browsers or other client applications), but there is no problem at all in leaving the door open in the draft for those who want to use WebSocket between other SIP entities. Regards. --=20 I=C3=B1aki Baz Castillo From dworley@avaya.com Mon Oct 31 12:37:42 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9D91F0CDE for ; Mon, 31 Oct 2011 12:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.902 X-Spam-Level: X-Spam-Status: No, score=-102.902 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a89jbPiIlQur for ; Mon, 31 Oct 2011 12:37:41 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id AF03A1F0C3D for ; Mon, 31 Oct 2011 12:37:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8IAFT4rk7GmAcF/2dsb2JhbABDpmmCTX4HgXIBAQEBAgESbAsCAQgNCDEyJQIEEwgah2CYTptTiCFhBIdWkgSMLw X-IronPort-AV: E=Sophos;i="4.69,433,1315195200"; d="scan'208";a="215596889" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 31 Oct 2011 15:37:40 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 31 Oct 2011 15:35:16 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.55]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Mon, 31 Oct 2011 15:37:40 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Mon, 31 Oct 2011 15:37:15 -0400 Thread-Topic: [sipcore] Proposal for a new SIP transport (WebSocket) Thread-Index: AQHMl/9/E/pvICxCE0iwgQIgSxeNp5WW2PwV Message-ID: References: <4EAAD0CD.6010506@alum.mit.edu> <4E2EBDE2-9128-4E6E-ACA6-E4671EA23934@acmepacket.com> , <2FCEB44F-12ED-4460-987A-E4FC6E4FB48E@acmepacket.com> In-Reply-To: <2FCEB44F-12ED-4460-987A-E4FC6E4FB48E@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 19:37:42 -0000 > From: I=F1aki Baz Castillo [ibc@aliax.net] =20 >=20 > Well, honestly I see no use case for using WebSocket transport between > SIP proxies/servers. WebSocket is clearly a transport for web browsers > and also for client applications. There is no advantage in using > WebSocket between other SIP nodes. It sounds like WebSocket paths are effectively a variant of the connection between the UA and the Edge Proxy in SIP Outbound (RFC 5626), and what they need is a "flow token" (defined by the edge proxy), not a new Via transport value (standardized). > From: Hadriel Kaplan [HKaplan@acmepacket.com] =20 >=20 > 2) Since websocket can cross even restrictive firewalls, you could use > a piece of proxy-ish software on your laptop like SER or Asterix or > SipXecs or whatever. I have no idea why you'd want to run those from > behind a restrictive firewall, or why you couldn't configure the > firewall to let you do it, instead of using websocket; but if you > needed to, you could use websocket. Isn't there an RFC (around 1 April 1988?) detailing encapsulating IP packets in HTTP requests/responses as a way to get through restrictive firewalls? Dale From HKaplan@acmepacket.com Mon Oct 31 12:44:07 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2804011E8190 for ; Mon, 31 Oct 2011 12:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NcDVeX4+C3mr for ; Mon, 31 Oct 2011 12:44:06 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 951C611E818C for ; Mon, 31 Oct 2011 12:44:06 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 31 Oct 2011 15:44:04 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 31 Oct 2011 15:44:04 -0400 From: Hadriel Kaplan To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [sipcore] Proposal for a new SIP transport (WebSocket) Thread-Index: AQHMmAVxaMQxglMC9EWoleNjPjfWcA== Date: Mon, 31 Oct 2011 19:44:03 +0000 Message-ID: <7618D6F6-0509-442A-9CDD-07DAC2B11D70@acmepacket.com> References: <4EAAD0CD.6010506@alum.mit.edu> <4E2EBDE2-9128-4E6E-ACA6-E4671EA23934@acmepacket.com> <2FCEB44F-12ED-4460-987A-E4FC6E4FB48E@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3F8BC9831446034F8F380235018F3123@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 19:44:07 -0000 On Oct 31, 2011, at 3:15 PM, I=F1aki Baz Castillo wrote: > 2011/10/31 Hadriel Kaplan : >> I'm not sure I see one either, but I think I can manufacture possible us= e-cases: >> 1) Since websocket has an HTTP layer to create the "transport" for the a= pplication/SIP layer, you can use the HTTP digest/challenge mechanism as a = transport-layer authentication scheme. For example, a proxy/B2BUA generati= ng a new websocket connection to another proxy can be challenged in HTTP - = without confusion as to whom the challenge is for, as is sometimes the case= when the challenge is in a SIP response. I.e., it would be a single-hop p= roxy-proxy digest/challenge mechanism. Mutual-TLS obviates the need for th= at generally, but mutual-TLS isn't always available/practical. >=20 > Unfortunately authentication in WebSocket is not defined at transport > layer (or at HTTP layer during the initial HTTP handshake). So > regardless it uses HTTP for the handshake, the client will not react > if it receives a HTTP 401/407 response. draft-ietf-hybi-thewebsocketprotocol-17, section 4.1: 1. If the status code received from the server is not 101, the client handles the response per HTTP [RFC2616] procedures, in particular the client might perform authentication if it receives 401 status code, the server might redirect the client using a 3xx status code (but clients are not required to follow them), etc. section 4.2.2: 2. The server can perform additional client authentication, for example by returning a 401 status code with the corresponding WWW-Authenticate header field as described in [RFC2616]. Do those not mean what I thought they meant? > In fact, the WebSocket JS API > does not include functions or callbacks for handling ah HTTP response > other than 101. But I'm not talking about what a Web browser might expose to a Javascript A= PI - I'm talking about websocket as a SIP transport layer. =20 Obviously we'll want to enable using websockets from a bowser's Javascript = too - but I'm only talking about a use-case of proxy-to-proxy above, which = doesn't care about browser-specific uses. -hadriel From ibc@aliax.net Mon Oct 31 12:48:36 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A3D11E81AF for ; Mon, 31 Oct 2011 12:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3KGQ6nRGX6i for ; Mon, 31 Oct 2011 12:48:36 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F0D1611E818C for ; Mon, 31 Oct 2011 12:48:35 -0700 (PDT) Received: by vws5 with SMTP id 5so6182362vws.31 for ; Mon, 31 Oct 2011 12:48:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.7.12 with SMTP id b12mr2638643vcb.23.1320090513330; Mon, 31 Oct 2011 12:48:33 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Mon, 31 Oct 2011 12:48:33 -0700 (PDT) In-Reply-To: References: <4EAAD0CD.6010506@alum.mit.edu> <4E2EBDE2-9128-4E6E-ACA6-E4671EA23934@acmepacket.com> <2FCEB44F-12ED-4460-987A-E4FC6E4FB48E@acmepacket.com> Date: Mon, 31 Oct 2011 20:48:33 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Worley, Dale R (Dale)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 19:48:36 -0000 2011/10/31 Worley, Dale R (Dale) : >> From: I=C3=B1aki Baz Castillo [ibc@aliax.net] >> >> Well, honestly I see no use case for using WebSocket transport between >> SIP proxies/servers. WebSocket is clearly a transport for web browsers >> and also for client applications. There is no advantage in using >> WebSocket between other SIP nodes. > > It sounds like WebSocket paths are effectively a variant of the > connection between the UA and the Edge Proxy in SIP Outbound (RFC > 5626), and what they need is a "flow token" (defined by the edge > proxy), not a new Via transport value (standardized). I agree, and that's the reason for which I plan to mandate Outbound in the draft. > not a new Via transport value (standardized). This is a new SIP transport, so IMHO a new Via transport value is required. Regards. --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Mon Oct 31 12:50:40 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DFB11E81B0 for ; Mon, 31 Oct 2011 12:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMs9kJs80554 for ; Mon, 31 Oct 2011 12:50:39 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id E47CA21F8D87 for ; Mon, 31 Oct 2011 12:50:37 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 31 Oct 2011 15:50:35 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 31 Oct 2011 15:50:35 -0400 From: Hadriel Kaplan To: "Worley, Dale R (Dale)" Thread-Topic: [sipcore] Proposal for a new SIP transport (WebSocket) Thread-Index: AQHMmAZaaMQxglMC9EWoleNjPjfWcA== Date: Mon, 31 Oct 2011 19:50:35 +0000 Message-ID: <509ED151-FEAD-44B3-A9A7-09FFFBB71D35@acmepacket.com> References: <4EAAD0CD.6010506@alum.mit.edu> <4E2EBDE2-9128-4E6E-ACA6-E4671EA23934@acmepacket.com> , <2FCEB44F-12ED-4460-987A-E4FC6E4FB48E@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2B6DF146A8DA9D458BBD9280480292EC@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 19:50:40 -0000 On Oct 31, 2011, at 3:37 PM, Worley, Dale R (Dale) wrote: >> From: Hadriel Kaplan [HKaplan@acmepacket.com] =20 >>=20 >> 2) Since websocket can cross even restrictive firewalls, you could use >> a piece of proxy-ish software on your laptop like SER or Asterix or >> SipXecs or whatever. I have no idea why you'd want to run those from >> behind a restrictive firewall, or why you couldn't configure the >> firewall to let you do it, instead of using websocket; but if you >> needed to, you could use websocket. >=20 > Isn't there an RFC (around 1 April 1988?) detailing encapsulating IP > packets in HTTP requests/responses as a way to get through restrictive > firewalls? Yup, and I was seriously debating whether to send an email to the IETF-disc= uss malling list suggesting draft-ietf-hybi-thewebsocketprotocol-17 should = actually either officially update or deprecate RFC 3093, when the draft was= put for IETF Last Call not long ago. But I thought doing so might backfir= e on me someday so I chickened out. :( -hadriel From ibc@aliax.net Mon Oct 31 12:51:19 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CFC11E81BC for ; Mon, 31 Oct 2011 12:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IbOOO1CUhYV for ; Mon, 31 Oct 2011 12:51:19 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4648B11E81B9 for ; Mon, 31 Oct 2011 12:51:19 -0700 (PDT) Received: by vws5 with SMTP id 5so6185096vws.31 for ; Mon, 31 Oct 2011 12:51:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.150.81 with SMTP id x17mr2567562vcv.233.1320090678792; Mon, 31 Oct 2011 12:51:18 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Mon, 31 Oct 2011 12:51:18 -0700 (PDT) In-Reply-To: <7618D6F6-0509-442A-9CDD-07DAC2B11D70@acmepacket.com> References: <4EAAD0CD.6010506@alum.mit.edu> <4E2EBDE2-9128-4E6E-ACA6-E4671EA23934@acmepacket.com> <2FCEB44F-12ED-4460-987A-E4FC6E4FB48E@acmepacket.com> <7618D6F6-0509-442A-9CDD-07DAC2B11D70@acmepacket.com> Date: Mon, 31 Oct 2011 20:51:18 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 19:51:20 -0000 2011/10/31 Hadriel Kaplan : >> 2011/10/31 Hadriel Kaplan : >>> I'm not sure I see one either, but I think I can manufacture possible u= se-cases: >>> 1) Since websocket has an HTTP layer to create the "transport" for the = application/SIP layer, you can use the HTTP digest/challenge mechanism as a= transport-layer authentication scheme. =C2=A0For example, a proxy/B2BUA ge= nerating a new websocket connection to another proxy can be challenged in H= TTP - without confusion as to whom the challenge is for, as is sometimes th= e case when the challenge is in a SIP response. =C2=A0I.e., it would be a s= ingle-hop proxy-proxy digest/challenge mechanism. =C2=A0Mutual-TLS obviates= the need for that generally, but mutual-TLS isn't always available/practic= al. >> >> Unfortunately authentication in WebSocket is not defined at transport >> layer (or at HTTP layer during the initial HTTP handshake). So >> regardless it uses HTTP for the handshake, the client will not react >> if it receives a HTTP 401/407 response. > > draft-ietf-hybi-thewebsocketprotocol-17, section 4.1: > =C2=A0 1. =C2=A0If the status code received from the server is not 101, t= he > =C2=A0 =C2=A0 =C2=A0 client handles the response per HTTP [RFC2616] proce= dures, in > =C2=A0 =C2=A0 =C2=A0 particular the client might perform authentication i= f it receives > =C2=A0 =C2=A0 =C2=A0 401 status code, the server might redirect the clien= t using a 3xx > =C2=A0 =C2=A0 =C2=A0 status code (but clients are not required to follow = them), etc. > > section 4.2.2: > =C2=A0 2. =C2=A0The server can perform additional client authentication, = for > =C2=A0 =C2=A0 =C2=A0 example by returning a 401 status code with the corr= esponding > =C2=A0 =C2=A0 =C2=A0 WWW-Authenticate header field as described in [RFC26= 16]. > > > Do those not mean what I thought they meant? Yes, you are right. However I invite you to test a WebSocket connection from the latest Chrome or Firefox (which implement the last version of websocket draft-17) against a WebSocket server that returns a 401 :) > >> In fact, the WebSocket JS API >> does not include functions or callbacks for handling ah HTTP response >> other than 101. > > But I'm not talking about what a Web browser might expose to a Javascript= API - I'm talking about websocket as a SIP transport layer. > > Obviously we'll want to enable using websockets from a bowser's Javascrip= t too - but I'm only talking about a use-case of proxy-to-proxy above, whic= h doesn't care about browser-specific uses. Sure. I agree. So that could added to the draft as a possible authentication mechanism. Thanks. --=20 I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Mon Oct 31 12:52:55 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D01A11E81BB for ; Mon, 31 Oct 2011 12:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-8G3B-wEnsH for ; Mon, 31 Oct 2011 12:52:54 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id A3EC411E81B5 for ; Mon, 31 Oct 2011 12:52:54 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta12.westchester.pa.mail.comcast.net with comcast id rQRQ1h0061uE5Es5CXsvl5; Mon, 31 Oct 2011 19:52:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta16.westchester.pa.mail.comcast.net with comcast id rXsu1h01K0tdiYw3cXsudF; Mon, 31 Oct 2011 19:52:54 +0000 Message-ID: <4EAEFC94.3050207@alum.mit.edu> Date: Mon, 31 Oct 2011 15:52:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4EAEE023.6010600@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 19:52:55 -0000 Iñaki, On 10/31/11 2:08 PM, Iñaki Baz Castillo wrote: > 2011/10/31 Paul Kyzivat: >> Iñaki, >> >> Thanks for submitting this. Its a good start. I saw a few things that need >> some investigation: >> >> Section 6: >> >> The requirement to use sips for the contact uri if the connection to the >> server is secure via wss will force all other hops to be secured too. So the >> server can only connect to another client that has established a wss >> connection with a sips contact, or to another sip server via a sips URI. >> This ought to be spelled out. (Its violated in an example.) > > First of all let me say that I plan to remove "sips" schema from the > draft (given the ammount of issues with "sips" mechanism). Well, if you remove the use of sips, then all issues related to use of sips will go away. :-) But I got the impression that you wanted use of wss to force use of a secured connection e2e. sips is the only thing we have that comes close to providing that. > However, the remote peer (using SIP over UDP so "sip" scheme) never > contacts a SIP node speaking "sips", but "sip". The proxy adds two > Record-Route, the the UDP peer always contacts the URI in the > Record-Route with "sip" schema and UDP protocol. The intent of sips is that every hop, e2e, is sips over tls. Double R-R doesn't eliminate that requirement. >> The constructed contact address is not globally reachable - it can only be >> reached through the server. And there mention of gruus, which is a solution >> to that problem. How to address this needs further discussion. > > Indeed, for a new revision of the draft I plan to make Outbound > mandatory for WebSocket clients so there is no need for "discovering > the local IP address". OK. If your intent is to require use of outbound then that answers a lot. Then we will have to ensure that it all integrates with outbound. > I also have to add a modification to RFC 3261: > > When a proxy/server receives a request via WebSocket transport, it MAY > choose not to add the ";received" param in the top Via. This is > because WebSocket is supposed to use already existing infrastructure > in which there can be certain number of HTTP or TCP load balancers > between the client and HTTP/WebSocket server, so the server would > write into ;received the IP of the load balancer in front of it. This > would reveal the client the internal HTTP/TCP topology of the server > which could be insecure. > > So adding ;received to Via would be a local policy decision. This seems like a real hack. If there is a problem to deal with here I hope it can be abstracted. >> Section 7: >> >> When the server is trying to route requests, how can it determine which >> addresses correspond to a particular websocket? > > As said above, Outbound should be mandatory for WebSocket client and > their outbound proxies (Outbound EDGE proxies). Of course, there could > be no outbound proxy but a single proxy/registrar (in this case it > must also implement Outbound). > > So for determining which addresses correspond to a particular > websocket the proxy MUST perform RFC 5626 procedures (by inspecting > the token flow in the Route header). Again, clarifying that use of outbound is intended answers many questions. > My current implementation does it and works perfectly. The same as for > TCP/TLS/UDP clients. > > >> This is a form of connection >> reuse, which has been addressed by RFC 5626 (outbound) and RFC 5923. Note >> that there was much effort to make 5923 define connection reuse over TCP, >> but no safe way was found and it was abandoned.) > > If I'm not wrong, we are done with Outbound. Its an RFC, if that is what you mean. I wasn't suggesting it wasn't. Clearly you needed some form of connection reuse here - either outbound or 5923. I was saying that 5923 doesn't work for you. I was guessing you were intending outbound, and now that is clear. >> There needs to be a careful analysis of the security aspects of reusing the >> connection for outbound requests. And then it will likely result in updating >> RFC 5630 (sip-sips) and RFC 3261 regarding sips. > > But using Outbound is enough, am I right? This is, I've coded a strict > implementation of Outbound in my proxy speaking WebSocket and I'm not > aware of security concerns. Again, use of outbound resolves much. >> Section 9.2: >> >> Shows sending to a sips URI using UDP, which isn't permitted. > > But the top Route is "sip", so the destination of the request is a > "sip" URI rather than "sips". Is it still invalid? I need > clarification on this. See above. >> I may have more comments later, but that's all for now. > > Really thanks a lot for your comments. I will address of all them in a > new revision of the draft. You are welcome. Thanks, Paul From ibc@aliax.net Mon Oct 31 12:54:42 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C6C11E81C6 for ; Mon, 31 Oct 2011 12:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTBS3kKrOXfu for ; Mon, 31 Oct 2011 12:54:42 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 695D211E81C8 for ; Mon, 31 Oct 2011 12:54:32 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so6185039vcb.31 for ; Mon, 31 Oct 2011 12:54:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.151.81 with SMTP id b17mr2481244vcw.198.1320090871964; Mon, 31 Oct 2011 12:54:31 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Mon, 31 Oct 2011 12:54:31 -0700 (PDT) In-Reply-To: <509ED151-FEAD-44B3-A9A7-09FFFBB71D35@acmepacket.com> References: <4EAAD0CD.6010506@alum.mit.edu> <4E2EBDE2-9128-4E6E-ACA6-E4671EA23934@acmepacket.com> <2FCEB44F-12ED-4460-987A-E4FC6E4FB48E@acmepacket.com> <509ED151-FEAD-44B3-A9A7-09FFFBB71D35@acmepacket.com> Date: Mon, 31 Oct 2011 20:54:31 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Hadriel Kaplan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 19:54:42 -0000 2011/10/31 Hadriel Kaplan : >> Isn't there an RFC (around 1 April 1988?) detailing encapsulating IP >> packets in HTTP requests/responses as a way to get through restrictive >> firewalls? > > Yup, and I was seriously debating whether to send an email to the IETF-di= scuss malling list suggesting draft-ietf-hybi-thewebsocketprotocol-17 shoul= d actually either officially update or deprecate RFC 3093, when the draft w= as put for IETF Last Call not long ago. =C2=A0But I thought doing so might = backfire on me someday so I chickened out. :( Note that WebSocket is more than just a IP tunnel opened with HTTP. It enforces the way in which data is transferred between client and server by mandating frame masking from client to server, it also defines a message boundadry protocol on top of TCP and a WebSocket subprotocol negotiation during the initial handshake. This is needed in order to avoid that a malicius JavaScript sends raw binary/text data over a TCP connection (imagine you visit a web page and the JS code open a TCP connection with a SMTP server and sends SPAM) :) --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Oct 31 20:57:28 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40EDC11E80FC for ; Mon, 31 Oct 2011 20:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQeDFgYx-hae for ; Mon, 31 Oct 2011 20:57:27 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9C411E80DB for ; Mon, 31 Oct 2011 20:57:27 -0700 (PDT) Received: by vws5 with SMTP id 5so6486253vws.31 for ; Mon, 31 Oct 2011 20:57:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.70.98 with SMTP id l2mr6768364vdu.101.1320119846951; Mon, 31 Oct 2011 20:57:26 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Mon, 31 Oct 2011 20:57:26 -0700 (PDT) In-Reply-To: <4EAEFC94.3050207@alum.mit.edu> References: <4EAEE023.6010600@alum.mit.edu> <4EAEFC94.3050207@alum.mit.edu> Date: Tue, 1 Nov 2011 04:57:26 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 03:57:28 -0000 2011/10/31 Paul Kyzivat : >> First of all let me say that I plan to remove "sips" schema from the >> draft (given the ammount of issues with "sips" mechanism). > > Well, if you remove the use of sips, then all issues related to use of si= ps > will go away. :-) > > But I got the impression that you wanted use of wss to force use of a > secured connection e2e. sips is the only thing we have that comes close t= o > providing that. Ok. So I will leave "sips" schema which in the context of WebSocket transport requires WebSocket over TLS ("wss" schema in the WebSocket URI connection of the client). However, nobody prevents a WS client to establish a WSS connection but use "sip" schema on top of it (as RFC 5630 section-3.1.3 states). >> However, the remote peer (using SIP over UDP so "sip" scheme) never >> contacts a SIP node speaking "sips", but "sip". The proxy adds two >> Record-Route, the the UDP peer always contacts the URI in the >> Record-Route with "sip" schema and UDP protocol. > > The intent of sips is that every hop, e2e, is sips over tls. > Double R-R doesn't eliminate that requirement. Ok. IMHO "sips" is just impossible to work since a proxy adding a "sips" schema must use a domain in the Record-Route, and such domain could resolve to multiple NAPTR/SRV/A/AAAA records, so we loose the pach for in-dialog requests and that's critical when Outbound is being used. However this is another history out of the scope here. > OK. If your intent is to require use of outbound then that answers a lot. > Then we will have to ensure that it all integrates with outbound. Sure :) >> I also have to add a modification to RFC 3261: >> >> When a proxy/server receives a request via WebSocket transport, it MAY >> choose not to add the ";received" param in the top Via. This is >> because WebSocket is supposed to use already existing infrastructure >> in which there can be certain number of HTTP or TCP load balancers >> between the client and HTTP/WebSocket server, so the server would >> write into ;received the IP of the load balancer in front of it. This >> would reveal the client the internal HTTP/TCP topology of the server >> which could be insecure. >> >> So adding ;received to Via would be a local policy decision. > > This seems like a real hack. If there is a problem to deal with here I ho= pe > it can be abstracted. Let's assume that: - A SIP Websocket client is a real client (not a proxy or server). - The spec will require Outbound so ;received and ;rport is 100% useless (even more when the server cannot try the IP in ;received/;rport for sending a response in case the connection is closed since a WebSocket client does not listen for incoming connections). So IMHO it's clear that ;received is useless in SIP over WebSocket, and it can reveal server internal infrastructure to the client. So, what can we do here? IMHO the SIP WebSocket server/proxy should be able not to set the ;received param given the above rationale. Thanks a lot. --=20 I=C3=B1aki Baz Castillo