The changes from the previous version are:

- Requirement section added

- Use-cases and example flows updated, based on work = in 3GPP

The draft does propose a protocol mechanism, but I wo= uld like us to first focus on the REQUIREMENTS, in order to come to an agre= ement on those.

So, I would like to hear whether people think the req= uirements are clear, whether something needs to be modified, whether someth= ing is missing etc.

Thanks!

Christer

--_000_7F2072F1E0DE894DA4B517B93C6A0585194E360227ESESSCMS0356e_-- From christer.holmberg@ericsson.com Thu Jun 9 14:08: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 95C2C11E80FF for ; Thu, 9 Jun 2011 14:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.506 X-Spam-Level: X-Spam-Status: No, score=-7.506 tagged_above=-999 required=5 tests=[AWL=1.092, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqAHPMAU6W6g for ; Thu, 9 Jun 2011 14:08: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 D69C211E80FC for ; Thu, 9 Jun 2011 14:08:13 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-00-4df1363ca18d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3A.45.20773.C3631FD4; Thu, 9 Jun 2011 23:08:12 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 9 Jun 2011 23:08:05 +0200 From: Christer Holmberg To: SIPCORE Chairs , "SIPCORE (Session Initiation Protocol Core) WG" Date: Thu, 9 Jun 2011 23:08:03 +0200 Thread-Topic: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Thread-Index: Acwj4WCkAecOmo7GTteRXYIV9OnhoADAwo8A Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E36022D@ESESSCMS0356.eemea.ericsson.se> References: <4DEC205A.5040503@cisco.com> In-Reply-To: <4DEC205A.5040503@cisco.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_7F2072F1E0DE894DA4B517B93C6A0585194E36022DESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-sipcore-rfc4244bis@tools.ietf.org" , Robert Sparks Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis 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, 09 Jun 2011 21:08:15 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E36022DESESSCMS0356e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Some comments, based on feedback I've got from collegues. 1. Usage of "rc" and "mp" in Contact header field (technical) The document defines the "rc" and "mp" parameters also for the Contact head= er field. However, it is unclear when and how the parameters would be used = in a Contact header field. 2. Tel to Sip transformation: ENUM (technical) Section 5 talks about transformation from Tel to Sip, according section 19.= 6.1 of RFC 3261. However, the transformation can also be the result of an E= NUM DNS lookup. So, maybe some text should be added, indicating that the tr= ansformation can be done based on local configuration (the hostpart of the = new SIP-URI needs to be taken from somewhere), or based on an ENUM DNS look= up. 3. Tel to Sip transformation: History-Info (technical) Related to the previous question, the text doesn't indicate whether the tra= nsformation from Tel to Sip should be recorded in an History-Info header fi= eld. The Request-URI is, after all, changed. 4. Home proxy (editorial) The draft mentions "home proxy", but there is no reference or definition fo= r it. I guess it should be "registrar", or something. 5. Out-of-dialog request (editorial) Section 5 talks about "request not associated with an early or established = dialog", while section 6.1 talks about "new or out-of-dialog request". In b= oth cases the text refers to the request that can carry History-Info, so th= e wording should be consistance. For example "out-of-dialog requests or ini= tial requests for a dialog". 6. Appearence (editorial) Section 5 says in which message types History-Info "can appear". It would b= e better to say for which message types the document/specification defines = the usage of History-Info. 7. Misc (editorial) There are, throughout the document, some inconsistance between usage of "he= ader" vs "header field", "this document" vs "this specification", the usage= of capital letters for requests and SIP entity names etc, but I guess that= can be taken care of by the authors without a list of every occurance here= . Regards, Christer ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 6. kes=E4kuuta 2011 3:34 To: SIPCORE (Session Initiation Protocol Core) WG Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org; SIPCORE Chairs; Robert Sp= arks Subject: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis [as co-chair] The current editor of draft-ietf-sipcore-rfc4244bis believes that the docum= ent has no remaining technical issues, and is ready for evaluation. Today, = we are starting a two-week working group last call period. This last call p= eriod ends on Sunday, June 19. The latest version of the document can be retrieved here: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis Any comments on the document should be sent to the SIPCORE mailing list. Thanks, Paul --_000_7F2072F1E0DE894DA4B517B93C6A0585194E36022DESESSCMS0356e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

Some comments, based on feedback I've got from=20 collegues.

1. Usage of "rc" and "mp" in Contact header fiel= d=20 (technical)

The document defines the "rc" and "mp" parameter= s also=20 for the Contact header field. However, it is unclear when and how the= =20 parameters would be used in a Contact header field.

2. Tel to Sip transformation: ENUM=20 (technical)

Section 5 talks about transformation from Tel to= Sip,=20 according section 19.6.1 of RFC 3261. However, the transformation can also = be=20 the result of an ENUM DNS lookup. So, maybe some text should be added,=20 indicating that the transformation can be done based on local configuration= (the=20 hostpart of the new SIP-URI needs to be taken from somewhere), or based on = an=20 ENUM DNS lookup.

3. Tel to Sip transformation: History-Info=20 (technical)

Related to the previous question, the text doesn't= indicate=20 whether the transformation from Tel to Sip should be recorded in an History= -Info=20 header field. The Request-URI is, after all, changed.

4. Home proxy (editorial)

The draft mentions "home proxy", but there is no r= eference=20 or definition for it. I guess it should be "registrar", or=20 something.

5. Out-of-dialog request=20 (editorial)

Section 5 talks about "request not associated wi= th an=20 early or established dialog", while section 6.1 talks about "new or=20 out-of-dialog request". In both cases the text refers to the request that c= an=20 carry History-Info, so the wording should be consistance. For example=20 "out-of-dialog requests or initial requests for a dialog".

6. Appearence (editorial)

Section 5 says in which message types Histo= ry-Info=20 "can appear". It would be better to say for which message types the=20 document/specification defines the usage of History-Info.

7. Misc (editorial)

There are, throughout the document, some inco= nsistance=20 between usage of "header" vs "header field", "this document" vs "this= =20 specification", the usage of capital letters for requests and SIP entity na= mes=20 etc, but I guess that can be taken care of by the authors without = ;a=20 list of every occurance here.

Regards,

Christer

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul=20 Kyzivat
Sent: 6. kes=E4kuuta 2011 3:34
To: SIPCORE (S= ession=20 Initiation Protocol Core) WG
Cc:=20 draft-ietf-sipcore-rfc4244bis@tools.ietf.org; SIPCORE Chairs; Robert=20 Sparks
Subject: [sipcore] WGLC:=20 draft-ietf-sipcore-rfc4244bis

[as co-chair]

The current editor of=20 draft-ietf-sipcore-rfc4244bis believes that the document has no remaining= =20 technical issues, and is ready for evaluation. Today, we are starting a=20 two-week working group last call period. This last call period ends on Su= nday,=20 June 19.

The latest version of the document can be retrieved=20 here:

http://= tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis

Any=20 comments on the document should be sent to the SIPCORE mailing=20 list.

Thanks,
Paul= =20 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E36022DESESSCMS0356e_-- From rjsparks@nostrum.com Mon Jun 13 15:09: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 339C79E800D for ; Mon, 13 Jun 2011 15:09:57 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6yahBtFNsMJ for ; Mon, 13 Jun 2011 15:09:56 -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 2B5B49E800E for ; Mon, 13 Jun 2011 15:09:55 -0700 (PDT) Received: from dn3-177.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 p5DM9qgs054067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 13 Jun 2011 17:09:52 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jun 2011 17:09:52 -0500 Message-Id: To: "SIPCORE (Session Initiation Protocol Core) WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] An alternate to the requirements section in proxy-feature-02 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, 13 Jun 2011 22:09:57 -0000 (As an individual contributor) I appreciate version -02 of this document adding a requirements section.=20= I believe it will be important to get a common understanding of what's = needed in order to be able to understand the impact of the proposed mechanism = and whatever it may evolve into. So far, I'm still having a hard time teasing out the requirements from = the text.=20 Here's a stab at a mechanism free statement of the requirements that I = can infer=20 from the proposed mechanism, along with several questions. Please help = clarify=20 the requirements where my inferences are wrong. Please also point out = where=20 there is a requirement these don't cover. 1) There is a requirement for a proxy to be able to=20 indicate support for a capability to other proxies=20 in the path of a dialog forming transaction and to the two endpoints of that transaction. 2) There is a requirement for a proxy to be able to indicate support for a capability to other proxies in the path of a REGISTER transaction, and to both the registering endpoint and the registrar. 3) There is a requirement for a proxy to be able to indicate that the support for the capability applies only to one of the endpoints establishing a dialog. Question 1: Is there a requirement for a proxy to be able to indicate that support for a capability applies only to the other proxies between it and one of the endpoints? Question 2: Is there a requirement for a proxy between Alice and Bob to hide that it's supporting a capability for Alice from Bob, or is the requirement only that Bob be able to tell this statement was not for him? 4) There is a requirement that a proxy indicating support for a capability in a dialog forming transaction will support that capability for the duration of all dialogs the transaction may create.=20 5) There is a requirement that other proxies be able to use the indication from 1) or 2) to affect routing decisions and other proxy handling of the request (such as choosing which capabilities these other proxies may choose to indicate as part of this transaction) 6) There is no requirement that the capabilities supported at any proxies involved in a dialog be able to change in the course of the dialog.=20 7) There is no requirement to negotiate support for a=20 capability. (For example, there is no requirement for there to be a way for an initiating endpoint, or a proxy along the path=20 to indicate "make this request fail unless something along the path=20= supports X") Question 3: It appears that the capability indication is only used when processing the initial request, and appears in subsequent in-dialog signalling in the current proposed mechanism because that's what 3261 requires. If the mechanism evolved such that the indication appeared only in the dialog establishing transaction, and not in any subsequent in-dialog messages, what would break? -------- Again, I'm sure I've missed some important requirements. What are they? The currently proposed mechanism appears to run against the advice in = RFC5897, particularly Do What I Say vs Do What I Mean. It appears to provide a declarative service identifier (such as g.3gpp.srvcc-alerting), and it's = not clear yet what an endpoint or intermediary that doesn't know what the identifier means should or shouldn't do. Is it the intent to require any element that doesn't recognize a value to behave exactly as it would if = there were no value present at all? If so, what keeps us from having the same service/feature/capability defined in separate namespaces resulting in non-interoperable islands? It's also easy to infer from the examples (like 1.3) that=20 there is a requirement for a proxy to say much more than "I support=20 capability X". In at least one case, it appears to be saying=20 "I am doing X - and other X-capable things MUST NOT do X". It would be good to avoid the confusion associated with when the presence of an option tag in Supported/Required means that the extentions associated with the tag is actually being used. Would it be acceptable to say that the presence of a proxy capability indication says nothing about whether the capability is being used?=20 From christer.holmberg@ericsson.com Mon Jun 13 22:38: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 1DEFE11E82BC for ; Mon, 13 Jun 2011 22:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrFhfA80j0QS for ; Mon, 13 Jun 2011 22:38:19 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id CDF9911E82B9 for ; Mon, 13 Jun 2011 22:38:18 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-20-4df6f3c963e3 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 98.12.20773.9C3F6FD4; Tue, 14 Jun 2011 07:38:17 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 14 Jun 2011 07:38:16 +0200 From: Christer Holmberg To: Robert Sparks , "SIPCORE (Session Initiation Protocol Core) WG" Date: Tue, 14 Jun 2011 07:38:15 +0200 Thread-Topic: [sipcore] An alternate to the requirements section in proxy-feature-02 Thread-Index: AcwqFqYTQEAn1z7mQXegva76OlfNlAAOpxLQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3A0EF4@ESESSCMS0356.eemea.ericsson.se> 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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] An alternate to the requirements section in proxy-feature-02 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, 14 Jun 2011 05:38:20 -0000 Hi Robert,=20 >(As an individual contributor) >=20 >I appreciate version -02 of this document adding a=20 >requirements section.=20 >=20 >I believe it will be important to get a common understanding=20 >of what's needed in order to be able to understand the impact=20 >of the proposed mechanism and whatever it may evolve into. >=20 >So far, I'm still having a hard time teasing out the=20 >requirements from the text.=20 >=20 >Here's a stab at a mechanism free statement of the=20 >requirements that I can infer from the proposed mechanism,=20 >along with several questions. Please help clarify the=20 >requirements where my inferences are wrong. Please also point=20 >out where there is a requirement these don't cover. >=20 >1) There is a requirement for a proxy to be able to=20 > indicate support for a capability to other proxies=20 > in the path of a dialog forming transaction and to > the two endpoints of that transaction. Correct. =20 >2) There is a requirement for a proxy to be able to > indicate support for a capability to other proxies > in the path of a REGISTER transaction, and to both > the registering endpoint and the registrar. Correct. >3) There is a requirement for a proxy to be able to > indicate that the support for the capability applies > only to one of the endpoints establishing a dialog. Partly correct. The requirement talks about only to one DIRECTION. That inc= ludes both one of the endpoints, but also possible proxies in between. >Question 1: Is there a requirement for a proxy to be able > to indicate that support for a capability applies > only to the other proxies between it and one of the > endpoints? Currently there is no such requirement. But, having said that, it's probably something we need to add text about in= the draft. >Question 2: Is there a requirement for a proxy between > Alice and Bob to hide that it's supporting a capability > for Alice from Bob, or is the requirement only that > Bob be able to tell this statement was not for him? Currently there is no explicit requirement to be able to hide the support.= =20 But, when we start to discuss how to implement the direction requirement, t= hat could of course be one possible solution. >4) There is a requirement that a proxy indicating support > for a capability in a dialog forming transaction will > support that capability for the duration of all dialogs > the transaction may create.=20 The intention is that whatever applies to a UA also applies to a proxy. See more on this in my reply to 6). =20 >5) There is a requirement that other proxies be able to > use the indication from 1) or 2) to affect routing > decisions and other proxy handling of the request > (such as choosing which capabilities these other proxies > may choose to indicate as part of this transaction) There is no explicit requirement for that. But, proxies can do routing decission etc based on whatever policies and me= ssage information in my opinion. >6) There is no requirement that the capabilities supported > at any proxies involved in a dialog be able to change > in the course of the dialog.=20 Again, the intention is that whatever applies to a UA also applies to a pro= xy. But, having said that, I am not sure it is clear even for UAs. For example,= if a UA indicates support of feature x in the initial INVITE, but does not= indicate the support in a re-INVITE/UPDATE/whatever-target-update-request,= does it mean that the UA does not support the feature anymore? So, maybe each feature definition (no matter if the feature tag is used by,= or defined for, a UA or a proxy) should explictily specify the scope, when= used as part of a dialog forming transaction and/or a registration transac= tion. > 7) There is no requirement to negotiate support for a=20 > capability. (For example, there is no requirement for there > to be a way for an initiating endpoint, or a proxy along the path=20 > to indicate "make this request fail unless something along=20 > the path supports X") Correct. For that you would need to define an option-tag, to be used with R= equire/Proxy-Require. > Question 3: It appears that the capability indication is > only used when processing the initial request, and appears > in subsequent in-dialog signalling in the current proposed > mechanism because that's what 3261 requires. If the mechanism > evolved such that the indication appeared only in the dialog > establishing transaction, and not in any subsequent in-dialog > messages, what would break? =20 >-------- >=20 >Again, I'm sure I've missed some important requirements. >What are they? When reading your text, I am not sure we need additional requirements. Howe= ver, it does seem that we DO need more clarfication text on certain topics.= The intention is not to change the "meaning" of feature tags etc, simply a= llow them to also be included by proxies (in addition to UAs), and the only= proxy specific issue (which I have identified so far) is that we need to d= eal with the direction issue - for which we do have a requirement. >The currently proposed mechanism appears to run against the=20 >advice in RFC5897, particularly Do What I Say vs Do What I=20 >Mean. It appears to provide a declarative service identifier=20 >(such as g.3gpp.srvcc-alerting), and it's not clear yet what=20 >an endpoint or intermediary that doesn't know what the=20 >identifier means should or shouldn't do. Is it the intent to=20 >require any element that doesn't recognize a value to behave=20 >exactly as it would if there were no value present at all? If=20 >so, what keeps us from having the same=20 >service/feature/capability defined in separate namespaces=20 >resulting in non-interoperable islands? The intention is to only indicate SUPPORT of a feature.=20 It MUST NOT be assumed that other entities understand the feature tag (agai= n, for that you would need an option-tag in a Require/Proxy-Require header = field). If entities don't understand the feature that they should just go o= n as if the feature tag wasn't there. Again, that is the same as when a UA indicates support of a feature. >It's also easy to infer from the examples (like 1.3) that=20 >there is a requirement for a proxy to say much more than "I=20 >support capability X". In at least one case, it appears to be=20 >saying "I am doing X - and other X-capable things MUST NOT do=20 >X". It would be good to avoid the confusion associated with=20 >when the presence of an option tag in Supported/Required=20 >means that the extentions associated with the tag is actually=20 >being used. Would it be acceptable to say that the presence=20 >of a proxy capability indication says nothing about whether=20 >the capability is being used?=20 I will take a closer look at the examples and 3GPP use-cases. I have tried = to make it very clear in 3GPP that the mechanism only provides a way to say= : "I CAN do this" ...but not: "I AM doing this" Thank You very much for the excellent and productive feedback! :) Regards, Christer From christer.holmberg@ericsson.com Mon Jun 13 22: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 DA63D22800F for ; Mon, 13 Jun 2011 22:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlyPlegxKRZp for ; Mon, 13 Jun 2011 22:44:50 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC9522800D for ; Mon, 13 Jun 2011 22:44:49 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-b4-4df6f5502e20 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4F.65.20773.055F6FD4; Tue, 14 Jun 2011 07:44:49 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 14 Jun 2011 07:44:47 +0200 From: Christer Holmberg To: Robert Sparks , "SIPCORE (Session Initiation Protocol Core) WG" Date: Tue, 14 Jun 2011 07:44:46 +0200 Thread-Topic: [sipcore] An alternate to the requirements section in proxy-feature-02 - Question 3 Thread-Index: AcwqFqYTQEAn1z7mQXegva76OlfNlAAPxOSA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3A0EF9@ESESSCMS0356.eemea.ericsson.se> 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 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] An alternate to the requirements section in proxy-feature-02 - Question 3 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, 14 Jun 2011 05:44:51 -0000 Hi Robert, In my previous reply, I forgot to comment on your question 3)=20 >Question 3: It appears that the capability indication is > only used when processing the initial request, and appears > in subsequent in-dialog signalling in the current proposed > mechanism because that's what 3261 requires. If the mechanism > evolved such that the indication appeared only in the dialog > establishing transaction, and not in any subsequent in-dialog > messages, what would break? I am not sure whether any of the existing use-cases would break, but I'd ne= ed to look into it. But, again, the intention is that what applies to UAs should also apply to = proxies. Regards, Christer From pkyzivat@cisco.com Tue Jun 14 06: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 87B9611E8141 for ; Tue, 14 Jun 2011 06:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.391 X-Spam-Level: X-Spam-Status: No, score=-110.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eh4E9aUHtpIA for ; Tue, 14 Jun 2011 06:09:52 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id D0B9B11E813B for ; Tue, 14 Jun 2011 06:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=9440; q=dns/txt; s=iport; t=1308056971; x=1309266571; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=q4hM/ax7NdW98ltRqvA06f52xKcaA9E5nMJG6y5hzAI=; b=hptQOLX0+ExnD40vUhhHkoiWxhlMMUzfGD0tvbeO27YCuY4o59kpYUNi 5zbWP/96kYJCJgyMzByjBVYjow6RM4Je2wYcuf58+mvDexX9zNuQE1OIX FXyNpAJZ0iyMFEJ6UHuaAZSUWIyzx3NK+kKG7TVHpeBZ7ADeX/9KUZ3e+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAZd902rRDoI/2dsb2JhbABSpkF3iHOiFJ5HhiQEkUiEV4ss X-IronPort-AV: E=Sophos;i="4.65,364,1304294400"; d="scan'208";a="336630950" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 14 Jun 2011 13:09:31 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5ED9UJq032206 for ; Tue, 14 Jun 2011 13:09:30 GMT Message-ID: <4DF75D8A.1010801@cisco.com> Date: Tue, 14 Jun 2011 09:09:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: sipcore@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A0EF4@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3A0EF4@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] An alternate to the requirements section in proxy-feature-02 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, 14 Jun 2011 13:09:54 -0000 (as individual) Comments inline. On 6/14/2011 1:38 AM, Christer Holmberg wrote: > > Hi Robert, > >> (As an individual contributor) >> >> I appreciate version -02 of this document adding a >> requirements section. >> >> I believe it will be important to get a common understanding >> of what's needed in order to be able to understand the impact >> of the proposed mechanism and whatever it may evolve into. >> >> So far, I'm still having a hard time teasing out the >> requirements from the text. >> >> Here's a stab at a mechanism free statement of the >> requirements that I can infer from the proposed mechanism, >> along with several questions. Please help clarify the >> requirements where my inferences are wrong. Please also point >> out where there is a requirement these don't cover. >> >> 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. > > Correct. > >> 2) There is a requirement for a proxy to be able to >> indicate support for a capability to other proxies >> in the path of a REGISTER transaction, and to both >> the registering endpoint and the registrar. > > Correct. > >> 3) There is a requirement for a proxy to be able to >> indicate that the support for the capability applies >> only to one of the endpoints establishing a dialog. > > Partly correct. The requirement talks about only to one DIRECTION. That includes both one of the endpoints, but also possible proxies in between. > > >> Question 1: Is there a requirement for a proxy to be able >> to indicate that support for a capability applies >> only to the other proxies between it and one of the >> endpoints? > > Currently there is no such requirement. > > But, having said that, it's probably something we need to add text about in the draft. > > >> Question 2: Is there a requirement for a proxy between >> Alice and Bob to hide that it's supporting a capability >> for Alice from Bob, or is the requirement only that >> Bob be able to tell this statement was not for him? > > Currently there is no explicit requirement to be able to hide the support. > > But, when we start to discuss how to implement the direction requirement, that could of course be one possible solution. That seems backward. Either there is a requirement, or not. Ideally all the requirements can be identified *before* discussing the mechanism. Of course its not unheard of to discover missing requirements while discussing mechanism, but we probably should not be expecting that to happen. The resulting mechanism may of course have properties not discussed in the requirements. But they only have bearing if there are competing mechanisms that meet the requirements. >> 4) There is a requirement that a proxy indicating support >> for a capability in a dialog forming transaction will >> support that capability for the duration of all dialogs >> the transaction may create. > > The intention is that whatever applies to a UA also applies to a proxy. > > See more on this in my reply to 6). *If* we were talking about mechanism now, and in particular about extending an existing mechanism, then architectural consistency might be an important issue. (E.g. the mechanism should behave the same way when applied to proxies as it does when applied to UAs.) But we are talking about *requirements* now. So there either is such a requirement, or not. The presence or absence of the requirement can affect the mechanism choice. So, is there such a requirement, or not? >> 5) There is a requirement that other proxies be able to >> use the indication from 1) or 2) to affect routing >> decisions and other proxy handling of the request >> (such as choosing which capabilities these other proxies >> may choose to indicate as part of this transaction) > > There is no explicit requirement for that. > > But, proxies can do routing decission etc based on whatever policies and message information in my opinion. Again, either there is a requirement, or not. There *is* precedent for mechanisms that *could* be used for routing but that explicitly control the right of proxies to do so. So I think it is a fair question to ask. >> 6) There is no requirement that the capabilities supported >> at any proxies involved in a dialog be able to change >> in the course of the dialog. > > Again, the intention is that whatever applies to a UA also applies to a proxy. > But, having said that, I am not sure it is clear even for UAs. For example, if a UA indicates support of feature x in the initial INVITE, but does not indicate the support in a re-INVITE/UPDATE/whatever-target-update-request, does it mean that the UA does not support the feature anymore? > > So, maybe each feature definition (no matter if the feature tag is used by, or defined for, a UA or a proxy) should explictily specify the scope, when used as part of a dialog forming transaction and/or a registration transaction. As time goes on we learn that much of what was defined in the past was underspecified. We are doing our best to learn from those mistakes and be more precise going forward. So again, rather than making assumptions about the mechanism, can we just decide if this is a requirement or not? And if the requirement is that the duration of guarantee vary from capability to capability, then lets call it out that way. >> 7) There is no requirement to negotiate support for a >> capability. (For example, there is no requirement for there >> to be a way for an initiating endpoint, or a proxy along the path >> to indicate "make this request fail unless something along >> the path supports X") > > Correct. For that you would need to define an option-tag, to be used with Require/Proxy-Require. > > >> Question 3: It appears that the capability indication is >> only used when processing the initial request, and appears >> in subsequent in-dialog signalling in the current proposed >> mechanism because that's what 3261 requires. If the mechanism >> evolved such that the indication appeared only in the dialog >> establishing transaction, and not in any subsequent in-dialog >> messages, what would break? > > > >> -------- >> >> Again, I'm sure I've missed some important requirements. >> What are they? > > When reading your text, I am not sure we need additional requirements. However, it does seem that we DO need more clarfication text on certain topics. The intention is not to change the "meaning" of feature tags etc, simply allow them to also be included by proxies (in addition to UAs), and the only proxy specific issue (which I have identified so far) is that we need to deal with the direction issue - for which we do have a requirement. Again, lets please set aside assumptions about the mechanism when discussing requirements. >> The currently proposed mechanism appears to run against the >> advice in RFC5897, particularly Do What I Say vs Do What I >> Mean. It appears to provide a declarative service identifier >> (such as g.3gpp.srvcc-alerting), and it's not clear yet what >> an endpoint or intermediary that doesn't know what the >> identifier means should or shouldn't do. Is it the intent to >> require any element that doesn't recognize a value to behave >> exactly as it would if there were no value present at all? If >> so, what keeps us from having the same >> service/feature/capability defined in separate namespaces >> resulting in non-interoperable islands? > > The intention is to only indicate SUPPORT of a feature. The point remains. Indicating support for something undefined has exactly the same issues as asking to do something undefined. Thanks, Paul > It MUST NOT be assumed that other entities understand the feature tag (again, for that you would need an option-tag in a Require/Proxy-Require header field). If entities don't understand the feature that they should just go on as if the feature tag wasn't there. > > Again, that is the same as when a UA indicates support of a feature. > > > >> It's also easy to infer from the examples (like 1.3) that >> there is a requirement for a proxy to say much more than "I >> support capability X". In at least one case, it appears to be >> saying "I am doing X - and other X-capable things MUST NOT do >> X". It would be good to avoid the confusion associated with >> when the presence of an option tag in Supported/Required >> means that the extentions associated with the tag is actually >> being used. Would it be acceptable to say that the presence >> of a proxy capability indication says nothing about whether >> the capability is being used? > > I will take a closer look at the examples and 3GPP use-cases. I have tried to make it very clear in 3GPP that the mechanism only provides a way to say: > > "I CAN do this" > > ...but not: > > "I AM doing this" > > Thank You very much for the excellent and productive feedback! :) > > Regards, > > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Tue Jun 14 07:08: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 545449E8006 for ; Tue, 14 Jun 2011 07:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gDSuEwz5l-B for ; Tue, 14 Jun 2011 07:08: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 13F059E8005 for ; Tue, 14 Jun 2011 07:08:08 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-55-4df76b48fbf2 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 4C.2A.09774.84B67FD4; Tue, 14 Jun 2011 16:08:08 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 14 Jun 2011 16:08:06 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Date: Tue, 14 Jun 2011 16:08:05 +0200 Thread-Topic: [sipcore] An alternate to the requirements section in proxy-feature-02 Thread-Index: AcwqlH7CsSM/BA54R2yGrVoi+CBG7AAAX37Q Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3A1451@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E3A0EF4@ESESSCMS0356.eemea.ericsson.se> <4DF75D8A.1010801@cisco.com> In-Reply-To: <4DF75D8A.1010801@cisco.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] An alternate to the requirements section in proxy-feature-02 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, 14 Jun 2011 14:08:10 -0000 Hi Paul,=20 >>> Question 2: Is there a requirement for a proxy between >>> Alice and Bob to hide that it's supporting a capability >>> for Alice from Bob, or is the requirement only that >>> Bob be able to tell this statement was not for him? >> >>Currently there is no explicit requirement to be able to=20 >>hide the support. >> >>But, when we start to discuss how to implement the=20 >>direction requirement, that could of course be one possible solution. >=20 >That seems backward. >Either there is a requirement, or not. >Ideally all the requirements can be identified *before*=20 >discussing the mechanism. Of course its not unheard of to=20 >discover missing requirements while discussing mechanism, but=20 >we probably should not be expecting that to happen. There is no requirement for hiding as such. There is a requirement for the direction, so if we later choose to use hidi= ng=20 in order to implement that requirement, I don't think it would be adding a new requirement. It would be a way to implement the existing direction=20 requirement. ------------- >>> 4) There is a requirement that a proxy indicating support >>> for a capability in a dialog forming transaction will >>> support that capability for the duration of all dialogs >>> the transaction may create. >> >>The intention is that whatever applies to a UA also applies=20 >>to a proxy. >> >>See more on this in my reply to 6). >=20 >*If* we were talking about mechanism now, and in particular=20 >about extending an existing mechanism, then architectural=20 >consistency might be an important issue. (E.g. the mechanism=20 >should behave the same way when applied to proxies as it does=20 >when applied to UAs.) >=20 >But we are talking about *requirements* now. So there either=20 >is such a requirement, or not. The presence or absence of the=20 >requirement can affect the mechanism choice. I agree. I also think I read Robert's question wrong. I read that he asked whether the indicated feature only applies to the current dialog, or also to future dialogs, established as part of completely separate transactions= =20 and session establishements. My suggestion would be to mandate the feature specification to indicate suc= h scope, and provide the alternatives. "The feature specification MUST define whether the feature support indicat= ion applies to: 1. The current dialog; 2. Any dialog created by the current transaction; or 3. Any dialog created outside the current transaction." However, if the feature indication is inserted by a proxy in an initial req= uest for a dialog, there is yet no dialog, so in that case I guess the prox= y would not be able to include the support until it receives the response w= ith a To tag. ------------- >>> 5) There is a requirement that other proxies be able to >>> use the indication from 1) or 2) to affect routing >>> decisions and other proxy handling of the request >>> (such as choosing which capabilities these other proxies >>> may choose to indicate as part of this transaction) >> >> There is no explicit requirement for that. >> >> But, proxies can do routing decission etc based on whatever=20 >> policies and message information in my opinion. >=20 >Again, either there is a requirement, or not. >=20 >There *is* precedent for mechanisms that *could* be used for=20 >routing but that explicitly control the right of proxies to do so. >=20 >So I think it is a fair question to ask. Of course. But, the intention is not to specify a new mechanim for making=20 routing decissions. But, we could of course say: "Proxies MUST be able to make routing decissions based on a feature=20 support indication." ------------- >>> 6) There is no requirement that the capabilities supported >>> at any proxies involved in a dialog be able to change >>> in the course of the dialog. >> >> Again, the intention is that whatever applies to a UA also=20 >> applies to a proxy. >=20 >> But, having said that, I am not sure it is clear even for=20 >> UAs. For example, if a UA indicates support of feature x in=20 >> the initial INVITE, but does not indicate the support in a=20 >> re-INVITE/UPDATE/whatever-target-update-request, does it mean=20 >> that the UA does not support the feature anymore? >> >> So, maybe each feature definition (no matter if the feature=20 >> tag is used by, or defined for, a UA or a proxy) should=20 >> explictily specify the scope, when used as part of a dialog=20 >> forming transaction and/or a registration transaction. >=20 > As time goes on we learn that much of what was defined in the=20 > past was underspecified. We are doing our best to learn from=20 > those mistakes and be more precise going forward. >=20 > So again, rather than making assumptions about the mechanism,=20 > can we just decide if this is a requirement or not? And if=20 > the requirement is that the duration of guarantee vary from=20 > capability to capability, then lets call it out that way. I see 3 alternatives here: 1. We specify that support for a feature can be changed during a dialog; or 2. We specify that support for a feature can never be changed during a dial= og; or 3. We specify that the feature specification must define whether support fo= r a feature can be changed during a dialog or not. I would vote for alternative 1, so the requirement text would say: "It MUST be possible for a proxy, during a dialog, to change the indicated= support for a feature." ----------- >>> Again, I'm sure I've missed some important requirements. >>> What are they? >> >> When reading your text, I am not sure we need additional=20 >> requirements. However, it does seem that we DO need more=20 >> clarfication text on certain topics. The intention is not to=20 >> change the "meaning" of feature tags etc, simply allow them=20 >> to also be included by proxies (in addition to UAs), and the=20 >> only proxy specific issue (which I have identified so far) is=20 >> that we need to deal with the direction issue - for which we=20 >> do have a requirement. >=20 > Again, lets please set aside assumptions about the mechanism=20 > when discussing requirements. The intention is not to make assumptions about the mechanism, but I guess i= t's my fault when I talk about feture tags :) So, please let me re-phrase: The intention is not to change the "meaning" of existing feature support=20 indications, simply allow feature support indications to also be included=20 by proxies (in addition to UAs) Maybe it could be covered by the following requirement: "A feature support indication MUST only be used to indicate support of a feature, and MUST NOT be used to indicate whether procedures associated with the features have been applied or not." --------- >>> The currently proposed mechanism appears to run against=20 >>> the advice in=20 >>> RFC5897, particularly Do What I Say vs Do What I Mean. It=20 >>> appears to provide a declarative service identifier (such as=20 >>> g.3gpp.srvcc-alerting), and it's not clear yet what an endpoint or=20 >>> intermediary that doesn't know what the identifier means should or=20 >>> shouldn't do. Is it the intent to require any element that doesn't=20 >>> recognize a value to behave exactly as it would if there were no=20 >>> value present at all? If so, what keeps us from having the same=20 >>> service/feature/capability defined in separate namespaces=20 >>> resulting in non-interoperable islands? >> >> The intention is to only indicate SUPPORT of a feature. >=20 >The point remains. Indicating support for something undefined=20 >has exactly the same issues as asking to do something undefined. I guess we could add the following requirement: "If a SIP entity receives a feature support indication that it does not=20 understand, it MUST act as if it hadn't received the feature support Indication." Regards, Christer From HKaplan@acmepacket.com Wed Jun 15 12:51:11 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 1796811E8146 for ; Wed, 15 Jun 2011 12:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jZo+OXtJ6il for ; Wed, 15 Jun 2011 12:51:10 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7A53411E810D for ; Wed, 15 Jun 2011 12:51:10 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 15 Jun 2011 15:51:07 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Wed, 15 Jun 2011 15:51:07 -0400 From: Hadriel Kaplan To: "SIPCORE (Session Initiation Protocol Core) WG" Date: Wed, 15 Jun 2011 15:51:06 -0400 Thread-Topic: 4244bis-05: editorial comments Thread-Index: AcwrlZFYNMWxH5CET6qjnuBLauwTmw== Message-ID: References: <4DEC205A.5040503@cisco.com> In-Reply-To: <4DEC205A.5040503@cisco.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: AAAAAQAAAUA= Cc: "draft-ietf-sipcore-rfc4244bis@tools.ietf.org" Subject: [sipcore] 4244bis-05: editorial comments 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, 15 Jun 2011 19:51:11 -0000 Following are editorial comments on 4244bis-05 in WGLC... 1) Page 8, section 5 first sentence: "REFER and OPTIONS, PUBLISH and SUBSCR= IBE, etc." get rid of the first "and". 2) Page 8, section 5 first bullet: "A mandatory parameter for...", change "= parameter" to "field", since hi-targeted-to-uri is a header field not a par= ameter. 3) Page 13, Figure 1 caption isn't on the same page as the figure itself. = There's an extra whitespace line below the 'Proxy Cancels INVITE' double-ar= row in the drawing which can be remove so that the caption fits on the same= page as the figure. 4) Page 16, Section 9.3, end of section: "(e.g., 1.2 and 1.4 could but pres= ent..." should be "...could be present...". -hadriel From HKaplan@acmepacket.com Wed Jun 15 12:52: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 0229211E8146 for ; Wed, 15 Jun 2011 12:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNKMrbpWouX1 for ; Wed, 15 Jun 2011 12:52:23 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6C80011E810D for ; Wed, 15 Jun 2011 12:52:23 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 15 Jun 2011 15:52:22 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Wed, 15 Jun 2011 15:52:22 -0400 From: Hadriel Kaplan To: "sipcore@ietf.org WG" Date: Wed, 15 Jun 2011 15:52:21 -0400 Thread-Topic: 4244bis-05: the infamous "rc" param Thread-Index: Acwrlb3AJW9ERtTMRXGy37W4MVjcRg== Message-ID: <7A463F33-4115-4E9D-8D1C-C8F49BA9CFDD@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: AAAAAgAAAUAAAAFV Cc: "draft-ietf-sipcore-rfc4244bis@tools.ietf.org" Subject: [sipcore] 4244bis-05: the infamous "rc" param 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, 15 Jun 2011 19:52:24 -0000 Howdy, I still have concerns regarding the "rc" param in this draft. Right now, t= he "rc" is only added for request-uri retargeting due to AoR-to-contact res= olution, populated by a SIP Registrar from a REGISTER. That's it. So "rc"= is not added due to static/provisioned Aor-to-contact mappings, for exampl= e. Nor is it added due to ENUM resolution. Nor, apparently, if the Proxy = doing the routing doesn't know how the database's entry was populated. So... why does it matter how the abstract location database got populated? = Example applications in this draft, as well as in rfc4244bis-callflows, a= pparently rely on the existence of an "rc" param to perform their logic. A= faict, however, it's NOT the case that they actually care whether it was du= e to a REGISTER or not. They only care about finding the first or last rel= evant URI they understand. For example: in a sip trunking context, a la Martini-GIN, request routing t= o GIN-PBX bulk-registered contacts would get the "rc". But request routing= to PBX's UAs using 3263 or static provisioning would not. Should the appl= ication service logic or behavior be different for these different ways of = deploying SIP trunks? -hadriel From HKaplan@acmepacket.com Wed Jun 15 13:15: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 3176B9E8026 for ; Wed, 15 Jun 2011 13:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzx-b8H0fMtJ for ; Wed, 15 Jun 2011 13:15:29 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF9E9E800F for ; Wed, 15 Jun 2011 13:15:29 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 15 Jun 2011 16:15:28 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Wed, 15 Jun 2011 16:15:28 -0400 From: Hadriel Kaplan To: "sipcore@ietf.org WG" Date: Wed, 15 Jun 2011 16:15:27 -0400 Thread-Topic: 4244bis-05: additional technical comments Thread-Index: AcwrmPf5m+md7tDbQPehEG90d3slFA== Message-ID: <3B2A8F8E-4255-4156-B882-BF68F4046F3D@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: AAAAAQAAAUA= Cc: "draft-ietf-sipcore-rfc4244bis@tools.ietf.org" Subject: [sipcore] 4244bis-05: additional technical comments 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, 15 Jun 2011 20:15:30 -0000 Hi, some more technical comments: 1) Section 10.3, page 19, says: In the case that a SIP entity (intermediary or UAS) adds an hi-entry on behalf of the previous hop, the hi-index MUST be set to 1. Taken literally, this means when a request already marked with H-I entries = happens to cross a legacy non-HI system, the next downstream element will a= dd an additional H-I entry starting at 1 again. Is that intentional/on-pur= pose?? At first I thought this was just an editorial mistake, but section = 11, page 22, says : Gaps are possible if the request is forwarded through intermediaries that do not support the History-info header field and are reflected by the existence of multiple hi-entries with an index of "1". =20 So a single SIP request can actually have multiple H-I trees with multiple = root indexes of 1? Wouldn't this make UAS logic code more complicated, bec= ause now the "mp=3DX" and "rc=3DX" index values are relative "X" values, sc= oped to within their particular tree, as opposed to being an absolute numbe= r for the whole H-I list? 2) Section 9.4, page 16 says: When sending a response other than a 100, a SIP entity MUST include all the cached hi-entries in the response, subject to the privacy consideration in Section 10.1.2 with the following exception: If the received request contained no hi-entries and there is no "histinfo" option tag in the Supported header field, the SIP entity MUST NOT include hi-entries in the response. Note the "If the received request contained no hi-entries and...". I don't= know what having H-I entries has to do with it. We have an option-tag for= this purpose: histinfo. If the option-tag is in the Supported, then you c= an send H-I entries in response. Else not. Even if the request contained = H-I entries but no "histinfo" option tag, you can't send 'em back. (e.g., s= uch would be the case if proxies added the entries but the UAC does not sup= port it) -hadriel From shida@ntt-at.com Wed Jun 15 22:30: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 4646311E80D4 for ; Wed, 15 Jun 2011 22:30:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i29rcVGZqNnP for ; Wed, 15 Jun 2011 22:30:03 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id B492311E80B4 for ; Wed, 15 Jun 2011 22:30:03 -0700 (PDT) Received: from [125.192.75.244] (port=53400 helo=[192.168.1.3]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QX59Q-0004ji-Hp; Thu, 16 Jun 2011 00:29:57 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Thu, 16 Jun 2011 14:29:57 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <519E63DC-C084-4822-AD08-7FDF5B9D7EB1@ntt-at.com> References: <4DEC205A.5040503@cisco.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) 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: flh1agj244.tky.mesh.ad.jp ([192.168.1.3]) [125.192.75.244]:53400 X-Source-Auth: shida@agnada.com X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "draft-ietf-sipcore-rfc4244bis@tools.ietf.org" , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] 4244bis-05: editorial comments 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, 16 Jun 2011 05:30:04 -0000 Hadriel; Thanks, we will reflect this on the next revision.=20 Regards Shida On Jun 16, 2011, at 4:51 AM, Hadriel Kaplan wrote: > Following are editorial comments on 4244bis-05 in WGLC... >=20 > 1) Page 8, section 5 first sentence: "REFER and OPTIONS, PUBLISH and = SUBSCRIBE, etc." get rid of the first "and". >=20 > 2) Page 8, section 5 first bullet: "A mandatory parameter for...", = change "parameter" to "field", since hi-targeted-to-uri is a header = field not a parameter. >=20 > 3) Page 13, Figure 1 caption isn't on the same page as the figure = itself. There's an extra whitespace line below the 'Proxy Cancels = INVITE' double-arrow in the drawing which can be remove so that the = caption fits on the same page as the figure. >=20 > 4) Page 16, Section 9.3, end of section: "(e.g., 1.2 and 1.4 could but = present..." should be "...could be present...". >=20 > -hadriel >=20 From shida@ntt-at.com Thu Jun 16 00:41: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 6614A11E80B5 for ; Thu, 16 Jun 2011 00:41:38 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wc8wPXediZtt for ; Thu, 16 Jun 2011 00:41:37 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id D9D2111E8078 for ; Thu, 16 Jun 2011 00:41:37 -0700 (PDT) Received: from [125.192.75.244] (port=54174 helo=[192.168.1.3]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QX7Co-0004HP-6p; Thu, 16 Jun 2011 02:41:34 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <7A463F33-4115-4E9D-8D1C-C8F49BA9CFDD@acmepacket.com> Date: Thu, 16 Jun 2011 16:41:31 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <7E5B50A1-81D0-433A-BAEF-F7B9037F4691@ntt-at.com> References: <7A463F33-4115-4E9D-8D1C-C8F49BA9CFDD@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) 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: flh1agj244.tky.mesh.ad.jp ([192.168.1.3]) [125.192.75.244]:54174 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sipcore@ietf.org WG" Subject: Re: [sipcore] 4244bis-05: the infamous "rc" param 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, 16 Jun 2011 07:41:38 -0000 I don't recall exactly why we decided to limit the scope of "rc".=20 I vaguely remember the debate on allowing "rc" to be used for = resolution=20 beside the current intended context, resulting in convoluting the=20 tag and overloading it making it indeterministic. I think it was about = non-REGISTER=20 could raise the question of "How do you know that it was for = AoR-to-Contact resolution?".=20 For example when barnes-sipcore-rfc4244bis-02 has 4 tags of which=20 "cc" covers the cases you expressed the concerns for, but I can't recall=20= the exact reason why we limited the scope.=20 "rc": The entry is a contact that is bound to an AOR in an abstract location service. The AOR-to-contact binding has been placed into the location service by a SIP Registrar that received a SIP REGISTER request. * "cc": The entry is a contact that is bound to an AOR in an abstract location service. The AOR-to-contact binding has been placed into the location service implicitly through a means other than a SIP Registrar acting on a REGISTER request, e.g., the user may be currently logged into a Web Portal that implements a Presence and IM service, or it could be manually configured. * "mp": The entry is a URI that represents another user. This occurs in cases where a request is statically or dynamically retargeted to another user. * "rt": The entry is "routed", i.e., it is either a no-op like a proxy forwarding, predetermined by a maddr in the Request-URI, or the Request-URI is changed to a new URI that represents the same user, and is not a contact in a SIP Registrar. By the time it was revised to 03 the tag was reduced to the two we=20 currently have. So there was a conclusion made sometime between the=20 02 and 03.=20 I personally don't have a strong opinions on this and would be happy = to change=20 the definition of the "rc" tag but I wasn't the one who raised the = concerns, so I think=20 we need to find those that lead us to the current status on this issue..=20= Regards Shida On Jun 16, 2011, at 4:52 AM, Hadriel Kaplan wrote: > Howdy, > I still have concerns regarding the "rc" param in this draft. Right = now, the "rc" is only added for request-uri retargeting due to = AoR-to-contact resolution, populated by a SIP Registrar from a REGISTER. = That's it. So "rc" is not added due to static/provisioned = Aor-to-contact mappings, for example. Nor is it added due to ENUM = resolution. Nor, apparently, if the Proxy doing the routing doesn't = know how the database's entry was populated. >=20 > So... why does it matter how the abstract location database got = populated? Example applications in this draft, as well as in = rfc4244bis-callflows, apparently rely on the existence of an "rc" param = to perform their logic. Afaict, however, it's NOT the case that they = actually care whether it was due to a REGISTER or not. They only care = about finding the first or last relevant URI they understand. >=20 > For example: in a sip trunking context, a la Martini-GIN, request = routing to GIN-PBX bulk-registered contacts would get the "rc". But = request routing to PBX's UAs using 3263 or static provisioning would = not. Should the application service logic or behavior be different for = these different ways of deploying SIP trunks? >=20 > -hadriel >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From shida@agnada.com Thu Jun 16 17:30: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 6AB2D1F0C58 for ; Thu, 16 Jun 2011 17:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[AWL=1.113, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhS8n6P9weZ8 for ; Thu, 16 Jun 2011 17:30:08 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.14.8]) by ietfa.amsl.com (Postfix) with SMTP id 0BC931F0C4E for ; Thu, 16 Jun 2011 17:30:07 -0700 (PDT) Received: (qmail 19307 invoked from network); 17 Jun 2011 00:29:31 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway04.websitewelcome.com with SMTP; 17 Jun 2011 00:29:31 -0000 Received: from [125.192.75.244] (port=58011 helo=[192.168.1.3]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QXMwl-0001z6-8q; Thu, 16 Jun 2011 19:30:04 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--749079247 From: Shida Schubert In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E36022D@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 17 Jun 2011 09:30:02 +0900 Message-Id: <2FDD10D8-6DF3-4D77-B300-C05C2AB5D3A2@agnada.com> References: <4DEC205A.5040503@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E36022D@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) 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 - agnada.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: flh1agj244.tky.mesh.ad.jp ([192.168.1.3]) [125.192.75.244]:58011 X-Source-Auth: shida@agnada.com X-Email-Count: 3 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t X-Mailman-Approved-At: Thu, 16 Jun 2011 18:59:01 -0700 Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org, "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs , Robert Sparks Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis 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, 17 Jun 2011 00:30:09 -0000 --Apple-Mail-1--749079247 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Christer; Thanks for the comments and for reviewing the draft. My comments inline.. On Jun 10, 2011, at 6:08 AM, Christer Holmberg wrote: > Hi, > =20 > Some comments, based on feedback I've got from collegues. > =20 > =20 > 1. Usage of "rc" and "mp" in Contact header field (technical) > =20 > The document defines the "rc" and "mp" parameters also for the Contact = header field. However, it is unclear when and how the parameters would = be used in a Contact header field. I think this is already described in the section 10.4.=20 "In the latter case, the specific header parameter field in the Contact header becomes the header field parameter that is used in the hi- target-param in the hi-entry when the request is retargeted." > =20 > =20 > 2. Tel to Sip transformation: ENUM (technical) > =20 > Section 5 talks about transformation from Tel to Sip, according = section 19.6.1 of RFC 3261. However, the transformation can also be the = result of an ENUM DNS lookup. So, maybe some text should be added, = indicating that the transformation can be done based on local = configuration (the hostpart of the new SIP-URI needs to be taken from = somewhere), or based on an ENUM DNS lookup. =20 Are you talking about adding target-param based on ENUM lookup or=20 simply recording the transformation/resolution in H-I?=20 Anyway, do you want to suggest some text as a co-author of the draft? = :-) > =20 > =20 > 3. Tel to Sip transformation: History-Info (technical) > =20 > Related to the previous question, the text doesn't indicate whether = the transformation from Tel to Sip should be recorded in an History-Info = header field. The Request-URI is, after all, changed. > =20 I don't know if we need to add anything specific for this. The draft = doesn't limit the=20 behavior of the entity recording H-I to only record SIP-URI, it just = says to record the=20 R-URI.=20 > =20 > 4. Home proxy (editorial) > =20 > The draft mentions "home proxy", but there is no reference or = definition for it. I guess it should be "registrar", or something. I guess we can call it a "registrar" or at the first instance include a = text used in=20 RFC 3327.=20 REGISTRAR or a "home proxy" (a proxy serving as the terminal point for = routing an address-of-record) > =20 > =20 > 5. Out-of-dialog request (editorial) > =20 > Section 5 talks about "request not associated with an early or = established dialog", while section 6.1 talks about "new or out-of-dialog = request". In both cases the text refers to the request that can carry = History-Info, so the wording should be consistance. For example = "out-of-dialog requests or initial requests for a dialog". I agree. > =20 > =20 > 6. Appearence (editorial) > =20 > Section 5 says in which message types History-Info "can appear". It = would be better to say for which message types the = document/specification defines the usage of History-Info. > =20 Sounds good.=20 > =20 > 7. Misc (editorial) > =20 > There are, throughout the document, some inconsistance between usage = of "header" vs "header field", "this document" vs "this specification", = the usage of capital letters for requests and SIP entity names etc, but = I guess that can be taken care of by the authors without a list of every = occurance here. We thought we were pretty careful with this as John has pointed these = out before.=20 We will go through the draft and make sure there is consistency with = the wording.=20 Thanks Shida > =20 > =20 > Regards, > =20 > Christer >=20 > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On = Behalf Of Paul Kyzivat > Sent: 6. kes=E4kuuta 2011 3:34 > To: SIPCORE (Session Initiation Protocol Core) WG > Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org; SIPCORE Chairs; = Robert Sparks > Subject: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis >=20 > [as co-chair] >=20 > The current editor of draft-ietf-sipcore-rfc4244bis believes that the = document has no remaining technical issues, and is ready for evaluation. = Today, we are starting a two-week working group last call period. This = last call period ends on Sunday, June 19. >=20 > The latest version of the document can be retrieved here: >=20 > http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis >=20 > Any comments on the document should be sent to the SIPCORE mailing = list. >=20 > Thanks, > Paul --Apple-Mail-1--749079247 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

Hi,

Some comments, based on = feedback I've got from=20 collegues.

1. Usage of "rc" and "mp" = in Contact header field=20 (technical)

The document defines the = "rc" and "mp" parameters also=20 for the Contact header field. However, it is unclear when and = how the=20 parameters would be used in a Contact header = field.

I = think this is already described in the section = 10.4.

"In the latter case, the = specific header parameter field in the Contact

= header becomes the header field parameter that is used in the = hi-

target-param in the hi-entry when the request = is retargeted."

2. Tel to Sip = transformation: ENUM=20 (technical)

Section 5 talks about = transformation from Tel to Sip,=20 according section 19.6.1 of RFC 3261. However, the transformation can = also be=20 the result of an ENUM DNS lookup. So, maybe some text should be added,=20= indicating that the transformation can be done based on local = configuration (the=20 hostpart of the new SIP-URI needs to be taken from somewhere), or based = on an=20 ENUM DNS = lookup.

= Are you talking about adding target-param based on ENUM lookup = or

simply recording the transformation/resolution in = H-I?

Anyway, do you want to = suggest some text as a co-author of the draft? :-)

