From john.elwell@siemens-enterprise.com Fri Jul 1 05:54: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 B08AC11E8E55 for ; Fri, 1 Jul 2011 05:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.463 X-Spam-Level: X-Spam-Status: No, score=-106.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 2pZqW8sGotnU for ; Fri, 1 Jul 2011 05:54:03 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id D27E47B8E82 for ; Fri, 1 Jul 2011 05:30:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-10.tower-216.messagelabs.com!1309523452!10139907!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 9201 invoked from network); 1 Jul 2011 12:30:52 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-10.tower-216.messagelabs.com with SMTP; 1 Jul 2011 12:30:52 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 1756223F03E9; Fri, 1 Jul 2011 14:30:52 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 1 Jul 2011 14:30:52 +0200 From: "Elwell, John" To: Robert Sparks , "SIPCORE (Session Initiation Protocol Core) WG" Date: Fri, 1 Jul 2011 14:30:51 +0200 Thread-Topic: [sipcore] An alternate to the requirements section in proxy-feature-02 Thread-Index: AcwqFqhna9wesgC4RMiW4b2HBb4ivQN02j/Q 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] 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: Fri, 01 Jul 2011 12:54:03 -0000 =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Robert Sparks > Sent: 13 June 2011 23:10 > To: SIPCORE (Session Initiation Protocol Core) WG > Subject: [sipcore] An alternate to the requirements section=20 > in proxy-feature-02 >=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 of the proposed=20 > 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=20 > from the proposed mechanism, along with several questions.=20 > Please help clarify=20 > the requirements where my inferences are wrong. Please also=20 > point out where=20 > 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. [JRE] I don't think this makes it clear whether the indication of support i= s intended to mean: a) there is a proxy somewhere on the path that supports this feature; or b) a particular proxy (as identified somehow) supports this feature. Section 4 of the draft, although not entirely clear, seems to hint at b) be= cause of the mechanisms it suggests, whereas Robert's text leaves it comple= tely open. I think we need to nail down this aspect of the requirement bett= er. John >=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. >=20 > 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. >=20 > 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? >=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? >=20 > 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 >=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) >=20 > 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 >=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=20 > the path=20 > supports X") >=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? >=20 > -------- >=20 > Again, I'm sure I've missed some important requirements. > What are they? >=20 > The currently proposed mechanism appears to run against the=20 > advice in RFC5897, > particularly Do What I Say vs Do What I Mean. It appears to provide a > declarative service identifier (such as=20 > 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=20 > require any > element that doesn't recognize a value to behave exactly as=20 > it would if there > were no value present at all? If so, what keeps us from=20 > having the same > service/feature/capability defined in separate namespaces resulting in > non-interoperable islands? >=20 > 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=20 > 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 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From HKaplan@acmepacket.com Fri Jul 1 07:56: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 731AB9E802C for ; Fri, 1 Jul 2011 07:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, J_CHICKENPOX_31=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 8HJJxHFXNeot for ; Fri, 1 Jul 2011 07:56:03 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id CDA9F9E801A for ; Fri, 1 Jul 2011 07:56:02 -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, 1 Jul 2011 10:56:00 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Fri, 1 Jul 2011 10:56:00 -0400 From: Hadriel Kaplan To: "Worley, Dale R (Dale)" Date: Fri, 1 Jul 2011 10:55:59 -0400 Thread-Topic: [sipcore] 4244bis: Describing redirections Thread-Index: Acw3/v03lLujN2apS/K2fn3FRGeYvg== Message-ID: <0B7939B3-4261-4F8E-AC78-81EE5021625E@acmepacket.com> 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: AAAAAQAAAUA= Cc: "sipcore@ietf.org" 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 14:56:03 -0000 That's why I proposed always adding the "rc" param when the req-uri is chan= ged, regardless of how it was changed (except for the case of "mp"), so tha= t the dotted-number pointer can always be there.=20 In other words, don't have "rc", "gr" and "hi" - just "rc" and "mp", where = "rc" now means 'req-uri changed'. Because it doesn't actually matter how t= he req-uri got changed. (it's not reliably useful info to the UAS) -hadriel On Jun 30, 2011, at 3:17 PM, Worley, Dale R (Dale) wrote: > Here's another unpleasant case: >=20 > 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. >=20 > The H-I at this point looks like: >=20 > History-Info: ;index=3D1, > ;index=3D1.1, > ;index=3D1.2;??=3D1.1 >=20 > but there is nothing that can be correctly put in place of "??". >=20 > Here is one possibility: >=20 > Have one H-I parameter solely for carrying the "predecessor" pointer. > Let's give it a really short name, like "p". >=20 > 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: >=20 > - "rc" ("registered contact") - Conversion of an AOR to its contact via > a location service (as described in RFC 3261). >=20 > - "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. >=20 > - "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.) >=20 > - "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. >=20 > A typical example would be: >=20 > 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 >=20 > 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). >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From dean.willis@softarmor.com Fri Jul 1 08:22:14 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD7B21F853B for ; Fri, 1 Jul 2011 08:22:14 -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 5qQYlMNGqLKe for ; Fri, 1 Jul 2011 08:22:13 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 785EB9E803F for ; Fri, 1 Jul 2011 08:21:12 -0700 (PDT) Received: by ywp31 with SMTP id 31so1717528ywp.31 for ; Fri, 01 Jul 2011 08:21:12 -0700 (PDT) Received: by 10.236.176.36 with SMTP id a24mr3950790yhm.284.1309533671911; Fri, 01 Jul 2011 08:21:11 -0700 (PDT) Received: from [192.168.2.143] (cpe-66-25-15-110.tx.res.rr.com [66.25.15.110]) by mx.google.com with ESMTPS id o47sm2439522yhn.30.2011.07.01.08.21.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jul 2011 08:21:10 -0700 (PDT) References: <8808E166-BEDA-4AAB-A75B-39D58A8F169A@standardstrack.com> In-Reply-To: <8808E166-BEDA-4AAB-A75B-39D58A8F169A@standardstrack.com> Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Message-Id: <752868B8-B9E4-45C3-9E20-B63B27B5539C@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Date: Fri, 1 Jul 2011 10:21:09 -0500 To: Eric Burger X-Mailer: Apple Mail (2.1084) Cc: sipcore@ietf.org Subject: Re: [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: Fri, 01 Jul 2011 15:22:14 -0000 On Jun 30, 2011, at 6:37 AM, Eric Burger wrote: > = http://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____________= ___________________________________ Yeah, this is sort of why I was on the "design MANDATORY TO USE privacy = into the protocol" bandwagon around the Prague meeting. Guess what? Very few people seem to care. If Facebook implemented it, = they'd probably post recordings of every phone call to their news feed. -- Dean From christer.holmberg@ericsson.com Fri Jul 1 16:10: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 A191421F8650 for ; Fri, 1 Jul 2011 16:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 6fsJB5KslL8i for ; Fri, 1 Jul 2011 16:10:41 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBAF21F8651 for ; Fri, 1 Jul 2011 16:10:40 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-31-4e0e53efcfcb Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7B.05.09774.FE35E0E4; Sat, 2 Jul 2011 01:10:40 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sat, 2 Jul 2011 01:10:39 +0200 From: Christer Holmberg To: "Elwell, John" , Robert Sparks , "SIPCORE (Session Initiation Protocol Core) WG" Date: Sat, 2 Jul 2011 01:08:44 +0200 Thread-Topic: [sipcore] An alternate to the requirements section in proxy-feature-02 Thread-Index: AQHMOEQXOpcb6dsOtke21YgsTWB5zA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6190FB4@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: 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: Fri, 01 Jul 2011 23:10:47 -0000 Hi, Please note that I have submitted draft-ietf-sipcore-proxy-feature-reqs-00. >> 1) There is a requirement for a proxy to be able to >> indicate support for a capability to other proxies >> in the path of a dialog forming transaction and to >> the two endpoints of that transaction. >[JRE] I don't think this makes it clear whether the indication of support = is intended to mean: >a) there is a proxy somewhere on the path that supports this feature; or >b) a particular proxy (as identified somehow) supports this feature. >Section 4 of the draft, although not entirely clear, seems to hint at b) b= ecause of the mechanisms it suggests, whereas Robert's text leaves it compl= etely open. I think we need to nail down this aspect of the requirement bet= ter. The intention is b). I'll look how to clarify it. Regards, Christer > > 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. > > 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. > > 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") > > 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 > 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? > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From dworley@avaya.com Tue Jul 5 12:13: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 9293521F887C for ; Tue, 5 Jul 2011 12:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.474 X-Spam-Level: X-Spam-Status: No, score=-103.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 j9NF3fQp7Gho for ; Tue, 5 Jul 2011 12:13:52 -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 0868121F857F for ; Tue, 5 Jul 2011 12:13:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtgGAKthE06HCzI1/2dsb2JhbABTqApwB6wng3UCmy6DNIMCBJdLiz0 X-IronPort-AV: E=Sophos;i="4.65,481,1304308800"; d="scan'208";a="254982822" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 05 Jul 2011 15:13:50 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 05 Jul 2011 15:07:03 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 5 Jul 2011 15:13:49 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Tue, 5 Jul 2011 15:10:49 -0400 Thread-Topic: 4244bis: How does History-Info account for Route? Thread-Index: AQHMO0ernbOrqXUQ2U2Mi4/0UjWpfg== 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: How does History-Info account for Route? 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, 05 Jul 2011 19:13:54 -0000 How does the History-Info reflect the actions due to Route headers? As wri= tten, while the request is being routed due to the Route URIs, the request-= URI does not change, and so many History-Info entries show the request-URI = (and give no information about where the request was being sent). Oddly, I ran into this while I was considering a practical use for H-I: It= allows the upstream proxies to determine if a fork reached a particular do= wnstream proxy, and so helps with the "redundant paths" routing issue. Dale From internet-drafts@ietf.org Thu Jul 7 09:56:28 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67E111E8089; Thu, 7 Jul 2011 09:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, 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 NGHvF10sGCrd; Thu, 7 Jul 2011 09:56:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C8E1F0C46; Thu, 7 Jul 2011 09:56:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110707165628.18445.51358.idtracker@ietfa.amsl.com> Date: Thu, 07 Jul 2011 09:56:28 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-reqs-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 16:56:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Work= ing Group of the IETF. Title : Requirements for indication of features supported by a S= IP proxy Author(s) : Christer Holmberg Ivo Sedlacek Filename : draft-ietf-sipcore-proxy-feature-reqs-00.txt Pages : 7 Date : 2011-06-19 The Session Initiation Protocol (SIP) "Caller Preferences" ext= ension defined in RFC 3840 provides a mechanism that allows a SIP message to convey information relating to the originator's supported features/ capabilities. This document defines requirements for a mechanism that would allow SIP proxies to convey information relating to the proxy's supported features/capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-proxy-feature-reqs-0= 0.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-proxy-feature-reqs-00= .txt From dworley@avaya.com Thu Jul 7 11:49: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 C1B661F0C97 for ; Thu, 7 Jul 2011 11:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.388 X-Spam-Level: X-Spam-Status: No, score=-103.388 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, 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 KgOkqKWApCl8 for ; Thu, 7 Jul 2011 11:49:10 -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 3895E1F0C55 for ; Thu, 7 Jul 2011 11:49:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowGAD3/FU7GmAcF/2dsb2JhbABTpzZwB7AhApshhjgEl2GLQg X-IronPort-AV: E=Sophos;i="4.65,494,1304308800"; d="scan'208";a="289391301" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Jul 2011 14:49:09 -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; 07 Jul 2011 14:47:52 -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, 7 Jul 2011 14:49:08 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Thu, 7 Jul 2011 14:49:08 -0400 Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-reqs-00.txt Thread-Index: Acw8xtXNBa4qiH7aTROq7p6uxNaD7AADja+Z Message-ID: References: <20110707165628.18445.51358.idtracker@ietfa.amsl.com> In-Reply-To: <20110707165628.18445.51358.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-reqs-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 18:49:10 -0000 I see in this draft: REQ-4: A SIP proxy MUST NOT, when indicating support of a feature/ capability, make any assumptions that SIP entities in the signalling path that receive the indicator will support, or understand the meaning of, the feature/capability. I think the phrasing of this can be improved. More importantly, it doesn't state that the proxy (that is doing the indicating) can do so even if inter= mediate elements don't support the proxy-feature mechanism at all. This might be a more comprehensive way to express it: REQ-4: A SIP proxy MUST be able to indicate support of a feature/capability to all other SIP entities in the signaling path (that support this mechanism), even if some SIP entities in the signaling path (possibly including the UAC and/or UAS) do not support, or understand the meaning of, the feature/capability, or even this mechanism as a whole. Dale From dworley@avaya.com Thu Jul 7 12:08: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 B643621F8539 for ; Thu, 7 Jul 2011 12:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.167 X-Spam-Level: X-Spam-Status: No, score=-103.167 tagged_above=-999 required=5 tests=[AWL=0.432, 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 A0vR5Kcj0J5c for ; Thu, 7 Jul 2011 12:08:27 -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 30EBE21F8524 for ; Thu, 7 Jul 2011 12:08:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPkDFk7GmAcF/2dsb2JhbABTpzZ3iHunKAKbG4Y4BJdhi0I X-IronPort-AV: E=Sophos;i="4.65,494,1304308800"; d="scan'208";a="289394988" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Jul 2011 15:08:04 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Jul 2011 15:06:48 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Thu, 7 Jul 2011 15:08:04 -0400 From: "Worley, Dale R (Dale)" To: Hadriel Kaplan Date: Thu, 7 Jul 2011 15:07:56 -0400 Thread-Topic: [sipcore] 4244bis: Describing redirections Thread-Index: Acw3/v03lLujN2apS/K2fn3FRGeYvgE2jBag Message-ID: References: , <0B7939B3-4261-4F8E-AC78-81EE5021625E@acmepacket.com> In-Reply-To: <0B7939B3-4261-4F8E-AC78-81EE5021625E@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" 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: Thu, 07 Jul 2011 19:08:27 -0000 > From: Hadriel Kaplan [HKaplan@acmepacket.com]=20 >=20 > That's why I proposed always adding the "rc" param when the req-uri is > changed, regardless of how it was changed (except for the case of > "mp"), so that the dotted-number pointer can always be there. >=20 > In other words, don't have "rc", "gr" and "hi" - just "rc" and "mp", > where "rc" now means 'req-uri changed'. Because it doesn't actually > matter how the req-uri got changed. (it's not reliably useful info to > the UAS) Essentially, that proposal is to have two cases, "mp" and other. That does the job. In any case, we need to have a way of tagging "other". I'm not really sure that we need to distinguish any cases. I think that the way to "solve" this question is to examine the application logic -- what cases do we need to distinguish to ensure that the application logic can make the decisions that people want to make? I've posted alternative application logic, but I suspect that version is shaky too. Others needs to review it. Dale From dworley@avaya.com Thu Jul 7 12:11:35 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E10AB21F86A1 for ; Thu, 7 Jul 2011 12:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.187 X-Spam-Level: X-Spam-Status: No, score=-103.187 tagged_above=-999 required=5 tests=[AWL=0.412, 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 2cFcJqSCv7df for ; Thu, 7 Jul 2011 12:11:34 -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 46A7621F86A0 for ; Thu, 7 Jul 2011 12:11:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPkDFk6HCzI1/2dsb2JhbABTpzZ3sCMCmxuGOASXYYtC X-IronPort-AV: E=Sophos;i="4.65,494,1304308800"; d="scan'208";a="289395648" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 07 Jul 2011 15:11:33 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Jul 2011 15:04:43 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Thu, 7 Jul 2011 15:11:33 -0400 From: "Worley, Dale R (Dale)" To: "R.Jesske@telekom.de" , "sipcore@ietf.org" Date: Thu, 7 Jul 2011 15:08:34 -0400 Thread-Topic: 4244bis: Describing redirections Thread-Index: AQHMN1iiQ88nfcLVj0Oe0yxoNpSGSZTW0b1wgApyGu0= Message-ID: References: , <580BEA5E3B99744AB1F5BFF5E9A3C67D090D2DFCB0@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D090D2DFCB0@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] 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, 07 Jul 2011 19:11:35 -0000 ________________________________________ From: R.Jesske@telekom.de [R.Jesske@telekom.de] 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. _______________________________________________ I think it is important to record the URI from which each URI is derived, t= o the extent that it is possible to do so. I think that relationship is more imp= ortant then the particular reason for each derivation. But those beliefs are due to the way I've constructed the application logic= , which is very different from the application logic in the current draft. There may = be a better way organize the application logic. I think we need to review the application = logic more carefully and after examining how to make such decisions, it will be clearer what inf= ormation needs to be recorded in H-I. Dale From christer.holmberg@ericsson.com Thu Jul 7 14:57:35 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D03921F8901 for ; Thu, 7 Jul 2011 14:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.435 X-Spam-Level: X-Spam-Status: No, score=-6.435 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, 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 uvKlcA-cHs+h for ; Thu, 7 Jul 2011 14:57:35 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A2A4821F8902 for ; Thu, 7 Jul 2011 14:57:34 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-70-4e162bcd23f8 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 7E.F2.20773.DCB261E4; Thu, 7 Jul 2011 23:57:33 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 7 Jul 2011 23:57:33 +0200 From: Christer Holmberg To: "'Worley, Dale R (Dale)'" , "sipcore@ietf.org" Date: Thu, 7 Jul 2011 23:57:33 +0200 Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-reqs-00.txt Thread-Index: Acw8xtXNBa4qiH7aTROq7p6uxNaD7AADja+ZAAbe7yA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB61820CC@ESESSCMS0356.eemea.ericsson.se> References: <20110707165628.18445.51358.idtracker@ietfa.amsl.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-reqs-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 21:57:35 -0000 Hi Dale, Your proposed change looks good, but a couple of minor suggestions: 1. I would suggest to remove the "(that support this mechanism)" part. 2. I would suggest to say "to other SIP entities", rather than "to ALL othe= r SIP entities", as we also need to consider the directionality. Regards, Christer=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Worley, Dale R (Dale) Sent: 7. hein=E4kuuta 2011 21:49 To: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-reqs-00= .txt I see in this draft: REQ-4: A SIP proxy MUST NOT, when indicating support of a feature/ capability, make any assumptions that SIP entities in the signalling path that receive the indicator will support, or understand the meaning of, the feature/capability. I think the phrasing of this can be improved. More importantly, it doesn't= state that the proxy (that is doing the indicating) can do so even if inte= rmediate elements don't support the proxy-feature mechanism at all. This m= ight be a more comprehensive way to express it: REQ-4: A SIP proxy MUST be able to indicate support of a feature/capability to all other SIP entities in the signaling path (that support this mechanism), even if some SIP entities in the signaling path (possibly including the UAC and/or UAS) do not support, or understand the meaning of, the feature/capability, or even this mechanism as a whole. Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From jmpolk@cisco.com Fri Jul 8 14:06: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 2747521F8CA2 for ; Fri, 8 Jul 2011 14:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.499 X-Spam-Level: X-Spam-Status: No, score=-105.499 tagged_above=-999 required=5 tests=[AWL=-2.900, 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 Dall2wKpFily for ; Fri, 8 Jul 2011 14:05:52 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B6B6F21F8C97 for ; Fri, 8 Jul 2011 14:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1012; q=dns/txt; s=iport; t=1310159152; x=1311368752; h=message-id:date:to:from:subject:cc:mime-version; bh=iC5WMTHxtJU96VTj9kivmyXdBv6qzRFdeHxyjKV78mg=; b=eu1wEJ+inSXlaBRKSkM+r3+ZmSNNmU6FEjeHIBHVV+mUn5tlrMoB6OI6 DCEsiYfFywB2Bk+VzGq8T/kTgEgCtnBLi5KlcxzGqVkup/lGbWptT0qye fxUZqmQ/SyITVG61e0NsWJjoo4tpI5exPLtgUgluIDRJGqiynepcHEA7X w=; X-IronPort-AV: E=Sophos;i="4.65,500,1304294400"; d="scan'208";a="1186932" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-3.cisco.com with ESMTP; 08 Jul 2011 21:05:52 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p68L5pfh032286; Fri, 8 Jul 2011 21:05:51 GMT Message-Id: <201107082105.p68L5pfh032286@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 08 Jul 2011 16:05:49 -0500 To: sipcore@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Adarsh Kaithal \(akaithal\)" , Jack Klecha Subject: [sipcore] New ID posted asking for two more RPH namespaces 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, 08 Jul 2011 21:06:01 -0000 SIPCORE A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IANA Registration of the UC and CUC Session Initiation Protocol (SIP) Resource-Priority Namespaces Author(s) : Adarsh Kaithal James Polk Jack Klecha Filename : draft-kaithal-sipcore-rph-cuc-uc-namespaces-00.txt Pages : 5 Date : 2011-07-04 This document creates two new Session Initiation Protocol (SIP) Resource-Priority namespaces, and places these namespaces in the IANA registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaithal-sipcore-rph-cuc-uc-namespaces-00.txt This is a simple 5 page draft requesting two new RPH namespaces be IANA registered. There are no new semantics involved, and uses RFC 5478 as a template for much of the text and all of the security considerations. Comments are appreciated James, Adarsh and Jack From shida@ntt-at.com Sun Jul 10 00:08:44 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D1A21F8AC6 for ; Sun, 10 Jul 2011 00:08:44 -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 6c0rfOwuHUki for ; Sun, 10 Jul 2011 00:08:44 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id F08C521F8AC3 for ; Sun, 10 Jul 2011 00:08:43 -0700 (PDT) Received: from [220.102.214.252] (port=49693 helo=[192.168.11.10]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qfo88-00042p-RN; Sun, 10 Jul 2011 02:08:41 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Sun, 10 Jul 2011 16:08:37 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <14FFF078-E5D1-45F2-8D9A-AD52DE677CEF@cisco.com>, 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: flh1ade252.tky.mesh.ad.jp ([192.168.11.10]) [220.102.214.252]:49693 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sipcore@ietf.org WG" 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: Sun, 10 Jul 2011 07:08:44 -0000 Hi Dale; Could you elaborate as to what you are suggesting? Regards Shida On Jun 23, 2011, at 4:50 AM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of = Cullen Jennings [fluffy@cisco.com] >=20 >> 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 > Most importantly, presenting algorithms for the use cases allows the = reader to verify that the mechanism does accomplish what it was designed = to do, and that there are not peculiar cases where the mechanism fails. >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From shida@agnada.com Sun Jul 10 00:08: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 9394421F8A97 for ; Sun, 10 Jul 2011 00:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 gIlsSm3dv7qX for ; Sun, 10 Jul 2011 00:08:53 -0700 (PDT) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.15.7]) by ietfa.amsl.com (Postfix) with SMTP id DCE4721F8ACC for ; Sun, 10 Jul 2011 00:08:52 -0700 (PDT) Received: (qmail 21185 invoked from network); 10 Jul 2011 07:06:09 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway12.websitewelcome.com with SMTP; 10 Jul 2011 07:06:09 -0000 Received: from flh1ade252.tky.mesh.ad.jp ([220.102.214.252]:49693 helo=[192.168.11.10]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qfo8J-00042p-AP; Sun, 10 Jul 2011 02:08:51 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Sun, 10 Jul 2011 16:08:49 +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 - agnada.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: flh1ade252.tky.mesh.ad.jp ([192.168.11.10]) [220.102.214.252]:49693 X-Source-Auth: shida@agnada.com X-Email-Count: 5 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: SIPCORE Chairs , SIPCORE 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: Sun, 10 Jul 2011 07:08:53 -0000 Hi Dale; It's not for backward compatibility. We couldn't come up with reason why reason should=20 be included in case of 2xx responses. Mary presented the proposed changes at the last=20 meeting and people agreed to the changes. Can you think of a good reason why we should revert=20 the changes, if so please let us know. Regards Shida=20 On Jun 23, 2011, at 5:06 AM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of = Mary Barnes [mary.ietf.barnes@gmail.com] >=20 > 2) Updated section 9.3 (receiving responses) to also include timeouts = and updated to reflect that we don't add the Reason header in the case = of 2xx responses. > ________________________________________ >=20 > Can you tell me the design considerations for why Reason is not used = in the case of 2xx responses? (Is it for backward compatibility?) >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Sun Jul 10 01:13: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 4F0D121F8637 for ; Sun, 10 Jul 2011 01:13:13 -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 fbvgr48ymd8t for ; Sun, 10 Jul 2011 01:13:12 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id CC8AC21F8622 for ; Sun, 10 Jul 2011 01:13:12 -0700 (PDT) Received: from [220.102.214.252] (port=56008 helo=[192.168.11.2]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qfp8Y-0002wi-QE; Sun, 10 Jul 2011 03:13:11 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Sun, 10 Jul 2011 17:13:08 +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: flh1ade252.tky.mesh.ad.jp ([192.168.11.2]) [220.102.214.252]:56008 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sipcore@ietf.org" Subject: Re: [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: Sun, 10 Jul 2011 08:13:13 -0000 Hi Dale; I think, I understand what you are saying but I am not sure=20 I understand what you are suggesting we do to the draft to=20 cover this fact.=20 The draft as you read it implies that this can happen as you=20 suggested here, and the index of the first three entries of=20 H-I may indeed be 1, 2 and 3.=20 Regards Shida On Jun 23, 2011, at 5:52 AM, Worley, Dale R (Dale) wrote: > 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. >=20 > How? The phone may receive a 3xx response to its first request. Per = the rules > 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. >=20 > 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. >=20 > Another consequence is that this technical problem is solved: >=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.] >=20 > 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. >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Sun Jul 10 01:14: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 2E45921F8A93 for ; Sun, 10 Jul 2011 01:14:30 -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 T5kRg3vp4h3i for ; Sun, 10 Jul 2011 01:14:29 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFD021F89F2 for ; Sun, 10 Jul 2011 01:14:29 -0700 (PDT) Received: from [220.102.214.252] (port=56536 helo=[192.168.11.2]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qfp9h-0003gB-LN; Sun, 10 Jul 2011 03:14:22 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Sun, 10 Jul 2011 17:14:19 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3B2A8F8E-4255-4156-B882-BF68F4046F3D@acmepacket.com> 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: flh1ade252.tky.mesh.ad.jp ([192.168.11.2]) [220.102.214.252]:56536 X-Source-Auth: shida@agnada.com X-Email-Count: 4 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: Sun, 10 Jul 2011 08:14:30 -0000 Hi Dale; My comments inline.. On Jun 23, 2011, at 5:47 AM, Worley, Dale R (Dale) wrote: > Thanks for writing this, as both points you made lead me to realize > errors I was making! >=20 >> 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? >=20 > 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. >=20 > But that's not what the draft says, the draft says that the new index > is just "1". >=20 > 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. Your understanding is correct AFAIK.=20 The index added for entity which didn't log H-I (didn't support H-I)=20 SHOULD be "[last-hi-entry's index].1". >=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) >=20 > Hmm, I would be inclinded to agree with you, but, as written, the > draft solves a "problem" I was wondering about: >=20 > phone A (no H-I supt.) --> proxy B (H-I supt.) --> proxy C (H-I) --> = phone D (H-I) >=20 > Phone A does not insert H-I in the request. >=20 > 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. >=20 > Proxy C inserts H-I in the request to phone D: index 1.1.1, > containing the request-URI it sends to phone D. >=20 > 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). >=20 > Proxy C copies the H-I into its response, adding Reason to index > 1.1.1 -- because it received H-I in the request. >=20 > 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. >=20 > Phone A receives a response without H-I, as it expected. >=20 > This arrangement satisfies these requirements: >=20 > 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. >=20 > 2) Every H-I-aware entity will receive H-I information from every > upstream and downstream entity H-I-aware entity. >=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. >=20 > Dale We still need "Supported: histinfo" for backward compatibility as=20 you stated yourself in the following e-mail.=20 Regards Shida > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Sun Jul 10 02:21: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 2530F21F85AB for ; Sun, 10 Jul 2011 02:21: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 xZ4kAIS6zcJE for ; Sun, 10 Jul 2011 02:21:52 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id B2C8E21F8587 for ; Sun, 10 Jul 2011 02:21:52 -0700 (PDT) Received: from [220.102.214.252] (port=55734 helo=[192.168.11.2]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QfqCz-0001ll-Rq; Sun, 10 Jul 2011 04:21:50 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Sun, 10 Jul 2011 18:21:47 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: , <0B7939B3-4261-4F8E-AC78-81EE5021625E@acmepacket.com> 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: flh1ade252.tky.mesh.ad.jp ([192.168.11.2]) [220.102.214.252]:55734 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sipcore@ietf.org" 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: Sun, 10 Jul 2011 09:21:53 -0000 It's "mp" and "rc". The "other" you mention below is "rc". You tag it with "mp" when you know for certain that the target user represented by the R-URI is different from one before. Otherwise you simply tag it with "rc". If the URI doesn't change when forwarded due to the Route header, you simply don't tag it because R-URI did not change. We used to have a tag called "np" (no-op) for that. Regards Shida On Jul 8, 2011, at 4:07 AM, Worley, Dale R (Dale) wrote: >> From: Hadriel Kaplan [HKaplan@acmepacket.com] >> >> That's why I proposed always adding the "rc" param when the req-uri is >> changed, regardless of how it was changed (except for the case of >> "mp"), so that the dotted-number pointer can always be there. >> >> In other words, don't have "rc", "gr" and "hi" - just "rc" and "mp", >> where "rc" now means 'req-uri changed'. Because it doesn't actually >> matter how the req-uri got changed. (it's not reliably useful info to >> the UAS) > > Essentially, that proposal is to have two cases, "mp" and other. That > does the job. In any case, we need to have a way of tagging "other". > I'm not really sure that we need to distinguish any cases. > > I think that the way to "solve" this question is to examine the > application logic -- what cases do we need to distinguish to ensure > that the application logic can make the decisions that people want to > make? > > I've posted alternative application logic, but I suspect that version > is shaky too. Others needs to review it. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Sun Jul 10 02:22: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 E8EC221F85B5 for ; Sun, 10 Jul 2011 02:22:07 -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 7DDlGY00YeNU for ; Sun, 10 Jul 2011 02:22:06 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id BBE6721F85B4 for ; Sun, 10 Jul 2011 02:22:06 -0700 (PDT) Received: from flh1ade252.tky.mesh.ad.jp ([220.102.214.252]:55734 helo=[192.168.11.2]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QfqDF-0001ll-R5; Sun, 10 Jul 2011 04:22:06 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Sun, 10 Jul 2011 18:22:05 +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: flh1ade252.tky.mesh.ad.jp ([192.168.11.2]) [220.102.214.252]:55734 X-Source-Auth: shida@agnada.com X-Email-Count: 4 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sipcore@ietf.org" Subject: Re: [sipcore] 4244bis: How does History-Info account for Route? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 09:22:08 -0000 Hi Dale; The H-I will capture the request being routed via Route header but will not add any tag.=20 It would have a redundant R-URI in H-I but will increase the=20 depth of branch. It will not have the "rc" tag, we considered=20 a tag "np" (No-op) for this in the earlier version of the draft but=20 WG decided it was useless so we removed it from the draft.=20 e.g.=20 History-Info: ;index=3D1; History-Info: ;index=3D1.1; (H-I due to = Route header) History-Info: = ;index=3D1.1.1;rc=3D1.1; History-Info: ;index=3D1.1.2;rc=3D1.1; Regards Shida On Jul 6, 2011, at 4:10 AM, Worley, Dale R (Dale) wrote: > How does the History-Info reflect the actions due to Route headers? = As written, while the request is being routed due to the Route URIs, the = request-URI does not change, and so many History-Info entries show the = request-URI (and give no information about where the request was being = sent). >=20 > Oddly, I ran into this while I was considering a practical use for = H-I: It allows the upstream proxies to determine if a fork reached a = particular downstream proxy, and so helps with the "redundant paths" = routing issue. >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Sun Jul 10 02:28: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 3166321F880C for ; Sun, 10 Jul 2011 02:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.567 X-Spam-Level: X-Spam-Status: No, score=-101.567 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, 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 rCX3PwkD89bu for ; Sun, 10 Jul 2011 02:28:04 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 284BF21F87E9 for ; Sun, 10 Jul 2011 02:28:04 -0700 (PDT) Received: from [220.102.214.252] (port=58424 helo=[192.168.11.2]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QfqIz-0002DB-Vb; Sun, 10 Jul 2011 04:28:03 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Sun, 10 Jul 2011 18:27:59 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <4383A308-0338-438E-80CB-3E8BFAA18F11@ntt-at.com> 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: flh1ade252.tky.mesh.ad.jp ([192.168.11.2]) [220.102.214.252]:58424 X-Source-Auth: shida@agnada.com X-Email-Count: 6 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sipcore@ietf.org" Subject: Re: [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: Sun, 10 Jul 2011 09:28:05 -0000 Hi Dale; Thanks again for your thorough analysis of the draft. My comments inline.. On Jun 30, 2011, at 1:07 AM, Worley, Dale R (Dale) wrote: > 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). As I mentioned in another thread, I think this is a bug.=20 The index for missing entity should be {whatever}.1.=20 If the last index of H-I was 1.1, then the index for R-URI=20 representing an entity that did not support H-I SHOULD be=20 1.1.1.=20 >=20 > 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. This is true, in case of parallel forking.=20 First branch would only see 1.1=20 Second branch would only see 1.2=20 Third 1.3 etc.=20 If it is a serial forking, you would have the whole brunches,=20 unless there are entities not supporting RFC4244bis or RFC4244.=20 First branch would see 1.1 Second would see 1.1 and 1.2=20 Third would see 1.1, 1.2 and 1.3 >=20 > 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: >=20 > 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. >=20 > 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: >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Looking at the use cases in > draft-barnes-sipcore-rfc4244bis-callflows-01, we can apply this > approach to implement the described use cases: >=20 > 3.1. Automatic Call Distribution >=20 > 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.). >=20 > What is needed is: >=20 > - 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.) >=20 > (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.) >=20 > 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. >=20 > The example is: >=20 > 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 >=20 > The chain of ancestor hi-entries is: >=20 > ;index=3D1.2.1.1;rc=3D1.2.1 > ;index=3D1.2.1 > ;index=3D1.2;mp=3D1 > ;index=3D1 >=20 > showing that the call was made to and that it > has been retargeted from Gold to Silver. >=20 > 3.2. Determining the Alias used. >=20 > History-Info: ;index=3D1; > History-Info: = ;index=3D1.1;rc=3D1; > History-Info: ;index=3D1.2;rc=3D1; >=20 > The chain of ancestor hi-entries is: >=20 > ;index=3D1.2;rc=3D1; > ;index=3D1; >=20 > The UA recognizes as (one of) its contact URIs, > and as an AOR/alias which it has been > configured to treat specially. >=20 > 3.3. PBX Voicemail Example >=20 > 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". >=20 > 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.) >=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;rc=3D1.2 >=20 > (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: >=20 > = ;index=3D1.2.1;rc=3D1.2 > ;index=3D1.2;mp=3D1 > ;index=3D1 >=20 > 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. >=20 > 3.4. Consumer Voicemail Example >=20 > 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 >=20 > The chain of ancestor hi-entries is: >=20 > ;index=3D1.2;mp=3D= 1 > ;index=3D1 >=20 > 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. >=20 > 3.5. GRUU >=20 > History-Info: ;gr=3Durn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;index=3D1 > History-Info: ;index=3D1.1 >=20 > The chain of ancestor hi-entries is: >=20 > ;index=3D1.1 > = ;= index=3D1 >=20 > The application can see that its contact URI was derived from the GRUU > at index 1. >=20 > 3.6. Limited Use Address [accessing URI parameters in a mapped-from = URI] >=20 > History-Info: > > ;index=3D1 > History-Info: ;index=3D1.1 >=20 > The chain of ancestor hi-entries is: >=20 > ;index=3D1.1 > = ;index=3D= 1 >=20 > 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. >=20 > 3.7. Service Invocation >=20 > History-Info: ;index=3D1, > ;index=3D1.1;mp=3D1, > ;index=3D1.1.1, > ;index=3D1.1.2;rc=3D1.1 >=20 > The chain of ancestor hi-entries is: >=20 > ;index=3D1.1.2;rc=3D1.1 > ;index=3D1.1;mp=3D1, > ;index=3D1, >=20 > 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. >=20 > Dale I think changing the semantics of "rc" to mean the "change of R-URI" = will=20 make it easier for application to read the ancestor hi-entries. Regards Shida > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Sun Jul 10 04:02: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 E4BA921F8580 for ; Sun, 10 Jul 2011 04:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.865 X-Spam-Level: X-Spam-Status: No, score=-101.865 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=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 VkNk+NkdvGHU for ; Sun, 10 Jul 2011 04:02:07 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 1622221F8567 for ; Sun, 10 Jul 2011 04:02:06 -0700 (PDT) Received: from [220.102.214.252] (port=49938 helo=[192.168.11.2]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Qfrlz-00086g-Co; Sun, 10 Jul 2011 06:02:03 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <0B7939B3-4261-4F8E-AC78-81EE5021625E@acmepacket.com> Date: Sun, 10 Jul 2011 20:02:01 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0B7939B3-4261-4F8E-AC78-81EE5021625E@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: flh1ade252.tky.mesh.ad.jp ([192.168.11.2]) [220.102.214.252]:49938 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" 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: Sun, 10 Jul 2011 11:02:08 -0000 +1 =20 In the example you indicated below, the entity receiving the=20 3xx will log the Contact in 3xx in H-I and add "rc" as it will=20 not know whether it is a different target user from the=20 previous R-URI but it knows that Contact URI is different=20 from the R-URI that cause the 3xx. =20 =20 *Based on the new semantics of "rc" that everybody seems to=20 be in favor of. =20 Regards Shida On Jul 1, 2011, at 11:55 PM, Hadriel Kaplan wrote: >=20 > That's why I proposed always adding the "rc" param when the req-uri is = changed, regardless of how it was changed (except for the case of "mp"), = so that the dotted-number pointer can always be there.=20 >=20 > In other words, don't have "rc", "gr" and "hi" - just "rc" and "mp", = where "rc" now means 'req-uri changed'. Because it doesn't actually = matter how the req-uri got changed. (it's not reliably useful info to = the UAS) >=20 > -hadriel >=20 >=20 > On Jun 30, 2011, at 3:17 PM, Worley, Dale R (Dale) wrote: >=20 >> Here's another unpleasant case: >>=20 >> 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. >>=20 >> The H-I at this point looks like: >>=20 >> History-Info: ;index=3D1, >> ;index=3D1.1, >> ;index=3D1.2;??=3D1.1 >>=20 >> but there is nothing that can be correctly put in place of "??". >>=20 >> Here is one possibility: >>=20 >> Have one H-I parameter solely for carrying the "predecessor" pointer. >> Let's give it a really short name, like "p". >>=20 >> 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: >>=20 >> - "rc" ("registered contact") - Conversion of an AOR to its contact = via >> a location service (as described in RFC 3261). >>=20 >> - "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. >>=20 >> - "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.) >>=20 >> - "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. >>=20 >> A typical example would be: >>=20 >> 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 >>=20 >> 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). >>=20 >> Dale >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Mon Jul 11 10:42: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 B24C211E8136 for ; Mon, 11 Jul 2011 10:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 mxMl7kz7Lgfa for ; Mon, 11 Jul 2011 10:42:07 -0700 (PDT) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by ietfa.amsl.com (Postfix) with ESMTP id 47D6711E8133 for ; Mon, 11 Jul 2011 10:42:07 -0700 (PDT) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta03.emeryville.ca.mail.comcast.net with comcast id 6hed1h0071afHeLA3hi4Vd; Mon, 11 Jul 2011 17:42:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta17.emeryville.ca.mail.comcast.net with comcast id 6hiR1h02G0tdiYw8dhiSE6; Mon, 11 Jul 2011 17:42:27 +0000 Message-ID: <4E1B35EC.60103@alum.mit.edu> Date: Mon, 11 Jul 2011 13:42:04 -0400 From: Paul Kyzivat 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: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] Change of affiliation 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, 11 Jul 2011 17:42:07 -0000 For anyone who cares, I accepted an opportunity to leave Cisco on favorable terms, and am now a free agent. I intend to continue my full participation in IETF while I decide what to do next. I expect that I will continue to be involved in the field one way or another. I'll be seeing you all in Quebec City. Thanks, Paul From dworley@avaya.com Mon Jul 11 11:55: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 F3D5121F8E63 for ; Mon, 11 Jul 2011 11:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.25 X-Spam-Level: X-Spam-Status: No, score=-103.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 I5lYpvy8EOD0 for ; Mon, 11 Jul 2011 11:55:49 -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 0078721F8DB5 for ; Mon, 11 Jul 2011 11:55:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgABAA1GG06HCzI1/2dsb2JhbABTl2WPN3etKwKbOYVbXwSXb4tI X-IronPort-AV: E=Sophos;i="4.65,516,1304308800"; d="scan'208";a="255998782" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Jul 2011 14:55:46 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Jul 2011 14:48:47 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Mon, 11 Jul 2011 14:55:45 -0400 From: "Worley, Dale R (Dale)" To: Shida Schubert Date: Mon, 11 Jul 2011 14:55:45 -0400 Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis Thread-Index: Acw+0DQSy4Ac8gpxR3CVAB27tHKBTQBKxgga 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 Cc: "sipcore@ietf.org WG" 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: Mon, 11 Jul 2011 18:55:50 -0000 (replying to the message below) Cullen was raising the question "Exactly how do you use History-Info to mak= e the decisions that we think it will allow to be made?" My concept is tha= t we should present algorithms that (allegedly) process History-Info to mak= e the decisions needed by the various use cases. My message "[sipcore] 424= 4bis Application processing" (http://www.ietf.org/mail-archive/web/sipcore/= current/msg04186.html) was an attempt to present such algorithms -- note th= at those algorithms work in a different way than do the algorithms in 4244b= is. In principle, you can read the algorithms and tell whether or not Hist= ory-Info (as we have defined it), processed by the presented algorithm, doe= s what the use case needs. If it *does*, then we know that History-Info ca= ptures enough information for the use case. Dale ________________________________________ From: Shida Schubert [shida@ntt-at.com] Sent: Sunday, July 10, 2011 3:08 AM To: Worley, Dale R (Dale) Cc: Cullen Jennings; sipcore@ietf.org WG Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis Hi Dale; Could you elaborate as to what you are suggesting? Regards Shida On Jun 23, 2011, at 4:50 AM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Cu= llen Jennings [fluffy@cisco.com] > >> However, I would like to see some text added to section 8 that allowed i= mplementers 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. > _______________________________________________ > > Most importantly, presenting algorithms for the use cases allows the read= er to verify that the mechanism does accomplish what it was designed to do,= and that there are not peculiar cases where the mechanism fails. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From dworley@avaya.com Mon Jul 11 11:59: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 13D0921F8ADE for ; Mon, 11 Jul 2011 11:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.263 X-Spam-Level: X-Spam-Status: No, score=-103.263 tagged_above=-999 required=5 tests=[AWL=0.336, 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 1dVdtDy0MnCs for ; Mon, 11 Jul 2011 11:59:05 -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 B57D221F86D1 for ; Mon, 11 Jul 2011 11:59:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPxGG07GmAcF/2dsb2JhbABTpx93rS4CmzmFW18El2+LSA X-IronPort-AV: E=Sophos;i="4.65,516,1304308800"; d="scan'208";a="255999329" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Jul 2011 14:59:03 -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; 11 Jul 2011 14:57:32 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 11 Jul 2011 14:59:02 -0400 From: "Worley, Dale R (Dale)" To: Shida Schubert Date: Mon, 11 Jul 2011 14:56:30 -0400 Thread-Topic: [sipcore] Updates to 4244bis-05 Thread-Index: Acw+0Dmo/rTm+G6FSOiOnviBISX16wBLAU/v 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 , SIPCORE 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: Mon, 11 Jul 2011 18:59:06 -0000 ________________________________________ From: Shida Schubert [shida@agnada.com] It's not for backward compatibility. We couldn't come up with reason why reason should be included in case of 2xx responses. ________________________________________ Of course, there is always the attraction of handling as many cases as poss= ible uniformly. But given that the only case in which the Reason is admitted is 2xx, and al= l 2xx's are largely created equal, leaving them off has few disadvantages. There might be cases when a 2xx carries a Reason showing a success code fro= m a downstream gateway. Dale From internet-drafts@ietf.org Mon Jul 11 16:46:35 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A1811E83E0; Mon, 11 Jul 2011 16:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 Gap4OACSLaIH; Mon, 11 Jul 2011 16:46:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5E811E83D3; Mon, 11 Jul 2011 16:46:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711234634.26333.11899.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 16:46:34 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-event-rate-control-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 23:46:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Work= ing Group of the IETF. Title : Session Initiation Protocol (SIP) Event Notification Ext= ension for Notification Rate Control Author(s) : Aki Niemi Krisztian Kiss Salvatore Loreto Filename : draft-ietf-sipcore-event-rate-control-08.txt Pages : 25 Date : 2011-07-11 This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. This document updates RFC 3265. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-event-rate-control-0= 8.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-event-rate-control-08= .txt From krisztian.kiss@nokia.com Mon Jul 11 17:12: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 A03C821F909D for ; Mon, 11 Jul 2011 17:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, 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 4wb2Dy8JsmyD for ; Mon, 11 Jul 2011 17:12:40 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2C121F9098 for ; Mon, 11 Jul 2011 17:12:39 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p6C0Cb8N032269 for ; Tue, 12 Jul 2011 03:12:38 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Jul 2011 03:12:32 +0300 Received: from 008-AM1MMR1-002.mgdnok.nokia.com (65.54.30.57) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 12 Jul 2011 02:12:31 +0200 Received: from 008-AM1MPN1-012.mgdnok.nokia.com ([169.254.1.63]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0323.002; Tue, 12 Jul 2011 02:12:31 +0200 From: To: Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-event-rate-control-08.txt Thread-Index: AQHMQCUsGhyD+B2wkkCnNXveTxauPZTnz8aA Date: Tue, 12 Jul 2011 00:12:30 +0000 Message-ID: References: <20110711234634.26333.11899.idtracker@ietfa.amsl.com> In-Reply-To: <20110711234634.26333.11899.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [99.92.93.52] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jul 2011 00:12:32.0403 (UTC) FILETIME=[64FC5630:01CC4028] X-Nokia-AV: Clean Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-event-rate-control-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2011 00:12:40 -0000 This version is addressing the remainder of the IESG comments. The rates ar= e now specified as decimal numbers rather than as fractions. Cheers, Krisztian -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of ext internet-drafts@ietf.org Sent: 2011. j=FAlius 11. 16:47 To: i-d-announce@ietf.org Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-event-rate-control-08.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Work= ing Group of the IETF. Title : Session Initiation Protocol (SIP) Event Notification Ext= ension for Notification Rate Control Author(s) : Aki Niemi Krisztian Kiss Salvatore Loreto Filename : draft-ietf-sipcore-event-rate-control-08.txt Pages : 25 Date : 2011-07-11 This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. This document updates RFC 3265. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-event-rate-control-0= 8.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-event-rate-control-08= .txt _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From hannes.tschofenig@gmx.net Wed Jul 13 03:20: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 1289B21F8877 for ; Wed, 13 Jul 2011 03:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 ecdjqPc1iG4e for ; Wed, 13 Jul 2011 03:20:15 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 30FF721F886C for ; Wed, 13 Jul 2011 03:20:14 -0700 (PDT) Received: (qmail invoked by alias); 13 Jul 2011 10:20:13 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp027) with SMTP; 13 Jul 2011 12:20:13 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19+7xtgoJp+W88JAJhk+pf+JsHXEu1awWHXZISKPV At2QpjoiAoUMUG From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jul 2011 13:20:12 +0300 Message-Id: To: "SIPCORE (Session Initiation Protocol Core) WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [sipcore] draft-ietf-sipcore-location-conveyance ? 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, 13 Jul 2011 10:20:26 -0000 Hi guys,=20 what is the status of draft-ietf-sipcore-location-conveyance? It is = fairly close to completion, I guess.=20 I did not see a new version submitted for this submission deadline and = there are still a few remarks from the IESG to address, see = https://datatracker.ietf.org/doc/draft-ietf-sipcore-location-conveyance/ba= llot/ I read through the document and here are my review comments:=20 1. I suggest to delete this sentence: "SIP acts as a Using Protocol of location information, as defined in=20 RFC 3693." 2. this sentence is difficult to parse (at least for me) - maybe = restructuring would help. " In order to convey location information, this document specifies three new SIP header fields, Geolocation, Geolocation-Routing and Geolocation-Error, which carry a reference to a Location Object (LO), grant permission to route a SIP request based on the location-value and provide error notifications specific to location errors respectively. " 3. I suggest to have a brief look at the Geopriv Arch document=20 http://www.rfc-editor.org/authors/rfc6280.txt and then to see what modifications are need for this paragraph from the = draft:=20 " A Target is an entity whose location is being conveyed, per RFC 3693 . Thus, a Target could be a SIP user agent (UA), some other IP device (a router or a PC) that does not have a SIP stack, a non-IP device (a person or a black phone) or even a non-communications device (a building or store front). In no way does this document assume that the SIP user agent client which sends a request containing a location object is necessarily the Target. The location of a Target conveyed within SIP typically corresponds to that of a device controlled by the Target, for example, a mobile phone, but such devices can be separated from their owners, and moreover, in some cases the user agent may not know its own location. " 4. Why aren't GEO URIs not appropriate? GEO-URIs [RFC5870] are not appropriate for usage in the SIP 5. What does this really mean? Other URI schemas used in the location URI MUST be reviewed against the=20 RFC 3693 [RFC3693] criteria for a Using Protocol. 6. In what cases are intermediaries allowed to modify or delete = locationValues? SIP intermediaries SHOULD NOT modify or delete any existing locationValue(s). 7. Editorial: The RFC Editor will insist on this.=20 Instead of "section X" write "Section X". 8. The Geopriv Privacy Considerations are more or less nonsense.=20 I suggest to reference the Geopriv Architecture doc instead of RFC3693.=20= While the text in the section says:=20 " [ID-GEO-ARCH] updates the guidance in RFC3693 to include subsequently-introduced entities and concepts in the geolocation architecture. " It does not even provide a brief summary of the privacy threat model or = the proposed countermeasures.=20 I would omit it and instead point to the Geopriv architecture document.=20= Ciao Hannes From keith.drage@alcatel-lucent.com Wed Jul 13 09:22: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 C903021F8753 for ; Wed, 13 Jul 2011 09:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.216 X-Spam-Level: X-Spam-Status: No, score=-106.216 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 aqaTpgNRMKBh for ; Wed, 13 Jul 2011 09:22:05 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id C982721F8752 for ; Wed, 13 Jul 2011 09:22:04 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p6DGLuhw006339 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Jul 2011 18:21:56 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 13 Jul 2011 18:21:57 +0200 From: "DRAGE, Keith (Keith)" To: "James M. Polk" , "sipcore@ietf.org" Date: Wed, 13 Jul 2011 18:21:54 +0200 Thread-Topic: [sipcore] New ID posted asking for two more RPH namespaces Thread-Index: Acw9stoS8qDG1cuvTdeT0bBkuy8pEADxZKkA Message-ID: References: <201107082105.p68L5pfh032286@mtv-core-2.cisco.com> In-Reply-To: <201107082105.p68L5pfh032286@mtv-core-2.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-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "Adarsh Kaithal \(akaithal\)" , Jack Klecha Subject: Re: [sipcore] New ID posted asking for two more RPH namespaces 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, 13 Jul 2011 16:22:05 -0000 The way this reads it gives the impression that these are not defined for p= riority purposes but for creating closed user groups. Assuming this is not = the case, maybe you can add some text that these are used only for priority= (and preemption) of individual groups within that group. Also, given that it appears that the intent is for all these namespaces to = coexist, maybe you need a few words on that and how that is handled. Can on= e namespace, defined by this document, preempt another, defined by this doc= ument, or is that precluded? Regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of James M. Polk > Sent: 08 July 2011 22:06 > To: sipcore@ietf.org > Cc: Adarsh Kaithal (akaithal); Jack Klecha > Subject: [sipcore] New ID posted asking for two more RPH namespaces >=20 > SIPCORE >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : IANA Registration of the UC and CUC Session > Initiation Protocol (SIP) Resource-Priority Namespaces > Author(s) : Adarsh Kaithal > James Polk > Jack Klecha > Filename : draft-kaithal-sipcore-rph-cuc-uc-namespaces-00.txt > Pages : 5 > Date : 2011-07-04 >=20 > This document creates two new Session Initiation Protocol (SIP) > Resource-Priority namespaces, and places these namespaces in the > IANA registry. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaithal-sipcore-rph-cuc-uc- > namespaces-00.txt >=20 > This is a simple 5 page draft requesting two new RPH namespaces be > IANA registered. There are no new semantics involved, and uses RFC > 5478 as a template for much of the text and all of the security > considerations. >=20 > Comments are appreciated >=20 > James, Adarsh and Jack >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From adam@nostrum.com Wed Jul 13 11:39: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 F0BE411E80D3 for ; Wed, 13 Jul 2011 11:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.205 X-Spam-Level: X-Spam-Status: No, score=-102.205 tagged_above=-999 required=5 tests=[AWL=0.395, 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 ZPbsXVWQCbVk for ; Wed, 13 Jul 2011 11:39:54 -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 3672211E80B2 for ; Wed, 13 Jul 2011 11:39:50 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6DIdjuV007679 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 13 Jul 2011 13:39:45 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4E1DE671.503@nostrum.com> Date: Wed, 13 Jul 2011 13:39:45 -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: Hannes Tschofenig References: In-Reply-To: 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: "draft-ietf-sipcore-location-conveyance@tools.ietf.org" , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance ? 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, 13 Jul 2011 18:39:55 -0000 [as chair] On 7/13/11 5:20 AM, Hannes Tschofenig wrote: > what is the status of draft-ietf-sipcore-location-conveyance? It is fairly close to completion, I guess. > I did not see a new version submitted for this submission deadline and there are still a few remarks from the IESG to address, see https://datatracker.ietf.org/doc/draft-ietf-sipcore-location-conveyance/ballot/ It would be unusual to allow meeting schedules to cause premature publication of a document in IESG review. The authors are presently working with the IESG to address the issues raised in the ballot. You can expect to see a new version once the IESG is satisfied with the authors' proposed changes. > I read through the document and here are my review comments: > Thanks for taking the time to review the document. Your input will be treated as IETF last call comments. /a From hannes.tschofenig@gmx.net Wed Jul 13 13:44:43 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636ED11E816B for ; Wed, 13 Jul 2011 13:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 uImukrDSOQMT for ; Wed, 13 Jul 2011 13:44:39 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5AD7A11E8155 for ; Wed, 13 Jul 2011 13:44:37 -0700 (PDT) Received: (qmail invoked by alias); 13 Jul 2011 20:44:35 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp008) with SMTP; 13 Jul 2011 22:44:35 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19br6Z1bjlbO/M1/GHV2Ps1jrvNwm4xD+x0MRbm3J 6qv+AMJ3USzdGX Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4E1DE671.503@nostrum.com> Date: Wed, 13 Jul 2011 23:44:33 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0851D70B-4CE4-4C17-8477-F04B68C32211@gmx.net> References: <4E1DE671.503@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "draft-ietf-sipcore-location-conveyance@tools.ietf.org" , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance ? 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, 13 Jul 2011 20:44:43 -0000 Thanks, Adam.=20 Great to see the progress. Hopefully we have an RFC published soon. On Jul 13, 2011, at 9:39 PM, Adam Roach wrote: > [as chair] >=20 > On 7/13/11 5:20 AM, Hannes Tschofenig wrote: >> what is the status of draft-ietf-sipcore-location-conveyance? It is = fairly close to completion, I guess. >> I did not see a new version submitted for this submission deadline = and there are still a few remarks from the IESG to address, see = https://datatracker.ietf.org/doc/draft-ietf-sipcore-location-conveyance/ba= llot/ >=20 > It would be unusual to allow meeting schedules to cause premature = publication of a document in IESG review. The authors are presently = working with the IESG to address the issues raised in the ballot. You = can expect to see a new version once the IESG is satisfied with the = authors' proposed changes. >=20 >=20 >> I read through the document and here are my review comments: >>=20 >=20 > Thanks for taking the time to review the document. Your input will be = treated as IETF last call comments. >=20 > /a From adam@nostrum.com Mon Jul 18 14:11: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 A577C21F871E for ; Mon, 18 Jul 2011 14:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.277 X-Spam-Level: X-Spam-Status: No, score=-102.277 tagged_above=-999 required=5 tests=[AWL=0.323, 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 LXSCCzOsloSp for ; Mon, 18 Jul 2011 14:11:06 -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 E451421F877F for ; Mon, 18 Jul 2011 14:11:05 -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 p6ILB4R0073740 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 18 Jul 2011 16:11:04 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4E24A168.9060002@nostrum.com> Date: Mon, 18 Jul 2011 16:11:04 -0500 From: Adam Roach - SIPCORE Chair 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: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Agenda for Next Week X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 21:11:06 -0000 [as chair] In case you didn't notice it, I have posted an agenda for next week's meeting on the meeting material site: http://www.ietf.org/proceedings/81/agenda/sipcore.html /a From pkyzivat@alum.mit.edu Wed Jul 20 11:30: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 70AF621F8B26 for ; Wed, 20 Jul 2011 11:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, J_CHICKENPOX_36=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 mqR0fzqx3W2Q for ; Wed, 20 Jul 2011 11:30:35 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id B02C221F8B1C for ; Wed, 20 Jul 2011 11:30:35 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta14.westchester.pa.mail.comcast.net with comcast id AJ8B1h0031HzFnQ5EJWc6R; Wed, 20 Jul 2011 18:30:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta14.westchester.pa.mail.comcast.net with comcast id AJWY1h00p0tdiYw3aJWZxT; Wed, 20 Jul 2011 18:30:35 +0000 Message-ID: <4E271EC6.4080607@alum.mit.edu> Date: Wed, 20 Jul 2011 14:30:30 -0400 From: Paul Kyzivat 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: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] Bug in RFC4235 (dialog event package)? 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, 20 Jul 2011 18:30:36 -0000 (as individual) I've come across what appears to me to be a bug 4235. But before filing it I'd like to get some other opinions on it. This has to do with the element used to represent the Contact address and its parameters. The parameters of a Contact can be 'feature-param's as defined in 3840, or various other things defined in 3261 and other extensions. The problem is that 4235 re-encodes contact parameters in a way that loses information, so that two semantically different parameters can be reported identically. An example given is: The corresponding Contact isn't given, but presumably is: Contact: sip:alice@pc33.example.com;isfocus="true";class="business"; description="";+sip.rendering="no" Note the change from description="" to This arises based on the following from 4.1.6.2: It can contain a list of Contact header parameters in param sub- elements (such as those defined in [10]). The param element contains two required attributes, pname and pval. Boolean parameters are represented by the explicit pval values, "true" and "false" (for example, when a feature parameter is explicitly negated). Parameters that have no value at all are represented by the explicit pval value "true". The param element itself has no contents. To avoid repeating Contact information in each request, the subscriber can assume that the target URI and parameters are the same as in previous notifications if no target element is present in the corresponding local or remote element. If a target element is present in the local or remote part of a notification, the new target tag and list of parameter tags completely supersedes the old target and parameter list in the corresponding part. Note that any quoting (including extra angle-bracket quoting used to quote string values in [10]) or backslash escaping MUST be removed before being placed in a pval attribute. Any remaining single quotes, double quotes, and ampersands MUST be properly XML escaped. Specifically, the second to last sentence calls for stripping the bracketing < and >. That bracketing is specified in 3840 for feature params: feature-param = enc-feature-tag [EQUAL LDQUOT (tag-value-list / string-value ) RDQUOT] enc-feature-tag = base-tags / other-tags base-tags = "audio" / "automata" / "class" / "duplex" / "data" / "control" / "mobility" / "description" / "events" / "priority" / "methods" / "schemes" / "application" / "video" / "language" / "type" / "isfocus" / "actor" / "text" / "extensions" other-tags = "+" ftag-name ftag-name = ALPHA *( ALPHA / DIGIT / "!" / "'" / "." / "-" / "%" ) tag-value-list = tag-value *("," tag-value) tag-value = ["!"] (token-nobang / boolean / numeric) token-nobang = 1*(alphanum / "-" / "." / "%" / "*" / "_" / "+" / "`" / "'" / "~" ) boolean = "TRUE" / "FALSE" numeric = "#" numeric-relation number numeric-relation = ">=" / "<=" / "=" / (number ":") number = [ "+" / "-" ] 1*DIGIT ["." 0*DIGIT] string-value = "<" *(qdtext-no-abkt / quoted-pair ) ">" qdtext-no-abkt = LWS / %x21 / %x23-3B / %x3D / %x3F-5B / %x5D-7E / UTF8-NONASCII The bracketing < and > serve to syntactically distinguish a string-value, which might look like a tag-value-list, from a tag-value-list. For instance: description="red,green,blue" has a tag value list with three tags, while description="" has a single string-value. These are handled quite differently by the matching rules of 3841. There is another "bug" in the 4235 example quoted above: It seems clear that sip.render was intended to represent a feature-param. If so, according to 3840, that would be represented in the Contact as +sip.render. If so, nothing in 4235 says to remove that "+" when encoding it in xml. If the + is removed, then the distinction between feature-params and other params is lost. I'd appreciate any thoughts others might have on this - whether its really a bug (I think that is clear), how significant it might be, and how it might be fixed. (I have some ideas for fixes, but nothing is pretty.) Thanks, Paul From aallen@rim.com Mon Jul 25 09:59: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 213B611E807A for ; Mon, 25 Jul 2011 09:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.089 X-Spam-Level: X-Spam-Status: No, score=-5.089 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 Ab0KlYG1wHxH for ; Mon, 25 Jul 2011 09:59:48 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 21D7921F888A for ; Mon, 25 Jul 2011 09:59:48 -0700 (PDT) X-AuditID: 0a41282f-b7b83ae000001e85-f8-4e2d9d6fc4c4 Received: from XHT108CNC.rim.net (xht108cnc.rim.net [10.65.22.54]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id BD.8D.07813.F6D9D2E4; Mon, 25 Jul 2011 16:44:32 +0000 (GMT) Received: from XCT103ADS.rim.net (10.67.111.44) by XHT108CNC.rim.net (10.65.22.54) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 25 Jul 2011 12:44:41 -0400 Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.01.0289.001; Mon, 25 Jul 2011 11:44:40 -0500 From: Andrew Allen To: Christer Holmberg , "SIPCORE (Session Initiation Protocol Core) WG" Thread-Topic: [sipcore] Draft submission: draft-ietf-sipcore-proxy-feature-reqs-00 Thread-Index: AcwvF0LKQFT7YaPITgGrkOCX9bk2pwbzoJQw Importance: high X-Priority: 1 Date: Mon, 25 Jul 2011 16:44:39 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05851DB5336480@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB5336480@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.253] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD23015972XMB105ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCKsWRmVeSWpSXmKPExsXC5ShmplswV9fP4NJ6LosLMw8zWnz9sYnN gcnj19erbB5LlvxkCmCKamC0SczLyy9JLElVSEktTrZV8klNT8xRCCjKLEtMrlRwySxOzknM zE0tUlLITLFVMlFSKMhJTE7NTc0rsVVKLChIzUtRsuNSwAA2QGWZeQqpecn5KZl56bZKnsH+ uhYWppa6hkp2ukgg4R93xp3bHewFr14xVlzc0cTYwHj1DGMXIyeHhICJxJQfP1khbDGJC/fW s3UxcnEICfQwSRw70gBWJCSwlFFiSbc9RGILo8Tn7/dYQBJsAsoSy3/PACsSEaiRmHf4FzuI LSwQLLG5fQM7RDxE4u33M8wQtpHE2WefwWxOAQGJX+2zWCA280pMmXsSrJ5FQFVi6t4PQDM5 OHgF3CQWvkyFuCFcomX2ZnaI1giJ/fuXs4HYjAKyErvPXmcCsZkFxCVuPZnPBDFSQGLJnvPM ELaoxMvH/6CeVJRY1PmdEaI+V2LpY4jzeQUEJU7OfMICsUtaYsfJNYwTGCVmIRk7C0nLLCQt EHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRWjYG5GsYGZQXJesl5RZq5eXmrJJkZwitLQ 38HYt1frEKMAB6MSD++vmbp+QqyJZcWVuYcYJTiYlUR4O52BQrwpiZVVqUX58UWlOanFhxhd gQE3kVmKOzkfmD7zSuKNDQxwc5TEeW2VVfyEBNKBaTI7NbUgtQhmDhMHp1QDo8jPDSYLjq5Z 0KEpmKbOEVV6pP3pCX1F27UFV2Wf/PrAuU5p99eK8GM51RXnVOalbzCVchMr2H9acmeEk3HI L6XYCjXRyN0Sq2Zbi3T3TjHeo5j54a2i7NptizY7T1ljpdNd4+nzyqxo89Hyj4L3xa8t47JO /THftOTpj4bnb2WbcvniF59yUmIpzkg01GIuKk4EAFq4d7F3AwAA Subject: Re: [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, 25 Jul 2011 16:59:53 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD23015972XMB105ADSrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Christer and all I have reviewed the requirements draft and I think it is a good start but I= don't think all the use cases and requirements have yet been captured. On January 21st 2011 I sent an email containing some additional use cases (i= ncluding some non IMS ones) to the SIPCORE list. These are not captured in t= he new draft and there hasn't yet been any discussion as to why they are not= also use cases and requirements to meet for proxy feature. The relevant con= tent of my earlier email is repeated below: ----------------------------------------------------------------------------= --------------------------------------------------------------------- I think the general requirement is that it is useful for UAs and other inter= mediaries to be able to detect the presence of an intermediary on the path= of a registration or the route of a dialog when that intermediary provides= some feature or service and be able to identify the URI of that intermediar= y in order to be able to address requests to it . In addition to the 3GPP sp= ecific use cases currently in the draft I think there are others including: Dealing with call feature interactions In a deployment where different intermediaries provide different call featur= es it is sometimes necessary to be able to detect that another intermediary= has invoked a particular feature as that may mean that a particular feature= should not be invoked or should be invoked in a way that takes account of t= he invocation of the feature by the other intermediary in order to prevent c= onflicts between different call features. Detecting the presence of a SIP PBX SIP PBXs may be present in a network and may provide call features and other= services on behalf of the UA. In some cases the UA may need to address requ= ests to the PBX to invoke some features or services. Although presence of th= e PBX could be indicated using configuration this isn't really effective whe= n there are mobile UAs moving between enterprise networks that have PBXs and= public networks that don't. Detecting the presence of a telephony application server. In 3GPP IMS Multimedia Telephony Service (MMTel) there is a Telephony Applic= ation Server (TAS) that provides call features on behalf of the UA. However= not all 3GPP networks will necessarily deploy MMTel so it is necessary that= a UA be able to identify that a TAS is involved in the call and be able to= send requests such as REFER to the TAS in order to perform functions like c= all transfer. Having the TAS always act as a full B2BUA and overwrite the Co= ntact is not a good solution as this will cause the loss of the GRUUs of the= far end UAs. ----------------------------------------------------------------------------= ---------------------------------------------------------------------- In addition to the above earlier requirements I have the following additiona= l input for consideration: If an SBC or other intermediary can identify to a UA its presence on the rou= te of a request and a URI that related request need to be routed via then th= e UA could know that related out of dialog requests need to be routed via th= at SBC (or intermediary) by including that URI in a route header. Then the S= BC (or intermediary) can do whatever messing of the header fields it needs t= o do to make that request (such as a REFER) be aligned with the original val= ues in the related request that the SBC (or intermediary) messed with so tha= t it works when it gets to the far end. I think this can help address the is= sues that SBC and other intermediaries cause for things like REFER and GRUU= where they monkey with things breaking end to end interoperability. I think that as well as the feature tag itself it also needs to be possible= to include a contact URI associated with the feature tag so that a request= can be addressed to or routed via the intermediary that supports the featur= e. Originally it was thought that the URI in the R-R, Route, Path or S-R hea= der could be used for that but it has been pointed out there are issues with= that because the URI may not be valid in both directions, also it may be me= ssed with by middleboxes, might be in local IP address space or simply not d= irectly reachable from the UA. Such a thing I think can deal with the direct= ionality problem. I also I have seen people defining feature tags with values that are URIs or= telephone numbers etc because they need a way to transport the URI that is= used to contact the intermediary. This is in my view an abuse of feature ta= gs as the value of the feature tag does not identify a capability but instea= d identifies a URI that can be used to contact the entity in order to invoke= the feature. However it seems clear that there is a need for an intermediar= y to be able to provide a contact URI (outside of all the constraints that t= he existing routing URI has) that another UA can use to route a request to t= hat intermediary. I think from the above the following additional requirements also need to be= considered: 1. It MUST be possible for an intermediary to indicate a contact URI a= ssociated with the indicated feature that can be used as a contact address (= i.e placed in the Request-URI) in order to contact the entity in order to pr= ovide the feature or perform some functionality that is part of the feature. 2. It MUST be possible for an intermediary to indicate multiple featur= es and to indicate different contact URIs for different features. 3. The contact URI should be routable from the intended consumer of th= e feature even when the routing URI is not globally routable (e.g because it= is behind a firewall, is private IP address space, obfuscated by an SBC etc= ) 4. It MUST be possible for the contact URI to contain any absolute URI= (not just a SIP URI e.g TEL, URN etc). 5. IT MUST be possible for an intermediary to indicate that out of dia= log requests related to this dialog need to be routed via the URI of the int= ermediary. Apologies for submitting this right before the WG discussion. I think this i= s very useful work but we need to fully nail down and discuss all the use ca= ses and requirements. Andrew From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf O= f Christer Holmberg Sent: Monday, June 20, 2011 1:57 AM To: SIPCORE (Session Initiation Protocol Core) WG Subject: [sipcore] Draft submission: draft-ietf-sipcore-proxy-feature-reqs-0= 0 Hi, I've submitted a requirements draft for proxy-feature (draft-ietf-sipcore-pr= oxy-feature-reqs-00). Based on discussions with the ADs and WG chairs, the draft only contains req= uirements. Based on e-mail discussions and off-line comments, I've also adde= d a number of requirements. The idea is to first agree on the requirements, and then focus on the soluti= on. 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 --------------------------------------------------------------------- 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. --_000_BBF5DDFE515C3946BC18D733B20DAD23015972XMB105ADSrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Christer and all

 

I have reviewed the requirements draft an= d I think it is a good start but I don’t think all the use cases and r= equirements have yet been captured.

 

On January 21st 2011 I sent an= email containing some additional use cases (including some non IMS ones) to= the SIPCORE list. These are not captured in the new draft and there hasn’t yet been any discussion as to why they are not= also use cases and requirements to meet for proxy feature. The relevant con= tent of my earlier email is repeated below:

 

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

 

I think the general requirement is tha= t it is useful for UAs and other intermediaries to be able to detect the pre= sence of an intermediary  on the path of a registration or the route of a dialog when that intermediary provides some feature or se= rvice and be able to identify the URI of that intermediary in order to be ab= le to address requests to it . In addition to the 3GPP specific use cases cu= rrently in the draft I think there are others including:

 

Dealing with call feature interactions=

 

In a deployment where different interm= ediaries provide different call features it is sometimes necessary to be abl= e to detect that another intermediary has invoked a particular feature as that may mean that a particular feature should not be invoked or= should be invoked in a way that takes account of the invocation of the feat= ure by the other intermediary in order to prevent conflicts between differen= t call features.

 

Detecting the presence of a SIP PBX

 

SIP PBXs may be present in a network a= nd may provide call features and other services on behalf of the UA. In some= cases the UA may need to address requests to the PBX to invoke some features or services. Although presence of the PBX could be= indicated using configuration this isn’t really effective when there= are mobile UAs moving between enterprise networks that have PBXs and public= networks that don’t. 

 

Detecting the presence of a telephony= application server.

 

In 3GPP IMS Multimedia Telephony Servi= ce (MMTel) there is a Telephony Application Server (TAS) that provides call= features on behalf of the UA. However not all 3GPP networks will necessarily deploy MMTel so it is necessary that a UA be able to ident= ify that a TAS is involved in the call and be able to send requests such as= REFER to the TAS in order to perform functions like call transfer. Having t= he TAS always act as a full B2BUA and overwrite the Contact is not a good solution as this will cause the los= s of the GRUUs of the far end UAs.

 

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

 

In addition to the above earlier requirem= ents I have the following additional input for consideration:

 

If an SBC or other intermediary can id= entify to a UA its presence on the route of a request and a URI that related= request need to be routed via then the UA could know that related out of dialog requests need to be routed via that SBC (or inte= rmediary) by including that URI in a route header. Then the SBC (or intermed= iary) can do whatever messing of the header fields it needs to do to make th= at request (such as a REFER) be aligned with the original values in the related request that the SBC (or= intermediary) messed with so that it works when it gets to the far end. I t= hink this can help address the issues that SBC and other intermediaries caus= e for things like REFER and GRUU where they monkey with things breaking end to end interoperability.

 

I think that as well as the feature ta= g itself it also needs to be possible to include a contact URI associated wi= th the feature tag so that a request can be addressed to or routed via the intermediary that supports the feature. Originally it= was thought that the URI in the R-R, Route, Path or S-R header could be use= d for that but it has been pointed out there are issues with that because th= e URI may not be valid in both directions, also it may be messed with by middleboxes, might be in local IP= address space or simply not directly reachable from the UA. Such a thing I= think can deal with the directionality problem.

 

I also I have seen people defining fea= ture tags with values that are URIs or telephone numbers etc because they ne= ed a way to transport the URI that is used to contact the intermediary. This is in my view an abuse of feature tags as the value= of the feature tag does not identify a capability but instead identifies a= URI that can be used to contact the entity in order to invoke the feature.= However it seems clear that there is a need for an intermediary to be able to provide a contact URI (outside= of all the constraints that the existing routing URI has) that another UA c= an use to route a request to that intermediary.

 

I think from the above the following a= dditional requirements also need to be considered:

 

1.      = ; It MUST be possible for an intermediary to indicate= a contact URI associated with the indicated feature that can be used as a c= ontact address (i.e placed in the Request-URI) in order to contact the entit= y in order to provide the feature or perform some functionality that is part of the feature.

2.      = ; It MUST be possible for an intermediary to indicate= multiple features and to indicate different contact URIs for different feat= ures.

3.      = ; The contact URI should be routable from the intended= consumer of the feature even when the routing URI is not globally routable= (e.g because it is behind a firewall, is private IP address space, obfuscat= ed by an SBC etc)

4.      = ; It MUST be possible for the contact URI to contain a= ny absolute URI (not just a SIP URI e.g TEL, URN etc).

5.      = ; IT MUST be possible for an intermediary to indicate= that out of dialog requests related to this dialog need to be routed via th= e URI of the intermediary.

 

Apologies for submitting this right befor= e the WG discussion. I think this is very useful work but we need to fully n= ail down and discuss all the use cases and requirements.

 

Andrew

 

From: sipcore-bou= nces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Monday, June 20, 2011 1:57 AM
To: SIPCORE (Session Initiation Protocol Core) WG
Subject: [sipcore] Draft submission: draft-ietf-sipcore-proxy-feature= -reqs-00

 

 

Hi,

 

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

 

Based on discussions with the ADs and WG ch= airs, 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 requireme= nts, and then focus on the solution.

 

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

 

 

Regards,

 

Christer

 

---------------------------------------------------------------------
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. --_000_BBF5DDFE515C3946BC18D733B20DAD23015972XMB105ADSrimnet_-- From mary.ietf.barnes@gmail.com Mon Jul 25 12:55:14 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E4B21F8B87 for ; Mon, 25 Jul 2011 12:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.434 X-Spam-Level: X-Spam-Status: No, score=-103.434 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, HTML_MESSAGE=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 pH0NrOozcdWd for ; Mon, 25 Jul 2011 12:55:13 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2FE21F8B85 for ; Mon, 25 Jul 2011 12:55:13 -0700 (PDT) Received: by vws12 with SMTP id 12so4035866vws.31 for ; Mon, 25 Jul 2011 12:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=M87kx6vJ4cI3sUk7Bd8tMkjyC6BavOjt6icHNGsTh0I=; b=KPKF1CfOylchXJKzXh64qDe7ePb9XRKKPpFHJKKZHjUCLYv4Zm7IOC5KOanp63gnYT YoVGpPPtHAAJnvPuJfWPEINV8/+eCiPUOp9T5X4U1r0kcKcwylJwUxygs5RTk0Tqt8KN yb1109grPTlqpfrlH89NODge279tuedgT3Esg= MIME-Version: 1.0 Received: by 10.52.93.72 with SMTP id cs8mr4722700vdb.518.1311623712527; Mon, 25 Jul 2011 12:55:12 -0700 (PDT) Received: by 10.52.167.34 with HTTP; Mon, 25 Jul 2011 12:55:12 -0700 (PDT) In-Reply-To: References: <064.81e343374deecdf821a6bab2507a302c@tools.ietf.org> Date: Mon, 25 Jul 2011 14:55:12 -0500 Message-ID: From: Mary Barnes To: Cullen Jennings Content-Type: multipart/alternative; boundary=20cf307cfdd476d3af04a8ea313b Cc: sipcore@ietf.org Subject: Re: [sipcore] rfc4244bis #44 (new): 4244bis-02: security section misleading 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, 25 Jul 2011 19:55:14 -0000 --20cf307cfdd476d3af04a8ea313b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable So, this is the issue that we were just discussing with regards to SEC-req-1. Note that the text and references are from RFC 4244). We did remove this text from the Security section and we should really just remove SEC-req-1. Regards, Mary. On Mon, Nov 8, 2010 at 12:14 AM, Mary Barnes wr= ote: > I agree. Removing this is consistent with some of the earlier text we > removed in terms handling and implications of missing information. > > Mary. > > On Sat, Nov 6, 2010 at 9:41 PM, sipcore issue tracker > wrote: > > #44: 4244bis-02: security section misleading > > > > Section 9 says: > > With the level of security provided by TLS (SEC-req-3), the > > information in the History-Info header can thus be evaluated to > > determine if information has been removed by evaluating the indices > > for gaps (SEC-req-1, SEC-req-2). It would be up to the application > > to define whether it can make use of the information in the case of > > missing entries. > > > > No, TLS doesn't do that. TLS only guarantees you that the next-hop or > > previous-hop is who its cert claims it to be (assuming you trust its > > anchor), and prevents tampering by something in-between you and that > > previous-hop or next-hop. That doesn't mean that previous-hop or next= - > > hop, or some upstream/downstream entity beyond it, did not modify the > H-I > > entries - including in ways which you cannot possibly detect. For > example > > it could have renumbered them, changed their content, etc. > > > > This section-9 paragraph is wrong, and we won't be able to satisfy the > > security requirements in appendix A.1 That's *OK*. We're not going t= o > > get better than that. In fact, we basically need that behavior, since > we > > need PSTN Gateways to be able to generate H-I entries based on ISUP in= fo > > (even for numbers they don't own); and we need Diversion interworked t= o > > H-I too. > > > > -- > > > ------------------------------------+------------------------------------= --- > > Reporter: hkaplan@=85 | Owner: > > Type: defect | Status: new > > Priority: minor | Milestone: milestone1 > > Component: rfc4244bis | Version: 2.0 > > Severity: In WG Last Call | Keywords: > > > ------------------------------------+------------------------------------= --- > > > > Ticket URL: > > sipcore > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > --20cf307cfdd476d3af04a8ea313b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable So, this is the issue that we were just discussing with regards to SEC-req-= 1. Note that the text and references are from RFC 4244). =A0We did remove t= his text from the Security section and we should really just remove SEC-req= -1. =A0=A0

Regards,
Mary.=A0


On Mon, Nov 8, 2010 at 12:14 AM, Mary Barnes &= lt;mary.ietf.barnes@gmail.com= > wrote:
I agree. =A0Removing this is consistent wit= h some of the earlier text we
removed in terms handling and implications of missing information.

Mary.

On Sat, Nov 6, 2010 at 9:41 PM, sipcore issue tracker
<trac@tools.ietf.org> wrot= e:
> #44: 4244bis-02: security section misleading
>
> =A0Section 9 says:
> =A0 =A0With the level of security provided by TLS (SEC-req-3), the
> =A0 =A0information in the History-Info header can thus be evaluated to=
> =A0 =A0determine if information has been removed by evaluating the ind= ices
> =A0 =A0for gaps (SEC-req-1, SEC-req-2). =A0It would be up to the appli= cation
> =A0 =A0to define whether it can make use of the information in the cas= e of
> =A0 =A0missing entries.
>
> =A0No, TLS doesn't do that. =A0TLS only guarantees you that the ne= xt-hop or
> =A0previous-hop is who its cert claims it to be (assuming you trust it= s
> =A0anchor), and prevents tampering by something in-between you and tha= t
> =A0previous-hop or next-hop. =A0That doesn't mean that previous-ho= p or next-
> =A0hop, or some upstream/downstream entity beyond it, did not modify t= he H-I
> =A0entries - including in ways which you cannot possibly detect. =A0Fo= r example
> =A0it could have renumbered them, changed their content, etc.
>
> =A0This section-9 paragraph is wrong, and we won't be able to sati= sfy the
> =A0security requirements in appendix A.1 =A0That's *OK*. =A0We'= ;re not going to
> =A0get better than that. =A0In fact, we basically need that behavior, = since we
> =A0need PSTN Gateways to be able to generate H-I entries based on ISUP= info
> =A0(even for numbers they don't own); and we need Diversion interw= orked to
> =A0H-I too.
>
> --
> ------------------------------------+---------------------------------= ------
> =A0Reporter: =A0hkaplan@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 = Owner:
> =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 = =A0Status: =A0new
> =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milest= one: =A0milestone1
> Component: =A0rfc4244bis =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:= =A02.0
> =A0Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 | =A0 =A0Keywords:
> ------------------------------------+---------------------------------= ------
>
> Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/tic= ket/44>
> sipcore <http://tools.ietf.org/sipcore/>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>

--20cf307cfdd476d3af04a8ea313b-- From adam@nostrum.com Wed Jul 27 10:54:56 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E893521F8B0C for ; Wed, 27 Jul 2011 10:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.126, 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 dye0nxOxCRHC for ; Wed, 27 Jul 2011 10:54:54 -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 E1F8B21F8B3D for ; Wed, 27 Jul 2011 10:54:53 -0700 (PDT) Received: from Svantevit.local (dhcp-47dd.meeting.ietf.org [130.129.71.221]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6RHsqAJ066507 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 27 Jul 2011 12:54:52 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4E3050EB.3030606@nostrum.com> Date: Wed, 27 Jul 2011 13:54:51 -0400 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: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.71.221 is authenticated by a trusted mechanism) Subject: [sipcore] RFC 3265 -- I forgot to mention... 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, 27 Jul 2011 17:54:56 -0000 Christer pointed out a change that I forgot to mention during the session on Monday: If a SUBSCRIBE request to refresh a subscription receives a 404, 405, 410, 416, 480-485, 489, 501, or 604 response, the subscriber MUST consider the subscription terminated. This normative "MUST" used to be a lowercase "should." This change was already discussed on the list -- I'm just pointing it out again because I didn't mention it during the face-to-face meeting. /a From dworley@avaya.com Thu Jul 28 08:13: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 BC26B21F8CBD for ; Thu, 28 Jul 2011 08:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.166 X-Spam-Level: X-Spam-Status: No, score=-103.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_36=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 pDaiD1tS2kaK for ; Thu, 28 Jul 2011 08:13:55 -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 F041A21F873D for ; Thu, 28 Jul 2011 08:13:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHZ7MU7GmAcF/2dsb2JhbAA0AQEBAQIBFCxKDAIBCQ0BBy0QFCMuAQEDAgEWDBunMXeIfKZhApwBhWJfBJgeiwhT X-IronPort-AV: E=Sophos;i="4.67,282,1309752000"; d="scan'208";a="259250295" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Jul 2011 11:13:53 -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; 28 Jul 2011 11:11:25 -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, 28 Jul 2011 11:13:52 -0400 From: "Worley, Dale R (Dale)" To: Paul Kyzivat , SIPCORE Date: Thu, 28 Jul 2011 11:13:52 -0400 Thread-Topic: [sipcore] Bug in RFC4235 (dialog event package)? Thread-Index: AcxHCyV0HVDoYYqASt62nxIy0mkmHQGK6fBf Message-ID: References: <4E271EC6.4080607@alum.mit.edu> In-Reply-To: <4E271EC6.4080607@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Bug in RFC4235 (dialog event package)? 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, 28 Jul 2011 15:13:55 -0000 > From: Paul Kyzivat [pkyzivat@alum.mit.edu] >=20 > The problem is that 4235 re-encodes contact parameters in a way that > loses information, so that two semantically different parameters can be > reported identically. >=20 > An example given is: >=20 > > > > > > >=20 > The corresponding Contact isn't given, but presumably is: >=20 > Contact: sip:alice@pc33.example.com;isfocus=3D"true";class=3D"business"; > description=3D"";+sip.rendering=3D"no" I believe that this behavior was intended, though (IMHO) it is not a good design -- instead, I would prefer that the elements carry the parameter name/value pairs in a way that is isomorphic to what can be given in a Contact header. (Including properly distinguishing ';p' from ';p=3D""'.) But if the reader of knows the semantics of the particular parameter (whether the value part is a tag-value-list or a string-value), it can properly reconstruct the parameter's value as represented in the SIP message. The problem is if the reader of does not know a priori the type of the parameter, or if parameters are introduced that are not feature parameters. > I'd appreciate any thoughts others might have on this - whether its > really a bug (I think that is clear), how significant it might be, and > how it might be fixed. (I have some ideas for fixes, but nothing is prett= y.) We might change 4235 to specify that parameters that are not feature parameters are handled in the way I preferred above. (Distinguishing feature parameters from others can be done absolutely by the rules in RFC 3840. > There is another "bug" in the 4235 example quoted above: >=20 > It seems clear that sip.render was intended to represent a > feature-param. If so, according to 3840, that would be represented in > the Contact as +sip.render. If so, nothing in 4235 says to remove that > "+" when encoding it in xml. If the + is removed, then the distinction > between feature-params and other params is lost. I suspect that the text is what is intended and the example is wrong and should be: What is the current implementation practice? Dale