3. Tel to Sip = transformation: History-Info=20 (technical)

Related to the previous = question, the text doesn't indicate=20 whether the transformation from Tel to Sip should be recorded in an = History-Info=20 header field. The Request-URI is, after all, = changed.

I don't know if we need to add anything specific for this. The = draft doesn't limit the

behavior of the entity recording = H-I to only record SIP-URI, it just says to record = the

R-URI.

4. Home proxy = (editorial)

The draft mentions "home = proxy", but there is no reference=20 or definition for it. I guess it should be "registrar", or=20 = something.

= ;I guess we can call it a "registrar" or at the first instance include a = text used in

RFC = 3327.

REGISTRAR or a "home proxy" = (a proxy serving as the terminal point for routing an = address-of-record)

5. Out-of-dialog request=20= (editorial)

Section 5 talks about = "request not associated with an=20 early or established dialog", while section 6.1 talks about "new or=20 out-of-dialog request". In both cases the text refers to the request = that can=20 carry History-Info, so the wording should be consistance. For example=20 "out-of-dialog requests or initial requests for a = dialog".

I = agree.

6. Appearence = (editorial)

Section 5 says in which = message types History-Info=20 "can appear". It would be better to say for which message types the=20 document/specification defines the usage of = History-Info.

= ;Sounds good.

7. Misc = (editorial)

There are, throughout the = document, some inconsistance=20 between usage of "header" vs "header field", "this document" vs = "this=20 specification", the usage of capital letters for requests and SIP entity = names=20 etc, but I guess that can be taken care of by the authors = without a=20 list of every occurance = here.

<= /div>

We thought we were pretty careful with this as John has = pointed these out before.

We will = go through the draft and make sure there is consistency with the = wording.

Thanks

= ;Shida

Regards,
=

Christer

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul=20 Kyzivat
Sent: 6. kes=E4kuuta 2011 3:34
To: SIPCORE = (Session=20 Initiation Protocol Core) WG
Cc:=20 draft-ietf-si= pcore-rfc4244bis@tools.ietf.org; SIPCORE Chairs; Robert=20 Sparks
Subject: [sipcore] WGLC:=20 draft-ietf-sipcore-rfc4244bis

[as co-chair]

The current editor = of=20 draft-ietf-sipcore-rfc4244bis believes that the document has no = remaining=20 technical issues, and is ready for evaluation. Today, we are starting = a=20 two-week working group last call period. This last call period ends on = Sunday,=20 June 19.

The latest version of the document can be retrieved=20 here:

http://t= ools.ietf.org/html/draft-ietf-sipcore-rfc4244bis

Any=20 comments on the document should be sent to the SIPCORE mailing=20 list.

Thanks,
= Paul=20

= --Apple-Mail-1--749079247-- From christer.holmberg@ericsson.com Fri Jun 17 00:25: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 7993321F84B2 for ; Fri, 17 Jun 2011 00:25:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id who1KxWORezs for ; Fri, 17 Jun 2011 00:25:49 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD1F21F84B1 for ; Fri, 17 Jun 2011 00:25:49 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-7b-4dfb017ca446 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 0B.BC.09774.C710BFD4; Fri, 17 Jun 2011 09:25:48 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 17 Jun 2011 09:25:47 +0200 From: Christer Holmberg To: Shida Schubert Date: Fri, 17 Jun 2011 09:25:47 +0200 Thread-Topic: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Thread-Index: AcwskE2KA3YSDlZTQ1ieRnsW6pVr1wAKRjFg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E3E71BA@ESESSCMS0356.eemea.ericsson.se> References: <4DEC205A.5040503@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E36022D@ESESSCMS0356.eemea.ericsson.se> <2FDD10D8-6DF3-4D77-B300-C05C2AB5D3A2@agnada.com> In-Reply-To: <2FDD10D8-6DF3-4D77-B300-C05C2AB5D3A2@agnada.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: "draft-ietf-sipcore-rfc4244bis@tools.ietf.org" , "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs , Robert Sparks Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis 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, 17 Jun 2011 07:25:50 -0000 Hi Shida,=20 =20 >>1. Usage of "rc" and "mp" in Contact header field (technical) >> =20 >>The document defines the "rc" and "mp" parameters also for the Contact he= ader field. However, it is unclear when and how the parameters would be use= d in a Contact header field. >> > > I think this is already described in the section 10.4.=20 > > "In the latter case, the specific header parameter field in the Contact > header becomes the header field parameter that is used in the hi- > target-param in the hi-entry when the request is retargeted." The text says what you use it for, but not how it was inserted in the Conta= ct in the first place. ---------- >>2. Tel to Sip transformation: ENUM (technical) >> =20 >>Section 5 talks about transformation from Tel to Sip, according section 1= 9.6.1 of RFC 3261. However, the transformation can also be the result of an= ENUM DNS lookup. So, maybe some text should=20 >>be added, indicating that the transformation can be done based on local c= onfiguration (the hostpart of the new SIP-URI needs to be taken from somewh= ere), or based on an ENUM DNS lookup. > >Are you talking about adding target-param based on ENUM lookup or simply r= ecording the transformation/resolution in H-I?=20 Both. >Anyway, do you want to suggest some text as a co-author of the draft? :-) Sure :)=20 But, it is a little unclear to me what target-param (if any), I would inclu= de, so I would like that to get soreted out first. ---------- =20 >>3. Tel to Sip transformation: History-Info (technical) >> =20 >>Related to the previous question, the text doesn't indicate whether the t= ransformation from Tel to Sip should be recorded in an History-Info header = field. The Request-URI is, after all,=20 >>changed. > =20 > >I don't know if we need to add anything specific for this. The draft doesn= 't limit the=20 >behavior of the entity recording H-I to only record SIP-URI, it just says = to record the=20 >R-URI.=20 Based on the comments I get, the text seems to indicate that you shouldn't = insert a Tel in a History-Info in the first place. Instead you should trans= form it to a SIP-URI before inserting it. But, I can think of some text for that also, because it's related to the pr= evious comments. ---------- >>4. Home proxy (editorial) >> =20 >>The draft mentions "home proxy", but there is no reference or definition = for it. I guess it should be "registrar", or something. > >I guess we can call it a "registrar" or at the first instance include a te= xt used in=20 >RFC 3327.=20 > > REGISTRAR or a "home proxy" (a proxy serving as the terminal point for r= outing an address-of-record) I think it occurs only once, but as long as there is a definition (or a ref= erence to a definition) I don't mind if it's used. Regards, Christer =20 =20 From HKaplan@acmepacket.com Fri Jun 17 09:07: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 94A1111E813B for ; Fri, 17 Jun 2011 09:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLkOGHWooMim for ; Fri, 17 Jun 2011 09:07:25 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 66A7911E80DB for ; Fri, 17 Jun 2011 09:07:25 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 17 Jun 2011 12:07:23 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Fri, 17 Jun 2011 12:07:23 -0400 From: Hadriel Kaplan To: Shida Schubert Date: Fri, 17 Jun 2011 12:07:22 -0400 Thread-Topic: [sipcore] 4244bis-05: the infamous "rc" param Thread-Index: AcwtCKR5V/loV58AR7+qFsLYCHw+MQ== Message-ID: <88801004-2367-4BE3-8564-3228A279B9E1@acmepacket.com> References: <7A463F33-4115-4E9D-8D1C-C8F49BA9CFDD@acmepacket.com> <7E5B50A1-81D0-433A-BAEF-F7B9037F4691@ntt-at.com> In-Reply-To: <7E5B50A1-81D0-433A-BAEF-F7B9037F4691@ntt-at.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: AAAAAgAAAUAAAAFS Cc: "sipcore@ietf.org WG" Subject: Re: [sipcore] 4244bis-05: the infamous "rc" param 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, 17 Jun 2011 16:07:26 -0000 I was one of the ones arguing for reducing/removing the other tags as "fluf= f", but that included removing the "rc" tag. That was because, at the time= there was an "aor" tag - the "aor" and "mp" tags were the only ones actual= ly used by receiving UAS applications, so the other tags just add confusion= . =20 Now there is no "aor" tag, because it's incredibly difficult for a system t= o know when a URI is an "Address of Record". But having the "rc" tag doesn= 't solve the problem - it just moves it around. Now you're just *implying* = the entry before the "rc" tagged one is an AoR, which is just as error pron= e as before. It's error-prone because: 1) It will have false-positives - cases where the entry prior to the "rc" t= agged one is not the one the application actually wants. 2) It will have false-negatives - cases where there is no "rc" tag because = the UAS did not use Registration model to receive a request, or the interme= diate proxy/ies did not know that it was due to a registration. My point is that the real purpose of using History-Info and having these ta= gs is to enable applications on the UAS. Some of those applications need t= o find target URIs that were changed along the way. *Why* they were change= d matters, but not *how* they were changed. Whether it was due to a SIP-Re= gistration database, ENUM database, LDAP lookup, or reading tea leaves does= n't matter. What "rc" should actually stand for is "Request-uri Changed". It should be= populated in ALL cases where the request-URI is changed, but where the new= target is still the same identity (ie, it's not an "mp" tag instead), and = it should still use an index to point to the previous H-I entry it changed = from as it does now. -hadriel On Jun 16, 2011, at 3:41 AM, Shida Schubert wrote: > I don't recall exactly why we decided to limit the scope of "rc".=20 >=20 > I vaguely remember the debate on allowing "rc" to be used for resolution= =20 > beside the current intended context, resulting in convoluting the=20 > tag and overloading it making it indeterministic. I think it was about no= n-REGISTER=20 > could raise the question of "How do you know that it was for AoR-to-Conta= ct resolution?".=20 >=20 > For example when barnes-sipcore-rfc4244bis-02 has 4 tags of which=20 > "cc" covers the cases you expressed the concerns for, but I can't recall= =20 > the exact reason why we limited the scope.=20 >=20 > "rc": The entry is a contact that is bound to an AOR in an > abstract location service. The AOR-to-contact binding has been > placed into the location service by a SIP Registrar that > received a SIP REGISTER request. >=20 > * "cc": The entry is a contact that is bound to an AOR in an > abstract location service. The AOR-to-contact binding has been > placed into the location service implicitly through a means > other than a SIP Registrar acting on a REGISTER request, e.g., > the user may be currently logged into a Web Portal that > implements a Presence and IM service, or it could be manually > configured. >=20 > * "mp": The entry is a URI that represents another user. This > occurs in cases where a request is statically or dynamically > retargeted to another user. >=20 > * "rt": The entry is "routed", i.e., it is either a no-op like a > proxy forwarding, predetermined by a maddr in the Request-URI, > or the Request-URI is changed to a new URI that represents the > same user, and is not a contact in a SIP Registrar. >=20 > By the time it was revised to 03 the tag was reduced to the two we=20 > currently have. So there was a conclusion made sometime between the=20 > 02 and 03.=20 >=20 > I personally don't have a strong opinions on this and would be happy to = change=20 > the definition of the "rc" tag but I wasn't the one who raised the concer= ns, so I think=20 > we need to find those that lead us to the current status on this issue..= =20 >=20 > Regards > Shida >=20 > On Jun 16, 2011, at 4:52 AM, Hadriel Kaplan wrote: >=20 >> Howdy, >> I still have concerns regarding the "rc" param in this draft. Right now= , the "rc" is only added for request-uri retargeting due to AoR-to-contact = resolution, populated by a SIP Registrar from a REGISTER. That's it. So "= rc" is not added due to static/provisioned Aor-to-contact mappings, for exa= mple. Nor is it added due to ENUM resolution. Nor, apparently, if the Pro= xy doing the routing doesn't know how the database's entry was populated. >>=20 >> So... why does it matter how the abstract location database got populate= d? Example applications in this draft, as well as in rfc4244bis-callflows= , apparently rely on the existence of an "rc" param to perform their logic.= Afaict, however, it's NOT the case that they actually care whether it was= due to a REGISTER or not. They only care about finding the first or last = relevant URI they understand. >>=20 >> For example: in a sip trunking context, a la Martini-GIN, request routin= g to GIN-PBX bulk-registered contacts would get the "rc". But request rout= ing to PBX's UAs using 3263 or static provisioning would not. Should the a= pplication service logic or behavior be different for these different ways = of deploying SIP trunks? >>=20 >> -hadriel >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 From dworley@avaya.com Fri Jun 17 13:02: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 96CEB9E8030 for ; Fri, 17 Jun 2011 13:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.405 X-Spam-Level: X-Spam-Status: No, score=-103.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmT+EelDu0SG for ; Fri, 17 Jun 2011 13:02:57 -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 A5D4E9E8035 for ; Fri, 17 Jun 2011 13:02:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADWx+02HCzI1/2dsb2JhbABFDaZSd4hzpAUCmyMCgxmDDASWWosd X-IronPort-AV: E=Sophos;i="4.65,382,1304308800"; d="scan'208";a="285653717" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Jun 2011 16:02:56 -0400 X-IronPort-AV: E=Sophos;i="4.65,382,1304308800"; d="scan'208";a="667611029" 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; 17 Jun 2011 16:02:56 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Fri, 17 Jun 2011 16:02:55 -0400 From: "Worley, Dale R (Dale)" To: Hadriel Kaplan , Shida Schubert Date: Fri, 17 Jun 2011 16:02:56 -0400 Thread-Topic: [sipcore] 4244bis-05: the infamous "rc" param Thread-Index: AcwtCKR5V/loV58AR7+qFsLYCHw+MQAH0Kgv Message-ID: References: <7A463F33-4115-4E9D-8D1C-C8F49BA9CFDD@acmepacket.com> <7E5B50A1-81D0-433A-BAEF-F7B9037F4691@ntt-at.com>, <88801004-2367-4BE3-8564-3228A279B9E1@acmepacket.com> In-Reply-To: <88801004-2367-4BE3-8564-3228A279B9E1@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 Cc: "sipcore@ietf.org WG" Subject: Re: [sipcore] 4244bis-05: the infamous "rc" param 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, 17 Jun 2011 20:02:58 -0000 > From: Hadriel Kaplan [HKaplan@acmepacket.com] >=20 > What "rc" should actually stand for is "Request-uri Changed". It > should be populated in ALL cases where the request-URI is changed, but > where the new target is still the same identity (ie, it's not an "mp" > tag instead), and it should still use an index to point to the > previous H-I entry it changed from as it does now. I'm not so concerned about the different categories of redirection and how = we record them, but that there will be some redirections to which neither "rc" nor "mp" wil= l apply. In those cases, there is no way to record which URI this URI is derived fro= m, because the back-pointer is the value of rc/mp. And it doesn't look like the draft thinks about that case much. There thre= e examples that I can find where a URI is not the same as its parent but does not have an r= c/mp parameter: Messages F6 and F9 in B.1 and one message in B.2: F6 INVITE example.com -> office INVITE sip:office@192.0.2.3.com SIP/2.0 History-Info: ;index=3D1 History-Info: ;\ index=3D1.1;rc=3D1 History-Info: ;index=3D1.2;mp=3D1 History-Info: ;index=3D1.2.1 <------------------ =20 F9 INVITE example.com -> home INVITE sip:home@192.0.2.6 SIP/2.0 History-Info: ;index=3D1 History-Info: ;\ index=3D1.1;rc=3D1 History-Info: ;index=3D1.2;mp=3D1 History-Info: ;\ index=3D1.2.1>;index=3D1.2.1 History-Info: ;index=3D1.3;mp=3D1 History-Info: ;index=3D1.3.1 <---------------------- | | INVITE sip:bob@biloxi.example.com;p=3Dx | |--------------->| | | History-Info: ;index=3D1 | History-Info: ;index=3D1.1 [Though the last one was due to anonymization.] I think we need to adjust the parameters to put the back-pointer into a sep= arate parameter from the "type of redirection" information. Dale From dworley@avaya.com Fri Jun 17 14:12: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 28DA921F8466 for ; Fri, 17 Jun 2011 14:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.398 X-Spam-Level: X-Spam-Status: No, score=-103.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LRTQf4Sd4nR for ; Fri, 17 Jun 2011 14:12:10 -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 9B29121F8462 for ; Fri, 17 Jun 2011 14:12:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABzC+02HCzI1/2dsb2JhbABSplR3rUACmyKGJwSWWosd X-IronPort-AV: E=Sophos;i="4.65,383,1304308800"; d="scan'208";a="251966299" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 Jun 2011 17:12:07 -0400 X-IronPort-AV: E=Sophos;i="4.65,383,1304308800"; d="scan'208";a="667637179" 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; 17 Jun 2011 17:12:06 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Fri, 17 Jun 2011 17:12:06 -0400 From: "Worley, Dale R (Dale)" To: "Worley, Dale R (Dale)" , Hadriel Kaplan , Shida Schubert Date: Fri, 17 Jun 2011 17:09:34 -0400 Thread-Topic: [sipcore] 4244bis-05: Semantics of History-Info Thread-Index: AQHMLTM2z4uZAgdj40ilXcDNMv+BZg== 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 Cc: "sipcore@ietf.org WG" Subject: Re: [sipcore] 4244bis-05: Semantics of History-Info 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, 17 Jun 2011 21:12:12 -0000 The -05 draft is considerably better written than the earlier drafts, but i= t still lacks what I think is a critical explanation: A description of what a give= n History-Info header means. The draft gives a series of procedures, but there's no way t= o check whether they are correct or not, because there's no way to say whether thei= r results are correct. It's like trying to check the correctness of an algorithm whe= n there's no specification of the desired output. I'll write a draft of such a thing this weekend. Dale From dworley@avaya.com Fri Jun 17 14:26:23 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 556FF11E80B9 for ; Fri, 17 Jun 2011 14:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.41 X-Spam-Level: X-Spam-Status: No, score=-103.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GA9f+xtSfkeX for ; Fri, 17 Jun 2011 14:26:22 -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 73FA311E807F for ; Fri, 17 Jun 2011 14:26:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAN/F+02HCzI1/2dsb2JhbABSplh3rVoCmyKGJwSWWosd X-IronPort-AV: E=Sophos;i="4.65,383,1304308800"; d="scan'208";a="251969866" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 17 Jun 2011 17:26:21 -0400 X-IronPort-AV: E=Sophos;i="4.65,383,1304308800"; d="scan'208";a="667641184" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 17 Jun 2011 17:26:20 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 17 Jun 2011 17:26:20 -0400 From: "Worley, Dale R (Dale)" To: "Worley, Dale R (Dale)" , Hadriel Kaplan , Shida Schubert Date: Fri, 17 Jun 2011 17:23:59 -0400 Thread-Topic: [sipcore] 4244bis-05: tel: URIs Thread-Index: AQHMLTUykQ3U4ckKl0ahZUrAJLWqTg== 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 Cc: "sipcore@ietf.org WG" Subject: Re: [sipcore] 4244bis-05: tel: URIs 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, 17 Jun 2011 21:26:23 -0000 How are tel: URIs handled? From section 5, it looks like a tel: gets turne= d into a sip: if Reason or Privacy needs to be applied: Note that since both the Reason and Privacy parameters are included in the hi-targeted-to-uri, these fields will not be available in the case that the hi-targeted-to-uri is a Tel-URI [RFC3966]. In such cases, the Tel-URI SHOULD be transformed into a SIP URI per section 19.1.6 of [RFC3261]. But 10.2 makes it sound as if Reason isn't applied to tel: If the Reason header field is being added due to receipt of an explicit SIP response and the response contains any Reason header fields (see [RFC3326]), then the SIP entity MUST include the Reason header fields in the "headers" component of the hi-targeted-to-uri in the last hi-entry added to the cache, unless the hi-targeted-to-uri is a Tel-URI. If the SIP response does not contain a Reason header field, the SIP entity MUST include a Reason header field, containing the SIP Response Code, in the "headers" component of the hi-targeted-to-uri in the last hi-entry added to the cache, unless the hi-targeted-to-uri is a Tel-URI. Dale From dworley@avaya.com Fri Jun 17 14:28: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 897BF11E807F for ; Fri, 17 Jun 2011 14:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.422 X-Spam-Level: X-Spam-Status: No, score=-103.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sioBfZIGyTCQ for ; Fri, 17 Jun 2011 14:28:24 -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 E1DAC11E80A9 for ; Fri, 17 Jun 2011 14:28:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAnG+02HCzI1/2dsb2JhbABSplh3rV0CmyKGJwSWWosd X-IronPort-AV: E=Sophos;i="4.65,383,1304308800"; d="scan'208";a="285668248" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Jun 2011 17:28:23 -0400 X-IronPort-AV: E=Sophos;i="4.65,383,1304308800"; d="scan'208";a="667641783" 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; 17 Jun 2011 17:28:23 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Fri, 17 Jun 2011 17:28:22 -0400 From: "Worley, Dale R (Dale)" To: "Worley, Dale R (Dale)" , Hadriel Kaplan , Shida Schubert Date: Fri, 17 Jun 2011 17:26:24 -0400 Thread-Topic: [sipcore] 4244bis-05: name-addr Thread-Index: AQHMLTV7Q223LCDkhkOs6WQumDAAzA== 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 Cc: "sipcore@ietf.org WG" Subject: Re: [sipcore] 4244bis-05: name-addr 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, 17 Jun 2011 21:28:24 -0000 For consistency of construction and parsing with To, From, Contact, etc., I= suggest that the syntax be modified to: hi-targeted-to-uri =3D addr-spec / name-addr We really don't need a separate parser for History-Info than from all the o= ther headers with a similar syntax. Dale From dworley@avaya.com Sun Jun 19 19:52:59 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 7C0F922800C for ; Sun, 19 Jun 2011 19:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.431 X-Spam-Level: X-Spam-Status: No, score=-103.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7P1Fo79SgWSc for ; Sun, 19 Jun 2011 19:52:58 -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 BB48F228008 for ; Sun, 19 Jun 2011 19:52:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkGANq0/k3GmAcF/2dsb2JhbABSpltwB6glg2oCmkyGKgSWW4sg X-IronPort-AV: E=Sophos;i="4.65,390,1304308800"; d="scan'208";a="252171149" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 Jun 2011 22:52:55 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Jun 2011 22:52:38 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Sun, 19 Jun 2011 22:52:54 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Sun, 19 Jun 2011 22:48:49 -0400 Thread-Topic: 4244bis-05: Semantics of History-Info Thread-Index: AQHMLvUmSuWIGmIhe0mkrHHB6J8m8w== 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] 4244bis-05: Semantics of History-Info 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, 20 Jun 2011 02:52:59 -0000 Here is a start for how I'd like to see section 5 organized. The idea is t= o describe clearly what a particular History-Info header means when you loo= k at it. It correlates with the procedures described in the draft in the s= ame way that the input/output specification of a module corresponds to the = code of the module -- it allows you to verify that the code does what it is= intended to do (and that the specification is correct). --------------------------- 5.1 Syntax of History-Info The ABNF syntax for the History-info header field and header field parameters is as follows: History-Info =3D "History-Info" HCOLON hi-entry *(COMMA hi-entry) hi-entry =3D hi-targeted-to-uri *(SEMI hi-param) hi-targeted-to-uri =3D name-addr hi-param =3D hi-index / hi-target-param / hi-extension index-val =3D 1*DIGIT *("." 1*DIGIT) hi-index =3D "index" EQUAL index-val hi-target-param =3D rc-param / mp-param rc-param =3D "rc" EQUAL index-val mp-param =3D "mp" EQUAL index-val hi-extension =3D generic-param The ABNF definitions for "generic-param" and "name-addr" are from [RFC3261]. This document also extends the "contact-params" for the Contact header field as defined in [RFC3261] with the "rc" and "mp" header field parameters defined above: contact-params =3D/ hi-target-param 5.2 Semantics of History-Info The History-Info header fields of a request or response together form an ordered sequence of hi-entries. The division of the hi-entries among one or more History-Info header fields is not significant. The hi-entries are a pre-order walk of a tree, the nodes of which represent requests derived from the same original request sent by the UAC. The tree is organized by the derivation of requests by forwarding and forking, with each node's request being derived (by one or more steps) from its parent node's request. [There are complexities if the UAC does not support History-Info, but downstream entities do, particularly if a first History-Info is added on two different forks -- both forks have hi-entries with index "1".] Because not all SIP entities support History-Info, the tree may not separately represent every forwarding and forking operation. (Abstractly, the tree can be derived from the tree that would be recorded if all entities supported History-Info by collapsing certain contiguous sets of nodes.) In addition, if an entity that supports History-Info receives a request whose Request-URI is different from the URI recorded in the History-Info that should correspond to the request, then the entity knows that the Request-URI has been changed by an entity that does not support History-Info, and the entity will perform a preparatory normalization by adding an additional leaf to the tree showing the new Request-URI. This operation is specified in section 9. [Note that this introduces a problem: Suppose the UAS sends "History-Info: AOR;index=3D1", and a non-History-Info-supporting entity for= ks it to two destinations, UAS A and UAS B, both of which support History-Info. UAS A normalizes the request to "History-Info: AOR;index=3D1, UAS-A;index=3D1.1" while UAS B normalizes the request to "History-Info: AOR;index=3D1, UAS-B;index=3D1.1". These two normalized requests violate the rule that everybody expects to be satisfied, viz., that all hi-entries in the entire forking structure with the same index represent the same request. As a result, the responses from the two UASs cannot be merged in any useful way. In this particular case, we are saved from a mess by the fact that the proxy will forward only one of the History-Info headers back, but we have to check whether this good fortune holds in all situations.] A SIP entity my perform "internal retargeting", multiple stages of retargeting that it models as more than one stage of forking, but without actually generating and sending a SIP request. Internal retargeting may be described in the History-Info tree as one or more nodes, as long as the semantics of the History-Info values correctly describes the derivation of the various Request-URI values. Because of the above complications, the depth of a node within the tree does not equal the number of Via headers in the corresponding request, although the number of Via headers increases as one moves downward in the tree. As forwardings or forkings of a request are generated at a SIP entity, they are numbered in time order as 1, 2, 3, etc. These numbers are the labels of the nodes of the tree, giving each node its index-val and determining the sequential ordering of the hi-entries. The trees recorded in various requests of the forwarding/forking structure are different, but all hi-entries in the trees that share the same index-val represent the same request, and will have the same hi-targeted-to-uri (excepting for changes dictated by privacy processing and changing tel: URIs to sip: URIs). [Also need to take care of the case where the UAC generates several requests as forks of a theoretical ancestral request, as is used in draft-ietf-bliss-call-completion. It seems like they should have index=3D1, index=3D2, index=3D3, etc.] In a request's History-Info, the only requests of the forking structure that are represented are the ones that are ancestral to the request, and subtrees that are siblings of ancestral nodes and have received non-100 responses (which may be recorded in Reason header fields in the hi-targeted-to-uri) (which must necessarily be earlier siblings) . Thus, the rightmost leaf (sequentially last) hi-entry in a request represents the request (and contains the Request-URI of the request) or it represents the latest ancestral request of this request that was constructed by a SIP entity that supports History-Info. A response contains a History-Info header only if the corresponding request contained "Supported: histinfo". As non-100 responses propagate in the reverse direction in the forwarding/forking structure, the hi-entries that they carry are recorded at each SIP entity as part of the state of SIP transactions. These hi-entries will be included in the History-Info of any responses and any additional requests that are generated. When a request or response is forwarded to a "different" domain, some or all of the hi-entries may be anonymized. If a "Privacy: history" header field is present, all hi-entries are anonymized. Any hi-targeted-to-uri that contains a Privacy header with value "history" is anonymized. An hi-entry is anonymized by replacing the URI part of the hi-targeted-to-uri with a URI with domain "anonymous.invalid". 5.3 Semantics of an hi-entry value The following provides details for the information that is captured in the History-Info header field entry (hi-entry) for each target used for forwarding a request: o hi-targeted-to-uri: A mandatory parameter for capturing the Request-URI for the specific request as it is forwarded. o hi-index: A mandatory parameter for History-Info reflecting the chronological order of the information, indexed to also reflect the forking and nesting of requests. The format for this parameter is a string of integers, separated by dots, to indicate the relationships between the requests that carried the Request-URIs captured in the hi-entries. o hi-target-param: An optional parameter reflecting the mechanism by which the Request-URI captured in the hi-targeted-to-uri in the hi-entry was determined, and the captures Request-URI from which it was derived. This parameter contains either an "rc" or "mp" header field parameter, which is interpreted as follows: "rc": The hi-targeted-to-URI is a contact bound to an AOR in an abstract location service, that AOR being the Request-URI that was retargeted. The AOR-to-contact binding has been placed into the location service by a SIP Registrar that received a SIP REGISTER request. The "rc" header field parameter contains the value of the hi-index in the hi-entry with an hi-targeted-to-uri that is the Request-URI that was retargeted "mp": The hi-targeted-to-URI represents a user other than the user associated with the Request-URI in the incoming request that was retargeted. This occurs when a request is statically or dynamically retargeted to another user. The "mp" header field parameter contains the value of the hi-index in the hi- entry with an hi-targeted-to-uri that is the Request-URI that was retargeted, thus identifying the "mapped from" target. [What if a mapping is done in some other manner? How do we record the index-val of the value from which the new Request-URI was derived?] o Extension (hi-extension): A parameter to allow for future optional extensions. As per [RFC3261], any implementation not understanding an extension MUST ignore it. In addition to the parameters defined by the ABNF, an hi-entry may also include a Reason header field and/or a Privacy header field, which are both included in the "headers" component of the hi- targeted-to-uri as described below: o Reason: An optional parameter for History-Info, reflected in the History-Info header field by including the Reason header field [RFC3326] included in the hi-targeted-to-uri. A reason is included in the hi-targeted-to-uri of an hi-entry to reflect information received in the response to the request represented by the hi-entry. [Need to detail exactly what can be included here. It seems that Reason may contain any non-2xx final SIP response code, as well as any non-SIP response codes -- see draft-jesske-dispatch-update3326-reason-responses. 2xx response codes seem to be implicit in that the hi-entry is seen in a non-descendant request or a response, but no SIP Response value is present. Do we want this irregularity for 2xx?] o Privacy: An optional parameter for History-Info, reflected in the History-Info header field values by including the Privacy Header [RFC3323] included in the hi- targeted-to-uri or by adding the Privacy header field to the request. The latter case indicates that the History-Info entries for the domain MUST be anonymized prior to forwarding, whereas the use of the Privacy header field included in the hi-targeted-to-uri means that a specific hi-entry MUST be anonymized. [This specification is vague, as it should give some indication of when anonymization is required. The discussion of "Privacy: history" should not be done here, as it is not part of the hi-entry. It looks like section 10.1.1 is OK for this. So I would revise the above paragraph to: o Privacy: An optional parameter for History-Info, reflected in the History-Info header field values by including in the hi-targeted-to-uri a Privacy Header [RFC3323] with value "history". The Privacy header field included in an hi-targeted-to-uri means that a specific hi-entry MUST be anonymized under the conditions specified in section 10.1.2. Note that since both the Reason and Privacy parameters are included in the hi-targeted-to-uri, these fields will not be available in the case that the hi-targeted-to-uri is a Tel-URI [RFC3966]. In such cases, the Tel-URI SHOULD be transformed into a SIP URI per section 19.1.6 of [RFC3261]. [Does this mean that if an entity desires or is required to apply Reason or Privacy to an hi-entry containing a tel: URI, that it MUST convert it to a sip: URI, and then proceed? If so, it would be better stated:] Note that since both the Reason and Privacy parameters are included in the hi-targeted-to-uri, these fields cannot be applied if=20 the hi-targeted-to-uri is a Tel-URI [RFC3966]. If an entity desires or is required to apply such a parameter, the Tel-URI SHOULD be transformed into a SIP URI per section 19.1.6 of [RFC3261] and then the parameter is applied. 5.4 History-Info Header Field Examples The following provides examples of the format for the History-info header field. Note that the backslash and CRLF between the fields in the examples below are for readability purposes only. History-Info: ;index=3D1;foo=3Dbar History-Info: ;index=3D1.1,\ ;index=3D1.2;mp=3D1.1,\ ;index=3D1.3;rc=3D1.2 --------------------------------------- Dale From christer.holmberg@ericsson.com Sun Jun 19 23:57: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 C67639E800B for ; Sun, 19 Jun 2011 23:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.384 X-Spam-Level: X-Spam-Status: No, score=-6.384 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XfWluklv7ak for ; Sun, 19 Jun 2011 23:57:06 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id D260B9E800A for ; Sun, 19 Jun 2011 23:57:05 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-52-4dfeef4080f9 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A6.C5.09774.04FEEFD4; Mon, 20 Jun 2011 08:57:04 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.138]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 20 Jun 2011 08:57:04 +0200 From: Christer Holmberg To: "SIPCORE (Session Initiation Protocol Core) WG" Date: Mon, 20 Jun 2011 08:57:03 +0200 Thread-Topic: Draft submission: draft-ietf-sipcore-proxy-feature-reqs-00 Thread-Index: AcwvF0LKQFT7YaPITgGrkOCX9bk2pw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB5336480@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_7F2072F1E0DE894DA4B517B93C6A05851DB5336480ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Draft submission: draft-ietf-sipcore-proxy-feature-reqs-00 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, 20 Jun 2011 06:57:06 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05851DB5336480ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a requirements draft for proxy-feature (draft-ietf-sipcore-p= roxy-feature-reqs-00). Based on discussions with the ADs and WG chairs, the draft only contains re= quirements. Based on e-mail discussions and off-line comments, I've also ad= ded a number of requirements. The idea is to first agree on the requirements, and then focus on the solut= ion. Until the draft appears in IETF, it can also be found at: http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-proxy-feature-req= s-00.txt Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05851DB5336480ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I've submitted a requirements draft for proxy-feature= (draft-ietf-sipcore-proxy-feature-reqs-00).

Based on discussions with the ADs and WG chairs, the = draft only contains requirements. Based on e-mail discussions and off-line = comments, I've also added a number of requirements.

The idea is to first agree on the requirements, and t= hen focus on the solution.

Until the draft appears in IETF, it can also be found= at:

http:= //users.piuha.net/cholmber/drafts/draft-ietf-sipcore-proxy-feature-reqs-00.= txt

Regards,

Christer

--_000_7F2072F1E0DE894DA4B517B93C6A05851DB5336480ESESSCMS0356e_-- From dworley@avaya.com Mon Jun 20 12:52: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 1957D1F0C56 for ; Mon, 20 Jun 2011 12:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.44 X-Spam-Level: X-Spam-Status: No, score=-103.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFssbF91GcI4 for ; Mon, 20 Jun 2011 12:52:24 -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 5252C1F0C39 for ; Mon, 20 Jun 2011 12:52:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0FAJuk/03GmAcF/2dsb2JhbABTpmVwB60sAptFhioElluLIA X-IronPort-AV: E=Sophos;i="4.65,396,1304308800"; d="scan'208";a="286035816" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 20 Jun 2011 15:52:23 -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; 20 Jun 2011 15:52:04 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 20 Jun 2011 15:52:23 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Mon, 20 Jun 2011 15:52:22 -0400 Thread-Topic: 4244bis-05: Semantics of History-Info Thread-Index: AQHMLvUmSuWIGmIhe0mkrHHB6J8m85TGoSMs 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] 4244bis-05: Semantics of History-Info 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, 20 Jun 2011 19:52:25 -0000 One advantage to writing this description is that it tends to throw into sharp relief the technical issues that haven't been solidified, either beca= use one discovers that some aspect of the semantics can't be described unambiguously, or because one of the "operational" sections doesn't fit with the semantics. The current version of the draft is considerably clearer than the previous versions, which made it much easier to write the semantics. In this vein, following is a list of technical issues, most of which are th= e parenthesized comments in my first draft of the semantics. [There are complexities if the UAC does not support History-Info, but downstream entities do, particularly if a first History-Info is added on two different forks -- both forks have hi-entries with index "1".] In the current state of the draft, this isn't a problem, because the UAC didn't include "Supported: histinfo", so no responses contain History-Info, and so no History-Info headers from one "island" will ever collide with tho= se of another "island". But it seems like it would be useful to allow a proxy to insert "Supported:= histinfo" into an outgoing request, as long as it purged the History-Info from any re= sponse it sent upstream. [Suppose the UAC sends "History-Info: AOR;index=3D1", and a non-History-Info-supporting entity for= ks it to two destinations, UAS A and UAS B, both of which support History-Info. UAS A normalizes the request to "History-Info: AOR;index=3D1, UAS-A;index=3D1.1" while UAS B normalizes the request to "History-Info: AOR;index=3D1, UAS-B;index=3D1.1".] These two normalized requests violate the rule that everybody expects to be satisfied, viz., that all hi-entries in the entire forking structure with the same index represent the same request. As a result, the responses from the two UASs cannot be merged in any useful way. Since both UASs could send 1xx responses containing History-Info, the UAC can see two different hi-entries with index=3D1.1. In section 9.1 are the rules to help in the case where a H-I-supporting ent= ity receives a request from a non-H-I-supporting entity. As written, it only d= iscusses the case where there is already an H-I header in the request. Strictly spe= aking, the algorithm given faults if there is no H-I header present. But ISTR tha= t we intended that in this case, an hi-entry with index=3D1 should be inserted b= y the receiving entity. [Also need to take care of the case where the UAC generates several requests as forks of a theoretical ancestral request, as is used in draft-ietf-bliss-call-completion. It seems like they should have index=3D1, index=3D2, index=3D3, etc. But this does mean that the "tree" n= ow has an invisible root node whose index is the empty string of integers.] [What if a mapping is done in some other manner? How do we record the index-val of the value from which the new Request-URI was derived?] We still need to decide what do to about mappings that do not qualify for either "rc" or "mp". [Need to detail exactly what can be included in a Reason header in an hi-targeted-to-uri. It seems that Reason may contain any non-2xx final SIP response code, as well as any non-SIP response codes -- see draft-jesske-dispatch-update3326-reason-responses. 2xx response codes seem to be implicit in that the hi-entry is seen in a non-descendant request or a response, but no SIP Response value is present. Do we want this irregularity for 2xx? Or is this necessary for backward compatib= ility?] Do we want to prescribe that reason texts be encoded into the Reason header= ? For SIP response codes, this seems pointless, except for error situations w= here the response-text might have been customized. For other protocols, the rea= son-text might be more important. But none of the examples in the draft shows reason-text, and I expect that people will not bother to implement it unless it is explicitly required. [If an entity desires or is required to apply Reason or Privacy to an hi-entry containing a tel: URI, MUST it convert it to a sip: URI, and then proceed? If so, it would be better if that was sta= ted explicitly. OTOH, it's possible that the step of applying the header is sk= ipped for tel: URIs.] Dale From dean.willis@softarmor.com Mon Jun 20 13:35: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 1A8AF11E8097 for ; Mon, 20 Jun 2011 13:35:27 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hDIwhqkW55j for ; Mon, 20 Jun 2011 13:35:26 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE7811E808E for ; Mon, 20 Jun 2011 13:35:26 -0700 (PDT) Received: by yxt33 with SMTP id 33so3873579yxt.31 for ; Mon, 20 Jun 2011 13:35:25 -0700 (PDT) Received: by 10.236.91.116 with SMTP id g80mr8931691yhf.165.1308602125291; Mon, 20 Jun 2011 13:35:25 -0700 (PDT) Received: from [192.168.2.100] (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id i30sm3792711yhm.49.2011.06.20.13.35.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Jun 2011 13:35:24 -0700 (PDT) References:

In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <7BFED6AD-195E-4901-A87D-B96CF762EEF8@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Date: Mon, 20 Jun 2011 15:35:21 -0500 To: "Worley, Dale R (Dale)" X-Mailer: Apple Mail (2.1084) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] 4244bis-05: Semantics of History-Info 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, 20 Jun 2011 20:35:27 -0000 On Jun 20, 2011, at 2:52 PM, Worley, Dale R (Dale) wrote: >=20 >=20 > But it seems like it would be useful to allow a proxy to insert = "Supported: histinfo" > into an outgoing request, as long as it purged the History-Info from = any response > it sent upstream. >=20 Perfectly doable. Such a "proxy" is called a back-to-back user agent. = The world is full of them. I personally don't use a SIP proxy anymore, = AFAIK, to drive my devices. There might be one at my TISP handling DID = routing. >=20 > [Suppose the UAC sends > "History-Info: AOR;index=3D1", and a non-History-Info-supporting = entity forks it > to two destinations, UAS A and UAS B, both of which support > History-Info. UAS A normalizes the request to "History-Info: > AOR;index=3D1, UAS-A;index=3D1.1" while UAS B normalizes the request = to > "History-Info: AOR;index=3D1, UAS-B;index=3D1.1".] >=20 > These two normalized requests violate the rule that everybody expects > to be satisfied, viz., that all hi-entries in the entire forking > structure with the same index represent the same request. As a > result, the responses from the two UASs cannot be merged in any useful > way. Since both UASs could send 1xx responses containing = History-Info, > the UAC can see two different hi-entries with index=3D1.1. >=20 >=20 Otherwise said, suppose a B2BUA has added "Supported: histinfo". If it = doesn't also add a first "History-Info", things can get hosed. Answer: = If you insert a Supported, insert an appropriate 1st index H-I. But what happens if there are two such b2buas, each deciding to add = "Supported: histinfo" along with index-1 records? Chaos ensues... > In section 9.1 are the rules to help in the case where a = H-I-supporting entity > receives a request from a non-H-I-supporting entity. As written, it = only discusses > the case where there is already an H-I header in the request. = Strictly speaking, > the algorithm given faults if there is no H-I header present. But = ISTR that we > intended that in this case, an hi-entry with index=3D1 should be = inserted by the receiving > entity. >=20 >=20 > [Also need to take care of the case where the UAC generates several > requests as forks of a theoretical ancestral request, as is used in > draft-ietf-bliss-call-completion. It seems like they should have > index=3D1, index=3D2, index=3D3, etc. But this does mean that the = "tree" now > has an invisible root node whose index is the empty string of = integers.] >=20 The problem is that we're used a numeric-sequenced tree for something = that has rather different cardinality. Perhaps if instead of "1", we used a tag that identified both the = inserter AND the ordinal sequence at that inserter relative to this = request? One could look at it as akin to the double-record-route problem for dual = homed proxies. -- Dean= From pkyzivat@cisco.com Mon Jun 20 13: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 40E0311E80AB for ; Mon, 20 Jun 2011 13:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.46 X-Spam-Level: X-Spam-Status: No, score=-110.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzb0x-KD5O9t for ; Mon, 20 Jun 2011 13:46:07 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 7612D11E80AF for ; Mon, 20 Jun 2011 13:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=1414; q=dns/txt; s=iport; t=1308602743; x=1309812343; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=yHNkadddula0gyVw/ScOsfx94B0LWnEObCKbyicfz2k=; b=gSvy9jBVKcLIvMVNMkIpqPIUDc79aTPcDzF+3ZSzCkN2uFpZM5qhYo8B 2vr3gkqpcRtX18P78dVWUuyGGu4a81pE9imJJ3afDOK7Y2vTRVBqxCtrG Ho1D5t8fCLAWZYuEGsJK6OAQkotyAe1JaOWgj5ORLSw63Mkv6cTV05E6c 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEyw/02tJXG9/2dsb2JhbABTpmV3iHOhc54chioEkV6EYIs9 X-IronPort-AV: E=Sophos;i="4.65,396,1304294400"; d="scan'208";a="717731585" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-6.cisco.com with ESMTP; 20 Jun 2011 20:45:42 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5KKjf9p031073; Mon, 20 Jun 2011 20:45:42 GMT Message-ID: <4DFFB175.5080507@cisco.com> Date: Mon, 20 Jun 2011 16:45:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christer Holmberg References: <4DEC205A.5040503@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E36022D@ESESSCMS0356.eemea.ericsson.se> <2FDD10D8-6DF3-4D77-B300-C05C2AB5D3A2@agnada.com> <7F2072F1E0DE894DA4B517B93C6A0585194E3E71BA@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3E71BA@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-sipcore-rfc4244bis@tools.ietf.org" , "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs , Shida Schubert , Robert Sparks Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis 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, 20 Jun 2011 20:46:08 -0000 (as individual) On 6/17/2011 3:25 AM, Christer Holmberg wrote: >>> 3. Tel to Sip transformation: History-Info (technical) >>> >>> Related to the previous question, the text doesn't indicate whether the transformation from Tel to Sip should be recorded in an History-Info header field. The Request-URI is, after all, >>> changed. >> >> >> I don't know if we need to add anything specific for this. The draft doesn't limit the >> behavior of the entity recording H-I to only record SIP-URI, it just says to record the >> R-URI. > > Based on the comments I get, the text seems to indicate that you shouldn't insert a Tel in a History-Info in the first place. Instead you should transform it to a SIP-URI before inserting it. I agree with Christer (!!!) that the transformation from tel: to sip: *is* a change, and if you care about H-I then this ought to be recorded. (This is not just a superficial change in representation - it is a *semantic* change, because different processing rules apply to sip URIs that tel URIs.) There isn't even a guarantee that a proxy will have a suitable way to re-represent a tel uri as a sip URI. So I think this calls for some sort of explanation. I guess its lucky that if you do create H-I entries for this, that its the translated (sip) URI that gets the parameters added. So its at least *possible* to do this. Thanks, Paul From aallen@rim.com Tue Jun 21 08:36: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 E1D7811E8148 for ; Tue, 21 Jun 2011 08:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvYznxfYYH94 for ; Tue, 21 Jun 2011 08:36:02 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0998911E807E for ; Tue, 21 Jun 2011 08:35:59 -0700 (PDT) X-AuditID: 0a412830-b7b5cae000000ee1-96-4e00ba4ab1d6 Received: from XCH139CNC.rim.net (xch139cnc.rim.net [10.65.10.235]) by mhs061cnc.rim.net (SBG) with SMTP id 1B.B9.03809.A4AB00E4; Tue, 21 Jun 2011 15:35:38 +0000 (GMT) Received: from XCH04ADS.rim.net ([10.67.10.91]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jun 2011 11:35:41 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC3028.DF9D6C3E" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 21 Jun 2011 10:35:39 -0500 Message-ID: <56DC300C52125F46BA19D2D5CCEC4D70011162C4@XCH04ADS.rim.net> In-Reply-To: <4DEC205A.5040503@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis thread-index: Acwj4WLMIxaV1i5ETwSDJeWbWUF+ngMRbVSg References: <4DEC205A.5040503@cisco.com> From: "Andrew Allen" To: "SIPCORE Chairs" , "SIPCORE (Session Initiation Protocol Core) WG" X-OriginalArrivalTime: 21 Jun 2011 15:35:41.0221 (UTC) FILETIME=[E09E7D50:01CC3028] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLKsWRmVeSWpSXmKPExsXC5cj1WtdrF4OfwfT9qhanXp1mtvj6YxOb A5PHkiU/mTy+XP7MFsAU1cBok5iXl1+SWJKqkJJanGyr5JOanpijEFCUWZaYXKngklmcnJOY mZtapKSQmWKrZKKkUJCTmJyam5pXYquUWFCQmpeiZMelgAFsgMoy8xRS85LzUzLz0m2VPIP9 dS0sTC11DZXsdJFAwj/ujC3fJzEV3O9grHiz/z5LA+OW4i5GTg4JAROJdY9usEHYYhIX7q0H srk4hARWMko8O/+YGSQhJNDHKHHuZzmIzSygJXHkUhMjiM0rIChxcuYTFoh4uMSsKQegBulJ LFs8BSwuLGAl8fl+OzuIzSKgKvHzwDXWLkYOoF53iVm/zUHCnAKaEoe7JrJDtApKLJq9hxnm nn+7HoKNFBGwlni4/hIThG0ksepKEyvEaRoSuyd8BathAxr/5vgGRoiaKolP0yBOExKQlthx cg0jxMxgib5TB5gmMIrOQvLNLCTfzELyzSygS5mBvmnbyAgR1pZYtvA1M4StK/H/+RxmZPEF jOyrGAVzM4oNzAyT85L1ijJz9fJSSzYxgpOKhsEOxgl7tQ4xCnAwKvHwlqxj8BNiTSwrrsw9 xCjBwawkwpu8FSjEm5JYWZValB9fVJqTWnyI0RUYbhOZpbiT84EJL68k3tjAADdHSZxXdMEc XyGBdGBiy05NLUgtgpnDxMEp1cC4w0Lq853iaS8vC9+3DXpgvfLh/xXKiZaL/U/Me/P4S//H wzsPLBAS43idfUlV5/aiPRxXhLlWLvRM31zx7S/Xu1CerZ1Fv5/V33P5ySfELnbkOtek/XOe dmt++zYlsDtmJ0fKr11rHj+u5dNt29RaaHRTPPzSvvR5rAtvmjV091U0+AZ27eE5rcRSnJFo qMVcVJwIAKPq33FQAwAA Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis 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, 21 Jun 2011 15:36:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC3028.DF9D6C3E Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Seems I missed the WGLC deadline by a day or so but here are the comments from my review: Section 5 "mp": The hi-targeted-to-URI represents a user other than the user associated with the Request-URI in the incoming request that was retargeted. The term "user" here is confusing. Does it mean the human user (who might have multiple AoRs/URIs which may or may not be known to the retargeting proxy as AoRs/URIs that all map to the same human user)? When retargeting is the proxy supposed to assess whether the new target URI represents the same human user or not in order to determine whether to include the "mp" parameter or not? I'm not sure what terminology would be best but I think "user" is likely to cause confusion. The above issue also reoccurs in section 7 Section 15 "Entities that have not implemented this specification MUST ignore these parameters"? We can't make any normative requirements on entities that have not implemented this specification! Therefore the MUST should be removed. I think you mean to state that according to RFC 3261 and RFC 4244 entities that are not compliant with this specification will ignore these parameters. There is a backward compatibility concern which I think should be addressed. With 4244bis the URI in the Request-URI is now clearly to be included in the History-Info when the Request-URI is replaced by the Contact address. This was not the case in RFC 4244 where in many (if not most) implementations rewriting the request-URI with the Contact was not considered retargeting. Some existing UA implementations may have assumed that the last History-Info entry cannot be their own Contact Address but will always be their AoR. For example a UA may only look at the next highest History-Info header field from the bottom most one in order to determine whether the call arrived as a result of forwarding or not from within their home domain and what the URI was that it was forwarded from. Since outside the home domain of the UA up to now the use of History-Info has not been deterministic some UAs may have only looked at the last couple of History-Info header fields in order to determine what happened to the request after it arrived within their domain. In these kinds of scenarios having a proxy now add an additional History-Info header field (for the rewriting of the Request-URI to the Contact) in 4244bis may break the logic of such UAs. I am not saying we shouldn't do this but I think some text about such possible problems with existing implementations should be indicated in the backwards compatibility section. Section B.1 In this example, the Office and Home are not the same AOR as sip:bob@example.com, but rather different AORs that have been configured as alternate addresses for Bob in the proxy. In other words, Office and Bob are not bound through SIP Registration with Bob's AOR. The opportunity is missed to explain here that this means that the "rc" parameter is not added. I think it would help to understand if that was highlighted. FLOW F1 INVITE sip:alice@example.com should be INVITE sip:bob@example.com FLOW F5 Request-URI for the ACK looks wrong to me shouldn't it be bob@192.0.2.4? FLOW F6 The URI in the Request-URI and the URI in the bottom most History-Info header field are not the same (R-URI =3D office@192.0.2.3 and H-I =3D office@192.0.2.5). These should be the same - suggest change R-URI to office@192.0.2.5 so as to avoid need to change H-I in the other flows and also since 192.0.2.3 is Alice's UA!!. FLOW F13 Again Request-URI for the ACK looks wrong to me shouldn't it be home@192.0.2.6? Examples in B.2 and B.3 do not have the same level of detail as in B.1 or RFC 4244. Editorials Last paragraph of 10.1 .2 "compenent" should be "component" First and 2nd paragraph of 10.3 "add an hi-index"/"adds an hi-entry" should be "a" not "an" Regards Andrew From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Sunday, June 05, 2011 7:34 PM To: SIPCORE (Session Initiation Protocol Core) WG Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org; SIPCORE Chairs; Robert Sparks Subject: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis [as co-chair] The current editor of draft-ietf-sipcore-rfc4244bis believes that the document has no remaining technical issues, and is ready for evaluation. Today, we are starting a two-week working group last call period. This last call period ends on Sunday, June 19. The latest version of the document can be retrieved here: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis Any comments on the document should be sent to the SIPCORE mailing list. Thanks, Paul --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_001_01CC3028.DF9D6C3E Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Seems I missed the WGLC deadline by a day or so but here are= the comments from my review:

Section 5

"mp": The hi-targeted-to-URI represents a user other than the

user associate= d with the Request-URI in the incoming request

that was retargeted.

The term “user” here is confusing. Does it= mean the human user (who might have multiple AoRs/URIs which may or may not be kn= own to the retargeting proxy as AoRs/URIs that all map to the same human user)? When retargeting is the proxy supposed to assess whether the new target URI represents the same human user or not in order to determine whether to inclu= de the “mp” parameter or not? I’m not sure what terminology would be best but I think “user” is likely to cause confusion.

The above issue also reoccurs in section 7

Section 15

“Entities tha= t have not implemented this specification MUST ignore these parameters”? We can’t make any normative requirements on entities that have not implemented this specification! Therefore the MUST should be removed. I thin= k you mean to state that according to RFC 3261 and RFC 4244 entities that are= not compliant with this specification will ignore these parameters.

There is a backward compatibility concern which I think should be addressed. With 4244bis the URI in the Request-URI is now clearly= to be included in the History-Info when the Request-URI is replaced by the Cont= act address. This was not the case in RFC 4244 where in many (if not most) implementations rewriting the request-URI with the Contact was not considere= d retargeting. Some existing UA implementations may have assumed that the last History-Info entry cannot be their own Contact Address but will always be th= eir AoR. For example a UA may only look at the next highest History-Info header field from the bottom most one in order to determine whether the call arrive= d as a result of forwarding or not from within their home domain and what the= URI was that it was forwarded from. Since outside the home domain of the UA up t= o now the use of History-Info has not been deterministic some UAs may have onl= y looked at the last couple of History-Info header fields in order to determin= e what happened to the request after it arrived within their domain. In these kinds of scenarios having a proxy now add an additional History-Info header field (for the rewriting of the Request-URI to the Contact) in 4244bis may break the logic of such UAs. I am not saying we shouldn’t do this but= I think some text about such possible problems with existing implementations should be indicated in the backwards compatibility section.

=
Section B.1

In this example, the Office=
 and Home are not the

same A= OR as sip:bob@example.com, but rather different AORs that have

   been configured as alternate addresses for Bob in the proxy. In<= /span>

   other= words, Office and Bob are not bound through SIP Registration<= /p>
with Bob's AOR.

The opportunity is missed to explain here that this mea= ns that the “rc” parameter is not added. I think it would help to understand if that was highlighted.

FLOW F1

INVITE sip:alice@exam= ple.com   should be INVITE sip:bob@example.com

FLOW F5

Request-URI for the ACK looks wrong to me shouldn’= ;t it be bob@192.0.2.4?

FLOW F6

The URI in the Request-URI and the URI in the bottom mo= st History-Info header field are not the same (R-URI =3D office@192.0.2.3 and H-I =3D office@192.0.2.5). These should be the= same – suggest change R-URI to office@1= 92.0.2.5 so as to avoid need to change H-I in the other flows and also since 192.0.2.= 3 is Alice’s UA!!.

FLOW F13

Again Request-URI for the ACK looks wrong to me shouldn’t it be home@192.0.2.6?<= o:p>

Examples in B.2 and B.3 do not have the same level of d= etail as in B.1 or RFC 4244.

Editorials

Last paragraph of 10.1 .2 “compenent” shoul= d be “component”

First and 2^nd paragraph of 10.3 “add a= n hi-index”/”adds an hi-entry” should be “a” not “an”

Regards

Andrew

From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: Sunday, June 05, 2011 7:34 PM
To: SIPCORE (Session Initiation Protocol Core) WG
Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org; SIPCORE Chairs; Rob= ert Sparks
Subject: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis

[as co-chair]

The current editor of draft-ietf-sipcore-rfc4244bis believes that the docume= nt has no remaining technical issues, and is ready for evaluation. Today, we ar= e starting a two-week working group last call period. This last call period en= ds on Sunday, June 19.

The latest version of the document can be retrieved here:

http://= tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis

Any comments on the document should be sent to the SIPCORE mailing list.

   Thanks,
   Paul

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_001_01CC3028.DF9D6C3E-- From fluffy@cisco.com Tue Jun 21 16: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 88C3421F851C for ; Tue, 21 Jun 2011 16:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.591 X-Spam-Level: X-Spam-Status: No, score=-110.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCBgdkZh4VF9 for ; Tue, 21 Jun 2011 16:07:30 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA2321F8515 for ; Tue, 21 Jun 2011 16:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=291; q=dns/txt; s=iport; t=1308697641; x=1309907241; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=C9GBOBcy/OHJilYbBEV04xChLJ4mn7w1AybKprSrGpo=; b=NU9Yim7OIlbKshpaEXeH9qddqtwScMNmUL/+IjB9Sdwa+vpPTxitij1y Im1T+Sw/spWik12PVSLXeb/JHWFXAwmP+PZ7rd3F8vA5BiaEqkyOgk09m GKYGczrGZFWOMl3JrqCPzw4ZUaYZwiG2XhN2bxOgk/Spod5zsIuUR06U1 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIMjAU5Io8UT/2dsb2JhbABHDacGd4hzoVaeIIMegwwEhyKKRJAm Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 21 Jun 2011 23:07:19 +0000 Received: from dhcp-171-68-21-143.cisco.com (dhcp-171-68-21-143.cisco.com [171.68.21.143]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5LN7G2f014374; Tue, 21 Jun 2011 23:07:18 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <88801004-2367-4BE3-8564-3228A279B9E1@acmepacket.com> Date: Tue, 21 Jun 2011 16:07:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7A463F33-4115-4E9D-8D1C-C8F49BA9CFDD@acmepacket.com> <7E5B50A1-81D0-433A-BAEF-F7B9037F4691@ntt-at.com> <88801004-2367-4BE3-8564-3228A279B9E1@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) Cc: "sipcore@ietf.org WG" Subject: Re: [sipcore] 4244bis-05: the infamous "rc" param 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, 21 Jun 2011 23:07:30 -0000 On Jun 17, 2011, at 9:07 , Hadriel Kaplan wrote: > What "rc" should actually stand for is "Request-uri Changed". It = should be populated in ALL cases where the request-URI is changed, but = where the new target is still the same identity (ie, it's not an "mp" = tag instead), +1 From fluffy@cisco.com Tue Jun 21 16:09: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 5349821F853A for ; Tue, 21 Jun 2011 16:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.592 X-Spam-Level: X-Spam-Status: No, score=-110.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0R6BnBdrKSZ for ; Tue, 21 Jun 2011 16:09:07 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id CBBE521F8528 for ; Tue, 21 Jun 2011 16:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3194; q=dns/txt; s=iport; t=1308697735; x=1309907335; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=aD8fiiiy51MMGx6QIYXNtxGG/kojXx1YO8GohQszb2E=; b=j7uww7YnwnmixO0N51e5SQQoGvaIxsjgtj3G+yvsxXQrWZtZiV8OHnk1 Si+YOkwKmrTSfDypnmCEN14P3KQpBFrIQEmLUu47fDx2oj+58ZMIID+Oe 7ycxBsszIXLJHF/Xh21s2hlEJS9WfXpwF3dMEg/ZbWqPOaLEnrtVjZScC o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHEjAU6rRDoJ/2dsb2JhbABUpwZ3qkmeIIYqBIciikSQJg X-IronPort-AV: E=Sophos;i="4.65,403,1304294400"; d="scan'208";a="466588470" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 21 Jun 2011 23:08:55 +0000 Received: from dhcp-171-68-21-143.cisco.com (dhcp-171-68-21-143.cisco.com [171.68.21.143]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5LN8t6D002944; Tue, 21 Jun 2011 23:08:55 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <4DEC205A.5040503@cisco.com> Date: Tue, 21 Jun 2011 16:08:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2C58A5B7-9EDE-4774-80B6-CE839EF59ACF@cisco.com> References: <4DEC205A.5040503@cisco.com> To: "sipcore@ietf.org WG" X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis 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, 21 Jun 2011 23:09:08 -0000 Privacy issue: There is no way to know that the next downstream proxy = support the processing required by the privacy header.=20 What's this for: The most concrete use is making sure a call arriving at = a voice mail servers goes to the correct mailbox. However, the draft is = woefully underspecified to be able to implement this from the draft. = This draft specifies a bunch of data that can get dumped in a bag, but = to allow interoperable implementation, it needs to say how one could use = that data for some actually feature.=20 As a coauthor of 4244, I agree this draft is better than 4244 but I = don't think it is ready to publish.Given what we have learned about 4244 = since it was published, I would support 4244 being changed to historic.=20= Does it work? Consider text such as =20 Note, this would be the original AoR if all the entities involved support the History-info header field and there is absence of an "mp" header field parameter prior to the "rc" header field parameter in the hi-target-param in the History-info header field. However, there is no guarantee that all entities will support History-Info, thus the hi-entry that matches the value of the "rc" parameter of the first hi-entry with an "rc" parameter in the hi-target-param within the domain associated with the target URI at the destination is more likely to be useful. This amounts to you might some information you want at X but then again = you might not. The whole draft is like this - it's pretty hard to = imagine this will reliably work for nearly any purpose I can think of = given the limitations of the draft.=20 Backwards Compatibly - yes the syntax is backwards compatible but no = effort has been put into consider what would happen if some elements in = the network were doing 4244 and some where doing 4244bis. Implementations: I'd like to know about implementations that were going = to use this data. And by use, I don't mean write to the history header = but instead ones that are going to read from it and use the information = for some purpose.=20 Does not meet requirements. As far as I can tell, the draft does not = meet the requirements outline in section A.1 of the draft.=20 On Jun 5, 2011, at 17:33 , Paul Kyzivat wrote: > [as co-chair] >=20 > The current editor of draft-ietf-sipcore-rfc4244bis believes that the = document has no remaining technical issues, and is ready for evaluation. = Today, we are starting a two-week working group last call period. This = last call period ends on Sunday, June 19. >=20 > The latest version of the document can be retrieved here: >=20 > http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis >=20 > Any comments on the document should be sent to the SIPCORE mailing = list. >=20 > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Tue Jun 21 16:21: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 9063511E80A6 for ; Tue, 21 Jun 2011 16:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.592 X-Spam-Level: X-Spam-Status: No, score=-110.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92kFspkiCDsb for ; Tue, 21 Jun 2011 16:21:32 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 31A6E11E8083 for ; Tue, 21 Jun 2011 16:21:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1086; q=dns/txt; s=iport; t=1308698492; x=1309908092; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=UTRPCISvtV+10Vs/djuuDPVcWaxsDr/MInIaJxJPPtM=; b=L1zE6U9kCmyoN0PaF6Ww2+5Nt3V/AJrnV5Punwzs+GUwIynV0sNaOaMg 37DcGbwlWxJcnJefL3oFpLagVDIeRNY9UaGvBe9oWHQAvWpdIBcgL/TKZ TvBCFjJ8+gmgGXoiZGm0wIzxmZtD3mZutgP4hwD3gF5V/hdAO28jILb8L Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPwmAU5Io8UR/2dsb2JhbABUpwZ3iHOhfJ4ghioEhyKKRJAm X-IronPort-AV: E=Sophos;i="4.65,403,1304294400"; d="scan'208";a="95708867" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 21 Jun 2011 23:21:30 +0000 Received: from dhcp-171-68-21-143.cisco.com (dhcp-171-68-21-143.cisco.com [171.68.21.143]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5LNLR0F026990 for ; Tue, 21 Jun 2011 23:21:28 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Cullen Jennings In-Reply-To: <14FFF078-E5D1-45F2-8D9A-AD52DE677CEF@cisco.com> Date: Tue, 21 Jun 2011 16:21:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <14FFF078-E5D1-45F2-8D9A-AD52DE677CEF@cisco.com> To: "sipcore@ietf.org WG" X-Mailer: Apple Mail (2.1084) Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis 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, 21 Jun 2011 23:21:36 -0000 I still feel the same as my email from last nov ... On Nov 11, 2010, at 1:41 , Cullen Jennings wrote: >=20 > The draft has a lot well specified procedures about how to write tags = to a message, and it discusses that the tags could be used in lots of = ways. However, I would like to see some text added to section 8 that = allowed implementers to use this specification to implemented some of = the use cases it is designed to meet. Specifically I would like to see = normative language on how a voicemail system can use the tags found in = an incoming invite to determined which mailbox the call should be = delivered too.=20 >=20 > People have suggested to me this information is in the call flows = document. I like call flows, I think they help people, but this is an = information document with no normative language describing how to do = this. I'm not a huge fan of people implementing things off call flows. I = rather have the procedures for this specified in 4244bis and then have = example call flows that illustrated this in the call flow draft.=20 From dworley@avaya.com Wed Jun 22 12:51: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 2B7FA21F8440 for ; Wed, 22 Jun 2011 12:51:56 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kF2vc4LBChLR for ; Wed, 22 Jun 2011 12:51:55 -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 2CF6011E80EC for ; Wed, 22 Jun 2011 12:51:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANRFAk6HCzI1/2dsb2JhbABTpxF3iHOlFQKbaYYtBJZsiyY X-IronPort-AV: E=Sophos;i="4.65,407,1304308800"; d="scan'208";a="194724537" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 Jun 2011 15:51:53 -0400 X-IronPort-AV: E=Sophos;i="4.65,407,1304308800"; d="scan'208";a="669004014" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Jun 2011 15:51:53 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 22 Jun 2011 15:51:52 -0400 From: "Worley, Dale R (Dale)" To: Cullen Jennings , "sipcore@ietf.org WG" Date: Wed, 22 Jun 2011 15:50:10 -0400 Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis Thread-Index: Acwwafu0W2/fwWoVTcePQf4dK+MY7QAq5vxD Message-ID: References: <14FFF078-E5D1-45F2-8D9A-AD52DE677CEF@cisco.com>, 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] draft-barnes-sipcore-rfc4244bis 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, 22 Jun 2011 19:51:58 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Cull= en Jennings [fluffy@cisco.com] > However, I would like to see some text added to section 8 that allowed im= plementers to use this specification to implemented some of the use cases i= t is designed to meet. Specifically I would like to see normative language = on how a voicemail system can use the tags found in an incoming invite to d= etermined which mailbox the call should be delivered too. _______________________________________________ Most importantly, presenting algorithms for the use cases allows the reader= to verify that the mechanism does accomplish what it was designed to do, a= nd that there are not peculiar cases where the mechanism fails. Dale From dworley@avaya.com Wed Jun 22 13:09: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 1218311E8167 for ; Wed, 22 Jun 2011 13:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hB9HPXUslE6 for ; Wed, 22 Jun 2011 13:09: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 3337F11E8181 for ; Wed, 22 Jun 2011 13:08:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4GAAJLAk6HCzI1/2dsb2JhbABTm0eLSneuCgKbaIYtBJZshCqGfA X-IronPort-AV: E=Sophos;i="4.65,407,1304308800"; d="scan'208";a="194727150" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 22 Jun 2011 16:08:43 -0400 X-IronPort-AV: E=Sophos;i="4.65,407,1304308800"; d="scan'208";a="669009770" 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; 22 Jun 2011 16:08:38 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 22 Jun 2011 16:08:37 -0400 From: "Worley, Dale R (Dale)" To: Mary Barnes , SIPCORE Date: Wed, 22 Jun 2011 16:06:46 -0400 Thread-Topic: [sipcore] Updates to 4244bis-05 Thread-Index: AcwF61oW8jPK+0nmRMOovHk3R8XFYArLI+IV 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 Cc: SIPCORE Chairs , Shida Schubert Subject: Re: [sipcore] Updates to 4244bis-05 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, 22 Jun 2011 20:09:01 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Mary= Barnes [mary.ietf.barnes@gmail.com] 2) Updated section 9.3 (receiving responses) to also include timeouts and u= pdated to reflect that we don't add the Reason header in the case of 2xx re= sponses. ________________________________________ Can you tell me the design considerations for why Reason is not used in the= case of 2xx responses? (Is it for backward compatibility?) Dale From dworley@avaya.com Wed Jun 22 13:47: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 20DA421F857B for ; Wed, 22 Jun 2011 13:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.418 X-Spam-Level: X-Spam-Status: No, score=-103.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xASFS6w3L7RA for ; Wed, 22 Jun 2011 13:47:07 -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 4A6BE21F857A for ; Wed, 22 Jun 2011 13:47:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAB9UAk7GmAcF/2dsb2JhbABTpxF3iHOlFwKbY4YtBJZsiyY X-IronPort-AV: E=Sophos;i="4.65,407,1304308800"; d="scan'208";a="286505961" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Jun 2011 16:47:06 -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; 22 Jun 2011 16:46:40 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 22 Jun 2011 16:47:05 -0400 From: "Worley, Dale R (Dale)" To: Hadriel Kaplan , "sipcore@ietf.org WG" Date: Wed, 22 Jun 2011 16:47:05 -0400 Thread-Topic: 4244bis-05: additional technical comments Thread-Index: AcwrmPf5m+md7tDbQPehEG90d3slFAFgcx4E Message-ID: References: <3B2A8F8E-4255-4156-B882-BF68F4046F3D@acmepacket.com> In-Reply-To: <3B2A8F8E-4255-4156-B882-BF68F4046F3D@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 Cc: "draft-ietf-sipcore-rfc4244bis@tools.ietf.org" Subject: Re: [sipcore] 4244bis-05: additional technical comments 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, 22 Jun 2011 20:47:08 -0000 Thanks for writing this, as both points you made lead me to realize errors I was making! > From: Hadriel Kaplan [HKaplan@acmepacket.com] >=20 > 1) Section 10.3, page 19, says: > In the case that a SIP entity (intermediary or UAS) adds an hi-entry > on behalf of the previous hop, the hi-index MUST be set to 1. >=20 > Taken literally, this means when a request already marked with H-I > entries happens to cross a legacy non-HI system, the next downstream > element will add an additional H-I entry starting at 1 again. Is that > intentional/on-purpose?? At first I thought this was just an > editorial mistake, but section 11, page 22, says : >=20 > Gaps are possible if the request is forwarded through > intermediaries that do not support the History-info header field and > are reflected by the existence of multiple hi-entries with an index > of "1". >=20 > So a single SIP request can actually have multiple H-I trees with > multiple root indexes of 1? Wouldn't this make UAS logic code more > complicated, because now the "mp=3DX" and "rc=3DX" index values are > relative "X" values, scoped to within their particular tree, as > opposed to being an absolute number for the whole H-I list? I had mis-read this to mean that the receiving entity would construct an H-I entry on behalf of the previous hop by adding a new H-I entry with index "[whatever].1", that is, the entry the previous hop would have added, had it forwarded to only one destination. But that's not what the draft says, the draft says that the new index is just "1". Given the specifications, that new H-I entry must be the child of the immediately preceeding H-I entry, so the H-I header is not ambiguous. But it does destroy the principle that the three of H-I entries is described simply by the index values. > 2) Section 9.4, page 16 says: > When sending a response other than a 100, a SIP entity MUST include > all the cached hi-entries in the response, subject to the privacy > consideration in Section 10.1.2 with the following exception: If the > received request contained no hi-entries and there is no "histinfo" > option tag in the Supported header field, the SIP entity MUST NOT > include hi-entries in the response. >=20 > Note the "If the received request contained no hi-entries and...". I > don't know what having H-I entries has to do with it. We have an > option-tag for this purpose: histinfo. If the option-tag is in the > Supported, then you can send H-I entries in response. Else not. Even > if the request contained H-I entries but no "histinfo" option tag, you > can't send 'em back. (e.g., such would be the case if proxies added > the entries but the UAC does not support it) Hmm, I would be inclinded to agree with you, but, as written, the draft solves a "problem" I was wondering about: phone A (no H-I supt.) --> proxy B (H-I supt.) --> proxy C (H-I) --> phone = D (H-I) Phone A does not insert H-I in the request. Proxy B inserts H-I in the request to proxy C: One entry, index 1, containing the original request-URI, and a second entry, index 1.1, containing the request-URI it sends to proxy C. Proxy C inserts H-I in the request to phone D: index 1.1.1, containing the request-URI it sends to phone D. Phone D copies the H-I into its response -- because it received H-I in the request (which implies that some upstream entity can understand the H-I). Proxy C copies the H-I into its response, adding Reason to index 1.1.1 -- because it received H-I in the request. Proxy B *does not* include H-I in its response. The absence of "Supported: histinfo" and an incoming H-I in its request shows that no upstream entity understands H-I. Phone A receives a response without H-I, as it expected. This arrangement satisfies these requirements: 1) No phone will receive H-I in a response if it does not support it. Thus, no pre-H-I phone will receive a response that is unexpectedly large. 2) Every H-I-aware entity will receive H-I information from every upstream and downstream entity H-I-aware entity. An implication of this is that "Supported: histinfo" is redundant and can be eliminated from the protocol; a phone can indicate whether or not it supports H-I by whether it includes a History-Info header. Dale From dworley@avaya.com Wed Jun 22 13:53: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 4BA7121F85AA for ; Wed, 22 Jun 2011 13:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.425 X-Spam-Level: X-Spam-Status: No, score=-103.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCOd+-xnEJbq for ; Wed, 22 Jun 2011 13:53:02 -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 78D7821F8583 for ; Wed, 22 Jun 2011 13:53:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsGABZVAk6HCzI1/2dsb2JhbABTpxFwB6okg2wCm2OGLQSWbIsm X-IronPort-AV: E=Sophos;i="4.65,407,1304308800"; d="scan'208";a="252826201" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Jun 2011 16:53:00 -0400 X-IronPort-AV: E=Sophos;i="4.65,407,1304308800"; d="scan'208";a="669025165" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 22 Jun 2011 16:53:00 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 22 Jun 2011 16:52:59 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Wed, 22 Jun 2011 16:52:59 -0400 Thread-Topic: 4244bis-05: Multiple forks from the UA Thread-Index: AQHMMR5e3kUkvCmI9kWt/lfYmZTAIg== 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] 4244bis-05: Multiple forks from the UA 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, 22 Jun 2011 20:53:03 -0000 In regard to the "root" of the History-Info tree, as the draft is written, = we are already requiring the possibility of H-I entries with indexes "2", "3", etc., that = is, siblings of the entry "1" that the phone creates. How? The phone may receive a 3xx response to its first request. Per the r= ules of the draft, the new requests generated due to a 3xx response to request "= 1" are siblings of request "1", and so are numbered "2", "3", etc. One consequence of this is that if we consider the H-I entries as nodes in = a tree, we have to allow that the root of the tree is *not* represented by an= H-I entry, and that the H-I entries with single integer index-vals are children of the= root. Another consequence is that this technical problem is solved: [Also need to take care of the case where the UAC generates several requests as forks of a theoretical ancestral request, as is used in draft-ietf-bliss-call-completion. It seems like they should have index=3D1, index=3D2, index=3D3, etc.] Since entries "1", "2", "3", etc. can be generated by normal redirection, H= -I processing software should not get confused when a UA generates more than one initial = fork. Dale From dworley@avaya.com Thu Jun 23 09:37: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 D95E111E8174 for ; Thu, 23 Jun 2011 09:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMBEi6enq4dd for ; Thu, 23 Jun 2011 09:37:52 -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 5143E11E8161 for ; Thu, 23 Jun 2011 09:37:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAE5rA06HCzI1/2dsb2JhbABSpyh3iHOkLAKbWYYtBJZ0iyg X-IronPort-AV: E=Sophos;i="4.65,414,1304308800"; d="scan'208";a="194877638" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 23 Jun 2011 12:37:45 -0400 X-IronPort-AV: E=Sophos;i="4.65,414,1304308800"; d="scan'208";a="669331693" 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; 23 Jun 2011 12:37:45 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 23 Jun 2011 12:37:45 -0400 From: "Worley, Dale R (Dale)" To: "Worley, Dale R (Dale)" , Hadriel Kaplan , "sipcore@ietf.org WG" Date: Thu, 23 Jun 2011 12:37:45 -0400 Thread-Topic: 4244bis-05: additional technical comments Thread-Index: AcwrmPf5m+md7tDbQPehEG90d3slFAFgcx4EACoWqCw= Message-ID: References: <3B2A8F8E-4255-4156-B882-BF68F4046F3D@acmepacket.com>, 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 Cc: "draft-ietf-sipcore-rfc4244bis@tools.ietf.org" Subject: Re: [sipcore] 4244bis-05: additional technical comments 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, 23 Jun 2011 16:37:53 -0000 > From: Worley, Dale R (Dale) [dworley@avaya.com] >=20 > An implication of this is that "Supported: histinfo" is redundant and > can be eliminated from the protocol; a phone can indicate whether or > not it supports H-I by whether it includes a History-Info header. Ah, but in 4244, a UAC can include "Supported: histinfo" *without* also adding History-Info. So "Supported: histinfo" is required for backward compatibility with 4244. Dale From shida@ntt-at.com Fri Jun 24 05:16: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 4E6B59E8007 for ; Fri, 24 Jun 2011 05:16:53 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V+WohhTqHxkW for ; Fri, 24 Jun 2011 05:16:52 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 88C009E8005 for ; Fri, 24 Jun 2011 05:16:52 -0700 (PDT) Received: from flh1agj244.tky.mesh.ad.jp ([125.192.75.244]:49761 helo=[192.168.11.3]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qa5JY-00015b-PA; Fri, 24 Jun 2011 07:16:49 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <88801004-2367-4BE3-8564-3228A279B9E1@acmepacket.com> Date: Fri, 24 Jun 2011 21:16:49 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7A463F33-4115-4E9D-8D1C-C8F49BA9CFDD@acmepacket.com> <7E5B50A1-81D0-433A-BAEF-F7B9037F4691@ntt-at.com> <88801004-2367-4BE3-8564-3228A279B9E1@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) 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: flh1agj244.tky.mesh.ad.jp ([192.168.11.3]) [125.192.75.244]:49761 X-Source-Auth: shida@agnada.com X-Email-Count: 9 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sipcore@ietf.org WG" Subject: Re: [sipcore] 4244bis-05: the infamous "rc" param 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, 24 Jun 2011 12:16:53 -0000 Hadriel; So you are suggesting to change the semantics so=20 "rc" will be used for any retarget where R-URI is modified=20 while the target of the R-URI represents the same user? And to use "mp" as defined currently, which is when=20 R-URI is changed and the target of the R-URI represents=20 a different user.=20 I thought about this a bit and it will solve some issues=20 relating to RFC4244. As RFC4244 doesn't add "rc",=20 4244bis compliant UAS would assume the entry without=20 "rc" to be "not registered via REGISTER", making the=20 semantics of "rc" even less relevant.=20 So I think this is a good idea to change the semantics of=20 "rc".=20 Regards Shida On Jun 18, 2011, at 1:07 AM, Hadriel Kaplan wrote: >=20 > I was one of the ones arguing for reducing/removing the other tags as = "fluff", but that included removing the "rc" tag. That was because, at = the time there was an "aor" tag - the "aor" and "mp" tags were the only = ones actually used by receiving UAS applications, so the other tags just = add confusion. =20 >=20 > Now there is no "aor" tag, because it's incredibly difficult for a = system to know when a URI is an "Address of Record". But having the = "rc" tag doesn't solve the problem - it just moves it around. Now you're = just *implying* the entry before the "rc" tagged one is an AoR, which is = just as error prone as before. >=20 > It's error-prone because: > 1) It will have false-positives - cases where the entry prior to the = "rc" tagged one is not the one the application actually wants. > 2) It will have false-negatives - cases where there is no "rc" tag = because the UAS did not use Registration model to receive a request, or = the intermediate proxy/ies did not know that it was due to a = registration. >=20 > My point is that the real purpose of using History-Info and having = these tags is to enable applications on the UAS. Some of those = applications need to find target URIs that were changed along the way. = *Why* they were changed matters, but not *how* they were changed. = Whether it was due to a SIP-Registration database, ENUM database, LDAP = lookup, or reading tea leaves doesn't matter. >=20 > What "rc" should actually stand for is "Request-uri Changed". It = should be populated in ALL cases where the request-URI is changed, but = where the new target is still the same identity (ie, it's not an "mp" = tag instead), and it should still use an index to point to the previous = H-I entry it changed from as it does now. >=20 > -hadriel >=20 >=20 > On Jun 16, 2011, at 3:41 AM, Shida Schubert wrote: >=20 >> I don't recall exactly why we decided to limit the scope of "rc".=20 >>=20 >> I vaguely remember the debate on allowing "rc" to be used for = resolution=20 >> beside the current intended context, resulting in convoluting the=20 >> tag and overloading it making it indeterministic. I think it was = about non-REGISTER=20 >> could raise the question of "How do you know that it was for = AoR-to-Contact resolution?".=20 >>=20 >> For example when barnes-sipcore-rfc4244bis-02 has 4 tags of which=20 >> "cc" covers the cases you expressed the concerns for, but I can't = recall=20 >> the exact reason why we limited the scope.=20 >>=20 >> "rc": The entry is a contact that is bound to an AOR in an >> abstract location service. The AOR-to-contact binding has = been >> placed into the location service by a SIP Registrar that >> received a SIP REGISTER request. >>=20 >> * "cc": The entry is a contact that is bound to an AOR in an >> abstract location service. The AOR-to-contact binding has = been >> placed into the location service implicitly through a means >> other than a SIP Registrar acting on a REGISTER request, e.g., >> the user may be currently logged into a Web Portal that >> implements a Presence and IM service, or it could be manually >> configured. >>=20 >> * "mp": The entry is a URI that represents another user. This >> occurs in cases where a request is statically or dynamically >> retargeted to another user. >>=20 >> * "rt": The entry is "routed", i.e., it is either a no-op like a >> proxy forwarding, predetermined by a maddr in the Request-URI, >> or the Request-URI is changed to a new URI that represents the >> same user, and is not a contact in a SIP Registrar. >>=20 >> By the time it was revised to 03 the tag was reduced to the two we=20 >> currently have. So there was a conclusion made sometime between the=20= >> 02 and 03.=20 >>=20 >> I personally don't have a strong opinions on this and would be happy = to change=20 >> the definition of the "rc" tag but I wasn't the one who raised the = concerns, so I think=20 >> we need to find those that lead us to the current status on this = issue..=20 >>=20 >> Regards >> Shida >>=20 >> On Jun 16, 2011, at 4:52 AM, Hadriel Kaplan wrote: >>=20 >>> Howdy, >>> I still have concerns regarding the "rc" param in this draft. Right = now, the "rc" is only added for request-uri retargeting due to = AoR-to-contact resolution, populated by a SIP Registrar from a REGISTER. = That's it. So "rc" is not added due to static/provisioned = Aor-to-contact mappings, for example. Nor is it added due to ENUM = resolution. Nor, apparently, if the Proxy doing the routing doesn't = know how the database's entry was populated. >>>=20 >>> So... why does it matter how the abstract location database got = populated? Example applications in this draft, as well as in = rfc4244bis-callflows, apparently rely on the existence of an "rc" param = to perform their logic. Afaict, however, it's NOT the case that they = actually care whether it was due to a REGISTER or not. They only care = about finding the first or last relevant URI they understand. >>>=20 >>> For example: in a sip trunking context, a la Martini-GIN, request = routing to GIN-PBX bulk-registered contacts would get the "rc". But = request routing to PBX's UAs using 3263 or static provisioning would = not. Should the application service logic or behavior be different for = these different ways of deploying SIP trunks? >>>=20 >>> -hadriel >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >=20 From shida@ntt-at.com Fri Jun 24 05:16: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 ABAEE9E803F for ; Fri, 24 Jun 2011 05:16:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmhSdNROf4d6 for ; Fri, 24 Jun 2011 05:16:55 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8E19E8018 for ; Fri, 24 Jun 2011 05:16:55 -0700 (PDT) Received: from [125.192.75.244] (port=49761 helo=[192.168.11.3]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qa5JP-00015b-TW; Fri, 24 Jun 2011 07:16:40 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <4DFFB175.5080507@cisco.com> Date: Fri, 24 Jun 2011 21:16:37 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <56BD4DB5-2808-4EA5-BF44-BEC1E5AB0874@ntt-at.com> References: <4DEC205A.5040503@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E36022D@ESESSCMS0356.eemea.ericsson.se> <2FDD10D8-6DF3-4D77-B300-C05C2AB5D3A2@agnada.com> <7F2072F1E0DE894DA4B517B93C6A0585194E3E71BA@ESESSCMS0356.eemea.ericsson.se> <4DFFB175.5080507@cisco.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.1084) 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: flh1agj244.tky.mesh.ad.jp ([192.168.11.3]) [125.192.75.244]:49761 X-Source-Auth: shida@agnada.com X-Email-Count: 7 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org, Robert Sparks , "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis 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, 24 Jun 2011 12:16:55 -0000 Paul; Are you suggesting to include three hi-entries,=20 whenever an entity retargeting the tel-URI=20 logs it to H-I? e.g.=20 History-Info : ;index=3D1 History-Info : ; index=3D1.1; mp=3D1= =20 History-Info : ;index=3D1.2, rc=3D1.1=20 (based on the new semantics Hadriel suggested) In that case, how do you think the privacy of the tel URI=20 should be handled?=20 Should the proxy apply the same privacy policy that it would=20 apply to the SIP URI?=20 Regards Shida On Jun 21, 2011, at 5:45 AM, Paul Kyzivat wrote: > (as individual) >=20 > On 6/17/2011 3:25 AM, Christer Holmberg wrote: >=20 >>>> 3. Tel to Sip transformation: History-Info (technical) >>>> =09 >>>> Related to the previous question, the text doesn't indicate whether = the transformation from Tel to Sip should be recorded in an History-Info = header field. The Request-URI is, after all, >>>> changed. >>> =09 >>>=20 >>> I don't know if we need to add anything specific for this. The draft = doesn't limit the >>> behavior of the entity recording H-I to only record SIP-URI, it just = says to record the >>> R-URI. >>=20 >> Based on the comments I get, the text seems to indicate that you = shouldn't insert a Tel in a History-Info in the first place. Instead you = should transform it to a SIP-URI before inserting it. >=20 > I agree with Christer (!!!) that the transformation from tel: to sip: = *is* a change, and if you care about H-I then this ought to be recorded. >=20 > (This is not just a superficial change in representation - it is a = *semantic* change, because different processing rules apply to sip URIs = that tel URIs.) >=20 > There isn't even a guarantee that a proxy will have a suitable way to = re-represent a tel uri as a sip URI. >=20 > So I think this calls for some sort of explanation. I guess its lucky = that if you do create H-I entries for this, that its the translated = (sip) URI that gets the parameters added. So its at least *possible* to = do this. >=20 > Thanks, > Paul From shida@ntt-at.com Fri Jun 24 05:40: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 B840F11E80CB for ; Fri, 24 Jun 2011 05:40:12 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EzzVef+Lge9 for ; Fri, 24 Jun 2011 05:40:12 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3E39011E80BB for ; Fri, 24 Jun 2011 05:40:12 -0700 (PDT) Received: from flh1agj244.tky.mesh.ad.jp ([125.192.75.244]:49761 helo=[192.168.11.3]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qa5KQ-00015b-Mh; Fri, 24 Jun 2011 07:17:43 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E3E71BA@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 24 Jun 2011 21:17:42 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <7EC88632-C52C-4517-BFBD-271880636396@ntt-at.com> References: <4DEC205A.5040503@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E36022D@ESESSCMS0356.eemea.ericsson.se> <2FDD10D8-6DF3-4D77-B300-C05C2AB5D3A2@agnada.com> <7F2072F1E0DE894DA4B517B93C6A0585194E3E71BA@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) 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: flh1agj244.tky.mesh.ad.jp ([192.168.11.3]) [125.192.75.244]:49761 X-Source-Auth: shida@agnada.com X-Email-Count: 30 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "draft-ietf-sipcore-rfc4244bis@tools.ietf.org" , "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs , Robert Sparks Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis 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, 24 Jun 2011 12:40:12 -0000 Hi Christer; Comments inline. =20 On Jun 17, 2011, at 4:25 PM, Christer Holmberg wrote: >=20 > Hi Shida,=20 > =20 >>> 1. Usage of "rc" and "mp" in Contact header field (technical) >>> =20 >>> The document defines the "rc" and "mp" parameters also for the = Contact header field. However, it is unclear when and how the parameters = would be used in a Contact header field. >>>=20 >>=20 >> I think this is already described in the section 10.4.=20 >>=20 >> "In the latter case, the specific header parameter field in the = Contact >> header becomes the header field parameter that is used in the = hi- >> target-param in the hi-entry when the request is retargeted." >=20 > The text says what you use it for, but not how it was inserted in the = Contact in the first place. Okay, I see your point. We will need to add a text with regards to this = in the=20 section describing the behavior of the redirection server.=20 >=20 > ---------- >=20 >>> 2. Tel to Sip transformation: ENUM (technical) >>> =20 >>> Section 5 talks about transformation from Tel to Sip, according = section 19.6.1 of RFC 3261. However, the transformation can also be the = result of an ENUM DNS lookup. So, maybe some text should=20 >>> be added, indicating that the transformation can be done based on = local configuration (the hostpart of the new SIP-URI needs to be taken = from somewhere), or based on an ENUM DNS lookup. >>=20 >> Are you talking about adding target-param based on ENUM lookup or = simply recording the transformation/resolution in H-I?=20 >=20 > Both. >=20 >> Anyway, do you want to suggest some text as a co-author of the draft? = :-) >=20 > Sure :)=20 >=20 > But, it is a little unclear to me what target-param (if any), I would = include, so I would like that to get soreted out first. I think the suggestion on the ML is to include the "mp" as far as I can = tell.=20 I guess if the system doing the translation is certain that the target = of=20 tel URI and that of SIP URI is the same user then it can add "rc" = according=20 to the new semantics suggested by Hadriel.=20 >=20 > ---------- > =20 >>> 3. Tel to Sip transformation: History-Info (technical) >>> =20 >>> Related to the previous question, the text doesn't indicate whether = the transformation from Tel to Sip should be recorded in an History-Info = header field. The Request-URI is, after all,=20 >>> changed. >> =20 >>=20 >> I don't know if we need to add anything specific for this. The draft = doesn't limit the=20 >> behavior of the entity recording H-I to only record SIP-URI, it just = says to record the=20 >> R-URI.=20 >=20 > Based on the comments I get, the text seems to indicate that you = shouldn't insert a Tel in a History-Info in the first place. Instead you = should transform it to a SIP-URI before inserting it. >=20 > But, I can think of some text for that also, because it's related to = the previous comments. >=20 > ---------- >=20 >>> 4. Home proxy (editorial) >>> =20 >>> The draft mentions "home proxy", but there is no reference or = definition for it. I guess it should be "registrar", or something. >>=20 >> I guess we can call it a "registrar" or at the first instance include = a text used in=20 >> RFC 3327.=20 >>=20 >> REGISTRAR or a "home proxy" (a proxy serving as the terminal = point for routing an address-of-record) >=20 > I think it occurs only once, but as long as there is a definition (or = a reference to a definition) I don't mind if it's used. >=20 >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > =20 > =20 >=20 >=20 From shida@ntt-at.com Fri Jun 24 05:40: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 E820411E80CB for ; Fri, 24 Jun 2011 05:40:12 -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=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oAAHeFD-TB4 for ; Fri, 24 Jun 2011 05:40:12 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7A03E11E80B5 for ; Fri, 24 Jun 2011 05:40:12 -0700 (PDT) Received: from flh1agj244.tky.mesh.ad.jp ([125.192.75.244]:49761 helo=[192.168.11.3]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qa5K9-00015b-JC; Fri, 24 Jun 2011 07:17:25 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <3B2A8F8E-4255-4156-B882-BF68F4046F3D@acmepacket.com> Date: Fri, 24 Jun 2011 21:17:25 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <4DFBA04C-5745-4050-93E1-A88BA07BEA12@ntt-at.com> References: <3B2A8F8E-4255-4156-B882-BF68F4046F3D@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1084) 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: flh1agj244.tky.mesh.ad.jp ([192.168.11.3]) [125.192.75.244]:49761 X-Source-Auth: shida@agnada.com X-Email-Count: 31 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org, "sipcore@ietf.org WG" Subject: Re: [sipcore] 4244bis-05: additional technical comments 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, 24 Jun 2011 12:40:13 -0000 Hi Hadriel; Thanks for your comments.. My comments inline.=20 On Jun 16, 2011, at 5:15 AM, Hadriel Kaplan wrote: > Hi, > some more technical comments: >=20 > 1) Section 10.3, page 19, says: > In the case that a SIP entity (intermediary or UAS) adds an hi-entry > on behalf of the previous hop, the hi-index MUST be set to 1. >=20 > Taken literally, this means when a request already marked with H-I = entries happens to cross a legacy non-HI system, the next downstream = element will add an additional H-I entry starting at 1 again. Is that = intentional/on-purpose?? At first I thought this was just an editorial = mistake, but section 11, page 22, says : > Gaps are possible if the request is forwarded through > intermediaries that do not support the History-info header field and > are reflected by the existence of multiple hi-entries with an index > of "1". =20 >=20 > So a single SIP request can actually have multiple H-I trees with = multiple root indexes of 1? Wouldn't this make UAS logic code more = complicated, because now the "mp=3DX" and "rc=3DX" index values are = relative "X" values, scoped to within their particular tree, as opposed = to being an absolute number for the whole H-I list? >=20 Hmm..=20 This doesn't sound right.=20 My understanding of the text was to have entity receiving the=20 request with a gap in H-I to add hi-entry and add it as a new hop,=20 meaning add a dot and index of "1".=20 Gap could still exists as text mentions, if there are multiple hops=20 between entities that support H-I. Because the entity receiving the=20 H-I on behalf of the entity not supporting the H-I could only record=20 R-URI it received.=20 >=20 > 2) Section 9.4, page 16 says: > When sending a response other than a 100, a SIP entity MUST include > all the cached hi-entries in the response, subject to the privacy > consideration in Section 10.1.2 with the following exception: If the > received request contained no hi-entries and there is no "histinfo" > option tag in the Supported header field, the SIP entity MUST NOT > include hi-entries in the response. >=20 > Note the "If the received request contained no hi-entries and...". I = don't know what having H-I entries has to do with it. We have an = option-tag for this purpose: histinfo. If the option-tag is in the = Supported, then you can send H-I entries in response. Else not. Even = if the request contained H-I entries but no "histinfo" option tag, you = can't send 'em back. (e.g., such would be the case if proxies added the = entries but the UAC does not support it) Agree.=20 will fix.=20 Regards Shida >=20 > -hadriel >=20 From shida@ntt-at.com Fri Jun 24 05:40: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 0E17F11E80B5 for ; Fri, 24 Jun 2011 05:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.52 X-Spam-Level: X-Spam-Status: No, score=-101.52 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1i6FT4+DSd0 for ; Fri, 24 Jun 2011 05:40:12 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id AFA8911E80C5 for ; Fri, 24 Jun 2011 05:40:12 -0700 (PDT) Received: from flh1agj244.tky.mesh.ad.jp ([125.192.75.244]:49761 helo=[192.168.11.3]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qa5Jv-00015b-4p; Fri, 24 Jun 2011 07:17:11 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Fri, 24 Jun 2011 21:17:11 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Worley, Dale R (Dale)" X-Mailer: Apple Mail (2.1084) 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: flh1agj244.tky.mesh.ad.jp ([192.168.11.3]) [125.192.75.244]:49761 X-Source-Auth: shida@agnada.com X-Email-Count: 32 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sipcore@ietf.org WG" Subject: Re: [sipcore] 4244bis-05: name-addr 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, 24 Jun 2011 12:40:13 -0000 Dale; Thanks for your comments.=20 We can change this upon revision.=20 Regards Shida On Jun 18, 2011, at 6:26 AM, Worley, Dale R (Dale) wrote: > For consistency of construction and parsing with To, From, Contact, = etc., I suggest that the syntax be modified to: >=20 > hi-targeted-to-uri =3D addr-spec / name-addr >=20 > We really don't need a separate parser for History-Info than from all = the other headers with a similar syntax. >=20 > Dale From shida@ntt-at.com Fri Jun 24 05:40: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 101F211E80CE for ; Fri, 24 Jun 2011 05:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.858 X-Spam-Level: X-Spam-Status: No, score=-101.858 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SARE_BAYES_5x7=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HirAZUVKj5Fv for ; Fri, 24 Jun 2011 05:40:11 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id BA3B711E809B for ; Fri, 24 Jun 2011 05:40:11 -0700 (PDT) Received: from [125.192.75.244] (port=49780 helo=[192.168.11.3]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qa5g6-00075o-Hm; Fri, 24 Jun 2011 07:40:07 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2--100476984 From: Shida Schubert In-Reply-To: <56DC300C52125F46BA19D2D5CCEC4D70011162C4@XCH04ADS.rim.net> Date: Fri, 24 Jun 2011 21:40:04 +0900 Message-Id: <637BE7FB-05BF-48F7-A9CA-547B709E7DE2@ntt-at.com> References: <4DEC205A.5040503@cisco.com> <56DC300C52125F46BA19D2D5CCEC4D70011162C4@XCH04ADS.rim.net> To: Andrew Allen X-Mailer: Apple Mail (2.1084) 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: flh1agj244.tky.mesh.ad.jp ([192.168.11.3]) [125.192.75.244]:49780 X-Source-Auth: shida@agnada.com X-Email-Count: 27 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis 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, 24 Jun 2011 12:40:13 -0000 --Apple-Mail-2--100476984 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Andrew; Thanks for your review.=20 My comments inline.=20 On Jun 22, 2011, at 12:35 AM, Andrew Allen wrote: > Seems I missed the WGLC deadline by a day or so but here are the = comments from my review: > =20 > Section 5 > =20 > "mp": The hi-targeted-to-URI represents a user other than the > user associated with the Request-URI in the incoming request > that was retargeted. >=20 > The term =93user=94 here is confusing. Does it mean the human user = (who might have multiple AoRs/URIs which may or may not be known to the = retargeting proxy as AoRs/URIs that all map to the same human user)? = When retargeting is the proxy supposed to assess whether the new target = URI represents the same human user or not in order to determine whether = to include the =93mp=94 parameter or not? I=92m not sure what = terminology would be best but I think =93user=94 is likely to cause = confusion. > The above issue also reoccurs in section 7 Your assumption is same as my understanding of this terminology as = well.=20 It could be an individual or it could be a corporate entity. =20 > =20 > Section 15 > =93Entities that have not implemented this specification MUST ignore = these parameters=94? We can=92t make any normative requirements on = entities that have not implemented this specification! Therefore the = MUST should be removed. I think you mean to state that according to RFC = 3261 and RFC 4244 entities that are not compliant with this = specification will ignore these parameters. Yes.=20 > =20 > =20 > There is a backward compatibility concern which I think should be = addressed. With 4244bis the URI in the Request-URI is now clearly to be = included in the History-Info when the Request-URI is replaced by the = Contact address. This was not the case in RFC 4244 where in many (if not = most) implementations rewriting the request-URI with the Contact was not = considered retargeting. Some existing UA implementations may have = assumed that the last History-Info entry cannot be their own Contact = Address but will always be their AoR. For example a UA may only look at = the next highest History-Info header field from the bottom most one in = order to determine whether the call arrived as a result of forwarding or = not from within their home domain and what the URI was that it was = forwarded from. Since outside the home domain of the UA up to now the = use of History-Info has not been deterministic some UAs may have only = looked at the last couple of History-Info header fields in order to = determine what happened to the request after it arrived within their = domain. In these kinds of scenarios having a proxy now add an additional = History-Info header field (for the rewriting of the Request-URI to the = Contact) in 4244bis may break the logic of such UAs. I am not saying we = shouldn=92t do this but I think some text about such possible problems = with existing implementations should be indicated in the backwards = compatibility section. The definition of retargeting in RFC4244 was not clear and it is = definitely not=20 defined in RFC3261, so I can understand why some may implement it the = way=20 you mentioned it. Although example in RFC4244 clearly inserts contact = address=20 as the History-Info.=20 Never the less, we will add some text with regards to this in the = backward=20 compatibility section. > =20 > Section B.1 > =20 > In this example, the Office and Home are not the > same AOR as sip:bob@example.com, but rather different AORs that = have > been configured as alternate addresses for Bob in the proxy. In > other words, Office and Bob are not bound through SIP Registration > with Bob's AOR. > =20 > The opportunity is missed to explain here that this means that the = =93rc=94 parameter is not added. I think it would help to understand if = that was highlighted. You are right, but Dale and Hadriel pointed the issue here with not = marking=20 hi-entry, so we are likely to change these texts as we are likely to = change the=20 semantics of "rc", from the looks of the discussion.=20 We will reflect the followings errors you found.=20 As for the details in call-flow B.2 and B.3, the idea is to focus only = on=20 H-I so it is easier for implementors to see what gets recorded. Do you = prefer=20 the extended version similar to B.1?=20 Regards Shida > =20 > =20 > =20 > FLOW F1 > =20 > INVITE sip:alice@example.com should be INVITE sip:bob@example.com > =20 > =20 > FLOW F5 > =20 > Request-URI for the ACK looks wrong to me shouldn=92t it be = bob@192.0.2.4? > =20 > =20 > FLOW F6 > =20 > The URI in the Request-URI and the URI in the bottom most History-Info = header field are not the same (R-URI =3D office@192.0.2.3 and H-I = =3Doffice@192.0.2.5). These should be the same =96 suggest change R-URI = tooffice@192.0.2.5 so as to avoid need to change H-I in the other flows = and also since 192.0.2.3 is Alice=92s UA!!. > =20 > =20 > FLOW F13 > =20 > Again Request-URI for the ACK looks wrong to me shouldn=92t it = behome@192.0.2.6? > =20 > =20 > Examples in B.2 and B.3 do not have the same level of detail as in B.1 = or RFC 4244. > =20 > =20 > Editorials > Last paragraph of 10.1 .2 =93compenent=94 should be =93component=94 > First and 2nd paragraph of 10.3 =93add an hi-index=94/=94adds an = hi-entry=94 should be =93a=94 not =93an=94 > =20 > Regards > Andrew > =20 > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On = Behalf OfPaul Kyzivat > Sent: Sunday, June 05, 2011 7:34 PM > To: SIPCORE (Session Initiation Protocol Core) WG > Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org; SIPCORE Chairs; = Robert Sparks > Subject: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis > =20 > [as co-chair] >=20 > The current editor of draft-ietf-sipcore-rfc4244bis believes that the = document has no remaining technical issues, and is ready for evaluation. = Today, we are starting a two-week working group last call period. This = last call period ends on Sunday, June 19. >=20 > The latest version of the document can be retrieved here: >=20 > http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis >=20 > Any comments on the document should be sent to the SIPCORE mailing = list. >=20 > Thanks, > Paul > ---------------------------------------------------------------------=20= > This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be = unlawful._______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail-2--100476984 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Hi = Andrew;

Thanks for your = review.

My comments = inline.

On Jun 22, 2011, at 12:35 AM, Andrew = Allen wrote:

Seems I missed the WGLC = deadline by a day or so but here are the comments from my = review:

Section 5

"mp": The hi-targeted-to-URI = represents a user other than the
user = associated with the Request-URI in the incoming = request
that = was retargeted.
The term = =93user=94 here is confusing. Does it mean the human user (who might = have multiple AoRs/URIs which may or may not be known to the retargeting = proxy as AoRs/URIs that all map to the same human user)? When = retargeting is the proxy supposed to assess whether the new target URI = represents the same human user or not in order to determine whether to = include the =93mp=94 parameter or not? I=92m not sure what terminology = would be best but I think =93user=94 is likely to cause = confusion.
The above issue = also reoccurs in section = 7

Your = assumption is same as my understanding of this terminology as = well.

It could be an individual or = it could be a corporate entity.

Section = 15
=93Entities that have not implemented this specification MUST = ignore these parameters=94? We can=92t make any = normative requirements on entities that have not implemented this = specification! Therefore the MUST should be removed. I think you mean to = state that according to RFC 3261 and RFC 4244 entities that are not = compliant with this specification will ignore these = parameters.

= ;Yes.

There is a = backward compatibility concern which I think should be addressed. With = 4244bis the URI in the Request-URI is now clearly to be included in the = History-Info when the Request-URI is replaced by the Contact address. = This was not the case in RFC 4244 where in many (if not most) = implementations rewriting the request-URI with the Contact was not = considered retargeting. Some existing UA implementations may have = assumed that the last History-Info entry cannot be their own Contact = Address but will always be their AoR. For example a UA may only look at = the next highest History-Info header field from the bottom most one in = order to determine whether the call arrived as a result of forwarding or = not from within their home domain and what the URI was that it was = forwarded from. Since outside the home domain of the UA up to now the = use of History-Info has not been deterministic some UAs may have only = looked at the last couple of History-Info header fields in order to = determine what happened to the request after it arrived within their = domain. In these kinds of scenarios having a proxy now add an additional = History-Info header field (for the rewriting of the Request-URI to the = Contact) in 4244bis may break the logic of such UAs. I am not saying we = shouldn=92t do this but I think some text about such possible problems = with existing implementations should be indicated in the backwards = compatibility = section.

Th= e definition of retargeting in RFC4244 was not clear and it is = definitely not

defined in RFC3261, so I can = understand why some may implement it the way

you = mentioned it. Although example in RFC4244 clearly inserts contact = address

as the = History-Info.

Never the less, we = will add some text with regards to this in the = backward

compatibility section.

Section = B.1
In this example, the Office and Home are not = the
   same AOR as sip:bob@example.com, but rather different AORs that = have
   been configured as alternate = addresses for Bob in the proxy. In
   = other words, Office and Bob are not bound through SIP = Registration
with Bob's = AOR.
The opportunity = is missed to explain here that this means that the =93rc=94 parameter is = not added. I think it would help to understand if that was = highlighted.

&nbs= p;You are right, but Dale and Hadriel pointed the issue here with not = marking

hi-entry, so we are likely to change these = texts as we are likely to change the

semantics of "rc", = from the looks of the = discussion.

We will reflect the = followings errors you found.

As for = the details in call-flow B.2 and B.3, the idea is to focus only = on

H-I so it is easier for implementors to see what gets = recorded. Do you prefer

the extended version similar to = B.1?

Regards

Sh= ida

FLOW = F1

INVITE sip:alice@example.com should be INVITE sip:bob@example.com

FLOW = F5

Request-URI for the ACK looks wrong to me = shouldn=92t it be bob@192.0.2.4?

FLOW = F6

The URI in the Request-URI and the URI in the = bottom most History-Info header field are not the same (R-URI =3D office@192.0.2.3 and H-I =3Doffice@192.0.2.5). These should be the same =96 suggest = change R-URI tooffice@192.0.2.5 so as to avoid need to = change H-I in the other flows and also since 192.0.2.3 is Alice=92s = UA!!.

Again Request-URI = for the ACK looks wrong to me shouldn=92t it behome@192.0.2.6?
Examples in B.2 = and B.3 do not have the same level of detail as in B.1 or RFC = 4244.

Last = paragraph of 10.1 .2 =93compenent=94 should be = =93component=94
First and = 2^nd paragraph= of 10.3 =93add an hi-index=94/=94adds an hi-entry=94 should be =93a=94 = not =93an=94

Andrew
From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.= org] On Behalf = OfPaul Kyzivat
Sent: Sunday, June 05, 2011 7:34 = PM
To: SIPCORE= (Session Initiation Protocol Core) WG
Cc:  [sipcore] WGLC: = draft-ietf-sipcore-rfc4244bis

[as co-chair]

The current = editor of draft-ietf-sipcore-rfc4244bis believes that the document has = no remaining technical issues, and is ready for evaluation. Today, we = are starting a two-week working group last call period. This last call = period ends on Sunday, June 19.

The latest version of the = document can be retrieved here:

This transmission = (including any attachments) may contain confidential information, = privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be = unlawful._______________________________________________
sipcore = mailing list
sipcore@ietf.org
X-Mailer: Apple Mail (2.1084) 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: flh1agj244.tky.mesh.ad.jp ([192.168.11.3]) [125.192.75.244]:49761 X-Source-Auth: shida@agnada.com X-Email-Count: 33 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sipcore@ietf.org WG" Subject: Re: [sipcore] 4244bis-05: the infamous "rc" param 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, 24 Jun 2011 12:40:13 -0000 I believe Hadriel's suggestion of adding the "rc" tag=20 whenever R-URI is changed.=20 I think it might have been overlooking the message as=20 I think the 2 former entries you pointed out obviously is a=20 contact address, which should have had the "rc" parameters.=20 But again as it currently limits the use only when the address=20 is registered via REGISTER, this could easily happen in=20 the deployment.=20 Regards Shida On Jun 18, 2011, at 5:02 AM, Worley, Dale R (Dale) wrote: >> From: Hadriel Kaplan [HKaplan@acmepacket.com] >>=20 >> What "rc" should actually stand for is "Request-uri Changed". It >> should be populated in ALL cases where the request-URI is changed, = but >> where the new target is still the same identity (ie, it's not an "mp" >> tag instead), and it should still use an index to point to the >> previous H-I entry it changed from as it does now. >=20 > I'm not so concerned about the different categories of redirection and = how we record them, > but that there will be some redirections to which neither "rc" nor = "mp" will apply. > In those cases, there is no way to record which URI this URI is = derived from, because the > back-pointer is the value of rc/mp. >=20 > And it doesn't look like the draft thinks about that case much. There = three examples that > I can find where a URI is not the same as its parent but does not have = an rc/mp parameter: >=20 > Messages F6 and F9 in B.1 and one message in B.2: >=20 > F6 INVITE example.com -> office >=20 > INVITE sip:office@192.0.2.3.com SIP/2.0 >=20 > History-Info: ;index=3D1 > History-Info: ;\ > index=3D1.1;rc=3D1 > History-Info: ;index=3D1.2;mp=3D1 > History-Info: ;index=3D1.2.1 = <------------------ >=20 >=20 >=20 > F9 INVITE example.com -> home >=20 > INVITE sip:home@192.0.2.6 SIP/2.0 >=20 > History-Info: ;index=3D1 > History-Info: ;\ > index=3D1.1;rc=3D1 > History-Info: ;index=3D1.2;mp=3D1 > History-Info: ;\ > index=3D1.2.1>;index=3D1.2.1 > History-Info: ;index=3D1.3;mp=3D1 > History-Info: ;index=3D1.3.1 = <---------------------- >=20 >=20 > | | INVITE sip:bob@biloxi.example.com;p=3Dx > | |--------------->| | > | History-Info: ;index=3D1 > | History-Info: ;index=3D1.1 >=20 > [Though the last one was due to anonymization.] >=20 >=20 > I think we need to adjust the parameters to put the back-pointer into = a separate > parameter from the "type of redirection" information. >=20 > Dale >=20 From pkyzivat@cisco.com Fri Jun 24 06:33: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 7B24611E808B for ; Fri, 24 Jun 2011 06:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.439 X-Spam-Level: X-Spam-Status: No, score=-110.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGtD94tRD8Nn for ; Fri, 24 Jun 2011 06:33:08 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id C567D228005 for ; Fri, 24 Jun 2011 06:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3793; q=dns/txt; s=iport; t=1308922388; x=1310131988; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Ps00PiYV4Kvy5ltLnEFqYVYPqjZmcyQxlhYPYECrE9E=; b=Qc8q2QkKmc9rJ53Lsy4HDofMEG0TESso0+kly9g76sXeSXtvLC1wNr9Y 2xDqudllodiQ+umUfksQmlOiKKK4mDkSR6xjaDSSNHAy55Ik6gnEYAGAL CZYFeGAOOg4Mmg06fC3CHgBV3e7t8vbfBOOTwI+mZzIz7knFEaZyvbUSI Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADuRBE6tJXG//2dsb2JhbABSpzZ3iHOjSp4Xhi0EkXuEaItG X-IronPort-AV: E=Sophos;i="4.65,419,1304294400"; d="scan'208";a="469292843" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-1.cisco.com with ESMTP; 24 Jun 2011 13:33:07 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5ODX6FO000848; Fri, 24 Jun 2011 13:33:06 GMT Message-ID: <4E049211.8040209@cisco.com> Date: Fri, 24 Jun 2011 09:33:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Shida Schubert References: <4DEC205A.5040503@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E36022D@ESESSCMS0356.eemea.ericsson.se> <2FDD10D8-6DF3-4D77-B300-C05C2AB5D3A2@agnada.com> <7F2072F1E0DE894DA4B517B93C6A0585194E3E71BA@ESESSCMS0356.eemea.ericsson.se> <4DFFB175.5080507@cisco.com> <56BD4DB5-2808-4EA5-BF44-BEC1E5AB0874@ntt-at.com> In-Reply-To: <56BD4DB5-2808-4EA5-BF44-BEC1E5AB0874@ntt-at.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org, Robert Sparks , "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis 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, 24 Jun 2011 13:33:09 -0000 On 6/24/2011 8:16 AM, Shida Schubert wrote: > > Paul; > > Are you suggesting to include three hi-entries, > whenever an entity retargeting the tel-URI > logs it to H-I? > > e.g. > > History-Info :;index=1 > History-Info :; index=1.1; mp=1 > History-Info :;index=1.2, rc=1.1 > (based on the new semantics Hadriel suggested) That seems about right. (I'm not sure about the tags, just because I haven't been following that closely.) > In that case, how do you think the privacy of the tel URI > should be handled? I guess you are asking because a privacy header can't be affixed to a tel uri? If so, that suggests to me that handling privacy by embedding a privacy header into the URI was a mistake. > Should the proxy apply the same privacy policy that it would > apply to the SIP URI? Oh. Do you mean that when privacy is applied by hiding things belonging to the proxy's domain, how does it decide that this should be hidden too? If it is hiding things because not hiding them would expose domain addresses, then there is no reason to hide the tel uri, since it doesn't expose a domain address. NOTE: That is precisely why tel URIs are *not* equivalent to their sip "equivalent" URIs. The tel uri implies no domain - anyone wanting to call it is both free and obligated to seek out its own way of routing it. Calls to sip URIs are constrained to be routed based on the domain of the URI until reaching a server responsible for that domain. For instance, if you have sip:+12121234567@example.com, and you have a device that has connectivity to both the pstn and internet, you are really obligated to route it to example.com. And if you currently only have pstn connectivity you ought not send it via the pstn. But if you have tel:+12121234567, you are free to do whatever you want. I know may devices will simply *assume* the sip uri is equivalent to a tel uri. But that isn't really proper. The device may have important features that can't work over a pstn connection. (These comments are really from an individual, rather than chair, perspective.) Thanks, Paul > Regards > Shida > > On Jun 21, 2011, at 5:45 AM, Paul Kyzivat wrote: > >> (as individual) >> >> On 6/17/2011 3:25 AM, Christer Holmberg wrote: >> >>>>> 3. Tel to Sip transformation: History-Info (technical) >>>>> >>>>> Related to the previous question, the text doesn't indicate whether the transformation from Tel to Sip should be recorded in an History-Info header field. The Request-URI is, after all, >>>>> changed. >>>> >>>> >>>> I don't know if we need to add anything specific for this. The draft doesn't limit the >>>> behavior of the entity recording H-I to only record SIP-URI, it just says to record the >>>> R-URI. >>> >>> Based on the comments I get, the text seems to indicate that you shouldn't insert a Tel in a History-Info in the first place. Instead you should transform it to a SIP-URI before inserting it. >> >> I agree with Christer (!!!) that the transformation from tel: to sip: *is* a change, and if you care about H-I then this ought to be recorded. >> >> (This is not just a superficial change in representation - it is a *semantic* change, because different processing rules apply to sip URIs that tel URIs.) >> >> There isn't even a guarantee that a proxy will have a suitable way to re-represent a tel uri as a sip URI. >> >> So I think this calls for some sort of explanation. I guess its lucky that if you do create H-I entries for this, that its the translated (sip) URI that gets the parameters added. So its at least *possible* to do this. >> >> Thanks, >> Paul > > From aallen@rim.com Fri Jun 24 07:32: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 0FD0E21F84A8 for ; Fri, 24 Jun 2011 07:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.902 X-Spam-Level: X-Spam-Status: No, score=-4.902 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_5x7=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffGt9qXlxNaa for ; Fri, 24 Jun 2011 07:32:34 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 28CED21F84A7 for ; Fri, 24 Jun 2011 07:32:33 -0700 (PDT) X-AuditID: 0a41282f-b7c7dae00000790d-be-4e049ffe0755 Received: from XCH139CNC.rim.net (xch139cnc.rim.net [10.65.10.235]) by mhs060cnc.rim.net (SBG) with SMTP id F6.29.30989.EFF940E4; Fri, 24 Jun 2011 14:32:30 +0000 (GMT) Received: from XCH04ADS.rim.net ([10.67.10.91]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jun 2011 10:32:32 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC327B.78D34EB0" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 24 Jun 2011 09:31:55 -0500 Message-ID: <56DC300C52125F46BA19D2D5CCEC4D700120285E@XCH04ADS.rim.net> In-Reply-To: <637BE7FB-05BF-48F7-A9CA-547B709E7DE2@ntt-at.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis thread-index: Acwya99QVnzAVwzjSmmflGptA1hCLQADefIg References: <4DEC205A.5040503@cisco.com> <56DC300C52125F46BA19D2D5CCEC4D70011162C4@XCH04ADS.rim.net> <637BE7FB-05BF-48F7-A9CA-547B709E7DE2@ntt-at.com> From: "Andrew Allen" To: "Shida Schubert" X-OriginalArrivalTime: 24 Jun 2011 14:32:32.0840 (UTC) FILETIME=[8DCEAC80:01CC327B] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCKsWRmVeSWpSXmKPExsXC5cj1WvfffBY/gwmXBSx+H5rHanHq1Wlm i68/NrE5MHssWfKTyaPn0mxGjy+XP7MFMEc1MNok5uXllySWpCqkpBYn2yr5pKYn5igEFGWW JSZXKrhkFifnJGbmphYpKWSm2CqZKCkU5CQmp+am5pXYKiUWFKTmpSjZcSlgABugssw8hdS8 5PyUzLx0WyXPYH9dCwtTS11DJTtdJJDwjzvjyYT/jAW9C5kqLrwtaWA8+IWxi5GDQ0LARKL/ q2cXIyeQKSZx4d56ti5GLg4hgZWMEmfWbmWGcPoYJQ6t+8ECUsUsoCVx5FITI4jNKyAocXLm E6h4uMSRFfcYISbpSSxbPAUsLixgJfH5fjs7iM0ioCrRe+YTK0Svu8SSlgdgNZwCdhL/du6C 6hWUWDR7DzPMRf92PWQDsUUErCUerr/EBGEbSaxrvsMEcdw0RonTV6+DNbMBLXhzfAMjRJG6 xI73U6GOq5I48uA32CAhAWmJHSfXQH0fLPHiOfsERrFZSF6bheS1WUhemwXUwQz0WttGRoiw tsSyha+ZIWxdif/P5zAjiy9gZF/FKJibUWxgZpCcl6xXlJmrl5dasokRnII09Hcw9u3VOsQo wMGoxMMbOIvFT4g1say4MvcQowQHs5IIr8lUoBBvSmJlVWpRfnxRaU5q8SFGV2AgTmSW4k7O B6bHvJJ4YwMD3BwlcV6RBXN8hQTSgSkvOzW1ILUIZg4TB6dUA+Ps6SY/3std4bjltLGXM3b2 5gtHJRrzBdoWtVfMnJz1cLWXYtyjP4+nHbs8/WzklKd/BJq31vT/87OokIh7OC9OV7dL/kur VEHZ5iaJVWVXAiWXhD15lCT8asmSo1yqrskGBqKeB3+Ire3Y831NdsARE9ZjZROuMe6trTs4 n0HrG8cMyzfTJzIqsRRnJBpqMRcVJwIACN09L2cDAAA= Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis 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, 24 Jun 2011 14:32:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC327B.78D34EB0 Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Shida Response below. Andrew From: Shida Schubert [mailto:shida@ntt-at.com] Sent: Friday, June 24, 2011 7:40 AM To: Andrew Allen Cc: SIPCORE Chairs; SIPCORE (Session Initiation Protocol Core) WG Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis Hi Andrew; Thanks for your review. My comments inline. On Jun 22, 2011, at 12:35 AM, Andrew Allen wrote: Seems I missed the WGLC deadline by a day or so but here are the comments from my review: Section 5 "mp": The hi-targeted-to-URI represents a user other than the user associated with the Request-URI in the incoming request that was retargeted. The term "user" here is confusing. Does it mean the human user (who might have multiple AoRs/URIs which may or may not be known to the retargeting proxy as AoRs/URIs that all map to the same human user)? When retargeting is the proxy supposed to assess whether the new target URI represents the same human user or not in order to determine whether to include the "mp" parameter or not? I'm not sure what terminology would be best but I think "user" is likely to cause confusion. The above issue also reoccurs in section 7 Your assumption is same as my understanding of this terminology as well. It could be an individual or it could be a corporate entity. [AA] So does the proxy that is doing the re-targeting need to have definitive knowledge that the two URIs are for the same individual (or corporate entity)? I am not convinced that a proxy will always know that this is the case. Often call forwarding is done based on some kind of user configuration. In some cases the user sets up the forwarding to another URI of (owned by) the same human user but in other cases it is not the same human user. For example I can choose to have all my calls forwarded to some other person (such as wife, friend, or even a hotel where I am staying). I don't know how a proxy can tell that the URI is for the same human user or not in such circumstances. I think this area needs further explanation. Section 15 "Entities that have not implemented this specification MUST ignore these parameters"? We can't make any normative requirements on entities that have not implemented this specification! Therefore the MUST should be removed. I think you mean to state that according to RFC 3261 and RFC 4244 entities that are not compliant with this specification will ignore these parameters. Yes. [AA] OK so this will be rephrased to remove the MUST? There is a backward compatibility concern which I think should be addressed. With 4244bis the URI in the Request-URI is now clearly to be included in the History-Info when the Request-URI is replaced by the Contact address. This was not the case in RFC 4244 where in many (if not most) implementations rewriting the request-URI with the Contact was not considered retargeting. Some existing UA implementations may have assumed that the last History-Info entry cannot be their own Contact Address but will always be their AoR. For example a UA may only look at the next highest History-Info header field from the bottom most one in order to determine whether the call arrived as a result of forwarding or not from within their home domain and what the URI was that it was forwarded from. Since outside the home domain of the UA up to now the use of History-Info has not been deterministic some UAs may have only looked at the last couple of History-Info header fields in order to determine what happened to the request after it arrived within their domain. In these kinds of scenarios having a proxy now add an additional History-Info header field (for the rewriting of the Request-URI to the Contact) in 4244bis may break the logic of such UAs. I am not saying we shouldn't do this but I think some text about such possible problems with existing implementations should be indicated in the backwards compatibility section. The definition of retargeting in RFC4244 was not clear and it is definitely not defined in RFC3261, so I can understand why some may implement it the way you mentioned it. Although example in RFC4244 clearly inserts contact address as the History-Info. Never the less, we will add some text with regards to this in the backward compatibility section. [AA] OK Section B.1 In this example, the Office and Home are not the same AOR as sip:bob@example.com, but rather different AORs that have been configured as alternate addresses for Bob in the proxy. In other words, Office and Bob are not bound through SIP Registration with Bob's AOR. The opportunity is missed to explain here that this means that the "rc" parameter is not added. I think it would help to understand if that was highlighted. You are right, but Dale and Hadriel pointed the issue here with not marking hi-entry, so we are likely to change these texts as we are likely to change the semantics of "rc", from the looks of the discussion. We will reflect the followings errors you found. As for the details in call-flow B.2 and B.3, the idea is to focus only on H-I so it is easier for implementors to see what gets recorded. Do you prefer the extended version similar to B.1? [AA] Yes I prefer the extended version as this is consistent with the flows in most other SIP RFCs and also with RFC 4244. At the very least the Request-URI, History-Info, and Contact headers need to be shown as these all interact in a meaningful way in History Info. Regards Shida FLOW F1 INVITE sip:alice@example.com should be INVITE sip:bob@example.com FLOW F5 Request-URI for the ACK looks wrong to me shouldn't it be bob@192.0.2.4? FLOW F6 The URI in the Request-URI and the URI in the bottom most History-Info header field are not the same (R-URI =3D office@192.0.2.3 and H-I =3Doffice@192.0.2.5). These should be the same - suggest change R-URI tooffice@192.0.2.5 so as to avoid need to change H-I in the other flows and also since 192.0.2.3 is Alice's UA!!. FLOW F13 Again Request-URI for the ACK looks wrong to me shouldn't it behome@192.0.2.6? Examples in B.2 and B.3 do not have the same level of detail as in B.1 or RFC 4244. Editorials Last paragraph of 10.1 .2 "compenent" should be "component" First and 2nd paragraph of 10.3 "add an hi-index"/"adds an hi-entry" should be "a" not "an" Regards Andrew From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf OfPaul Kyzivat Sent: Sunday, June 05, 2011 7:34 PM To: SIPCORE (Session Initiation Protocol Core) WG Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org; SIPCORE Chairs; Robert Sparks Subject: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis [as co-chair] The current editor of draft-ietf-sipcore-rfc4244bis believes that the document has no remaining technical issues, and is ready for evaluation. Today, we are starting a two-week working group last call period. This last call period ends on Sunday, June 19. The latest version of the document can be retrieved here: http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis Any comments on the document should be sent to the SIPCORE mailing list. Thanks, Paul --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful._______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_001_01CC327B.78D34EB0 Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Shida

Response below.

Andrew

From: Shida Schubert [mailto:shida@ntt-at.com]
Sent: Friday, June 24, 2011 7:40 AM
To: Andrew Allen
Cc: SIPCORE Chairs; SIPCORE (Session Initiation Protocol Core) WG
Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis=

Hi Andrew;

Thanks for your review.

My comments inline.

On Jun 22, 2011, at 12:35 AM, Andrew Allen wrote:<= /o:p>

Seems I missed the WGLC deadline by a day or so but here are= the comments from my review:

Section 5<= /p>

"mp= ": The hi-targeted-to-URI represents a user other than the

us= er associated with the Request-URI in the incoming request

that was retargeted.

The term “user”= here is confusing. Does it mean the human user (who might have multiple AoRs/URIs which may or may not be known to the retargeting proxy as AoRs/URIs that all map to the same human user)? When retargeting is the proxy supposed to asses= s whether the new target URI represents the same human user or not in order to determine whether to include the “mp” parameter or not? I’= m not sure what terminology would be best but I think “user” is likely to cause confusion.

The above issue also reoccu= rs in section 7

Your assumption is same as my understanding of th= is terminology as well.

It could be an individual or it could be a corpor= ate entity.

[AA] So does the proxy that is doing the re-ta= rgeting need to have definitive knowledge that the two URIs are for the same individ= ual (or corporate entity)? I am not convinced that a proxy will always know that this is the case. Often call forwarding is done based on some kind of user configuration. In some cases the user sets up the forwarding to another URI= of (owned by) the same human user but in other cases it is not the same human user. Fo= r example I can choose to have all my calls forwarded to some other person (su= ch as wife, friend, or even a hotel where I am staying). I don’t know how= a proxy can tell that the URI is for the same human user or not in such circumstances. I think this area needs further explanation.

Section 15

“= Entities that have not implemented this specification MUST ignore these parameters”? We can’= ;t make any normative requirements on entities that have not implemented this specification! Therefore the MUST should be removed. I think you mean to sta= te that according to RFC 3261 and RFC 4244 entities that are not compliant with this specification will ignore these parameters.

Yes.

[AA] OK so this will be rephrased to remove th= e MUST?

There is a backward compati= bility concern which I think should be addressed. With 4244bis the URI in the Request-URI is now clearly to be included in the History-Info when the Request-URI is replaced by the Contact address. This was not the case in RFC 4244 where in many (if not most) implementations rewriting the request-URI w= ith the Contact was not considered retargeting. Some existing UA implementations may have assumed that the last History-Info entry cannot be their own Contac= t Address but will always be their AoR. For example a UA may only look at the next highest History-Info header field from the bottom most one in order to determine whether the call arrived as a result of forwarding or not from wit= hin their home domain and what the URI was that it was forwarded from. Since outside the home domain of the UA up to now the use of History-Info has not been deterministic some UAs may have only looked at the last couple of History-Info header fields in order to determine what happened to the reques= t after it arrived within their domain. In these kinds of scenarios having a proxy now add an additional History-Info header field (for the rewriting of= the Request-URI to the Contact) in 4244bis may break the logic of such UAs. I am not saying we shouldn’t do this but I think some text about such possi= ble problems with existing implementations should be indicated in the backwards compatibility section.

The definition of retargeting in RFC4244 was not= clear and it is definitely not

defined in RFC3261, so I can understand why some m= ay implement it the way

you mentioned it. Although example in RFC4244 clearly inserts contact address

as the History-Info.

Never the less, we will add some text with regard= s to this in the backward

compatibility section.

[AA] OK

= Section B.1

In this example, the Office= and Home are not the

&= nbsp; same AOR as sip:bob@example.com, but rather different A= ORs that have

&= nbsp; been configured as alternate addresses for Bob in the proxy. In=

&= nbsp; other words, Office and Bob are not bound through SIP Registration

with Bo= b's AOR.

The opportunity is missed t= o explain here that this means that the “rc” parameter is not adde= d. I think it would help to understand if that was highlighted.

You are right, but Dale and Hadriel pointed the i= ssue here with not marking

hi-entry, so we are likely to change these texts a= s we are likely to change the

semantics of "rc", from the looks of the discussion.

We will reflect the followings errors you found.&= nbsp;

As for the details in call-flow B.2 and B.3, the= idea is to focus only on

H-I so it is easier for implementors to see what gets recorded. Do you prefer

the extended version similar to B.1?

[AA] Yes I prefer the extended version as this is consistent with the flows in most other SIP RFCs and also with RFC 4244. At the very le= ast the Request-URI, History-Info, and Contact headers need to be shown as these all interact in a meaningful way in History Info.

Regards

  Shida

FLOW F1

INVITE sip:alice@example.com   should be INVITE sip:bob@example.com

FLOW F5

Request-URI for the ACK loo= ks wrong to me shouldn’t it be <= /span>bob@192.0.2.4?

FLOW F6

The URI in the Request-URI= and the URI in the bottom most History-Info header field are not the same (R-URI =3D= office@192.0.2.3 and H-I =3Doffice@192.0.2.5). These should be the= same – suggest change R-URI tooffice@19= 2.0.2.5 so as to avoid need to change H-I= in the other flows and also since 192.0.2.3 is Alice’s UA!!.

FLOW F13<= /p>

Again Request-URI for the A= CK looks wrong to me shouldn’t it behom= e@192.0.2.6?

Examples in B.2 and B.3 do= not have the same level of detail as in B.1 or RFC 4244.

Editorials

Last paragraph of 10.1 .2 “compenent” should be “component”<= /p>

First and 2^nd paragraph of 10.3 “add an hi-index”/”adds an hi-entry” should be “a” not “an”

Regards<= /p>

Andrew

From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org]= On Behalf OfPaul Kyzivat Sent: Sunday, June 05= , 2011 7:34 PM
To: SIPCORE (Session Initiation Protocol Core) WG
Cc: draft-ietf-sipc= ore-rfc4244bis@tools.ietf.org; SIPCORE Chairs; Robert Sparks
Subject: [sipcore] WG= LC: draft-ietf-sipcore-rfc4244bis<= /span>

[as co-cha= ir]

The current editor of draft-ietf-sipcore-rfc4244bis believes that the docume= nt has no remaining technical issues, and is ready for evaluation. Today, we ar= e starting a two-week working group last call period. This last call period en= ds on Sunday, June 19.

The latest version of the document can be retrieved here:

http://= tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis

Any comments on the document should be sent to the SIPCORE mailing list.

   Thanks,
   Paul=

-------------------------------------------------------------= --------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmissi= on by unintended recipients is not authorized and may be unlawful._______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.o= rg/mailman/listinfo/sipcore

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. ------_=_NextPart_001_01CC327B.78D34EB0-- From dworley@avaya.com Sun Jun 26 20:25: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 73C3911E809D for ; Sun, 26 Jun 2011 20:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyyLVPrzWCE8 for ; Sun, 26 Jun 2011 20:25:53 -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 2593211E80AB for ; Sun, 26 Jun 2011 20:25:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAGAAD3B06HCzI1/2dsb2JhbABSp0NwB6kmg20CmkyGMASXDoss X-IronPort-AV: E=Sophos;i="4.65,429,1304308800"; d="scan'208";a="287143725" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 26 Jun 2011 23:25:48 -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; 26 Jun 2011 23:19:20 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Sun, 26 Jun 2011 23:25:48 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Sun, 26 Jun 2011 23:25:46 -0400 Thread-Topic: 4244bis: Syntax and semantics of History-Info Thread-Index: AQHMNHnofkhwewF19kGSG1oTuofCnw== 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] 4244bis: Syntax and semantics of History-Info 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, 27 Jun 2011 03:25:54 -0000 Here is a revision of the syntax and semantics of History-Info. All of the= open issues are listed at the left margin; the rest is formatted as if it = is part of the draft. I've updated it based on the discussions, but some o= f the issues may not reflect changes recently decided by the authors. I hoped to add implementations of the "application" processing of chapter 1= 1, but that will have to wait. ---------------------------------------------------------------------------= ----------- 5.1 Syntax of History-Info The ABNF syntax for the History-info header field and header field parameters is as follows: History-Info =3D "History-Info" HCOLON hi-entry *(COMMA hi-entry) hi-entry =3D hi-targeted-to-uri *(SEMI hi-param) hi-targeted-to-uri =3D name-addr For consistency's sake, I think this should be: hi-targeted-to-uri =3D addr-spec / name-addr hi-param =3D hi-index / hi-target-param / hi-extension index-val =3D 1*DIGIT *("." 1*DIGIT) hi-index =3D "index" EQUAL index-val hi-target-param =3D rc-param / mp-param rc-param =3D "rc" EQUAL index-val mp-param =3D "mp" EQUAL index-val hi-extension =3D generic-param The ABNF definitions for "generic-param" and "name-addr" are from [RFC3261]. This document also extends the "contact-params" for the Contact header field as defined in [RFC3261] with the "rc" and "mp" header field parameters defined above: contact-params =3D/ hi-target-param 5.2 Semantics of History-Info The History-Info header field values of a request or response together form an ordered sequence of hi-entries. The division of the hi-entries among one or more History-Info header fields is not significant. The sequence of hi-entries form a pre-order walk of a tree, the nodes of which represent requests derived from the same original request sent by the UAC. The tree is organized by the derivation of requests by forwarding and forking, with each node's request being derived (by one or more steps) from its parent node's request. This organization is indicated by the "index" parameters of the hi-entries. This deviates from the draft by assuming that entries added on behalf of legacy entites are numbered within the tree structure rather than being indexed just "1". However, the UAC may have originally sent several forks of the request (particularly if it received a 3xx response to the first request it sent). Thus, the request forks sent by the UAC are considered children of an unrealized ancestral root request. This ancestral request would be represented by an hi-entry at the beginning of the sequence, with an index consisting of zero integers, but this hi-entry is not included in History-Info. Here we deal with the fact that the UAC can send several sibling requests. Because not all SIP entities support History-Info, the tree may not separately represent every forwarding and forking operation. (Abstractly, the hi-entry tree can be derived from the tree that would be recorded if all entities supported History-Info by collapsing certain contiguous sets of nodes.) In addition, if an entity that supports History-Info receives a request that does not contain History-Info or whose Request-URI is different from the URI recorded in the History-Info that should correspond to the request, then the entity knows that the Request-URI has been changed by an upstream entity that does not support History-Info, and the entity will perform a preparatory normalization by adding an additional leaf to the tree showing the new Request-URI. This operation is specified in section 9. I have added that History-Info can be added de novo by an intermediate entity even if "Supported: histinfo" is not present. This behavior may or may not be intended by section 9.1. But if neither History-Info nor Supported: histinfo is present in the incoming request, the entity will not return History-Info upstream -- this rule avoids the know problem cases. What index is to be used for this new hi-entry? I have been assuming that it was constructed by adding .1 to the preceeding hi-entry index. But I read the draft more carefully, and it says (top of 10.3) to use just "1". Note that even the rule I describe introduces a problem: Suppose the UAS sends "History-Info: AOR;index=3D1", and a non-History-Info-supporting entity forks it to two destinations, UAS A and UAS B, both of which support History-Info. UAS A normalizes the request to "History-Info: AOR;index=3D1, UAS-A;index=3D1.1" while UAS B normalizes the request to "History-Info: AOR;index=3D1, UAS-B;index=3D1.1". These two normalized requests violate the rule that everybody expects to be satisfied, viz., that all hi-entries in the entire forking structure with the same index represent the same request. As a result, the responses from the two UASs cannot be merged in any useful way. Unfortunately, both index 1.1 hi-entries can be sent upstream (possibly to the UAC) in 1xx resonses forwarded from the two UASs. This gets really ugly, because each intermediate SIP entity is *required* to add the hi-entries that it learns from a 1xx to the cache for the transaction, and it is *required* to send those cached hi-entries upstream. With carefully selected network delays, the two 1xx responses could race each other upstream, each alternately being in the lead, causing some of the upstream caches to contain one 1.1 hi-entry and others to contain the other. A SIP entity my perform "internal retargeting", multiple stages of retargeting that it models as more than one stage of forking but without actually generating and sending a SIP request. Internal retargeting may be described in the History-Info tree as one or more nodes, as long as the semantics of the History-Info values correctly describes the derivation of the various Request-URI values. Because of the above complications, the depth of a node within the tree does not necessarily equal the number of Via headers in the corresponding request, although the number of Via headers increases as one moves downward in the tree. As forwardings or forkings of a request are generated at a SIP entity, they are numbered in time order as 1, 2, 3, etc. These numbers are the labels of the nodes of the tree; each node's index-val is assembled from the labels of the nodes from the root to itself, and it determines the sequential ordering of the hi-entries. The trees recorded in the various requests and responses of the forwarding/forking structure differ, but all hi-entries in the trees that share the same index-val represent the same request, and will have the same hi-targeted-to-uri (excepting for changes dictated by privacy processing and changing tel: URIs to sip: URIs). In a request's History-Info, the only requests of the forking structure that are represented are the ones that are ancestral to the request, and subtrees that are siblings of ancestral nodes and have received non-100 responses (which may be recorded in Reason header fields in the hi-targeted-to-uri) (which must necessarily be earlier siblings). Thus, the rightmost leaf (sequentially last) hi-entry in a request represents the request itself (and contains the Request-URI of the request) or it represents the latest ancestral request of this request that was constructed by a SIP entity that supports History-Info. A response contains a History-Info header only if the corresponding request contained "Supported: histinfo" or a History-Info header. As non-100 responses propagate in the reverse direction in the forwarding/forking structure, the hi-entries that they carry are recorded at each SIP entity as part of the state of the SIP transactions. These hi-entries will be included in the History-Info of any responses and any additional requests that are generated. When a request or response is forwarded to a domain not associated with the forwarding SIP entity, some or all of the hi-entries may be anonymized as specified in section 10.1. If a "Privacy: history" or "Privacy: header" header field is present, all hi-entries whose domain is associated with the forwarding SIP entity are anonymized. Also, any hi-targeted-to-uri with such a domain that contains a Privacy header with value "history" is anonymized. An hi-entry is anonymized by replacing the URI part of the hi-targeted-to-uri with a URI with domain "anonymous.invalid". 5.3 Semantics of an hi-entry value The following provides details for the information that is captured in the History-Info header field entry (hi-entry) for each target used for forwarding a request: o hi-targeted-to-uri: A mandatory value capturing the Request-URI for the specific request as it is forwarded. o hi-index: A mandatory parameter for History-Info reflecting the chronological order of the information, indexed to also reflect the forking and nesting of requests. The format for this parameter is a string of integers, separated by dots, that indicate the relationships between the requests that carried the Request-URIs captured in the hi-entries. o hi-target-param: An optional parameter indicating the mechanism by which the Request-URI captured in the hi-targeted-to-uri in the hi-entry was determined, and indicating the hi-entry that captures Request-URI from which it was derived. This parameter contains either an "rc" or "mp" header field parameter, which is interpreted as follows: "rc": The hi-targeted-to-URI is a contact bound to an AOR in an abstract location service, that AOR being the Request-URI that was retargeted. The AOR-to-contact binding has been placed into the location service by a SIP Registrar that received a SIP REGISTER request. The "rc" header field parameter contains the value of the hi-index in the hi-entry with an hi-targeted-to-uri that is the Request-URI that was retargeted "mp": The hi-targeted-to-URI represents a user other than the user associated with the Request-URI in the incoming request that was retargeted. This occurs when a request is statically or dynamically retargeted to another user. The "mp" header field parameter contains the value of the hi-index in the hi- entry with an hi-targeted-to-uri that is the Request-URI that was retargeted, thus identifying the "mapped from" target. [What if a mapping is done in some other manner? How do we record the index-val of the value from which the new Request-URI was derived?] If the Request-URI was generated by the SIP entity that sends the request based directly on the Request-URI of the incoming request, the value of the parameter is the index of the hi-entry for the incoming request, and the parameter name indicates the way in which the new Request-URI was derived. If the Request-URI was copied by the SIP entity that sends the request from a Contact header of a 3xx response to a sibling fork of this request, then the "rc" or "mp" header parameter (if any) of that Contact header is copied as the hi-target-param. (Any UAS that generates (rather than forwards upstream) a 3xx response must include in each Contact header an hi-target-param header parameter indicating the method by which the Contact URI was derived from the Request-URI it received. The value of the parameter is the index of the hi-entry containing the received Request-URI.) o Extension (hi-extension): A parameter to allow for future optional extensions. As per [RFC3261], any implementation not understanding an extension MUST ignore it. In addition to the parameters defined by the ABNF, an hi-entry may also include a Reason header field and/or a Privacy header field, which are both included in the "headers" component of the hi- targeted-to-uri as described below: o Reason: gives the SIP status and possibly other protocol statuses received in the response to the request represented by the hi-entry. 2xx response codes seem to be implicit in that the hi-entry is seen in a non-descendant request or a response, but no SIP Response value is present. Do we want this irregularity for 2xx? Also, if the 2xx response has a Reason header containing a non-SIP code (e.g., what a downstream gateway received from the far-side network), should it be included? o Privacy: An optional parameter for History-Info, reflected in the History-Info header field values by including in the hi-targeted-to-uri a Privacy Header [RFC3323] with value "history". The Privacy header field included in an hi-targeted-to-uri means that a specific hi-entry MUST be anonymized as specified in section 10.1. Note that since both the Reason and Privacy parameters are included in the hi-targeted-to-uri, these fields cannot be applied if=20 the hi-targeted-to-uri is a tel-URI [RFC3966]. If an entity desires or is required to apply such a parameter, the tel-URI SHOULD be transformed into a SIP URI per section 19.1.6 of [RFC3261] and then the parameter is applied. 5.4 History-Info Header Field Examples The following provides examples of the format for the History-info header field. Note that the backslash and CRLF between the fields in the examples below are for readability purposes only. History-Info: ;index=3D1;foo=3Dbar History-Info: ;index=3D1.1,\ ;index=3D1.2;mp=3D1.1,\ ;index=3D1.3;rc=3D1.2 ---------------------------------------------------------------------------= ----------- Dale From shida@ntt-at.com Sun Jun 26 22: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 48B0921F8607 for ; Sun, 26 Jun 2011 22:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.02 X-Spam-Level: X-Spam-Status: No, score=-99.02 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SARE_BAYES_5x7=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMweTFHUUF8d for ; Sun, 26 Jun 2011 22:07:45 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 920D021F8602 for ; Sun, 26 Jun 2011 22:07:45 -0700 (PDT) Received: from [125.192.75.244] (port=53365 helo=[192.168.11.2]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qb42j-00027d-Lu; Mon, 27 Jun 2011 00:07:31 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4-120697268 From: Shida Schubert In-Reply-To: <56DC300C52125F46BA19D2D5CCEC4D700120285E@XCH04ADS.rim.net> Date: Mon, 27 Jun 2011 11:06:18 +0900 Message-Id: References: <4DEC205A.5040503@cisco.com> <56DC300C52125F46BA19D2D5CCEC4D70011162C4@XCH04ADS.rim.net> <637BE7FB-05BF-48F7-A9CA-547B709E7DE2@ntt-at.com> <56DC300C52125F46BA19D2D5CCEC4D700120285E@XCH04ADS.rim.net> To: Andrew Allen X-Mailer: Apple Mail (2.1084) 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: flh1agj244.tky.mesh.ad.jp ([192.168.11.2]) [125.192.75.244]:53365 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis 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, 27 Jun 2011 05:07:47 -0000 --Apple-Mail-4-120697268 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Andrew; My comments below.=20 On Jun 24, 2011, at 11:31 PM, Andrew Allen wrote: > Shida > =20 > Response below. > =20 > Andrew > =20 > From: Shida Schubert [mailto:shida@ntt-at.com]=20 > Sent: Friday, June 24, 2011 7:40 AM > To: Andrew Allen > Cc: SIPCORE Chairs; SIPCORE (Session Initiation Protocol Core) WG > Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis > =20 > =20 > Hi Andrew; > =20 > Thanks for your review.=20 > =20 > My comments inline.=20 > =20 > On Jun 22, 2011, at 12:35 AM, Andrew Allen wrote: >=20 >=20 > Seems I missed the WGLC deadline by a day or so but here are the = comments from my review: > =20 > Section 5 > =20 > "mp": The hi-targeted-to-URI represents a user other than the > user associated with the Request-URI in the incoming request > that was retargeted. >=20 > The term =93user=94 here is confusing. Does it mean the human user = (who might have multiple AoRs/URIs which may or may not be known to the = retargeting proxy as AoRs/URIs that all map to the same human user)? = When retargeting is the proxy supposed to assess whether the new target = URI represents the same human user or not in order to determine whether = to include the =93mp=94 parameter or not? I=92m not sure what = terminology would be best but I think =93user=94 is likely to cause = confusion. > The above issue also reoccurs in section 7 > =20 > Your assumption is same as my understanding of this terminology as = well.=20 > =20 > It could be an individual or it could be a corporate entity. =20 >=20 > [AA] So does the proxy that is doing the re-targeting need to have = definitive knowledge that the two URIs are for the same individual (or = corporate entity)? I am not convinced that a proxy will always know that = this is the case. Often call forwarding is done based on some kind of = user configuration. In some cases the user sets up the forwarding to = another URI of (owned by) the same human user but in other cases it is = not the same human user. For example I can choose to have all my calls = forwarded to some other person (such as wife, friend, or even a hotel = where I am staying). I don=92t know how a proxy can tell that the URI is = for the same human user or not in such circumstances. I think this area = needs further explanation. It assumes that Proxy has way to know whether this is the same user or = not.=20 =20 It could be that the user would indicate that the retargeting target is = a same=20 user when he/she configures the retargeting. And sometime proxy knows = that=20 it is a same user because it is configured as an alias to the original = AoR etc. I agree some text needs to be added.=20 > =20 > Section 15 > =93Entities that have not implemented this specification MUST ignore = these parameters=94? We can=92t make any normative requirements on = entities that have not implemented this specification! Therefore the = MUST should be removed. I think you mean to state that according to RFC = 3261 and RFC 4244 entities that are not compliant with this = specification will ignore these parameters. > =20 > Yes.=20 >=20 > [AA] OK so this will be rephrased to remove the MUST? Yes. It makes no sense to mandate something from non-RFC4244bis = compliant proxy.=20 > =20 > =20 > There is a backward compatibility concern which I think should be = addressed. With 4244bis the URI in the Request-URI is now clearly to be = included in the History-Info when the Request-URI is replaced by the = Contact address. This was not the case in RFC 4244 where in many (if not = most) implementations rewriting the request-URI with the Contact was not = considered retargeting. Some existing UA implementations may have = assumed that the last History-Info entry cannot be their own Contact = Address but will always be their AoR. For example a UA may only look at = the next highest History-Info header field from the bottom most one in = order to determine whether the call arrived as a result of forwarding or = not from within their home domain and what the URI was that it was = forwarded from. Since outside the home domain of the UA up to now the = use of History-Info has not been deterministic some UAs may have only = looked at the last couple of History-Info header fields in order to = determine what happened to the request after it arrived within their = domain. In these kinds of scenarios having a proxy now add an additional = History-Info header field (for the rewriting of the Request-URI to the = Contact) in 4244bis may break the logic of such UAs. I am not saying we = shouldn=92t do this but I think some text about such possible problems = with existing implementations should be indicated in the backwards = compatibility section. > =20 > The definition of retargeting in RFC4244 was not clear and it is = definitely not=20 > defined in RFC3261, so I can understand why some may implement it the = way=20 > you mentioned it. Although example in RFC4244 clearly inserts contact = address=20 > as the History-Info.=20 > =20 > Never the less, we will add some text with regards to this in the = backward=20 > compatibility section. >=20 > [AA] OK > =20 > Section B.1 > =20 > In this example, the Office and Home are not the > same AOR as sip:bob@example.com, but rather different AORs that = have > been configured as alternate addresses for Bob in the proxy. In > other words, Office and Bob are not bound through SIP Registration > with Bob's AOR. > =20 > The opportunity is missed to explain here that this means that the = =93rc=94 parameter is not added. I think it would help to understand if = that was highlighted. > =20 > You are right, but Dale and Hadriel pointed the issue here with not = marking=20 > hi-entry, so we are likely to change these texts as we are likely to = change the=20 > semantics of "rc", from the looks of the discussion.=20 > =20 > We will reflect the followings errors you found.=20 > =20 > As for the details in call-flow B.2 and B.3, the idea is to focus = only on=20 > H-I so it is easier for implementors to see what gets recorded. Do you = prefer=20 > the extended version similar to B.1?=20 > =20 > [AA] Yes I prefer the extended version as this is consistent with the = flows in most other SIP RFCs and also with RFC 4244. At the very least = the Request-URI, History-Info, and Contact headers need to be shown as = these all interact in a meaningful way in History Info. Okay, if that is what people want, we can change it to the extended = version.=20 Regards Shida > =20 > Regards > Shida >=20 >=20 > =20 > =20 > =20 > FLOW F1 > =20 > INVITE sip:alice@example.com should be INVITE sip:bob@example.com > =20 > =20 > FLOW F5 > =20 > Request-URI for the ACK looks wrong to me shouldn=92t it be = bob@192.0.2.4? > =20 > =20 > FLOW F6 > =20 > The URI in the Request-URI and the URI in the bottom most History-Info = header field are not the same (R-URI =3D office@192.0.2.3 and H-I = =3Doffice@192.0.2.5). These should be the same =96 suggest change R-URI = tooffice@192.0.2.5 so as to avoid need to change H-I in the other flows = and also since 192.0.2.3 is Alice=92s UA!!. > =20 > =20 > FLOW F13 > =20 > Again Request-URI for the ACK looks wrong to me shouldn=92t it = behome@192.0.2.6? > =20 > =20 > Examples in B.2 and B.3 do not have the same level of detail as in B.1 = or RFC 4244. > =20 > =20 > Editorials > Last paragraph of 10.1 .2 =93compenent=94 should be =93component=94 > First and 2nd paragraph of 10.3 =93add an hi-index=94/=94adds an = hi-entry=94 should be =93a=94 not =93an=94 > =20 > Regards > Andrew > =20 > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On = Behalf OfPaul Kyzivat > Sent: Sunday, June 05, 2011 7:34 PM > To: SIPCORE (Session Initiation Protocol Core) WG > Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org; SIPCORE Chairs; = Robert Sparks > Subject: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis > =20 > [as co-chair] >=20 > The current editor of draft-ietf-sipcore-rfc4244bis believes that the = document has no remaining technical issues, and is ready for evaluation. = Today, we are starting a two-week working group last call period. This = last call period ends on Sunday, June 19. >=20 > The latest version of the document can be retrieved here: >=20 > http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis >=20 > Any comments on the document should be sent to the SIPCORE mailing = list. >=20 > Thanks, > Paul > ---------------------------------------------------------------------=20= > This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be = unlawful._______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > =20 > ---------------------------------------------------------------------=20= > This transmission (including any attachments) may contain confidential = information, privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be unlawful. --Apple-Mail-4-120697268 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Hi = Andrew;

My comments = below.

On Jun 24, 2011, at 11:31 PM, Andrew = Allen wrote:

From: Shida Schubert = [mailto:shida@ntt-at.com]
Sent: Friday, June 24, 2011 7:40 = AM
To: Andrew = Allen
Cc: SIPCORE Chairs; SIPCORE = (Session Initiation Protocol Core) WG
Subject: Re: [sipcore] WGLC: = draft-ietf-sipcore-rfc4244bis

Hi = Andrew;
Thanks for your = review.
My comments = inline.
On Jun 22, 2011, at 12:35 = AM, Andrew Allen wrote:
Seems = I missed the WGLC deadline by a day or so but here are the comments from = my review:Section 5
"mp": The hi-targeted-to-URI = represents a user other than the user associated with the = Request-URI in the incoming request
that = was retargeted.The term =93user=94 here is confusing. Does it mean the human = user (who might have multiple AoRs/URIs which may or may not be known to = the retargeting proxy as AoRs/URIs that all map to the same human user)? = When retargeting is the proxy supposed to assess whether the new target = URI represents the same human user or not in order to determine whether = to include the =93mp=94 parameter or not? I=92m not sure what = terminology would be best but I think =93user=94 is likely to cause = confusion.
The above issue also reoccurs in section = 7
Your assumption is = same as my understanding of this terminology as = well.
It could be an = individual or it could be a corporate = entity.

[AA] So does the proxy that is doing the = re-targeting need to have definitive knowledge that the two URIs are for = the same individual (or corporate entity)? I am not convinced that a = proxy will always know that this is the case. Often call forwarding is = done based on some kind of user configuration. In some cases the user = sets up the forwarding to another URI of (owned by) the same human user = but in other cases it is not the same human user. For example I can = choose to have all my calls forwarded to some other person (such as = wife, friend, or even a hotel where I am staying). I don=92t know how a = proxy can tell that the URI is for the same human user or not in such = circumstances. I think this area needs further = explanation.

It assumes that Proxy has way to know whether this = is the same user or not.

It could = be that the user would indicate that the retargeting target is a = same

user when he/she configures the retargeting. And = sometime proxy knows that

it is a same user because it = is configured as an alias to the original AoR = etc.

I agree some text needs to be = added.

Section = 15
=93Entities that have not = implemented this specification MUST ignore these = parameters=94? We can=92t = make any normative requirements on entities that have not implemented = this specification! Therefore the MUST should be removed. I think you = mean to state that according to RFC 3261 and RFC 4244 entities that are = not compliant with this specification will ignore these = parameters.

[AA] OK so this will be rephrased to remove the = MUST?

Yes. It makes no sense to mandate something from = non-RFC4244bis compliant proxy.

There is a backward compatibility concern which = I think should be addressed. With 4244bis the URI in the Request-URI is = now clearly to be included in the History-Info when the Request-URI is = replaced by the Contact address. This was not the case in RFC 4244 where = in many (if not most) implementations rewriting the request-URI with the = Contact was not considered retargeting. Some existing UA implementations = may have assumed that the last History-Info entry cannot be their own = Contact Address but will always be their AoR. For example a UA may only = look at the next highest History-Info header field from the bottom most = one in order to determine whether the call arrived as a result of = forwarding or not from within their home domain and what the URI was = that it was forwarded from. Since outside the home domain of the UA up = to now the use of History-Info has not been deterministic some UAs may = have only looked at the last couple of History-Info header fields in = order to determine what happened to the request after it arrived within = their domain. In these kinds of scenarios having a proxy now add an = additional History-Info header field (for the rewriting of the = Request-URI to the Contact) in 4244bis may break the logic of such UAs. = I am not saying we shouldn=92t do this but I think some text about such = possible problems with existing implementations should be indicated in = the backwards compatibility = section.
The definition of = retargeting in RFC4244 was not clear and it is definitely = not
defined in RFC3261, so I = can understand why some may implement it the = way
you mentioned it. = Although example in RFC4244 clearly inserts contact = address
as the = History-Info.
Never the less, we = will add some text with regards to this in the = backward
compatibility = section.

[AA] OK
Section = B.1
In this example, the Office and Home are not = the
   same AOR as sip:bob@example.com, but rather different AORs that = have   been configured = as alternate addresses for Bob in the proxy. In
   = other words, Office and Bob are not bound through SIP = Registrationwith Bob's = AOR.
The opportunity is missed to = explain here that this means that the =93rc=94 parameter is not added. I = think it would help to understand if that was = highlighted.

You are = right, but Dale and Hadriel pointed the issue here with not = marking
hi-entry, so we = are likely to change these texts as we are likely to change = the
semantics of "rc", from = the looks of the discussion.

We will = reflect the followings errors you = found.
As for the details = in call-flow B.2 and B.3, the idea is to focus only = on
H-I so it is easier for = implementors to see what gets recorded. Do you = prefer
the extended version = similar to B.1?
[AA] = Yes I prefer the extended version as this is consistent with the flows = in most other SIP RFCs and also with RFC 4244. At the very least the = Request-URI, History-Info, and Contact headers need to be shown as these = all interact in a meaningful way in History = Info.
<= br>
Okay, if that is what people want, we can change it = to the extended = version.

Regards
&nbs= p;Shida

FLOW = F1

INVITE sip:alice@example.com   should be INVITE sip:bob@example.com

FLOW = F5

Request-URI for the ACK looks = wrong to me shouldn=92t it be bob@192.0.2.4?

FLOW = F6

The URI in the Request-URI and = the URI in the bottom most History-Info header field are not the same = (R-URI =3D office@192.0.2.3 and H-I =3Doffice@192.0.2.5). These should be the same =96 suggest = change R-URI tooffice@192.0.2.5 so as to avoid need to = change H-I in the other flows and also since 192.0.2.3 is Alice=92s = UA!!.
FLOW F13
Again Request-URI for the ACK looks wrong to me = shouldn=92t it be
Examples in B.2 and B.3 do not = have the same level of detail as in B.1 or RFC = 4244.

Last paragraph of 10.1 .2 =93compenent=94 = should be =93component=94
First and 2^nd paragraph of 10.3 =93add an = hi-index=94/=94adds an hi-entry=94 should be =93a=94 not = =93an=94

[mailto:sipcore-bounces@ietf.= org] On Behalf = OfPaul Kyzivat
Sent: Sunday, June 05, 2011 7:34 = PM
To: SIPCORE= (Session Initiation Protocol Core) WG
Cc:  [sipcore] WGLC: = draft-ietf-sipcore-rfc4244bis
[as = co-chair]

The current editor of draft-ietf-sipcore-rfc4244bis = believes that the document has no remaining technical issues, and is = ready for evaluation. Today, we are starting a two-week working group = last call period. This last call period ends on Sunday, June = 19.

The latest version of the document can be retrieved = here:

This transmission = (including any attachments) may contain confidential information, = privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be = unlawful._______________________________________________
sipcore = mailing list
sipcore@ietf.org

This transmission = (including any attachments) may contain confidential information, = privileged material (including material protected by the = solicitor-client or other applicable privileges), or constitute = non-public information. Any use of this information by anyone other than = the intended recipient is prohibited. If you have received this = transmission in error, please immediately reply to the sender and delete = this information from your system. Use, dissemination, distribution, or = reproduction of this transmission by unintended recipients is not = authorized and may be = unlawful.

= --Apple-Mail-4-120697268-- From shida@ntt-at.com Sun Jun 26 22:34: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 28C2E21F861C for ; Sun, 26 Jun 2011 22:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.713 X-Spam-Level: X-Spam-Status: No, score=-99.713 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7I9Bjasb1Lz for ; Sun, 26 Jun 2011 22:34:47 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC5921F85C4 for ; Sun, 26 Jun 2011 22:34:47 -0700 (PDT) Received: from [125.192.75.244] (port=53804 helo=[192.168.11.2]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qb4Su-00010M-Cb; Mon, 27 Jun 2011 00:34:33 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <4E049211.8040209@cisco.com> Date: Mon, 27 Jun 2011 14:34:33 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <67B7434C-1501-4071-BBAF-9C2C79AFA312@ntt-at.com> References: <4DEC205A.5040503@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194E36022D@ESESSCMS0356.eemea.ericsson.se> <2FDD10D8-6DF3-4D77-B300-C05C2AB5D3A2@agnada.com> <7F2072F1E0DE894DA4B517B93C6A0585194E3E71BA@ESESSCMS0356.eemea.ericsson.se> <4DFFB175.5080507@cisco.com> <56BD4DB5-2808-4EA5-BF44-BEC1E5AB0874@ntt-at.com> <4E049211.8040209@cisco.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.1084) 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: flh1agj244.tky.mesh.ad.jp ([192.168.11.2]) [125.192.75.244]:53804 X-Source-Auth: shida@agnada.com X-Email-Count: 11 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org, Robert Sparks , "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis 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, 27 Jun 2011 05:34:48 -0000 Hi Paul; My comments inline. On Jun 24, 2011, at 10:33 PM, Paul Kyzivat wrote: >=20 >=20 > On 6/24/2011 8:16 AM, Shida Schubert wrote: >>=20 >> Paul; >>=20 >> Are you suggesting to include three hi-entries, >> whenever an entity retargeting the tel-URI >> logs it to H-I? >>=20 >> e.g. >>=20 >> History-Info :;index=3D1 >> History-Info :; index=3D1.1; = mp=3D1 >> History-Info :;index=3D1.2, rc=3D1.1 >> (based on the new semantics Hadriel suggested) >=20 > That seems about right. (I'm not sure about the tags, just because I = haven't been following that closely.) >=20 >> In that case, how do you think the privacy of the tel URI >> should be handled? >=20 > I guess you are asking because a privacy header can't be affixed to a = tel uri? >=20 > If so, that suggests to me that handling privacy by embedding a = privacy header into the URI was a mistake. This wasn't what I was asking per se. =20 =20 We can't express the desired way privacy is handled for tel URI due to = the constrain=20 you mentioned above, but what we can say in the draft is to suggest the = use of Privacy=20 header field instead of Privacy header embedded in the URI when tel URI = is in the list=20 of H-I which needs to be anonymized.=20 * Another question about anonymizing tel URI, AFAIK there is no = guideline on how=20 one anonymizes tel URI? I guess if there is domain in = "phone-context", we change that=20 to "invalid.domain" or something. (May be in the security = consideration?) >=20 >> Should the proxy apply the same privacy policy that it would >> apply to the SIP URI? >=20 > Oh. Do you mean that when privacy is applied by hiding things = belonging to the proxy's domain, how does it decide that this should be = hidden too? Yes.=20 >=20 > If it is hiding things because not hiding them would expose domain = addresses, then there is no reason to hide the tel uri, since it doesn't = expose a domain address. >=20 > NOTE: That is precisely why tel URIs are *not* equivalent to their sip = "equivalent" URIs. The tel uri implies no domain - anyone wanting to = call it is both free and obligated to seek out its own way of routing = it. Calls to sip URIs are constrained to be routed based on the domain = of the URI until reaching a server responsible for that domain. >=20 > For instance, if you have sip:+12121234567@example.com, and you have a = device that has connectivity to both the pstn and internet, you are = really obligated to route it to example.com. And if you currently only = have pstn connectivity you ought not send it via the pstn. >=20 > But if you have tel:+12121234567, you are free to do whatever you = want. >=20 > I know may devices will simply *assume* the sip uri is equivalent to a = tel uri. But that isn't really proper. The device may have important = features that can't work over a pstn connection. >=20 > (These comments are really from an individual, rather than chair, = perspective.) So are you saying that privacy of tel URI shouldn't be a concern of a = proxy that is=20 handling the request, as long as the domain isn't exposed?=20 Regards Shida >=20 > Thanks, > Paul >=20 >> Regards >> Shida >>=20 >> On Jun 21, 2011, at 5:45 AM, Paul Kyzivat wrote: >>=20 >>> (as individual) >>>=20 >>> On 6/17/2011 3:25 AM, Christer Holmberg wrote: >>>=20 >>>>>> 3. Tel to Sip transformation: History-Info (technical) >>>>>> =09 >>>>>> Related to the previous question, the text doesn't indicate = whether the transformation from Tel to Sip should be recorded in an = History-Info header field. The Request-URI is, after all, >>>>>> changed. >>>>> =09 >>>>>=20 >>>>> I don't know if we need to add anything specific for this. The = draft doesn't limit the >>>>> behavior of the entity recording H-I to only record SIP-URI, it = just says to record the >>>>> R-URI. >>>>=20 >>>> Based on the comments I get, the text seems to indicate that you = shouldn't insert a Tel in a History-Info in the first place. Instead you = should transform it to a SIP-URI before inserting it. >>>=20 >>> I agree with Christer (!!!) that the transformation from tel: to = sip: *is* a change, and if you care about H-I then this ought to be = recorded. >>>=20 >>> (This is not just a superficial change in representation - it is a = *semantic* change, because different processing rules apply to sip URIs = that tel URIs.) >>>=20 >>> There isn't even a guarantee that a proxy will have a suitable way = to re-represent a tel uri as a sip URI. >>>=20 >>> So I think this calls for some sort of explanation. I guess its = lucky that if you do create H-I entries for this, that its the = translated (sip) URI that gets the parameters added. So its at least = *possible* to do this. >>>=20 >>> Thanks, >>> Paul >>=20 >>=20 From shida@ntt-at.com Mon Jun 27 00:13: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 0E82C21F85D4 for ; Mon, 27 Jun 2011 00:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.689 X-Spam-Level: X-Spam-Status: No, score=-99.689 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ol0ihvZfEDCO for ; Mon, 27 Jun 2011 00:13:22 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id B0A3221F85F0 for ; Mon, 27 Jun 2011 00:13:20 -0700 (PDT) Received: from [125.192.75.244] (port=56323 helo=[192.168.11.2]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qb60S-0004uW-LE; Mon, 27 Jun 2011 02:13:17 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <2C58A5B7-9EDE-4774-80B6-CE839EF59ACF@cisco.com> Date: Mon, 27 Jun 2011 16:13:14 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <6E7C7223-0667-43B3-AFA8-323E89AB7B05@ntt-at.com> References: <4DEC205A.5040503@cisco.com> <2C58A5B7-9EDE-4774-80B6-CE839EF59ACF@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) 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: flh1agj244.tky.mesh.ad.jp ([192.168.11.2]) [125.192.75.244]:56323 X-Source-Auth: shida@agnada.com X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: draft-ietf-sipcore-rfc4244bis@tools.ietf.org, "sipcore@ietf.org WG" Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-rfc4244bis 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, 27 Jun 2011 07:13:26 -0000 Hi Cullen; Thanks for your review and comments.=20 My comments inline. On Jun 22, 2011, at 8:08 AM, Cullen Jennings wrote: >=20 > Privacy issue: There is no way to know that the next downstream proxy = support the processing required by the privacy header.=20 That is generally true for any privacy mechanism based on 3323, this is = not a problem limited to 4244/4244bis.=20 Most deployments I am aware of have these servers that handle the = privacy.=20 > What's this for: The most concrete use is making sure a call arriving = at a voice mail servers goes to the correct mailbox. However, the draft = is woefully underspecified to be able to implement this from the draft. = This draft specifies a bunch of data that can get dumped in a bag, but = to allow interoperable implementation, it needs to say how one could use = that data for some actually feature.=20 We tried to cover these use-cases in section 3.3/3.4 of = 4244bis-callflow draft. I am not sure, the example will satisfy you, but let me know what you = think. >=20 > As a coauthor of 4244, I agree this draft is better than 4244 but I = don't think it is ready to publish.Given what we have learned about 4244 = since it was published, I would support 4244 being changed to historic.=20= >=20 > Does it work? Consider text such as =20 >=20 > Note, this would be > the original AoR if all the entities involved support the > History-info header field and there is absence of an "mp" header > field parameter prior to the "rc" header field parameter in the > hi-target-param in the History-info header field. However, = there > is no guarantee that all entities will support History-Info, = thus > the hi-entry that matches the value of the "rc" parameter of the > first hi-entry with an "rc" parameter in the hi-target-param > within the domain associated with the target URI at the > destination is more likely to be useful. >=20 > This amounts to you might some information you want at X but then = again you might not. The whole draft is like this - it's pretty hard to = imagine this will reliably work for nearly any purpose I can think of = given the limitations of the draft.=20 I think it definitely has some uses and is valuable, even it is only = supported within one domain=20 which intend to use this.=20 Sure, there is a good chance that some information may get lost or may = not exist in the=20 first place when it crosses the domain due to the reason you mentioned = above, but as long=20 as all the entities within a domain who wants to use it, supports it, I = believe it provides useful=20 information..=20 >=20 > Backwards Compatibly - yes the syntax is backwards compatible but no = effort has been put into consider what would happen if some elements in = the network were doing 4244 and some where doing 4244bis. I am looking at this in more details right now, as I had some internal = people form my company=20 showing concern about this as well. I am hoping to add the summary of my = findings in the next=20 revision.=20 >=20 > Implementations: I'd like to know about implementations that were = going to use this data. And by use, I don't mean write to the history = header but instead ones that are going to read from it and use the = information for some purpose.=20 >=20 > Does not meet requirements. As far as I can tell, the draft does not = meet the requirements outline in section A.1 of the draft.=20 Do you mind being more specific if it is particular requirement you are = talking about or=20 are you saying all the requirements aren't satisfied by the mechanism? Thanks Shida >=20 >=20 >=20 >=20 >=20 >=20 > On Jun 5, 2011, at 17:33 , Paul Kyzivat wrote: >=20 >> [as co-chair] >>=20 >> The current editor of draft-ietf-sipcore-rfc4244bis believes that the = document has no remaining technical issues, and is ready for evaluation. = Today, we are starting a two-week working group last call period. This = last call period ends on Sunday, June 19. >>=20 >> The latest version of the document can be retrieved here: >>=20 >> http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis >>=20 >> Any comments on the document should be sent to the SIPCORE mailing = list. >>=20 >> Thanks, >> Paul >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 From dworley@avaya.com Wed Jun 29 09:08: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 E11A711E8076 for ; Wed, 29 Jun 2011 09:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wh+PD2+hw7-S for ; Wed, 29 Jun 2011 09:08:47 -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 BFF139E8044 for ; Wed, 29 Jun 2011 09:08:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMGAEVNC07GmAcF/2dsb2JhbABICqdecAerPINtAptDgymDBwSXKYpUYA X-IronPort-AV: E=Sophos;i="4.65,443,1304308800"; d="scan'208";a="287797015" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 29 Jun 2011 12:08:45 -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; 29 Jun 2011 12:07:56 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Wed, 29 Jun 2011 12:08:44 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Wed, 29 Jun 2011 12:07:49 -0400 Thread-Topic: 4244bis Application processing Thread-Index: AQHMNnbR1jQGF7ByY0+jF5iWwb8Uug== 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] 4244bis Application processing 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, 29 Jun 2011 16:08:48 -0000 The initial part of section 11 "Application Considerations" discusses "gaps" in the H-I values. Unfortunately, it doesn't distinguish between two very different types of gaps. One type of gap is due to a non-H-I-supporting proxy. In the system of the draft, this results in an hi-entry with index "1" that is not the first (root (almost)) hi-entry. If we use the alternative proposal, a non-H-I-supporting proxy results in an hi-entry that is fit into the tree structure in the ordinary way and is not distinguishable (although it has no hi-target-param). The second type of gap is due to elder forks which had not yet returned non-100 responses. These gaps can be detected by examining the index numbers; a gap of this type is evidenced by an index that is present whose last component is greater than 1, but there is no hi-entry whose index is the same except for having a last component 1 less. Note that there is another sort of gap which is entirely undetectable: a younger fork. But in the case of parallel forking, the "current" fork, its elder forks, and its younger forks are all have equal status. The fact that younger forks cannot be detected warns us to follow the following principle: Gaps in the hi-entries are to be expected, and sometimes are undetectable. Thus, any processing applied to History-Info that requires that there are no gaps in the hi-entries will likely be unsuccessful in practice. The current section 11 gives some simple algorithms that can be applied to H-I to extract information. I believe that more effective algorithms can be constructed based on the following considerations: Each hi-entry (explicitly or implicitly) points to an "ancestor" hi-entry from whose hi-targeted-to-uri its hi-targeted-to-uri was derived (possibly through several steps, if some intermediate SIP entities did not implement H-I). The "ancestor" hi-entry is always before the hi-entry in the pre-order. If the hi-entry has an hi-target-param, the value of the parameter is the index of the ancestor hi-entry. If the hi-entry does not have an hi-target-param, the ancestor hi-entry is its parent in the tree, whose index is the same except for having the last component deleted. Starting at the current hi-entry (the last one sequentially, which corresponds to the request received by this SIP entity), the chain of ancestor hi-entries shows the derivation of the current Request-URI, and where hi-target-params are present, it shows the nature of each derivation step. The application should examine the hi-targeted-to-uris in the chain of ancestor hi-entries to see which of them it recognizes as being within its domain of responsibility, and whose semantics it understands. The examination should stop when it first reaches an hi-targeted-to-uri that it does not understand. In many cases, there will be earlier hi-entries in the chain because of various retargetings applied by the caller's services, and possibly due to intermediate services. And sometimes there will be hi-entries in the chain that the applicaiton understands that are earlier than hi-entries in the chain that the application does not understand. The application should not make the mistake of considering these hi-entries -- they are are due to an earlier passage through (and out of) its domain, and do not describe how the request entered the domain and reached the application. To emphasize, the application starts at the hi-entry describing the request that it received, and successively examines the ancestor hi-entries, and *stops* when it sees an hi-entry that it does not understand. This chain of hi-entries tells what URI the request had when it entered the domain, and how it progressed through the domain to the application. In addition, the application can examine sibling hi-entries of the ancestor hi-entries that it understands to determine alternative destinations for the call that have already been attempted. Looking at the use cases in draft-barnes-sipcore-rfc4244bis-callflows-01, we can apply this approach to implement the described use cases: 3.1. Automatic Call Distribution In this example, it is envisioned that example.com has two AORs, and . Different categories of customers are given different AORs to call for customer service, and due to that, the calls may be routed differently within example.com's call center. In addition, calls originally targeted at one AOR may be routed to the other (due to overflow, etc.). What is needed is: - Determine which AOR the call was "originally" targeted to. - Determine the set of retargetings the call was subjected to within example.com (as that may indicate how long the caller has been waiting, etc.) (Note that retargeting from one AOR to another in this situation is not recommended. Better is to retarget Silver -> silver-agents and Gold -> (both gold-agents and silver-agents), so that no call ever is routed through more than one AOR.) Following the chain of ancestor hi-entries eventually reaches the hi-entry describing how the call was targets to example.com originally: either sip:Gold@example.com or sip:Silver@example.com. The chain itself documents what retargeting the call has gone through. The example is: History-Info: ;index=3D1 History-Info: ;\ index=3D1.1 History-Info: ;index=3D1.2;mp=3D1 History-Info: ;index=3D1.2.1 History-Info: ;index=3D1.2.1.1;rc=3D1.2.1 The chain of ancestor hi-entries is: ;index=3D1.2.1.1;rc=3D1.2.1 ;index=3D1.2.1 ;index=3D1.2;mp=3D1 ;index=3D1 showing that the call was made to and that it has been retargeted from Gold to Silver. 3.2. Determining the Alias used. History-Info: ;index=3D1; History-Info: ;index= =3D1.1;rc=3D1; History-Info: ;index=3D1.2;rc=3D1; The chain of ancestor hi-entries is: ;index=3D1.2;rc=3D1; ;index=3D1; The UA recognizes as (one of) its contact URIs, and as an AOR/alias which it has been configured to treat specially. 3.3. PBX Voicemail Example In this example, a call to Bob has been call-forward-always to Carol, who has not answered. The proxy handling the call wants to route the call to the voicemail system, using Bob's mailbox not Carol's mailbox. This requires determining that the call "was originally for Bob". The History-Info of the failed call to Carol is as follows. (This has been updated with the failure reason, and is actually the cache at the proxy at the time the INVITE to the VM system is generated.) History-Info: ;index=3D1 History-Info: ;\ index=3D1.1;rc=3D1 History-Info: ;index=3D1.2;mp=3D1 History-Info: ;\ index=3D1.2.1;rc=3D1.2 (Note that the chain must start at the hi-entry of the failed fork. there may have been younger forks added since that fork was initiated, so the failed fork may not be the last hi-entry.) The chain of ancestor hi-entries is: ;index=3D1.2.1;rc=3D1.= 2 ;index=3D1.2;mp=3D1 ;index=3D1 The application recognizes indexes 1.2 and 1 as AORs for the system, and so can route the call to the VM system knowing that the "original callee" is sip:bob@example.com, and the cause for sending the call to VM was no-answer. 3.4. Consumer Voicemail Example History-Info: ;index=3D1 History-Info: ;\ index=3D1.1;rc History-Info: ;\ index=3D1.2;mp=3D1 History-Info: ;index=3D1.2.1;rc=3D1.2 The chain of ancestor hi-entries is: ;index=3D1.2;mp=3D1 ;index=3D1 In this case, the desired behavior is for the call to go to Carol's voicemail, and the application, seeing that hi-entry 1.2 contains Carol's AOR, it looks no further back. 3.5. GRUU History-Info: ;index=3D1 History-Info: ;index=3D1.1 The chain of ancestor hi-entries is: ;index=3D1.1 ;index=3D1 The application can see that its contact URI was derived from the GRUU at index 1. 3.6. Limited Use Address [accessing URI parameters in a mapped-from URI] History-Info: ;index=3D1 History-Info: ;index=3D1.1 The chain of ancestor hi-entries is: ;index=3D1.1 ;inde= x=3D1 Since the application knows it has provided limited-use-addresses that map into sip:john@192.0.2.1, it knows to look at the ancestor hi-entry to find the additional information. 3.7. Service Invocation History-Info: ;index=3D1, ;index=3D1.1;mp=3D1, ;index=3D1.1.1, ;index=3D1.1.2;rc=3D1.1 The chain of ancestor hi-entries is: ;index=3D1.1.2;rc=3D1.1 ;index=3D1.1;mp=3D1, ;index=3D1, The application knows that the first URI is its contact, and that the second URI is the PSTN incoming number, and so it examines the 3rd URI to find the toll-free PSTN number that indicates the service that is desired. Dale From eburger@standardstrack.com Thu Jun 30 04:38: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 5236021F8821 for ; Thu, 30 Jun 2011 04:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.27 X-Spam-Level: X-Spam-Status: No, score=-102.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a35r3A5Ho1vK for ; Thu, 30 Jun 2011 04:38:06 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7E47021F881A for ; Thu, 30 Jun 2011 04:38:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:From:Content-Type:Subject:Date:Message-Id:To:Mime-Version:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=D2L/yEvZJDFD2bAnQ0PzdcAemFsgOh32Bj7CNSE5s4IQhHjYfSlLJxbkkDGzMQhcj1Vgt3827v8hhBtEylqxIlQGapiTM3wwDE/ouI90zagdIxMmcCJ1svBD+QfI8s2E; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.126]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QcFZI-0007Jc-GP for sipcore@ietf.org; Thu, 30 Jun 2011 04:38:00 -0700 From: Eric Burger Content-Type: multipart/signed; boundary=Apple-Mail-69-414197752; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 30 Jun 2011 07:37:59 -0400 Message-Id: <8808E166-BEDA-4AAB-A75B-39D58A8F169A@standardstrack.com> To: sipcore@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [sipcore] How to do a Man-in-the-Middle attack using STUN and TURN 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, 30 Jun 2011 11:38:07 -0000 --Apple-Mail-69-414197752 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii h= ttp://appft1.uspto.gov/netacgi/nph-Parser?Sect1=3DPTO2&Sect2=3DHITOFF&p=3D= 1&u=3D/netahtml/PTO/search-bool.html&r=3D1&f=3DG&l=3D50&co1=3DAND&d=3DPG01= &s1=3D20110153809.PGNR.&OS=3DDN/20110153809RS=3DDN/20110153809= --Apple-Mail-69-414197752 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA2MzAxMTM3NTlaMCMGCSqGSIb3DQEJ BDEWBBS1i9dLwKhGv2Voe3t6imtUoLquFjCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAKlrjZS03ByrbOti21AZEmmxhr3a3euRajtUN5StxOFOkivl U2fG1va7Q1skv6IwNNbOkPLIWhsC9jhWo6NTt5kyehqRNl8vz3lV9r+QPUDzklBHuYWfgABRoKKF 0r9smcJcFJzoi2IUcI0y3xkWl9U9o/WIWN+iWpmudlyZ3srF0LisROcnVYFwob00q7njKFq2dyCv yvPdhG7oooNcgDvN2p26RtW0O0qVByjX89e8ojwaD7IIn6aCpQnYFrAzStYzG+L1cWstB/KKDY29 +pSmJgYMZZv6Y1pgNWRpWJmK0D4dEdVGCnMU+Tz9kdGl5twpDKsfdsYFOGRyNfrzAssAAAAAAAA= --Apple-Mail-69-414197752-- From dworley@avaya.com Thu Jun 30 12:17: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 37D3211E8201 for ; Thu, 30 Jun 2011 12:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.974 X-Spam-Level: X-Spam-Status: No, score=-102.974 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMcOM5qWD8gT for ; Thu, 30 Jun 2011 12:17:39 -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 636F911E81E8 for ; Thu, 30 Jun 2011 12:17:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0HAFLLDE6HCzI1/2dsb2JhbABFDadacAeoZoNzApsfAoMegxEEl0KLNw X-IronPort-AV: E=Sophos;i="4.65,454,1304308800"; d="scan'208";a="254272674" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 30 Jun 2011 15:17:37 -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; 30 Jun 2011 15:11:00 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Thu, 30 Jun 2011 15:17:36 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Thu, 30 Jun 2011 15:17:35 -0400 Thread-Topic: 4244bis: Describing redirections Thread-Index: AQHMN1iiQ88nfcLVj0Oe0yxoNpSGSQ== 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] 4244bis: Describing redirections 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, 30 Jun 2011 19:17:40 -0000 Here's another unpleasant case: Suppose sip:A is redirected to sip:B. The UAS for sip:B returns a 3xx response, with "Contact: sip:C", but *without* an hi-target-param (presumably because the UAS does not support H-I). We want to be able to document that sip:C was derived from sip:B (as opposed to the default sip:A, which is also true, but gives less information), but we cannot do so because we don't know what hi-target-param would be correct. The H-I at this point looks like: History-Info: ;index=3D1, ;index=3D1.1, ;index=3D1.2;??=3D1.1 but there is nothing that can be correctly put in place of "??". Here is one possibility: Have one H-I parameter solely for carrying the "predecessor" pointer. Let's give it a really short name, like "p". Have several other H-I parameters that are flags (they have no values) that document *how* the current URI was derived from the URI pointed to by "p". (If we don't mind the additional bytes, vendors can add further proprietary values, not in replacement of the standard values, but as additional annotations to them.) The types of redirection that I know of are: - "rc" ("registered contact") - Conversion of an AOR to its contact via a location service (as described in RFC 3261). - "mp" ("mapping") - Replacement of a URI by another URI that (either in fact or is typical for this replacement operation) is "a different user", in that the new URI's identity (from a human point of view) is not subsumed in the old URI's identity. - "gr" ("GRUU") - Replacement of a GRUU by the GRUU's contact value. (Strictly, we can probably omit indicating this as the "gr" situation can be determined by examining the URIs.) - "hi" ("History-Info compatibility") - This hi-entry was added when the request entered an entity that supports History-Info because the last hi-entry (if any) did not match the Request-URI. A typical example would be: History-Info: ;index=3D1;hi History-Info: ;index=3D1.1= ;p=3D1;rc History-Info: ;index=3D1.2;p=3D1;mp History-Info: ;index=3D1.2.1 Alternatively, we could have the "type of redirection" be the values of a single parameter name, or we could append the codes to the "index" value (which would save space). Dale From adam@nostrum.com Thu Jun 30 13:57: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 00E6F11E80C9 for ; Thu, 30 Jun 2011 13:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qN6sB4z2e-3 for ; Thu, 30 Jun 2011 13:57:36 -0700 (PDT) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by ietfa.amsl.com (Postfix) with ESMTP id 115F111E80DF for ; Thu, 30 Jun 2011 13:57:35 -0700 (PDT) Received: from dn3-110.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 p5UKuFMM064491 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 30 Jun 2011 15:56:15 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4E0CE2F0.803@nostrum.com> Date: Thu, 30 Jun 2011 15:56:16 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Christer Holmberg References: <4C6C5147.7090304@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851B7B8A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851B7B8A@ESESSCMS0356.eemea.ericsson.se> 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) Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Comments on 3265bis-02 (CHH) 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, 30 Jun 2011 20:57:37 -0000 On 8/23/10 4:05 AM, Christer Holmberg wrote: > > QE1: The docuements sometimes uses "message", sometimes "request", and sometimes nothing after the method name. We should be consistant. I changed them all to "request." > QE2: There are many instances of "as defined in SIP [ref]", "as describe in SIP [ref]", etc. I think it is enough to only use the reference. Fixed. > > QE3: Expand GRUU abbreviation on first occurance. Done. > QE4: Where the document talks about crating a dialog, should it be dialog usage instead? In a few places, yes. Fixed. > QE5: Section 4.1.2.2: When reading the text regarding RFC 5839 it seems like it's mandatory to support. Also, if we want to talk about 5839 in specific sections I think we will need text elsewhere also. I would suggest to remove the text from 4.1.2.2, and have a specific section where we talk about compatibility with 5839. There's nothing to be done for compatibility with 5839, except for not running timer N when you get a 204. I don't believe the document warrants an entire new section to say this one thing. I have added the word "optional" to the sentence to remove any implication that 5839 is mandatory to implement: "...such as the 204 response defined for use with the optional extension described in [RFC5839]..." > QE6: Section 3.1.1: "the implied default is defined" -> "the implied default MUST be defined" Okay. > QE7: Section 3.2.1: "header fields will contain a single" -> "header fields MUST contain a single" Okay. > QE8: Section 4.1.2.3: "the final NOTIFY may or may not". Remove "or may not". I think both possibilities are as important as each other, and I wouldn't want to de-emphasize either of them. > QE9: Section 4.1.2.4: "Documents which define new event packages MUST" -> "Event package specifications MUST" Okay. > FUNCTIONAL: > =========== > > QF1: Section 3.1.3 says that Event packages must define behavior for SUB requests without Accept header. 3261 says that, in case there is no Accept header, the default value is "application/sdp". I don't think 3265bis should change that. That text is from 3265, and I'm certain that implementations are out in the field that count on such a behavior. What you propose isn't backwards compatible. > QF2: The document contains lots of SHOULDs, without any explanation on when something applies, and when it doesn't. It makes it very difficult to specify and perform conformance tests, and in most of the 3265bis occurances it might also cause state unsynch among entities. So, I think we should have MUST - or explain when SHOULD applies, and when it doesn't. The vast, vast majority of these predate 3265bis. Blindly taking normative statements from SHOULD to MUST will arbitrarily make legacy implementations noncompliant -- and, in some cases, incompatible. Your alternate suggestion steps on one of the things that I think has gone very wrong with RAI in the past few years. Please bear with me while I vent my spleen for a moment on that topic. In terms of explaining when SHOULD-level normative statements can be violated -- I strongly disagree with the current (RAI-only) cultural bent that requires all SHOULD normative requirements to be accompanied by enumerated lists. Such an approach effectively removes "SHOULD" and "SHOULD NOT" completely from the lexicon, replacing them with "MUST... unless..." and "MUST NOT... unless...". If you go back 10 years, or step outside of RAI, there's a culture of *allowing* those things that don't break interoperability. All of the SHOULD-level statements in 3265/3265bis are statements of things that make the system work *better*; none of them are required for the system to *work*. I understand that some implementors will do profoundly stupid things, cut corners, and intentionally misread portions of specifications to suit their level of skill, motivation, and timelines. And I know that using "SHOULD" appears to give them some kind of a moral "out" to do so. But there's nothing we can say here that will change that kind of behavior: failing to implement a MUST is just as easy as failing to implement a SHOULD, and there's no armed force that's going to police the difference. But it's insulting to implementors and constraining to future extensions to place hard prohibitions in protocol specifications where they aren't necessary. Good implementors can determine when circumstances warrant violation of SHOULD-strength requirements, even if they fall outside circumstances we can presently enumerate. That said, I'm not opposed to adding *examples* of exceptions to SHOULD-strength statements. I just don't think they're necessary. So, if you'd like to see such examples added: send text. > QF2a: Section 4.1.2.2 says that if specific SUB responses are received, the subscriber should consider the subscription terminated. In this particular instance, I agree that a change may be helpful. I think it really should be a normative "MUST". > QF2b: Section 4.1.2.4 says that the subscriber SHOULD reject a NOT after Timer N expireation. This is a good example where failing to implement the SHOULD won't cause interop problems. I don't think a change is warranted. > QF2c: Section 4.2.1.4 says that the notifier SHOULD send a NOT with "terminated" state. This is a good example of legacy behavior that we can't change without potentially making existing deployment non-interoperable. Additionally, since both ends are running the same timers, this NOTIFY is really just a safety net. Failing to send it won't cause any problems unless something *else* has been mis-implemented. > QF2d: Section 4.2.2 says that the notifier SHOULD remove the subscription if NOT fails due to Timer F expireation. Again, no interop issues here. There's non-normative text that tells implementors why they *want* to do this. But failing to do it doesn't break the system. > QF2e: Section 4.2.3. I guess a notifier that doesn't support PINT MUST return 489 in case of SUB without an Event header field? What's really important here, from an interop perspective, is that the transaction fails. Exactly *how* it fails isn't important. And what's cool is that there's no hope of it succeeding, since there's no event package specified. So it's really just a Nice Thing [tm] for troubleshooting. > QF3: Section 4.3. Do we need to say that the Timer N expiration procedures etc also apply to stateless proxies? I'm confused. Stateless proxies don't maintain state. They don't need to run timer N. > QF4: Section 4.4.1 says that a subscription is terminated after a notifier sends a NOT with "terminated". I think we should add ", or when Timer N expires.", to cover the case when there is no NOT. > The statement wasn't meant to be exhaustive, but I can see how it might be confusing. Of course, those aren't the only two circumstances that can result in a subscription going away -- there are a wide variety of error situations that can cause that. I've added text: A subscription is destroyed after a notifier sends a NOTIFY request with a "Subscription-State" of "terminated," or in certain error situations. /a From adam@nostrum.com Thu Jun 30 14:27: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 09C7921F883F for ; Thu, 30 Jun 2011 14:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.879 X-Spam-Level: X-Spam-Status: No, score=-101.879 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLouTa8KYozc for ; Thu, 30 Jun 2011 14:27:52 -0700 (PDT) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by ietfa.amsl.com (Postfix) with ESMTP id 61DB521F8839 for ; Thu, 30 Jun 2011 14:27:52 -0700 (PDT) Received: from dn3-110.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 p5ULQMjb067310 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 30 Jun 2011 16:26:23 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4E0CE9FF.3010801@nostrum.com> Date: Thu, 30 Jun 2011 16:26:23 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Paul Kyzivat References: <4C6C5147.7090304@nostrum.com> <4C6D53F1.5020409@cisco.com> <4C6DAAA7.8080507@nostrum.com> <4C6DBF67.5000401@cisco.com> In-Reply-To: <4C6DBF67.5000401@cisco.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) Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] 3265bis-02 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, 30 Jun 2011 21:27:53 -0000 On 8/19/10 6:33 PM, Paul Kyzivat wrote: > > > Adam Roach wrote: >> >> [as individual] >> >> On 8/19/10 10:55 AM, Paul Kyzivat wrote: >>> First, I question some changes you made to the state model picture >>> in 4.1.2. Now Timer N expiry is a trigger for moving to Terminated >>> from Pending or Active. How can that be right? >> >> This is part of the change to make Timer N apply to subscription >> refreshes. When a subscription is in Active (and even Pending, if >> permission pends for longer than a refresh period), the subscriber >> periodically sends new SUBSCRIBE messages to refresh the expiration. >> The document *now* says that these refreshes cause Timer N to be set. >> If no NOTIFY arrives before Timer N expires, then the subscription >> will transition from Active (or Pending) to Terminated. > > I understand how Timer N should apply after sending a resubscribe. > But that is not how I read the diagram. The diagram says to me that > the following is a common scenario: > > - I send an initial subscribe and enter notify-wait > - I receive a NOTIFY with pending, and enter pending. > - If I don't get another notify within Timer N, > I enter terminated state. > - To avoid that fate, before Timer N expires I can send a resubscribe, > thus resetting Timer N and (I guess) going back into notify-wait. > > If I send a subscribe that goes into pending, it could be hours or > days until the notifier's user gets around to blessing me. The above > analysis says that for all that time I'll be sending a new resubscribe > every Timer N seconds. That doesn't seem desirable. > > IIUC, the intended behavior is that when in pending or active, one is > waiting for the *expires* timer to run down. (It of course gets > updated with each notify received.) When it runs down enough, a new > subscribe should be sent, and then timer N is set again for the first > notify after that. But I don't get that behavior out of the existing > diagram. > > One way to show that would be: > > From pending and active, > - sending a resubscribe causes transition back to notify-wait. > - exhaustion of the expires timer causes transition to terminated. The issue with that approach is that it causes confusion with regards to RFC 3857 (winfo) handling. I'm hesitant to take the subscription out of "pending" and "active," since it will almost certainly confuse people trying to implement winfo. ("But RFC XXXX says that you leave 'active' state when you send a re-SUBSCRIBE, so don't we need to change the value in the winfo doc?"). That said, I can see why the diagram is wrong, since Timer N is still actually running. So what we really need to say for the exit from "pending" and "active" is something like "Timer N fires before receiving a NOTIFY for a subscription refresh." That's a bit long for the diagram. Perhaps "Re-subscription times out," with an explanation below? Something like: +-------------+ | init |<-----------------------+ +-------------+ | | Retry-after Send SUBSCRIBE expires | | V Timer N Fires; | +-------------+ SUBSCRIBE failure | +------------| notify_wait |-- response; --------+ | | +-------------+ or NOTIFY, | | | | state=terminated | | | | | | ++========|===================|============================|==|====++ || | | V | || || Receive NOTIFY, Receive NOTIFY, +-------------+ || || state=active state=pending | terminated | || || | | +-------------+ || || | | Re-subscription A A || || | V times out; | | || || | +-------------+ Receive NOTIFY, | | || || | | pending |-- state=terminated; --+ | || || | +-------------+ or 481 response | || || | | to SUBSCRIBE | || || | Receive NOTIFY, refresh | || || | state=active | || || | | Re-subscription | || || | V times out; | || || | +-------------+ Receive NOTIFY, | || || +----------->| active |-- state=terminated; -----+ || || +-------------+ or 481 response || || to SUBSCRIBE || || Subscription refresh || ++=================================================================++ In the state diagram, "Re-subscription times out" means that an attempt to refresh or update the subscription using a new SUBSCRIBE request does not result in a NOTIFY request before the corresponding Timer N expires. What do you think? /a From R.Jesske@telekom.de Thu Jun 30 20:42: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 135081F0C4B for ; Thu, 30 Jun 2011 20:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRqUvr3HAKnW for ; Thu, 30 Jun 2011 20:42:41 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 3D36B1F0C56 for ; Thu, 30 Jun 2011 20:42:41 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 01 Jul 2011 05:42:36 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.157]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 1 Jul 2011 05:42:35 +0200 From: To: , Date: Fri, 1 Jul 2011 05:42:31 +0200 Thread-Topic: 4244bis: Describing redirections Thread-Index: AQHMN1iiQ88nfcLVj0Oe0yxoNpSGSZTW0b1w Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D090D2DFCB0@HE111648.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] 4244bis: Describing redirections 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, 01 Jul 2011 03:42:42 -0000 Hi Dale, How often will this happen? Due to the fact that the hi-target-param is an optional parameter I would p= ut in nothing. I think additional parameters would more confuse than help. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Worley, Dale R (Dale) > Gesendet: Donnerstag, 30. Juni 2011 21:18 > An: sipcore@ietf.org > Betreff: [sipcore] 4244bis: Describing redirections > > Here's another unpleasant case: > > Suppose sip:A is redirected to sip:B. The UAS for sip:B returns a 3xx > response, with "Contact: sip:C", but *without* an hi-target-param > (presumably because the UAS does not support H-I). We want to be able > to document that sip:C was derived from sip:B (as opposed to the > default sip:A, which is also true, but gives less information), but we > cannot do so because we don't know what hi-target-param would be > correct. > > The H-I at this point looks like: > > History-Info: ;index=3D1, > ;index=3D1.1, > ;index=3D1.2;??=3D1.1 > > but there is nothing that can be correctly put in place of "??". > > Here is one possibility: > > Have one H-I parameter solely for carrying the "predecessor" pointer. > Let's give it a really short name, like "p". > > Have several other H-I parameters that are flags (they have no values) > that document *how* the current URI was derived from the URI pointed > to by "p". (If we don't mind the additional bytes, vendors can add > further proprietary values, not in replacement of the standard values, > but as additional annotations to them.) The types of redirection that > I know of are: > > - "rc" ("registered contact") - Conversion of an AOR to its > contact via > a location service (as described in RFC 3261). > > - "mp" ("mapping") - Replacement of a URI by another URI that (either > in fact or is typical for this replacement operation) is "a > different user", in that the new URI's identity (from a human point > of view) is not subsumed in the old URI's identity. > > - "gr" ("GRUU") - Replacement of a GRUU by the GRUU's contact value. > (Strictly, we can probably omit indicating this as the "gr" > situation can be determined by examining the URIs.) > > - "hi" ("History-Info compatibility") - This hi-entry was added when > the request entered an entity that supports History-Info because the > last hi-entry (if any) did not match the Request-URI. > > A typical example would be: > > History-Info: ;index=3D1;hi > History-Info: > ;index=3D1.1;p=3D1;rc > History-Info: ;index=3D1.2;p=3D1;mp > History-Info: ;index=3D1.2.1 > > Alternatively, we could have the "type of redirection" be the values > of a single parameter name, or we could append the codes to the > "index" value (which would save space). > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >