From dworley@nortel.com Mon Jun 1 12:54:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E513A7140 for ; Mon, 1 Jun 2009 12:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEhGBav8g82i for ; Mon, 1 Jun 2009 12:54:52 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 7C64C3A6DAD for ; Mon, 1 Jun 2009 12:54:52 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n51JsLq19150; Mon, 1 Jun 2009 19:54:21 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Jun 2009 15:54:21 -0400 From: "Dale Worley" To: Adam Roach In-Reply-To: <4A1C4C45.90204@nostrum.com> References: <1240958114.18691.54.camel@victoria-pingtel-com.us.nortel.com> <4A1C4C45.90204@nostrum.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 01 Jun 2009 15:54:20 -0400 Message-Id: <1243886060.3743.74.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jun 2009 19:54:21.0084 (UTC) FILETIME=[C15D25C0:01C9E2F2] Cc: SIPCORE Subject: Re: [sipcore] Comments on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 19:54:54 -0000 On Tue, 2009-05-26 at 15:08 -0500, Adam Roach wrote: > > ** Editorial Comments on the comments on my editorial points: > > * section 3.1.2 > > > > The Request URI of a SUBSCRIBE request, most importantly, contains > > enough information to route the request to the appropriate entity per > > the request routing procedures outlined in SIP [RFC3261]. > > > > This is not necessarily true -- the routing is also affected by any > > Route headers in the request. In sipX, we use that feature so that we > > can present to the notifier a resource name (request-URI) that need > > not be the same as the SIP URI of the notifier. > > > > Would "The Request URI of a SUBSCRIBE request, in conjunction its Route > header fields, contains enough information..." satisfy your concern? I would prefer that the RFC say that SUBSCRIBEs to be routed as generic requests are. That avoids having to enumerate any complications of the routing process as defined elsewhere. The distinctive thing about SUBSCRIBEs is that the request-URI (of the SUBSCRIBE when it arrives at the notifier) identifies the resource. > > * section 4.4.1 > > > > NOTIFY requests are matched to such SUBSCRIBE requests if they > > contain the same "Call-ID", a "To" header field "tag" parameter which > > matches the "From" header field "tag" parameter of the SUBSCRIBE, and > > the same "Event" header field. Rules for comparisons of the "Event" > > header fields are described in Section 8.2.1. > > > > This is awkward. How about: > > > > NOTIFY and SUBSCRIBE requests are within the same subscription > > usage if they contain the same "Call-ID", a "To" header field "tag" > > parameter which matches the "From" header field "tag" parameter of > > the SUBSCRIBE, and the same "Event" header field. Rules for > > comparisons of the "Event" header fields are described in Section > > 8.2.1. > > > > Actually, I think this would be best served by recasting the association > as it relates to 3261 dialogs, and then adding on the "Event" matching. > I'll see if I can come up with something reasonable that conveys enough > information. You're right there. Re-reading my proposal, I see that it is not exactly correct either, but if we inherit 3261 dialogs, and then add the Event type/tag match, it will be exactly correct. > > * section 4.4.2. > > > > Notifier migration is an interesting concept. But note that the text > > is incorrect: > > > > Upon receipt of this NOTIFY message, the subscriber SHOULD attempt to > > re-subscribe (as described in the preceding sections). Note that > > this subscription is established on a new dialog, and does not re-use > > the route set from the previous subscription dialog. > > > > It's not correct to say the subscriber is "re-subscribing" (in the > > sense of the draft). > > I can see your point. I'll change it to something like "initate a new > subscription to the resource." > > > There is also the technical question of what > > request-URI the subscriber should use to re-subscribe. (see above) > > > > I think the intention was always that the subscriber would use the same > Request-URI (and, if relevant, Route) that was used to set up the > subscription that has just terminated. I'll clarify this point. One additional point to claify: What you mean is the request-URI/Route of the *initial* SUBSCRIBE for the subscription. Reading your sentence quickly, one might consider (as I once did) using the target-URI/route-set of the established subscription, which is not guaranteed to work. (E.g., in sipX, the route-set URIs can carry authorization information that is bound to the dialog identifiers.) There are some tricky problems regarding attempting to reestablish a subscription. (Think of time-based routing.) I think that the proper way to deal with them is to ignore them (in regard to these passages), and leave the subscriber with a generalized (and vague) obligation to "reestablish the subscription" -- the problems are implied by that commandment (if the implementer knows what he is doing). > > * section 5.1 > > > > When designing an event package using the methods described in this > > document for event notification, it is important to consider: is SIP > > an appropriate mechanism for the problem set? Is SIP being selected > > > > The initial "is" of the clauses are not consistently capitalized. > > > > This issue isn't as simple as it appears at first. See, for example, > . If I > changed it to a capital letter, there's a good chance that I'd get a > request to change it back from someone who has a different sense of > aesthetics than you do (and I believe that there's a strong argument to > be made that the form in the current document is the more common form > for both American and British English). I've had to mediate these kinds > of disputes before, and was kind of hoping to avoid them this time -- in > particular, I don't want to have to add another paragraph like the final > paragraph of section 1.2 to clarify how I have chosen to treat colons > and capitalization. > > So, unless there is an argument that can be made regarding clarity, I'm > not accepting comments on the topic of typographical conventions. :) I wasn't aware of just how many ways one can handle the colon -- "The wonderful thing about standards is that there are so many to choose from!" > > > > * section 5.4 > > > > Event packages are not required to reiterate any of the behavior > > described in this document, although they may choose to do so for > > clarity or emphasis. In general, though, such packages are expected > > to describe only the behavior that extends or modifies the behavior > > described in this document. > > > > This reads strangely, as it suggests that an event package description > > might contradict the RFC. > > > > We certainly can't prevent it. :) > > Examples of where this happens include filtering and throttling, which > do actually change things like when NOTIFY messages are sent. 3265bis > (and 3265) say this happens when the state changes. The throttling > document says this happens when the state changes and/or when other > criteria are met. Good point. Dale From dworley@nortel.com Thu Jun 4 12:31:36 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98E223A70C8 for ; Thu, 4 Jun 2009 12:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75bfdg7eABnE for ; Thu, 4 Jun 2009 12:31:35 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id DD48B3A70BD for ; Thu, 4 Jun 2009 12:31:34 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n54JV4q18690; Thu, 4 Jun 2009 19:31:04 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 15:30:51 -0400 From: "Dale Worley" To: Adam Roach In-Reply-To: <4A1C4C45.90204@nostrum.com> References: <1240958114.18691.54.camel@victoria-pingtel-com.us.nortel.com> <4A1C4C45.90204@nostrum.com> Content-Type: text/plain Organization: Nortel Networks Date: Thu, 04 Jun 2009 15:30:50 -0400 Message-Id: <1244143850.3743.62.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jun 2009 19:30:51.0204 (UTC) FILETIME=[F83FC840:01C9E54A] Cc: SIPCORE Subject: Re: [sipcore] Comments on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 19:31:36 -0000 On Tue, 2009-05-26 at 15:08 -0500, Adam Roach wrote: > What you're identifying is a general philosophy that the types of state > deltas that make sense are better described by the event packages > themselves, instead of some generic state-delta mechanism. I'm intrigued > by your proposal to add versioning information to the base > specification, and would be interested in whether you have a > backwards-compatible proposal for doing so. I can't think of any mechanism that wouldn't take more effort than it is worth. E.g., we could easily define an option on the SUBSCRIBE Event header, and then suitable parameters on the NOTIFY Event header. But since all implementations would need to support the old style as well, nobody would save any coding effort. > This reflects the evolution of the document from its original mechanism > (which was, indeed, more event oriented than state oriented). I have the > same model in mind as you do -- that of conveying the state of the > resource. I agree that cleaning up all of the "event" language to > instead talk about states and state transitions would indeed be an > improvement. I'll add this to my list of changes for the next revision. The reason I'm interested in this is that the sipXecs notifier mechanism is designed based on the idea of sending state information -- the application publishes to the notifier subsystem the successive state values, and the subsystem takes care of sending the NOTIFYs. But the code cannot handle *event* notifications in the sense that people normally use the term. That is, the sipXecs mechanism was designed to implement the model that RFC 3265 appeared to use, but as a result, it cannot be used for "events" that do not fit that model. This is an example that if the RFC doesn't define a model and require conformance to it, people will not be able to implement machinery that can handle subscriptions generically, since each event package will violate the model in slightly different ways, and each event package will require additional custom coding. > Semantically, these are the same thing as hardwired filters on the > state. Do you have any concrete suggestions for treatment of this in the > base spec? Or should it simply be mentioned that some event packages > inherently contain the semantic equivalent of hard-coded filters? As I think of them, a filter restricts what information a subscriber may see. Implied by that is that changes in data that the subscriber may not see do not trigger notifications to the subscriber. I think what you're aiming for is an implied "notification threshold", where a change in certain data does not reach the threshold for sending a notification. Now that I go back and look, I see that thresholds are mentioned once in RFC 3265, in section 5.4.3. This ties in with the idea of events as state changes -- if we become more explicit that notification events are state changes, we need to become more explicit that various mechanisms can modulate which state changes trigger notification. > > - In principle, the state should not be affected by who has subscribed > > to received notifications for it. But there are circumstances where > > we want to be aware of the set of subscribers, and to be able to > > present differing information to them. The first job can probably > > be done (in principle) by examining the "winfo" state, but I don't > > know of a solution to the second. > You're venturing into the realm of things like the presence common > policy framework, which I think cover this very well. Do you have a > proposal for how to incorporate this into the base specification? The critical thing is not how to specify filtration, but to make explicit that it can be done, that we do not restrict the notifier to presenting the same information to two subscribers to the same resource, even if their subscriptions are identical. But that gets hard to implement within the model that subscribers are receiving some function of a common state -- if two subscriptions are identical, why would they receive different information? (Whereas the naive "state update" idea presumes that every subscriber sees the same state.) (Again, the sipXecs system assumes that what a subscriber sees is not dependent on the subscriber.) > Agreed. This version of the document puts far more emphasis on NOTIFY as > "the second leg in the three-way handshake." As such, I'm inclined to > deprecate the conveyance of any information in SUBSCRIBE responses, and > use NOTIFY requests exclusively. I'll do a pass of the document for > expires use in this regard. This problem is pretty messy. REGISTERs are fairly simple, since the information flows from UA to registrar and from registrar to UA are synchronized. In addition, the registrar cannot spontaneously modify the registration. So it's easy for the UA to maintain agreement with the registrar on when the registration expires. I like the idea of using the NOTIFYs exclusively for conveying expiration information, but that's not convenient for programming -- suppose the subscriber sends a reSUBSCRIBE and then doesn't get a NOTIFY? That case introduces Yet Another Timer into the code. I think we can simplify the situation by adding a few restrictions: - the subscriber may always terminate the subscription (by sending a SUBSCRIBE with Expires: 0), but otherwise may only postpone the expiration time of the subscription. - the notifier may always terminate the subscription (by sending a NOTIFY with Subscription-State: terminated), but otherwise may only postpone the expiration time of the subscription. Within these rules, the notifier behaves much as it does now. (The only change being that when a subscription is refreshed, the notifier may not shorten the requested subscription duration to before the previous expiration time.) And the subscriber can interpret both the 200's for the SUBSCRIBEs and the NOTIFYs consistently -- the latest expiration seen is the one currently in effect. (The only restriction is that the subscriber should never bring in an established expiration time.) > > If we do not assume that the subscriber can reliably get a NOTIFY from > > every SUBSCRIBE, then working out a reliable solution is more > > difficult, due to the race condition. > > > > There are related problems regarding terminology. The "length of a > > subscription" can mean two things, the "time from present" that it > > expires, or the absolute endpoint of the subscription. The draft says > > in various circumstances that a subscription cannot be lengthened > > without being specific what this means. As far as I can tell: when > > processing a SUBSCRIBE, a notifier must update the subscription > > endpoint of the subscription so that the time from present is no > > larger than what the subscriber requested (which is likely later than > > the previous endpoint); a notifier may unilaterally bring sooner the > > endpoint of a subscription so long as it notifies the subscriber; a > > subscriber's refresh duration request is unconstrained (in that it may > > require bringing forward the endpoint of the subscription, as well as > > postponing it). > > > > The rules are intended to operate exactly like expiration handling for > REGISTER. Is there any language you think is particularly ambiguous? The complexity comes because we want to allow a notifier to unilaterally terminate a subscription. And, as far as I can tell, to unilaterally shorten it. I don't think that registrars have this capability. (See what I wrote in the previous section.) > > * Notifier migration > > > > Notifier migration is an interesting concept and seems like it might > > be very useful. > > Note that the preponderance of this text was copied verbatim from > RFC3265, section 3.3.5. > > > But how does a subscriber take advantage of it? The > > text in 4.4.2 assumes that the subscriber will send a new > > out-of-dialog SUBSCRIBE to whatever URI it did originally. But will > > that obtain an alternative notifier for the resource whose notifier > > just ceased? The possibilities of SIP routing make that doubtful. > > > > Not really. There are a couple of architectures we had in mind when we > designed this mechanism: > > 1. The proxy/registrar has a "default" destination that it will send > SUBSCRIBE requests to when a user has no registered UAs. This > "default" destination could serve proper state for the > corresponding resource (or even act as a simple "parking lot", > from which subscribers will be migrated once the watched user has > a UA registered). > > 2. The notifier is part of a cluster of notifiers that can all > service requests corresponding to the user. In order to take the > notifier offline, it informs its clustering mechanism that it is > no longer accepting new traffic, and then sends NOTIFY messages to > each subscribed UA for the purpose of moving them to a notifier > that is not going offline. Once all such subscriptions are shed, > the node can be taken out of service. A similar mechanism can be > used to rebalance subscriptions after adding notifiers to a cluster. > > In any case, it's not the subscriber taking advantage of this mechanism; > it's the notifier. Thinking about this some more, it seems to be clear that there is no better alternative than "resubscribe to the request-URI you subscribed to". There are all sorts of possible snafus, but they are no different than anywhere else in SIP. If the notifier wants to direct the subscriber to a particular alternative notifier, it can use REFER, as you describe below: > > What we want is for the notifier to give the subscriber a > > globally-routable URI that will reach an alternative notifier, but > > there seems to be no mechanism to carry the URI. > > > > At the risk of triggering your "REFER means everything" rant, I think > this kind of operation would best be served by using REFER to initiate > the equivalent of a "blind transfer" of the subscription. This looks a > lot like figure 1 of > draft-ietf-sipping-cc-transfer-12 (except with "SUBSCRIBE" instead of > "INVITE"). Hmmm, that seems like a good idea. You can avoid my rant by explicitly defining this mechanism in the draft -- that a notifier can explicitly replace itself with another notifier by sending a REFER within the subscription dialog. Using REFER is also upward compatible, since the subscriber will fail the REFER if it does not implement the mechanism. Dale From pkyzivat@cisco.com Thu Jun 4 13:23:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7942F3A6CE2 for ; Thu, 4 Jun 2009 13:23:29 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-Y5PtL8KGem for ; Thu, 4 Jun 2009 13:23:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 50E673A6D48 for ; Thu, 4 Jun 2009 13:23:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,307,1241395200"; d="scan'208";a="195041381" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 04 Jun 2009 20:23:30 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n54KNSud000384; Thu, 4 Jun 2009 16:23:28 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n54KNSxj014026; Thu, 4 Jun 2009 20:23:28 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 16:23:28 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jun 2009 16:23:28 -0400 Message-ID: <4A282D39.2090401@cisco.com> Date: Thu, 04 Jun 2009 16:23:21 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dale Worley References: <1240958114.18691.54.camel@victoria-pingtel-com.us.nortel.com> <4A1C4C45.90204@nostrum.com> <1244143850.3743.62.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1244143850.3743.62.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jun 2009 20:23:28.0249 (UTC) FILETIME=[51FE9E90:01C9E552] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3740; t=1244147008; x=1245011008; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Comments=20on=20draft-roach -sipcore-rfc3265bis-00 |Sender:=20 |To:=20Dale=20Worley=20; bh=UHeFDaXMzyTtbnTAhOj+n55UJEdDpX8sJPDe5XFInhA=; b=NuWL7kZi9zpCzoSswBrE5hgN5kSNDIyG9gpQex+C86rurVELAbR8vRpOwB Tl/XgVV0XpDFCofDGfAYzR0BxVpBgpA9DhO5oAClLBa4WLpvkIAwz3ooEOSF o1wktn13Di; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Comments on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 20:23:29 -0000 Dale Worley wrote: > I think we can simplify the situation by adding a few restrictions: > > - the subscriber may always terminate the subscription (by sending a > SUBSCRIBE with Expires: 0), but otherwise may only postpone the > expiration time of the subscription. > > - the notifier may always terminate the subscription (by sending a > NOTIFY with Subscription-State: terminated), but otherwise may only > postpone the expiration time of the subscription. > > Within these rules, the notifier behaves much as it does now. (The only > change being that when a subscription is refreshed, the notifier may not > shorten the requested subscription duration to before the previous > expiration time.) And the subscriber can interpret both the 200's for > the SUBSCRIBEs and the NOTIFYs consistently -- the latest expiration > seen is the one currently in effect. (The only restriction is that the > subscriber should never bring in an established expiration time.) > >>> If we do not assume that the subscriber can reliably get a NOTIFY from >>> every SUBSCRIBE, then working out a reliable solution is more >>> difficult, due to the race condition. >>> >>> There are related problems regarding terminology. The "length of a >>> subscription" can mean two things, the "time from present" that it >>> expires, or the absolute endpoint of the subscription. The draft says >>> in various circumstances that a subscription cannot be lengthened >>> without being specific what this means. As far as I can tell: when >>> processing a SUBSCRIBE, a notifier must update the subscription >>> endpoint of the subscription so that the time from present is no >>> larger than what the subscriber requested (which is likely later than >>> the previous endpoint); a notifier may unilaterally bring sooner the >>> endpoint of a subscription so long as it notifies the subscriber; a >>> subscriber's refresh duration request is unconstrained (in that it may >>> require bringing forward the endpoint of the subscription, as well as >>> postponing it). >>> >> The rules are intended to operate exactly like expiration handling for >> REGISTER. Is there any language you think is particularly ambiguous? > > The complexity comes because we want to allow a notifier to unilaterally > terminate a subscription. And, as far as I can tell, to unilaterally > shorten it. I don't think that registrars have this capability. (See > what I wrote in the previous section.) As appealing as this proposal is, I see a couple of issues: After a (re)SUBSCRIBE, you will receive both a 200(SUBSCRIBE) and a NOTIFY. There is no guarantee which will arrive first. Which one do you believe for the expiration time? If it was a reSUBSCRIBE, the subscriber doesn't even know if the NOTIFY was a result of the reSUBSCRIBE or was sent previously. Perhaps saying that you can only extend, not reduce, would help here. But the no-reduce rule has its own trouble. In particular my usual source of exceptions to everything: 3pcc. The subscriber may think he is continuing a single subscription. But a middle box may be moving a subscription from one UAS to another. The new target may not be willing to support such a long subscription, and so may have need to reduce it. (Perhaps an answer to that would be to put the burden on the middle box to "make it right" by managing different expiration times on the two sides. But that can be difficult.) And then there is the general issue: practically speaking, can we ever add new restrictions? Backward compatibility issues will require most everyone to support cases where those restrictions aren't observed. Thanks, Paul From Glenn.Cahall@Level3.com Thu Jun 4 13:50:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D62C3A68A5 for ; Thu, 4 Jun 2009 13:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEqrgG2fya8y for ; Thu, 4 Jun 2009 13:50:25 -0700 (PDT) Received: from mail37.messagelabs.com (mail37.messagelabs.com [216.82.241.83]) by core3.amsl.com (Postfix) with SMTP id A73003A67E9 for ; Thu, 4 Jun 2009 13:50:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Glenn.Cahall@Level3.com X-Msg-Ref: server-14.tower-37.messagelabs.com!1244148626!23337250!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [209.245.18.106] Received: (qmail 4583 invoked from network); 4 Jun 2009 20:50:26 -0000 Received: from unknown.level3.net (HELO f10bb8-10) (209.245.18.106) by server-14.tower-37.messagelabs.com with SMTP; 4 Jun 2009 20:50:26 -0000 Received: from idc1embx0003.corp.global.level3.com (idc1embx0003.corp.global.level3.com [10.1.9.78]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by f10bb8-10 (Postfix) with ESMTP id 23C7B447A for ; Thu, 4 Jun 2009 20:50:26 +0000 (GMT) Received: from idc1embx0003.corp.global.level3.com ([10.1.9.78]) by idc1embx0003.corp.global.level3.com ([10.1.9.78]) with mapi; Thu, 4 Jun 2009 14:50:25 -0600 From: "Cahall, Glenn" To: "sipcore@ietf.org" Date: Thu, 4 Jun 2009 14:50:24 -0600 Thread-Topic: Reuse of Sip Call-Id question.. Thread-Index: AcnlVhVmBxaxhqnkQUu5KarjnRMthw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E29E40522A7DEE4AAF590882786809AD15CC655CD6idc1embx0003c_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 04 Jun 2009 15:56:13 -0700 Subject: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 20:50:29 -0000 --_000_E29E40522A7DEE4AAF590882786809AD15CC655CD6idc1embx0003c_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, I work for a VoIP company, Level3 Communications, and have been doing some = research on the internet about a specific condition that has arisen here dealing with the Sip protocol. Y= our names came up during my research. Was hoping I could get some feedback about the reuse of Sip Call-Id. We have customer UAs that are reusing the same Sip Call-Id for multiple cal= l attempts into our network. After reviewing the Sip RFC 3261, both myself and my team concluded that th= is was a clear violation of the spec. based on the following verbiage... 8.1.1.4 Call-ID The Call-ID header field acts as a unique identifier to group together a series of messages. It MUST be the same for all requests and responses sent by either UA in a dialog. It SHOULD be the same in each registration from a UA. In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior. All SIP UAs must have a means to guarantee that the Call- ID header fields they produce will not be inadvertently generated by any other UA. Note that when requests are retried after certain However, some voice engineers are stating that the definition of "globally = unique over time and space" means only during the context of a given call. Therefore, once this context is over....Sip Call-= Id can in fact be reused in the very next context. What is your take on this? Thanks, Glenn E. Cahall Sr. Architect Level3 Communications --_000_E29E40522A7DEE4AAF590882786809AD15CC655CD6idc1embx0003c_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

I work for a VoIP company, Level3 Communications, and ha= ve been doing some research on the internet about

a specific condition that has arisen here dealing with t= he Sip protocol.  Your names came up during my research.

Was hoping I could get some feedback about the reuse of = Sip Call-Id.

 

We have customer UAs that are reusing the same Sip Call-= Id for multiple call attempts into our network. 

 

After reviewing the Sip RFC 3261, both myself and my tea= m concluded that this was a clear violation of the spec.  based

on the following verbiage...

 

8.1.1.4 Call-ID

 

   The Call-ID header field acts as a unique identifier to group

   together a series of messages.  It MUS= T be the same for all requests

   and responses sent by either UA in a dialog.  It SHOULD be the same

   in each registration from a UA.<= /span>

 

   In a new request created by a UAC outside o= f any dialog, the Call-ID

   header field MUST be selected by the UAC as= a globally unique

   identifier over space and time unless overridden by method-specific

   behavior.  All SIP UAs must have a mea= ns to guarantee that the Call-

   ID header fields they produce will not be inadvertently generated by

   any other UA.  Note that when requests= are retried after certain

 

 

 

However, some voice engineers are stating that the definition of “globally unique over time and space”  means only during the

context of a given call.  Therefore, once this cont= ext is over....Sip Call-Id can in fact be reused in the very next context.=

 

 

What is your take on this?

 

 

Thanks,

Glenn E. Cahall

Sr. Architect

Level3 Communications

 

 

 

--_000_E29E40522A7DEE4AAF590882786809AD15CC655CD6idc1embx0003c_-- From pkyzivat@cisco.com Thu Jun 4 17:13:13 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AC033A6950 for ; Thu, 4 Jun 2009 17:13:13 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pzz7+EPR9onU for ; Thu, 4 Jun 2009 17:13:12 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 63E5F3A68EE for ; Thu, 4 Jun 2009 17:13:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,307,1241395200"; d="scan'208";a="172833771" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 05 Jun 2009 00:13:14 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n550DEKL003451; Thu, 4 Jun 2009 20:13:14 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n550DE8g000629; Fri, 5 Jun 2009 00:13:14 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jun 2009 20:13:14 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 Jun 2009 20:13:14 -0400 Message-ID: <4A286319.4010902@cisco.com> Date: Thu, 04 Jun 2009 20:13:13 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Cahall, Glenn" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 05 Jun 2009 00:13:14.0052 (UTC) FILETIME=[6AF93840:01C9E572] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1343; t=1244160794; x=1245024794; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Reuse=20of=20Sip=20Call-Id= 20question.. |Sender:=20 |To:=20=22Cahall,=20Glenn=22=20; bh=itJdfZu0CuR0J3p3vK7yWhR5s2BbK2I4b6bbBrIs6Ww=; b=fKpUPSkU9zlIueTU3aphDQqxrJVaLlEyL5tHRaKc+A+Hiey4tQFAmCjYNX 2hX5191F785b61EazeiTwj3o/7TayreNbaTxx82jFbiZcfTYNKoirNUJTq/o P3RD2iUZ0H; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 00:13:13 -0000 Cahall, Glenn wrote: > We have customer UAs that are reusing the same Sip Call-Id for multiple > call attempts into our network. > > After reviewing the Sip RFC 3261, both myself and my team concluded that > this was a clear violation of the spec. based > on the following verbiage... ... > However, some voice engineers are stating that the definition of > “globally unique over time and space” means only during the > context of a given call. Therefore, once this context is over....Sip > Call-Id can in fact be reused in the very next context. :-) I would have thought that “globally unique over time and space” was pretty clear. I don't know how you can get from there to: "only during the context of a given call". In fact, "only during the context of a given call" is the *exception*, during which the same callid *may* be reused. Specifically, if you make several different INVITE attempts in pursuit of the same "call" then they may have the same callid, but must be distinguished by different from-tags. (This would typically come up if an initial request resulted in a 3xx response, and the UAC is recursing on the Contacts in the 3xx in an attempt to complete the call.) These guys have no legs to stand on, if you are accurately describing the situation. Thanks, Paul From Glenn.Cahall@Level3.com Fri Jun 5 08:18:03 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 567053A6B39 for ; Fri, 5 Jun 2009 08:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vk48tmG7kskK for ; Fri, 5 Jun 2009 08:18:02 -0700 (PDT) Received: from mail29.messagelabs.com (mail29.messagelabs.com [216.82.249.147]) by core3.amsl.com (Postfix) with SMTP id 7EB6B3A68E5 for ; Fri, 5 Jun 2009 08:18:02 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Glenn.Cahall@Level3.com X-Msg-Ref: server-7.tower-29.messagelabs.com!1244215084!26319698!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [209.245.18.107] Received: (qmail 4325 invoked from network); 5 Jun 2009 15:18:04 -0000 Received: from unknown.level3.net (HELO f10cc8-10) (209.245.18.107) by server-7.tower-29.messagelabs.com with SMTP; 5 Jun 2009 15:18:04 -0000 Received: from idc1embx0003.corp.global.level3.com (idc1embx0003.corp.global.level3.com [10.1.9.78]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by f10cc8-10 (Postfix) with ESMTP id 15EAB3417; Fri, 5 Jun 2009 15:18:04 +0000 (GMT) Received: from idc1embx0003.corp.global.level3.com ([10.1.9.78]) by idc1embx0003.corp.global.level3.com ([10.1.9.78]) with mapi; Fri, 5 Jun 2009 09:18:03 -0600 From: "Cahall, Glenn" To: Paul Kyzivat Date: Fri, 5 Jun 2009 09:18:02 -0600 Thread-Topic: [sipcore] Reuse of Sip Call-Id question.. Thread-Index: AcnlcmynRGF0FikKT72CP6C/6pr0SgAfMACg Message-ID: References: <4A286319.4010902@cisco.com> In-Reply-To: <4A286319.4010902@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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 15:18:03 -0000 Paul, Thanks for the response. Once I read your response, I felt that I needed to explain the situation in= more detail. Customer is sending us an INVITE, our response is a 486 BUSY. This exact s= cenario (all with same TNs) repeats itself 100+ times over the next 90 seco= nds or so. All 100+ INVITEs contain the same Call-Id. However, tag value = in the From field is different. So....now that you know more about the situation....is this in violation of= the RFC? Also, during our discussions on the topic, we argued whether or not Call-Id= could be reused. In short, as stated before, even if the initial call was= successful, they believed that as soon as that call was completed, they we= re free to use the exact same Call-Id on the very next call. Thanks for your input, Glenn -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Thursday, June 04, 2009 6:13 PM To: Cahall, Glenn Cc: sipcore@ietf.org Subject: Re: [sipcore] Reuse of Sip Call-Id question.. Cahall, Glenn wrote: > We have customer UAs that are reusing the same Sip Call-Id for multiple=20 > call attempts into our network.=20 >=20 > After reviewing the Sip RFC 3261, both myself and my team concluded that= =20 > this was a clear violation of the spec. based > on the following verbiage... ... > However, some voice engineers are stating that the definition of=20 > "globally unique over time and space" means only during the > context of a given call. Therefore, once this context is over....Sip=20 > Call-Id can in fact be reused in the very next context. :-) I would have thought that "globally unique over time and space" was=20 pretty clear. I don't know how you can get from there to: "only during=20 the context of a given call". In fact, "only during the context of a given call" is the *exception*,=20 during which the same callid *may* be reused. Specifically, if you make=20 several different INVITE attempts in pursuit of the same "call" then=20 they may have the same callid, but must be distinguished by different=20 from-tags. (This would typically come up if an initial request resulted=20 in a 3xx response, and the UAC is recursing on the Contacts in the 3xx=20 in an attempt to complete the call.) These guys have no legs to stand on, if you are accurately describing=20 the situation. Thanks, Paul From bcampen@estacado.net Fri Jun 5 08:27:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E88BD3A6808 for ; Fri, 5 Jun 2009 08:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Kew2qTR6+NK for ; Fri, 5 Jun 2009 08:27:47 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 3746F3A6B64 for ; Fri, 5 Jun 2009 08:27:47 -0700 (PDT) Received: from dn3-233.estacado.net (dn3-233.estacado.net [172.16.3.233]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n55FQig2071522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Jun 2009 10:26:44 -0500 (CDT) (envelope-from bcampen@estacado.net) Message-Id: <26A8F7B3-FC88-4CA1-96B4-3A80150C49F1@estacado.net> From: Byron Campen To: "Cahall, Glenn" In-Reply-To: Content-Type: multipart/signed; boundary=Apple-Mail-42--379568087; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 5 Jun 2009 10:26:39 -0500 References: <4A286319.4010902@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 15:27:49 -0000 --Apple-Mail-42--379568087 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Yeah, they are completely wrong on this one. My first thought when I saw your email was that you were pulling our leg (or that these engineers were pulling yours). But, upon reflection, I have seen things just about as broken at SIPit. Best regards, Byron Campen > Paul, > > Thanks for the response. > > Once I read your response, I felt that I needed to explain the > situation in more detail. > > Customer is sending us an INVITE, our response is a 486 BUSY. This > exact scenario (all with same TNs) repeats itself 100+ times over > the next 90 seconds or so. All 100+ INVITEs contain the same Call- > Id. However, tag value in the From field is different. > > So....now that you know more about the situation....is this in > violation of the RFC? > > Also, during our discussions on the topic, we argued whether or not > Call-Id could be reused. In short, as stated before, even if the > initial call was successful, they believed that as soon as that call > was completed, they were free to use the exact same Call-Id on the > very next call. > > Thanks for your input, > Glenn > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, June 04, 2009 6:13 PM > To: Cahall, Glenn > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Reuse of Sip Call-Id question.. > > > > Cahall, Glenn wrote: > >> We have customer UAs that are reusing the same Sip Call-Id for >> multiple >> call attempts into our network. >> >> After reviewing the Sip RFC 3261, both myself and my team concluded >> that >> this was a clear violation of the spec. based >> on the following verbiage... > ... >> However, some voice engineers are stating that the definition of >> "globally unique over time and space" means only during the >> context of a given call. Therefore, once this context is over....Sip >> Call-Id can in fact be reused in the very next context. > > :-) > > I would have thought that "globally unique over time and space" was > pretty clear. I don't know how you can get from there to: "only during > the context of a given call". > > In fact, "only during the context of a given call" is the *exception*, > during which the same callid *may* be reused. Specifically, if you > make > several different INVITE attempts in pursuit of the same "call" then > they may have the same callid, but must be distinguished by different > from-tags. (This would typically come up if an initial request > resulted > in a 3xx response, and the UAC is recursing on the Contacts in the 3xx > in an attempt to complete the call.) > > These guys have no legs to stand on, if you are accurately describing > the situation. > > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail-42--379568087 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGZDCCAx0w ggKGoAMCAQICEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDkyMzA0MzgwNFoXDTA5MDkyMzA0Mzgw NFowazEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQxIzAhBgkqhkiG9w0BCQEWFGRvY2ZhcmFkYXlAZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIGiyvzQgsqDjR3TiFTO4nkc/VRo/eX6xKu ky4CR2QtnIPEWhNLbU5UgXdGzU3YWx/cRj5alT0auKVQ/BnjCbf3bFSzP5mIfV6KlJV89dpxKQQA 3FaDYxE3whiRPIjQh3nmqxSacBTLohlt/g8MlFyiHoNs3XcH83M3QMjMxU8pD7SgXUDaXdtqC8vV +7g3rzPmlONdJ+4vac159wuZe37WVTsFI4sYL3p/KvqT1NZhmn1cmOVWKfCVAdGLk8VEUZtWuSeM NU5CLnFvenxaSPkDeVR5h0qDpw4DQyHfWXQuKvRs1WgVeHASz87EPgncyp90yiByetvE0WIBGKiz 0QIDAQABo0cwRTA1BgNVHREELjAsgRRiY2FtcGVuQGVzdGFjYWRvLm5ldIEUZG9jZmFyYWRheUBn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQANmDZo4t+1SrO9nb8KfjN4 QtlV1gzaAa2jEsAZ369PBXdsxVz32a1JIa1KudXFfMMxtF1NRDJ0Z3ib/qq+L8B28IpkYgRWtRr+ WWm6LzJ6rm1Q85cC0VSqoIRr+NoRZjaBdqWbJC4QsPnwVSXN9jLMLkFkjcxVDSxQtEx6v1PF9zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUP SAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0Eu Y3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2f Ni/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH 1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQW7SrCyoCwnsms5MfcqmjmzAJBgUr DgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2 MDUxNTI2NDBaMCMGCSqGSIb3DQEJBDEWBBS4v+vP+/MT7FPol/M3qKXgSDRLEzCBhQYJKwYBBAGC NxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsq AsJ7JrOTH3Kpo5swgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEBBQAEggEASfk/ yUWxgAyUogBKNW8kmP6ZYYakOvokMSjXdKaid9i8YTaIHi2AH4IYWKOdBxsxVEa/C7OT91SLoKpC POdoaMoRmpndVprJa+Mk9O6kW3m89+vGOexZpjfKDwsJYDpkIVjbmJ4NybVmGLKIoHOoY5LTYcLe Ld7URfN/OUrFJWp8jhL6IRDd4i3n5UNye48M6vakEkEEQg3+DcncSZ70mXQJAgsjGpqWtgrTnUyU vimCTfSsdpI/8yXCf2KoSZApvzRJeEV6KwrNbFT5vAfusJ5qAgSt/uNLqcqnensG9SnkCwIzYAjd LWn79e/cQOutDGqA9iNMCX1oaJDaFYo3eQAAAAAAAA== --Apple-Mail-42--379568087-- From pkyzivat@cisco.com Fri Jun 5 08:30:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D4A43A6808 for ; Fri, 5 Jun 2009 08:30:27 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VQCB5B310pl for ; Fri, 5 Jun 2009 08:30:26 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 27BA73A6B9A for ; Fri, 5 Jun 2009 08:30:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,312,1241395200"; d="scan'208";a="46382496" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 05 Jun 2009 15:30:26 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n55FUQFt003578; Fri, 5 Jun 2009 11:30:26 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n55FUQD6003498; Fri, 5 Jun 2009 15:30:26 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jun 2009 11:30:26 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Jun 2009 11:30:26 -0400 Message-ID: <4A293A10.2050802@cisco.com> Date: Fri, 05 Jun 2009 11:30:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Cahall, Glenn" References: <4A286319.4010902@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2009 15:30:26.0502 (UTC) FILETIME=[8CDEAE60:01C9E5F2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2893; t=1244215826; x=1245079826; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Reuse=20of=20Sip=20Call-Id= 20question.. |Sender:=20 |To:=20=22Cahall,=20Glenn=22=20; bh=39NLGb9W5eoWPpCKsnOAPXQrZ8FAsuk2IuDct0L+Od8=; b=FmGogMvY6hM2tBKK8Pw/10usTEVvA/QzAKXrtdyjgeSTAHtnaEuZfatdTd jH3N4Dxo/LkmIY9dhP95T2dmk4xpdzYPinaFuzwBKn19Eur5NGG8O13sPKiO uUK16vWQv7; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 15:30:27 -0000 Cahall, Glenn wrote: > Paul, > > Thanks for the response. > > Once I read your response, I felt that I needed to explain the situation in more detail. > > Customer is sending us an INVITE, our response is a 486 BUSY. This exact scenario (all with same TNs) repeats itself 100+ times over the next 90 seconds or so. All 100+ INVITEs contain the same Call-Id. However, tag value in the From field is different. > So....now that you know more about the situation....is this in violation of the RFC? Well... That case is arguable. I think it can be viewed as retried attempts to establish the same call. And on that basis, as long as they change the from-tag, I don't think I would call this use a violation. But its a gray area - you may get other opinions. (Lets wait and see. Surely Dale will have an opinion!) > Also, during our discussions on the topic, we argued whether or not Call-Id could be reused. In short, as stated before, even if the initial call was successful, they believed that as soon as that call was completed, they were free to use the exact same Call-Id on the very next call. On that point I don't think they have a leg to stand on. Thanks, Paul > Thanks for your input, > Glenn > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, June 04, 2009 6:13 PM > To: Cahall, Glenn > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Reuse of Sip Call-Id question.. > > > > Cahall, Glenn wrote: > >> We have customer UAs that are reusing the same Sip Call-Id for multiple >> call attempts into our network. >> >> After reviewing the Sip RFC 3261, both myself and my team concluded that >> this was a clear violation of the spec. based >> on the following verbiage... > ... >> However, some voice engineers are stating that the definition of >> "globally unique over time and space" means only during the >> context of a given call. Therefore, once this context is over....Sip >> Call-Id can in fact be reused in the very next context. > > :-) > > I would have thought that "globally unique over time and space" was > pretty clear. I don't know how you can get from there to: "only during > the context of a given call". > > In fact, "only during the context of a given call" is the *exception*, > during which the same callid *may* be reused. Specifically, if you make > several different INVITE attempts in pursuit of the same "call" then > they may have the same callid, but must be distinguished by different > from-tags. (This would typically come up if an initial request resulted > in a 3xx response, and the UAC is recursing on the Contacts in the 3xx > in an attempt to complete the call.) > > These guys have no legs to stand on, if you are accurately describing > the situation. > > Thanks, > Paul > From attila.sipos@vegastream.com Fri Jun 5 08:34:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0850C3A68BF for ; Fri, 5 Jun 2009 08:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5UgOLJLdhxW for ; Fri, 5 Jun 2009 08:34:50 -0700 (PDT) Received: from cluster-d.mailcontrol.com (cluster-d.mailcontrol.com [85.115.60.190]) by core3.amsl.com (Postfix) with ESMTP id D31023A6808 for ; Fri, 5 Jun 2009 08:34:49 -0700 (PDT) Received: from rly49d.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly49d.srv.mailcontrol.com (MailControl) with ESMTP id n55FYXrA003166 for ; Fri, 5 Jun 2009 16:34:50 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rly49d.srv.mailcontrol.com (MailControl) id n55FXs4n031675 for ; Fri, 5 Jun 2009 16:33:54 +0100 Received: from exsmtp04.nasstar-t1.net (exsmtp04.nasstar-t1.net [89.28.233.151]) by rly49d-eth0.srv.mailcontrol.com (envelope-sender ) (MIMEDefang) with ESMTP id n55FXslw031635; Fri, 05 Jun 2009 16:33:54 +0100 (BST) Received: from EXVS02.nasstar-t1.net ([10.2.10.104]) by exsmtp04.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Jun 2009 16:34:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Jun 2009 16:33:53 +0100 Message-ID: <680808427CF931459462C3D78CB5EC6005EAC47A@EXVS02.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Reuse of Sip Call-Id question.. Thread-Index: AcnlcmynRGF0FikKT72CP6C/6pr0SgAfMACgAADAdPAAABY88A== From: "Attila Sipos" To: "Cahall, Glenn" , "Paul Kyzivat" X-OriginalArrivalTime: 05 Jun 2009 15:34:39.0769 (UTC) FILETIME=[23D42890:01C9E5F3] X-Scanned-By: MailControl A-09-00-10 (www.mailcontrol.com) on 10.68.1.159 Cc: sipcore@ietf.org Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 15:34:51 -0000 >>is this in violation of the RFC? Yes, it's a violation. If a new call is starting, a new call-ID must be used. RFC3261 is very clear on this... Call-ID contains a globally unique identifier for this call, generated by the combination of a random string and the softphone's host name or IP address. And... In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior.=20 Each new request after the 486 is outside of any dialog. (And there is nothing method-specific here which allows your described behaviour) Regards, Attila =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Cahall, Glenn Sent: 05 June 2009 16:18 To: Paul Kyzivat Cc: sipcore@ietf.org Subject: Re: [sipcore] Reuse of Sip Call-Id question.. Paul, Thanks for the response. Once I read your response, I felt that I needed to explain the situation in more detail. Customer is sending us an INVITE, our response is a 486 BUSY. This exact scenario (all with same TNs) repeats itself 100+ times over the next 90 seconds or so. All 100+ INVITEs contain the same Call-Id. However, tag value in the From field is different. So....now that you know more about the situation....is this in violation of the RFC? Also, during our discussions on the topic, we argued whether or not Call-Id could be reused. In short, as stated before, even if the initial call was successful, they believed that as soon as that call was completed, they were free to use the exact same Call-Id on the very next call. Thanks for your input, Glenn -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Thursday, June 04, 2009 6:13 PM To: Cahall, Glenn Cc: sipcore@ietf.org Subject: Re: [sipcore] Reuse of Sip Call-Id question.. Cahall, Glenn wrote: > We have customer UAs that are reusing the same Sip Call-Id for=20 > multiple call attempts into our network. >=20 > After reviewing the Sip RFC 3261, both myself and my team concluded=20 > that this was a clear violation of the spec. based on the following=20 > verbiage... ... > However, some voice engineers are stating that the definition of=20 > "globally unique over time and space" means only during the context=20 > of a given call. Therefore, once this context is over....Sip Call-Id=20 > can in fact be reused in the very next context. :-) I would have thought that "globally unique over time and space" was pretty clear. I don't know how you can get from there to: "only during the context of a given call". In fact, "only during the context of a given call" is the *exception*, during which the same callid *may* be reused. Specifically, if you make several different INVITE attempts in pursuit of the same "call" then they may have the same callid, but must be distinguished by different from-tags. (This would typically come up if an initial request resulted in a 3xx response, and the UAC is recursing on the Contacts in the 3xx in an attempt to complete the call.) These guys have no legs to stand on, if you are accurately describing the situation. Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From attila.sipos@vegastream.com Fri Jun 5 08:42:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5E5428C0E9 for ; Fri, 5 Jun 2009 08:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEOAkWszU3d1 for ; Fri, 5 Jun 2009 08:42:33 -0700 (PDT) Received: from cluster-d.mailcontrol.com (cluster-d.mailcontrol.com [85.115.60.190]) by core3.amsl.com (Postfix) with ESMTP id 7FD0E3A682D for ; Fri, 5 Jun 2009 08:42:33 -0700 (PDT) Received: from rly25d.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly25d.srv.mailcontrol.com (MailControl) with ESMTP id n55FgVC0023770 for ; Fri, 5 Jun 2009 16:42:35 +0100 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by rly25d.srv.mailcontrol.com (MailControl) id n55Ffhon017882 for ; Fri, 5 Jun 2009 16:41:43 +0100 Received: from exsmtp02.nasstar-t1.net (exsmtp02.nasstar-t1.net [89.28.233.152]) by rly25d-eth0.srv.mailcontrol.com (envelope-sender ) (MIMEDefang) with ESMTP id n55FfZ3w015691; Fri, 05 Jun 2009 16:41:42 +0100 (BST) Received: from EXVS02.nasstar-t1.net ([10.2.10.104]) by exsmtp02.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jun 2009 16:42:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Jun 2009 16:41:27 +0100 Message-ID: <680808427CF931459462C3D78CB5EC6005EAC48B@EXVS02.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Reuse of Sip Call-Id question.. Thread-Index: AcnlcmynRGF0FikKT72CP6C/6pr0SgAfMACgAADAdPAAABY88AAAMTew From: "Attila Sipos" To: "Attila Sipos" , "Cahall, Glenn" , "Paul Kyzivat" X-OriginalArrivalTime: 05 Jun 2009 15:42:15.0694 (UTC) FILETIME=[3394CAE0:01C9E5F4] X-Scanned-By: MailControl A-09-00-10 (www.mailcontrol.com) on 10.68.1.135 Cc: sipcore@ietf.org Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 15:42:35 -0000 After seeing Paul's answer, I agree that it could be argued that all the INVITEs after the 486 responses are different attempts of the same call. I think their behaviour might work in some cases but I suspect interop success will be lower than if they modified their behaviour to use a new call-ID each time. As for re-using the call-ID for different calls... definitely NO. =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Attila Sipos Sent: 05 June 2009 16:34 To: Cahall, Glenn; Paul Kyzivat Cc: sipcore@ietf.org Subject: Re: [sipcore] Reuse of Sip Call-Id question.. >>is this in violation of the RFC? Yes, it's a violation. If a new call is starting, a new call-ID must be used. RFC3261 is very clear on this... Call-ID contains a globally unique identifier for this call, generated by the combination of a random string and the softphone's host name or IP address. And... In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior.=20 Each new request after the 486 is outside of any dialog. (And there is nothing method-specific here which allows your described behaviour) Regards, Attila =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Cahall, Glenn Sent: 05 June 2009 16:18 To: Paul Kyzivat Cc: sipcore@ietf.org Subject: Re: [sipcore] Reuse of Sip Call-Id question.. Paul, Thanks for the response. Once I read your response, I felt that I needed to explain the situation in more detail. Customer is sending us an INVITE, our response is a 486 BUSY. This exact scenario (all with same TNs) repeats itself 100+ times over the next 90 seconds or so. All 100+ INVITEs contain the same Call-Id. However, tag value in the From field is different. So....now that you know more about the situation....is this in violation of the RFC? Also, during our discussions on the topic, we argued whether or not Call-Id could be reused. In short, as stated before, even if the initial call was successful, they believed that as soon as that call was completed, they were free to use the exact same Call-Id on the very next call. Thanks for your input, Glenn -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Thursday, June 04, 2009 6:13 PM To: Cahall, Glenn Cc: sipcore@ietf.org Subject: Re: [sipcore] Reuse of Sip Call-Id question.. Cahall, Glenn wrote: > We have customer UAs that are reusing the same Sip Call-Id for=20 > multiple call attempts into our network. >=20 > After reviewing the Sip RFC 3261, both myself and my team concluded=20 > that this was a clear violation of the spec. based on the following=20 > verbiage... ... > However, some voice engineers are stating that the definition of=20 > "globally unique over time and space" means only during the context=20 > of a given call. Therefore, once this context is over....Sip Call-Id=20 > can in fact be reused in the very next context. :-) I would have thought that "globally unique over time and space" was pretty clear. I don't know how you can get from there to: "only during the context of a given call". In fact, "only during the context of a given call" is the *exception*, during which the same callid *may* be reused. Specifically, if you make several different INVITE attempts in pursuit of the same "call" then they may have the same callid, but must be distinguished by different from-tags. (This would typically come up if an initial request resulted in a 3xx response, and the UAC is recursing on the Contacts in the 3xx in an attempt to complete the call.) These guys have no legs to stand on, if you are accurately describing the situation. Thanks, Paul _______________________________________________ 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 bcampen@estacado.net Fri Jun 5 08:43:15 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F7C63A682D for ; Fri, 5 Jun 2009 08:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpRXsoYwFq4t for ; Fri, 5 Jun 2009 08:43:14 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 73AF728C0F4 for ; Fri, 5 Jun 2009 08:43:13 -0700 (PDT) Received: from dn3-233.estacado.net (dn3-233.estacado.net [172.16.3.233]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n55FhCwH074238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Jun 2009 10:43:12 -0500 (CDT) (envelope-from bcampen@estacado.net) Message-Id: From: Byron Campen To: Paul Kyzivat In-Reply-To: <4A293A10.2050802@cisco.com> Content-Type: multipart/signed; boundary=Apple-Mail-43--378580358; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 5 Jun 2009 10:43:08 -0500 References: <4A286319.4010902@cisco.com> <4A293A10.2050802@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: "Cahall, Glenn" , "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 15:43:15 -0000 --Apple-Mail-43--378580358 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jun 5, 2009, at 10:30 AM, Paul Kyzivat wrote: > > > Cahall, Glenn wrote: >> Paul, >> Thanks for the response. >> Once I read your response, I felt that I needed to explain the >> situation in more detail. >> Customer is sending us an INVITE, our response is a 486 BUSY. This >> exact scenario (all with same TNs) repeats itself 100+ times over >> the next 90 seconds or so. All 100+ INVITEs contain the same Call- >> Id. However, tag value in the From field is different. > >> So....now that you know more about the situation....is this in >> violation of the RFC? > > Well... > > That case is arguable. I think it can be viewed as retried attempts > to establish the same call. And on that basis, as long as they > change the from-tag, I don't think I would call this use a violation. > But its a gray area - you may get other opinions. > (Lets wait and see. Surely Dale will have an opinion!) > Erm, I think that _not_ reusing the tags would make this a violation. If the Call-Id and tags were the same, this would appear identical to a proxy forking sequentially (unless something was peeking into the Via stack), so forbidding a UA to do it doesn't make a whole lot of sense. >> Also, during our discussions on the topic, we argued whether or not >> Call-Id could be reused. In short, as stated before, even if the >> initial call was successful, they believed that as soon as that >> call was completed, they were free to use the exact same Call-Id on >> the very next call. > > On that point I don't think they have a leg to stand on. > Agreed. Best regards, Byron Campen --Apple-Mail-43--378580358 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGZDCCAx0w ggKGoAMCAQICEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDkyMzA0MzgwNFoXDTA5MDkyMzA0Mzgw NFowazEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQxIzAhBgkqhkiG9w0BCQEWFGRvY2ZhcmFkYXlAZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIGiyvzQgsqDjR3TiFTO4nkc/VRo/eX6xKu ky4CR2QtnIPEWhNLbU5UgXdGzU3YWx/cRj5alT0auKVQ/BnjCbf3bFSzP5mIfV6KlJV89dpxKQQA 3FaDYxE3whiRPIjQh3nmqxSacBTLohlt/g8MlFyiHoNs3XcH83M3QMjMxU8pD7SgXUDaXdtqC8vV +7g3rzPmlONdJ+4vac159wuZe37WVTsFI4sYL3p/KvqT1NZhmn1cmOVWKfCVAdGLk8VEUZtWuSeM NU5CLnFvenxaSPkDeVR5h0qDpw4DQyHfWXQuKvRs1WgVeHASz87EPgncyp90yiByetvE0WIBGKiz 0QIDAQABo0cwRTA1BgNVHREELjAsgRRiY2FtcGVuQGVzdGFjYWRvLm5ldIEUZG9jZmFyYWRheUBn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQANmDZo4t+1SrO9nb8KfjN4 QtlV1gzaAa2jEsAZ369PBXdsxVz32a1JIa1KudXFfMMxtF1NRDJ0Z3ib/qq+L8B28IpkYgRWtRr+ WWm6LzJ6rm1Q85cC0VSqoIRr+NoRZjaBdqWbJC4QsPnwVSXN9jLMLkFkjcxVDSxQtEx6v1PF9zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUP SAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0Eu Y3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2f Ni/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH 1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQW7SrCyoCwnsms5MfcqmjmzAJBgUr DgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2 MDUxNTQzMDhaMCMGCSqGSIb3DQEJBDEWBBQqVKjzp3FKUPHxm5TTcVIz6j3X7zCBhQYJKwYBBAGC NxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsq AsJ7JrOTH3Kpo5swgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEBBQAEggEAeb4l giPW22bzEyCpzi/TfDbvljClh8ZI9+3g6AhLvCKnBcJ8vq8Nx1ErMdEEf74QyPS8pfUtT568wdpT 0i6vO01hneT3NGmlXgm3QSw5BbEZV0ko2p/SYle+ezAcmdl414NDTqFaxA56ey7KgDgYawr66lqz SS6TzRg0cT0PO94kfMymzLDUPrvdWSm5Cx9g91jRdtSHHZ6Ad1mDAZ7uJNrUEdmN81L92e2IJ2Bb y3pXwF/znYD+IfY10nEP8RvgLBu6eZZTOl6Uewr+zklQ0j3qt2yOT4BE9S9OhX1sep81lCIt/fTq NtQ6A1O43Dc1CBAinDCjrf4rBwEL2X8GnwAAAAAAAA== --Apple-Mail-43--378580358-- From pkyzivat@cisco.com Fri Jun 5 09:30:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D103A6E12 for ; Fri, 5 Jun 2009 09:30:01 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZllfE9jC6Opd for ; Fri, 5 Jun 2009 09:30:00 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 63F513A697B for ; Fri, 5 Jun 2009 09:30:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,312,1241395200"; d="scan'208";a="46346237" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Jun 2009 16:30:03 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n55GU3sF025411; Fri, 5 Jun 2009 12:30:03 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n55GU3r1016691; Fri, 5 Jun 2009 16:30:03 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Jun 2009 12:30:03 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Jun 2009 12:30:02 -0400 Message-ID: <4A294809.7020507@cisco.com> Date: Fri, 05 Jun 2009 12:30:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Byron Campen References: <4A286319.4010902@cisco.com> <4A293A10.2050802@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2009 16:30:02.0526 (UTC) FILETIME=[E058A3E0:01C9E5FA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1842; t=1244219403; x=1245083403; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Reuse=20of=20Sip=20Call-Id= 20question.. |Sender:=20 |To:=20Byron=20Campen=20; bh=oPxLOk/9PBd29l/0gyilEJWW8qj9knhVTpIzo7/0QFs=; b=VsD58AXAGMfUL6pfiu9D4rIbdEKzRKGu8anEgwmFJoAt9mZHTeJslaKTi8 zNzVSEzknnSWnq8WXCmwYVkv12qEqKIC3dC44Rce0ZCDgNt5JRsihxR/ArsU /YWJUxLmu2; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "Cahall, Glenn" , "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 16:30:01 -0000 Byron Campen wrote: > > On Jun 5, 2009, at 10:30 AM, Paul Kyzivat wrote: > >> >> >> Cahall, Glenn wrote: >>> Paul, >>> Thanks for the response. >>> Once I read your response, I felt that I needed to explain the >>> situation in more detail. >>> Customer is sending us an INVITE, our response is a 486 BUSY. This >>> exact scenario (all with same TNs) repeats itself 100+ times over the >>> next 90 seconds or so. All 100+ INVITEs contain the same Call-Id. >>> However, tag value in the From field is different. >> >>> So....now that you know more about the situation....is this in >>> violation of the RFC? >> >> Well... >> >> That case is arguable. I think it can be viewed as retried attempts to >> establish the same call. And on that basis, as long as they change the >> from-tag, I don't think I would call this use a violation. >> But its a gray area - you may get other opinions. >> (Lets wait and see. Surely Dale will have an opinion!) >> > > Erm, I think that _not_ reusing the tags would make this a > violation. If the Call-Id and tags were the same, this would appear > identical to a proxy forking sequentially (unless something was peeking > into the Via stack), so forbidding a UA to do it doesn't make a whole > lot of sense. Hmm. Perhaps you are right about the tags. But going down that path then leads me to believe that this isn't valid either. When a proxy forks a request it is not allowed to send it to the same destination a 2nd time. And if trying a different target eventually loops back to the same destination, isn't it the callid + from-tag that results in the request being rejected rather than considered again? That tells me that its invalid regardless of the tag. So I take back my tentative approval in the 486 case. Paul From bcampen@estacado.net Fri Jun 5 09:35:46 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C05F3A6D7C for ; Fri, 5 Jun 2009 09:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9p26VQoqqbb for ; Fri, 5 Jun 2009 09:35:45 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 6063D3A6D2C for ; Fri, 5 Jun 2009 09:35:45 -0700 (PDT) Received: from dn3-233.estacado.net (dn3-233.estacado.net [172.16.3.233]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n55GZcdi085873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 5 Jun 2009 11:35:39 -0500 (CDT) (envelope-from bcampen@estacado.net) Message-Id: <55BBEC2D-28EE-4989-84BC-885FF5B1A226@estacado.net> From: Byron Campen To: Paul Kyzivat In-Reply-To: <4A294809.7020507@cisco.com> Content-Type: multipart/signed; boundary=Apple-Mail-44--375433909; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 5 Jun 2009 11:35:33 -0500 References: <4A286319.4010902@cisco.com> <4A293A10.2050802@cisco.com> <4A294809.7020507@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: "Cahall, Glenn" , "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 16:35:46 -0000 --Apple-Mail-44--375433909 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > > > Byron Campen wrote: >> On Jun 5, 2009, at 10:30 AM, Paul Kyzivat wrote: >>> >>> >>> Cahall, Glenn wrote: >>>> Paul, >>>> Thanks for the response. >>>> Once I read your response, I felt that I needed to explain the >>>> situation in more detail. >>>> Customer is sending us an INVITE, our response is a 486 BUSY. >>>> This exact scenario (all with same TNs) repeats itself 100+ times >>>> over the next 90 seconds or so. All 100+ INVITEs contain the >>>> same Call-Id. However, tag value in the From field is different. >>> >>>> So....now that you know more about the situation....is this in >>>> violation of the RFC? >>> >>> Well... >>> >>> That case is arguable. I think it can be viewed as retried >>> attempts to establish the same call. And on that basis, as long as >>> they change the from-tag, I don't think I would call this use a >>> violation. >>> But its a gray area - you may get other opinions. >>> (Lets wait and see. Surely Dale will have an opinion!) >>> >> Erm, I think that _not_ reusing the tags would make this a >> violation. If the Call-Id and tags were the same, this would appear >> identical to a proxy forking sequentially (unless something was >> peeking into the Via stack), so forbidding a UA to do it doesn't >> make a whole lot of sense. > > Hmm. Perhaps you are right about the tags. > > But going down that path then leads me to believe that this isn't > valid either. > > When a proxy forks a request it is not allowed to send it to the > same destination a 2nd time. And if trying a different target > eventually loops back to the same destination, isn't it the callid + > from-tag that results in the request being rejected rather than > considered again? > Depends on the destination, really. Proxies are supposed to only send to a given destination with the same routing information once though. Best regards, Byron Campen --Apple-Mail-44--375433909 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGZDCCAx0w ggKGoAMCAQICEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDkyMzA0MzgwNFoXDTA5MDkyMzA0Mzgw NFowazEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQxIzAhBgkqhkiG9w0BCQEWFGRvY2ZhcmFkYXlAZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIGiyvzQgsqDjR3TiFTO4nkc/VRo/eX6xKu ky4CR2QtnIPEWhNLbU5UgXdGzU3YWx/cRj5alT0auKVQ/BnjCbf3bFSzP5mIfV6KlJV89dpxKQQA 3FaDYxE3whiRPIjQh3nmqxSacBTLohlt/g8MlFyiHoNs3XcH83M3QMjMxU8pD7SgXUDaXdtqC8vV +7g3rzPmlONdJ+4vac159wuZe37WVTsFI4sYL3p/KvqT1NZhmn1cmOVWKfCVAdGLk8VEUZtWuSeM NU5CLnFvenxaSPkDeVR5h0qDpw4DQyHfWXQuKvRs1WgVeHASz87EPgncyp90yiByetvE0WIBGKiz 0QIDAQABo0cwRTA1BgNVHREELjAsgRRiY2FtcGVuQGVzdGFjYWRvLm5ldIEUZG9jZmFyYWRheUBn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQANmDZo4t+1SrO9nb8KfjN4 QtlV1gzaAa2jEsAZ369PBXdsxVz32a1JIa1KudXFfMMxtF1NRDJ0Z3ib/qq+L8B28IpkYgRWtRr+ WWm6LzJ6rm1Q85cC0VSqoIRr+NoRZjaBdqWbJC4QsPnwVSXN9jLMLkFkjcxVDSxQtEx6v1PF9zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUP SAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0Eu Y3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2f Ni/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH 1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQW7SrCyoCwnsms5MfcqmjmzAJBgUr DgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2 MDUxNjM1MzRaMCMGCSqGSIb3DQEJBDEWBBQL/YFW/BEDU7F7/c4X4/Li3DIq7TCBhQYJKwYBBAGC NxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsq AsJ7JrOTH3Kpo5swgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEBBQAEggEAR5/o Zk6biO37XQPFUppVcvFhQfL1dCultd21zTWxOHZlFZAOWbD7ID++qpsHOugmHx5ftGwcH7o7w9PJ 7ZsXU8OhEnVtf6dn+NZQ0OZgX9R39+sRvcHxN2m0hqW4GMKQAfDLeSzc6yye/kx2UWU/RnfSUZwb BgeCPIYXkugiekjpfx5PnMCPfi1pJtqkDCi0WTijJrbSLf8pIq6UQ+r82WxU0/c+S9UNWciWnYBN bkz8ZpI3NaKwK20jsXLb+v3Pc8ym2hHigbebP+7QxY2krh0yDGLLNUQqBa3ydcVeIzK2BC80yH7K 907qRyT5njJKE9JwI/K4sWBR2QH6mcdWoQAAAAAAAA== --Apple-Mail-44--375433909-- From Glenn.Cahall@Level3.com Fri Jun 5 09:37:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A8213A6E18 for ; Fri, 5 Jun 2009 09:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYrVBy8QNOM4 for ; Fri, 5 Jun 2009 09:37:31 -0700 (PDT) Received: from mail200.messagelabs.com (mail200.messagelabs.com [216.82.254.195]) by core3.amsl.com (Postfix) with SMTP id 803303A6D2C for ; Fri, 5 Jun 2009 09:37:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Glenn.Cahall@Level3.com X-Msg-Ref: server-5.tower-200.messagelabs.com!1244219854!38607550!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [209.245.18.107] Received: (qmail 20981 invoked from network); 5 Jun 2009 16:37:34 -0000 Received: from unknown.level3.net (HELO f10cc8-10) (209.245.18.107) by server-5.tower-200.messagelabs.com with SMTP; 5 Jun 2009 16:37:34 -0000 Received: from idc1embx0003.corp.global.level3.com (idc1embx0003.corp.global.level3.com [10.1.9.78]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by f10cc8-10 (Postfix) with ESMTP id 40ADD33BA; Fri, 5 Jun 2009 16:37:34 +0000 (GMT) Received: from idc1embx0003.corp.global.level3.com ([10.1.9.78]) by idc1embx0003.corp.global.level3.com ([10.1.9.78]) with mapi; Fri, 5 Jun 2009 10:37:33 -0600 From: "Cahall, Glenn" To: Paul Kyzivat , Byron Campen Date: Fri, 5 Jun 2009 10:37:32 -0600 Thread-Topic: [sipcore] Reuse of Sip Call-Id question.. Thread-Index: Acnl+uG8KE3MtFeMRgulBxjdFbj4/gAAL/yg Message-ID: References: <4A286319.4010902@cisco.com> <4A293A10.2050802@cisco.com> <4A294809.7020507@cisco.com> In-Reply-To: <4A294809.7020507@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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 16:37:32 -0000 Just so I got it straight....so, are you now saying that repeated INVITEs w= ith 486 responses using same Call-Id is ok...or a violation? -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Friday, June 05, 2009 10:30 AM To: Byron Campen Cc: Cahall, Glenn; sipcore@ietf.org Subject: Re: [sipcore] Reuse of Sip Call-Id question.. Byron Campen wrote: >=20 > On Jun 5, 2009, at 10:30 AM, Paul Kyzivat wrote: >=20 >> >> >> Cahall, Glenn wrote: >>> Paul, >>> Thanks for the response. >>> Once I read your response, I felt that I needed to explain the=20 >>> situation in more detail. >>> Customer is sending us an INVITE, our response is a 486 BUSY. This=20 >>> exact scenario (all with same TNs) repeats itself 100+ times over the=20 >>> next 90 seconds or so. All 100+ INVITEs contain the same Call-Id. =20 >>> However, tag value in the From field is different. >> >>> So....now that you know more about the situation....is this in=20 >>> violation of the RFC? >> >> Well... >> >> That case is arguable. I think it can be viewed as retried attempts to=20 >> establish the same call. And on that basis, as long as they change the=20 >> from-tag, I don't think I would call this use a violation. >> But its a gray area - you may get other opinions. >> (Lets wait and see. Surely Dale will have an opinion!) >> >=20 > Erm, I think that _not_ reusing the tags would make this a=20 > violation. If the Call-Id and tags were the same, this would appear=20 > identical to a proxy forking sequentially (unless something was peeking=20 > into the Via stack), so forbidding a UA to do it doesn't make a whole=20 > lot of sense. Hmm. Perhaps you are right about the tags. But going down that path then leads me to believe that this isn't valid=20 either. When a proxy forks a request it is not allowed to send it to the same=20 destination a 2nd time. And if trying a different target eventually=20 loops back to the same destination, isn't it the callid + from-tag that=20 results in the request being rejected rather than considered again? That tells me that its invalid regardless of the tag. So I take back my tentative approval in the 486 case. Paul From dworley@nortel.com Fri Jun 5 09:59:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D65FD3A68F2 for ; Fri, 5 Jun 2009 09:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.932 X-Spam-Level: X-Spam-Status: No, score=-6.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVmK-JYbRxSu for ; Fri, 5 Jun 2009 09:59:38 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id D31C43A68C9 for ; Fri, 5 Jun 2009 09:59:37 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n55GxZR24249; Fri, 5 Jun 2009 16:59:36 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Jun 2009 12:59:33 -0400 From: "Dale Worley" To: "Cahall, Glenn" In-Reply-To: <4A293A10.2050802@cisco.com> References: <4A286319.4010902@cisco.com> <4A293A10.2050802@cisco.com> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 05 Jun 2009 12:59:33 -0400 Message-Id: <1244221173.3786.35.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2009 16:59:33.0517 (UTC) FILETIME=[FFF06BD0:01C9E5FE] Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 16:59:38 -0000 On Fri, 2009-06-05 at 11:30 -0400, Paul Kyzivat wrote: > (Lets wait and see. Surely Dale will have an opinion!) Of course! To confirm what everyone else is saying: A UA may "retry" an INVITE that received a failure response by incrementing the CSeq, but keeping the Call-Id and from-tag. But if an INVITE is for a logically different call, it must have a different Call-Id, and the phone must have a method for constructing Call-Id's that makes it statistically impossible to duplicate the Call-Id's generated by any other element. It is clearly understood that if a call is *successful* its Call-Id may not be reused. Cahall, Glenn wrote: > Customer is sending us an INVITE, our response is a 486 BUSY. This > exact scenario (all with same TNs) repeats itself 100+ times over the > next 90 seconds or so. All 100+ INVITEs contain the same Call-Id. > However, tag value in the From field is different. In regard to the from-tag in retried requests, I'm not sure if there is an explicit statement that the from-tag must be the same, but that is the universal understanding. None of this discussion addresses the oddest aspect of your scenario: Having gotten a "Busy Here" response, why is the UA automatically retrying the request in less than 1 second? Does the UA think that the callee is likely to have hung up in the last 0.9 second? I suspect the UA is retrying when it sees any 4xx response, and is not restricting itself to responses that it can remedy. Dale From pkyzivat@cisco.com Fri Jun 5 10:00:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31E6F28C10D for ; Fri, 5 Jun 2009 10:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsYFVFctSer6 for ; Fri, 5 Jun 2009 10:00:29 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 185913A6C00 for ; Fri, 5 Jun 2009 10:00:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,312,1241395200"; d="scan'208";a="46352013" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Jun 2009 17:00:31 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n55H0Vqv017267; Fri, 5 Jun 2009 13:00:31 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n55H0Vuj006709; Fri, 5 Jun 2009 17:00:31 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Jun 2009 13:00:29 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Jun 2009 13:00:29 -0400 Message-ID: <4A294F2B.8020908@cisco.com> Date: Fri, 05 Jun 2009 13:00:27 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Cahall, Glenn" References: <4A286319.4010902@cisco.com> <4A293A10.2050802@cisco.com> <4A294809.7020507@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2009 17:00:29.0233 (UTC) FILETIME=[21260210:01C9E5FF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2314; t=1244221231; x=1245085231; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Reuse=20of=20Sip=20Call-Id= 20question.. |Sender:=20 |To:=20=22Cahall,=20Glenn=22=20; bh=FW+ZB35VI1Tu2cITVpZWLXo01qtAfjstEYPvZKU+G3M=; b=ul0I2gy6p96Jax8V2Tjak8sU0eNQNc9C36raL1tUcbEOxgYM40ShGSNE4r Gtwqmv868W08lSQ/XlKRAhDOqDHlkS2AXS1J4gahJSN3VKwigSzRg0adU17u 8EUcZ9CS5C; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "sipcore@ietf.org" , Byron Campen Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 17:00:30 -0000 violation Cahall, Glenn wrote: > Just so I got it straight....so, are you now saying that repeated INVITEs with 486 responses using same Call-Id is ok...or a violation? > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, June 05, 2009 10:30 AM > To: Byron Campen > Cc: Cahall, Glenn; sipcore@ietf.org > Subject: Re: [sipcore] Reuse of Sip Call-Id question.. > > > > Byron Campen wrote: >> On Jun 5, 2009, at 10:30 AM, Paul Kyzivat wrote: >> >>> >>> Cahall, Glenn wrote: >>>> Paul, >>>> Thanks for the response. >>>> Once I read your response, I felt that I needed to explain the >>>> situation in more detail. >>>> Customer is sending us an INVITE, our response is a 486 BUSY. This >>>> exact scenario (all with same TNs) repeats itself 100+ times over the >>>> next 90 seconds or so. All 100+ INVITEs contain the same Call-Id. >>>> However, tag value in the From field is different. >>>> So....now that you know more about the situation....is this in >>>> violation of the RFC? >>> Well... >>> >>> That case is arguable. I think it can be viewed as retried attempts to >>> establish the same call. And on that basis, as long as they change the >>> from-tag, I don't think I would call this use a violation. >>> But its a gray area - you may get other opinions. >>> (Lets wait and see. Surely Dale will have an opinion!) >>> >> Erm, I think that _not_ reusing the tags would make this a >> violation. If the Call-Id and tags were the same, this would appear >> identical to a proxy forking sequentially (unless something was peeking >> into the Via stack), so forbidding a UA to do it doesn't make a whole >> lot of sense. > > Hmm. Perhaps you are right about the tags. > > But going down that path then leads me to believe that this isn't valid > either. > > When a proxy forks a request it is not allowed to send it to the same > destination a 2nd time. And if trying a different target eventually > loops back to the same destination, isn't it the callid + from-tag that > results in the request being rejected rather than considered again? > > That tells me that its invalid regardless of the tag. > > So I take back my tentative approval in the 486 case. > > Paul > From BPenfield@acmepacket.com Fri Jun 5 10:05:03 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2D463A68F2 for ; Fri, 5 Jun 2009 10:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXdEyCTcnIDm for ; Fri, 5 Jun 2009 10:05:03 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id CA4563A68C9 for ; Fri, 5 Jun 2009 10:05:02 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 5 Jun 2009 13:05:04 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 5 Jun 2009 13:05:04 -0400 From: Bob Penfield To: "Cahall, Glenn" , Paul Kyzivat , Byron Campen Date: Fri, 5 Jun 2009 13:05:03 -0400 Thread-Topic: [sipcore] Reuse of Sip Call-Id question.. Thread-Index: Acnl+uG8KE3MtFeMRgulBxjdFbj4/gAAL/ygAAC5LHA= Message-ID: References: <4A286319.4010902@cisco.com> <4A293A10.2050802@cisco.com> <4A294809.7020507@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" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 17:05:04 -0000 Section 8.1.3.5 talks about retrying requests that get certain 4xx response= s. For 401, 413, 415, 416, and 420, it says: In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous. Then it goes on to say: With other 4xx responses, including those yet to be defined, a retry may or may not be possible depending on the method and the use case. I would say that retrying a request that got a 486 with the same Call-ID, F= rom & To would only be appropriate if a different Request-URI was used to a= ttempt to contact the same user. It is not appropriate to use the same Call= -ID/From/To for a "redial" function that simply retries the same request wi= thout any modification (other than CSeq). cheers, (-:bob -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Cahall, Glenn Sent: Friday, June 05, 2009 12:38 PM To: Paul Kyzivat; Byron Campen Cc: sipcore@ietf.org Subject: Re: [sipcore] Reuse of Sip Call-Id question.. Just so I got it straight....so, are you now saying that repeated INVITEs w= ith 486 responses using same Call-Id is ok...or a violation? -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Friday, June 05, 2009 10:30 AM To: Byron Campen Cc: Cahall, Glenn; sipcore@ietf.org Subject: Re: [sipcore] Reuse of Sip Call-Id question.. Byron Campen wrote: >=20 > On Jun 5, 2009, at 10:30 AM, Paul Kyzivat wrote: >=20 >> >> >> Cahall, Glenn wrote: >>> Paul, >>> Thanks for the response. >>> Once I read your response, I felt that I needed to explain the=20 >>> situation in more detail. >>> Customer is sending us an INVITE, our response is a 486 BUSY. This=20 >>> exact scenario (all with same TNs) repeats itself 100+ times over the=20 >>> next 90 seconds or so. All 100+ INVITEs contain the same Call-Id. =20 >>> However, tag value in the From field is different. >> >>> So....now that you know more about the situation....is this in=20 >>> violation of the RFC? >> >> Well... >> >> That case is arguable. I think it can be viewed as retried attempts to=20 >> establish the same call. And on that basis, as long as they change the=20 >> from-tag, I don't think I would call this use a violation. >> But its a gray area - you may get other opinions. >> (Lets wait and see. Surely Dale will have an opinion!) >> >=20 > Erm, I think that _not_ reusing the tags would make this a=20 > violation. If the Call-Id and tags were the same, this would appear=20 > identical to a proxy forking sequentially (unless something was peeking=20 > into the Via stack), so forbidding a UA to do it doesn't make a whole=20 > lot of sense. Hmm. Perhaps you are right about the tags. But going down that path then leads me to believe that this isn't valid=20 either. When a proxy forks a request it is not allowed to send it to the same=20 destination a 2nd time. And if trying a different target eventually=20 loops back to the same destination, isn't it the callid + from-tag that=20 results in the request being rejected rather than considered again? That tells me that its invalid regardless of the tag. So I take back my tentative approval in the 486 case. Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Fri Jun 5 10:05:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 366AB3A6DB8 for ; Fri, 5 Jun 2009 10:05:57 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvR7y-DsdUY4 for ; Fri, 5 Jun 2009 10:05:56 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 4A28D3A68C9 for ; Fri, 5 Jun 2009 10:05:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,312,1241395200"; d="scan'208";a="173112931" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 05 Jun 2009 17:05:59 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n55H5uxp022379; Fri, 5 Jun 2009 10:05:56 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n55H5nZD012857; Fri, 5 Jun 2009 17:05:56 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Jun 2009 13:05:56 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Jun 2009 13:05:55 -0400 Message-ID: <4A295073.40706@cisco.com> Date: Fri, 05 Jun 2009 13:05:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dale Worley References: <4A286319.4010902@cisco.com> <4A293A10.2050802@cisco.com> <1244221173.3786.35.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1244221173.3786.35.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2009 17:05:55.0793 (UTC) FILETIME=[E3CB1C10:01C9E5FF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1803; t=1244221559; x=1245085559; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Reuse=20of=20Sip=20Call-Id= 20question.. |Sender:=20; bh=26IQTBsEnjiH8grK3MHJM2pWBt3crP795GcriSL1M8E=; b=gn22eUGrW2SF/g5k4fchMQ4qy2u4YRl1gVWObVeYBPwqkpf2ebKH1rLwoo wfTbTBo9GDY8+ABtf3iUAjPysUBZ3ic6l1Ao4fVnpGYhEUY3r++X3sEiDmGI xsEdNttlwu; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "Cahall, Glenn" , "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 17:05:57 -0000 Dale Worley wrote: > On Fri, 2009-06-05 at 11:30 -0400, Paul Kyzivat wrote: >> (Lets wait and see. Surely Dale will have an opinion!) > > Of course! > > To confirm what everyone else is saying: A UA may "retry" an INVITE > that received a failure response by incrementing the CSeq, but keeping > the Call-Id and from-tag. But if an INVITE is for a logically different > call, it must have a different Call-Id, and the phone must have a method > for constructing Call-Id's that makes it statistically impossible to > duplicate the Call-Id's generated by any other element. > > It is clearly understood that if a call is *successful* its Call-Id may > not be reused. > > Cahall, Glenn wrote: >> Customer is sending us an INVITE, our response is a 486 BUSY. This >> exact scenario (all with same TNs) repeats itself 100+ times over the >> next 90 seconds or so. All 100+ INVITEs contain the same Call-Id. >> However, tag value in the From field is different. > > In regard to the from-tag in retried requests, I'm not sure if there is > an explicit statement that the from-tag must be the same, but that is > the universal understanding. > > None of this discussion addresses the oddest aspect of your scenario: > Having gotten a "Busy Here" response, why is the UA automatically > retrying the request in less than 1 second? Does the UA think that the > callee is likely to have hung up in the last 0.9 second? I suspect the > UA is retrying when it sees any 4xx response, and is not restricting > itself to responses that it can remedy. In the absence of a call queuing mechanism, this is the way you get through to an address that is constantly busy with a series of calls. Maybe they are trying to get in to vote on American Idol. :-) Paul From dworley@nortel.com Fri Jun 5 13:03:07 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C33C33A6BFC for ; Fri, 5 Jun 2009 13:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.849 X-Spam-Level: X-Spam-Status: No, score=-6.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veXe2Xf2QGF1 for ; Fri, 5 Jun 2009 13:03:07 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id B260A3A6B95 for ; Fri, 5 Jun 2009 13:03:06 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n55K1Hd17700; Fri, 5 Jun 2009 20:01:18 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Jun 2009 16:02:31 -0400 From: "Dale Worley" To: Paul Kyzivat In-Reply-To: <4A282D39.2090401@cisco.com> References: <1240958114.18691.54.camel@victoria-pingtel-com.us.nortel.com> <4A1C4C45.90204@nostrum.com> <1244143850.3743.62.camel@victoria-pingtel-com.us.nortel.com> <4A282D39.2090401@cisco.com> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 05 Jun 2009 16:02:31 -0400 Message-Id: <1244232151.3786.70.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2009 20:02:31.0892 (UTC) FILETIME=[8F8F8140:01C9E618] Cc: SIPCORE Subject: Re: [sipcore] Comments on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 20:03:07 -0000 On Thu, 2009-06-04 at 16:23 -0400, Paul Kyzivat wrote: > After a (re)SUBSCRIBE, you will receive both a 200(SUBSCRIBE) and a > NOTIFY. There is no guarantee which will arrive first. Which one do you > believe for the expiration time? If it was a reSUBSCRIBE, the subscriber > doesn't even know if the NOTIFY was a result of the reSUBSCRIBE or was > sent previously. Perhaps saying that you can only extend, not reduce, > would help here. If the notifier can only extend subscriptions, then the subscriber can believe the furthest expiration that it has seen, and does not need to know the order in which the various messages were sent. > But the no-reduce rule has its own trouble. In particular my usual > source of exceptions to everything: 3pcc. The subscriber may think he is > continuing a single subscription. But a middle box may be moving a > subscription from one UAS to another. The new target may not be willing > to support such a long subscription, and so may have need to reduce it. That's an annoyingly realistic problem. > (Perhaps an answer to that would be to put the burden on the middle box > to "make it right" by managing different expiration times on the two > sides. But that can be difficult.) That would add a lot of complexity that is not now needed. > And then there is the general issue: practically speaking, can we ever > add new restrictions? Backward compatibility issues will require most > everyone to support cases where those restrictions aren't observed. I think that we can escape the general issue in this case. Partly, because current implementations rarely use the full range of allowed behavior, and partly because we can add some hacks what I have proposed to accommodate current behavior. But I need to think about this more... Dale From dean.willis@softarmor.com Fri Jun 5 17:13:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E8D53A6C0A for ; Fri, 5 Jun 2009 17:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZxvJAvkw+IH for ; Fri, 5 Jun 2009 17:13:31 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 57DBC3A6C6E for ; Fri, 5 Jun 2009 17:13:31 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n560DVQ2004133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 5 Jun 2009 19:13:33 -0500 Message-Id: <6B8A59AF-FB35-42E8-B3D7-EF6206C0A65D@softarmor.com> From: Dean Willis To: "Cahall, Glenn" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 5 Jun 2009 19:13:26 -0500 References: <4A286319.4010902@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 00:13:32 -0000 On Jun 5, 2009, at 10:18 AM, Cahall, Glenn wrote: > Paul, > > Thanks for the response. > > Once I read your response, I felt that I needed to explain the > situation in more detail. > > Customer is sending us an INVITE, our response is a 486 BUSY. This > exact scenario (all with same TNs) repeats itself 100+ times over > the next 90 seconds or so. All 100+ INVITEs contain the same Call- > Id. However, tag value in the From field is different. > > So....now that you know more about the situation....is this in > violation of the RFC? > > Also, during our discussions on the topic, we argued whether or not > Call-Id could be reused. In short, as stated before, even if the > initial call was successful, they believed that as soon as that call > was completed, they were free to use the exact same Call-Id on the > very next call. The From: tag SHOULD be invariant if the Call-ID is re-used in response to a 4xx, else the transaction won't match. And the CSeq SHOULD increase, since it is a new INVITE. This is specified in paragraph 6 of section 8.1.4.5 in RFC 3261. In practice, state matching fails if this isn't honored, so it really could have been specified as a MUST; that is, we should probably rewrite RFC 3261 to say something like: "The UAC MAY retry a transaction following certain 400-class responses, If the UAC retries such a transaction, it MUST retain the To, From, Call-ID and Request-URI of the original transaction, and MUST increment the CSeq. Failure to observe these two operational requirements is likely to result in proxies or the UAS not matching the retried transaction to any retained state from previous transactions, which could result in errors ranging from erroneous log entries to denial-of-service scenarios, and it is in extremely poor taste too." In other words, the tag should be the same, the CSeq should increment, and you spank the customer for being annoying. Failing that, how's the Retry-After: header field on your 486 populated? Perhaps you could crank it up to about 60 seconds, THEN spank them for being annoying it if they ignore it. -- Dean From dean.willis@softarmor.com Fri Jun 5 17:16:37 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879DE3A6A69 for ; Fri, 5 Jun 2009 17:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJcGZ-9NYcTq for ; Fri, 5 Jun 2009 17:16:36 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C9B773A68A2 for ; Fri, 5 Jun 2009 17:16:36 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n560GaU8004154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 5 Jun 2009 19:16:37 -0500 Message-Id: From: Dean Willis To: Dean Willis In-Reply-To: <6B8A59AF-FB35-42E8-B3D7-EF6206C0A65D@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 5 Jun 2009 19:16:30 -0500 References: <4A286319.4010902@cisco.com> <6B8A59AF-FB35-42E8-B3D7-EF6206C0A65D@softarmor.com> X-Mailer: Apple Mail (2.935.3) Cc: "Cahall, Glenn" , "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 00:16:37 -0000 On Jun 5, 2009, at 7:13 PM, Dean Willis wrote: > > > > The From: tag SHOULD be invariant if the Call-ID is re-used in > response to a 4xx, else the transaction won't match. And the CSeq > SHOULD increase, since it is a new INVITE. This is specified in > paragraph 6 of section 8.1.4.5 I meant 8.1.3.5, dangit! > in RFC 3261. In practice, state matching fails if this isn't > honored, so it really could have been specified as a MUST; that is, > we should probably rewrite RFC 3261 to So, we know HOW to retry a transaction. Now, the other question: Should the transaction be retried at all? The general consensus seems to be no, not unless a Retry-After was specified in the 4xx response and the request time period has elapsed. -- Dean From dworley@nortel.com Fri Jun 5 18:29:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 228283A69B8 for ; Fri, 5 Jun 2009 18:29:30 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJUCTgSSHQOf for ; Fri, 5 Jun 2009 18:29:29 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2DFBF3A687A for ; Fri, 5 Jun 2009 18:29:28 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n561TR807235; Sat, 6 Jun 2009 01:29:27 GMT Received: from [47.141.31.158] ([47.141.31.158]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Jun 2009 21:29:26 -0400 From: "Dale Worley" To: Dean Willis In-Reply-To: <6B8A59AF-FB35-42E8-B3D7-EF6206C0A65D@softarmor.com> References: <4A286319.4010902@cisco.com> <6B8A59AF-FB35-42E8-B3D7-EF6206C0A65D@softarmor.com> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 05 Jun 2009 21:29:26 -0400 Message-Id: <1244251766.4158.21.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jun 2009 01:29:26.0993 (UTC) FILETIME=[3B126410:01C9E646] Cc: "Cahall, Glenn" , "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 01:29:30 -0000 On Fri, 2009-06-05 at 19:13 -0500, Dean Willis wrote: > "The UAC MAY retry a transaction following certain 400-class > responses, If the UAC retries such a transaction, it MUST retain the > To, From, Call-ID and Request-URI of the original transaction, and > MUST increment the CSeq. Failure to observe these two operational > requirements is likely to result in proxies or the UAS not matching > the retried transaction to any retained state from previous > transactions, which could result in errors ranging from erroneous log > entries to denial-of-service scenarios, and it is in extremely poor > taste too." I think one can safely change the request-URI when retrying, and in some cases, one may need to to fix the problem. As far as I know, nobody uses the request-URI for any kind of transaction or dialog matching (and they surely should not). Dale From dean.willis@softarmor.com Sat Jun 6 11:33:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2292E3A6DA9 for ; Sat, 6 Jun 2009 11:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKTYUgiCJo-F for ; Sat, 6 Jun 2009 11:33:21 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 697153A6DA5 for ; Sat, 6 Jun 2009 11:33:21 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n56IXNqf009329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 6 Jun 2009 13:33:24 -0500 Message-Id: <8DCBAE37-E805-43CD-9805-576A1E69FC7F@softarmor.com> From: Dean Willis To: Dale Worley In-Reply-To: <1244251766.4158.21.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 6 Jun 2009 13:33:18 -0500 References: <4A286319.4010902@cisco.com> <6B8A59AF-FB35-42E8-B3D7-EF6206C0A65D@softarmor.com> <1244251766.4158.21.camel@victoria-pingtel-com.us.nortel.com> X-Mailer: Apple Mail (2.935.3) Cc: "Cahall, Glenn" , "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 18:33:22 -0000 On Jun 5, 2009, at 8:29 PM, Dale Worley wrote: > On Fri, 2009-06-05 at 19:13 -0500, Dean Willis wrote: >> "The UAC MAY retry a transaction following certain 400-class >> responses, If the UAC retries such a transaction, it MUST retain the >> To, From, Call-ID and Request-URI of the original transaction, and >> MUST increment the CSeq. Failure to observe these two operational >> requirements is likely to result in proxies or the UAS not matching >> the retried transaction to any retained state from previous >> transactions, which could result in errors ranging from erroneous log >> entries to denial-of-service scenarios, and it is in extremely poor >> taste too." > > I think one can safely change the request-URI when retrying, and in > some > cases, one may need to to fix the problem. As far as I know, nobody > uses the request-URI for any kind of transaction or dialog matching > (and > they surely should not). I'd argue it's a new transaction, not a retry, if the R-URI changes. -- Dean From BPenfield@acmepacket.com Sat Jun 6 12:19:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 340F93A6DA1 for ; Sat, 6 Jun 2009 12:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tCirS6uXVN0 for ; Sat, 6 Jun 2009 12:19:51 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 483633A6836 for ; Sat, 6 Jun 2009 12:19:51 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Sat, 6 Jun 2009 15:19:54 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 6 Jun 2009 15:19:54 -0400 From: Bob Penfield To: Dean Willis , Dale Worley Date: Sat, 6 Jun 2009 15:19:53 -0400 Thread-Topic: [sipcore] Reuse of Sip Call-Id question.. Thread-Index: Acnm1Va5YmRKMtJ1Tre7dnga4qvh0QABdGxw Message-ID: References: <4A286319.4010902@cisco.com> <6B8A59AF-FB35-42E8-B3D7-EF6206C0A65D@softarmor.com> <1244251766.4158.21.camel@victoria-pingtel-com.us.nortel.com> <8DCBAE37-E805-43CD-9805-576A1E69FC7F@softarmor.com> In-Reply-To: <8DCBAE37-E805-43CD-9805-576A1E69FC7F@softarmor.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: "Cahall, Glenn" , "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 19:19:52 -0000 =20 >-----Original Message----- >From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf= Of Dean Willis >Sent: Saturday, June 06, 2009 2:33 PM >To: Dale Worley >Cc: Cahall, Glenn; sipcore@ietf.org >Subject: Re: [sipcore] Reuse of Sip Call-Id question.. > > >On Jun 5, 2009, at 8:29 PM, Dale Worley wrote: > >> On Fri, 2009-06-05 at 19:13 -0500, Dean Willis wrote: >>> "The UAC MAY retry a transaction following certain 400-class >>> responses, If the UAC retries such a transaction, it MUST retain the >>> To, From, Call-ID and Request-URI of the original transaction, and >>> MUST increment the CSeq. Failure to observe these two operational >>> requirements is likely to result in proxies or the UAS not matching >>> the retried transaction to any retained state from previous >>> transactions, which could result in errors ranging from erroneous log >>> entries to denial-of-service scenarios, and it is in extremely poor >>> taste too." >> >> I think one can safely change the request-URI when retrying, and in =20 >> some >> cases, one may need to to fix the problem. As far as I know, nobody >> uses the request-URI for any kind of transaction or dialog matching =20 >> (and >> they surely should not). > >I'd argue it's a new transaction, not a retry, if the R-URI changes. In section 8.1.3.5 of 3261 it does give one case where the Request-URI woul= d change: If a 416 (Unsupported URI Scheme) response is received (Section 21.4.14), the Request-URI used a URI scheme not supported by the server. The client SHOULD retry the request, this time, using a SIP URI. And just to be picky, I think you meant "new session" rather than "new tran= saction". A retry is a new transaction :) > >-- >Dean > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From vkg@alcatel-lucent.com Sat Jun 6 21:17:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825AC3A6992 for ; Sat, 6 Jun 2009 21:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwQ6I2m-Dwf6 for ; Sat, 6 Jun 2009 21:17:33 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id DDF163A68F3 for ; Sat, 6 Jun 2009 21:17:32 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n574HTx6025951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Jun 2009 23:17:30 -0500 (CDT) Received: from shoonya.ih.lucent.com (guard.research.bell-labs.com [135.104.2.10]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n574HPTZ003567; Sat, 6 Jun 2009 23:17:26 -0500 (CDT) Message-ID: <4A2B3F73.6080704@alcatel-lucent.com> Date: Sat, 06 Jun 2009 23:17:55 -0500 From: Vijay Gurbani User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Eric Burger , Hadriel Kaplan , christer.holmberg@ericsson.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: sipcore@ietf.org Subject: [sipcore] Review of draft-ietf-sip-info-events-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2009 04:17:35 -0000 Sorry for the long review. Summary statement: This draft is on the right track but has open issues, described in the review. First of all, thanks for tackling this particular piece of work; this is good stuff and it will make life easier for many developers. That said, the draft needs a substantial amount of work to be ready for publication, both at the editorial level and at the content level. Editorially, it is currently written in a collegial and informal style, which is not appropriate for a standards-track document, and an important one at that. Besides gratuitous commas and run-on sentences, the draft also contains phrases like "...and so on", "some may think", "It is the hope of this draft's authors", "we could be lazy ...", "we require...", "use a totally externally signaled channel", "can do stuff", etc. (you get the idea.) I think that choosing one author as an editor and allowing him a couple of free hours and a pint or two of beer will not be a bad idea ;-) General comments (3 comments): ------------------------------ 1) When talking about entities receiving or sending INFO requests, you should either stick to "UAS" and "UAC" respectively, or "server" and "client", respectively. As the text is now written, in some places "UAS" is used and in other, "server" is used. 2) Should we add a subsection in S7 on INFO refresh (see comment number 10 in the next section for more context)? 3) I found the Appendix fairly useful as historical context. Is the idea to retain it going forward? If so, you may want to edit it carefully. Right now it looks like it has been written by two co-authors independently and then mashed together: note that SA.1 - SA.4 contain pretty much the same information as SA5. Substantive content-specific comments (24 comments) --------------------------------------------------- 1) S1, third paragraph, sentence on line 9: what you are describing here is more akin to a problem of deciding how to render a JPEG image instead of supporting it. The sender and receiver both support the JPEG image, where "support" means they will send and receive the image; it is just that the receiver does not know how to render the image because the sender did not provide any hints when it sent the image. I think you need to phrase the discussion here in that there is a multiplicity of ways to render an image received with a "image/jpeg" MIME type and that the sender of the image needs to provide some hints to the receiver on how to render it. In much the same way, the new INFO package proposes to provide some hints to the receiver on how to make sense of the user-to-user information being exchanged in the INFO message. 2) S1, page 5, fourth paragraph, it is stated that "This document provides a similar framework for INVITE-based application level information exchange." Do you not mean "INFO-based application level information exchange instead? Additional comment in the same paragraph: collect all the places where you talk about SUBS/NOT in one place and distinguish them from how Info packages are supposed to work. Currently, you talk about SUBS/NOT, then you talk about INFO, and then circle back to SUBS/NOT and hop to INFO to close the paragraph. This leaves the reader going back and forth trying to bridge the gap between how SUBS/NOT differs from INFO. While this is okay for old SIP hands, new developers who do not have the history of SIP embedded in their DNA genomes will be completely lost. 3) S1, page 6, first complete paragraph on that page: I would suggest that you replace "near end" and "far end" with something else; for instance, instead of saying "If the far end indicates it can receive a package offered by the near end,..." how about "If one peer indicates it can receive a package offered by the the other peer ...". The terms "near end" and "far end" are subjective: near to who? far from who? Same paragraph, you may also want to inform the reader that the Recv-Info and Info-Package headers are both defined in this document. That is, instead of saying "The Recv-Info header indicates ...", how about "The Recv-Info header, defined in this document, indicates ...". Similarly for the succeeding sentence that discusses Info-Package. 4) Section 3 requires a lot of work, IMHO; more so because this is a very important section and lays down the behavior of the communicating entities. As such, as much as we can avoid ambiguity here and provide clear instructions to developers, the better off we'd be in the long run. The next few issues are around making this section less ambiguous. S3.1, general comment on the section: it appears that this section has been written while keeping a UAS in mind. It will be much better if this section was broken down into two subsections, one discussing UAS behavior and the other discussing UAC behavior. 5) S3.1, first paragraph: As I read this paragraph, is becomes obvious that if we do not specify in some detail how the negotiation for sending Recv-Info is done, we could run into interoperability problems. For instance, given the INVITE transaction, I can see at least two ways to probe for support of this package: i) Initiating-UA triggered INFO package negotiation: INVITE sip:... Recv-Info: foo, bar ... 180 Ringing sip:... Recv-Info: bar or ii) Target-UA triggered INFO package negotiation: INVITE sip:... ... 180 Ringing SIP/2.0 Recv-Info: foo, bar ... ACK sip:... Recv-Info: bar In case (i), the UAS could have indicated support for the INFO packages in a 200 as well. In case (i), the ACK will not have any Recv-Info headers (please confirm.) Now, to make matters more complex, from the table in S5.2, it appears that INFO negotiations can be done in a PRACK/200 and an UPDATE/200 as well. While doing the INFO negotiation in UPDATE/200 is fine, I am curious why we would want to do it in PRACK/200, since that particular transaction is nested within the INVITE transaction (thus adding more complexity when it could easily be avoided.) Is that the intent? Are we sure we want to add this additional complexity on top of PRACK? Is there a good reason why we would want to take on additional complexity introduced by PRACK. If there is, we should at least provide clear guidelines. So, there are two specific comments here: (1) Provide better guidelines to implementers (see case i and ii above) including showing portions of a SIP message and flow to be more explicit on the intent; and (2) determine if we need to do INFO event negotiation in a PRACK, and if so, provide better guidelines, including showing call flows and portions of SIP messages to be more explicit of the intent. 6) S3.1, page 7, last paragraph, second last line: s/the UAS MUST list the preferred Info Package lexically earlier in the message./it MUST maintain an ordinal sequence of the preferred Info Package among others./ 7) S3.1, page 8, towards the top of the page it is said that "Listing a package multiple times does no harm." I am curious, why even allow the listing of the same package multiple times? It will make parsing more cumbersome and force the receiving side to maintain a larger set of Info packages where some elements may occur multiple times. All this can be trivially avoided by just mandating that packages must be listed once. 8) S3.1, the indented "NOTE" in the middle of page 8: I would advise to make the text more terse and more formal; something like the following (please feel free to edit as you see fit): NOTE: While an empty Recv-Info header could be used to indicate that the sender does not wish to receive any Info packages, such usage will fall short should a richer negotiation strategy be required at some later time. Using the value 'nil' makes the intent of the sender of the Recv-Info request explicit. 9) S3.1, page 8, in the discussion on the second half of that page, I am lost as to your intent. The initiating UA sends an INV with support for two packages P and R. You do not show what the target UA supports -- did it support both packages, or did the target UA send a 200 OK with an additional package, T? You then go on to show an ACK going from the initiating UA with package R and T. This implies that there is an offer/counter-offer/answer type of negotiation, which is not what you had outlined in the beginning of Section 3.1. Can the target UA add a package that was not present in the Recv-Info header of the initiating UA? This is very important to clarify if we want to get the negotiation right. 10) S3.1, page 9, the paragraph "In the case of ... specified by this document." is a very important one and needs to be highlighted more. Essentially, if I read the paragraph correctly, the validity of an INFO message is bounded by either of the following two conditions: (i) The dialog is terminated normally; or (ii) A peer receives a dialog refresh request, but that request did not have a Recv-Info header in it. Case (i) can be characterized as the normal behavior, after all, if a dialog goes away, it makes sense that any state associated with it vanishes as well. Case (ii), however, is rather important if the intent of the draft is indeed to terminate Info package state if it is not refreshed by a dialog refresh request. Case (ii) implies that Info packages have a lifetime that may be less than that of the dialog in which they are contained. If that is indeed the case, then a mid-dialog refresh request appears to be a means to terminate an Info package state before the dialog itself is terminated. This would normally be okay, but brings to the fore another important question: what if a dialog usage does not have a mid-dialog request but the services of an Info package are no longer needed for the duration of the lifetime of the dialog. In such a case, should we come up with a specific Info-Expires header? To make matters worse, while S3.1 appears to state that the Info packages may have a lifetime less than that of the dialog they are contained in, S4.1, fourth paragraph, appears to contradict this assertion. In S4.1, fourth paragraph, it is stated that "The INFO method has no lifetime or usage of its own ..." So, some more thoughts on the lifetime of an Info package seem appropriate and they should be spelled out in detail in this section. Personally, I think that it should be okay to simply bound the lifetime of an Info package with that of the dialog and leave it at that. Exhorting implementers to expire an Info package if the dialog refresh did not include a Recv-Info header seems to be calling for more complexity than needed. Are there existing usages of Info that require such behavior? 11) S3.2, second paragraph: The second reason for why versioning is not supported needs to be made a bit more clear. I would suggest the following replacement text (edit as needed): A second reason for not supporting a package versioning system is that not all payloads are capable of encoding a version number. In the end, while it is easy for user agents to negotiate Info package support, asking them to also negotiate specific package versions closely ties the signaling to a specific payload version. Since the payload is to be interpreted by a transaction user, such coupling may not be beneficial as a general rule. 12) S4.1, page 10, last paragraph: I am curious -- why are we allowing early INFO requests? More so since when they interact with forking, they seem to produce undesirable complexity. RFC2976 does not mention INFO forking in the context of a initiating UA receiving multiple INFO messages, which is what is being discussed here. RFC2976 does talk about the INFO request forking, but this is in the context of a forking proxy sending out multiple INFO requests. As such, if we intend to allow the first behavior, i.e., an initiating UA receiving multiple INFO requests as result of a forked INVITE, then we'd better say a lot more than this one paragraph on the resulting complexity (this small paragraph is the only place in the document where early INFO is mentioned.) The behavior in this section for such a case is inadequately specified: should the initiating UA expect INFO requests before the provisionals or after the provisionals, or does it not matter? What if PRACK is used? Should the target UA wait for a PRACK before it sends an INFO? And so on. IMHO, since we are defining new behavior for INFO, why take on additional complexity in the form of burdening the initiating UA with receiving multiple INFO requests? Is there a proposed Info package that requires such behavior? Or conversely, is there a legacy Info usage whose behavior we want to preserve by this complexity? If the answer is no, then I really think we should simply mandate that the INFO request is to be sent once the dialog has been established. 13) S4.2, second paragraph: I don't understand this -- why is it left to the UAC to determine whether it is "appropriate to send that payload to the UAS"? Should this not be the task of the Info package designer? In other words, all we need to say here is "If the Info package defines a payload, the UAC MUST include the payload and the MIME type described in the Info package." 14) S4.2, third paragraph: The sentence here is self-evident; I am not sure why list this behavior out explicitly. 15) S4.2, fourth paragraph: what do you mean by "INFO proper"? I presume you either mean RFC2976, or the ad-hoc use of INFO in the Internet. If so, please restate as such. If not, please amplify the meaning of "INFO proper". 16) S4.7, first paragraph, it is stated that the "UAS cannot use the CSeq to determine the sequence of INFO messages." I am not sure I understand why. Is it not the case that the CSeq number of later requests will be higher than the one of previous requests? Sure, there will be gaps, but later requests will have a CSeq number bigger than previous ones. Same section, second paragraph, it is stated that "Since overlapping requests will occur even if the application (Info package) does not allow it..." -- I don't understand why overlapping would occur if the Info package did not allow it? Is it because of some legacy INFO usage that behaves in this way? If so, simply state that as the reason, and if not, you may want to add text that supports why a developer should be prepared to handle overlapped requests if the Info package prohibits these. 17) S6, last paragraph: should we not do more than "hope" that vendors who implement proprietary Info usages submit their mechanisms as Info package extension documents? That is, shouldn't we "require" them to do ss at least using a SHOULD strength? 18) S7.1 - S7.11: In certain sub-sections, the text says "This section, [...], MUST be present..." Why the singling out of certain sections in this manner? Shouldn't it be the case that ALL sections MUST be present in an Info package extension document? If they are not relevant to that specific package, the package designer can simply state "N/A". As these sections are now written, if I was an Info package designer, I would automatically assume that some sections, especially those ones where it does not say that they MUST be present, can be omitted when documenting my Info package. I don't think that is the intent here, is it? 19) S7.6 and S7.7: I think the meat of these two sub-sections deals with overlapped INFO requests, and as such, a new sub-section on this topic should be added if overlapped requests are to be allowed. The UAC generation of INFO requests takes only a paragraph and can be moved to its own sub-section. Likewise for UAS processing of INFO requests. 20) S7.10, discussion in the middle of the section: The reason for not mandating TLS is not because there are "few protocol mechanisms to enforce this" -- indeed, there are few protocol mechanisms to enforce any arbitrary behavior, which is why policing network traffic is so lucrative a business model. The main reason why TLS is not sufficient is because of its hop-by-hop nature, intermediaries will be privy to any INFO package contents. Now, there really isn't a way around this in SIP unless you do an end-to-end certificate exchange to bootstrap TLS. S/MIME, which is given as an option in the draft, is academic since I do not believe that many SIP implementations, if any, support it at all. I am not sure what to say here except that the text needs to be cleaned up a bit to inform Info package designers that while TLS is better than nothing, it will still leak Info package bodies to intermediaries (i.e., remove the "few protocol mechanisms to enforce this" sentence.) Those Info implementations that want to protect their payload should use S/MIME or some other means to prevent intermediary eavesdropping. 21) S8, in the Info-package-type production rule, why is the dot (".") used to separate parameters when everywhere else in SIP the semi-colon (";") plays the same role? 22) S10: S7.11 asks Info package designers to provide complete and syntactically correct SIP messages as examples. Ironically, this very issue is violated by your examples :-) It would be good to provide complete messages, if possible. 23) S10.1: The example in this section can also result in a situation where package "bar" never gets triggered even though Bob may indeed support it. Here's how, and please let me know if I am misunderstanding something here: Let's say Bob supported both "foo" and "bar". According to your text in S10.1, while Alice supports sending "bar", she can send AND receive "foo"; so she only puts "foo" in the Recv-Info header. Now, when the Recv-Info header reaches Bob, all Bob knows is that Alice supports receiving "foo". Bob can receive "bar", but does not know that Alice can indeed send "bar". So, "bar" as an Info package has inadvertently been cut out. This is not good, right (if I am missing something critical here, please do let me know.) If the above is indeed true, then we may have a bigger problem on our hands. The example in this section got me thinking about the distinction between Recv-Info containing package names that can be sent and received versus packages that can only be sent (and therefore, not received?) The text in S10.1 states that "Alice can support sending or receiving "foo" Info packages, and sending "bar" Info Packages." Does that mean that Alice cannot receive "bar" package? Only send it? Is there a distinction between Recv-Info containing package names that a UAC can "send", "receive" or "send and receive"? S1 starts to tease this on page 6 when it states that "Each UA enumerates which Info Packages it can receive." but it does not finish the discussion; much is left unsaid. Does that mean that when a UAC includes an Info package name in Recv-Info, it can only receive that type of package but cannot send it? In fact, how can a UAC indicate support for Info packages that it can send? It looks like a UAC cannot use the "Supported" header for this (c.f., S3.1). Similarly, how does a UAC include support for Info packages it can send and receive? Clearly, if a UAC is capable of receiving an Info package, is it not capable of sending it as well? In other words, consider the following exchange -- a UAC sends: INVITE ... Recv-Info: A, B to which a UAS replies: 200 OK ... Recv-Info: B And the UAC now sends an INFO request with Info package B. So, "receive" seems to automatically imply "send", and thereby "send and receive" as well. Am I correct or am I just plain missing something here? To me at least, this is a rather important distinction that ought to be spelled out. Right now I am not sure whether Recv-Info implies both receive and send -- I think it does, but portions of the draft lead me to believe otherwise. 24) S11: I think what you are trying to do here is to establish a Info package registry in the same way that we established the tel URI parameter registry (RFC5341) and the sip URI parameter registry (RFC3969), correct? If so, I agree with the note that this section may be a separate document altogether since the mechanics of assigning an expert review, etc. are described in such registry documents (you can use RFC5341 and RFC3969 as templates.) Nits and editorials (11 comments) --------------------------------- 1) Abstract, first sentence: Instead of saying, "This document defines a new SIP INFO method", probably better to say that "This document provides new semantics to the INFO method of RFC2976, obsoleting the old usage in a backwards-compatible manner." My reason for this comment is that this document is not defining a new method called INFO as much as it is trying to provide a new context and semantics for the use of an existing method called INFO. 2) Abstract, paragraph three: s/Be mindful/The reader is urged to be mindful/ 3) S1, page 6, last paragraph: s/Conversely, this can be/Conversely, this can also be/ 4) S3, opening paragraph: s/To be abundantly clear, as stated/As stated 5) S3.1, page 8, towards the end of the page: s/send form package/send package/ 6) S3.1, page 9: s/UA in the dial will/UA in the dialog will/ 7) S3.1, last paragraph: consider replacing "far-end" with something else -- something as such: OLD If the far-end UA does not indicate support for an Info package that the local server requires, the server MAY terminate the session with a CANCEL or BYE request. NEW If the UA receiving the INFO request did not indicate support for a required Info package, the sender of the INFO MAY terminate the session with a CANCEL or a BYE request. 8) S4.3, page 13, the indented "NOTE" paragraph at the top of the page: I think you can remove this paragraph -- you are mandating that a 489 be sent when the UAS receives an INFO message with a package it does not understand. That should be it; I think pointing out the link between INFO and NOTIFY serves only to confuse the issue. As a developer, I want to know what to send when I get a request I cannot handle. As long as the good RFC tells me to send a 489, so be it. 9) S4.3, page 13, second paragraph: s/but it has no/but the INFO request has no/ s/as it sees fit// (i.e., remove "as it sees fit") 10) S8, first paragraph: s/user-to-user data exchange in SIP./INFO method./ Same section, second paragraph is redundant and can be easily removed without impacting readability or understanding. 11) S12, first paragraph: s/improve the security of the Internet./improve the security of SIP-based communications./ Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://ect.bell-labs.com/who/vkg From pkyzivat@cisco.com Sun Jun 7 20:31:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA013A6801 for ; Sun, 7 Jun 2009 20:31:24 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBAg4rKYUlyl for ; Sun, 7 Jun 2009 20:31:22 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D23113A67A8 for ; Sun, 7 Jun 2009 20:31:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,322,1241395200"; d="scan'208";a="46487760" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 08 Jun 2009 03:31:26 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n583VQ1V010693; Sun, 7 Jun 2009 23:31:26 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n583VQWN005772; Mon, 8 Jun 2009 03:31:26 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 7 Jun 2009 23:31:26 -0400 Received: from [10.86.247.194] ([10.86.247.194]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 7 Jun 2009 23:31:25 -0400 Message-ID: <4A2C8606.7030302@cisco.com> Date: Sun, 07 Jun 2009 23:31:18 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Vijay Gurbani References: <4A2B3F73.6080704@alcatel-lucent.com> In-Reply-To: <4A2B3F73.6080704@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2009 03:31:25.0624 (UTC) FILETIME=[9A245B80:01C9E7E9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=25415; t=1244431886; x=1245295886; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Review=20of=20draft-ietf-si p-info-events-03 |Sender:=20 |To:=20Vijay=20Gurbani=20; bh=My6RfvLmECVwLu4vgo52+z4K9wtTFBstVSF8LOh8wL0=; b=E1i1hvVpwn317yX94ISas4Eet3Srugr05kghFv/YJI+FMzRXCPLJcbeQoG 80ICpss4wtZnDA1FRLeh7LBACD74X4nDCyYHVd2FOYxx5WTVpbWy5fh0X/mZ mXPb9/LhGO; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sipcore@ietf.org, Hadriel Kaplan Subject: Re: [sipcore] Review of draft-ietf-sip-info-events-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 03:31:24 -0000 Vijay, Wow! A very thorough review!!! I haven't had time to do so. I just provide a few observations inline on yours. Thanks, Paul Vijay Gurbani wrote: > Sorry for the long review. > > Summary statement: > This draft is on the right track but has open issues, > described in the review. > > First of all, thanks for tackling this particular piece of work; > this is good stuff and it will make life easier for many > developers. > > That said, the draft needs a substantial amount of work to be ready > for publication, both at the editorial level and at the content level. > Editorially, it is currently written in a collegial and informal > style, which is not appropriate for a standards-track document, and an > important one at that. Besides gratuitous commas and run-on > sentences, the draft also contains phrases like "...and so on", "some > may think", "It is the hope of this draft's authors", "we could be > lazy ...", "we require...", "use a totally externally signaled > channel", "can do stuff", etc. (you get the idea.) I think that > choosing one author as an editor and allowing him a couple of free > hours and a pint or two of beer will not be a bad idea ;-) > > General comments (3 comments): > ------------------------------ > 1) When talking about entities receiving or sending INFO requests, you > should either stick to "UAS" and "UAC" respectively, or "server" and > "client", respectively. As the text is now written, in some places > "UAS" is used and in other, "server" is used. > > 2) Should we add a subsection in S7 on INFO refresh (see comment > number 10 in the next section for more context)? > > 3) I found the Appendix fairly useful as historical context. Is the > idea to retain it going forward? If so, you may want to edit it > carefully. Right now it looks like it has been written by two > co-authors independently and then mashed together: note that SA.1 - > SA.4 contain pretty much the same information as SA5. > > Substantive content-specific comments (24 comments) > --------------------------------------------------- > 1) S1, third paragraph, sentence on line 9: what you are describing > here is more akin to a problem of deciding how to render a JPEG image > instead of supporting it. The sender and receiver both support the > JPEG image, where "support" means they will send and receive the > image; it is just that the receiver does not know how to render the > image because the sender did not provide any hints when it sent the > image. > > I think you need to phrase the discussion here in that there is a > multiplicity of ways to render an image received with a "image/jpeg" > MIME type and that the sender of the image needs to provide some hints > to the receiver on how to render it. In much the same way, the new > INFO package proposes to provide some hints to the receiver on how to > make sense of the user-to-user information being exchanged in the INFO > message. > > 2) S1, page 5, fourth paragraph, it is stated that "This document > provides a similar framework for INVITE-based application level > information exchange." Do you not mean "INFO-based application level > information exchange instead? > > Additional comment in the same paragraph: collect all the places where > you talk about SUBS/NOT in one place and distinguish them from how > Info packages are supposed to work. Currently, you talk about > SUBS/NOT, then you talk about INFO, and then circle back to SUBS/NOT > and hop to INFO to close the paragraph. This leaves the reader going > back and forth trying to bridge the gap between how SUBS/NOT differs > from INFO. While this is okay for old SIP hands, new developers who > do not have the history of SIP embedded in their DNA genomes will be > completely lost. > > 3) S1, page 6, first complete paragraph on that page: I would suggest > that you replace "near end" and "far end" with something else; for > instance, instead of saying "If the far end indicates it can receive a > package offered by the near end,..." how about "If one peer indicates > it can receive a package offered by the the other peer ...". The > terms "near end" and "far end" are subjective: near to who? far from > who? > > Same paragraph, you may also want to inform the reader that the > Recv-Info and Info-Package headers are both defined in this document. > That is, instead of saying "The Recv-Info header indicates ...", how > about "The Recv-Info header, defined in this document, indicates ...". > Similarly for the succeeding sentence that discusses Info-Package. > > 4) Section 3 requires a lot of work, IMHO; more so because this is a > very important section and lays down the behavior of the communicating > entities. As such, as much as we can avoid ambiguity here and provide > clear instructions to developers, the better off we'd be in the long > run. The next few issues are around making this section less ambiguous. > > S3.1, general comment on the section: it appears that this section > has been written while keeping a UAS in mind. It will be much better > if this section was broken down into two subsections, one discussing > UAS behavior and the other discussing UAC behavior. > > 5) S3.1, first paragraph: As I read this paragraph, is becomes obvious > that if we do not specify in some detail how the negotiation for > sending Recv-Info is done, we could run into interoperability > problems. For instance, given the INVITE transaction, I can see at > least two ways to probe for support of this package: > > i) Initiating-UA triggered INFO package negotiation: > > INVITE sip:... > Recv-Info: foo, bar > ... > > 180 Ringing sip:... > Recv-Info: bar > > or > > ii) Target-UA triggered INFO package negotiation: > INVITE sip:... > ... > > 180 Ringing SIP/2.0 > Recv-Info: foo, bar > ... > > ACK sip:... > Recv-Info: bar > > In case (i), the UAS could have indicated support for the INFO > packages in a 200 as well. In case (i), the ACK will not have any > Recv-Info headers (please confirm.) > > Now, to make matters more complex, from the table in S5.2, it appears > that INFO negotiations can be done in a PRACK/200 and an UPDATE/200 as > well. While doing the INFO negotiation in UPDATE/200 is fine, I am > curious why we would want to do it in PRACK/200, since that particular > transaction is nested within the INVITE transaction (thus adding more > complexity when it could easily be avoided.) Is that the intent? Are > we sure we want to add this additional complexity on top of PRACK? Is > there a good reason why we would want to take on additional complexity > introduced by PRACK. If there is, we should at least provide clear > guidelines. There is need to get the negotiation done well before the ACK, so that the INVO can be used before the request is accepted. (At least I think it is.) That is covered in case (1), but if it is UAS that wants to use it, then case (2) isn't enough. This could be covered using 18x/prack. Or it could be covered using UPDATE. > So, there are two specific comments here: (1) Provide better > guidelines to implementers (see case i and ii above) including showing > portions of a SIP message and flow to be more explicit on the intent; > and (2) determine if we need to do INFO event negotiation in a PRACK, > and if so, provide better guidelines, including showing call flows and > portions of SIP messages to be more explicit of the intent. > > 6) S3.1, page 7, last paragraph, second last line: > s/the UAS MUST list the preferred Info Package lexically earlier in > the message./it MUST maintain an ordinal sequence of the preferred Info > Package among others./ > > 7) S3.1, page 8, towards the top of the page it is said that "Listing > a package multiple times does no harm." I am curious, why even allow > the listing of the same package multiple times? It will make parsing > more cumbersome and force the receiving side to maintain a larger set > of Info packages where some elements may occur multiple times. All > this can be trivially avoided by just mandating that packages must be > listed once. > > 8) S3.1, the indented "NOTE" in the middle of page 8: I would advise > to make the text more terse and more formal; something like the > following (please feel free to edit as you see fit): > > NOTE: While an empty Recv-Info header could be used to indicate > that the sender does not wish to receive any Info packages, such > usage will fall short should a richer negotiation strategy be > required at some later time. Using the value 'nil' makes the > intent of the sender of the Recv-Info request explicit. > > 9) S3.1, page 8, in the discussion on the second half of that page, I > am lost as to your intent. The initiating UA sends an INV with > support for two packages P and R. You do not show what the target UA > supports -- did it support both packages, or did the target UA send a > 200 OK with an additional package, T? You then go on to show an ACK > going from the initiating UA with package R and T. This implies that > there is an offer/counter-offer/answer type of negotiation, which is > not what you had outlined in the beginning of Section 3.1. Can the > target UA add a package that was not present in the Recv-Info header > of the initiating UA? This is very important to clarify if we want to > get the negotiation right. > > 10) S3.1, page 9, the paragraph "In the case of ... specified by this > document." is a very important one and needs to be highlighted more. > Essentially, if I read the paragraph correctly, the validity of an > INFO message is bounded by either of the following two conditions: > (i) The dialog is terminated normally; or > (ii) A peer receives a dialog refresh request, but that request > did not have a Recv-Info header in it. > > Case (i) can be characterized as the normal behavior, after all, if a > dialog goes away, it makes sense that any state associated with it > vanishes as well. Case (ii), however, is rather important if the > intent of the draft is indeed to terminate Info package state if it is > not refreshed by a dialog refresh request. > > Case (ii) implies that Info packages have a lifetime that may be less > than that of the dialog in which they are contained. If that is > indeed the case, then a mid-dialog refresh request appears to be a > means to terminate an Info package state before the dialog itself is > terminated. This would normally be okay, but brings to the fore > another important question: what if a dialog usage does not have a > mid-dialog request but the services of an Info package are no longer > needed for the duration of the lifetime of the dialog. In such > a case, should we come up with a specific Info-Expires header? This termination mid-dialog is important to ensure that 3pcc scenarios can work. I don't understand your question here. If you want an info usage to go away mid-dialog, why not use a dialog refresh to cause that? This would be entirely analogous to termination of a session-timer mid-session. > To make matters worse, while S3.1 appears to state that the Info > packages may have a lifetime less than that of the dialog they are > contained in, S4.1, fourth paragraph, appears to contradict this > assertion. In S4.1, fourth paragraph, it is stated that "The INFO > method has no lifetime or usage of its own ..." > So, some more thoughts on the lifetime of an Info package seem > appropriate and they should be spelled out in detail in this section. > Personally, I think that it should be okay to simply bound the > lifetime of an Info package with that of the dialog and leave it at > that. Exhorting implementers to expire an Info package if the dialog > refresh did not include a Recv-Info header seems to be calling for > more complexity than needed. Are there existing usages of Info that > require such behavior? Any time you do a 3pcc transfer, one side things their dialog is preserved, while on the other side there have been two distinct dialogs. If the first of those supported the info pkg, but the 2nd does not, then you need a way to renegotiate. > 11) S3.2, second paragraph: The second reason for why versioning is > not supported needs to be made a bit more clear. I would suggest the > following replacement text (edit as needed): > > A second reason for not supporting a package versioning system > is that not all payloads are capable of encoding a version > number. In the end, while it is easy for user agents to > negotiate Info package support, asking them to also negotiate > specific package versions closely ties the signaling to a > specific payload version. Since the payload is to be > interpreted by a transaction user, such coupling may not be > beneficial as a general rule. > > 12) S4.1, page 10, last paragraph: I am curious -- why are we allowing > early INFO requests? More so since when they interact with > forking, they seem to produce undesirable complexity. Well, since the poster child has always been DTMF, that is something that is frequently desired in early dialogs. > RFC2976 does not mention INFO forking in the context of a initiating > UA receiving multiple INFO messages, which is what is being discussed > here. RFC2976 does talk about the INFO request forking, but this is > in the context of a forking proxy sending out multiple INFO requests. > As such, if we intend to allow the first behavior, i.e., an initiating > UA receiving multiple INFO requests as result of a forked INVITE, then > we'd better say a lot more than this one paragraph on the resulting > complexity (this small paragraph is the only place in the document > where early INFO is mentioned.) The behavior in this section for such > a case is inadequately specified: should the initiating UA expect INFO > requests before the provisionals or after the provisionals, or does it > not matter? What if PRACK is used? Should the target UA wait for a > PRACK before it sends an INFO? And so on. > > IMHO, since we are defining new behavior for INFO, why take on > additional complexity in the form of burdening the initiating UA with > receiving multiple INFO requests? Is there a proposed Info package > that requires such behavior? Or conversely, is there a legacy Info > usage whose behavior we want to preserve by this complexity? If the > answer is no, then I really think we should simply mandate that the > INFO request is to be sent once the dialog has been established. Once again I think DTMF gives an example. You might need to send it during early dialog, and in conjunction with forking you then may be exchanging them on multiple early dialogs. > 13) S4.2, second paragraph: I don't understand this -- why is it left > to the UAC to determine whether it is "appropriate to send that > payload to the UAS"? Should this not be the task of the Info package > designer? In other words, all we need to say here is "If the Info > package defines a payload, the UAC MUST include the payload and the > MIME type described in the Info package." > > 14) S4.2, third paragraph: The sentence here is self-evident; I am not > sure why list this behavior out explicitly. > > 15) S4.2, fourth paragraph: what do you mean by "INFO proper"? I > presume you either mean RFC2976, or the ad-hoc use of INFO in the > Internet. If so, please restate as such. If not, please amplify the > meaning of "INFO proper". > > 16) S4.7, first paragraph, it is stated that the "UAS cannot use the > CSeq to determine the sequence of INFO messages." I am not sure I > understand why. Is it not the case that the CSeq number of later > requests will be higher than the one of previous requests? Sure, > there will be gaps, but later requests will have a CSeq number bigger > than previous ones. > > Same section, second paragraph, it is stated that "Since overlapping > requests will occur even if the application (Info package) does not > allow it..." -- I don't understand why overlapping would occur if > the Info package did not allow it? Is it because of some legacy INFO > usage that behaves in this way? If so, simply state that as the > reason, and if not, you may want to add text that supports why a > developer should be prepared to handle overlapped requests if the Info > package prohibits these. > > 17) S6, last paragraph: should we not do more than "hope" that vendors > who implement proprietary Info usages submit their mechanisms as Info > package extension documents? That is, shouldn't we "require" them to > do ss at least using a SHOULD strength? > > 18) S7.1 - S7.11: In certain sub-sections, the text says "This > section, [...], MUST be present..." Why the singling out of certain > sections in this manner? Shouldn't it be the case that ALL sections > MUST be present in an Info package extension document? If they are > not relevant to that specific package, the package designer can simply > state "N/A". As these sections are now written, if I was an Info > package designer, I would automatically assume that some sections, > especially those ones where it does not say that they MUST be present, > can be omitted when documenting my Info package. > > I don't think that is the intent here, is it? > > 19) S7.6 and S7.7: I think the meat of these two sub-sections deals with > overlapped INFO requests, and as such, a new sub-section on this topic > should be added if overlapped requests are to be allowed. The UAC > generation of INFO requests takes only a paragraph and can be moved to > its own sub-section. Likewise for UAS processing of INFO requests. > > 20) S7.10, discussion in the middle of the section: The reason for not > mandating TLS is not because there are "few protocol mechanisms to > enforce this" -- indeed, there are few protocol mechanisms to enforce > any arbitrary behavior, which is why policing network traffic is so > lucrative a business model. The main reason why TLS is not sufficient > is because of its hop-by-hop nature, intermediaries will be privy to > any INFO package contents. Now, there really isn't a way around this > in SIP unless you do an end-to-end certificate exchange to bootstrap > TLS. S/MIME, which is given as an option in the draft, is academic > since I do not believe that many SIP implementations, if any, support > it at all. > > I am not sure what to say here except that the text needs to be > cleaned up a bit to inform Info package designers that while TLS is > better than nothing, it will still leak Info package bodies to > intermediaries (i.e., remove the "few protocol mechanisms to enforce > this" sentence.) Those Info implementations that want to protect > their payload should use S/MIME or some other means to prevent > intermediary eavesdropping. > > 21) S8, in the Info-package-type production rule, why is the dot (".") > used to separate parameters when everywhere else in SIP the > semi-colon (";") plays the same role? > > 22) S10: S7.11 asks Info package designers to provide > complete and syntactically correct SIP messages as examples. > Ironically, this very issue is violated by your examples :-) > It would be good to provide complete messages, if possible. > > 23) S10.1: The example in this section can also result in a situation > where package "bar" never gets triggered even though Bob may indeed > support it. Here's how, and please let me know if I am > misunderstanding something here: Let's say Bob supported both "foo" > and "bar". According to your text in S10.1, while Alice supports > sending "bar", she can send AND receive "foo"; so she only puts "foo" > in the Recv-Info header. > > Now, when the Recv-Info header reaches Bob, all Bob knows is that > Alice supports receiving "foo". Bob can receive "bar", but does not > know that Alice can indeed send "bar". So, "bar" as an Info package > has inadvertently been cut out. This is not good, right (if I am > missing something critical here, please do let me know.) > > If the above is indeed true, then we may have a bigger problem on our > hands. The example in this section got me thinking about the > distinction between Recv-Info containing package names that can be > sent and received versus packages that can only be sent (and > therefore, not received?) The text in S10.1 states that "Alice can > support sending or receiving "foo" Info packages, and sending "bar" > Info Packages." Does that mean that Alice cannot receive "bar" > package? Only send it? > > Is there a distinction between Recv-Info containing package names that > a UAC can "send", "receive" or "send and receive"? S1 starts to tease > this on page 6 when it states that "Each UA enumerates which Info > Packages it can receive." but it does not finish the discussion; much > is left unsaid. Does that mean that when a UAC includes an Info > package name in Recv-Info, it can only receive that type of package > but cannot send it? In fact, how can a UAC indicate support for Info > packages that it can send? It looks like a UAC cannot use the > "Supported" header for this (c.f., S3.1). Similarly, how does a UAC > include support for Info packages it can send and receive? > > Clearly, if a UAC is capable of receiving an Info package, is it not > capable of sending it as well? In other words, consider the following > exchange -- a UAC sends: > > INVITE ... > Recv-Info: A, B > > to which a UAS replies: > > 200 OK ... > Recv-Info: B > > And the UAC now sends an INFO request with Info package B. So, > "receive" seems to automatically imply "send", and thereby "send and > receive" as well. Am I correct or am I just plain missing something > here? To me at least, this is a rather important distinction that > ought to be spelled out. Right now I am not sure whether Recv-Info > implies both receive and send -- I think it does, but portions of the > draft lead me to believe otherwise. > > 24) S11: I think what you are trying to do here is to establish a Info > package registry in the same way that we established the tel URI > parameter registry (RFC5341) and the sip URI parameter registry > (RFC3969), correct? If so, I agree with the note that this section > may be a separate document altogether since the mechanics of assigning > an expert review, etc. are described in such registry documents (you > can use RFC5341 and RFC3969 as templates.) > > Nits and editorials (11 comments) > --------------------------------- > > 1) Abstract, first sentence: Instead of saying, "This document > defines a new SIP INFO method", probably better to say that > "This document provides new semantics to the INFO method of > RFC2976, obsoleting the old usage in a backwards-compatible > manner." > > My reason for this comment is that this document is not defining > a new method called INFO as much as it is trying to provide a > new context and semantics for the use of an existing method called > INFO. > > 2) Abstract, paragraph three: > s/Be mindful/The reader is urged to be mindful/ > > 3) S1, page 6, last paragraph: > s/Conversely, this can be/Conversely, this can also be/ > > 4) S3, opening paragraph: > s/To be abundantly clear, as stated/As stated > > 5) S3.1, page 8, towards the end of the page: > s/send form package/send package/ > > 6) S3.1, page 9: > s/UA in the dial will/UA in the dialog will/ > > 7) S3.1, last paragraph: consider replacing "far-end" with something > else -- something as such: > > OLD > If the far-end UA does not indicate support for an Info package that > the local server requires, the server MAY terminate the session with > a CANCEL or BYE request. > > NEW > If the UA receiving the INFO request did not indicate support > for a required Info package, the sender of the INFO MAY > terminate the session with a CANCEL or a BYE request. > > 8) S4.3, page 13, the indented "NOTE" paragraph at the top of the > page: I think you can remove this paragraph -- you are mandating that > a 489 be sent when the UAS receives an INFO message with a package it > does not understand. That should be it; I think pointing out the link > between INFO and NOTIFY serves only to confuse the issue. As a > developer, I want to know what to send when I get a request I cannot > handle. As long as the good RFC tells me to send a 489, so be it. > > 9) S4.3, page 13, second paragraph: > s/but it has no/but the INFO request has no/ > s/as it sees fit// (i.e., remove "as it sees fit") > > 10) S8, first paragraph: > s/user-to-user data exchange in SIP./INFO method./ > > Same section, second paragraph is redundant and can be easily removed > without impacting readability or understanding. > > 11) S12, first paragraph: > s/improve the security of the Internet./improve the security of > SIP-based communications./ > > Thanks, > > - vijay From vkg@alcatel-lucent.com Mon Jun 8 08:41:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B6C53A6878 for ; Mon, 8 Jun 2009 08:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjY225r06K9l for ; Mon, 8 Jun 2009 08:41:30 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id E4B0828C102 for ; Mon, 8 Jun 2009 08:41:29 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id n58FfWUS027620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 10:41:32 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n58FfW5w002172; Mon, 8 Jun 2009 10:41:32 -0500 (CDT) Message-ID: <4A2D312C.90804@alcatel-lucent.com> Date: Mon, 08 Jun 2009 10:41:32 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Paul Kyzivat References: <4A2B3F73.6080704@alcatel-lucent.com> <4A2C8606.7030302@cisco.com> In-Reply-To: <4A2C8606.7030302@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: sipcore@ietf.org Subject: Re: [sipcore] Review of draft-ietf-sip-info-events-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 15:41:31 -0000 Paul Kyzivat wrote: > Wow! A very thorough review!!! I haven't had time to do so. > I just provide a few observations inline on yours. Paul: Thanks; more inline. > There is need to get the negotiation done well before the ACK, so that > the INVO can be used before the request is accepted. (At least I think > it is.) > > That is covered in case (1), but if it is UAS that wants to use it, then > case (2) isn't enough. This could be covered using 18x/prack. Or it > could be covered using UPDATE. OK, so then the negotiation aspects can be sub-sectioned off to show how a UAC would negotiate and use INFO packages and how the dynamics for triggering this negotiation by the UAS are different (essentially, take the two cases I outlined in my email and make them into sub-sections.) Of the two cases, case (ii), the Target-UA triggered INFO package negotiation (i.e., UAS-triggered) is the more complex case. As you say, it can be covered using 18x/PRACK or UPDATE. I suspect that the draft will have to provide guidance and examples on how to use both UPDATE and 18x/PRACK (I am sorry I am not being obstinate here, but if the draft does not provide guidance on which one to use and how, history shows that with more choices for doing a piece of work comes the inevitable question of interoperability.) I will leave it to the authors to determine whether or not one is a preferred mode of negotiation, though it seems to me that there should be some guidance provided to implementers (it may be as simple as saying that if the UAC did not have "100rel" in a Supported header, then the UAS MUST use UPDATE to trigger a INFO negotiation. If the UAC supports "100rel", the UAS MAY use PRACK or UPDATE.) > I don't understand your question here. If you want an info usage to go > away mid-dialog, why not use a dialog refresh to cause that? This would > be entirely analogous to termination of a session-timer mid-session. I was more worried about the case that suppose an INFO message installs some (non-dialog) state in the recipient. As the dialog progresses along, the state becomes stale and is no longer needed. But, there is no mid-dialog communications between the peers, which would normally cause the stale state to be flushed. As such, the recipient will have to maintain the now stale state until the dialog is torn down. Now granted that this type of scenario may not apply to existing INFO usages, but since the draft takes the burden of discussing how to refresh Info packages, it implies that there is a lifetime to these packages. Ergo, it should also cover the case where such refreshes are not done (I realize I am being a pedantic protocol designer here, so I will shut up if the WG feels that this is a moot point. An easy way to handle this would be to state simply that if no mid-dialog requests arrive to refresh the Info package state, then the state is simply maintained until the normal termination of the dialog.) > Any time you do a 3pcc transfer, one side things their dialog is > preserved, while on the other side there have been two distinct dialogs. > If the first of those supported the info pkg, but the 2nd does not, then > you need a way to renegotiate. I am not sure I follow, can you please elucidate... > Well, since the poster child has always been DTMF, that is something > that is frequently desired in early dialogs. Ah, enough said ;-) I think it will do some good in the draft if the reason for an early INFO message (namely, DTMF) is mentioned there (suggested text below.) > Once again I think DTMF gives an example. > You might need to send it during early dialog, and in conjunction with > forking you then may be exchanging them on multiple early dialogs. Hmmm ... okay; I can buy that. It will be good to just put down some text that gives the reason for supporting multiple INFO requests as a side-effect of forking. Something along these lines: OLD: The converse is not true during initial session establishment. The initiating UA of the first INVITE MUST be prepared to receive multiple INFO requests, as the first INVITE may fork. Since dialog negotiation has not completed, and we allow early INFO requests, multiple target UAs may respond. This initial dialog establishment phase is the only time the UAS need be prepared to receive multiple INFO requests, as we require post-session-establishment negotiation to fully complete before a UAC can send an INFO request. NEW: The converse is not true during initial session establishment. The initiating UA of the first INVITE MUST be prepared to receive multiple INFO requests, as the first INVITE may fork. Since dialog negotiation has not completed, and we allow early INFO requests, multiple target UAs may respond. When an INVITE forks and reaches multiple targets, these targets may want to interact with the initiator of the INVITE for some services, DTMF being the canonical one. The complexity of early INFO requests is thus needed to handle such interactions. The initial dialog establishment phase is the only time the UAC need be prepared to receive multiple INFO requests, as we require post-session-establishment negotiation to fully complete before a UAC can send an INFO request. (Note that there was a typo -- I think -- above. In the original text, it says "This initial dialog establishment phase is the only time the UAS need be prepared to receive multiple INFO requests...", but I think the authors meant the *UAC* should be prepared to receive multiple INFO requests. I have corrected this in the modified text.) Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From pkyzivat@cisco.com Mon Jun 8 09:42:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BAF128C171 for ; Mon, 8 Jun 2009 09:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9t7n+3fc6yX for ; Mon, 8 Jun 2009 09:42:08 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C100F3A6CF1 for ; Mon, 8 Jun 2009 09:42:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,325,1241395200"; d="scan'208";a="46570359" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 08 Jun 2009 16:42:12 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n58GgCZV015107; Mon, 8 Jun 2009 12:42:12 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n58GgCsH023349; Mon, 8 Jun 2009 16:42:12 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Jun 2009 12:42:12 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Jun 2009 12:42:11 -0400 Message-ID: <4A2D3F63.3070109@cisco.com> Date: Mon, 08 Jun 2009 12:42:11 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <4A2B3F73.6080704@alcatel-lucent.com> <4A2C8606.7030302@cisco.com> <4A2D312C.90804@alcatel-lucent.com> In-Reply-To: <4A2D312C.90804@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2009 16:42:12.0011 (UTC) FILETIME=[126477B0:01C9E858] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9596; t=1244479332; x=1245343332; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Review=20of=20draft-ietf-si p-info-events-03 |Sender:=20 |To:=20=22Vijay=20K.=20Gurbani=22=20; bh=Lx7/OPBj9vGJT2VmRbCc/T5lgU/bv/q2S17iOfjDEyc=; b=P9E4mkfOZ3b5L4cFqkd2LShstlndF36qsKu+rW53PdnpekkTx5iWpphc4Q yaiqDl0KKRRKxVi3RvRBcq9rPUbPdbSKwQmF747l/ybU95rVEhhIv/HZYZno FJB8CvaueA; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sipcore@ietf.org Subject: Re: [sipcore] Review of draft-ietf-sip-info-events-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 16:42:09 -0000 Vijay K. Gurbani wrote: > Paul Kyzivat wrote: >> Wow! A very thorough review!!! I haven't had time to do so. >> I just provide a few observations inline on yours. > > Paul: Thanks; more inline. > >> There is need to get the negotiation done well before the ACK, so that >> the INVO can be used before the request is accepted. (At least I think >> it is.) >> >> That is covered in case (1), but if it is UAS that wants to use it, >> then case (2) isn't enough. This could be covered using 18x/prack. Or >> it could be covered using UPDATE. > > OK, so then the negotiation aspects can be sub-sectioned off > to show how a UAC would negotiate and use INFO packages and > how the dynamics for triggering this negotiation by the UAS are > different (essentially, take the two cases I outlined in my > email and make them into sub-sections.) > > Of the two cases, case (ii), the Target-UA triggered INFO > package negotiation (i.e., UAS-triggered) is the more complex > case. As you say, it can be covered using 18x/PRACK or > UPDATE. I suspect that the draft will have to provide guidance > and examples on how to use both UPDATE and 18x/PRACK (I am > sorry I am not being obstinate here, but if the draft does > not provide guidance on which one to use and how, history shows > that with more choices for doing a piece of work comes > the inevitable question of interoperability.) > > I will leave it to the authors to determine whether or not one > is a preferred mode of negotiation, though it seems to me that > there should be some guidance provided to implementers (it may > be as simple as saying that if the UAC did not have "100rel" in > a Supported header, then the UAS MUST use UPDATE to trigger a > INFO negotiation. If the UAC supports "100rel", the UAS MAY > use PRACK or UPDATE.) I'm fine with all you say above. I agree that spelling things out clearly is important given the difficulties we have had in the past when not doing so. >> I don't understand your question here. If you want an info usage to go >> away mid-dialog, why not use a dialog refresh to cause that? This >> would be entirely analogous to termination of a session-timer >> mid-session. > > I was more worried about the case that suppose an INFO message > installs some (non-dialog) state in the recipient. As the > dialog progresses along, the state becomes stale and is no longer > needed. But, there is no mid-dialog communications between > the peers, which would normally cause the stale state to be > flushed. As such, the recipient will have to maintain the > now stale state until the dialog is torn down. > > Now granted that this type of scenario may not apply to > existing INFO usages, but since the draft takes the burden > of discussing how to refresh Info packages, it implies > that there is a lifetime to these packages. Ergo, it should > also cover the case where such refreshes are not done > (I realize I am being a pedantic protocol designer here, > so I will shut up if the WG feels that this is a moot point. > An easy way to handle this would be to state simply that if > no mid-dialog requests arrive to refresh the Info package > state, then the state is simply maintained until the normal > termination of the dialog.) Perhaps the term "refresh" should not be applied to info packages. Perhaps a different term, such as "revise" would be better. I've harped for a long time that the lifetime is poorly defined for many of the things we negotiate. Here we have the opportunity to be clear. Having said that, and in light of your comments, I think we may be talking about two things: 1) the state that consists of the info packages that have been negotiated to be usable on the current dialog. 2) the state of *something* that is negotiated by the exchange of some particular info messages. For (1), IMO the negotiated state should remain in effect for the dialog until and unless changed by some additional signaling exchange. In particular, I think each reINVITE or UPDATE has the opportunity to change this, and should probably start out with a clean slate, except that the last agreement remains in effect until the new one is fully negotiated. This can however be tricky to nail down. (Witness all the issues around rollback of O/A. Lets not repeat that fiasco.) For (2), I think that the rules must be be defined when some new negotiation is specified to use INFO as its transport. I don't see anything we should necessarily define as part of the general info package mechanism. There is an interesting case that might be worth discussing: Suppose Info package P is negotiated. Then exchanging messages of type P, some state is agreed upon between UAC and UAS. And assume that it is intended to remain in effect within the dialog until changed by another exchange of messages of type P. Then suppose that a reINVITE or UPDATE removes the agreement to use Info package P. Does the agreement previously established remain in effect even though there is no longer any way to revoke it? I guess my thought on that is that it is up to the designers of package P to specify what happens in this case. But they had better be careful about it. >> Any time you do a 3pcc transfer, one side things their dialog is >> preserved, while on the other side there have been two distinct >> dialogs. If the first of those supported the info pkg, but the 2nd >> does not, then you need a way to renegotiate. > > I am not sure I follow, can you please elucidate... OK. Lets take the usual 3pcc use case: |-------- C | A -------- B | |-------- D Here A, C, and D are UAs, and B is a B2BUA. Initially A sends an INVITE which is received by B, who sends a corresponding INVITE to C. The AB and BC dialogs are coordinated by B so that it seems that A has a session with C. During that setup, A includes Recv-Info:P, as does C in its response. A and C the proceed to exchange Info packages of type P. At some point, B decides that the "call" should be transferred to D. This can be for a lot of reasons. In order to preserve consistency, B sends an offerless invite to A. And I think it is probably also Recv-Info-less. Lets assume for now that A immediately sends a 200 response, with offer, and with Recv-Info including P. B then uses that to send an INVITE to D. But D does not support info package P, so it doesn't include that in its Recv-Info. We need to end up in a situation where A knows that info package P cannot be used. >> Well, since the poster child has always been DTMF, that is something >> that is frequently desired in early dialogs. > > Ah, enough said ;-) I think it will do some good in the draft > if the reason for an early INFO message (namely, DTMF) is > mentioned there (suggested text below.) > >> Once again I think DTMF gives an example. >> You might need to send it during early dialog, and in conjunction with >> forking you then may be exchanging them on multiple early dialogs. > > Hmmm ... okay; I can buy that. It will be good to just put > down some text that gives the reason for supporting multiple > INFO requests as a side-effect of forking. Something along > these lines: I agree with your points above. > OLD: > > The converse is not true during initial session establishment. The > initiating UA of the first INVITE MUST be prepared to receive > multiple INFO requests, as the first INVITE may fork. Since dialog > negotiation has not completed, and we allow early INFO requests, > multiple target UAs may respond. This initial dialog establishment > phase is the only time the UAS need be prepared to receive multiple > INFO requests, as we require post-session-establishment negotiation > to fully complete before a UAC can send an INFO request. > > NEW: > > The converse is not true during initial session establishment. The > initiating UA of the first INVITE MUST be prepared to receive > multiple INFO requests, as the first INVITE may fork. Since dialog > negotiation has not completed, and we allow early INFO requests, > multiple target UAs may respond. > > When an INVITE forks and reaches multiple targets, these > targets may want to interact with the initiator of the > INVITE for some services, DTMF being the canonical one. > The complexity of early INFO requests is thus needed > to handle such interactions. > > The initial dialog establishment phase is the only time > the UAC need be prepared to receive multiple INFO requests, > as we require post-session-establishment negotiation to > fully complete before a UAC can send an INFO request. The above isn't working for me. What I think is lacking, and something that seems confusing to people on a regular basis, is clarity on the point that the multiplicity is due to multiple dialogs. As long as you consider things from the point of view of an individual dialog, there is nothing special here. Also, I don't think the paragraph is the converse of anything stated previously. So, how about: NEW: While INFO cannot fork, an initial INVITE may fork, resulting in multiple early and/or full dialogs. A UA must be prepared to receive INFO requests over each dialog resulting from an INVITE it has sent. Thanks, Paul From vkg@alcatel-lucent.com Mon Jun 8 10:09:17 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEDFA3A695E for ; Mon, 8 Jun 2009 10:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbq3j0zBA0RV for ; Mon, 8 Jun 2009 10:09:16 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id CACDB3A687B for ; Mon, 8 Jun 2009 10:09:16 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id n58H9JmE023532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 12:09:19 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n58H9IP7020935; Mon, 8 Jun 2009 12:09:18 -0500 (CDT) Message-ID: <4A2D45BE.60208@alcatel-lucent.com> Date: Mon, 08 Jun 2009 12:09:18 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Paul Kyzivat References: <4A2B3F73.6080704@alcatel-lucent.com> <4A2C8606.7030302@cisco.com> <4A2D312C.90804@alcatel-lucent.com> <4A2D3F63.3070109@cisco.com> In-Reply-To: <4A2D3F63.3070109@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: sipcore@ietf.org Subject: Re: [sipcore] Review of draft-ietf-sip-info-events-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 17:09:17 -0000 Paul Kyzivat wrote: > Perhaps the term "refresh" should not be applied to info packages. > Perhaps a different term, such as "revise" would be better. > > I've harped for a long time that the lifetime is poorly defined for many > of the things we negotiate. Here we have the opportunity to be clear. Agreed; I think that the authors of the draft should spend some time thinking through the issue of Info package lifetime and impacts on refreshing/revising it. The discussion captured in this email thread can help frame the text in the draft, especially the different states that can be instantiated in the communicating peers, as you describe below: > Having said that, and in light of your comments, I think we may be > talking about two things: > > 1) the state that consists of the info packages that have been > negotiated to be usable on the current dialog. > > 2) the state of *something* that is negotiated by the exchange of > some particular info messages. Complicating the issue of lifetimes is the 3pcc case you describe below (your comment makes sense to me now, with an example you provided.) Obviously, the motivation of expiring an Info package if the dialog refresh did not include a Recv-Info header makes sense in the context of the 3pcc example you gave. Without that context, it did not make sense. The authors, from an editorial point of view, may want to justify the reason why Info packages expire if the dialog refresh reveals that one side does not support Recv-Info. I realize that they cannot simply give examples each time they describe behavior, but when describing a rather complex behavior that an implementation must support, it may be well worth to buttress the behavior with an example. [...] >>> Any time you do a 3pcc transfer, one side things their dialog is >>> preserved, while on the other side there have been two distinct >>> dialogs. If the first of those supported the info pkg, but the 2nd >>> does not, then you need a way to renegotiate. >> >> I am not sure I follow, can you please elucidate... > > OK. Lets take the usual 3pcc use case: [...] OK; I see your point. > The above isn't working for me. > > [...]So, how about: > > NEW: > > While INFO cannot fork, an initial INVITE may fork, resulting in > multiple early and/or full dialogs. A UA must be prepared to receive > INFO requests over each dialog resulting from an INVITE it has sent. This works for me. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From dworley@nortel.com Mon Jun 8 13:39:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39BC028C148 for ; Mon, 8 Jun 2009 13:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.799 X-Spam-Level: X-Spam-Status: No, score=-6.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8hCBfenSRpN for ; Mon, 8 Jun 2009 13:39:57 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 9C70A28C167 for ; Mon, 8 Jun 2009 13:39:35 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n58KcIs05747; Mon, 8 Jun 2009 20:38:18 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Jun 2009 16:39:34 -0400 From: "Dale Worley" To: Dean Willis In-Reply-To: <8DCBAE37-E805-43CD-9805-576A1E69FC7F@softarmor.com> References: <4A286319.4010902@cisco.com> <6B8A59AF-FB35-42E8-B3D7-EF6206C0A65D@softarmor.com> <1244251766.4158.21.camel@victoria-pingtel-com.us.nortel.com> <8DCBAE37-E805-43CD-9805-576A1E69FC7F@softarmor.com> Content-Type: text/plain Organization: Nortel Networks Date: Mon, 08 Jun 2009 16:39:34 -0400 Message-Id: <1244493574.3741.75.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2009 20:39:34.0544 (UTC) FILETIME=[3B9A8900:01C9E879] Cc: "Cahall, Glenn" , "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 20:39:58 -0000 On Sat, 2009-06-06 at 13:33 -0500, Dean Willis wrote: > > I think one can safely change the request-URI when retrying, and in > > some > > cases, one may need to to fix the problem. As far as I know, nobody > > uses the request-URI for any kind of transaction or dialog matching > > (and > > they surely should not). > > I'd argue it's a new transaction, not a retry, if the R-URI changes. I would argue that it depends on the semantics of the situation. But more importantly, a downstream element can't tell whether the UAC changed its request-URI, since the request-URI may have been changed by an intermediate proxy. But a downstream element can tell if the from-tag was changed by the UAC, since proxies don't change the from-tag. Dale From hisham.khartabil@gmail.com Mon Jun 8 17:04:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467C13A6C08 for ; Mon, 8 Jun 2009 17:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30Zs8RXPlTzt for ; Mon, 8 Jun 2009 17:04:57 -0700 (PDT) Received: from mail-pz0-f181.google.com (mail-pz0-f181.google.com [209.85.222.181]) by core3.amsl.com (Postfix) with ESMTP id 5DAE83A63CB for ; Mon, 8 Jun 2009 17:04:57 -0700 (PDT) Received: by pzk11 with SMTP id 11so638181pzk.29 for ; Mon, 08 Jun 2009 17:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lf4DImK8pyLdzBMgE1cHNRgsnVxhLFdzvmHwuiFEkzQ=; b=AufY0ipg4tKBIPpfClPCLsZUDrM98fsnTI6wTwrlj4XHymNAtBWBQvQWUIXlsF/LL4 i30bKM8Cd15OidEytevOUZt0eRWG4T+czlqS2Ig8cp4rQwcJ2RXvOQQ4d7pz7KBAETQW C8xrFNAwukum2LD01tX+cbdth33yx1qwuQglU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pHidrCt+GwrvlctDlC6JLmhoLX4MBRDHOzK9HLPAVcZ2vWFpBV8Puwg9AS5AL4Pq1s he89XAoZjSY9oCoNQU8z2SpPN2K9aWyKmEs2mj4m4iqwuW9fEdlKbpeah0deUWiYQKp2 0NEvkBAZOCC3hG/4eYtckntDQa/ItyVW7iUmA= MIME-Version: 1.0 Received: by 10.142.102.10 with SMTP id z10mr2573210wfb.260.1244505900761; Mon, 08 Jun 2009 17:05:00 -0700 (PDT) In-Reply-To: <6B8A59AF-FB35-42E8-B3D7-EF6206C0A65D@softarmor.com> References: <4A286319.4010902@cisco.com> <6B8A59AF-FB35-42E8-B3D7-EF6206C0A65D@softarmor.com> Date: Tue, 9 Jun 2009 10:05:00 +1000 Message-ID: <66cd252f0906081705o4eec7e15p76c630caaebd357f@mail.gmail.com> From: Hisham Khartabil To: Dean Willis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Cahall, Glenn" , "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 00:04:58 -0000 The via branch is used to match transactions. The state machine doesnt care about call-id or tags when matching transactions (if it is RFC3261 compliant that is). So a question to Glenn. Is the branch also the same? The transaction layer will pass the request to the UAS Core if there is no match in the transaction (branch in top via header). In that case, the core will not find a dialog match (since it rejected the original request) and will process the new request as a new request. Hisham 2009/6/6 Dean Willis : > > On Jun 5, 2009, at 10:18 AM, Cahall, Glenn wrote: > >> Paul, >> >> Thanks for the response. >> >> Once I read your response, I felt that I needed to explain the situation >> in more detail. >> >> Customer is sending us an INVITE, our response is a 486 BUSY. =A0This ex= act >> scenario (all with same TNs) repeats itself 100+ times over the next 90 >> seconds or so. =A0All 100+ INVITEs contain the same Call-Id. =A0However,= tag >> value in the From field is different. >> >> So....now that you know more about the situation....is this in violation >> of the RFC? >> >> Also, during our discussions on the topic, we argued whether or not >> Call-Id could be reused. =A0In short, as stated before, even if the init= ial >> call was successful, they believed that as soon as that call was complet= ed, >> they were free to use the exact same Call-Id on the very next call. > > > > The From: tag SHOULD be invariant if the Call-ID is re-used in response t= o a > 4xx, else the transaction won't match. And the CSeq SHOULD increase, sinc= e > it is a new INVITE. This is specified in paragraph 6 of section 8.1.4.5 i= n > RFC 3261. In practice, state matching fails if this isn't honored, so it > really could have been specified as a MUST; that is, we should probably > rewrite RFC 3261 to say something like: > > "The UAC MAY retry a transaction following certain 400-class responses, I= f > the UAC retries such a transaction, it MUST retain the To, From, Call-ID = and > Request-URI of the original transaction, and MUST increment the CSeq. > Failure to observe these two operational requirements is likely to result= in > proxies or the UAS not matching the retried transaction to any retained > state from previous transactions, which could result in errors ranging fr= om > erroneous log entries to denial-of-service scenarios, and it is in extrem= ely > poor taste too." > > In other words, the tag should be the same, the CSeq should increment, an= d > you spank the customer =A0for being annoying. > > Failing that, how's the Retry-After: header field on your 486 populated? > Perhaps you could crank it up to about 60 seconds, THEN spank them for be= ing > annoying it if they ignore it. > > -- > Dean > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From tanguy@ortolo.eu Mon Jun 8 03:10:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49C653A6DE4 for ; Mon, 8 Jun 2009 03:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4txYVaYIUyz7 for ; Mon, 8 Jun 2009 03:10:02 -0700 (PDT) Received: from verne.ortolo.eu (verne.ortolo.eu [IPv6:2001:41d0:1:d1a4::12]) by core3.amsl.com (Postfix) with ESMTP id 6B4BB3A6DED for ; Mon, 8 Jun 2009 03:10:00 -0700 (PDT) Received: by verne.ortolo.eu (Postfix, from userid 1000) id DD6C9E84C; Mon, 8 Jun 2009 12:10:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ortolo.eu; s=default; t=1244455802; bh=fI9eXE45f0aB092ekFKLXwHNGnpYcRwa0wgWRdRg86w=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=Mw63 NrgAncMLbhXhzAlLTAJTcsy2srEtCTqg2+Cn37dBP++hwdQnJ3l9mi8BalZ6NmVFB4j kgmEBOjNs605bE1XD5PugXHkZDvMZJkQnxavcCi86o8ZBGMa1CmEauRwxS87e+lVIZH W/RreVbNJZEe6g/yszqDli1D2Q+fnI/YM= Date: Mon, 8 Jun 2009 12:10:02 +0200 From: Tanguy Ortolo To: SIP core working group Message-ID: <20090608101002.GA9059@ortolo.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Mon, 08 Jun 2009 21:09:11 -0700 Subject: [sipcore] HTTP Basic deprecation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 10:11:14 -0000 Hello, Documenting myself to set up a personal telephony service, I found that SIP authentication requires the use of HTTP Digest, and deprecates HTTP Basic because of its weaknesses. I suppose these weaknesses are the possible cleartext transmission of the password, and the possibility to replay an authentication. These issues can be addressed by using an external encryption, such as TLS. With HTTP Digest, these problems no more exist, as it is challenge-response and nonce-based. But it introduces two side-effects: - the passwords need to be stored in clear (or, at least, the HA1, which knowing is sufficient to authenticate, and that actually /replaces/ the password); - it forbids the use of some generic authentication managers, such as PAM, that requires the cleartext password, in particular to check it against a secured hashed password database. Ideally, for my personal services, I prefer to use PAM as a single authentication manager with a secure storage: for SIP, I know I cannot do so, right now. But are there solutions to avoid HTTP Digest issues, or to reintroduce HTTP Basic (over TLS) in future SIP improvements? Regards, -- Tanguy Ortolo From theo@crazygreek.co.uk Mon Jun 8 21:28:37 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84FA53A68F4 for ; Mon, 8 Jun 2009 21:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUwAfdHna8iI for ; Mon, 8 Jun 2009 21:28:36 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by core3.amsl.com (Postfix) with SMTP id 63DA93A6768 for ; Mon, 8 Jun 2009 21:28:36 -0700 (PDT) Received: from source ([72.14.220.154]) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKSi3k+c7BFn65prssHRp3NmGOND2qwPlT@postini.com; Mon, 08 Jun 2009 21:28:42 PDT Received: by fg-out-1718.google.com with SMTP id e12so1543820fga.10 for ; Mon, 08 Jun 2009 21:28:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.59.18 with SMTP id h18mr7925962fga.71.1244521721275; Mon, 08 Jun 2009 21:28:41 -0700 (PDT) In-Reply-To: <20090608101002.GA9059@ortolo.eu> References: <20090608101002.GA9059@ortolo.eu> From: Theo Zourzouvillys Date: Tue, 9 Jun 2009 05:28:21 +0100 Message-ID: <167dfb9b0906082128t31c0e172g906f4cb103024a2e@mail.gmail.com> To: Tanguy Ortolo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIP core working group Subject: Re: [sipcore] HTTP Basic deprecation X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 04:28:37 -0000 On Mon, Jun 8, 2009 at 11:10 AM, Tanguy Ortolo wrote: > But are there solutions to avoid HTTP Digest issues, > or to reintroduce HTTP Basic (over TLS) in future SIP improvements? There are a number of solutions available, none of which involve sending plain text passwords over the wire :) If you're trying to authenticate directly attached clients, i.e an outbound proxy service, then mutual TLS is the way forward. If you're trying to provide a service to non directly connected clients, but want to be able to identify them, take a look at Identity (rfc4474), or it's trusted network cousin P-Asserted-Identity. ~ Theo From adam@nostrum.com Mon Jun 8 21:32:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0654F3A6768 for ; Mon, 8 Jun 2009 21:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kipz4hKrX-2U for ; Mon, 8 Jun 2009 21:32:48 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A21E73A6AEB for ; Mon, 8 Jun 2009 21:32:47 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-101.dsl.rcsntx.swbell.net [70.249.149.101]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n594Wnww062617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 23:32:49 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A2DE5F1.3030602@nostrum.com> Date: Mon, 08 Jun 2009 23:32:49 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Hisham Khartabil References: <4A286319.4010902@cisco.com> <6B8A59AF-FB35-42E8-B3D7-EF6206C0A65D@softarmor.com> <66cd252f0906081705o4eec7e15p76c630caaebd357f@mail.gmail.com> In-Reply-To: <66cd252f0906081705o4eec7e15p76c630caaebd357f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.149.101 is authenticated by a trusted mechanism) Cc: "Cahall, Glenn" , "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 04:32:49 -0000 [as an individual] This is an excellent example of where Postel's Maxim would address the problem. (For the unaware, Postel's Maxim is "be conservative in what you do, be liberal in what you accept from others"). For the failure Glenn is describing, it takes the efforts of two misbehaving systems to cause a failure. There is nothing in RFC3261 that normatively assigns semantics to a Call-ID by itself. It is meaningful only when combined with other identifiers, such as To: and From: tags. If you have software that is failing when it sees duplicate Call-IDs, then that is a bug that should be resolved. However, this misbehavior wouldn't happen if the sending party were a bit more conservative in what it sent -- if it were more vigorous in generating new Call-IDs for new attempts. If we're seeing real-life failures due to this behavior, I'd say both sides are at fault. It takes two to dance this "Failure Tango". /a Hisham Khartabil wrote: > The via branch is used to match transactions. The state machine doesnt > care about call-id or tags when matching transactions (if it is > RFC3261 compliant that is). So a question to Glenn. Is the branch also > the same? > > The transaction layer will pass the request to the UAS Core if there > is no match in the transaction (branch in top via header). In that > case, the core will not find a dialog match (since it rejected the > original request) and will process the new request as a new request. > > Hisham > > 2009/6/6 Dean Willis : > >> On Jun 5, 2009, at 10:18 AM, Cahall, Glenn wrote: >> >> >>> Paul, >>> >>> Thanks for the response. >>> >>> Once I read your response, I felt that I needed to explain the situation >>> in more detail. >>> >>> Customer is sending us an INVITE, our response is a 486 BUSY. This exact >>> scenario (all with same TNs) repeats itself 100+ times over the next 90 >>> seconds or so. All 100+ INVITEs contain the same Call-Id. However, tag >>> value in the From field is different. >>> >>> So....now that you know more about the situation....is this in violation >>> of the RFC? >>> >>> Also, during our discussions on the topic, we argued whether or not >>> Call-Id could be reused. In short, as stated before, even if the initial >>> call was successful, they believed that as soon as that call was completed, >>> they were free to use the exact same Call-Id on the very next call. >>> >> >> The From: tag SHOULD be invariant if the Call-ID is re-used in response to a >> 4xx, else the transaction won't match. And the CSeq SHOULD increase, since >> it is a new INVITE. This is specified in paragraph 6 of section 8.1.4.5 in >> RFC 3261. In practice, state matching fails if this isn't honored, so it >> really could have been specified as a MUST; that is, we should probably >> rewrite RFC 3261 to say something like: >> >> "The UAC MAY retry a transaction following certain 400-class responses, If >> the UAC retries such a transaction, it MUST retain the To, From, Call-ID and >> Request-URI of the original transaction, and MUST increment the CSeq. >> Failure to observe these two operational requirements is likely to result in >> proxies or the UAS not matching the retried transaction to any retained >> state from previous transactions, which could result in errors ranging from >> erroneous log entries to denial-of-service scenarios, and it is in extremely >> poor taste too." >> >> In other words, the tag should be the same, the CSeq should increment, and >> you spank the customer for being annoying. >> >> Failing that, how's the Retry-After: header field on your 486 populated? >> Perhaps you could crank it up to about 60 seconds, THEN spank them for being >> annoying it if they ignore it. >> >> -- >> Dean >> >> >> >> _______________________________________________ >> 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 dean.willis@softarmor.com Tue Jun 9 01:18:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF4CD28C16B for ; Tue, 9 Jun 2009 01:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2wndGlVJ8gY for ; Tue, 9 Jun 2009 01:18:25 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id B4B5E3A6912 for ; Tue, 9 Jun 2009 01:18:25 -0700 (PDT) Received: from [192.168.2.102] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n598IRcd027526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Jun 2009 03:18:29 -0500 Message-ID: <4A2E1ACD.5040608@softarmor.com> Date: Tue, 09 Jun 2009 03:18:21 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Penfield References: <4A286319.4010902@cisco.com> <6B8A59AF-FB35-42E8-B3D7-EF6206C0A65D@softarmor.com> <1244251766.4158.21.camel@victoria-pingtel-com.us.nortel.com> <8DCBAE37-E805-43CD-9805-576A1E69FC7F@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Cahall, Glenn" , "sipcore@ietf.org" , Dale Worley Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 08:18:26 -0000 Bob Penfield wrote: > > > >>-----Original Message----- >>From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis >>Sent: Saturday, June 06, 2009 2:33 PM >>To: Dale Worley >>Cc: Cahall, Glenn; sipcore@ietf.org >>Subject: Re: [sipcore] Reuse of Sip Call-Id question.. >> >> >>On Jun 5, 2009, at 8:29 PM, Dale Worley wrote: >> >> >>>On Fri, 2009-06-05 at 19:13 -0500, Dean Willis wrote: >>> >>>>"The UAC MAY retry a transaction following certain 400-class >>>>responses, If the UAC retries such a transaction, it MUST retain the >>>>To, From, Call-ID and Request-URI of the original transaction, and >>>>MUST increment the CSeq. Failure to observe these two operational >>>>requirements is likely to result in proxies or the UAS not matching >>>>the retried transaction to any retained state from previous >>>>transactions, which could result in errors ranging from erroneous log >>>>entries to denial-of-service scenarios, and it is in extremely poor >>>>taste too." >>> >>>I think one can safely change the request-URI when retrying, and in >>>some >>>cases, one may need to to fix the problem. As far as I know, nobody >>>uses the request-URI for any kind of transaction or dialog matching >>>(and >>>they surely should not). >> >>I'd argue it's a new transaction, not a retry, if the R-URI changes. > > > In section 8.1.3.5 of 3261 it does give one case where the Request-URI would change: > > If a 416 (Unsupported URI Scheme) response is received (Section > 21.4.14), the Request-URI used a URI scheme not supported by the > server. The client SHOULD retry the request, this time, using a SIP > URI. > > And just to be picky, I think you meant "new session" rather than "new transaction". A retry is a new transaction :) You are most pickily correct. I'm not sure I believe that the 8.1.3.5 you quote above is right, or at least it isn't cocnsistent with what I think by "retry". It seems likely that something along the line might get weird if we re-use the call-ID with the new request-URI. I'm pretty sure call-ID based CDR aggregation systems that I remember speccing at a carrier or two would melt-down. -- Dean -- Dean From pkyzivat@cisco.com Tue Jun 9 06:08:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49E0228C19F for ; Tue, 9 Jun 2009 06:08:56 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JT1XuSKfUKWc for ; Tue, 9 Jun 2009 06:08:55 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4A26D3A6C8A for ; Tue, 9 Jun 2009 06:08:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,331,1241395200"; d="scan'208";a="196849743" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 09 Jun 2009 13:09:01 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n59D9193004080; Tue, 9 Jun 2009 06:09:01 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n59D8qcr007675; Tue, 9 Jun 2009 13:09:01 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 09:08:54 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 09:08:53 -0400 Message-ID: <4A2E5EE5.9070601@cisco.com> Date: Tue, 09 Jun 2009 09:08:53 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Adam Roach References: <4A286319.4010902@cisco.com> <6B8A59AF-FB35-42E8-B3D7-EF6206C0A65D@softarmor.com> <66cd252f0906081705o4eec7e15p76c630caaebd357f@mail.gmail.com> <4A2DE5F1.3030602@nostrum.com> In-Reply-To: <4A2DE5F1.3030602@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2009 13:08:53.0721 (UTC) FILETIME=[706E2490:01C9E903] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5282; t=1244552941; x=1245416941; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Reuse=20of=20Sip=20Call-Id= 20question.. |Sender:=20; bh=w9VOeRVU49ljPDsZ2LyapzU8pHWFpUyNMynGVBEOBgo=; b=b7/TJ+O5YoJizdzs5QfggiBPdoLnNwSbQt9VCsjusIQm3oAxokEH7f4eBA l6LI/5vT/qZiBTGBn3cILe+q3+pvuSF39Mw+BMoR6qbXQ7R3S9qPZo6VPk0D DVixhBKb0q; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: "Cahall, Glenn" , "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 13:08:56 -0000 Adam, I will agree with you on this one. Yet I want to emphasize the need for conservatism on the originating side. I have repeatedly seen cases where somebody says on of: - I can reuse the same callid because the from and to tags will make the dialog id unique - I can reuse the same from tag because the callid and to tag will make the dialog id unique - I can reuse the same to tag because the callid and from tag will make the dialog id unique Of course nobody agrees on which ones really must be unique. When you reason this way you are betting that everybody else involved has made compatible assumptions to the one you are making. Thanks, Paul Adam Roach wrote: > [as an individual] > > This is an excellent example of where Postel's Maxim would address the > problem. (For the unaware, Postel's Maxim is "be conservative in what > you do, be liberal in what you accept from others"). For the failure > Glenn is describing, it takes the efforts of two misbehaving systems to > cause a failure. > > There is nothing in RFC3261 that normatively assigns semantics to a > Call-ID by itself. It is meaningful only when combined with other > identifiers, such as To: and From: tags. If you have software that is > failing when it sees duplicate Call-IDs, then that is a bug that should > be resolved. > > However, this misbehavior wouldn't happen if the sending party were a > bit more conservative in what it sent -- if it were more vigorous in > generating new Call-IDs for new attempts. > > If we're seeing real-life failures due to this behavior, I'd say both > sides are at fault. It takes two to dance this "Failure Tango". > > /a > > > Hisham Khartabil wrote: >> The via branch is used to match transactions. The state machine doesnt >> care about call-id or tags when matching transactions (if it is >> RFC3261 compliant that is). So a question to Glenn. Is the branch also >> the same? >> >> The transaction layer will pass the request to the UAS Core if there >> is no match in the transaction (branch in top via header). In that >> case, the core will not find a dialog match (since it rejected the >> original request) and will process the new request as a new request. >> >> Hisham >> >> 2009/6/6 Dean Willis : >> >>> On Jun 5, 2009, at 10:18 AM, Cahall, Glenn wrote: >>> >>> >>>> Paul, >>>> >>>> Thanks for the response. >>>> >>>> Once I read your response, I felt that I needed to explain the >>>> situation >>>> in more detail. >>>> >>>> Customer is sending us an INVITE, our response is a 486 BUSY. This >>>> exact >>>> scenario (all with same TNs) repeats itself 100+ times over the next 90 >>>> seconds or so. All 100+ INVITEs contain the same Call-Id. However, >>>> tag >>>> value in the From field is different. >>>> >>>> So....now that you know more about the situation....is this in >>>> violation >>>> of the RFC? >>>> >>>> Also, during our discussions on the topic, we argued whether or not >>>> Call-Id could be reused. In short, as stated before, even if the >>>> initial >>>> call was successful, they believed that as soon as that call was >>>> completed, >>>> they were free to use the exact same Call-Id on the very next call. >>>> >>> >>> The From: tag SHOULD be invariant if the Call-ID is re-used in >>> response to a >>> 4xx, else the transaction won't match. And the CSeq SHOULD increase, >>> since >>> it is a new INVITE. This is specified in paragraph 6 of section >>> 8.1.4.5 in >>> RFC 3261. In practice, state matching fails if this isn't honored, so it >>> really could have been specified as a MUST; that is, we should probably >>> rewrite RFC 3261 to say something like: >>> >>> "The UAC MAY retry a transaction following certain 400-class >>> responses, If >>> the UAC retries such a transaction, it MUST retain the To, From, >>> Call-ID and >>> Request-URI of the original transaction, and MUST increment the CSeq. >>> Failure to observe these two operational requirements is likely to >>> result in >>> proxies or the UAS not matching the retried transaction to any retained >>> state from previous transactions, which could result in errors >>> ranging from >>> erroneous log entries to denial-of-service scenarios, and it is in >>> extremely >>> poor taste too." >>> >>> In other words, the tag should be the same, the CSeq should >>> increment, and >>> you spank the customer for being annoying. >>> >>> Failing that, how's the Retry-After: header field on your 486 populated? >>> Perhaps you could crank it up to about 60 seconds, THEN spank them >>> for being >>> annoying it if they ignore it. >>> >>> -- >>> Dean >>> >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From dean.willis@softarmor.com Tue Jun 9 10:33:37 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3353A6D3F for ; Tue, 9 Jun 2009 10:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAAOLBSumgHS for ; Tue, 9 Jun 2009 10:33:36 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 958E13A6BD6 for ; Tue, 9 Jun 2009 10:33:36 -0700 (PDT) Received: from [192.168.2.2] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n59HXbR2031617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 9 Jun 2009 12:33:39 -0500 Message-ID: <4A2E9CEC.9020602@softarmor.com> Date: Tue, 09 Jun 2009 12:33:32 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Adam Roach References: <4A286319.4010902@cisco.com> <6B8A59AF-FB35-42E8-B3D7-EF6206C0A65D@softarmor.com> <66cd252f0906081705o4eec7e15p76c630caaebd357f@mail.gmail.com> <4A2DE5F1.3030602@nostrum.com> In-Reply-To: <4A2DE5F1.3030602@nostrum.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Cahall, Glenn" , "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 17:33:37 -0000 > If we're seeing real-life failures due to this behavior, I'd say both > sides are at fault. It takes two to dance this "Failure Tango". Although the real "dance beat" of the failure tango in Glenn's case is the rhythm of the UAS resending the failed request 100 times in rapid succession. All questions of protocol specification aside, that's just plain rude. -- Dean From pkyzivat@cisco.com Tue Jun 9 11:05:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EF203A6C9B for ; Tue, 9 Jun 2009 11:05:19 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaGsXJ7O-kjG for ; Tue, 9 Jun 2009 11:05:18 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 8D39C3A6C70 for ; Tue, 9 Jun 2009 11:05:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,334,1241395200"; d="scan'208";a="197011256" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 09 Jun 2009 18:05:24 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n59I5OPF013346; Tue, 9 Jun 2009 11:05:24 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n59I5AAG015206; Tue, 9 Jun 2009 18:05:24 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 14:05:23 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 14:05:22 -0400 Message-ID: <4A2EA45F.7010109@cisco.com> Date: Tue, 09 Jun 2009 14:05:19 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dean Willis References: <4A286319.4010902@cisco.com> <6B8A59AF-FB35-42E8-B3D7-EF6206C0A65D@softarmor.com> <66cd252f0906081705o4eec7e15p76c630caaebd357f@mail.gmail.com> <4A2DE5F1.3030602@nostrum.com> <4A2E9CEC.9020602@softarmor.com> In-Reply-To: <4A2E9CEC.9020602@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2009 18:05:22.0730 (UTC) FILETIME=[DB8180A0:01C9E92C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=674; t=1244570724; x=1245434724; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Reuse=20of=20Sip=20Call-Id= 20question.. |Sender:=20; bh=nGI5nclJzMS4Y7Wjefbe1uWgCtZzsi3TWEK1BPxsLF4=; b=La86KZHtVg6+SxJqrpxVczUzyuIitWPna5hkWL6EMpj0IpQmJdqJewbS3p AJl93gJ0cSpUQpnC/2Xc0xpHlezBUSUnuo6BZIRmibz/ANr5zXIwBttKYjbk Gq8hr0W535; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: "Cahall, Glenn" , "sipcore@ietf.org" Subject: Re: [sipcore] Reuse of Sip Call-Id question.. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 18:05:19 -0000 Depends on your perspective. It might be the UAS that is rude by continuing to be busy. :-) Paul Dean Willis wrote: >> If we're seeing real-life failures due to this behavior, I'd say both >> sides are at fault. It takes two to dance this "Failure Tango". > > Although the real "dance beat" of the failure tango in Glenn's case is > the rhythm of the UAS resending the failed request 100 times in rapid > succession. All questions of protocol specification aside, that's just > plain rude. > > -- > Dean > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From rjsparks@nostrum.com Tue Jun 9 11:51:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79F253A6D64 for ; Tue, 9 Jun 2009 11:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qX8+NhUmp2+p for ; Tue, 9 Jun 2009 11:51:33 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6316A3A6D59 for ; Tue, 9 Jun 2009 11:51:33 -0700 (PDT) Received: from dn3-232.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 n59IpKk7091418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Jun 2009 13:51:21 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: sipcore@ietf.org, Aki Niemi , Dean Willis , Adam Roach Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 9 Jun 2009 13:51:20 -0500 X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] AD review: draft-ietf-sipcore-subnot-etags-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 18:51:34 -0000 This document is ready for IETF LC - watch for the announcement of such shortly. Some comments that we can address as part of that last call: 1) Page 14: "subscriber can clear handle" isn't clear to me. Should this say "subscriber can release state"? 2) Page 15: The second paragraph of section 5.3 might need clarification. It says: "The subscriber MUST NOT infer any meaning from the value of an entity-tag; specifically, the subscriber MUST NOT assume identical entities (i.e. event state) for NOTIFYs with identical entity-tag values." That could be read to mean that a given notifier might assign tag E1 to state "foo" at one point in time, and assign tag E2 to it at some other point in time. I suspect this was intended to capture the warning that different notifiers might generate different tags for the same state, and that after receiving E1->"foo" from notifier 1, the subscriber MUST NOT assume E1 from notifier 2 means "foo". 3) Page 21, section 6.3, 3rd paragraph. I suggest adding "following the procedures in RFC3265" to the end of "A successful conditional SUBSCRIBE request MUST extend the subscription expiry time." to avoid implementer arguments about whether honoring an Expires header field value that actually makes the remaining subscription time _shorter_ (such as Expires: 0), "extends" the subscription expiry time. RjS From wwwrun@core3.amsl.com Tue Jun 9 11:58:48 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7E07F3A6D21; Tue, 9 Jun 2009 11:58:48 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090609185848.7E07F3A6D21@core3.amsl.com> Date: Tue, 9 Jun 2009 11:58:48 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] Last Call: draft-ietf-sipcore-subnot-etags (An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 18:58:48 -0000 The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-06-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sipcore-subnot-etags-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18505&rfc_flag=0 From dworley@nortel.com Wed Jun 10 12:12:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 799383A68C3 for ; Wed, 10 Jun 2009 12:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.766 X-Spam-Level: X-Spam-Status: No, score=-6.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltotpvX2+nhq for ; Wed, 10 Jun 2009 12:12:18 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 844AF3A6855 for ; Wed, 10 Jun 2009 12:12:18 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5AJCKZ03241; Wed, 10 Jun 2009 19:12:20 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 15:12:04 -0400 From: "Dale Worley" To: Paul Kyzivat In-Reply-To: <1244232151.3786.70.camel@victoria-pingtel-com.us.nortel.com> References: <1240958114.18691.54.camel@victoria-pingtel-com.us.nortel.com> <4A1C4C45.90204@nostrum.com> <1244143850.3743.62.camel@victoria-pingtel-com.us.nortel.com> <4A282D39.2090401@cisco.com> <1244232151.3786.70.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 10 Jun 2009 15:12:04 -0400 Message-Id: <1244661124.3769.93.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jun 2009 19:12:04.0997 (UTC) FILETIME=[5774BB50:01C9E9FF] Cc: SIPCORE Subject: Re: [sipcore] Comments on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 19:12:19 -0000 On Fri, 2009-06-05 at 16:02 -0400, Dale Worley wrote: > > But the no-reduce rule has its own trouble. In particular my usual > > source of exceptions to everything: 3pcc. The subscriber may think he is > > continuing a single subscription. But a middle box may be moving a > > subscription from one UAS to another. The new target may not be willing > > to support such a long subscription, and so may have need to reduce it. > > That's an annoyingly realistic problem. In this situation, can we demand that the middle box terminate the subscription (rather than shorten it), with the expectation that the subscriber will create a new subscription? (In terms of message traffic, there is little additional load.) Dale From pkyzivat@cisco.com Wed Jun 10 13:16:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C10363A67B2 for ; Wed, 10 Jun 2009 13:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tR30iSVOogV3 for ; Wed, 10 Jun 2009 13:16:40 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1A7F63A6A59 for ; Wed, 10 Jun 2009 13:16:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,197,1243814400"; d="scan'208";a="46862095" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 10 Jun 2009 20:16:46 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5AKGkmi004852; Wed, 10 Jun 2009 16:16:46 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5AKGkkN015032; Wed, 10 Jun 2009 20:16:46 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 16:16:45 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 16:16:45 -0400 Message-ID: <4A3014AD.6090906@cisco.com> Date: Wed, 10 Jun 2009 16:16:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dale Worley References: <1240958114.18691.54.camel@victoria-pingtel-com.us.nortel.com> <4A1C4C45.90204@nostrum.com> <1244143850.3743.62.camel@victoria-pingtel-com.us.nortel.com> <4A282D39.2090401@cisco.com> <1244232151.3786.70.camel@victoria-pingtel-com.us.nortel.com> <1244661124.3769.93.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1244661124.3769.93.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jun 2009 20:16:45.0618 (UTC) FILETIME=[607C8120:01C9EA08] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=992; t=1244665006; x=1245529006; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Comments=20on=20draft-roach -sipcore-rfc3265bis-00 |Sender:=20 |To:=20Dale=20Worley=20; bh=AXYJGd5avQpfR7okcS4wio5MsstgQ0p+7vm4quECVTQ=; b=X2huH7N50JLj0MN4LjSBJM3WqqY3xgn0xKxTolmYtuB8dMRRdfkoM25nFf kFNHDeUVNnNWBnlhRIWnKnDPOPwssOgaRjaTQWzYTF27VjyfjfcWtqfS13jO 2HLP1LaQF2; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Comments on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 20:16:45 -0000 Do we have a way of terminating a subscription that subscribers are likely to interpret as "sorry but I'd like you to try again"? The closest I can think of would be send a REFER. Thanks, Paul Dale Worley wrote: > On Fri, 2009-06-05 at 16:02 -0400, Dale Worley wrote: >>> But the no-reduce rule has its own trouble. In particular my usual >>> source of exceptions to everything: 3pcc. The subscriber may think he is >>> continuing a single subscription. But a middle box may be moving a >>> subscription from one UAS to another. The new target may not be willing >>> to support such a long subscription, and so may have need to reduce it. >> That's an annoyingly realistic problem. > > In this situation, can we demand that the middle box terminate the > subscription (rather than shorten it), with the expectation that the > subscriber will create a new subscription? (In terms of message > traffic, there is little additional load.) > > Dale > > > From dworley@nortel.com Wed Jun 10 13:21:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83DE43A6C0A for ; Wed, 10 Jun 2009 13:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.742 X-Spam-Level: X-Spam-Status: No, score=-6.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnWTCdGHwPfy for ; Wed, 10 Jun 2009 13:21:34 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 927E73A6C00 for ; Wed, 10 Jun 2009 13:21:34 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5AKLaZ21655; Wed, 10 Jun 2009 20:21:36 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 16:21:32 -0400 From: "Dale Worley" To: Paul Kyzivat In-Reply-To: <4A3014AD.6090906@cisco.com> References: <1240958114.18691.54.camel@victoria-pingtel-com.us.nortel.com> <4A1C4C45.90204@nostrum.com> <1244143850.3743.62.camel@victoria-pingtel-com.us.nortel.com> <4A282D39.2090401@cisco.com> <1244232151.3786.70.camel@victoria-pingtel-com.us.nortel.com> <1244661124.3769.93.camel@victoria-pingtel-com.us.nortel.com> <4A3014AD.6090906@cisco.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 10 Jun 2009 16:21:31 -0400 Message-Id: <1244665291.3769.120.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jun 2009 20:21:32.0297 (UTC) FILETIME=[0B5C3F90:01C9EA09] Cc: SIPCORE Subject: Re: [sipcore] Comments on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 20:21:35 -0000 On Wed, 2009-06-10 at 16:16 -0400, Paul Kyzivat wrote: > Do we have a way of terminating a subscription that subscribers are > likely to interpret as "sorry but I'd like you to try again"? > > The closest I can think of would be send a REFER. The use of REFER was mentioned earlier by Adam, IIRC. In all the cases I know of, a subscription is either a state query (expires=0, in which case this question can't arise), or a subscription that is intended to be kept in force perpetually (in which case, if the subscription is terminated by the notifier, the subscriber will attempt to reestablish the subscription). Dale From bcampen@estacado.net Wed Jun 10 13:32:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC673A6C0A for ; Wed, 10 Jun 2009 13:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nje7cjBgfvuN for ; Wed, 10 Jun 2009 13:32:39 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 60B5C3A6AFE for ; Wed, 10 Jun 2009 13:32:39 -0700 (PDT) Received: from dn3-233.estacado.net (dn3-233.estacado.net [172.16.3.233]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n5AKWgLR037161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 10 Jun 2009 15:32:43 -0500 (CDT) (envelope-from bcampen@estacado.net) Message-Id: <106280B2-9FAC-40F2-9CDE-690BB9246156@estacado.net> From: Byron Campen To: Paul Kyzivat In-Reply-To: <4A3014AD.6090906@cisco.com> Content-Type: multipart/signed; boundary=Apple-Mail-4-70790659; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 10 Jun 2009 15:32:39 -0500 References: <1240958114.18691.54.camel@victoria-pingtel-com.us.nortel.com> <4A1C4C45.90204@nostrum.com> <1244143850.3743.62.camel@victoria-pingtel-com.us.nortel.com> <4A282D39.2090401@cisco.com> <1244232151.3786.70.camel@victoria-pingtel-com.us.nortel.com> <1244661124.3769.93.camel@victoria-pingtel-com.us.nortel.com> <4A3014AD.6090906@cisco.com> X-Mailer: Apple Mail (2.935.3) Cc: SIPCORE , Dale Worley Subject: Re: [sipcore] Comments on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 20:32:40 -0000 --Apple-Mail-4-70790659 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit 3265 specifies that a reason param of "deactivated" on a NOTIFY terminated should cause the UAC to immediately re-establish the subscription. (See Sec 3.2.4, or 4.1.3 in bis-00) Whether this is actually implemented... *shrug* Best regards, Byron Campen > Do we have a way of terminating a subscription that subscribers are > likely to interpret as "sorry but I'd like you to try again"? > > The closest I can think of would be send a REFER. > > Thanks, > Paul > > Dale Worley wrote: >> On Fri, 2009-06-05 at 16:02 -0400, Dale Worley wrote: >>>> But the no-reduce rule has its own trouble. In particular my >>>> usual source of exceptions to everything: 3pcc. The subscriber >>>> may think he is continuing a single subscription. But a middle >>>> box may be moving a subscription from one UAS to another. The new >>>> target may not be willing to support such a long subscription, >>>> and so may have need to reduce it. >>> That's an annoyingly realistic problem. >> In this situation, can we demand that the middle box terminate the >> subscription (rather than shorten it), with the expectation that the >> subscriber will create a new subscription? (In terms of message >> traffic, there is little additional load.) >> Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail-4-70790659 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGZDCCAx0w ggKGoAMCAQICEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDkyMzA0MzgwNFoXDTA5MDkyMzA0Mzgw NFowazEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQxIzAhBgkqhkiG9w0BCQEWFGRvY2ZhcmFkYXlAZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIGiyvzQgsqDjR3TiFTO4nkc/VRo/eX6xKu ky4CR2QtnIPEWhNLbU5UgXdGzU3YWx/cRj5alT0auKVQ/BnjCbf3bFSzP5mIfV6KlJV89dpxKQQA 3FaDYxE3whiRPIjQh3nmqxSacBTLohlt/g8MlFyiHoNs3XcH83M3QMjMxU8pD7SgXUDaXdtqC8vV +7g3rzPmlONdJ+4vac159wuZe37WVTsFI4sYL3p/KvqT1NZhmn1cmOVWKfCVAdGLk8VEUZtWuSeM NU5CLnFvenxaSPkDeVR5h0qDpw4DQyHfWXQuKvRs1WgVeHASz87EPgncyp90yiByetvE0WIBGKiz 0QIDAQABo0cwRTA1BgNVHREELjAsgRRiY2FtcGVuQGVzdGFjYWRvLm5ldIEUZG9jZmFyYWRheUBn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQANmDZo4t+1SrO9nb8KfjN4 QtlV1gzaAa2jEsAZ369PBXdsxVz32a1JIa1KudXFfMMxtF1NRDJ0Z3ib/qq+L8B28IpkYgRWtRr+ WWm6LzJ6rm1Q85cC0VSqoIRr+NoRZjaBdqWbJC4QsPnwVSXN9jLMLkFkjcxVDSxQtEx6v1PF9zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUP SAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0Eu Y3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2f Ni/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH 1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQW7SrCyoCwnsms5MfcqmjmzAJBgUr DgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2 MTAyMDMyNDBaMCMGCSqGSIb3DQEJBDEWBBT/so90xfMge64EqLDHNDigO4n8zjCBhQYJKwYBBAGC NxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsq AsJ7JrOTH3Kpo5swgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEBBQAEggEAJGB4 LZwrSSY8TdDiX5VMLuewvydT4JsVqIF9vUR5i3X9WZxfcKH/LHCeAPWPK6S23BUzHpMmDBVZoXF0 bbmals78a7jPwhGpKrVR7ftFIIrqBTKj+BzZyrMstUoX2CARVHVg8D3e38Z8ksVElyITVQiZs4iu 9NX16SwKG/2zsBjUxiIngaGCDI8jQR82qHJ0SmET+0B+ZrEg+hP2hsNNLG/BselcpWien7Pz8Cnn GcUtnjFKbALKPLXRe6dxSR7jzlctOONZHr4TQZP+CzBUH7Vs92xvP6kR/NIe0pigTxTdYRA6FtFr CpZNKWkb6TzJzjH5bq6ddjHuyEsLLRV5IAAAAAAAAA== --Apple-Mail-4-70790659-- From pkyzivat@cisco.com Wed Jun 10 13:39:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761253A69B0 for ; Wed, 10 Jun 2009 13:39:31 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Swsg-9860gL0 for ; Wed, 10 Jun 2009 13:39:30 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 770143A67BD for ; Wed, 10 Jun 2009 13:39:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,197,1243814400"; d="scan'208";a="46912622" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 10 Jun 2009 20:39:36 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5AKda8I017140; Wed, 10 Jun 2009 16:39:36 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5AKdakl026119; Wed, 10 Jun 2009 20:39:36 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 16:39:35 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 16:39:35 -0400 Message-ID: <4A301A06.3000608@cisco.com> Date: Wed, 10 Jun 2009 16:39:34 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Byron Campen References: <1240958114.18691.54.camel@victoria-pingtel-com.us.nortel.com> <4A1C4C45.90204@nostrum.com> <1244143850.3743.62.camel@victoria-pingtel-com.us.nortel.com> <4A282D39.2090401@cisco.com> <1244232151.3786.70.camel@victoria-pingtel-com.us.nortel.com> <1244661124.3769.93.camel@victoria-pingtel-com.us.nortel.com> <4A3014AD.6090906@cisco.com> <106280B2-9FAC-40F2-9CDE-690BB9246156@estacado.net> In-Reply-To: <106280B2-9FAC-40F2-9CDE-690BB9246156@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jun 2009 20:39:35.0063 (UTC) FILETIME=[90BD3A70:01C9EA0B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1690; t=1244666376; x=1245530376; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Comments=20on=20draft-roach -sipcore-rfc3265bis-00 |Sender:=20 |To:=20Byron=20Campen=20; bh=O//FSECHzKEf7o1V+lUlLfNLVgAeO5NWEr6uYH50kb4=; b=Y2c5m5GHceAuzIwMccD3MvUhxFsMegQdnWY6qBrJEBG8QjfZNQCKbw0Z2H iF5eBg4diDk4BHhtUCiGaShHart52gzLWgNXrq0w2++9uG8sjdgSGhFglz/x TL0h/Q9vc4; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIPCORE , Dale Worley Subject: Re: [sipcore] Comments on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 20:39:31 -0000 Byron Campen wrote: > 3265 specifies that a reason param of "deactivated" on a NOTIFY > terminated should cause the UAC to immediately re-establish the > subscription. (See Sec 3.2.4, or 4.1.3 in bis-00) Whether this is > actually implemented... *shrug* OK. That is what I was looking for. In that case I think Dale's approach can fly. If people haven't implemented it, maybe they will when it starts to be useful to do so. Thanks, Paul > Best regards, > Byron Campen > >> Do we have a way of terminating a subscription that subscribers are >> likely to interpret as "sorry but I'd like you to try again"? >> >> The closest I can think of would be send a REFER. >> >> Thanks, >> Paul >> >> Dale Worley wrote: >>> On Fri, 2009-06-05 at 16:02 -0400, Dale Worley wrote: >>>>> But the no-reduce rule has its own trouble. In particular my usual >>>>> source of exceptions to everything: 3pcc. The subscriber may think >>>>> he is continuing a single subscription. But a middle box may be >>>>> moving a subscription from one UAS to another. The new target may >>>>> not be willing to support such a long subscription, and so may have >>>>> need to reduce it. >>>> That's an annoyingly realistic problem. >>> In this situation, can we demand that the middle box terminate the >>> subscription (rather than shorten it), with the expectation that the >>> subscriber will create a new subscription? (In terms of message >>> traffic, there is little additional load.) >>> Dale >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > From dworley@nortel.com Wed Jun 10 15:12:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC6E43A6AB3 for ; Wed, 10 Jun 2009 15:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.71 X-Spam-Level: X-Spam-Status: No, score=-6.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sluBhle8qNkt for ; Wed, 10 Jun 2009 15:12:16 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id BFBF43A65A6 for ; Wed, 10 Jun 2009 15:12:15 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5AMAkP21212; Wed, 10 Jun 2009 22:10:47 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 18:12:04 -0400 From: "Dale Worley" To: Paul Kyzivat In-Reply-To: <4A301A06.3000608@cisco.com> References: <1240958114.18691.54.camel@victoria-pingtel-com.us.nortel.com> <4A1C4C45.90204@nostrum.com> <1244143850.3743.62.camel@victoria-pingtel-com.us.nortel.com> <4A282D39.2090401@cisco.com> <1244232151.3786.70.camel@victoria-pingtel-com.us.nortel.com> <1244661124.3769.93.camel@victoria-pingtel-com.us.nortel.com> <4A3014AD.6090906@cisco.com> <106280B2-9FAC-40F2-9CDE-690BB9246156@estacado.net> <4A301A06.3000608@cisco.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 10 Jun 2009 18:12:04 -0400 Message-Id: <1244671924.3769.131.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jun 2009 22:12:04.0632 (UTC) FILETIME=[7C8A4180:01C9EA18] Cc: SIPCORE , Byron Campen Subject: Re: [sipcore] Comments on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 22:12:16 -0000 On Wed, 2009-06-10 at 16:39 -0400, Paul Kyzivat wrote: > Byron Campen wrote: > > 3265 specifies that a reason param of "deactivated" on a NOTIFY > > terminated should cause the UAC to immediately re-establish the > > subscription. (See Sec 3.2.4, or 4.1.3 in bis-00) Whether this is > > actually implemented... *shrug* > > OK. That is what I was looking for. > In that case I think Dale's approach can fly. > If people haven't implemented it, maybe they will when it starts to be > useful to do so. Well, as I said before, I think that in 99% of the current implementation situations, the subscriber will re-subscribe as a matter of policy. But it's good for the termination message to have an explicit semantic for that behavior as well. Dale From adam@nostrum.com Thu Jun 11 01:00:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E9623A6B66 for ; Thu, 11 Jun 2009 01:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9ibY3OJr268 for ; Thu, 11 Jun 2009 01:00:05 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 00D713A6B5E for ; Thu, 11 Jun 2009 01:00:04 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-101.dsl.rcsntx.swbell.net [70.249.149.101]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n5B80AIA011799 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Jun 2009 03:00:10 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A30B989.9040805@nostrum.com> Date: Thu, 11 Jun 2009 03:00:09 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: sipcore@ietf.org References: <4A16F967.6050509@nostrum.com> In-Reply-To: <4A16F967.6050509@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.149.101 is authenticated by a trusted mechanism) Subject: Re: [sipcore] IETF 75: Agenda Time Requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 08:00:06 -0000 On 22-May-2009, Adam Roach wrote: > If you wish to request agenda time, please send these three pieces of > information to the SIPCORE chairs on or before June 3rd. That was, of course, a typo. The deadline for agenda requests is July 3rd. Please see the original mail below (with the date corrected) for further details. /a > [as chair] > > In keeping with the spirit of our charter, we intend to run SIPCORE > face-to-face meetings in a very focused fashion. To that end, requests > for SIPCORE agenda time need to contain the following information: > > 1. The name of the draft or drafts under discussion > 2. A list of open issues to be addressed > 3. A pointer to non-trivial mailing list discussion of the draft (the > subject line of associated threads is sufficient) > > Presentations are expected to be focused around the list of open > issues, not the general contents of or changes to the document. > Tutorial content must be limited to explaining the open issues and > potential resolutions to those issues. > > Please note that it will be very difficult to have non-trivial mailing > list discussion of drafts that are submitted very close to the > document submission deadlines. We strongly encourage authors who plan > to request agenda time to publish a revised document well ahead of the > deadlines. > > Currently, we have requested a total of 3.5 hours of meeting time at > the upcoming meeting in Stockholm this July. Depending on the total > number of open issues and the associated volume of mailing list > traffic, we may reduce this to 2.5 hours or even 1 hour. > > If you wish to request agenda time, please send these three pieces of > information to the SIPCORE chairs on or before July 3rd. Length of > timeslots will be determined based on the number and complexity of > open issues in the agenda request. If a new open issue arises after > submission of a request, please notify the chairs so that we can > adjust timeslots accordingly. > > For the sake of clarity: the discussion will not be limited to the > open items listed in your request; it can include open items that > arise after you submit your request. So, if your list of open items is > somewhat weak but you expect that difficult points may arise between > June 3rd and the Stockholm meeting, please send in a request > indicating that fact. > > /a From mary.barnes@nortel.com Thu Jun 11 11:02:14 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC52B3A6ABA for ; Thu, 11 Jun 2009 11:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaEaHwQ-nhyI for ; Thu, 11 Jun 2009 11:02:13 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id A5E243A67B1 for ; Thu, 11 Jun 2009 11:02:13 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5BI2Hl01656 for ; Thu, 11 Jun 2009 18:02:17 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9EABE.BFFA307D" Date: Thu, 11 Jun 2009 13:04:48 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9w From: "Mary Barnes" To: Subject: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 18:02:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EABE.BFFA307D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, We have made a few changes to this document which was submitted last week just to tie up some loose ends and inconsistencies, some of which Shida identified when he reviewed the -00 version.=20 The following summarizes the high level changes in the sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San Francisco: 1) Renamed the "retarget" parameter to "target" and defined explicit tags to reflect the various mechanisms by which a Request is retargeted. All entries are now tagged.=20 2) Updated redirect server processing as the redirect server must capture the "target" parameter since it is the entity that knows the specific mechanism by which the new target has been determined.=20 3) Changed the privacy such that rather than removing entries based on the various values of the privacy header, the entries are recommended to be anonymized.=20 4) Updated security section 5) Updated examples to reflect the new parameter, use loose routing and fix errors/nits. 6) Editorial changes to remove redundant text and the convuluted text around optionality in the non-normative sections, which is now discussed appropriately in the context of the histinfo option tag. The detailed changes between the versions are summarized in the document. If you're wanting to look at a diff, I would recommend you diff against RFC 4244 rather than the earlier 4244bis documents.=20 We'd really appreciate feedback on this approach to precisely tagging all the entries. We believe it is comprehensive and should suffice for all the use cases identified in the target-uri document, as well as any others that might arise. =20 Thanks, Mary and Francois. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, June 11, 2009 12:45 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, F. Audet Filename : draft-barnes-sipcore-rfc4244bis-01.txt Pages : 42 Date : 2009-06-11 This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01.t xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C9EABE.BFFA307D Content-Type: application/octet-stream; name="draft-barnes-sipcore-rfc4244bis-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-barnes-sipcore-rfc4244bis-01.URL Content-Disposition: attachment; filename="draft-barnes-sipcore-rfc4244bis-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1iYXJuZXMtc2lwY29yZS1yZmM0MjQ0YmlzLTAxLnR4dA0K ------_=_NextPart_001_01C9EABE.BFFA307D Content-Type: text/plain; name="ATT9205918.txt" Content-Transfer-Encoding: base64 Content-Description: ATT9205918.txt Content-Disposition: attachment; filename="ATT9205918.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K ------_=_NextPart_001_01C9EABE.BFFA307D-- From christer.holmberg@ericsson.com Thu Jun 11 13:30:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C2E43A6A50 for ; Thu, 11 Jun 2009 13:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuFrpB+y4Bf3 for ; Thu, 11 Jun 2009 13:30:43 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EFFBC3A6B10 for ; Thu, 11 Jun 2009 13:30:39 -0700 (PDT) X-AuditID: c1b4fb3e-b7bedae0000062bb-bc-4a3169752983 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 43.F0.25275.579613A4; Thu, 11 Jun 2009 22:30:45 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jun 2009 22:30:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Jun 2009 22:30:44 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedA= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Mary Barnes" , X-OriginalArrivalTime: 11 Jun 2009 20:30:45.0180 (UTC) FILETIME=[7F513FC0:01C9EAD3] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 20:30:50 -0000 Hi, I think it is important to mention that there are still different approaches regarding the target uri delivery, and that there is another approach described in the latest version of the target-uri delivery draft (I am not sure it appears in the archieves, though, for some reason). Both approaches are based on History-Info, though. We haven't yet been able to agree on an approach, so we thought the best is to bring it to the list in order for other people to get involved. Regards, Christer =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, June 11, 2009 9:05 PM To: sipcore@ietf.org Subject: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi folks, We have made a few changes to this document which was submitted last week just to tie up some loose ends and inconsistencies, some of which Shida identified when he reviewed the -00 version.=20 The following summarizes the high level changes in the sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San Francisco: 1) Renamed the "retarget" parameter to "target" and defined explicit tags to reflect the various mechanisms by which a Request is retargeted. All entries are now tagged.=20 2) Updated redirect server processing as the redirect server must capture the "target" parameter since it is the entity that knows the specific mechanism by which the new target has been determined.=20 3) Changed the privacy such that rather than removing entries based on the various values of the privacy header, the entries are recommended to be anonymized.=20 4) Updated security section 5) Updated examples to reflect the new parameter, use loose routing and fix errors/nits. 6) Editorial changes to remove redundant text and the convuluted text around optionality in the non-normative sections, which is now discussed appropriately in the context of the histinfo option tag. The detailed changes between the versions are summarized in the document. If you're wanting to look at a diff, I would recommend you diff against RFC 4244 rather than the earlier 4244bis documents.=20 We'd really appreciate feedback on this approach to precisely tagging all the entries. We believe it is comprehensive and should suffice for all the use cases identified in the target-uri document, as well as any others that might arise. =20 Thanks, Mary and Francois. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, June 11, 2009 12:45 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, F. Audet Filename : draft-barnes-sipcore-rfc4244bis-01.txt Pages : 42 Date : 2009-06-11 This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01.t xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From christer.holmberg@ericsson.com Thu Jun 11 13:32:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CEE33A69F1 for ; Thu, 11 Jun 2009 13:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cu1HvhDWqjxJ for ; Thu, 11 Jun 2009 13:32:30 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 046BF3A69EF for ; Thu, 11 Jun 2009 13:32:20 -0700 (PDT) X-AuditID: c1b4fb3e-b7bedae0000062bb-29-4a3169d6816b Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 2E.F0.25275.6D9613A4; Thu, 11 Jun 2009 22:32:22 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jun 2009 22:32:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Jun 2009 22:32:21 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Christer Holmberg" , "Mary Barnes" , X-OriginalArrivalTime: 11 Jun 2009 20:32:21.0645 (UTC) FILETIME=[B8D0A3D0:01C9EAD3] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 20:32:31 -0000 Here is the link to the latest version of the target-uri draft: http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00. txt=20 -----Original Message----- From: Christer Holmberg=20 Sent: Thursday, June 11, 2009 11:31 PM To: 'Mary Barnes'; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi, I think it is important to mention that there are still different approaches regarding the target uri delivery, and that there is another approach described in the latest version of the target-uri delivery draft (I am not sure it appears in the archieves, though, for some reason). Both approaches are based on History-Info, though. We haven't yet been able to agree on an approach, so we thought the best is to bring it to the list in order for other people to get involved. Regards, Christer =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, June 11, 2009 9:05 PM To: sipcore@ietf.org Subject: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi folks, We have made a few changes to this document which was submitted last week just to tie up some loose ends and inconsistencies, some of which Shida identified when he reviewed the -00 version.=20 The following summarizes the high level changes in the sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San Francisco: 1) Renamed the "retarget" parameter to "target" and defined explicit tags to reflect the various mechanisms by which a Request is retargeted. All entries are now tagged.=20 2) Updated redirect server processing as the redirect server must capture the "target" parameter since it is the entity that knows the specific mechanism by which the new target has been determined.=20 3) Changed the privacy such that rather than removing entries based on the various values of the privacy header, the entries are recommended to be anonymized.=20 4) Updated security section 5) Updated examples to reflect the new parameter, use loose routing and fix errors/nits. 6) Editorial changes to remove redundant text and the convuluted text around optionality in the non-normative sections, which is now discussed appropriately in the context of the histinfo option tag. The detailed changes between the versions are summarized in the document. If you're wanting to look at a diff, I would recommend you diff against RFC 4244 rather than the earlier 4244bis documents.=20 We'd really appreciate feedback on this approach to precisely tagging all the entries. We believe it is comprehensive and should suffice for all the use cases identified in the target-uri document, as well as any others that might arise. =20 Thanks, Mary and Francois. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, June 11, 2009 12:45 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, F. Audet Filename : draft-barnes-sipcore-rfc4244bis-01.txt Pages : 42 Date : 2009-06-11 This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01.t xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From mdolly@att.com Thu Jun 11 13:39:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17F863A6902 for ; Thu, 11 Jun 2009 13:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU56giSXC6mh for ; Thu, 11 Jun 2009 13:39:42 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 9A4BD3A6A62 for ; Thu, 11 Jun 2009 13:39:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-13.tower-161.messagelabs.com!1244752785!15922917!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 5774 invoked from network); 11 Jun 2009 20:39:46 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-13.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Jun 2009 20:39:46 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5BKdjk1029644 for ; Thu, 11 Jun 2009 16:39:45 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5BKdf2v029616 for ; Thu, 11 Jun 2009 16:39:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Jun 2009 16:39:37 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLw References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> From: "DOLLY, MARTIN C, ATTLABS" To: "Christer Holmberg" , "Mary Barnes" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 20:39:45 -0000 Hello, Can someone please summarize the differences between the two approaches? Thanks, Martin -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: Thursday, June 11, 2009 4:32 PM To: Christer Holmberg; Mary Barnes; sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Here is the link to the latest version of the target-uri draft: http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00. txt=20 -----Original Message----- From: Christer Holmberg=20 Sent: Thursday, June 11, 2009 11:31 PM To: 'Mary Barnes'; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi, I think it is important to mention that there are still different approaches regarding the target uri delivery, and that there is another approach described in the latest version of the target-uri delivery draft (I am not sure it appears in the archieves, though, for some reason). Both approaches are based on History-Info, though. We haven't yet been able to agree on an approach, so we thought the best is to bring it to the list in order for other people to get involved. Regards, Christer =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, June 11, 2009 9:05 PM To: sipcore@ietf.org Subject: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi folks, We have made a few changes to this document which was submitted last week just to tie up some loose ends and inconsistencies, some of which Shida identified when he reviewed the -00 version.=20 The following summarizes the high level changes in the sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San Francisco: 1) Renamed the "retarget" parameter to "target" and defined explicit tags to reflect the various mechanisms by which a Request is retargeted. All entries are now tagged.=20 2) Updated redirect server processing as the redirect server must capture the "target" parameter since it is the entity that knows the specific mechanism by which the new target has been determined.=20 3) Changed the privacy such that rather than removing entries based on the various values of the privacy header, the entries are recommended to be anonymized.=20 4) Updated security section 5) Updated examples to reflect the new parameter, use loose routing and fix errors/nits. 6) Editorial changes to remove redundant text and the convuluted text around optionality in the non-normative sections, which is now discussed appropriately in the context of the histinfo option tag. The detailed changes between the versions are summarized in the document. If you're wanting to look at a diff, I would recommend you diff against RFC 4244 rather than the earlier 4244bis documents.=20 We'd really appreciate feedback on this approach to precisely tagging all the entries. We believe it is comprehensive and should suffice for all the use cases identified in the target-uri document, as well as any others that might arise. =20 Thanks, Mary and Francois. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, June 11, 2009 12:45 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, F. Audet Filename : draft-barnes-sipcore-rfc4244bis-01.txt Pages : 42 Date : 2009-06-11 This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01.t xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From mary.barnes@nortel.com Thu Jun 11 14:10:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213973A6DF4 for ; Thu, 11 Jun 2009 14:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+YLGo0l5uxI for ; Thu, 11 Jun 2009 14:10:43 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8CB5B3A6D9B for ; Thu, 11 Jun 2009 14:10:39 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5BLAhl20864; Thu, 11 Jun 2009 21:10:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Jun 2009 16:13:16 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAQbmA References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Christer Holmberg" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 21:10:45 -0000 Christer, I reviewed the updated target-uri draft and have a few comments - well I reviewed the diff since there isn't a summary of changes in the document: 1) I had a lot of difficulty picking out the normative processing for History-Info in this document. Can you summarize the differences?=20 2) The reason I'm concerned about understanding how this fits with the current normative processing is because I'm not seeing precisely when these tags are added as the terminology is different than that used in RFC 4244 - i.e., are these two terms equivalent: RFC 4244: "... hi-entry received in the request being forwarded." target-uri: "...hi-entry recording the incoming request URI." There is no reference in terms of current History-Info processing as to when in the request processing these tags are added. =20 3) In particular, I'm having difficulty with this text in section 6: =20 "When a home proxy receives a request for a user or resource for which is abstract location function returns registered contacts or configured URIs, the proxy adds two History-Info header field values. The first is the incoming request URI. Since the Request-URI identifies a user or resource for which it has a registration or configuration, the Request-URI is an AOR and thus an address for the user. The proxy adds a History-Info header field parameter, "aor", which indicates this. Next, the proxy inserts the contact URI which will be contained in the outgoing Request-URI." Currently, in RFC 4244, the proxy only adds that additional (first) hi-entry IF there wasn't one in the incoming request, since the UAC can initially add one when it builds the request. So, this is inconsistent with current RFC 4244. And, I think you need to define "home" proxy - that's not an RFC 3261 term - there is the concept of a "home" domain.=20 4) There is a bug in the Syntax (section 9) - the Index is not optional (that is an error we have fixed in the 4244bis).=20 5) I'm really confused about this two-stage tagging - how does that happen in the context of the determination of Request Targets in section 16.5 of RFC3261? Wouldn't the decisions as to the addition of the two different tags occur at the same time and thus what is the advantage of the defining the two tags - i.e., why not one tag for each combination? Also, are you proposing that the addition of the tags be mandatory - there is no normative language in the target-uri document, so it's impossible to tell. And, if you are proposing they be mandatory, your ABNF syntax needs to reflect that, thus defining a single parameter with multiple values would be necessary (which is the approach in 4244bis). 6) What is the difference (or is there a difference?) between the functionality associated with the tags in 4244bis and the tags defined in this document in terms of types of retargets that are being tagged? I think this is the crux of what we need to agree - i.e., why aren't the 4244bis tags sufficient? If there is no logical difference and it's just the words used to define the tags, then we're very close to agreement.=20 Regards, Mary.=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Thursday, June 11, 2009 3:32 PM To: Christer Holmberg; Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Here is the link to the latest version of the target-uri draft: http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00. txt=20 -----Original Message----- From: Christer Holmberg Sent: Thursday, June 11, 2009 11:31 PM To: 'Mary Barnes'; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi, I think it is important to mention that there are still different approaches regarding the target uri delivery, and that there is another approach described in the latest version of the target-uri delivery draft (I am not sure it appears in the archieves, though, for some reason). Both approaches are based on History-Info, though. We haven't yet been able to agree on an approach, so we thought the best is to bring it to the list in order for other people to get involved. Regards, Christer =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, June 11, 2009 9:05 PM To: sipcore@ietf.org Subject: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi folks, We have made a few changes to this document which was submitted last week just to tie up some loose ends and inconsistencies, some of which Shida identified when he reviewed the -00 version.=20 The following summarizes the high level changes in the sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San Francisco: 1) Renamed the "retarget" parameter to "target" and defined explicit tags to reflect the various mechanisms by which a Request is retargeted. All entries are now tagged.=20 2) Updated redirect server processing as the redirect server must capture the "target" parameter since it is the entity that knows the specific mechanism by which the new target has been determined.=20 3) Changed the privacy such that rather than removing entries based on the various values of the privacy header, the entries are recommended to be anonymized.=20 4) Updated security section 5) Updated examples to reflect the new parameter, use loose routing and fix errors/nits. 6) Editorial changes to remove redundant text and the convuluted text around optionality in the non-normative sections, which is now discussed appropriately in the context of the histinfo option tag. The detailed changes between the versions are summarized in the document. If you're wanting to look at a diff, I would recommend you diff against RFC 4244 rather than the earlier 4244bis documents.=20 We'd really appreciate feedback on this approach to precisely tagging all the entries. We believe it is comprehensive and should suffice for all the use cases identified in the target-uri document, as well as any others that might arise. =20 Thanks, Mary and Francois. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, June 11, 2009 12:45 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, F. Audet Filename : draft-barnes-sipcore-rfc4244bis-01.txt Pages : 42 Date : 2009-06-11 This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01.t xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From bcampen@estacado.net Thu Jun 11 19:33:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FBB128C192 for ; Thu, 11 Jun 2009 19:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIzf2Ah4rxVm for ; Thu, 11 Jun 2009 19:33:18 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 24BE228C14C for ; Thu, 11 Jun 2009 19:33:17 -0700 (PDT) Received: from [192.168.1.65] (99-48-0-163.lightspeed.dllstx.sbcglobal.net [99.48.0.163]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n5C2XEcW089221 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 11 Jun 2009 21:33:18 -0500 (CDT) (envelope-from bcampen@estacado.net) In-Reply-To: <109101c9eae2$f8ef9890$eacec9b0$@net> References: <109101c9eae2$f8ef9890$eacec9b0$@net> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-178794867; protocol="application/pkcs7-signature" Message-Id: <1EF42B19-CB00-48C3-9EF7-F15A36AE5CF7@estacado.net> From: Byron Campen Date: Thu, 11 Jun 2009 21:32:46 -0500 To: "Brian Rosen" X-Mailer: Apple Mail (2.753.1) Cc: sipcore@ietf.org Subject: Re: [sipcore] [Sipping] draft-niemi-sipcore-event-rate-control-00 and forcing notifications when state has not changed X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 02:33:22 -0000 --Apple-Mail-1-178794867 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Going ahead and moving to sipcore, and updating subject line... Ok, then I will say that this is a bad idea. I really, really don't want to deal with implementors that want to deploy clients that use the longest subscription duration possible, and shift the burden of keeping the subscription alive to the server through use of the force parameter. Because that is exactly what they will do. Best regards, Byron Campen > I would say yes, the intention is to force an update even if nothing > changed. > > Brian > >> -----Original Message----- >> From: sipping-bounces@ietf.org [mailto:sipping-bounces@ietf.org] On >> Behalf Of Byron Campen >> Sent: Thursday, June 11, 2009 6:00 PM >> To: sipping >> Subject: [Sipping] draft-niemi-sipping-event-throttle-08 and forcing >> notifications when state has not changed >> >> It appears that the normative language in this draft requires the >> notifier to send a notification if the force interval has elapsed, >> even >> when state has not changed since the last notification. Reading over >> some past discussion on list, I got the impression that this was not >> the intent. So which is it? >> >> Best regards, >> Byron Campen > --Apple-Mail-1-178794867 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGZDCCAx0w ggKGoAMCAQICEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDkyMzA0MzgwNFoXDTA5MDkyMzA0Mzgw NFowazEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQxIzAhBgkqhkiG9w0BCQEWFGRvY2ZhcmFkYXlAZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIGiyvzQgsqDjR3TiFTO4nkc/VRo/eX6xKu ky4CR2QtnIPEWhNLbU5UgXdGzU3YWx/cRj5alT0auKVQ/BnjCbf3bFSzP5mIfV6KlJV89dpxKQQA 3FaDYxE3whiRPIjQh3nmqxSacBTLohlt/g8MlFyiHoNs3XcH83M3QMjMxU8pD7SgXUDaXdtqC8vV +7g3rzPmlONdJ+4vac159wuZe37WVTsFI4sYL3p/KvqT1NZhmn1cmOVWKfCVAdGLk8VEUZtWuSeM NU5CLnFvenxaSPkDeVR5h0qDpw4DQyHfWXQuKvRs1WgVeHASz87EPgncyp90yiByetvE0WIBGKiz 0QIDAQABo0cwRTA1BgNVHREELjAsgRRiY2FtcGVuQGVzdGFjYWRvLm5ldIEUZG9jZmFyYWRheUBn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQANmDZo4t+1SrO9nb8KfjN4 QtlV1gzaAa2jEsAZ369PBXdsxVz32a1JIa1KudXFfMMxtF1NRDJ0Z3ib/qq+L8B28IpkYgRWtRr+ WWm6LzJ6rm1Q85cC0VSqoIRr+NoRZjaBdqWbJC4QsPnwVSXN9jLMLkFkjcxVDSxQtEx6v1PF9zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUP SAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0Eu Y3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2f Ni/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH 1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQW7SrCyoCwnsms5MfcqmjmzAJBgUr DgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2 MTIwMjMyNDdaMCMGCSqGSIb3DQEJBDEWBBQAC2htP2ilrYBiiT3950Drp8XHbjCBhQYJKwYBBAGC NxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsq AsJ7JrOTH3Kpo5swgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEBBQAEggEAQTBj LL3AqrjsbatFkhfOj1TSknED3ZHB67B0XfsOZevNKINXGvnn+o4jDjqYYrydQ85TqP9b3O+kccRc ak1MgYWK8gOmy7IRUcuSP6g7edcfg890CL8uzpAv4nr6R5YCQg+dOXkWQzErZ+af6CZSuWt3xLGr vkIgTmvNN3InWtVBpX7m1JpagU0O8m0FOeDS5OIUeTFPbSiaTOyD8YrH3ZHKM8osoM68zBNsDDax TSWYHgXj6LxNOGD0ArwaHMLNZYkGQykkFUrxDx8JaqMA7PwWEFKt7KSVWyL59qDfv5EQ2mLh51x3 fXlIbdOJoh9mmNVLmVpCyXgNrsVnjNIJpwAAAAAAAA== --Apple-Mail-1-178794867-- From christer.holmberg@ericsson.com Thu Jun 11 23:20:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D9093A6C19 for ; Thu, 11 Jun 2009 23:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2pG-8PhQC4C for ; Thu, 11 Jun 2009 23:20:33 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A07AF3A6B92 for ; Thu, 11 Jun 2009 23:20:31 -0700 (PDT) X-AuditID: c1b4fb3e-b7bedae0000062bb-a0-4a31f3b04aec Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 67.74.25275.0B3F13A4; Fri, 12 Jun 2009 08:20:32 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jun 2009 08:20:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 08:20:20 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAQbmAABQZkXA= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Mary Barnes" , X-OriginalArrivalTime: 12 Jun 2009 06:20:20.0458 (UTC) FILETIME=[DCA04CA0:01C9EB25] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 06:20:34 -0000 Hi Mary, I will look at your comments more in detail later, but just to clarify = one thing: The idea - which you also are very aware about - IS to eventually put = the normative target uri text into 4244bis. The reason we haven't done = that yet is because we couldn't agree on the approache, and therefor the = decission was to keep one approach in the target uri draft for now, so = that we have both approaches properly documented. Regards. Christer =20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 > Sent: 12. kes=E4kuuta 2009 0:13 > To: Christer Holmberg; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Christer, >=20 > I reviewed the updated target-uri draft and have a few=20 > comments - well I reviewed the diff since there isn't a=20 > summary of changes in the > document: >=20 > 1) I had a lot of difficulty picking out the normative=20 > processing for History-Info in this document. Can you=20 > summarize the differences?=20 >=20 > 2) The reason I'm concerned about understanding how this fits=20 > with the current normative processing is because I'm not=20 > seeing precisely when these tags are added as the terminology=20 > is different than that used in RFC 4244 - i.e., are these two=20 > terms equivalent: > RFC 4244: > "... hi-entry received in the request being forwarded." >=20 > target-uri: > "...hi-entry recording the incoming request URI." >=20 > There is no reference in terms of current History-Info=20 > processing as to when in the request processing these tags=20 > are added. =20 >=20 > 3) In particular, I'm having difficulty with this text in section 6: =20 > "When a home proxy receives a request for a user or=20 > resource for which > is abstract location function returns registered contacts or > configured URIs, the proxy adds two History-Info header=20 > field values. > The first is the incoming request URI. Since the Request-URI > identifies a user or resource for which it has a registration or > configuration, the Request-URI is an AOR and thus an=20 > address for the > user. The proxy adds a History-Info header field parameter, "aor", > which indicates this. Next, the proxy inserts the contact=20 > URI which > will be contained in the outgoing Request-URI." > Currently, in RFC 4244, the proxy only adds that additional=20 > (first) hi-entry IF there wasn't one in the incoming request,=20 > since the UAC can initially add one when it builds the=20 > request. So, this is inconsistent with current RFC 4244. And,=20 > I think you need to define "home" proxy - that's not an RFC=20 > 3261 term - there is the concept of a "home" domain.=20 >=20 > 4) There is a bug in the Syntax (section 9) - the Index is=20 > not optional (that is an error we have fixed in the 4244bis).=20 >=20 > 5) I'm really confused about this two-stage tagging - how=20 > does that happen in the context of the determination of=20 > Request Targets in section > 16.5 of RFC3261? Wouldn't the decisions as to the addition of=20 > the two different tags occur at the same time and thus what=20 > is the advantage of the defining the two tags - i.e., why not=20 > one tag for each combination? > Also, are you proposing that the addition of the tags be=20 > mandatory - there is no normative language in the target-uri=20 > document, so it's impossible to tell. And, if you are=20 > proposing they be mandatory, your ABNF syntax needs to=20 > reflect that, thus defining a single parameter with multiple=20 > values would be necessary (which is the approach in 4244bis). >=20 >=20 > 6) What is the difference (or is there a difference?) between=20 > the functionality associated with the tags in 4244bis and the=20 > tags defined in this document in terms of types of retargets=20 > that are being tagged? > I think this is the crux of what we need to agree - i.e., why=20 > aren't the 4244bis tags sufficient? If there is no logical=20 > difference and it's just the words used to define the tags,=20 > then we're very close to agreement.=20 >=20 > Regards, > Mary.=20 >=20 >=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, June 11, 2009 3:32 PM > To: Christer Holmberg; Barnes, Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Here is the link to the latest version of the target-uri draft: >=20 > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-de livery-00. > txt=20 >=20 > -----Original Message----- > From: Christer Holmberg > Sent: Thursday, June 11, 2009 11:31 PM > To: 'Mary Barnes'; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi, >=20 > I think it is important to mention that there are still different > approaches regarding the target uri delivery, and that there=20 > is another > approach described in the latest version of the target-uri delivery > draft (I am not sure it appears in the archieves, though, for some > reason). Both approaches are based on History-Info, though. >=20 > We haven't yet been able to agree on an approach, so we=20 > thought the best > is to bring it to the list in order for other people to get involved. >=20 > Regards, >=20 > Christer >=20 > =20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Mary Barnes > Sent: Thursday, June 11, 2009 9:05 PM > To: sipcore@ietf.org > Subject: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hi folks, >=20 > We have made a few changes to this document which was submitted last > week just to tie up some loose ends and inconsistencies, some of which > Shida identified when he reviewed the -00 version.=20 >=20 > The following summarizes the high level changes in the > sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San > Francisco: > 1) Renamed the "retarget" parameter to "target" and defined explicit > tags to reflect the various mechanisms by which a Request is=20 > retargeted. > All entries are now tagged.=20 > 2) Updated redirect server processing as the redirect server must > capture the "target" parameter since it is the entity that knows the > specific mechanism by which the new target has been determined.=20 > 3) Changed the privacy such that rather than removing entries based on > the various values of the privacy header, the entries are=20 > recommended to > be anonymized.=20 > 4) Updated security section > 5) Updated examples to reflect the new parameter, use loose=20 > routing and > fix errors/nits. > 6) Editorial changes to remove redundant text and the convuluted text > around optionality in the non-normative sections, which is=20 > now discussed > appropriately in the context of the histinfo option tag. >=20 > The detailed changes between the versions are summarized in the > document. >=20 > If you're wanting to look at a diff, I would recommend you=20 > diff against > RFC 4244 rather than the earlier 4244bis documents.=20 >=20 > We'd really appreciate feedback on this approach to precisely tagging > all the entries. We believe it is comprehensive and should suffice for > all the use cases identified in the target-uri document, as=20 > well as any > others that might arise. =20 >=20 > Thanks, > Mary and Francois. >=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, June 11, 2009 12:45 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : An Extension to the Session Initiation > Protocol (SIP) for Request History Information > Author(s) : M. Barnes, F. Audet > Filename : draft-barnes-sipcore-rfc4244bis-01.txt > Pages : 42 > Date : 2009-06-11 >=20 > This document defines a standard mechanism for capturing the history > information associated with a Session Initiation Protocol=20 > (SIP) request. > This capability enables many enhanced services by providing the > information as to how and why a call arrives at a specific application > or user. This document defines a new optional SIP header,=20 > History-Info, > for capturing the history information in requests. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc42 44bis-01.t > xt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 From christer.holmberg@ericsson.com Fri Jun 12 01:12:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8823A6767 for ; Fri, 12 Jun 2009 01:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.812 X-Spam-Level: X-Spam-Status: No, score=-4.812 tagged_above=-999 required=5 tests=[AWL=-0.863, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xT1f2G34MAKu for ; Fri, 12 Jun 2009 01:12:37 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 23D763A6403 for ; Fri, 12 Jun 2009 01:12:36 -0700 (PDT) X-AuditID: c1b4fb3c-b7bbdae0000049e3-6a-4a320dfa3bf0 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id BD.9E.18915.AFD023A4; Fri, 12 Jun 2009 10:12:43 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jun 2009 10:12:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 10:12:42 +0200 Message-ID: In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwABgxmCA= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> From: "Christer Holmberg" To: "DOLLY, MARTIN C, ATTLABS" , "Mary Barnes" , X-OriginalArrivalTime: 12 Jun 2009 08:12:42.0289 (UTC) FILETIME=[8F121210:01C9EB35] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 08:12:39 -0000 Hi, The biggest difference is regarding support of service-number (like = toll-free/freephone) type-of services, where the Request-URI translation = does not change the targeted user or resource. Without going in to the = protocol differences (which aren't that big), my understanding of the = functional differences are the following: - 4244bis approach does not distinguish between service-number (like = toll-free/freephone) number translation and diversion. - 4244bis approach does not allow a service-number (like = toll-free/freephone) translation for a user which belongs to another = domain. - 4244bis requires that all service-numbers for a user/company (like = toll-free/freephone) must be registered (explicitly or implictly), which = means that the translation must be done by an entity (normally the = registrar) which has the registration information for the called user. The target uri approach does allow translation in another domain, and = does not require toll-free/freephone numbers to be registered for the = called user. So, I don't think that the 4244bis approach supports all service-numbers = (like toll-free/freephone) in a sufficient way, and that it is too = restrictive for no good reason. It imposes restrictions on the potential = business models that are not necessary. Regards, Christer=20 > -----Original Message----- > From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]=20 > Sent: 11. kes=E4kuuta 2009 23:40 > To: Christer Holmberg; Mary Barnes; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hello, >=20 > Can someone please summarize the differences between the two=20 > approaches? >=20 > Thanks, >=20 > Martin >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Thursday, June 11, 2009 4:32 PM > To: Christer Holmberg; Mary Barnes; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Here is the link to the latest version of the target-uri draft: >=20 > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-de > livery-00. > txt=20 >=20 > -----Original Message----- > From: Christer Holmberg > Sent: Thursday, June 11, 2009 11:31 PM > To: 'Mary Barnes'; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi, >=20 > I think it is important to mention that there are still different > approaches regarding the target uri delivery, and that there=20 > is another > approach described in the latest version of the target-uri delivery > draft (I am not sure it appears in the archieves, though, for some > reason). Both approaches are based on History-Info, though. >=20 > We haven't yet been able to agree on an approach, so we=20 > thought the best > is to bring it to the list in order for other people to get involved. >=20 > Regards, >=20 > Christer >=20 > =20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Mary Barnes > Sent: Thursday, June 11, 2009 9:05 PM > To: sipcore@ietf.org > Subject: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hi folks, >=20 > We have made a few changes to this document which was submitted last > week just to tie up some loose ends and inconsistencies, some of which > Shida identified when he reviewed the -00 version.=20 >=20 > The following summarizes the high level changes in the > sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San > Francisco: > 1) Renamed the "retarget" parameter to "target" and defined explicit > tags to reflect the various mechanisms by which a Request is=20 > retargeted. > All entries are now tagged.=20 > 2) Updated redirect server processing as the redirect server must > capture the "target" parameter since it is the entity that knows the > specific mechanism by which the new target has been determined.=20 > 3) Changed the privacy such that rather than removing entries based on > the various values of the privacy header, the entries are=20 > recommended to > be anonymized.=20 > 4) Updated security section > 5) Updated examples to reflect the new parameter, use loose=20 > routing and > fix errors/nits. > 6) Editorial changes to remove redundant text and the convuluted text > around optionality in the non-normative sections, which is=20 > now discussed > appropriately in the context of the histinfo option tag. >=20 > The detailed changes between the versions are summarized in the > document. >=20 > If you're wanting to look at a diff, I would recommend you=20 > diff against > RFC 4244 rather than the earlier 4244bis documents.=20 >=20 > We'd really appreciate feedback on this approach to precisely tagging > all the entries. We believe it is comprehensive and should suffice for > all the use cases identified in the target-uri document, as=20 > well as any > others that might arise. =20 >=20 > Thanks, > Mary and Francois. >=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, June 11, 2009 12:45 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : An Extension to the Session Initiation > Protocol (SIP) for Request History Information > Author(s) : M. Barnes, F. Audet > Filename : draft-barnes-sipcore-rfc4244bis-01.txt > Pages : 42 > Date : 2009-06-11 >=20 > This document defines a standard mechanism for capturing the history > information associated with a Session Initiation Protocol=20 > (SIP) request. > This capability enables many enhanced services by providing the > information as to how and why a call arrives at a specific application > or user. This document defines a new optional SIP header,=20 > History-Info, > for capturing the history information in requests. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc42 > 44bis-01.t > xt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From ietf.hanserik@gmail.com Fri Jun 12 01:38:05 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10AA93A68EC for ; Fri, 12 Jun 2009 01:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkkzbcvnKuKk for ; Fri, 12 Jun 2009 01:38:03 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 714C83A6BE3 for ; Fri, 12 Jun 2009 01:38:02 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so106851eyf.9 for ; Fri, 12 Jun 2009 01:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=dVKVz2kV3GoNwSWdTZF+03cELbV47KvjTn2nhCsrQNU=; b=XRl+yIku6cLsI3TBQDSpU+NuQuykYtogpfltkdk6YuJSl4URinYhTe267PBboQ2lSx LOO4FnYM9EyAdUOY6tF5efmEN5v2eW04NxDY2ASai9Zkx/MdtiI7+pESEMa6KUC8B9+I zr17BD7tiKDHLgs1lWGtvQu885tj+HlzRsc4Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cDU1l/ZjaiWhSJ0z2CFJ2slYukLT7V7vnwvCY1I0D/gRYSsThKkYgCI4zyoXiodS8I 0mQ9eNvbcMFNMBIOBvZDZ/vsJNjza7rfM6KYE0RACZHconeYhlY+BVlil5NB79JDXWGv O6buptIcdX/V2Ll4cVU7sOMG8T48C0dHC8o58= MIME-Version: 1.0 Received: by 10.210.136.15 with SMTP id j15mr4097145ebd.48.1244795887442; Fri, 12 Jun 2009 01:38:07 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> Date: Fri, 12 Jun 2009 10:38:07 +0200 Message-ID: <9ae56b1e0906120138y540f7c2bja62adcf942cba3a0@mail.gmail.com> From: Hans Erik van Elburg To: Mary Barnes Content-Type: multipart/alternative; boundary=00151748db24b05aed046c22a098 Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 08:38:05 -0000 --00151748db24b05aed046c22a098 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Mary, Sure when we agree on the way forward we have to resolve all these detailed procedures and conform to the 4244 language etc. But we already agreed to integrate it into 4424bis at the moment that there is agreement about the solution. Regarding the two tag approach that is open for discussion, i think it is more clean and in general pays off to separate concepts that are independent from each other. For example a hi-entry may be routed and not be an AOR, whereas it may also be routed and also an AOR. The decisions to be taken for additions of these tags are independent, so there is also no need to intertwine procedural text for them. (It is also more clear for implementors.) BR, /Hans Erik van Elburg On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes wrote: > Christer, > > I reviewed the updated target-uri draft and have a few comments - well I > reviewed the diff since there isn't a summary of changes in the > document: > > 1) I had a lot of difficulty picking out the normative processing for > History-Info in this document. Can you summarize the differences? > > 2) The reason I'm concerned about understanding how this fits with the > current normative processing is because I'm not seeing precisely when > these tags are added as the terminology is different than that used in > RFC 4244 - i.e., are these two terms equivalent: > RFC 4244: > "... hi-entry received in the request being forwarded." > > target-uri: > "...hi-entry recording the incoming request URI." > > There is no reference in terms of current History-Info processing as to > when in the request processing these tags are added. > > 3) In particular, I'm having difficulty with this text in section 6: > "When a home proxy receives a request for a user or resource for > which > is abstract location function returns registered contacts or > configured URIs, the proxy adds two History-Info header field values. > The first is the incoming request URI. Since the Request-URI > identifies a user or resource for which it has a registration or > configuration, the Request-URI is an AOR and thus an address for the > user. The proxy adds a History-Info header field parameter, "aor", > which indicates this. Next, the proxy inserts the contact URI which > will be contained in the outgoing Request-URI." > Currently, in RFC 4244, the proxy only adds that additional (first) > hi-entry IF there wasn't one in the incoming request, since the UAC can > initially add one when it builds the request. So, this is inconsistent > with current RFC 4244. And, I think you need to define "home" proxy - > that's not an RFC 3261 term - there is the concept of a "home" domain. > > 4) There is a bug in the Syntax (section 9) - the Index is not optional > (that is an error we have fixed in the 4244bis). > > 5) I'm really confused about this two-stage tagging - how does that > happen in the context of the determination of Request Targets in section > 16.5 of RFC3261? Wouldn't the decisions as to the addition of the two > different tags occur at the same time and thus what is the advantage of > the defining the two tags - i.e., why not one tag for each combination? > Also, are you proposing that the addition of the tags be mandatory - > there is no normative language in the target-uri document, so it's > impossible to tell. And, if you are proposing they be mandatory, your > ABNF syntax needs to reflect that, thus defining a single parameter with > multiple values would be necessary (which is the approach in 4244bis). > > > 6) What is the difference (or is there a difference?) between the > functionality associated with the tags in 4244bis and the tags defined > in this document in terms of types of retargets that are being tagged? > I think this is the crux of what we need to agree - i.e., why aren't the > 4244bis tags sufficient? If there is no logical difference and it's > just the words used to define the tags, then we're very close to > agreement. > > Regards, > Mary. > > > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, June 11, 2009 3:32 PM > To: Christer Holmberg; Barnes, Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > Here is the link to the latest version of the target-uri draft: > > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00. > txt > > -----Original Message----- > From: Christer Holmberg > Sent: Thursday, June 11, 2009 11:31 PM > To: 'Mary Barnes'; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > Hi, > > I think it is important to mention that there are still different > approaches regarding the target uri delivery, and that there is another > approach described in the latest version of the target-uri delivery > draft (I am not sure it appears in the archieves, though, for some > reason). Both approaches are based on History-Info, though. > > We haven't yet been able to agree on an approach, so we thought the best > is to bring it to the list in order for other people to get involved. > > Regards, > > Christer > > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Mary Barnes > Sent: Thursday, June 11, 2009 9:05 PM > To: sipcore@ietf.org > Subject: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Hi folks, > > We have made a few changes to this document which was submitted last > week just to tie up some loose ends and inconsistencies, some of which > Shida identified when he reviewed the -00 version. > > The following summarizes the high level changes in the > sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San > Francisco: > 1) Renamed the "retarget" parameter to "target" and defined explicit > tags to reflect the various mechanisms by which a Request is retargeted. > All entries are now tagged. > 2) Updated redirect server processing as the redirect server must > capture the "target" parameter since it is the entity that knows the > specific mechanism by which the new target has been determined. > 3) Changed the privacy such that rather than removing entries based on > the various values of the privacy header, the entries are recommended to > be anonymized. > 4) Updated security section > 5) Updated examples to reflect the new parameter, use loose routing and > fix errors/nits. > 6) Editorial changes to remove redundant text and the convuluted text > around optionality in the non-normative sections, which is now discussed > appropriately in the context of the histinfo option tag. > > The detailed changes between the versions are summarized in the > document. > > If you're wanting to look at a diff, I would recommend you diff against > RFC 4244 rather than the earlier 4244bis documents. > > We'd really appreciate feedback on this approach to precisely tagging > all the entries. We believe it is comprehensive and should suffice for > all the use cases identified in the target-uri document, as well as any > others that might arise. > > Thanks, > Mary and Francois. > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, June 11, 2009 12:45 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : An Extension to the Session Initiation > Protocol (SIP) for Request History Information > Author(s) : M. Barnes, F. Audet > Filename : draft-barnes-sipcore-rfc4244bis-01.txt > Pages : 42 > Date : 2009-06-11 > > This document defines a standard mechanism for capturing the history > information associated with a Session Initiation Protocol (SIP) request. > This capability enables many enhanced services by providing the > information as to how and why a call arrives at a specific application > or user. This document defines a new optional SIP header, History-Info, > for capturing the history information in requests. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01.t > xt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --00151748db24b05aed046c22a098 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mary,

Sure when we agree on the way forward we have to resolve al= l these detailed procedures and conform to the 4244 language etc. But we al= ready agreed to integrate it into 4424bis at the moment that there is agree= ment about the solution.

Regarding the two tag approach that is open for discussion, i think it = is more clean and in general pays off to separate concepts that are indepen= dent from each other. For example a hi-entry may be routed and not be an AO= R, whereas it may also be routed and also an AOR. The decisions to be taken= for additions of these tags are independent, so there is also no need to i= ntertwine procedural text for them. (It is also more clear for implementors= .)

BR,
/Hans Erik van Elburg

On Thu, Jun 11, 2009 at 11:13 PM, Mary Barne= s <mary.barn= es@nortel.com> wrote:
Christer,

I reviewed the updated target-uri draft and have a few comments - well I reviewed the diff since there isn't a summary of changes in the
document:

1) I had a lot of difficulty picking out the normative processing for
History-Info in this document. Can you summarize the differences?

2) The reason I'm concerned about understanding how this fits with the<= br> current normative processing is because I'm not seeing precisely when these tags are added as the terminology is different than that used in
RFC 4244 - i.e., are these two terms equivalent:
RFC 4244:
"... hi-entry received in the request being forwarded."

target-uri:
"...hi-entry recording the incoming request URI."

There is no reference in terms of current History-Info processing as to
when in the request processing these tags are added.

3) In particular, I'm having difficulty with this text in section 6: =A0 "When a home proxy receives a request for a user or resource for<= br> which
=A0 is abstract location function returns registered contacts or
=A0 configured URIs, the proxy adds two History-Info header field values.<= br> =A0 The first is the incoming request URI. =A0Since the Request-URI
=A0 identifies a user or resource for which it has a registration or
=A0 configuration, the Request-URI is an AOR and thus an address for the =A0 user. =A0The proxy adds a History-Info header field parameter, "a= or",
=A0 which indicates this. =A0Next, the proxy inserts the contact URI which=
=A0 will be contained in the outgoing Request-URI."
Currently, in RFC 4244, the proxy only adds that additional (first)
hi-entry IF there wasn't one in the incoming request, since the UAC can=
initially add one when it builds the request. So, this is inconsistent
with current RFC 4244. And, I think you need to define "home" pro= xy -
that's not an RFC 3261 term - there is the concept of a "home"= ; domain.

4) There is a bug in the Syntax (section 9) - the Index is not optional
(that is an error we have fixed in the 4244bis).

5) I'm really confused about this two-stage tagging - how does that
happen in the context of the determination of Request Targets in section 16.5 of RFC3261? Wouldn't the decisions as to the addition of the two different tags occur at the same time and thus what is the advantage of
the defining the two tags - i.e., why not one tag for each combination?
Also, are you proposing that the addition of the tags be mandatory -
there is no normative language in the target-uri document, so it's
impossible to tell. =A0And, if you are proposing they be mandatory, your ABNF syntax needs to reflect that, thus defining a single parameter with multiple values would be necessary (which is the approach in 4244bis).


6) What is the difference (or is there a difference?) between the
functionality associated with the tags in 4244bis and the tags defined
in this document in terms of types of retargets that are being tagged?
I think this is the crux of what we need to agree - i.e., why aren't th= e
4244bis tags sufficient? =A0If there is no logical difference and it's<= br> just the words used to define the tags, then we're very close to
agreement.

Regards,
Mary.



-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Thursday, June 11, 2009 3:32 PM
To: Christer Holmberg; Barnes, Mary= (RICH2:AR00); sipcore@ietf.org
Subject: RE: [sipcore] FW: I-D
Action:draft-barnes-sipcore-rfc4244bis-01.txt


Here is the link to the latest version of the target-uri draft:

http://tools.ietf.org/id/draft-rosenberg-= sipcore-target-uri-delivery-00.
txt

-----Original Message-----
From: Christer Holmberg
Sent: Thursday, June 11, 2009 11:31 PM
To: 'Mary Barnes'; sipcore@ietf= .org
Subject: RE: [sipcore] FW: I-D
Action:draft-barnes-sipcore-rfc4244bis-01.txt


Hi,

I think it is important to mention that there are still different
approaches regarding the target uri delivery, and that there is another
approach described in the latest version of the target-uri delivery
draft (I am not sure it appears in the archieves, though, for some
reason). Both approaches are based on History-Info, though.

We haven't yet been able to agree on an approach, so we thought the bes= t
is to bring it to the list in order for other people to get involved.

Regards,

Christer



-----Original Message-----
From: sipcore-bounces@ietf.org<= /a> [mailto:sipcore-bounces@iet= f.org] On
Behalf Of Mary Barnes
Sent: Thursday, June 11, 2009 9:05 PM
To: sipcore@ietf.org
Subject: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt
Hi folks,

We have made a few changes to this document which was submitted last
week just to tie up some loose ends and inconsistencies, some of which
Shida identified when he reviewed the -00 version.

The following summarizes the high level changes in the
sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San
Francisco:
1) Renamed the "retarget" parameter to "target" and def= ined explicit
tags to reflect the various mechanisms by which a Request is retargeted. All entries are now tagged.
2) Updated redirect server processing as the redirect server must
capture the "target" parameter since it is the entity that knows = the
specific mechanism by which the new target has been determined.
3) Changed the privacy such that rather than removing entries based on
the various values of the privacy header, the entries are recommended to be anonymized.
4) Updated security section
5) Updated examples to reflect the new parameter, use loose routing and
fix errors/nits.
6) Editorial changes to remove redundant text and the convuluted text
around optionality in the non-normative sections, which is now discussed appropriately in the context of the histinfo option tag.

The detailed changes between the versions are summarized in the
document.

If you're wanting to look at a diff, I would recommend you diff against=
RFC 4244 rather than the earlier 4244bis documents.

We'd really appreciate feedback on this approach to precisely tagging all the entries. We believe it is comprehensive and should suffice for
all the use cases identified in the target-uri document, as well as any
others that might arise.

Thanks,
Mary and Francois.

-----Original Message-----
From: i-d-announce-bounces= @ietf.org
[mailto:i-d-announce-bounc= es@ietf.org] On Behalf Of
Internet-Drafts@ietf.org Sent: Thursday, June 11, 2009 12:45 PM
To: i-d-announce@ietf.org
Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : An Extension to the Session Ini= tiation
Protocol (SIP) for Request History Information
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M. Barnes, F. Audet
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-barnes-sipcore-rfc4244bis-0= 1.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 42
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-06-11

This document defines a standard mechanism for capturing the history
information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the
information as to how and why a call arrives at a specific application
or user. =A0This document defines a new optional SIP header, History-Info,<= br> for capturing the history information in requests.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-= barnes-sipcore-rfc4244bis-01.t
xt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--00151748db24b05aed046c22a098-- From gonzalo.camarillo@ericsson.com Fri Jun 12 03:02:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94B3528C106 for ; Fri, 12 Jun 2009 03:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTTVWrPZxKhq for ; Fri, 12 Jun 2009 03:02:52 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 96B763A6AAC for ; Fri, 12 Jun 2009 03:02:52 -0700 (PDT) X-AuditID: c1b4fb3e-b7bedae0000062bb-b8-4a3227d357fd Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id C0.9D.25275.3D7223A4; Fri, 12 Jun 2009 12:02:59 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jun 2009 12:02:58 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jun 2009 12:02:58 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 901C9245F; Fri, 12 Jun 2009 13:02:58 +0300 (EEST) Message-ID: <4A3227D2.4020808@ericsson.com> Date: Fri, 12 Jun 2009 13:02:58 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2009 10:02:58.0704 (UTC) FILETIME=[F6C2E100:01C9EB44] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Milestone to revise RFC 3265 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 10:02:53 -0000 Folks, since the publication of RFC 3265, we have gotten significant experience deploying SIP-based notification systems. It has been proposed to revise RFC 3265 based on that experience. We have two questions for the WG: 1) should we add a milestone to our charter to revise RFC 3265? 2) if we add such a milestone, should we take the following draft as the initial WG item for the milestone? http://tools.ietf.org/html/draft-roach-sipcore-rfc3265bis-00 Thanks, Gonzalo SIPCORE co-chair From mdolly@att.com Fri Jun 12 03:12:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 328643A68A6 for ; Fri, 12 Jun 2009 03:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.449 X-Spam-Level: X-Spam-Status: No, score=-105.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzvNQsqhJAsl for ; Fri, 12 Jun 2009 03:12:40 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 330163A6403 for ; Fri, 12 Jun 2009 03:12:40 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-7.tower-167.messagelabs.com!1244801566!16194928!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 18704 invoked from network); 12 Jun 2009 10:12:46 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-7.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Jun 2009 10:12:46 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5CACk8d026722 for ; Fri, 12 Jun 2009 06:12:46 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5CACfZM026692 for ; Fri, 12 Jun 2009 06:12:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 06:12:40 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA036D0D6E@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwABgxmCAABCWdkA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> From: "DOLLY, MARTIN C, ATTLABS" To: "Christer Holmberg" , "Mary Barnes" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 10:12:43 -0000 Christer, The items you listed need to be supported. Our call center customers = require us to pass them the original dialed toll-free number. And the = same is true for call processing needs of the other call = service-numbers. Cheers, Martin -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On = Behalf Of Christer Holmberg Sent: Friday, June 12, 2009 4:13 AM To: DOLLY, MARTIN C, ATTLABS; Mary Barnes; sipcore@ietf.org Subject: Re: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi, The biggest difference is regarding support of service-number (like = toll-free/freephone) type-of services, where the Request-URI translation = does not change the targeted user or resource. Without going in to the = protocol differences (which aren't that big), my understanding of the = functional differences are the following: - 4244bis approach does not distinguish between service-number (like = toll-free/freephone) number translation and diversion. - 4244bis approach does not allow a service-number (like = toll-free/freephone) translation for a user which belongs to another = domain. - 4244bis requires that all service-numbers for a user/company (like = toll-free/freephone) must be registered (explicitly or implictly), which = means that the translation must be done by an entity (normally the = registrar) which has the registration information for the called user. The target uri approach does allow translation in another domain, and = does not require toll-free/freephone numbers to be registered for the = called user. So, I don't think that the 4244bis approach supports all service-numbers = (like toll-free/freephone) in a sufficient way, and that it is too = restrictive for no good reason. It imposes restrictions on the potential = business models that are not necessary. Regards, Christer=20 > -----Original Message----- > From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]=20 > Sent: 11. kes=E4kuuta 2009 23:40 > To: Christer Holmberg; Mary Barnes; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hello, >=20 > Can someone please summarize the differences between the two=20 > approaches? >=20 > Thanks, >=20 > Martin >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Thursday, June 11, 2009 4:32 PM > To: Christer Holmberg; Mary Barnes; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Here is the link to the latest version of the target-uri draft: >=20 > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-de > livery-00. > txt=20 >=20 > -----Original Message----- > From: Christer Holmberg > Sent: Thursday, June 11, 2009 11:31 PM > To: 'Mary Barnes'; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi, >=20 > I think it is important to mention that there are still different > approaches regarding the target uri delivery, and that there=20 > is another > approach described in the latest version of the target-uri delivery > draft (I am not sure it appears in the archieves, though, for some > reason). Both approaches are based on History-Info, though. >=20 > We haven't yet been able to agree on an approach, so we=20 > thought the best > is to bring it to the list in order for other people to get involved. >=20 > Regards, >=20 > Christer >=20 > =20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Mary Barnes > Sent: Thursday, June 11, 2009 9:05 PM > To: sipcore@ietf.org > Subject: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hi folks, >=20 > We have made a few changes to this document which was submitted last > week just to tie up some loose ends and inconsistencies, some of which > Shida identified when he reviewed the -00 version.=20 >=20 > The following summarizes the high level changes in the > sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San > Francisco: > 1) Renamed the "retarget" parameter to "target" and defined explicit > tags to reflect the various mechanisms by which a Request is=20 > retargeted. > All entries are now tagged.=20 > 2) Updated redirect server processing as the redirect server must > capture the "target" parameter since it is the entity that knows the > specific mechanism by which the new target has been determined.=20 > 3) Changed the privacy such that rather than removing entries based on > the various values of the privacy header, the entries are=20 > recommended to > be anonymized.=20 > 4) Updated security section > 5) Updated examples to reflect the new parameter, use loose=20 > routing and > fix errors/nits. > 6) Editorial changes to remove redundant text and the convuluted text > around optionality in the non-normative sections, which is=20 > now discussed > appropriately in the context of the histinfo option tag. >=20 > The detailed changes between the versions are summarized in the > document. >=20 > If you're wanting to look at a diff, I would recommend you=20 > diff against > RFC 4244 rather than the earlier 4244bis documents.=20 >=20 > We'd really appreciate feedback on this approach to precisely tagging > all the entries. We believe it is comprehensive and should suffice for > all the use cases identified in the target-uri document, as=20 > well as any > others that might arise. =20 >=20 > Thanks, > Mary and Francois. >=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, June 11, 2009 12:45 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : An Extension to the Session Initiation > Protocol (SIP) for Request History Information > Author(s) : M. Barnes, F. Audet > Filename : draft-barnes-sipcore-rfc4244bis-01.txt > Pages : 42 > Date : 2009-06-11 >=20 > This document defines a standard mechanism for capturing the history > information associated with a Session Initiation Protocol=20 > (SIP) request. > This capability enables many enhanced services by providing the > information as to how and why a call arrives at a specific application > or user. This document defines a new optional SIP header,=20 > History-Info, > for capturing the history information in requests. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc42 > 44bis-01.t > xt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > 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 mdolly@att.com Fri Jun 12 04:05:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F20943A6A70 for ; Fri, 12 Jun 2009 04:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.024 X-Spam-Level: X-Spam-Status: No, score=-106.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2J33EE65WEuI for ; Fri, 12 Jun 2009 04:05:10 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 418FC3A685A for ; Fri, 12 Jun 2009 04:05:10 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-15.tower-129.messagelabs.com!1244804716!18652763!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 27091 invoked from network); 12 Jun 2009 11:05:17 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-15.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Jun 2009 11:05:17 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5CB5GGt014774 for ; Fri, 12 Jun 2009 07:05:16 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5CB5DPF014754 for ; Fri, 12 Jun 2009 07:05:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 12 Jun 2009 07:05:12 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD4803@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Milestone to revise RFC 3265 Thread-Index: AcnrRP6Px0NtU7k9QZWPNmcS0gN2+gACKodI From: "DOLLY, MARTIN C, ATTLABS" To: , Subject: Re: [sipcore] Milestone to revise RFC 3265 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 11:05:11 -0000 WWVzIHRvIGJvdGgNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogc2lwY29y ZS1ib3VuY2VzQGlldGYub3JnIDxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogU0lQQ09S RSA8c2lwY29yZUBpZXRmLm9yZz4NClNlbnQ6IEZyaSBKdW4gMTIgMDY6MDI6NTggMjAwOQ0KU3Vi amVjdDogW3NpcGNvcmVdIE1pbGVzdG9uZSB0byByZXZpc2UgUkZDIDMyNjUNCg0KRm9sa3MsDQoN CnNpbmNlIHRoZSBwdWJsaWNhdGlvbiBvZiBSRkMgMzI2NSwgd2UgaGF2ZSBnb3R0ZW4gc2lnbmlm aWNhbnQgZXhwZXJpZW5jZSANCmRlcGxveWluZyBTSVAtYmFzZWQgbm90aWZpY2F0aW9uIHN5c3Rl bXMuIEl0IGhhcyBiZWVuIHByb3Bvc2VkIHRvIHJldmlzZSANClJGQyAzMjY1IGJhc2VkIG9uIHRo YXQgZXhwZXJpZW5jZS4gV2UgaGF2ZSB0d28gcXVlc3Rpb25zIGZvciB0aGUgV0c6DQoNCjEpIHNo b3VsZCB3ZSBhZGQgYSBtaWxlc3RvbmUgdG8gb3VyIGNoYXJ0ZXIgdG8gcmV2aXNlIFJGQyAzMjY1 Pw0KDQoyKSBpZiB3ZSBhZGQgc3VjaCBhIG1pbGVzdG9uZSwgc2hvdWxkIHdlIHRha2UgdGhlIGZv bGxvd2luZyBkcmFmdCBhcyB0aGUgDQppbml0aWFsIFdHIGl0ZW0gZm9yIHRoZSBtaWxlc3RvbmU/ DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJvYWNoLXNpcGNvcmUtcmZjMzI2 NWJpcy0wMA0KDQpUaGFua3MsDQoNCkdvbnphbG8NClNJUENPUkUgY28tY2hhaXINCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcg bGlzdA0Kc2lwY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zaXBjb3JlDQo= From victor.pascual.avila@gmail.com Fri Jun 12 04:22:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 243C628C10F for ; Fri, 12 Jun 2009 04:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWq1fQUrO8e7 for ; Fri, 12 Jun 2009 04:22:37 -0700 (PDT) Received: from mail-fx0-f216.google.com (mail-fx0-f216.google.com [209.85.220.216]) by core3.amsl.com (Postfix) with ESMTP id 34CD83A67F2 for ; Fri, 12 Jun 2009 04:22:37 -0700 (PDT) Received: by fxm12 with SMTP id 12so549134fxm.37 for ; Fri, 12 Jun 2009 04:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=7sqBX/0qEGSUT5tNNqRge31cBNcliql3pVxhpMU+Ce0=; b=Ywh6jy03C3whwzwNjl1JTGKwxo5U+FY+MMVepko8jSXTNUCa4y6158Vla26KZV4+qi LABMtIjCZ0N7isT3DSSOdS7cQE6rNPsrNaVYirBWKt3wClnN6SMaAJpRm4fQ/xPUbX8t UxL4c4vdCDnV04J93l+iDY+MyWyqntdaeeYKI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=KV3iLgIJ6sB7VxG0YQQYTysFiovBvbWLmxB69Mp5z7p/OpMnVyQAks/6+frQNz3UAy 8uhmCerrWAYZMpCxI7cgpB2nUgSZwec/BjmwtX+w1UkkoDyi4dUNVqTnxwRG/0uLeRL6 C170wo+pbwve/p5NO4YvxsQFrRhzJ5aMCkbHU= MIME-Version: 1.0 Received: by 10.204.53.143 with SMTP id m15mr3505645bkg.112.1244805762606; Fri, 12 Jun 2009 04:22:42 -0700 (PDT) In-Reply-To: <4A3227D2.4020808@ericsson.com> References: <4A3227D2.4020808@ericsson.com> Date: Fri, 12 Jun 2009 13:22:42 +0200 Message-ID: <618e24240906120422u7af7f1c7p7487a2216430ba0@mail.gmail.com> From: =?UTF-8?Q?Victor_Pascual_=C3=81vila?= To: Gonzalo Camarillo , SIPCORE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] Milestone to revise RFC 3265 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 11:22:38 -0000 On Fri, Jun 12, 2009 at 12:02 PM, Gonzalo Camarillo wrote: > 1) should we add a milestone to our charter to revise RFC 3265? Yes > 2) if we add such a milestone, should we take the following draft as the > initial WG item for the milestone? > > http://tools.ietf.org/html/draft-roach-sipcore-rfc3265bis-00 Yes Cheers, --=20 Victor Pascual =C3=81vila From mary.barnes@nortel.com Fri Jun 12 06:55:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFDC03A686A for ; Fri, 12 Jun 2009 06:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.439 X-Spam-Level: X-Spam-Status: No, score=-5.439 tagged_above=-999 required=5 tests=[AWL=-1.140, BAYES_00=-2.599, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zg-c9TgYq-Dx for ; Fri, 12 Jun 2009 06:55:55 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id F26223A6918 for ; Fri, 12 Jun 2009 06:55:54 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5CDtw710845; Fri, 12 Jun 2009 13:55:58 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 08:57:42 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E787F1B@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAQbmAABQZkXAAEAyU8A== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Christer Holmberg" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 13:55:57 -0000 Hi Christer, The problem I have is that it is very difficult to discern exactly how = you all are proposing to tag the entities in terms of core RFC 3261 = functionality. Yes, we had a small thread of discussion amongst the = authors with no conclusion, but Francois did put forth the exact changes = proposed in RFC 4244.... -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Friday, June 12, 2009 1:20 AM To: Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi Mary, I will look at your comments more in detail later, but just to clarify = one thing: The idea - which you also are very aware about - IS to eventually put = the normative target uri text into 4244bis. The reason we haven't done = that yet is because we couldn't agree on the approache, and therefor the = decission was to keep one approach in the target uri draft for now, so = that we have both approaches properly documented. Regards. Christer =20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 12. kes=E4kuuta 2009 0:13 > To: Christer Holmberg; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Christer, >=20 > I reviewed the updated target-uri draft and have a few comments - well = > I reviewed the diff since there isn't a summary of changes in the > document: >=20 > 1) I had a lot of difficulty picking out the normative processing for=20 > History-Info in this document. Can you summarize the differences? >=20 > 2) The reason I'm concerned about understanding how this fits with the = > current normative processing is because I'm not seeing precisely when=20 > these tags are added as the terminology is different than that used in = > RFC 4244 - i.e., are these two terms equivalent: > RFC 4244: > "... hi-entry received in the request being forwarded." >=20 > target-uri: > "...hi-entry recording the incoming request URI." >=20 > There is no reference in terms of current History-Info processing as=20 > to when in the request processing these tags are added. >=20 > 3) In particular, I'm having difficulty with this text in section 6: =20 > "When a home proxy receives a request for a user or resource for=20 > which > is abstract location function returns registered contacts or > configured URIs, the proxy adds two History-Info header field=20 > values. > The first is the incoming request URI. Since the Request-URI > identifies a user or resource for which it has a registration or > configuration, the Request-URI is an AOR and thus an address for=20 > the > user. The proxy adds a History-Info header field parameter, "aor", > which indicates this. Next, the proxy inserts the contact URI=20 > which > will be contained in the outgoing Request-URI." > Currently, in RFC 4244, the proxy only adds that additional > (first) hi-entry IF there wasn't one in the incoming request, since=20 > the UAC can initially add one when it builds the request. So, this is=20 > inconsistent with current RFC 4244. And, I think you need to define=20 > "home" proxy - that's not an RFC > 3261 term - there is the concept of a "home" domain.=20 >=20 > 4) There is a bug in the Syntax (section 9) - the Index is not=20 > optional (that is an error we have fixed in the 4244bis). >=20 > 5) I'm really confused about this two-stage tagging - how does that=20 > happen in the context of the determination of Request Targets in=20 > section > 16.5 of RFC3261? Wouldn't the decisions as to the addition of the two=20 > different tags occur at the same time and thus what is the advantage=20 > of the defining the two tags - i.e., why not one tag for each=20 > combination? > Also, are you proposing that the addition of the tags be mandatory -=20 > there is no normative language in the target-uri document, so it's=20 > impossible to tell. And, if you are proposing they be mandatory, your = > ABNF syntax needs to reflect that, thus defining a single parameter=20 > with multiple values would be necessary (which is the approach in=20 > 4244bis). >=20 >=20 > 6) What is the difference (or is there a difference?) between the=20 > functionality associated with the tags in 4244bis and the tags defined = > in this document in terms of types of retargets that are being tagged? > I think this is the crux of what we need to agree - i.e., why aren't=20 > the 4244bis tags sufficient? If there is no logical difference and=20 > it's just the words used to define the tags, then we're very close to=20 > agreement. >=20 > Regards, > Mary.=20 >=20 >=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, June 11, 2009 3:32 PM > To: Christer Holmberg; Barnes, Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Here is the link to the latest version of the target-uri draft: >=20 > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-de livery-00. > txt >=20 > -----Original Message----- > From: Christer Holmberg > Sent: Thursday, June 11, 2009 11:31 PM > To: 'Mary Barnes'; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi, >=20 > I think it is important to mention that there are still different=20 > approaches regarding the target uri delivery, and that there is=20 > another approach described in the latest version of the target-uri=20 > delivery draft (I am not sure it appears in the archieves, though, for = > some reason). Both approaches are based on History-Info, though. >=20 > We haven't yet been able to agree on an approach, so we thought the=20 > best is to bring it to the list in order for other people to get=20 > involved. >=20 > Regards, >=20 > Christer >=20 > =20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > Behalf Of Mary Barnes > Sent: Thursday, June 11, 2009 9:05 PM > To: sipcore@ietf.org > Subject: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hi folks, >=20 > We have made a few changes to this document which was submitted last=20 > week just to tie up some loose ends and inconsistencies, some of which = > Shida identified when he reviewed the -00 version. >=20 > The following summarizes the high level changes in the=20 > sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San > Francisco: > 1) Renamed the "retarget" parameter to "target" and defined explicit=20 > tags to reflect the various mechanisms by which a Request is=20 > retargeted. > All entries are now tagged.=20 > 2) Updated redirect server processing as the redirect server must=20 > capture the "target" parameter since it is the entity that knows the=20 > specific mechanism by which the new target has been determined. > 3) Changed the privacy such that rather than removing entries based on = > the various values of the privacy header, the entries are recommended=20 > to be anonymized. > 4) Updated security section > 5) Updated examples to reflect the new parameter, use loose routing=20 > and fix errors/nits. > 6) Editorial changes to remove redundant text and the convuluted text=20 > around optionality in the non-normative sections, which is now=20 > discussed appropriately in the context of the histinfo option tag. >=20 > The detailed changes between the versions are summarized in the=20 > document. >=20 > If you're wanting to look at a diff, I would recommend you diff=20 > against RFC 4244 rather than the earlier 4244bis documents. >=20 > We'd really appreciate feedback on this approach to precisely tagging=20 > all the entries. We believe it is comprehensive and should suffice for = > all the use cases identified in the target-uri document, as well as=20 > any others that might arise. >=20 > Thanks, > Mary and Francois. >=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: Thursday, June 11, 2009 12:45 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 > Title : An Extension to the Session Initiation > Protocol (SIP) for Request History Information > Author(s) : M. Barnes, F. Audet > Filename : draft-barnes-sipcore-rfc4244bis-01.txt > Pages : 42 > Date : 2009-06-11 >=20 > This document defines a standard mechanism for capturing the history=20 > information associated with a Session Initiation Protocol > (SIP) request. > This capability enables many enhanced services by providing the=20 > information as to how and why a call arrives at a specific application = > or user. This document defines a new optional SIP header,=20 > History-Info, for capturing the history information in requests. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc42 44bis-01.t > xt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. >=20 From bcampen@estacado.net Fri Jun 12 06:56:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0778B3A68A9 for ; Fri, 12 Jun 2009 06:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-zMj3cJFG3b for ; Fri, 12 Jun 2009 06:56:07 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id B9B473A686A for ; Fri, 12 Jun 2009 06:56:06 -0700 (PDT) Received: from dn3-233.estacado.net (dn3-233.estacado.net [172.16.3.233]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n5CDtZS3002922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Jun 2009 08:56:09 -0500 (CDT) (envelope-from bcampen@estacado.net) Message-Id: <68C626DF-76DB-4849-A7FC-FDB84AE2A576@estacado.net> From: Byron Campen To: Gonzalo Camarillo In-Reply-To: <4A3227D2.4020808@ericsson.com> Content-Type: multipart/signed; boundary=Apple-Mail-13-219796874; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 08:56:09 -0500 References: <4A3227D2.4020808@ericsson.com> X-Mailer: Apple Mail (2.935.3) Cc: SIPCORE Subject: Re: [sipcore] Milestone to revise RFC 3265 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 13:56:08 -0000 --Apple-Mail-13-219796874 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Yes. Best regards, Byron Campen > Folks, > > since the publication of RFC 3265, we have gotten significant > experience deploying SIP-based notification systems. It has been > proposed to revise RFC 3265 based on that experience. We have two > questions for the WG: > > 1) should we add a milestone to our charter to revise RFC 3265? > > 2) if we add such a milestone, should we take the following draft as > the initial WG item for the milestone? > > http://tools.ietf.org/html/draft-roach-sipcore-rfc3265bis-00 > > Thanks, > > Gonzalo > SIPCORE co-chair > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail-13-219796874 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGZDCCAx0w ggKGoAMCAQICEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDkyMzA0MzgwNFoXDTA5MDkyMzA0Mzgw NFowazEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQxIzAhBgkqhkiG9w0BCQEWFGRvY2ZhcmFkYXlAZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIGiyvzQgsqDjR3TiFTO4nkc/VRo/eX6xKu ky4CR2QtnIPEWhNLbU5UgXdGzU3YWx/cRj5alT0auKVQ/BnjCbf3bFSzP5mIfV6KlJV89dpxKQQA 3FaDYxE3whiRPIjQh3nmqxSacBTLohlt/g8MlFyiHoNs3XcH83M3QMjMxU8pD7SgXUDaXdtqC8vV +7g3rzPmlONdJ+4vac159wuZe37WVTsFI4sYL3p/KvqT1NZhmn1cmOVWKfCVAdGLk8VEUZtWuSeM NU5CLnFvenxaSPkDeVR5h0qDpw4DQyHfWXQuKvRs1WgVeHASz87EPgncyp90yiByetvE0WIBGKiz 0QIDAQABo0cwRTA1BgNVHREELjAsgRRiY2FtcGVuQGVzdGFjYWRvLm5ldIEUZG9jZmFyYWRheUBn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQANmDZo4t+1SrO9nb8KfjN4 QtlV1gzaAa2jEsAZ369PBXdsxVz32a1JIa1KudXFfMMxtF1NRDJ0Z3ib/qq+L8B28IpkYgRWtRr+ WWm6LzJ6rm1Q85cC0VSqoIRr+NoRZjaBdqWbJC4QsPnwVSXN9jLMLkFkjcxVDSxQtEx6v1PF9zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUP SAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0Eu Y3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2f Ni/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH 1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQW7SrCyoCwnsms5MfcqmjmzAJBgUr DgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2 MTIxMzU2MDlaMCMGCSqGSIb3DQEJBDEWBBRLtPOGKGtiOIIVWZEdRaFwJ27T1jCBhQYJKwYBBAGC NxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsq AsJ7JrOTH3Kpo5swgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEBBQAEggEAKvFe Y0QdqaP27wdHTspjC/VBH9VEE9FsPQ6ND+YAhvQAbVyzWDXuExPTnZdHMnsfhn1662S06giqi4GB 76ZfhkRFJsNNqKbMz7Ud+ej/Kzhb5MSpM0NnoYpbJUKhxbhzFj1yBoM3IuTasqkm9QiTLJoFweKy pSsZICLpqyQILBEzVlufs/RHf7fYU4R2EljMZDKzxyG22vF/oVBJM5QWZqjZzP6T+twC1Ezlz5Yq nRu7ay8udKFNxtOGuGLWd3RFb+woyWv1C11sTwbu1yWj2To1PtMZq7dtYIJZ/sz/IZ2bSY9wd00y ALjNZGlb1WnXjUYV+4RKCO8ra3B0kTU54AAAAAAAAA== --Apple-Mail-13-219796874-- From mary.barnes@nortel.com Fri Jun 12 06:59:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A353A67E7 for ; Fri, 12 Jun 2009 06:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.402 X-Spam-Level: X-Spam-Status: No, score=-5.402 tagged_above=-999 required=5 tests=[AWL=-1.103, BAYES_00=-2.599, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h67KC1q776mj for ; Fri, 12 Jun 2009 06:59:09 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 783213A67E2 for ; Fri, 12 Jun 2009 06:59:09 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5CDvrR11625; Fri, 12 Jun 2009 13:57:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 09:01:37 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E787F33@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAQbmAABQZkXAAEAyU8AAAH2Hw References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Christer Holmberg" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 13:59:11 -0000 =20 Hi Christer, Sorry, I hit send before I finished...=20 So, I am trying to figure out why we have the differences and have = difficulty because I cannot understand how this solution is fitting with = core SIP processing in section 16.5 in terms of determining Request = targets and am confused about the double tagging. So, it is quite = difficult to sift through the differences in the solution proposal if we = are not starting from common ground in terms of how the hi-entries are = added, etc.=20 I will respond separately to Hans' email on the services that are = suggested not to be supported by 4244bis. =20 Mary.=20 -----Original Message----- From: Barnes, Mary (RICH2:AR00)=20 Sent: Friday, June 12, 2009 8:58 AM To: 'Christer Holmberg'; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi Christer, The problem I have is that it is very difficult to discern exactly how = you all are proposing to tag the entities in terms of core RFC 3261 = functionality. Yes, we had a small thread of discussion amongst the = authors with no conclusion, but Francois did put forth the exact changes = proposed in RFC 4244.... -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, June 12, 2009 1:20 AM To: Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi Mary, I will look at your comments more in detail later, but just to clarify = one thing: The idea - which you also are very aware about - IS to eventually put = the normative target uri text into 4244bis. The reason we haven't done = that yet is because we couldn't agree on the approache, and therefor the = decission was to keep one approach in the target uri draft for now, so = that we have both approaches properly documented. Regards. Christer =20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 12. kes=E4kuuta 2009 0:13 > To: Christer Holmberg; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Christer, >=20 > I reviewed the updated target-uri draft and have a few comments - well = > I reviewed the diff since there isn't a summary of changes in the > document: >=20 > 1) I had a lot of difficulty picking out the normative processing for=20 > History-Info in this document. Can you summarize the differences? >=20 > 2) The reason I'm concerned about understanding how this fits with the = > current normative processing is because I'm not seeing precisely when=20 > these tags are added as the terminology is different than that used in = > RFC 4244 - i.e., are these two terms equivalent: > RFC 4244: > "... hi-entry received in the request being forwarded." >=20 > target-uri: > "...hi-entry recording the incoming request URI." >=20 > There is no reference in terms of current History-Info processing as=20 > to when in the request processing these tags are added. >=20 > 3) In particular, I'm having difficulty with this text in section 6: =20 > "When a home proxy receives a request for a user or resource for=20 > which > is abstract location function returns registered contacts or > configured URIs, the proxy adds two History-Info header field=20 > values. > The first is the incoming request URI. Since the Request-URI > identifies a user or resource for which it has a registration or > configuration, the Request-URI is an AOR and thus an address for=20 > the > user. The proxy adds a History-Info header field parameter, "aor", > which indicates this. Next, the proxy inserts the contact URI=20 > which > will be contained in the outgoing Request-URI." > Currently, in RFC 4244, the proxy only adds that additional > (first) hi-entry IF there wasn't one in the incoming request, since=20 > the UAC can initially add one when it builds the request. So, this is=20 > inconsistent with current RFC 4244. And, I think you need to define=20 > "home" proxy - that's not an RFC > 3261 term - there is the concept of a "home" domain.=20 >=20 > 4) There is a bug in the Syntax (section 9) - the Index is not=20 > optional (that is an error we have fixed in the 4244bis). >=20 > 5) I'm really confused about this two-stage tagging - how does that=20 > happen in the context of the determination of Request Targets in=20 > section > 16.5 of RFC3261? Wouldn't the decisions as to the addition of the two=20 > different tags occur at the same time and thus what is the advantage=20 > of the defining the two tags - i.e., why not one tag for each=20 > combination? > Also, are you proposing that the addition of the tags be mandatory -=20 > there is no normative language in the target-uri document, so it's=20 > impossible to tell. And, if you are proposing they be mandatory, your = > ABNF syntax needs to reflect that, thus defining a single parameter=20 > with multiple values would be necessary (which is the approach in=20 > 4244bis). >=20 >=20 > 6) What is the difference (or is there a difference?) between the=20 > functionality associated with the tags in 4244bis and the tags defined = > in this document in terms of types of retargets that are being tagged? > I think this is the crux of what we need to agree - i.e., why aren't=20 > the 4244bis tags sufficient? If there is no logical difference and=20 > it's just the words used to define the tags, then we're very close to=20 > agreement. >=20 > Regards, > Mary.=20 >=20 >=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Thursday, June 11, 2009 3:32 PM > To: Christer Holmberg; Barnes, Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Here is the link to the latest version of the target-uri draft: >=20 > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-de livery-00. > txt >=20 > -----Original Message----- > From: Christer Holmberg > Sent: Thursday, June 11, 2009 11:31 PM > To: 'Mary Barnes'; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi, >=20 > I think it is important to mention that there are still different=20 > approaches regarding the target uri delivery, and that there is=20 > another approach described in the latest version of the target-uri=20 > delivery draft (I am not sure it appears in the archieves, though, for = > some reason). Both approaches are based on History-Info, though. >=20 > We haven't yet been able to agree on an approach, so we thought the=20 > best is to bring it to the list in order for other people to get=20 > involved. >=20 > Regards, >=20 > Christer >=20 > =20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > Behalf Of Mary Barnes > Sent: Thursday, June 11, 2009 9:05 PM > To: sipcore@ietf.org > Subject: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hi folks, >=20 > We have made a few changes to this document which was submitted last=20 > week just to tie up some loose ends and inconsistencies, some of which = > Shida identified when he reviewed the -00 version. >=20 > The following summarizes the high level changes in the=20 > sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San > Francisco: > 1) Renamed the "retarget" parameter to "target" and defined explicit=20 > tags to reflect the various mechanisms by which a Request is=20 > retargeted. > All entries are now tagged.=20 > 2) Updated redirect server processing as the redirect server must=20 > capture the "target" parameter since it is the entity that knows the=20 > specific mechanism by which the new target has been determined. > 3) Changed the privacy such that rather than removing entries based on = > the various values of the privacy header, the entries are recommended=20 > to be anonymized. > 4) Updated security section > 5) Updated examples to reflect the new parameter, use loose routing=20 > and fix errors/nits. > 6) Editorial changes to remove redundant text and the convuluted text=20 > around optionality in the non-normative sections, which is now=20 > discussed appropriately in the context of the histinfo option tag. >=20 > The detailed changes between the versions are summarized in the=20 > document. >=20 > If you're wanting to look at a diff, I would recommend you diff=20 > against RFC 4244 rather than the earlier 4244bis documents. >=20 > We'd really appreciate feedback on this approach to precisely tagging=20 > all the entries. We believe it is comprehensive and should suffice for = > all the use cases identified in the target-uri document, as well as=20 > any others that might arise. >=20 > Thanks, > Mary and Francois. >=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: Thursday, June 11, 2009 12:45 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 > Title : An Extension to the Session Initiation > Protocol (SIP) for Request History Information > Author(s) : M. Barnes, F. Audet > Filename : draft-barnes-sipcore-rfc4244bis-01.txt > Pages : 42 > Date : 2009-06-11 >=20 > This document defines a standard mechanism for capturing the history=20 > information associated with a Session Initiation Protocol > (SIP) request. > This capability enables many enhanced services by providing the=20 > information as to how and why a call arrives at a specific application = > or user. This document defines a new optional SIP header,=20 > History-Info, for capturing the history information in requests. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc42 44bis-01.t > xt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. >=20 From mary.barnes@nortel.com Fri Jun 12 07:09:13 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CA7B3A6A3B for ; Fri, 12 Jun 2009 07:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQlmVR-C0Ufh for ; Fri, 12 Jun 2009 07:09:11 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 3E0163A6765 for ; Fri, 12 Jun 2009 07:09:11 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5CE9F717180; Fri, 12 Jun 2009 14:09:15 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EB67.424EB8BA" Date: Fri, 12 Jun 2009 09:11:01 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E787F80@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0906120138y540f7c2bja62adcf942cba3a0@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnrOSJUIxJUTr4ARKW042266Sxg/gALUlJA References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120138y540f7c2bja62adcf942cba3a0@mail.gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 14:09:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EB67.424EB8BA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hans, =20 A couple comments below [MB]. =20 Mary. ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Friday, June 12, 2009 3:38 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi Mary, Sure when we agree on the way forward we have to resolve all these detailed procedures and conform to the 4244 language etc. But we already agreed to integrate it into 4424bis at the moment that there is agreement about the solution.=20 Regarding the two tag approach that is open for discussion, i think it is more clean and in general pays off to separate concepts that are independent from each other. For example a hi-entry may be routed and not be an AOR, whereas it may also be routed and also an AOR. The decisions to be taken for additions of these tags are independent, so there is also no need to intertwine procedural text for them. (It is also more clear for implementors.)=20 [MB] This is where my major confusion is in that you say the tags are independent, BUT where in the normative RFC 3261 processing does this occur? I'm confused because the logic in section 16.5 isn't "multi-stage" (for lack of a better term), the incoming request URI is evaluated and then the new target list is constructed The tagging in 4244 is based on the mechanism by which a new target is determined . The previous hi-entry (that in the incoming request) is tagged at the point the request is being forwarded. I do agree that in the internal processing that information needs to exist so that the tagging at the point of forwarding the request is appropriate. [/MB] =20 BR, /Hans Erik van Elburg On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes wrote: Christer, =09 I reviewed the updated target-uri draft and have a few comments - well I reviewed the diff since there isn't a summary of changes in the document: =09 1) I had a lot of difficulty picking out the normative processing for History-Info in this document. Can you summarize the differences? =09 2) The reason I'm concerned about understanding how this fits with the current normative processing is because I'm not seeing precisely when these tags are added as the terminology is different than that used in RFC 4244 - i.e., are these two terms equivalent: RFC 4244: "... hi-entry received in the request being forwarded." =09 target-uri: "...hi-entry recording the incoming request URI." =09 There is no reference in terms of current History-Info processing as to when in the request processing these tags are added. =09 3) In particular, I'm having difficulty with this text in section 6: "When a home proxy receives a request for a user or resource for which is abstract location function returns registered contacts or configured URIs, the proxy adds two History-Info header field values. The first is the incoming request URI. Since the Request-URI identifies a user or resource for which it has a registration or configuration, the Request-URI is an AOR and thus an address for the user. The proxy adds a History-Info header field parameter, "aor", which indicates this. Next, the proxy inserts the contact URI which will be contained in the outgoing Request-URI." Currently, in RFC 4244, the proxy only adds that additional (first) hi-entry IF there wasn't one in the incoming request, since the UAC can initially add one when it builds the request. So, this is inconsistent with current RFC 4244. And, I think you need to define "home" proxy - that's not an RFC 3261 term - there is the concept of a "home" domain. =09 4) There is a bug in the Syntax (section 9) - the Index is not optional (that is an error we have fixed in the 4244bis). =09 5) I'm really confused about this two-stage tagging - how does that happen in the context of the determination of Request Targets in section 16.5 of RFC3261? Wouldn't the decisions as to the addition of the two different tags occur at the same time and thus what is the advantage of the defining the two tags - i.e., why not one tag for each combination? Also, are you proposing that the addition of the tags be mandatory - there is no normative language in the target-uri document, so it's impossible to tell. And, if you are proposing they be mandatory, your ABNF syntax needs to reflect that, thus defining a single parameter with multiple values would be necessary (which is the approach in 4244bis). =09 =09 6) What is the difference (or is there a difference?) between the functionality associated with the tags in 4244bis and the tags defined in this document in terms of types of retargets that are being tagged? I think this is the crux of what we need to agree - i.e., why aren't the 4244bis tags sufficient? If there is no logical difference and it's just the words used to define the tags, then we're very close to agreement. =09 Regards, Mary. =09 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Thursday, June 11, 2009 3:32 PM =09 To: Christer Holmberg; Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt =09 =09 Here is the link to the latest version of the target-uri draft: =09 =09 http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00. txt =20 =09 -----Original Message----- From: Christer Holmberg Sent: Thursday, June 11, 2009 11:31 PM To: 'Mary Barnes'; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt =09 =09 Hi, =09 I think it is important to mention that there are still different approaches regarding the target uri delivery, and that there is another approach described in the latest version of the target-uri delivery draft (I am not sure it appears in the archieves, though, for some reason). Both approaches are based on History-Info, though. =09 We haven't yet been able to agree on an approach, so we thought the best is to bring it to the list in order for other people to get involved. =09 Regards, =09 Christer =09 =09 =09 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, June 11, 2009 9:05 PM To: sipcore@ietf.org Subject: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt =09 Hi folks, =09 We have made a few changes to this document which was submitted last week just to tie up some loose ends and inconsistencies, some of which Shida identified when he reviewed the -00 version. =09 The following summarizes the high level changes in the sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San Francisco: 1) Renamed the "retarget" parameter to "target" and defined explicit tags to reflect the various mechanisms by which a Request is retargeted. All entries are now tagged. 2) Updated redirect server processing as the redirect server must capture the "target" parameter since it is the entity that knows the specific mechanism by which the new target has been determined. 3) Changed the privacy such that rather than removing entries based on the various values of the privacy header, the entries are recommended to be anonymized. 4) Updated security section 5) Updated examples to reflect the new parameter, use loose routing and fix errors/nits. 6) Editorial changes to remove redundant text and the convuluted text around optionality in the non-normative sections, which is now discussed appropriately in the context of the histinfo option tag. =09 The detailed changes between the versions are summarized in the document. =09 If you're wanting to look at a diff, I would recommend you diff against RFC 4244 rather than the earlier 4244bis documents. =09 We'd really appreciate feedback on this approach to precisely tagging all the entries. We believe it is comprehensive and should suffice for all the use cases identified in the target-uri document, as well as any others that might arise. =09 Thanks, Mary and Francois. =09 -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, June 11, 2009 12:45 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt =09 A New Internet-Draft is available from the on-line Internet-Drafts directories. =09 Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, F. Audet Filename : draft-barnes-sipcore-rfc4244bis-01.txt Pages : 42 Date : 2009-06-11 =09 This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. =09 A URL for this Internet-Draft is: =09 http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01.t xt =20 =09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =09 ------_=_NextPart_001_01C9EB67.424EB8BA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Hans,
 
A=20 couple comments below [MB].
 
Mary.

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Friday, June 12, 2009 = 3:38=20 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer = Holmberg;=20 sipcore@ietf.org
Subject: Re: [sipcore] FW: I-D=20 Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi Mary,

Sure when we agree on the way forward we have to = resolve=20 all these detailed procedures and conform to the 4244 language etc. But = we=20 already agreed to integrate it into 4424bis at the moment that there is=20 agreement about the solution.

Regarding the two tag approach = that is=20 open for discussion, i think it is more clean and in general pays off to = separate concepts that are independent from each other. For example a = hi-entry=20 may be routed and not be an AOR, whereas it may also be routed and also = an AOR.=20 The decisions to be taken for additions of these tags are independent, = so there=20 is also no need to intertwine procedural text for them. (It is also more = clear=20 for implementors.) 
[MB] This is where my major confusion is in that you say = the tags=20 are independent, BUT where in the normative RFC 3261 processing does = this=20 occur?  I'm confused because the logic in section 16.5 = isn't=20 "multi-stage" (for lack of a better term), the incoming request URI = is=20 evaluated and then the new target list is constructed   The = tagging in=20 4244 is based on the mechanism by which a new target is = determined . =20 The previous hi-entry (that in the incoming request) is tagged at the = point the=20 request is being forwarded. I do agree that in the internal processing = that=20 information needs to exist so that the tagging at the point of = forwarding the request is appropriate.  [/MB]
 


BR,
/Hans Erik van Elburg

On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes = <mary.barnes@nortel.com>=20 wrote:
Christer,

I=20 reviewed the updated target-uri draft and have a few comments - well=20 I
reviewed the diff since there isn't a summary of changes in=20 the
document:

1) I had a lot of difficulty picking out the = normative=20 processing for
History-Info in this document. Can you summarize the = differences?

2) The reason I'm concerned about understanding = how this=20 fits with the
current normative processing is because I'm not = seeing=20 precisely when
these tags are added as the terminology is different = than=20 that used in
RFC 4244 - i.e., are these two terms = equivalent:
RFC=20 4244:
"... hi-entry received in the request being=20 forwarded."

target-uri:
"...hi-entry recording the incoming = request=20 URI."

There is no reference in terms of current History-Info = processing=20 as to
when in the request processing these tags are = added.

3) In=20 particular, I'm having difficulty with this text in section = 6:
  "When=20 a home proxy receives a request for a user or resource = for
which
 =20 is abstract location function returns registered contacts or
  = configured URIs, the proxy adds two History-Info header field=20 values.
  The first is the incoming request URI.  Since = the=20 Request-URI
  identifies a user or resource for which it has a = registration or
  configuration, the Request-URI is an AOR and = thus an=20 address for the
  user.  The proxy adds a History-Info = header=20 field parameter, "aor",
  which indicates this.  Next, = the proxy=20 inserts the contact URI which
  will be contained in the = outgoing=20 Request-URI."
Currently, in RFC 4244, the proxy only adds that = additional=20 (first)
hi-entry IF there wasn't one in the incoming request, since = the UAC=20 can
initially add one when it builds the request. So, this is=20 inconsistent
with current RFC 4244. And, I think you need to define = "home"=20 proxy -
that's not an RFC 3261 term - there is the concept of a = "home"=20 domain.

4) There is a bug in the Syntax (section 9) - the Index = is not=20 optional
(that is an error we have fixed in the 4244bis).

5) = I'm=20 really confused about this two-stage tagging - how does that
happen = in the=20 context of the determination of Request Targets in section
16.5 of = RFC3261?=20 Wouldn't the decisions as to the addition of the two
different tags = occur=20 at the same time and thus what is the advantage of
the defining the = two=20 tags - i.e., why not one tag for each combination?
Also, are you = proposing=20 that the addition of the tags be mandatory -
there is no normative = language=20 in the target-uri document, so it's
impossible to tell.  And, = if you=20 are proposing they be mandatory, your
ABNF syntax needs to reflect = that,=20 thus defining a single parameter with
multiple values would be = necessary=20 (which is the approach in 4244bis).


6) What is the = difference (or=20 is there a difference?) between the
functionality associated with = the tags=20 in 4244bis and the tags defined
in this document in terms of types = of=20 retargets that are being tagged?
I think this is the crux of what = we need=20 to agree - i.e., why aren't the
4244bis tags sufficient?  If = there is=20 no logical difference and it's
just the words used to define the = tags, then=20 we're very close to
agreement.

Regards,
Mary.



-----Original Message-----
From: = Christer=20 Holmberg [mailto:christer.holmberg@ericsson= .com]
Sent:=20 Thursday, June 11, 2009 3:32 PM
To: Christer Holmberg; Barnes, Mary (RICH2:AR00); sipcore@ietf.org
Subject: RE: = [sipcore]=20 FW: = I-D
Action:draft-barnes-sipcore-rfc4244bis-01.txt


Here is=20 the link to the latest version of the target-uri draft:

http://tools.ietf.org/id/draft-rosenberg-sipcore-target-u= ri-delivery-00.
txt

-----Original=20 Message-----
From: Christer Holmberg
Sent: Thursday, June 11, = 2009 11:31=20 PM
To: 'Mary Barnes'; sipcore@ietf.org
Subject: RE: = [sipcore]=20 FW:=20 = I-D
Action:draft-barnes-sipcore-rfc4244bis-01.txt


Hi,
I=20 think it is important to mention that there are still = different
approaches=20 regarding the target uri delivery, and that there is = another
approach=20 described in the latest version of the target-uri delivery
draft (I = am not=20 sure it appears in the archieves, though, for some
reason). Both = approaches=20 are based on History-Info, though.

We haven't yet been able to = agree on=20 an approach, so we thought the best
is to bring it to the list in = order for=20 other people to get=20 involved.

Regards,

Christer



-----Original = Message-----
From: sipcore-bounces@ietf.org = [mailto:sipcore-bounces@ietf.org] = On
Behalf Of Mary Barnes
Sent: Thursday, June 11, 2009 9:05 = PM
To: sipcore@ietf.org
Subject: = [sipcore] FW:=20 I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi = folks,

We=20 have made a few changes to this document which was submitted = last
week just=20 to tie up some loose ends and inconsistencies, some of which
Shida=20 identified when he reviewed the -00 version.

The following = summarizes=20 the high level changes in the
sipcore-rfc4244bis from the = sip-rfc4244bis=20 that we discussed in San
Francisco:
1) Renamed the "retarget" = parameter=20 to "target" and defined explicit
tags to reflect the various = mechanisms by=20 which a Request is retargeted.
All entries are now tagged.
2) = Updated=20 redirect server processing as the redirect server must
capture the = "target"=20 parameter since it is the entity that knows the
specific mechanism = by which=20 the new target has been determined.
3) Changed the privacy such = that rather=20 than removing entries based on
the various values of the privacy = header,=20 the entries are recommended to
be anonymized.
4) Updated = security=20 section
5) Updated examples to reflect the new parameter, use loose = routing=20 and
fix errors/nits.
6) Editorial changes to remove redundant = text and=20 the convuluted text
around optionality in the non-normative = sections, which=20 is now discussed
appropriately in the context of the histinfo = option=20 tag.

The detailed changes between the versions are summarized = in=20 the
document.

If you're wanting to look at a diff, I would = recommend=20 you diff against
RFC 4244 rather than the earlier 4244bis=20 documents.

We'd really appreciate feedback on this approach to=20 precisely tagging
all the entries. We believe it is comprehensive = and=20 should suffice for
all the use cases identified in the target-uri = document,=20 as well as any
others that might arise.

Thanks,
Mary and=20 Francois.

-----Original Message-----
From: i-d-announce-bounces@ietf.o= rg
[mailto:i-d-announce-bounces@ietf.o= rg]=20 On Behalf Of
Internet-Drafts@ietf.org
= Sent:=20 Thursday, June 11, 2009 12:45 PM
To: i-d-announce@ietf.org
Subjec= t: I-D=20 Action:draft-barnes-sipcore-rfc4244bis-01.txt

A New = Internet-Draft is=20 available from the on-line = Internet-Drafts
directories.

 =20      Title           : An = Extension to=20 the Session Initiation
Protocol (SIP) for Request History=20 Information
       Author(s)     =   : M.=20 Barnes, F. Audet
       Filename     =  =20  : draft-barnes-sipcore-rfc4244bis-01.txt
      =  Pages           : 42
    =  =20  Date            : = 2009-06-11

This=20 document defines a standard mechanism for capturing the = history
information=20 associated with a Session Initiation Protocol (SIP) request.
This=20 capability enables many enhanced services by providing = the
information as=20 to how and why a call arrives at a specific application
or user. =  This=20 document defines a new optional SIP header, History-Info,
for = capturing the=20 history information in requests.

A URL for this Internet-Draft=20 is:
http://www.ietf.org/internet-drafts/draft-barnes-sipcore-= rfc4244bis-01.t
xt

Internet-Drafts=20 are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below = is the data=20 which will enable a MIME compliant mail reader
implementation to=20 automatically retrieve the ASCII version of=20 = the
Internet-Draft.
_______________________________________________=
sipcore=20 mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

------_=_NextPart_001_01C9EB67.424EB8BA-- From christer.holmberg@ericsson.com Fri Jun 12 07:11:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EE8F3A6A5F for ; Fri, 12 Jun 2009 07:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.716 X-Spam-Level: X-Spam-Status: No, score=-4.716 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkJ66U2mHeEI for ; Fri, 12 Jun 2009 07:11:53 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 11A143A6A3B for ; Fri, 12 Jun 2009 07:11:52 -0700 (PDT) X-AuditID: c1b4fb3e-b7bedae0000062bb-fe-4a326228f261 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 8C.95.25275.822623A4; Fri, 12 Jun 2009 16:11:52 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jun 2009 16:11:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 16:11:51 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E787F33@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAQbmAABQZkXAAEAyU8AAAH2HwAABz1WA= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787F33@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Mary Barnes" , X-OriginalArrivalTime: 12 Jun 2009 14:11:52.0597 (UTC) FILETIME=[BC0E1C50:01C9EB67] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 14:11:55 -0000 Hi,=20 >So, I am trying to figure out why we have the differences and=20 >have difficulty because I cannot understand how this solution=20 >is fitting with core SIP processing in section 16.5 in terms=20 >of determining Request targets and am confused about the=20 >double tagging. So, it is quite difficult to sift through=20 >the differences in the solution proposal if we are not=20 >starting from common ground in terms of how the hi-entries=20 >are added, etc.=20 I think we should start from common ground on what functional = requirements we have... Regards, Christer > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Friday, June 12, 2009 8:58 AM > To: 'Christer Holmberg'; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hi Christer, >=20 > The problem I have is that it is very difficult to discern=20 > exactly how you all are proposing to tag the entities in=20 > terms of core RFC 3261 functionality. Yes, we had a small=20 > thread of discussion amongst the authors with no conclusion,=20 > but Francois did put forth the exact changes proposed in RFC 4244.... >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, June 12, 2009 1:20 AM > To: Barnes, Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi Mary, >=20 > I will look at your comments more in detail later, but just=20 > to clarify one thing: >=20 > The idea - which you also are very aware about - IS to=20 > eventually put the normative target uri text into 4244bis.=20 > The reason we haven't done that yet is because we couldn't=20 > agree on the approache, and therefor the decission was to=20 > keep one approach in the target uri draft for now, so that we=20 > have both approaches properly documented. >=20 > Regards. >=20 > Christer >=20 > =20 >=20 > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: 12. kes=E4kuuta 2009 0:13 > > To: Christer Holmberg; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > Christer, > >=20 > > I reviewed the updated target-uri draft and have a few=20 > comments - well=20 > > I reviewed the diff since there isn't a summary of changes in the > > document: > >=20 > > 1) I had a lot of difficulty picking out the normative=20 > processing for=20 > > History-Info in this document. Can you summarize the differences? > >=20 > > 2) The reason I'm concerned about understanding how this=20 > fits with the=20 > > current normative processing is because I'm not seeing=20 > precisely when=20 > > these tags are added as the terminology is different than=20 > that used in=20 > > RFC 4244 - i.e., are these two terms equivalent: > > RFC 4244: > > "... hi-entry received in the request being forwarded." > >=20 > > target-uri: > > "...hi-entry recording the incoming request URI." > >=20 > > There is no reference in terms of current History-Info=20 > processing as=20 > > to when in the request processing these tags are added. > >=20 > > 3) In particular, I'm having difficulty with this text in=20 > section 6: =20 > > "When a home proxy receives a request for a user or resource for=20 > > which > > is abstract location function returns registered contacts or > > configured URIs, the proxy adds two History-Info header field=20 > > values. > > The first is the incoming request URI. Since the Request-URI > > identifies a user or resource for which it has a registration or > > configuration, the Request-URI is an AOR and thus an address for=20 > > the > > user. The proxy adds a History-Info header field=20 > parameter, "aor", > > which indicates this. Next, the proxy inserts the contact URI=20 > > which > > will be contained in the outgoing Request-URI." > > Currently, in RFC 4244, the proxy only adds that additional > > (first) hi-entry IF there wasn't one in the incoming request, since=20 > > the UAC can initially add one when it builds the request.=20 > So, this is=20 > > inconsistent with current RFC 4244. And, I think you need to define=20 > > "home" proxy - that's not an RFC > > 3261 term - there is the concept of a "home" domain.=20 > >=20 > > 4) There is a bug in the Syntax (section 9) - the Index is not=20 > > optional (that is an error we have fixed in the 4244bis). > >=20 > > 5) I'm really confused about this two-stage tagging - how does that=20 > > happen in the context of the determination of Request Targets in=20 > > section > > 16.5 of RFC3261? Wouldn't the decisions as to the addition=20 > of the two=20 > > different tags occur at the same time and thus what is the=20 > advantage=20 > > of the defining the two tags - i.e., why not one tag for each=20 > > combination? > > Also, are you proposing that the addition of the tags be=20 > mandatory -=20 > > there is no normative language in the target-uri document, so it's=20 > > impossible to tell. And, if you are proposing they be=20 > mandatory, your=20 > > ABNF syntax needs to reflect that, thus defining a single parameter=20 > > with multiple values would be necessary (which is the approach in=20 > > 4244bis). > >=20 > >=20 > > 6) What is the difference (or is there a difference?) between the=20 > > functionality associated with the tags in 4244bis and the=20 > tags defined=20 > > in this document in terms of types of retargets that are=20 > being tagged? > > I think this is the crux of what we need to agree - i.e.,=20 > why aren't=20 > > the 4244bis tags sufficient? If there is no logical difference and=20 > > it's just the words used to define the tags, then we're=20 > very close to=20 > > agreement. > >=20 > > Regards, > > Mary.=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Thursday, June 11, 2009 3:32 PM > > To: Christer Holmberg; Barnes, Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Here is the link to the latest version of the target-uri draft: > >=20 > > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-de > livery-00. > > txt > >=20 > > -----Original Message----- > > From: Christer Holmberg > > Sent: Thursday, June 11, 2009 11:31 PM > > To: 'Mary Barnes'; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > I think it is important to mention that there are still different=20 > > approaches regarding the target uri delivery, and that there is=20 > > another approach described in the latest version of the target-uri=20 > > delivery draft (I am not sure it appears in the archieves,=20 > though, for=20 > > some reason). Both approaches are based on History-Info, though. > >=20 > > We haven't yet been able to agree on an approach, so we thought the=20 > > best is to bring it to the list in order for other people to get=20 > > involved. > >=20 > > Regards, > >=20 > > Christer > >=20 > > =20 > >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > > Behalf Of Mary Barnes > > Sent: Thursday, June 11, 2009 9:05 PM > > To: sipcore@ietf.org > > Subject: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > Hi folks, > >=20 > > We have made a few changes to this document which was=20 > submitted last=20 > > week just to tie up some loose ends and inconsistencies,=20 > some of which=20 > > Shida identified when he reviewed the -00 version. > >=20 > > The following summarizes the high level changes in the=20 > > sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San > > Francisco: > > 1) Renamed the "retarget" parameter to "target" and defined=20 > explicit=20 > > tags to reflect the various mechanisms by which a Request is=20 > > retargeted. > > All entries are now tagged.=20 > > 2) Updated redirect server processing as the redirect server must=20 > > capture the "target" parameter since it is the entity that=20 > knows the=20 > > specific mechanism by which the new target has been determined. > > 3) Changed the privacy such that rather than removing=20 > entries based on=20 > > the various values of the privacy header, the entries are=20 > recommended=20 > > to be anonymized. > > 4) Updated security section > > 5) Updated examples to reflect the new parameter, use loose routing=20 > > and fix errors/nits. > > 6) Editorial changes to remove redundant text and the=20 > convuluted text=20 > > around optionality in the non-normative sections, which is now=20 > > discussed appropriately in the context of the histinfo option tag. > >=20 > > The detailed changes between the versions are summarized in the=20 > > document. > >=20 > > If you're wanting to look at a diff, I would recommend you diff=20 > > against RFC 4244 rather than the earlier 4244bis documents. > >=20 > > We'd really appreciate feedback on this approach to=20 > precisely tagging=20 > > all the entries. We believe it is comprehensive and should=20 > suffice for=20 > > all the use cases identified in the target-uri document, as well as=20 > > any others that might arise. > >=20 > > Thanks, > > Mary and Francois. > >=20 > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > > Internet-Drafts@ietf.org > > Sent: Thursday, June 11, 2009 12:45 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > >=20 > > Title : An Extension to the Session Initiation > > Protocol (SIP) for Request History Information > > Author(s) : M. Barnes, F. Audet > > Filename : draft-barnes-sipcore-rfc4244bis-01.txt > > Pages : 42 > > Date : 2009-06-11 > >=20 > > This document defines a standard mechanism for capturing=20 > the history=20 > > information associated with a Session Initiation Protocol > > (SIP) request. > > This capability enables many enhanced services by providing the=20 > > information as to how and why a call arrives at a specific=20 > application=20 > > or user. This document defines a new optional SIP header,=20 > > History-Info, for capturing the history information in requests. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc42 > 44bis-01.t > > xt > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=20 >=20 From pkyzivat@cisco.com Fri Jun 12 07:29:05 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B6B3A6814 for ; Fri, 12 Jun 2009 07:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txsBhbDNzFRv for ; Fri, 12 Jun 2009 07:29:04 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id DB0CE3A6765 for ; Fri, 12 Jun 2009 07:28:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,210,1243814400"; d="scan'208";a="47150570" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 12 Jun 2009 14:28:44 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5CESiV5014375; Fri, 12 Jun 2009 10:28:44 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5CESihl014009; Fri, 12 Jun 2009 14:28:44 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 10:28:44 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 10:28:43 -0400 Message-ID: <4A32661B.4090905@cisco.com> Date: Fri, 12 Jun 2009 10:28:43 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: =?UTF-8?B?VmljdG9yIFBhc2N1YWwgw4F2aWxh?= References: <4A3227D2.4020808@ericsson.com> <618e24240906120422u7af7f1c7p7487a2216430ba0@mail.gmail.com> In-Reply-To: <618e24240906120422u7af7f1c7p7487a2216430ba0@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 12 Jun 2009 14:28:43.0777 (UTC) FILETIME=[16C3EF10:01C9EB6A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=428; t=1244816924; x=1245680924; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Milestone=20to=20revise=20R FC=203265 |Sender:=20 |To:=20=3D?UTF-8?B?VmljdG9yIFBhc2N1YWwgw4F2aWxh?=3D=0A=20; bh=Hki/2avCyv5TZtVjztaOjKPSQuG2SMdO+/1DjaVumgA=; b=c0ux9yPs5pTZUzCBNW0WUCmwAQlJTdx1gKjupY7ITCnSvmAmCWYFb2Tmmw ys/w9FJIJLHvFZCP1jjkPb9ESoCRpC9G+0d755BgfMz8J7Zn3I7neSVTj2e5 yzNf3dYCbz; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Milestone to revise RFC 3265 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 14:29:05 -0000 Yes Victor Pascual Ăvila wrote: > On Fri, Jun 12, 2009 at 12:02 PM, Gonzalo > Camarillo wrote: >> 1) should we add a milestone to our charter to revise RFC 3265? > > Yes > >> 2) if we add such a milestone, should we take the following draft as the >> initial WG item for the milestone? >> >> http://tools.ietf.org/html/draft-roach-sipcore-rfc3265bis-00 > > Yes > > Cheers, From mary.barnes@nortel.com Fri Jun 12 07:30:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93EF3A6765 for ; Fri, 12 Jun 2009 07:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.37 X-Spam-Level: X-Spam-Status: No, score=-5.37 tagged_above=-999 required=5 tests=[AWL=-1.071, BAYES_00=-2.599, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gojz8yuJAwto for ; Fri, 12 Jun 2009 07:30:24 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 574DB3A6819 for ; Fri, 12 Jun 2009 07:30:24 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5CET5R18718; Fri, 12 Jun 2009 14:29:06 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 09:31:52 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E78800A@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwABgxmCAADJMXoA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> From: "Mary Barnes" To: "Christer Holmberg" , "DOLLY, MARTIN C, ATTLABS" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 14:30:26 -0000 Hi Christer, I really think one of the biggest issues here is that 4244bis is written = from the perspective of core SIP processing and entirely uses existing = constructs.=20 Let me make sure I understand your scenarios, as I think they're = obviously all related in that your 3rd point describes how things could = work with core SIP and 4244bis, which supports both your first two cases = (although see my note on your 2nd case below). I also think the = target-uri solution is convoluting how the UAS that would use = History-Info versus how History-Info is captured - that's likely why we = getting into these never ending discussions. =20 One question I have is whether or not these numbers are tel-uris? I = think they have to be for any of this to work. But, if so then your 2nd = bullet does violate core SIP functionality in that you cannot change the = target of a Request (you can only forward) if the Request-URI does not = belong to the domain of the entity doing the retargeting (per section = 16.5): "If the domain of the Request-URI indicates a domain this element is not responsible for, the Request-URI MUST be placed into the target set as the only target, and the element MUST proceed to the task of Request Forwarding (Section 16.6)." For item 1, yes the entries are tagged differently depending upon how = you configure the 800 service on the home proxy. But, that's basic SIP. = If you don't want to do item 3 below, then since these numbers have = meaning in terms of a service, you really are talking about special = flavors of URIs that the UAS can still pull out of the History-Info - = i.e., you need History-Info a URI parameter, so you move the complexity = to the UAS. =20 Mary.=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Friday, June 12, 2009 3:13 AM To: DOLLY, MARTIN C, ATTLABS; Barnes, Mary (RICH2:AR00); = sipcore@ietf.org Subject: RE: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi, The biggest difference is regarding support of service-number (like = toll-free/freephone) type-of services, where the Request-URI translation = does not change the targeted user or resource. Without going in to the = protocol differences (which aren't that big), my understanding of the = functional differences are the following: - 4244bis approach does not distinguish between service-number (like = toll-free/freephone) number translation and diversion. - 4244bis approach does not allow a service-number (like = toll-free/freephone) translation for a user which belongs to another = domain. - 4244bis requires that all service-numbers for a user/company (like = toll-free/freephone) must be registered (explicitly or implictly), which = means that the translation must be done by an entity (normally the = registrar) which has the registration information for the called user. The target uri approach does allow translation in another domain, and = does not require toll-free/freephone numbers to be registered for the = called user. So, I don't think that the 4244bis approach supports all service-numbers = (like toll-free/freephone) in a sufficient way, and that it is too = restrictive for no good reason. It imposes restrictions on the potential = business models that are not necessary. Regards, Christer=20 > -----Original Message----- > From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > Sent: 11. kes=E4kuuta 2009 23:40 > To: Christer Holmberg; Mary Barnes; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hello, >=20 > Can someone please summarize the differences between the two=20 > approaches? >=20 > Thanks, >=20 > Martin >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Thursday, June 11, 2009 4:32 PM > To: Christer Holmberg; Mary Barnes; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Here is the link to the latest version of the target-uri draft: >=20 > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-de > livery-00. > txt >=20 > -----Original Message----- > From: Christer Holmberg > Sent: Thursday, June 11, 2009 11:31 PM > To: 'Mary Barnes'; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi, >=20 > I think it is important to mention that there are still different=20 > approaches regarding the target uri delivery, and that there is=20 > another approach described in the latest version of the target-uri=20 > delivery draft (I am not sure it appears in the archieves, though, for = > some reason). Both approaches are based on History-Info, though. >=20 > We haven't yet been able to agree on an approach, so we thought the=20 > best is to bring it to the list in order for other people to get=20 > involved. >=20 > Regards, >=20 > Christer >=20 > =20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > Behalf Of Mary Barnes > Sent: Thursday, June 11, 2009 9:05 PM > To: sipcore@ietf.org > Subject: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hi folks, >=20 > We have made a few changes to this document which was submitted last=20 > week just to tie up some loose ends and inconsistencies, some of which = > Shida identified when he reviewed the -00 version. >=20 > The following summarizes the high level changes in the=20 > sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San > Francisco: > 1) Renamed the "retarget" parameter to "target" and defined explicit=20 > tags to reflect the various mechanisms by which a Request is=20 > retargeted. > All entries are now tagged.=20 > 2) Updated redirect server processing as the redirect server must=20 > capture the "target" parameter since it is the entity that knows the=20 > specific mechanism by which the new target has been determined. > 3) Changed the privacy such that rather than removing entries based on = > the various values of the privacy header, the entries are recommended=20 > to be anonymized. > 4) Updated security section > 5) Updated examples to reflect the new parameter, use loose routing=20 > and fix errors/nits. > 6) Editorial changes to remove redundant text and the convuluted text=20 > around optionality in the non-normative sections, which is now=20 > discussed appropriately in the context of the histinfo option tag. >=20 > The detailed changes between the versions are summarized in the=20 > document. >=20 > If you're wanting to look at a diff, I would recommend you diff=20 > against RFC 4244 rather than the earlier 4244bis documents. >=20 > We'd really appreciate feedback on this approach to precisely tagging=20 > all the entries. We believe it is comprehensive and should suffice for = > all the use cases identified in the target-uri document, as well as=20 > any others that might arise. >=20 > Thanks, > Mary and Francois. >=20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: Thursday, June 11, 2009 12:45 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 > Title : An Extension to the Session Initiation > Protocol (SIP) for Request History Information > Author(s) : M. Barnes, F. Audet > Filename : draft-barnes-sipcore-rfc4244bis-01.txt > Pages : 42 > Date : 2009-06-11 >=20 > This document defines a standard mechanism for capturing the history=20 > information associated with a Session Initiation Protocol > (SIP) request. > This capability enables many enhanced services by providing the=20 > information as to how and why a call arrives at a specific application = > or user. This document defines a new optional SIP header,=20 > History-Info, for capturing the history information in requests. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc42 > 44bis-01.t > xt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader=20 > implementation to automatically retrieve the ASCII version of the=20 > Internet-Draft. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From mary.barnes@nortel.com Fri Jun 12 07:32:07 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 169263A6814 for ; Fri, 12 Jun 2009 07:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.339 X-Spam-Level: X-Spam-Status: No, score=-5.339 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_00=-2.599, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nN2lYu9mkR6y for ; Fri, 12 Jun 2009 07:32:05 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 6F4B83A6765 for ; Fri, 12 Jun 2009 07:32:05 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5CEUpR19291; Fri, 12 Jun 2009 14:30:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 09:34:19 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E78801F@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAQbmAABQZkXAAEAyU8AAAH2HwAABz1WAAAL04sA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787F33@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Christer Holmberg" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 14:32:07 -0000 Hi Christer, I think we're entirely clear on the types of services that need to be = supported. It is the mechanism that we're debating. And by mechanism, I = mean how information that is meaningful to services (at a UAS) is "lost" = information as a request is retargeted.=20 Mary.=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Friday, June 12, 2009 9:12 AM To: Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi,=20 >So, I am trying to figure out why we have the differences and have=20 >difficulty because I cannot understand how this solution is fitting=20 >with core SIP processing in section 16.5 in terms of determining=20 >Request targets and am confused about the double tagging. So, it is=20 >quite difficult to sift through the differences in the solution=20 >proposal if we are not starting from common ground in terms of how the=20 >hi-entries are added, etc. I think we should start from common ground on what functional = requirements we have... Regards, Christer > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Friday, June 12, 2009 8:58 AM > To: 'Christer Holmberg'; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hi Christer, >=20 > The problem I have is that it is very difficult to discern exactly how = > you all are proposing to tag the entities in terms of core RFC 3261=20 > functionality. Yes, we had a small thread of discussion amongst the=20 > authors with no conclusion, but Francois did put forth the exact=20 > changes proposed in RFC 4244.... >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, June 12, 2009 1:20 AM > To: Barnes, Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi Mary, >=20 > I will look at your comments more in detail later, but just to clarify = > one thing: >=20 > The idea - which you also are very aware about - IS to eventually put = > the normative target uri text into 4244bis. > The reason we haven't done that yet is because we couldn't agree on=20 > the approache, and therefor the decission was to keep one approach in=20 > the target uri draft for now, so that we have both approaches properly = > documented. >=20 > Regards. >=20 > Christer >=20 > =20 >=20 > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: 12. kes=E4kuuta 2009 0:13 > > To: Christer Holmberg; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > Christer, > >=20 > > I reviewed the updated target-uri draft and have a few > comments - well > > I reviewed the diff since there isn't a summary of changes in the > > document: > >=20 > > 1) I had a lot of difficulty picking out the normative > processing for > > History-Info in this document. Can you summarize the differences? > >=20 > > 2) The reason I'm concerned about understanding how this > fits with the > > current normative processing is because I'm not seeing > precisely when > > these tags are added as the terminology is different than > that used in > > RFC 4244 - i.e., are these two terms equivalent: > > RFC 4244: > > "... hi-entry received in the request being forwarded." > >=20 > > target-uri: > > "...hi-entry recording the incoming request URI." > >=20 > > There is no reference in terms of current History-Info > processing as > > to when in the request processing these tags are added. > >=20 > > 3) In particular, I'm having difficulty with this text in > section 6: =20 > > "When a home proxy receives a request for a user or resource for=20 > > which > > is abstract location function returns registered contacts or > > configured URIs, the proxy adds two History-Info header field=20 > > values. > > The first is the incoming request URI. Since the Request-URI > > identifies a user or resource for which it has a registration or > > configuration, the Request-URI is an AOR and thus an address for=20 > > the > > user. The proxy adds a History-Info header field > parameter, "aor", > > which indicates this. Next, the proxy inserts the contact URI=20 > > which > > will be contained in the outgoing Request-URI." > > Currently, in RFC 4244, the proxy only adds that additional > > (first) hi-entry IF there wasn't one in the incoming request, since=20 > > the UAC can initially add one when it builds the request. > So, this is > > inconsistent with current RFC 4244. And, I think you need to define=20 > > "home" proxy - that's not an RFC > > 3261 term - there is the concept of a "home" domain.=20 > >=20 > > 4) There is a bug in the Syntax (section 9) - the Index is not=20 > > optional (that is an error we have fixed in the 4244bis). > >=20 > > 5) I'm really confused about this two-stage tagging - how does that=20 > > happen in the context of the determination of Request Targets in=20 > > section > > 16.5 of RFC3261? Wouldn't the decisions as to the addition > of the two > > different tags occur at the same time and thus what is the > advantage > > of the defining the two tags - i.e., why not one tag for each=20 > > combination? > > Also, are you proposing that the addition of the tags be > mandatory - > > there is no normative language in the target-uri document, so it's=20 > > impossible to tell. And, if you are proposing they be > mandatory, your > > ABNF syntax needs to reflect that, thus defining a single parameter=20 > > with multiple values would be necessary (which is the approach in=20 > > 4244bis). > >=20 > >=20 > > 6) What is the difference (or is there a difference?) between the=20 > > functionality associated with the tags in 4244bis and the > tags defined > > in this document in terms of types of retargets that are > being tagged? > > I think this is the crux of what we need to agree - i.e., > why aren't > > the 4244bis tags sufficient? If there is no logical difference and=20 > > it's just the words used to define the tags, then we're > very close to > > agreement. > >=20 > > Regards, > > Mary.=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Thursday, June 11, 2009 3:32 PM > > To: Christer Holmberg; Barnes, Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Here is the link to the latest version of the target-uri draft: > >=20 > > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-de > livery-00. > > txt > >=20 > > -----Original Message----- > > From: Christer Holmberg > > Sent: Thursday, June 11, 2009 11:31 PM > > To: 'Mary Barnes'; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > I think it is important to mention that there are still different=20 > > approaches regarding the target uri delivery, and that there is=20 > > another approach described in the latest version of the target-uri=20 > > delivery draft (I am not sure it appears in the archieves, > though, for > > some reason). Both approaches are based on History-Info, though. > >=20 > > We haven't yet been able to agree on an approach, so we thought the=20 > > best is to bring it to the list in order for other people to get=20 > > involved. > >=20 > > Regards, > >=20 > > Christer > >=20 > > =20 > >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > > Behalf Of Mary Barnes > > Sent: Thursday, June 11, 2009 9:05 PM > > To: sipcore@ietf.org > > Subject: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > Hi folks, > >=20 > > We have made a few changes to this document which was > submitted last > > week just to tie up some loose ends and inconsistencies, > some of which > > Shida identified when he reviewed the -00 version. > >=20 > > The following summarizes the high level changes in the=20 > > sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San > > Francisco: > > 1) Renamed the "retarget" parameter to "target" and defined > explicit > > tags to reflect the various mechanisms by which a Request is=20 > > retargeted. > > All entries are now tagged.=20 > > 2) Updated redirect server processing as the redirect server must=20 > > capture the "target" parameter since it is the entity that > knows the > > specific mechanism by which the new target has been determined. > > 3) Changed the privacy such that rather than removing > entries based on > > the various values of the privacy header, the entries are > recommended > > to be anonymized. > > 4) Updated security section > > 5) Updated examples to reflect the new parameter, use loose routing=20 > > and fix errors/nits. > > 6) Editorial changes to remove redundant text and the > convuluted text > > around optionality in the non-normative sections, which is now=20 > > discussed appropriately in the context of the histinfo option tag. > >=20 > > The detailed changes between the versions are summarized in the=20 > > document. > >=20 > > If you're wanting to look at a diff, I would recommend you diff=20 > > against RFC 4244 rather than the earlier 4244bis documents. > >=20 > > We'd really appreciate feedback on this approach to > precisely tagging > > all the entries. We believe it is comprehensive and should > suffice for > > all the use cases identified in the target-uri document, as well as=20 > > any others that might arise. > >=20 > > Thanks, > > Mary and Francois. > >=20 > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > > Internet-Drafts@ietf.org > > Sent: Thursday, June 11, 2009 12:45 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > >=20 > > Title : An Extension to the Session Initiation > > Protocol (SIP) for Request History Information > > Author(s) : M. Barnes, F. Audet > > Filename : draft-barnes-sipcore-rfc4244bis-01.txt > > Pages : 42 > > Date : 2009-06-11 > >=20 > > This document defines a standard mechanism for capturing > the history > > information associated with a Session Initiation Protocol > > (SIP) request. > > This capability enables many enhanced services by providing the=20 > > information as to how and why a call arrives at a specific > application > > or user. This document defines a new optional SIP header,=20 > > History-Info, for capturing the history information in requests. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc42 > 44bis-01.t > > xt > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=20 >=20 From pkyzivat@cisco.com Fri Jun 12 07:47:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E583A6996 for ; Fri, 12 Jun 2009 07:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.439 X-Spam-Level: X-Spam-Status: No, score=-5.439 tagged_above=-999 required=5 tests=[AWL=-1.140, BAYES_00=-2.599, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jX08Fn-UF6Pa for ; Fri, 12 Jun 2009 07:47:49 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6B90C3A691E for ; Fri, 12 Jun 2009 07:47:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,210,1243814400"; d="scan'208";a="199074478" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 12 Jun 2009 14:47:55 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5CElvhi010271; Fri, 12 Jun 2009 07:47:57 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5CElebs018801; Fri, 12 Jun 2009 14:47:57 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 10:47:56 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 10:47:55 -0400 Message-ID: <4A326A9B.3020404@cisco.com> Date: Fri, 12 Jun 2009 10:47:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mary Barnes References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E78800A@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E78800A@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 12 Jun 2009 14:47:55.0637 (UTC) FILETIME=[C553D250:01C9EB6C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9871; t=1244818077; x=1245682077; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20FW=3A=20I-D=20Action=3Adraf t-barnes-sipcore-rfc4244bis-01.txt |Sender:=20; bh=XmH3g2714XzCkHdvLjDS04WuV6337//3cpPwzM8K2Cg=; b=k79IUeqY6lp1dgT9w9AlJ6ShAGdWDkVKMnQ3Wm10vh/9mfJqCFbXVm5vHb bY7Z5j9WifyQUARuvyoA/ashaXAKRFqfEa5wIPVX0jB8oc9EewRD3ZsjSbY1 GTuPIUpdtX; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 14:47:51 -0000 Mary Barnes wrote: > Hi Christer, > > I really think one of the biggest issues here is that 4244bis is written from the perspective of core SIP processing and entirely uses existing constructs. > > Let me make sure I understand your scenarios, as I think they're obviously all related in that your 3rd point describes how things could work with core SIP and 4244bis, which supports both your first two cases (although see my note on your 2nd case below). I also think the target-uri solution is convoluting how the UAS that would use History-Info versus how History-Info is captured - that's likely why we getting into these never ending discussions. > > One question I have is whether or not these numbers are tel-uris? > I think they have to be for any of this to work. > But, if so then your 2nd bullet does violate core SIP functionality > in that you cannot change the target of a Request (you can only forward) > if the Request-URI does not belong to the domain of the entity doing the retargeting (per section 16.5): > "If the domain of the Request-URI indicates a domain this element is > not responsible for, the Request-URI MUST be placed into the target > set as the only target, and the element MUST proceed to the task of > Request Forwarding (Section 16.6)." I'm not sure I follow the exact assumptions people are making here, and as a result exactly what is meant by the particular issues raised. If an R-URI is: sip:+1-800-555-1234@sp1.net (with or without user=phone), then it can only be replaced by a server responsible for sp1.net. If the request is being handled by proxy.sp2.net then it will have to pass it along to sp1.net unchanged. That's clear from what Mary quotes above. Things are not so clear if the R-URI is tel:+1-800-555-1234. It doesn't have a domain. Does that mean that nobody is responsible for it, or that anybody can consider themselves responsible for it? I think I can make a case either way. But if nobody is permitted to consider themselves responsible for it, then how can it ever be answered? Thanks, Paul > For item 1, yes the entries are tagged differently depending upon how you configure the 800 service on the home proxy. But, that's basic SIP. If you don't want to do item 3 below, then since these numbers have meaning in terms of a service, you really are talking about special flavors of URIs that the UAS can still pull out of the History-Info - i.e., you need History-Info a URI parameter, so you move the complexity to the UAS. > > Mary. > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, June 12, 2009 3:13 AM > To: DOLLY, MARTIN C, ATTLABS; Barnes, Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > Hi, > > The biggest difference is regarding support of service-number (like toll-free/freephone) type-of services, where the Request-URI translation does not change the targeted user or resource. Without going in to the protocol differences (which aren't that big), my understanding of the functional differences are the following: > > - 4244bis approach does not distinguish between service-number (like toll-free/freephone) number translation and diversion. > > - 4244bis approach does not allow a service-number (like toll-free/freephone) translation for a user which belongs to another domain. > > - 4244bis requires that all service-numbers for a user/company (like toll-free/freephone) must be registered (explicitly or implictly), which means that the translation must be done by an entity (normally the registrar) which has the registration information for the called user. > > > The target uri approach does allow translation in another domain, and does not require toll-free/freephone numbers to be registered for the called user. > > So, I don't think that the 4244bis approach supports all service-numbers (like toll-free/freephone) in a sufficient way, and that it is too restrictive for no good reason. It imposes restrictions on the potential business models that are not necessary. > > Regards, > > Christer > > >> -----Original Message----- >> From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] >> Sent: 11. kesäkuuta 2009 23:40 >> To: Christer Holmberg; Mary Barnes; sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Hello, >> >> Can someone please summarize the differences between the two >> approaches? >> >> Thanks, >> >> Martin >> >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: Thursday, June 11, 2009 4:32 PM >> To: Christer Holmberg; Mary Barnes; sipcore@ietf.org >> Subject: Re: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> Here is the link to the latest version of the target-uri draft: >> >> http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-de >> livery-00. >> txt >> >> -----Original Message----- >> From: Christer Holmberg >> Sent: Thursday, June 11, 2009 11:31 PM >> To: 'Mary Barnes'; sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> Hi, >> >> I think it is important to mention that there are still different >> approaches regarding the target uri delivery, and that there is >> another approach described in the latest version of the target-uri >> delivery draft (I am not sure it appears in the archieves, though, for >> some reason). Both approaches are based on History-Info, though. >> >> We haven't yet been able to agree on an approach, so we thought the >> best is to bring it to the list in order for other people to get >> involved. >> >> Regards, >> >> Christer >> >> >> >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of Mary Barnes >> Sent: Thursday, June 11, 2009 9:05 PM >> To: sipcore@ietf.org >> Subject: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Hi folks, >> >> We have made a few changes to this document which was submitted last >> week just to tie up some loose ends and inconsistencies, some of which >> Shida identified when he reviewed the -00 version. >> >> The following summarizes the high level changes in the >> sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San >> Francisco: >> 1) Renamed the "retarget" parameter to "target" and defined explicit >> tags to reflect the various mechanisms by which a Request is >> retargeted. >> All entries are now tagged. >> 2) Updated redirect server processing as the redirect server must >> capture the "target" parameter since it is the entity that knows the >> specific mechanism by which the new target has been determined. >> 3) Changed the privacy such that rather than removing entries based on >> the various values of the privacy header, the entries are recommended >> to be anonymized. >> 4) Updated security section >> 5) Updated examples to reflect the new parameter, use loose routing >> and fix errors/nits. >> 6) Editorial changes to remove redundant text and the convuluted text >> around optionality in the non-normative sections, which is now >> discussed appropriately in the context of the histinfo option tag. >> >> The detailed changes between the versions are summarized in the >> document. >> >> If you're wanting to look at a diff, I would recommend you diff >> against RFC 4244 rather than the earlier 4244bis documents. >> >> We'd really appreciate feedback on this approach to precisely tagging >> all the entries. We believe it is comprehensive and should suffice for >> all the use cases identified in the target-uri document, as well as >> any others that might arise. >> >> Thanks, >> Mary and Francois. >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: Thursday, June 11, 2009 12:45 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : An Extension to the Session Initiation >> Protocol (SIP) for Request History Information >> Author(s) : M. Barnes, F. Audet >> Filename : draft-barnes-sipcore-rfc4244bis-01.txt >> Pages : 42 >> Date : 2009-06-11 >> >> This document defines a standard mechanism for capturing the history >> information associated with a Session Initiation Protocol >> (SIP) request. >> This capability enables many enhanced services by providing the >> information as to how and why a call arrives at a specific application >> or user. This document defines a new optional SIP header, >> History-Info, for capturing the history information in requests. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc42 >> 44bis-01.t >> xt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> _______________________________________________ >> 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 ietf.hanserik@gmail.com Fri Jun 12 08:24:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97B5C3A6A3B for ; Fri, 12 Jun 2009 08:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxDoI6+7luKO for ; Fri, 12 Jun 2009 08:24:04 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 8AC9828C12E for ; Fri, 12 Jun 2009 08:24:03 -0700 (PDT) Received: by ewy6 with SMTP id 6so3078313ewy.37 for ; Fri, 12 Jun 2009 08:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6MWnoD3Zx2GYC8+q9pxICBMJz1HLrhl8X2FBLxN1oTw=; b=HOvY51lyS9bXbMvNJ/krf+kCXuqpeJ9YjOjhzp0lbPPCEjRvKnv2MMHjCrQsyJr+lA LBdKho61c1B7QxF1rwTKengTjK1edKVBLJnwsB777e4Ijs09jW70Auo8oxdwu5PiP8/Y p8XFhi87pwIbCNt/vsbUF/4GYb1pzevlvq9ww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=yGKGHL+MOL0tl4a8ThMf1JJBVAFhuj+lQtCu20bZ5k+AKAYTClQTcFaDw0/MVamAYz 92MtYoEr+kYNmknzvnkm6uEnrzsLR6TBuN0DNpxAKR351qmwGFQ9ZdigSmW8c2o12g6W wJeK2TvASdFwOlun0L5CQfAiPdw9h3OKw22wY= MIME-Version: 1.0 Received: by 10.210.39.8 with SMTP id m8mr4493717ebm.95.1244820249057; Fri, 12 Jun 2009 08:24:09 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E787F80@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120138y540f7c2bja62adcf942cba3a0@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E787F80@zrc2hxm0.corp.nortel.com> Date: Fri, 12 Jun 2009 17:24:09 +0200 Message-ID: <9ae56b1e0906120824s24f0ddfyb9dc6d6c38651d75@mail.gmail.com> From: Hans Erik van Elburg To: Mary Barnes Content-Type: multipart/alternative; boundary=00151748e904c11be5046c284cd8 Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 15:24:06 -0000 --00151748e904c11be5046c284cd8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Mary, I do not understand what you mean with multi stage. All the tagging can be prepared at the time that the translation is done and added at the time that 4244 suggests the H-I to be added. If the current text suggests otherwise, then we might need to fix that. BR, /Hans Erik van Elburg On Fri, Jun 12, 2009 at 4:11 PM, Mary Barnes wrote: > Hi Hans, > > A couple comments below [MB]. > > Mary. > > ------------------------------ > *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > *Sent:* Friday, June 12, 2009 3:38 AM > *To:* Barnes, Mary (RICH2:AR00) > *Cc:* Christer Holmberg; sipcore@ietf.org > *Subject:* Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Hi Mary, > > Sure when we agree on the way forward we have to resolve all these detailed > procedures and conform to the 4244 language etc. But we already agreed to > integrate it into 4424bis at the moment that there is agreement about the > solution. > > Regarding the two tag approach that is open for discussion, i think it is > more clean and in general pays off to separate concepts that are independent > from each other. For example a hi-entry may be routed and not be an AOR, > whereas it may also be routed and also an AOR. The decisions to be taken for > additions of these tags are independent, so there is also no need to > intertwine procedural text for them. (It is also more clear for > implementors.) > [MB] This is where my major confusion is in that you say the tags are > independent, BUT where in the normative RFC 3261 processing does this > occur? I'm confused because the logic in section 16.5 isn't "multi-stage" > (for lack of a better term), the incoming request URI is evaluated and then > the new target list is constructed The tagging in 4244 is based on the > mechanism by which a new target is determined . The previous hi-entry (that > in the incoming request) is tagged at the point the request is being > forwarded. I do agree that in the internal processing that information needs > to exist so that the tagging at the point of forwarding the request is > appropriate. [/MB] > > > > BR, > /Hans Erik van Elburg > > On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes wrote: > >> Christer, >> >> I reviewed the updated target-uri draft and have a few comments - well I >> reviewed the diff since there isn't a summary of changes in the >> document: >> >> 1) I had a lot of difficulty picking out the normative processing for >> History-Info in this document. Can you summarize the differences? >> >> 2) The reason I'm concerned about understanding how this fits with the >> current normative processing is because I'm not seeing precisely when >> these tags are added as the terminology is different than that used in >> RFC 4244 - i.e., are these two terms equivalent: >> RFC 4244: >> "... hi-entry received in the request being forwarded." >> >> target-uri: >> "...hi-entry recording the incoming request URI." >> >> There is no reference in terms of current History-Info processing as to >> when in the request processing these tags are added. >> >> 3) In particular, I'm having difficulty with this text in section 6: >> "When a home proxy receives a request for a user or resource for >> which >> is abstract location function returns registered contacts or >> configured URIs, the proxy adds two History-Info header field values. >> The first is the incoming request URI. Since the Request-URI >> identifies a user or resource for which it has a registration or >> configuration, the Request-URI is an AOR and thus an address for the >> user. The proxy adds a History-Info header field parameter, "aor", >> which indicates this. Next, the proxy inserts the contact URI which >> will be contained in the outgoing Request-URI." >> Currently, in RFC 4244, the proxy only adds that additional (first) >> hi-entry IF there wasn't one in the incoming request, since the UAC can >> initially add one when it builds the request. So, this is inconsistent >> with current RFC 4244. And, I think you need to define "home" proxy - >> that's not an RFC 3261 term - there is the concept of a "home" domain. >> >> 4) There is a bug in the Syntax (section 9) - the Index is not optional >> (that is an error we have fixed in the 4244bis). >> >> 5) I'm really confused about this two-stage tagging - how does that >> happen in the context of the determination of Request Targets in section >> 16.5 of RFC3261? Wouldn't the decisions as to the addition of the two >> different tags occur at the same time and thus what is the advantage of >> the defining the two tags - i.e., why not one tag for each combination? >> Also, are you proposing that the addition of the tags be mandatory - >> there is no normative language in the target-uri document, so it's >> impossible to tell. And, if you are proposing they be mandatory, your >> ABNF syntax needs to reflect that, thus defining a single parameter with >> multiple values would be necessary (which is the approach in 4244bis). >> >> >> 6) What is the difference (or is there a difference?) between the >> functionality associated with the tags in 4244bis and the tags defined >> in this document in terms of types of retargets that are being tagged? >> I think this is the crux of what we need to agree - i.e., why aren't the >> 4244bis tags sufficient? If there is no logical difference and it's >> just the words used to define the tags, then we're very close to >> agreement. >> >> Regards, >> Mary. >> >> >> >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Thursday, June 11, 2009 3:32 PM >> To: Christer Holmberg; Barnes, Mary (RICH2:AR00); sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> Here is the link to the latest version of the target-uri draft: >> >> http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00. >> txt >> >> -----Original Message----- >> From: Christer Holmberg >> Sent: Thursday, June 11, 2009 11:31 PM >> To: 'Mary Barnes'; sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> Hi, >> >> I think it is important to mention that there are still different >> approaches regarding the target uri delivery, and that there is another >> approach described in the latest version of the target-uri delivery >> draft (I am not sure it appears in the archieves, though, for some >> reason). Both approaches are based on History-Info, though. >> >> We haven't yet been able to agree on an approach, so we thought the best >> is to bring it to the list in order for other people to get involved. >> >> Regards, >> >> Christer >> >> >> >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of Mary Barnes >> Sent: Thursday, June 11, 2009 9:05 PM >> To: sipcore@ietf.org >> Subject: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Hi folks, >> >> We have made a few changes to this document which was submitted last >> week just to tie up some loose ends and inconsistencies, some of which >> Shida identified when he reviewed the -00 version. >> >> The following summarizes the high level changes in the >> sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San >> Francisco: >> 1) Renamed the "retarget" parameter to "target" and defined explicit >> tags to reflect the various mechanisms by which a Request is retargeted. >> All entries are now tagged. >> 2) Updated redirect server processing as the redirect server must >> capture the "target" parameter since it is the entity that knows the >> specific mechanism by which the new target has been determined. >> 3) Changed the privacy such that rather than removing entries based on >> the various values of the privacy header, the entries are recommended to >> be anonymized. >> 4) Updated security section >> 5) Updated examples to reflect the new parameter, use loose routing and >> fix errors/nits. >> 6) Editorial changes to remove redundant text and the convuluted text >> around optionality in the non-normative sections, which is now discussed >> appropriately in the context of the histinfo option tag. >> >> The detailed changes between the versions are summarized in the >> document. >> >> If you're wanting to look at a diff, I would recommend you diff against >> RFC 4244 rather than the earlier 4244bis documents. >> >> We'd really appreciate feedback on this approach to precisely tagging >> all the entries. We believe it is comprehensive and should suffice for >> all the use cases identified in the target-uri document, as well as any >> others that might arise. >> >> Thanks, >> Mary and Francois. >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> [mailto:i-d-announce-bounces@ietf.org] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: Thursday, June 11, 2009 12:45 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : An Extension to the Session Initiation >> Protocol (SIP) for Request History Information >> Author(s) : M. Barnes, F. Audet >> Filename : draft-barnes-sipcore-rfc4244bis-01.txt >> Pages : 42 >> Date : 2009-06-11 >> >> This document defines a standard mechanism for capturing the history >> information associated with a Session Initiation Protocol (SIP) request. >> This capability enables many enhanced services by providing the >> information as to how and why a call arrives at a specific application >> or user. This document defines a new optional SIP header, History-Info, >> for capturing the history information in requests. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01.t >> xt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > --00151748e904c11be5046c284cd8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mary,

I do not understand what you mean with multi stage. All the= tagging can be prepared at the time that the translation is done and added= at the time that 4244 suggests the H-I to be added. If the current text su= ggests otherwise, then we might need to fix that.

BR,
/Hans Erik van Elburg


On Fri, Jun 12, 2009 at 4:11 PM, Mary Ba= rnes <mary.b= arnes@nortel.com> wrote:
Hi=20 Hans,
= =A0
A=20 couple comments below [MB].
= =A0
Mary.

From: Hans Erik van Elburg=20 [mailto:ietf.h= anserik@gmail.com]
Sent: Friday, June 12, 2009 3:38=20 AM

To: Barnes, Mary (RICH2:AR00)
Cc= : Christer Holmberg;=20 sipcore@ietf.org<= br>Subject: Re: [sipcore] FW: I-D=20 Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi Mary,

Sure when we agree on the way forward we have to resol= ve=20 all these detailed procedures and conform to the 4244 language etc. But we= =20 already agreed to integrate it into 4424bis at the moment that there is=20 agreement about the solution.

Regarding the two tag approach that i= s=20 open for discussion, i think it is more clean and in general pays off to=20 separate concepts that are independent from each other. For example a hi-en= try=20 may be routed and not be an AOR, whereas it may also be routed and also an = AOR.=20 The decisions to be taken for additions of these tags are independent, so t= here=20 is also no need to intertwine procedural text for them. (It is also more cl= ear=20 for implementors.)= =A0
[MB]=A0T= his is where my major confusion is in that you say the tags=20 are independent, BUT where in the normative RFC 3261 processing does this= =20 occur?=A0=A0I'm confused because the=A0logic in section 16.5 isn't= =20 "multi-stage" (for lack of a better term),=A0the incoming request= URI is=20 evaluated and then the new target list is constructed=A0=A0 The tagging in= =20 4244 is based on the mechanism by which a new target is determined=A0.=A0= =20 The previous hi-entry (that in the incoming request) is tagged at the point= the=20 request is being forwarded. I do agree that in the internal processing that= =20 information needs to=A0exist so that=A0the tagging at the point of=20 forwarding the request is appropriate.=A0=A0[/MB]
= =A0


BR,
/Hans Erik van Elburg

On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes <mary.barnes@nortel.com>=20 wrote:
Christer,

= I=20 reviewed the updated target-uri draft and have a few comments - well=20 I
reviewed the diff since there isn't a summary of changes in=20 the
document:

1) I had a lot of difficulty picking out the norm= ative=20 processing for
History-Info in this document. Can you summarize the=20 differences?

2) The reason I'm concerned about understanding h= ow this=20 fits with the
current normative processing is because I'm not seei= ng=20 precisely when
these tags are added as the terminology is different th= an=20 that used in
RFC 4244 - i.e., are these two terms equivalent:
RFC= =20 4244:
"... hi-entry received in the request being=20 forwarded."

target-uri:
"...hi-entry recording the in= coming request=20 URI."

There is no reference in terms of current History-Info = processing=20 as to
when in the request processing these tags are added.

3) I= n=20 particular, I'm having difficulty with this text in section 6:
=A0= "When=20 a home proxy receives a request for a user or resource for
which
= =A0=20 is abstract location function returns registered contacts or
=A0=20 configured URIs, the proxy adds two History-Info header field=20 values.
=A0 The first is the incoming request URI. =A0Since the=20 Request-URI
=A0 identifies a user or resource for which it has a=20 registration or
=A0 configuration, the Request-URI is an AOR and thus = an=20 address for the
=A0 user. =A0The proxy adds a History-Info header=20 field parameter, "aor",
=A0 which indicates this. =A0Next, t= he proxy=20 inserts the contact URI which
=A0 will be contained in the outgoing=20 Request-URI."
Currently, in RFC 4244, the proxy only adds that ad= ditional=20 (first)
hi-entry IF there wasn't one in the incoming request, sinc= e the UAC=20 can
initially add one when it builds the request. So, this is=20 inconsistent
with current RFC 4244. And, I think you need to define &q= uot;home"=20 proxy -
that's not an RFC 3261 term - there is the concept of a &q= uot;home"=20 domain.

4) There is a bug in the Syntax (section 9) - the Index is= not=20 optional
(that is an error we have fixed in the 4244bis).

5) I&= #39;m=20 really confused about this two-stage tagging - how does that
happen in= the=20 context of the determination of Request Targets in section
16.5 of RFC= 3261?=20 Wouldn't the decisions as to the addition of the two
different tag= s occur=20 at the same time and thus what is the advantage of
the defining the tw= o=20 tags - i.e., why not one tag for each combination?
Also, are you propo= sing=20 that the addition of the tags be mandatory -
there is no normative lan= guage=20 in the target-uri document, so it's
impossible to tell. =A0And, if= you=20 are proposing they be mandatory, your
ABNF syntax needs to reflect tha= t,=20 thus defining a single parameter with
multiple values would be necessa= ry=20 (which is the approach in 4244bis).


6) What is the difference = (or=20 is there a difference?) between the
functionality associated with the = tags=20 in 4244bis and the tags defined
in this document in terms of types of= =20 retargets that are being tagged?
I think this is the crux of what we n= eed=20 to agree - i.e., why aren't the
4244bis tags sufficient? =A0If the= re is=20 no logical difference and it's
just the words used to define the t= ags, then=20 we're very close to
agreement.

Regards,
Mary.



-----Original Message-----
From: Christer=20 Holmberg [mailto:christer.holmberg@ericsson.com]
Sent:=20 Thursday, June 11, 2009 3:32 PM
To: Christer Holmberg; Barnes, Mary (RICH2:AR00); sipcore@ietf.org
Subject: RE: [s= ipcore]=20 FW: I-D
Action:draft-barnes-sipcore-rfc4244bis-01.txt


Here = is=20 the link to the latest version of the target-uri draft:

http://tools.ietf.org/id/draft-rosenberg-sipcore-ta= rget-uri-delivery-00.
txt

-----Original=20 Message-----
From: Christer Holmberg
Sent: Thursday, June 11, 2009 = 11:31=20 PM
To: 'Mary Barnes'; sipcore@ietf.org
Subject: RE: [sipcore]=20 FW:=20 I-D
Action:draft-barnes-sipcore-rfc4244bis-01.txt


Hi,
I=20 think it is important to mention that there are still different
approa= ches=20 regarding the target uri delivery, and that there is another
approach= =20 described in the latest version of the target-uri delivery
draft (I am= not=20 sure it appears in the archieves, though, for some
reason). Both appro= aches=20 are based on History-Info, though.

We haven't yet been able to= agree on=20 an approach, so we thought the best
is to bring it to the list in orde= r for=20 other people to get=20 involved.

Regards,

Christer



-----Original=20 Message-----
From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org]=20 On
Behalf Of Mary Barnes
Sent: Thursday, June 11, 2009 9:05 PM
T= o: sipcore@ietf.org
Subject: [sipcore] FW:=20 I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi folks,
We=20 have made a few changes to this document which was submitted last
week= just=20 to tie up some loose ends and inconsistencies, some of which
Shida=20 identified when he reviewed the -00 version.

The following summari= zes=20 the high level changes in the
sipcore-rfc4244bis from the sip-rfc4244b= is=20 that we discussed in San
Francisco:
1) Renamed the "retarget&q= uot; parameter=20 to "target" and defined explicit
tags to reflect the various= mechanisms by=20 which a Request is retargeted.
All entries are now tagged.
2) Updat= ed=20 redirect server processing as the redirect server must
capture the &qu= ot;target"=20 parameter since it is the entity that knows the
specific mechanism by = which=20 the new target has been determined.
3) Changed the privacy such that r= ather=20 than removing entries based on
the various values of the privacy heade= r,=20 the entries are recommended to
be anonymized.
4) Updated security= =20 section
5) Updated examples to reflect the new parameter, use loose ro= uting=20 and
fix errors/nits.
6) Editorial changes to remove redundant text = and=20 the convuluted text
around optionality in the non-normative sections, = which=20 is now discussed
appropriately in the context of the histinfo option= =20 tag.

The detailed changes between the versions are summarized in= =20 the
document.

If you're wanting to look at a diff, I would = recommend=20 you diff against
RFC 4244 rather than the earlier 4244bis=20 documents.

We'd really appreciate feedback on this approach to= =20 precisely tagging
all the entries. We believe it is comprehensive and= =20 should suffice for
all the use cases identified in the target-uri docu= ment,=20 as well as any
others that might arise.

Thanks,
Mary and=20 Francois.

-----Original Message-----
From: i-d-announce-bounces@ietf.or= g
[mailto:i-d-announce-bounces@ietf.org]=20 On Behalf Of
Internet-Drafts@ietf.org
Sent:=20 Thursday, June 11, 2009 12:45 PM
To: i-d-announce@ietf.org
Subject: I-D=20 Action:draft-barnes-sipcore-rfc4244bis-01.txt

A New Internet-Draft= is=20 available from the on-line Internet-Drafts
directories.

=A0=20 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : An Extension to=20 the Session Initiation
Protocol (SIP) for Request History=20 Information
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M.=20 Barnes, F. Audet
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0=20 =A0: draft-barnes-sipcore-rfc4244bis-01.txt
=A0 =A0 =A0=20 =A0Pages =A0 =A0 =A0 =A0 =A0 : 42
=A0 =A0 =A0=20 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-06-11

This=20 document defines a standard mechanism for capturing the history
inform= ation=20 associated with a Session Initiation Protocol (SIP) request.
This=20 capability enables many enhanced services by providing the
information= as=20 to how and why a call arrives at a specific application
or user. =A0Th= is=20 document defines a new optional SIP header, History-Info,
for capturin= g the=20 history information in requests.

A URL for this Internet-Draft=20 is:
http://www.ietf.org/internet-draf= ts/draft-barnes-sipcore-rfc4244bis-01.t
xt

Internet-Drafts=20 are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/=

Below is the data=20 which will enable a MIME compliant mail reader
implementation to=20 automatically retrieve the ASCII version of=20 the
Internet-Draft.
_______________________________________________=
sipcore=20 mailing list
sip= core@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
=


--00151748e904c11be5046c284cd8-- From ben@nostrum.com Fri Jun 12 08:33:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7199C3A69FD for ; Fri, 12 Jun 2009 08:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voVJrL5iN54l for ; Fri, 12 Jun 2009 08:33:55 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 68DEF3A68F8 for ; Fri, 12 Jun 2009 08:33:55 -0700 (PDT) Received: from dn3-109.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 n5CFXx6M055170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Jun 2009 10:33:59 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <88D6249E-AE11-48C3-82F4-49A2E58E9BE7@nostrum.com> From: Ben Campbell To: Gonzalo Camarillo In-Reply-To: <4A3227D2.4020808@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 10:33:58 -0500 References: <4A3227D2.4020808@ericsson.com> X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Milestone to revise RFC 3265 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 15:33:56 -0000 On Jun 12, 2009, at 5:02 AM, Gonzalo Camarillo wrote: [...] > > 1) should we add a milestone to our charter to revise RFC 3265? > yes > 2) if we add such a milestone, should we take the following draft as > the initial WG item for the milestone? > http://tools.ietf.org/html/draft-roach-sipcore-rfc3265bis-00 yes [...] Thanks! Ben. From dworley@nortel.com Fri Jun 12 08:35:18 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6249A3A6A8A for ; Fri, 12 Jun 2009 08:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.699 X-Spam-Level: X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2Wmai1rDIeg for ; Fri, 12 Jun 2009 08:35:17 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 78CC93A69FD for ; Fri, 12 Jun 2009 08:35:17 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5CFZM715917; Fri, 12 Jun 2009 15:35:22 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 11:35:12 -0400 From: "Dale Worley" To: Gonzalo Camarillo In-Reply-To: <4A3227D2.4020808@ericsson.com> References: <4A3227D2.4020808@ericsson.com> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 12 Jun 2009 11:35:12 -0400 Message-Id: <1244820912.3768.8.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2009 15:35:13.0199 (UTC) FILETIME=[60A56BF0:01C9EB73] Cc: SIPCORE Subject: Re: [sipcore] Milestone to revise RFC 3265 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 15:35:18 -0000 On Fri, 2009-06-12 at 13:02 +0300, Gonzalo Camarillo wrote: > 1) should we add a milestone to our charter to revise RFC 3265? Yes. > 2) if we add such a milestone, should we take the following draft as the > initial WG item for the milestone? > > http://tools.ietf.org/html/draft-roach-sipcore-rfc3265bis-00 Yes. Dale From dworley@nortel.com Fri Jun 12 08:39:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 225493A6CC4 for ; Fri, 12 Jun 2009 08:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.69 X-Spam-Level: X-Spam-Status: No, score=-6.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PycytjbqLUwo for ; Fri, 12 Jun 2009 08:39:34 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2F1303A6C98 for ; Fri, 12 Jun 2009 08:39:34 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5CFdS716802; Fri, 12 Jun 2009 15:39:28 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 11:39:20 -0400 From: "Dale Worley" To: Byron Campen In-Reply-To: <1EF42B19-CB00-48C3-9EF7-F15A36AE5CF7@estacado.net> References: <109101c9eae2$f8ef9890$eacec9b0$@net> <1EF42B19-CB00-48C3-9EF7-F15A36AE5CF7@estacado.net> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 12 Jun 2009 11:39:20 -0400 Message-Id: <1244821160.3768.13.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2009 15:39:20.0812 (UTC) FILETIME=[F43C2AC0:01C9EB73] Cc: sipcore@ietf.org Subject: Re: [sipcore] [Sipping] draft-niemi-sipcore-event-rate-control-00 and forcing notifications when state has not changed X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 15:39:35 -0000 > > I would say yes, the intention is to force an update even if nothing > > changed. It does appear that that is the only plausible interpretation of the 'force' parameter. On Thu, 2009-06-11 at 21:32 -0500, Byron Campen wrote: > Ok, then I will say that this is a bad idea. I really, really don't > want to deal with implementors that want to deploy clients that use > the longest subscription duration possible, and shift the burden of > keeping the subscription alive to the server through use of the force > parameter. Because that is exactly what they will do. Could you explicate why this is a bad idea? As far as I can tell, this scenario of 'force' usage does not place any additional burden on the notifier, since the notifier would otherwise be responding to re-subscribe messages, and would be maintaining timers for the expiration of the subscription. Indeed, using 'force' would decrease the message traffic at each quasi-refresh interval to one NOTIFY/response pair. (Although a similar effect could be obtained using re-SUBSCRIBE with etag.) The risk, it seems to me, is that the notifier would vanish and the subscriber might continue the subscription for far too long. Dale From bcampen@estacado.net Fri Jun 12 09:02:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6F5C3A6A1C for ; Fri, 12 Jun 2009 09:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHnZSwqi6sDm for ; Fri, 12 Jun 2009 09:02:20 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 176B73A68E0 for ; Fri, 12 Jun 2009 09:02:19 -0700 (PDT) Received: from dn3-233.estacado.net (dn3-233.estacado.net [172.16.3.233]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n5CG2Ns4023949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Jun 2009 11:02:23 -0500 (CDT) (envelope-from bcampen@estacado.net) Message-Id: <85ED2F6F-EBAC-454D-858B-D3BFAF901CCA@estacado.net> From: Byron Campen To: "Dale Worley" In-Reply-To: <1244821160.3768.13.camel@victoria-pingtel-com.us.nortel.com> Content-Type: multipart/signed; boundary=Apple-Mail-15-227370702; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 11:02:19 -0500 References: <109101c9eae2$f8ef9890$eacec9b0$@net> <1EF42B19-CB00-48C3-9EF7-F15A36AE5CF7@estacado.net> <1244821160.3768.13.camel@victoria-pingtel-com.us.nortel.com> X-Mailer: Apple Mail (2.935.3) Cc: sipcore@ietf.org Subject: Re: [sipcore] [Sipping] draft-niemi-sipcore-event-rate-control-00 and forcing notifications when state has not changed X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 16:02:21 -0000 --Apple-Mail-15-227370702 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Stuff inline: >>> I would say yes, the intention is to force an update even if nothing >>> changed. > > It does appear that that is the only plausible interpretation of the > 'force' parameter. > The general use-case that has been outlined previously is where normal notification has been suppressed by filters (or something else, maybe event-package-specific); the state has not changed "enough" for the subscriber to care about immediate notification. A specific example is location data. > On Thu, 2009-06-11 at 21:32 -0500, Byron Campen wrote: >> Ok, then I will say that this is a bad idea. I really, really don't >> want to deal with implementors that want to deploy clients that use >> the longest subscription duration possible, and shift the burden of >> keeping the subscription alive to the server through use of the force >> parameter. Because that is exactly what they will do. > > Could you explicate why this is a bad idea? > > As far as I can tell, this scenario of 'force' usage does not place > any > additional burden on the notifier, since the notifier would > otherwise be > responding to re-subscribe messages, and would be maintaining timers > for > the expiration of the subscription. Indeed, using 'force' would > decrease the message traffic at each quasi-refresh interval to one > NOTIFY/response pair. (Although a similar effect could be obtained > using re-SUBSCRIBE with etag.) > Indeed, this could be done with etag, and using etag is a far more efficient mechanism, because you are not gratuitously sending (potentially very large) documents. My main beef is that this shifts the job of maintaining soft-state to the server. As a general principle, this has been the client's job, and this is specifically how SIP events is supposed to work. Allowing the client to say, "Nah, you're going to handle recovery now." is a rather fundamental change to the protocol, that we should only make if there is a compelling reason. I see no such reason. > The risk, it seems to me, is that the notifier would vanish and the > subscriber might continue the subscription for far too long. > Right, that is yet another problem with this. Best regards, Byron Campen --Apple-Mail-15-227370702 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGZDCCAx0w ggKGoAMCAQICEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDkyMzA0MzgwNFoXDTA5MDkyMzA0Mzgw NFowazEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQxIzAhBgkqhkiG9w0BCQEWFGRvY2ZhcmFkYXlAZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIGiyvzQgsqDjR3TiFTO4nkc/VRo/eX6xKu ky4CR2QtnIPEWhNLbU5UgXdGzU3YWx/cRj5alT0auKVQ/BnjCbf3bFSzP5mIfV6KlJV89dpxKQQA 3FaDYxE3whiRPIjQh3nmqxSacBTLohlt/g8MlFyiHoNs3XcH83M3QMjMxU8pD7SgXUDaXdtqC8vV +7g3rzPmlONdJ+4vac159wuZe37WVTsFI4sYL3p/KvqT1NZhmn1cmOVWKfCVAdGLk8VEUZtWuSeM NU5CLnFvenxaSPkDeVR5h0qDpw4DQyHfWXQuKvRs1WgVeHASz87EPgncyp90yiByetvE0WIBGKiz 0QIDAQABo0cwRTA1BgNVHREELjAsgRRiY2FtcGVuQGVzdGFjYWRvLm5ldIEUZG9jZmFyYWRheUBn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQANmDZo4t+1SrO9nb8KfjN4 QtlV1gzaAa2jEsAZ369PBXdsxVz32a1JIa1KudXFfMMxtF1NRDJ0Z3ib/qq+L8B28IpkYgRWtRr+ WWm6LzJ6rm1Q85cC0VSqoIRr+NoRZjaBdqWbJC4QsPnwVSXN9jLMLkFkjcxVDSxQtEx6v1PF9zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUP SAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0Eu Y3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2f Ni/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH 1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQW7SrCyoCwnsms5MfcqmjmzAJBgUr DgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2 MTIxNjAyMTlaMCMGCSqGSIb3DQEJBDEWBBQVJ1cqLGwwAwEzFgMRo+IEIVgL+jCBhQYJKwYBBAGC NxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsq AsJ7JrOTH3Kpo5swgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEBBQAEggEAgWJr DvMpQFt+cDSe6qxqGlBjBnf1GK+AOOeC40Yh03yfXm+/GmImRKRDuugYC/b0C2eMAnVDaYpnlvPy hyTjxJjc1wWwa66U+9l00AetdWANJEwiKQqjQSkcL1x4r9wtrbasjAGb+xI37hk7woxqNdHD6Ui1 6MdxEDMtUXJGxsFjMVzwP1VxVeTqaeYPfwzMJl1AHxsOAjSzeUVqtK3+gRa+PQ78rbbgeJ0OQO+v eqRqayk7ayew/+BBAhVzMrIWPbwab3GrYim18VgfNS8NwcaJueHLlIZY853J/uNa8BDdObJRLbDH 5hyvvYgObmOd9Z4lYIgR/18BU1DRZha13wAAAAAAAA== --Apple-Mail-15-227370702-- From bcampen@estacado.net Fri Jun 12 09:12:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FB113A68E0 for ; Fri, 12 Jun 2009 09:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlX8uottDXSt for ; Fri, 12 Jun 2009 09:12:50 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 0EBF03A680C for ; Fri, 12 Jun 2009 09:12:49 -0700 (PDT) Received: from dn3-233.estacado.net (dn3-233.estacado.net [172.16.3.233]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n5CGCruY025619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Jun 2009 11:12:54 -0500 (CDT) (envelope-from bcampen@estacado.net) Message-Id: <879393A2-6494-4552-8A66-3A154EA73AB2@estacado.net> From: Byron Campen To: Dale Worley In-Reply-To: <85ED2F6F-EBAC-454D-858B-D3BFAF901CCA@estacado.net> Content-Type: multipart/signed; boundary=Apple-Mail-16-228001430; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 11:12:50 -0500 References: <109101c9eae2$f8ef9890$eacec9b0$@net> <1EF42B19-CB00-48C3-9EF7-F15A36AE5CF7@estacado.net> <1244821160.3768.13.camel@victoria-pingtel-com.us.nortel.com> <85ED2F6F-EBAC-454D-858B-D3BFAF901CCA@estacado.net> X-Mailer: Apple Mail (2.935.3) Cc: SIPCORE Subject: Re: [sipcore] [Sipping] draft-niemi-sipcore-event-rate-control-00 and forcing notifications when state has not changed X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 16:12:51 -0000 --Apple-Mail-16-228001430 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Also, I should note that I see no reason to require these forced notifications to contain full state if a partial update is available. Best regards, Byron Campen > Stuff inline: > >>>> I would say yes, the intention is to force an update even if >>>> nothing >>>> changed. >> >> It does appear that that is the only plausible interpretation of the >> 'force' parameter. >> > > The general use-case that has been outlined previously is where > normal notification has been suppressed by filters (or something > else, maybe event-package-specific); the state has not changed > "enough" for the subscriber to care about immediate notification. A > specific example is location data. > >> On Thu, 2009-06-11 at 21:32 -0500, Byron Campen wrote: >>> Ok, then I will say that this is a bad idea. I really, really don't >>> want to deal with implementors that want to deploy clients that use >>> the longest subscription duration possible, and shift the burden of >>> keeping the subscription alive to the server through use of the >>> force >>> parameter. Because that is exactly what they will do. >> >> Could you explicate why this is a bad idea? >> >> As far as I can tell, this scenario of 'force' usage does not place >> any >> additional burden on the notifier, since the notifier would >> otherwise be >> responding to re-subscribe messages, and would be maintaining >> timers for >> the expiration of the subscription. Indeed, using 'force' would >> decrease the message traffic at each quasi-refresh interval to one >> NOTIFY/response pair. (Although a similar effect could be obtained >> using re-SUBSCRIBE with etag.) >> > > Indeed, this could be done with etag, and using etag is a far more > efficient mechanism, because you are not gratuitously sending > (potentially very large) documents. My main beef is that this shifts > the job of maintaining soft-state to the server. As a general > principle, this has been the client's job, and this is specifically > how SIP events is supposed to work. Allowing the client to say, > "Nah, you're going to handle recovery now." is a rather fundamental > change to the protocol, that we should only make if there is a > compelling reason. I see no such reason. > >> The risk, it seems to me, is that the notifier would vanish and the >> subscriber might continue the subscription for far too long. >> > > Right, that is yet another problem with this. > > Best regards, > Byron Campen > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail-16-228001430 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGZDCCAx0w ggKGoAMCAQICEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDkyMzA0MzgwNFoXDTA5MDkyMzA0Mzgw NFowazEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQxIzAhBgkqhkiG9w0BCQEWFGRvY2ZhcmFkYXlAZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIGiyvzQgsqDjR3TiFTO4nkc/VRo/eX6xKu ky4CR2QtnIPEWhNLbU5UgXdGzU3YWx/cRj5alT0auKVQ/BnjCbf3bFSzP5mIfV6KlJV89dpxKQQA 3FaDYxE3whiRPIjQh3nmqxSacBTLohlt/g8MlFyiHoNs3XcH83M3QMjMxU8pD7SgXUDaXdtqC8vV +7g3rzPmlONdJ+4vac159wuZe37WVTsFI4sYL3p/KvqT1NZhmn1cmOVWKfCVAdGLk8VEUZtWuSeM NU5CLnFvenxaSPkDeVR5h0qDpw4DQyHfWXQuKvRs1WgVeHASz87EPgncyp90yiByetvE0WIBGKiz 0QIDAQABo0cwRTA1BgNVHREELjAsgRRiY2FtcGVuQGVzdGFjYWRvLm5ldIEUZG9jZmFyYWRheUBn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQANmDZo4t+1SrO9nb8KfjN4 QtlV1gzaAa2jEsAZ369PBXdsxVz32a1JIa1KudXFfMMxtF1NRDJ0Z3ib/qq+L8B28IpkYgRWtRr+ WWm6LzJ6rm1Q85cC0VSqoIRr+NoRZjaBdqWbJC4QsPnwVSXN9jLMLkFkjcxVDSxQtEx6v1PF9zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUP SAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0Eu Y3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2f Ni/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH 1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQW7SrCyoCwnsms5MfcqmjmzAJBgUr DgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2 MTIxNjEyNTBaMCMGCSqGSIb3DQEJBDEWBBRxCSi4ZbLroUd4sk/YwL1JgxZv2DCBhQYJKwYBBAGC NxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsq AsJ7JrOTH3Kpo5swgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEBBQAEggEAjuPB D48WP2b0trNFl8Ad3paAbTlBqBwhO4y0C/5CjYnxpQArqKwPLE6rpECPNhwmxG2HQKxXaiHtJD9B Ac5Ad8U/Qw4Q2vZnotXjdXQVl5Ii1JRuog2NMd/6sElC/0U9mKFIatmS1KJ+lxhDRYZUKl6l0ynQ ZGdMYCoNqhenwFuwKCTXXX/No9qLYr5xPGtctmuOwAndmDXjBuLVILLYUAY6gWEcM3+AOmgLZy+h ZSSZMiCm3d34wmEjuTPA/LPPyrg43V93mKUK4E1HrAHmNVGncXhVEeFOYKVYSc1patzznBd2gi/e OKoU0KE4g7EEIjWBLvKw9DOpg64o42rUgQAAAAAAAA== --Apple-Mail-16-228001430-- From dworley@nortel.com Fri Jun 12 09:41:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68EB53A693D for ; Fri, 12 Jun 2009 09:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.682 X-Spam-Level: X-Spam-Status: No, score=-6.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNPdnwWmY1Rm for ; Fri, 12 Jun 2009 09:41:54 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 3DC533A67AF for ; Fri, 12 Jun 2009 09:41:54 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5CGfiZ03942; Fri, 12 Jun 2009 16:41:44 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Jun 2009 12:41:34 -0400 From: "Dale Worley" To: Byron Campen In-Reply-To: <85ED2F6F-EBAC-454D-858B-D3BFAF901CCA@estacado.net> References: <109101c9eae2$f8ef9890$eacec9b0$@net> <1EF42B19-CB00-48C3-9EF7-F15A36AE5CF7@estacado.net> <1244821160.3768.13.camel@victoria-pingtel-com.us.nortel.com> <85ED2F6F-EBAC-454D-858B-D3BFAF901CCA@estacado.net> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 12 Jun 2009 12:41:33 -0400 Message-Id: <1244824893.3768.19.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jun 2009 16:41:34.0422 (UTC) FILETIME=[A5A3D760:01C9EB7C] Cc: sipcore@ietf.org Subject: Re: [sipcore] [Sipping] draft-niemi-sipcore-event-rate-control-00 and forcing notifications when state has not changed X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 16:41:55 -0000 On Fri, 2009-06-12 at 11:02 -0500, Byron Campen wrote: > My main beef is that this shifts > the job of maintaining soft-state to the server. As a general > principle, this has been the client's job, and this is specifically > how SIP events is supposed to work. Allowing the client to say, "Nah, > you're going to handle recovery now." is a rather fundamental change > to the protocol, that we should only make if there is a compelling > reason. I see no such reason. I don't understand this. In my experience, the notifier has to keep quite a bit of state for a subscription. The force mechanism only adds one more timer. Dale From mary.barnes@nortel.com Fri Jun 12 09:43:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5683A67AF for ; Fri, 12 Jun 2009 09:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGDodQSB103V for ; Fri, 12 Jun 2009 09:43:53 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id D71453A6991 for ; Fri, 12 Jun 2009 09:43:52 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5CGhvZ04376; Fri, 12 Jun 2009 16:43:57 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EB7C.E388C4E1" Date: Fri, 12 Jun 2009 11:45:51 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E7D809A@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0906120824s24f0ddfyb9dc6d6c38651d75@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: Acnrcdu+fGwgIJSrTauJO5RsMGAVJgACcmJg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120138y540f7c2bja62adcf942cba3a0@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E787F80@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120824s24f0ddfyb9dc6d6c38651d75@mail.gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 16:43:55 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EB7C.E388C4E1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hans, =20 My confusion comes from the 3rd paragraph in section 6 (the same one that confuses in terms of the unconditional addition of two hi-entries), specifically this text: " When a home proxy receives a request for a user or resource for which is abstract location function returns registered contacts or configured URIs, the proxy adds two History-Info header field values. The first is the incoming request URI. Since the Request-URI identifies a user or resource for which it has a registration or configuration, the Request-URI is an AOR and thus an address for the user. The proxy adds a History-Info header field parameter, "aor", which indicates this. Next, the proxy inserts the contact URI which will be contained in the outgoing Request-URI." =20 (Note: this also confuses me because it is combining determining request targets with the forwarding) =20 But, then later in that section, there's the following text (7th paragraph): "When a proxy receives a request for a user or resource for which it is responsible, then when a request URI rewrite occurs that is a routing translation, then add a History-Info header field parameter "routed" to the hi-entry recording the incoming request URI. Otherwise when a request URI rewrite occurs that is a mapping translation, then add a History-Info header field parameter "mapped" to the hi-entry recording the incoming request URI. " =20 So, it's just not clear at all to me how you coordinate the addition of the two tags. Perhaps, it's just how that section is written, but again, this is my point that it's really difficult to understand your solution proposal when it is not described in the context of the current normative RFC 4244 functionality. =20 =20 This solution also does not seem to give clear delineation between registered contacts versus configured URIs. I had understood that to be important for some services. In particular, how will this solution support being able to identify aliases? =20 Thanks, Mary.=20 =20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Friday, June 12, 2009 10:24 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi Mary, I do not understand what you mean with multi stage. All the tagging can be prepared at the time that the translation is done and added at the time that 4244 suggests the H-I to be added. If the current text suggests otherwise, then we might need to fix that. BR, /Hans Erik van Elburg On Fri, Jun 12, 2009 at 4:11 PM, Mary Barnes wrote: Hi Hans, =20 A couple comments below [MB]. =20 Mary. ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Friday, June 12, 2009 3:38 AM=20 To: Barnes, Mary (RICH2:AR00) =09 Cc: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt =09 =09 Hi Mary, =09 Sure when we agree on the way forward we have to resolve all these detailed procedures and conform to the 4244 language etc. But we already agreed to integrate it into 4424bis at the moment that there is agreement about the solution.=20 =09 Regarding the two tag approach that is open for discussion, i think it is more clean and in general pays off to separate concepts that are independent from each other. For example a hi-entry may be routed and not be an AOR, whereas it may also be routed and also an AOR. The decisions to be taken for additions of these tags are independent, so there is also no need to intertwine procedural text for them. (It is also more clear for implementors.)=20 [MB] This is where my major confusion is in that you say the tags are independent, BUT where in the normative RFC 3261 processing does this occur? I'm confused because the logic in section 16.5 isn't "multi-stage" (for lack of a better term), the incoming request URI is evaluated and then the new target list is constructed The tagging in 4244 is based on the mechanism by which a new target is determined . The previous hi-entry (that in the incoming request) is tagged at the point the request is being forwarded. I do agree that in the internal processing that information needs to exist so that the tagging at the point of forwarding the request is appropriate. [/MB] =20 BR, /Hans Erik van Elburg =09 =09 On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes wrote: =09 Christer, =09 I reviewed the updated target-uri draft and have a few comments - well I reviewed the diff since there isn't a summary of changes in the document: =09 1) I had a lot of difficulty picking out the normative processing for History-Info in this document. Can you summarize the differences? =09 2) The reason I'm concerned about understanding how this fits with the current normative processing is because I'm not seeing precisely when these tags are added as the terminology is different than that used in RFC 4244 - i.e., are these two terms equivalent: RFC 4244: "... hi-entry received in the request being forwarded." =09 target-uri: "...hi-entry recording the incoming request URI." =09 There is no reference in terms of current History-Info processing as to when in the request processing these tags are added. =09 3) In particular, I'm having difficulty with this text in section 6: "When a home proxy receives a request for a user or resource for which is abstract location function returns registered contacts or configured URIs, the proxy adds two History-Info header field values. The first is the incoming request URI. Since the Request-URI identifies a user or resource for which it has a registration or configuration, the Request-URI is an AOR and thus an address for the user. The proxy adds a History-Info header field parameter, "aor", which indicates this. Next, the proxy inserts the contact URI which will be contained in the outgoing Request-URI." Currently, in RFC 4244, the proxy only adds that additional (first) hi-entry IF there wasn't one in the incoming request, since the UAC can initially add one when it builds the request. So, this is inconsistent with current RFC 4244. And, I think you need to define "home" proxy - that's not an RFC 3261 term - there is the concept of a "home" domain. =09 4) There is a bug in the Syntax (section 9) - the Index is not optional (that is an error we have fixed in the 4244bis). =09 5) I'm really confused about this two-stage tagging - how does that happen in the context of the determination of Request Targets in section 16.5 of RFC3261? Wouldn't the decisions as to the addition of the two different tags occur at the same time and thus what is the advantage of the defining the two tags - i.e., why not one tag for each combination? Also, are you proposing that the addition of the tags be mandatory - there is no normative language in the target-uri document, so it's impossible to tell. And, if you are proposing they be mandatory, your ABNF syntax needs to reflect that, thus defining a single parameter with multiple values would be necessary (which is the approach in 4244bis). =09 =09 6) What is the difference (or is there a difference?) between the functionality associated with the tags in 4244bis and the tags defined in this document in terms of types of retargets that are being tagged? I think this is the crux of what we need to agree - i.e., why aren't the 4244bis tags sufficient? If there is no logical difference and it's just the words used to define the tags, then we're very close to agreement. =09 Regards, Mary. =09 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Thursday, June 11, 2009 3:32 PM =09 To: Christer Holmberg; Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt =09 =09 Here is the link to the latest version of the target-uri draft: =09 =09 http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00. txt =20 =09 -----Original Message----- From: Christer Holmberg Sent: Thursday, June 11, 2009 11:31 PM To: 'Mary Barnes'; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt =09 =09 Hi, =09 I think it is important to mention that there are still different approaches regarding the target uri delivery, and that there is another approach described in the latest version of the target-uri delivery draft (I am not sure it appears in the archieves, though, for some reason). Both approaches are based on History-Info, though. =09 We haven't yet been able to agree on an approach, so we thought the best is to bring it to the list in order for other people to get involved. =09 Regards, =09 Christer =09 =09 =09 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Thursday, June 11, 2009 9:05 PM To: sipcore@ietf.org Subject: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt =09 Hi folks, =09 We have made a few changes to this document which was submitted last week just to tie up some loose ends and inconsistencies, some of which Shida identified when he reviewed the -00 version. =09 The following summarizes the high level changes in the sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San Francisco: 1) Renamed the "retarget" parameter to "target" and defined explicit tags to reflect the various mechanisms by which a Request is retargeted. All entries are now tagged. 2) Updated redirect server processing as the redirect server must capture the "target" parameter since it is the entity that knows the specific mechanism by which the new target has been determined. 3) Changed the privacy such that rather than removing entries based on the various values of the privacy header, the entries are recommended to be anonymized. 4) Updated security section 5) Updated examples to reflect the new parameter, use loose routing and fix errors/nits. 6) Editorial changes to remove redundant text and the convuluted text around optionality in the non-normative sections, which is now discussed appropriately in the context of the histinfo option tag. =09 The detailed changes between the versions are summarized in the document. =09 If you're wanting to look at a diff, I would recommend you diff against RFC 4244 rather than the earlier 4244bis documents. =09 We'd really appreciate feedback on this approach to precisely tagging all the entries. We believe it is comprehensive and should suffice for all the use cases identified in the target-uri document, as well as any others that might arise. =09 Thanks, Mary and Francois. =09 -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, June 11, 2009 12:45 PM To: i-d-announce@ietf.org Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt =09 A New Internet-Draft is available from the on-line Internet-Drafts directories. =09 Title : An Extension to the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, F. Audet Filename : draft-barnes-sipcore-rfc4244bis-01.txt Pages : 42 Date : 2009-06-11 =09 This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests. =09 A URL for this Internet-Draft is: =09 http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01.t xt =20 =09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =09 ------_=_NextPart_001_01C9EB7C.E388C4E1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Hans,
 
My = confusion comes=20 from the 3rd paragraph in section 6 (the same one that confuses in terms = of the=20 unconditional addition of two hi-entries), specifically this=20 text:
" When a home proxy receives a request = for a user=20 or resource for which
   is abstract location function = returns=20 registered contacts or
   configured URIs, the proxy adds = two=20 History-Info header field values.
   The first is the = incoming=20 request URI.  Since the Request-URI
   identifies a = user or=20 resource for which it has a registration or
   = configuration, the=20 Request-URI is an AOR and thus an address for the
   = user.  =20 The proxy adds a History-Info header field parameter, = "aor",
  =20 which indicates this.  Next, the proxy inserts the contact URI=20 which
   will be contained in the outgoing=20 Request-URI."
 
(Note: this also confuses me because it is = combining=20 determining request targets with the=20 forwarding)
 
But, then later  in that section, = there's the=20 following text (7th paragraph):
  "When a proxy receives a request for a = user or=20 resource for which it
   is responsible, then when a = request URI=20 rewrite occurs that is a
   routing translation, then add a = History-Info header field parameter
   "routed" to the = hi-entry=20 recording the incoming request URI.
   Otherwise when a = request URI=20 rewrite occurs that is a mapping
   translation, then add a = History-Info header field parameter "mapped"
   to the = hi-entry=20 recording the incoming request URI. "
 
So, it's just not clear at all to me how = you=20 coordinate the addition of the two tags.  Perhaps, it's just how = that=20 section is written, but again, this is my point that it's really = difficult to=20 understand your solution proposal when it is not described in the = context of the=20 current normative RFC 4244 functionality. =20
 
This solution also does not seem to give = clear=20 delineation between registered contacts versus configured URIs. I had = understood=20 that to be important for some services. In particular, how will this = solution=20 support being able to identify = aliases?
 
Thanks,
Mary.
 
From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Friday, June 12, 2009 = 10:24=20 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer = Holmberg;=20 sipcore@ietf.org
Subject: Re: [sipcore] FW: I-D=20 Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi Mary,

I do not understand what you mean with multi = stage.=20 All the tagging can be prepared at the time that the translation is done = and=20 added at the time that 4244 suggests the H-I to be added. If the current = text=20 suggests otherwise, then we might need to fix that.

BR,/Hans Erik van Elburg


On Fri, Jun 12, 2009 at 4:11 PM, Mary Barnes = <mary.barnes@nortel.com>=20 wrote:
Hi = Hans,
 
A couple = comments below=20 [MB].
 
Mary.

From: Hans Erik van Elburg = [mailto:ietf.hanserik@gmail.com]
Sent: Friday, = June 12,=20 2009 3:38 AM

To: Barnes, Mary = (RICH2:AR00)
Cc:=20 Christer Holmberg; sipcore@ietf.org
Subject: Re: [sipcore] = FW: I-D=20 Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi Mary,

Sure when we agree on the way forward we have to = resolve=20 all these detailed procedures and conform to the 4244 language etc. = But we=20 already agreed to integrate it into 4424bis at the moment that there = is=20 agreement about the solution.

Regarding the two tag approach = that is=20 open for discussion, i think it is more clean and in general pays off = to=20 separate concepts that are independent from each other. For example a = hi-entry=20 may be routed and not be an AOR, whereas it may also be routed and = also an=20 AOR. The decisions to be taken for additions of these tags are = independent, so=20 there is also no need to intertwine procedural text for them. (It is = also more=20 clear for implementors.) 
[MB] This = is where my=20 major confusion is in that you say the tags are independent, BUT where = in the=20 normative RFC 3261 processing does this occur?  I'm confused = because=20 the logic in section 16.5 isn't "multi-stage" (for lack of a = better=20 term), the incoming request URI is evaluated and then the new = target list=20 is constructed   The tagging in 4244 is based on the = mechanism by=20 which a new target is determined .  The previous hi-entry = (that in=20 the incoming request) is tagged at the point the request is being = forwarded. I=20 do agree that in the internal processing that information needs = to exist=20 so that the tagging at the point of forwarding the request is=20 appropriate.  [/MB]
 


BR,
/Hans Erik van Elburg

On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes = <mary.barnes@nortel.com> wrote:
Christer,

I=20 reviewed the updated target-uri draft and have a few comments - well = I
reviewed the diff since there isn't a summary of changes in=20 the
document:

1) I had a lot of difficulty picking out the = normative processing for
History-Info in this document. Can you = summarize=20 the differences?

2) The reason I'm concerned about = understanding how=20 this fits with the
current normative processing is because I'm = not seeing=20 precisely when
these tags are added as the terminology is = different than=20 that used in
RFC 4244 - i.e., are these two terms = equivalent:
RFC=20 4244:
"... hi-entry received in the request being=20 forwarded."

target-uri:
"...hi-entry recording the = incoming=20 request URI."

There is no reference in terms of current = History-Info=20 processing as to
when in the request processing these tags are=20 added.

3) In particular, I'm having difficulty with this text = in=20 section 6:
  "When a home proxy receives a request for a = user or=20 resource for
which
  is abstract location function = returns=20 registered contacts or
  configured URIs, the proxy adds two = History-Info header field values.
  The first is the = incoming=20 request URI.  Since the Request-URI
  identifies a user = or=20 resource for which it has a registration or
  configuration, = the=20 Request-URI is an AOR and thus an address for the
  user. =  The=20 proxy adds a History-Info header field parameter, "aor",
  = which=20 indicates this.  Next, the proxy inserts the contact URI=20 which
  will be contained in the outgoing=20 Request-URI."
Currently, in RFC 4244, the proxy only adds that = additional=20 (first)
hi-entry IF there wasn't one in the incoming request, = since the=20 UAC can
initially add one when it builds the request. So, this is = inconsistent
with current RFC 4244. And, I think you need to = define=20 "home" proxy -
that's not an RFC 3261 term - there is the concept = of a=20 "home" domain.

4) There is a bug in the Syntax (section 9) - = the=20 Index is not optional
(that is an error we have fixed in the=20 4244bis).

5) I'm really confused about this two-stage tagging = - how=20 does that
happen in the context of the determination of Request = Targets=20 in section
16.5 of RFC3261? Wouldn't the decisions as to the = addition of=20 the two
different tags occur at the same time and thus what is = the=20 advantage of
the defining the two tags - i.e., why not one tag = for each=20 combination?
Also, are you proposing that the addition of the = tags be=20 mandatory -
there is no normative language in the target-uri = document, so=20 it's
impossible to tell.  And, if you are proposing they be=20 mandatory, your
ABNF syntax needs to reflect that, thus defining = a single=20 parameter with
multiple values would be necessary (which is the = approach=20 in 4244bis).


6) What is the difference (or is there a=20 difference?) between the
functionality associated with the tags = in=20 4244bis and the tags defined
in this document in terms of types = of=20 retargets that are being tagged?
I think this is the crux of what = we need=20 to agree - i.e., why aren't the
4244bis tags sufficient?  If = there=20 is no logical difference and it's
just the words used to define = the tags,=20 then we're very close to
agreement.

Regards,
Mary.



-----Original Message-----
From: Christer = Holmberg=20 [mailto:christer.holmberg@ericsson.com]
Sent: = Thursday, June=20 11, 2009 3:32 PM
To: Christer Holmberg; Barnes, Mary (RICH2:AR00); sipcore@ietf.org
Subject: RE: [sipcore] FW:=20 I-D
Action:draft-barnes-sipcore-rfc4244bis-01.txt


Here = is the=20 link to the latest version of the target-uri draft:

http://tools.ietf.org/id/draft-rosenberg-sipcore-target-u= ri-delivery-00.
txt

-----Original=20 Message-----
From: Christer Holmberg
Sent: Thursday, June 11, = 2009=20 11:31 PM
To: 'Mary Barnes'; sipcore@ietf.org
Subject: RE: [sipcore] FW:=20 = I-D
Action:draft-barnes-sipcore-rfc4244bis-01.txt


Hi,
I=20 think it is important to mention that there are still=20 different
approaches regarding the target uri delivery, and that = there is=20 another
approach described in the latest version of the = target-uri=20 delivery
draft (I am not sure it appears in the archieves, = though, for=20 some
reason). Both approaches are based on History-Info,=20 though.

We haven't yet been able to agree on an approach, so = we=20 thought the best
is to bring it to the list in order for other = people to=20 get = involved.

Regards,

Christer



-----Original=20 Message-----
From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
Behalf Of Mary=20 Barnes
Sent: Thursday, June 11, 2009 9:05 PM
To: sipcore@ietf.org
Subject: [sipcore] FW: I-D=20 Action:draft-barnes-sipcore-rfc4244bis-01.txt

Hi = folks,

We=20 have made a few changes to this document which was submitted = last
week=20 just to tie up some loose ends and inconsistencies, some of = which
Shida=20 identified when he reviewed the -00 version.

The following = summarizes=20 the high level changes in the
sipcore-rfc4244bis from the = sip-rfc4244bis=20 that we discussed in San
Francisco:
1) Renamed the "retarget"=20 parameter to "target" and defined explicit
tags to reflect the = various=20 mechanisms by which a Request is retargeted.
All entries are now=20 tagged.
2) Updated redirect server processing as the redirect = server=20 must
capture the "target" parameter since it is the entity that = knows=20 the
specific mechanism by which the new target has been = determined.
3)=20 Changed the privacy such that rather than removing entries based = on
the=20 various values of the privacy header, the entries are recommended = to
be=20 anonymized.
4) Updated security section
5) Updated examples to = reflect=20 the new parameter, use loose routing and
fix errors/nits.
6) = Editorial=20 changes to remove redundant text and the convuluted text
around=20 optionality in the non-normative sections, which is now=20 discussed
appropriately in the context of the histinfo option=20 tag.

The detailed changes between the versions are summarized = in=20 the
document.

If you're wanting to look at a diff, I would = recommend you diff against
RFC 4244 rather than the earlier = 4244bis=20 documents.

We'd really appreciate feedback on this approach = to=20 precisely tagging
all the entries. We believe it is comprehensive = and=20 should suffice for
all the use cases identified in the target-uri = document, as well as any
others that might = arise.

Thanks,
Mary=20 and Francois.

-----Original Message-----
From: i-d-announce-bounces@ietf.org
[mailto:i-d-announce-bounces@ietf.org] On Behalf = Of
Internet-Drafts@ietf.org
Sent: Thursday, June = 11, 2009=20 12:45 PM
To: i-d-announce@ietf.org
Subject: I-D=20 Action:draft-barnes-sipcore-rfc4244bis-01.txt

A New = Internet-Draft is=20 available from the on-line = Internet-Drafts
directories.

 =20      Title           : An = Extension=20 to the Session Initiation
Protocol (SIP) for Request History=20 Information
       Author(s)     =   :=20 M. Barnes, F. Audet
       Filename   =  =20    : draft-barnes-sipcore-rfc4244bis-01.txt
  =  =20    Pages           : 42
  =  =20    Date            :=20 2009-06-11

This document defines a standard mechanism for = capturing=20 the history
information associated with a Session Initiation = Protocol=20 (SIP) request.
This capability enables many enhanced services by=20 providing the
information as to how and why a call arrives at a = specific=20 application
or user.  This document defines a new optional = SIP=20 header, History-Info,
for capturing the history information in=20 requests.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-barnes-sipcore-= rfc4244bis-01.t
xt

Internet-Drafts=20 are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below = is the=20 data which will enable a MIME compliant mail = reader
implementation to=20 automatically retrieve the ASCII version of=20 = the
Internet-Draft.
_______________________________________________=
sipcore=20 mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


<= /BODY> ------_=_NextPart_001_01C9EB7C.E388C4E1-- From bcampen@estacado.net Fri Jun 12 10:25:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4643A68FB for ; Fri, 12 Jun 2009 10:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOmUutCd+ipt for ; Fri, 12 Jun 2009 10:25:44 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id E385E3A67E1 for ; Fri, 12 Jun 2009 10:25:43 -0700 (PDT) Received: from dn3-233.estacado.net (dn3-233.estacado.net [172.16.3.233]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n5CHPnhG037271 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Jun 2009 12:25:49 -0500 (CDT) (envelope-from bcampen@estacado.net) Message-Id: From: Byron Campen To: "Dale Worley" In-Reply-To: <1244824893.3768.19.camel@victoria-pingtel-com.us.nortel.com> Content-Type: multipart/signed; boundary=Apple-Mail-17-232377109; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 12:25:45 -0500 References: <109101c9eae2$f8ef9890$eacec9b0$@net> <1EF42B19-CB00-48C3-9EF7-F15A36AE5CF7@estacado.net> <1244821160.3768.13.camel@victoria-pingtel-com.us.nortel.com> <85ED2F6F-EBAC-454D-858B-D3BFAF901CCA@estacado.net> <1244824893.3768.19.camel@victoria-pingtel-com.us.nortel.com> X-Mailer: Apple Mail (2.935.3) Cc: sipcore@ietf.org Subject: Re: [sipcore] [Sipping] draft-niemi-sipcore-event-rate-control-00 and forcing notifications when state has not changed X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 17:25:45 -0000 --Apple-Mail-17-232377109 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > On Fri, 2009-06-12 at 11:02 -0500, Byron Campen wrote: >> My main beef is that this shifts >> the job of maintaining soft-state to the server. As a general >> principle, this has been the client's job, and this is specifically >> how SIP events is supposed to work. Allowing the client to say, "Nah, >> you're going to handle recovery now." is a rather fundamental change >> to the protocol, that we should only make if there is a compelling >> reason. I see no such reason. > > I don't understand this. In my experience, the notifier has to keep > quite a bit of state for a subscription. The force mechanism only > adds > one more timer. The subscription itself was the soft-state I was referring to; the whole idea is that, if the client stops maintaining it, it goes away in a reasonable amount of time. I worry that this will be circumvented by implementors through the force mechanism. Best regards, Byron Campen --Apple-Mail-17-232377109 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGZDCCAx0w ggKGoAMCAQICEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDkyMzA0MzgwNFoXDTA5MDkyMzA0Mzgw NFowazEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQxIzAhBgkqhkiG9w0BCQEWFGRvY2ZhcmFkYXlAZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIGiyvzQgsqDjR3TiFTO4nkc/VRo/eX6xKu ky4CR2QtnIPEWhNLbU5UgXdGzU3YWx/cRj5alT0auKVQ/BnjCbf3bFSzP5mIfV6KlJV89dpxKQQA 3FaDYxE3whiRPIjQh3nmqxSacBTLohlt/g8MlFyiHoNs3XcH83M3QMjMxU8pD7SgXUDaXdtqC8vV +7g3rzPmlONdJ+4vac159wuZe37WVTsFI4sYL3p/KvqT1NZhmn1cmOVWKfCVAdGLk8VEUZtWuSeM NU5CLnFvenxaSPkDeVR5h0qDpw4DQyHfWXQuKvRs1WgVeHASz87EPgncyp90yiByetvE0WIBGKiz 0QIDAQABo0cwRTA1BgNVHREELjAsgRRiY2FtcGVuQGVzdGFjYWRvLm5ldIEUZG9jZmFyYWRheUBn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQANmDZo4t+1SrO9nb8KfjN4 QtlV1gzaAa2jEsAZ369PBXdsxVz32a1JIa1KudXFfMMxtF1NRDJ0Z3ib/qq+L8B28IpkYgRWtRr+ WWm6LzJ6rm1Q85cC0VSqoIRr+NoRZjaBdqWbJC4QsPnwVSXN9jLMLkFkjcxVDSxQtEx6v1PF9zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUP SAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0Eu Y3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2f Ni/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH 1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQW7SrCyoCwnsms5MfcqmjmzAJBgUr DgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2 MTIxNzI1NDZaMCMGCSqGSIb3DQEJBDEWBBSkLd7Ki9h4bxZ36uItIlduCdyfiDCBhQYJKwYBBAGC NxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsq AsJ7JrOTH3Kpo5swgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEBBQAEggEAhkhf 0yNyc/biB63iAIDdTnRgc1LjSbe7rP9I6PsKV7NcaMiBABC1ipEqf7lZyaQM7cA0u6j3f+mRe0+1 svgullpV85qmKsnjOARqFCwsqSIJE65iOr/MvXyde1aiGRO1iKHiFMtixavYRFYFzzWnUMjvNIuO sk5JcdJPrtykLkrYuQKST3zac/WNGAnQ4+/cwFo/xoQes/i6pAuGoMXb0zHz8uiKr3KhOO5wkdvw AHrIYOFjWfR1Iie/PLdG//kmqezWzfS6Yf8izoYmlpgoA6wmcpoOsFoIyFyHdsajBHmiyJFPKLXl cNuDf7QSira61Z0qj8eb/zKJa8fs5d4aTAAAAAAAAA== --Apple-Mail-17-232377109-- From bcampen@estacado.net Fri Jun 12 10:44:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 266623A68FD for ; Fri, 12 Jun 2009 10:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LU97vTVdB+pf for ; Fri, 12 Jun 2009 10:44:31 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id E23FF3A68D8 for ; Fri, 12 Jun 2009 10:44:30 -0700 (PDT) Received: from dn3-233.estacado.net (dn3-233.estacado.net [172.16.3.233]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n5CHiaSL040222 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Jun 2009 12:44:36 -0500 (CDT) (envelope-from bcampen@estacado.net) Message-Id: From: Byron Campen To: "Dale Worley" In-Reply-To: <1244824893.3768.19.camel@victoria-pingtel-com.us.nortel.com> Content-Type: multipart/signed; boundary=Apple-Mail-18-233503984; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 12:44:32 -0500 References: <109101c9eae2$f8ef9890$eacec9b0$@net> <1EF42B19-CB00-48C3-9EF7-F15A36AE5CF7@estacado.net> <1244821160.3768.13.camel@victoria-pingtel-com.us.nortel.com> <85ED2F6F-EBAC-454D-858B-D3BFAF901CCA@estacado.net> <1244824893.3768.19.camel@victoria-pingtel-com.us.nortel.com> X-Mailer: Apple Mail (2.935.3) Cc: sipcore@ietf.org Subject: Re: [sipcore] [Sipping] draft-niemi-sipcore-event-rate-control-00 and forcing notifications when state has not changed X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 17:44:32 -0000 --Apple-Mail-18-233503984 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Jun 12, 2009, at 11:41 AM, Dale Worley wrote: > On Fri, 2009-06-12 at 11:02 -0500, Byron Campen wrote: >> My main beef is that this shifts >> the job of maintaining soft-state to the server. As a general >> principle, this has been the client's job, and this is specifically >> how SIP events is supposed to work. Allowing the client to say, "Nah, >> you're going to handle recovery now." is a rather fundamental change >> to the protocol, that we should only make if there is a compelling >> reason. I see no such reason. > > I don't understand this. In my experience, the notifier has to keep > quite a bit of state for a subscription. The force mechanism only > adds > one more timer. I also should have noted that I don't object to there being a force mechanism at all; I only object to it forcing notifications to be sent when the state is exactly the same as the last NOTIFY (I also object to it forcing a full-state notification; if the client wants full state, it should send a SUBSCRIBE). If you have mechanisms that can suppress notifications, a force mechanism is a nice thing to have. I just see no value in having doubly gratuitous full-state notifications. Best regards, Byron Campen --Apple-Mail-18-233503984 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGZDCCAx0w ggKGoAMCAQICEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDkyMzA0MzgwNFoXDTA5MDkyMzA0Mzgw NFowazEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQxIzAhBgkqhkiG9w0BCQEWFGRvY2ZhcmFkYXlAZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIGiyvzQgsqDjR3TiFTO4nkc/VRo/eX6xKu ky4CR2QtnIPEWhNLbU5UgXdGzU3YWx/cRj5alT0auKVQ/BnjCbf3bFSzP5mIfV6KlJV89dpxKQQA 3FaDYxE3whiRPIjQh3nmqxSacBTLohlt/g8MlFyiHoNs3XcH83M3QMjMxU8pD7SgXUDaXdtqC8vV +7g3rzPmlONdJ+4vac159wuZe37WVTsFI4sYL3p/KvqT1NZhmn1cmOVWKfCVAdGLk8VEUZtWuSeM NU5CLnFvenxaSPkDeVR5h0qDpw4DQyHfWXQuKvRs1WgVeHASz87EPgncyp90yiByetvE0WIBGKiz 0QIDAQABo0cwRTA1BgNVHREELjAsgRRiY2FtcGVuQGVzdGFjYWRvLm5ldIEUZG9jZmFyYWRheUBn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQANmDZo4t+1SrO9nb8KfjN4 QtlV1gzaAa2jEsAZ369PBXdsxVz32a1JIa1KudXFfMMxtF1NRDJ0Z3ib/qq+L8B28IpkYgRWtRr+ WWm6LzJ6rm1Q85cC0VSqoIRr+NoRZjaBdqWbJC4QsPnwVSXN9jLMLkFkjcxVDSxQtEx6v1PF9zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUP SAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0Eu Y3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2f Ni/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH 1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQW7SrCyoCwnsms5MfcqmjmzAJBgUr DgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2 MTIxNzQ0MzJaMCMGCSqGSIb3DQEJBDEWBBQGrNzI/KYAt9RCVjboSK68PwKarDCBhQYJKwYBBAGC NxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsq AsJ7JrOTH3Kpo5swgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEBBQAEggEANUf5 ezpCbThgGA7Z/W8HRDTdxppXF5GTKOTP1MYJg08N8woa9l6KJ+F323SjC6Mgey4/9kLTD2FgytVZ UPvmOtu596q880fPNLfjB0th/iZt/AfKH9T6h0NFfG1h6xgnOgYsUXa7qM3PkD5UGtki6sZ5Kemz hpOpB2/Llk+iowyMZ0Ngly1Yvq4MUbWY9FBtAhiXAh8Pu+TmaD5TQmgPajeqQoPDqyUTuYrblDuu J6b7pdzi1DDnQ/28e+WkY/2oe9QZyToFPd1sC/V563UWKBgommOdkL840TjjJcT1dhmgRIgHqtpR hyCHI2F8QYZoVtZBplB+L/snNHIQFJbmRgAAAAAAAA== --Apple-Mail-18-233503984-- From AUDET@nortel.com Fri Jun 12 11:20:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 763193A6A6F for ; Fri, 12 Jun 2009 11:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBn+UMB8FcdJ for ; Fri, 12 Jun 2009 11:20:03 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id F06653A677C for ; Fri, 12 Jun 2009 11:20:02 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5CIIi127093; Fri, 12 Jun 2009 18:18:44 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 13:18:53 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E7D828B@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwABgxmCAAFTBxQA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> From: "Francois Audet" To: "Christer Holmberg" , "DOLLY, MARTIN C, ATTLABS" , "Mary Barnes" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 18:20:04 -0000 This is a lame way to describe the problem without describing what a=20 service number is. Also, it is completely innacurate.=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Friday, June 12, 2009 01:13 > To: DOLLY, MARTIN C, ATTLABS; Barnes, Mary (RICH2:AR00);=20 > sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi, >=20 > The biggest difference is regarding support of service-number=20 > (like toll-free/freephone) type-of services, where the=20 > Request-URI translation does not change the targeted user or=20 > resource. Without going in to the protocol differences (which=20 > aren't that big), my understanding of the functional=20 > differences are the following: >=20 > - 4244bis approach does not distinguish between=20 > service-number (like toll-free/freephone) number translation=20 > and diversion. >=20 > - 4244bis approach does not allow a service-number (like=20 > toll-free/freephone) translation for a user which belongs to=20 > another domain. >=20 > - 4244bis requires that all service-numbers for a=20 > user/company (like toll-free/freephone) must be registered=20 > (explicitly or implictly), which means that the translation=20 > must be done by an entity (normally the registrar) which has=20 > the registration information for the called user. >=20 >=20 > The target uri approach does allow translation in another=20 > domain, and does not require toll-free/freephone numbers to=20 > be registered for the called user. >=20 > So, I don't think that the 4244bis approach supports all=20 > service-numbers (like toll-free/freephone) in a sufficient=20 > way, and that it is too restrictive for no good reason. It=20 > imposes restrictions on the potential business models that=20 > are not necessary. >=20 > Regards, >=20 > Christer=20 >=20 >=20 > > -----Original Message----- > > From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > > Sent: 11. kes=E4kuuta 2009 23:40 > > To: Christer Holmberg; Mary Barnes; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > Hello, > >=20 > > Can someone please summarize the differences between the two=20 > > approaches? > >=20 > > Thanks, > >=20 > > Martin > >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: Thursday, June 11, 2009 4:32 PM > > To: Christer Holmberg; Mary Barnes; sipcore@ietf.org > > Subject: Re: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Here is the link to the latest version of the target-uri draft: > >=20 > > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-de > > livery-00. > > txt > >=20 > > -----Original Message----- > > From: Christer Holmberg > > Sent: Thursday, June 11, 2009 11:31 PM > > To: 'Mary Barnes'; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > I think it is important to mention that there are still different=20 > > approaches regarding the target uri delivery, and that there is=20 > > another approach described in the latest version of the target-uri=20 > > delivery draft (I am not sure it appears in the archieves,=20 > though, for=20 > > some reason). Both approaches are based on History-Info, though. > >=20 > > We haven't yet been able to agree on an approach, so we thought the=20 > > best is to bring it to the list in order for other people to get=20 > > involved. > >=20 > > Regards, > >=20 > > Christer > >=20 > > =20 > >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > > Behalf Of Mary Barnes > > Sent: Thursday, June 11, 2009 9:05 PM > > To: sipcore@ietf.org > > Subject: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > Hi folks, > >=20 > > We have made a few changes to this document which was=20 > submitted last=20 > > week just to tie up some loose ends and inconsistencies,=20 > some of which=20 > > Shida identified when he reviewed the -00 version. > >=20 > > The following summarizes the high level changes in the=20 > > sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San > > Francisco: > > 1) Renamed the "retarget" parameter to "target" and defined=20 > explicit=20 > > tags to reflect the various mechanisms by which a Request is=20 > > retargeted. > > All entries are now tagged.=20 > > 2) Updated redirect server processing as the redirect server must=20 > > capture the "target" parameter since it is the entity that=20 > knows the=20 > > specific mechanism by which the new target has been determined. > > 3) Changed the privacy such that rather than removing=20 > entries based on=20 > > the various values of the privacy header, the entries are=20 > recommended=20 > > to be anonymized. > > 4) Updated security section > > 5) Updated examples to reflect the new parameter, use loose routing=20 > > and fix errors/nits. > > 6) Editorial changes to remove redundant text and the=20 > convuluted text=20 > > around optionality in the non-normative sections, which is now=20 > > discussed appropriately in the context of the histinfo option tag. > >=20 > > The detailed changes between the versions are summarized in the=20 > > document. > >=20 > > If you're wanting to look at a diff, I would recommend you diff=20 > > against RFC 4244 rather than the earlier 4244bis documents. > >=20 > > We'd really appreciate feedback on this approach to=20 > precisely tagging=20 > > all the entries. We believe it is comprehensive and should=20 > suffice for=20 > > all the use cases identified in the target-uri document, as well as=20 > > any others that might arise. > >=20 > > Thanks, > > Mary and Francois. > >=20 > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > > Internet-Drafts@ietf.org > > Sent: Thursday, June 11, 2009 12:45 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > >=20 > > Title : An Extension to the Session Initiation > > Protocol (SIP) for Request History Information > > Author(s) : M. Barnes, F. Audet > > Filename : draft-barnes-sipcore-rfc4244bis-01.txt > > Pages : 42 > > Date : 2009-06-11 > >=20 > > This document defines a standard mechanism for capturing=20 > the history=20 > > information associated with a Session Initiation Protocol > > (SIP) request. > > This capability enables many enhanced services by providing the=20 > > information as to how and why a call arrives at a specific=20 > application=20 > > or user. This document defines a new optional SIP header,=20 > > History-Info, for capturing the history information in requests. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc42 > > 44bis-01.t > > xt > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > > _______________________________________________ > > 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 >=20 From AUDET@nortel.com Fri Jun 12 11:36:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 578A13A6BC8 for ; Fri, 12 Jun 2009 11:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDyKVkZ3CxIC for ; Fri, 12 Jun 2009 11:36:32 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 4F84B3A6A07 for ; Fri, 12 Jun 2009 11:36:32 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5CIZF100881; Fri, 12 Jun 2009 18:35:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 13:36:24 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSA= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> From: "Francois Audet" To: "DOLLY, MARTIN C, ATTLABS" , "Christer Holmberg" , "Mary Barnes" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 18:36:33 -0000 Here is the summary. I'm going to spare details, but the main different is as follows. 1) RFC 4244bis In RFC 4244bis, if the domain is responsible for the URI in the Request-URI and it replacing it with a Contact, it will put a reg-uri flag (if the Request-URI was the AOR used for=20 registration), or reg-uri-alias (if the Request-URI was an=20 alias for the AOR used in registration). If the domain is responsible for the URI and it "maps" it to a different user, then it puts a "mapped" flag. If the domain is NOT responsible for the AOR but it changes the Request-URI nevertheless, then it is also marked as "mapped". Note: With loose routing, this is not supposed to happen=20 (at least in theory). This next statement is where there is a big difference: If the domain is NOT responsible for the URI, the mapping cannot know if the new URI is belongs to the same User than the original one. This is why it is mapping: it is impossible for a proxy NOT responsible for a URI to change it to something else and "know" if it a different user (retarget) or just a "synonym" for the same user. 2) Target-UI In target-URI, there is an assumption that a domain NOT responsible for a URI can change the URI to something AND know authoritatively that the new target is a "synonym" for the original target. ------------- So this is what it boils down to. Can a domain NOT responsible for a target change the target AND mark the new target authoritatively as "belonging" to the same user? In target-URI, the assumption is yes. In 4244bis, the assumption is no (only the domain responsible for the = URI can do so).=20 ---- As pointed out by Paul Kyzivat, we probably need to think on how this works with Tel URIs. I think for Tel URI it would be totally different. > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, MARTIN=20 > C, ATTLABS > Sent: Thursday, June 11, 2009 13:40 > To: Christer Holmberg; Barnes, Mary (RICH2:AR00); sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hello, >=20 > Can someone please summarize the differences between the two=20 > approaches? >=20 > Thanks, >=20 > Martin From ietf.hanserik@gmail.com Fri Jun 12 12:07:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63CF928C245 for ; Fri, 12 Jun 2009 12:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dol4qi3jleWE for ; Fri, 12 Jun 2009 12:07:50 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 0F8603A6BC8 for ; Fri, 12 Jun 2009 12:07:49 -0700 (PDT) Received: by ewy6 with SMTP id 6so3250536ewy.37 for ; Fri, 12 Jun 2009 12:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=hBwPqEPEshbr6kqpA68VEPysFtL0G90ONusoJTyVdp0=; b=V1GEcbNLVj0WswoloT0sX+2j22AH1C5MsgVZk195q0KKlB4b8y5lAg0W4wZFzOCofo /MClXlcwUYwEvmhQ/fTApz5NtkvuWzP+E9qPtC1Je97LCksR4t93ijG+LEx69yhA/HV6 RxxKmXJBpDJyZqmXKPybuKIZWQMMzDkY8uJs8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=P31oOUa5KynyO3frAd5qVdqjSq5DkAgS0AHp+7ozIBnwjPVGbQzlvLlqY42GP7DkHf wbMlq25v7n+8Shb1mUrL0QDnuBG5C5k4qSlYkD5uoOPLPtA6VcVMXX/7OEjBoE+QjRU8 qh8LabZ/lI04NtA7qdfDgHAG4+W0WyPay9CbQ= Received: by 10.210.126.18 with SMTP id y18mr1191901ebc.74.1244833674478; Fri, 12 Jun 2009 12:07:54 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 7sm242328eyg.7.2009.06.12.12.07.53 (version=SSLv3 cipher=RC4-MD5); Fri, 12 Jun 2009 12:07:54 -0700 (PDT) Message-ID: <4A32A789.9040802@gmail.com> Date: Fri, 12 Jun 2009 21:07:53 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Francois Audet References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 19:07:51 -0000 Francois, It is clear that a service or tollfree address if expressed as a SIP URI is always delivered to the domain that is expressed in the home part. Such service is therefore responsible for that domain. If it forwards the request to an AOR of another domain, but knows that this is the same addressed target. Then it can tag the hi-entry accordingly. This knowledge is inherently linked to the service being provided, so this can be very reliably decided by this specific proxy. > 2) Target-UI > > In target-URI, there is an assumption that a domain NOT responsible for > a URI can change the URI to something AND know authoritatively that the > new target is a "synonym" for the original target. This is incorrect. An entry is only tagged to be an AOR if the proxy is responsible for the domain and translates Request URI based on a abstract location function lookup. (per RFC3261 section 16.5 ) > Can a domain NOT responsible for a target change the target AND > mark the new target authoritatively as "belonging" to the same user? > > In target-URI, the assumption is yes. This is again incorrect. Target-uri draft does not imply this. It is a misinterpretation. > In 4244bis, the assumption is no (only the domain responsible for the URI can do so). 4424bis does not allow distinction between a diversion and a users service number (like a tollfree number service) Best Regards, /Hans Erik Francois Audet wrote: > Here is the summary. > > I'm going to spare details, but the main different is as follows. > > 1) RFC 4244bis > > In RFC 4244bis, if the domain is responsible for the URI > in the Request-URI and it replacing it with a Contact, it will > put a reg-uri flag (if the Request-URI was the AOR used for > registration), or reg-uri-alias (if the Request-URI was an > alias for the AOR used in registration). > > If the domain is responsible for the URI and it "maps" it > to a different user, then it puts a "mapped" flag. > > If the domain is NOT responsible for the AOR but it changes > the Request-URI nevertheless, then it is also marked as "mapped". > > Note: With loose routing, this is not supposed to happen > (at least in theory). > > This next statement is where there is a big difference: > > If the domain is NOT responsible for the URI, the mapping cannot > know if the new URI is belongs to the same User than the original > one. This is why it is mapping: it is impossible for a proxy NOT > responsible for a URI to change it to something else and "know" if > it a different user (retarget) or just a "synonym" for the same user. > > 2) Target-UI > > In target-URI, there is an assumption that a domain NOT responsible for > a URI can change the URI to something AND know authoritatively that the > new target is a "synonym" for the original target. > > > ------------- > > So this is what it boils down to. > > Can a domain NOT responsible for a target change the target AND > mark the new target authoritatively as "belonging" to the same user? > > In target-URI, the assumption is yes. > > In 4244bis, the assumption is no (only the domain responsible for the URI can > do so). > > ---- > > As pointed out by Paul Kyzivat, we probably need to think on how this > works with Tel URIs. I think for Tel URI it would be totally different. > > > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, MARTIN >> C, ATTLABS >> Sent: Thursday, June 11, 2009 13:40 >> To: Christer Holmberg; Barnes, Mary (RICH2:AR00); sipcore@ietf.org >> Subject: Re: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Hello, >> >> Can someone please summarize the differences between the two >> approaches? >> >> Thanks, >> >> Martin >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From ietf.hanserik@gmail.com Fri Jun 12 12:46:17 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D05513A677C for ; Fri, 12 Jun 2009 12:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FW+ByURFOZs for ; Fri, 12 Jun 2009 12:46:16 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 949C93A65A6 for ; Fri, 12 Jun 2009 12:46:15 -0700 (PDT) Received: by ewy6 with SMTP id 6so3279582ewy.37 for ; Fri, 12 Jun 2009 12:46:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=nXUM1qyqEVd684vFWPamE+J84/fMDD/1nNmLp6i4ZA8=; b=mYNMgWrftbtqG0ziRXLukcy/Gj8a6oWe97qKZZfIzJuoiKfoHdXEHqOyNt9Y4ukR9X MVdbvKlCoNxbZaxPId350JPw1dVC3yqqhFUc6I0mTevKWJG8UpwjUr3ZT0p01nsD7gHX 607BsRud0z1y3vI/dPXQ0E8+F40lbumB3Vmwo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=VMvT+hE64nYV+re692q08/8TIsSWE3s+qZQxcwL9ocVILJHn1/Mr5J55vQUibjd2HX 9Nk3/k/LHPRPBO3ye2pFnSvmxWYeFI+AkSgBR7ctLwW8fNpJFFNYhxecjqw8LsUSOXoX whN/3LRUndRD482VdGuW5k6Cx5SHonvsN9XlQ= Received: by 10.210.37.16 with SMTP id k16mr443462ebk.91.1244835981533; Fri, 12 Jun 2009 12:46:21 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 28sm747737eyg.44.2009.06.12.12.46.20 (version=SSLv3 cipher=RC4-MD5); Fri, 12 Jun 2009 12:46:21 -0700 (PDT) Message-ID: <4A32B08C.4010308@gmail.com> Date: Fri, 12 Jun 2009 21:46:20 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Mary Barnes References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120138y540f7c2bja62adcf942cba3a0@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E787F80@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120824s24f0ddfyb9dc6d6c38651d75@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D809A@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E7D809A@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 19:46:17 -0000 Hi Mary, > So, it's just not clear at all to me how you coordinate the addition of the two tags. Perhaps, it's just how that section is written, > but again, this is my point that it's really difficult to understand your solution proposal when it is not described in the context of > the current normative RFC 4244 functionality. The text can definitely be improved, but still the criteria for adding the tags are independent. I will try draft a chapter as it would look like in 4424. > This solution also does not seem to give clear delineation between registered contacts versus configured URIs. I had understood > that to be important for some services. In particular, how will this solution support being able to identify aliases? Regarding the alias concept, I have no problems in adding that. But it is currently not in scope of the target-uri work, if people agree then we can add that requirement. We could reuse the definition that is contained in the 4424bis draft as I think that is a good definition. But what is the essential difference between bindings that came about due to registration and those that are configured? (To me this has nothing todo with aliases, in fact I think it is not a meaningful difference how the binding was made.) But if you have a requirement for that, you should maybe explain it. /Hans Erik Mary Barnes wrote: > Hi Hans, > > My confusion comes from the 3rd paragraph in section 6 (the same one > that confuses in terms of the unconditional addition of two > hi-entries), specifically this text: > " When a home proxy receives a request for a user or resource for which > is abstract location function returns registered contacts or > configured URIs, the proxy adds two History-Info header field values. > The first is the incoming request URI. Since the Request-URI > identifies a user or resource for which it has a registration or > configuration, the Request-URI is an AOR and thus an address for the > user. The proxy adds a History-Info header field parameter, "aor", > which indicates this. Next, the proxy inserts the contact URI which > will be contained in the outgoing Request-URI." > > (Note: this also confuses me because it is combining determining > request targets with the forwarding) > > But, then later in that section, there's the following text (7th > paragraph): > "When a proxy receives a request for a user or resource for which it > is responsible, then when a request URI rewrite occurs that is a > routing translation, then add a History-Info header field parameter > "routed" to the hi-entry recording the incoming request URI. > Otherwise when a request URI rewrite occurs that is a mapping > translation, then add a History-Info header field parameter "mapped" > to the hi-entry recording the incoming request URI. " > > So, it's just not clear at all to me how you coordinate the addition > of the two tags. Perhaps, it's just how that section is written, but > again, this is my point that it's really difficult to understand your > solution proposal when it is not described in the context of the > current normative RFC 4244 functionality. > > This solution also does not seem to give clear delineation between > registered contacts versus configured URIs. I had understood that to > be important for some services. In particular, how will this solution > support being able to identify aliases? > > Thanks, > Mary. > > ------------------------------------------------------------------------ > *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > *Sent:* Friday, June 12, 2009 10:24 AM > *To:* Barnes, Mary (RICH2:AR00) > *Cc:* Christer Holmberg; sipcore@ietf.org > *Subject:* Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Hi Mary, > > I do not understand what you mean with multi stage. All the tagging > can be prepared at the time that the translation is done and added at > the time that 4244 suggests the H-I to be added. If the current text > suggests otherwise, then we might need to fix that. > > BR, > /Hans Erik van Elburg > > > On Fri, Jun 12, 2009 at 4:11 PM, Mary Barnes > wrote: > > Hi Hans, > > A couple comments below [MB]. > > Mary. > > ------------------------------------------------------------------------ > *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com > ] > *Sent:* Friday, June 12, 2009 3:38 AM > > *To:* Barnes, Mary (RICH2:AR00) > *Cc:* Christer Holmberg; sipcore@ietf.org > *Subject:* Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Hi Mary, > > Sure when we agree on the way forward we have to resolve all these > detailed procedures and conform to the 4244 language etc. But we > already agreed to integrate it into 4424bis at the moment that > there is agreement about the solution. > > Regarding the two tag approach that is open for discussion, i > think it is more clean and in general pays off to separate > concepts that are independent from each other. For example a > hi-entry may be routed and not be an AOR, whereas it may also be > routed and also an AOR. The decisions to be taken for additions of > these tags are independent, so there is also no need to intertwine > procedural text for them. (It is also more clear for implementors.) > [MB] This is where my major confusion is in that you say the tags > are independent, BUT where in the normative RFC 3261 processing > does this occur? I'm confused because the logic in section 16.5 > isn't "multi-stage" (for lack of a better term), the incoming > request URI is evaluated and then the new target list is > constructed The tagging in 4244 is based on the mechanism by > which a new target is determined . The previous hi-entry (that in > the incoming request) is tagged at the point the request is being > forwarded. I do agree that in the internal processing that > information needs to exist so that the tagging at the point of > forwarding the request is appropriate. [/MB] > > > > BR, > /Hans Erik van Elburg > > On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes > > wrote: > > Christer, > > I reviewed the updated target-uri draft and have a few > comments - well I > reviewed the diff since there isn't a summary of changes in the > document: > > 1) I had a lot of difficulty picking out the normative > processing for > History-Info in this document. Can you summarize the differences? > > 2) The reason I'm concerned about understanding how this fits > with the > current normative processing is because I'm not seeing > precisely when > these tags are added as the terminology is different than that > used in > RFC 4244 - i.e., are these two terms equivalent: > RFC 4244: > "... hi-entry received in the request being forwarded." > > target-uri: > "...hi-entry recording the incoming request URI." > > There is no reference in terms of current History-Info > processing as to > when in the request processing these tags are added. > > 3) In particular, I'm having difficulty with this text in > section 6: > "When a home proxy receives a request for a user or resource for > which > is abstract location function returns registered contacts or > configured URIs, the proxy adds two History-Info header > field values. > The first is the incoming request URI. Since the Request-URI > identifies a user or resource for which it has a registration or > configuration, the Request-URI is an AOR and thus an address > for the > user. The proxy adds a History-Info header field parameter, > "aor", > which indicates this. Next, the proxy inserts the contact > URI which > will be contained in the outgoing Request-URI." > Currently, in RFC 4244, the proxy only adds that additional > (first) > hi-entry IF there wasn't one in the incoming request, since > the UAC can > initially add one when it builds the request. So, this is > inconsistent > with current RFC 4244. And, I think you need to define "home" > proxy - > that's not an RFC 3261 term - there is the concept of a "home" > domain. > > 4) There is a bug in the Syntax (section 9) - the Index is not > optional > (that is an error we have fixed in the 4244bis). > > 5) I'm really confused about this two-stage tagging - how does > that > happen in the context of the determination of Request Targets > in section > 16.5 of RFC3261? Wouldn't the decisions as to the addition of > the two > different tags occur at the same time and thus what is the > advantage of > the defining the two tags - i.e., why not one tag for each > combination? > Also, are you proposing that the addition of the tags be > mandatory - > there is no normative language in the target-uri document, so it's > impossible to tell. And, if you are proposing they be > mandatory, your > ABNF syntax needs to reflect that, thus defining a single > parameter with > multiple values would be necessary (which is the approach in > 4244bis). > > > 6) What is the difference (or is there a difference?) between the > functionality associated with the tags in 4244bis and the tags > defined > in this document in terms of types of retargets that are being > tagged? > I think this is the crux of what we need to agree - i.e., why > aren't the > 4244bis tags sufficient? If there is no logical difference > and it's > just the words used to define the tags, then we're very close to > agreement. > > Regards, > Mary. > > > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com > ] > Sent: Thursday, June 11, 2009 3:32 PM > To: Christer Holmberg; Barnes, Mary (RICH2:AR00); > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > Here is the link to the latest version of the target-uri draft: > > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00. > txt > > > -----Original Message----- > From: Christer Holmberg > Sent: Thursday, June 11, 2009 11:31 PM > To: 'Mary Barnes'; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > Hi, > > I think it is important to mention that there are still different > approaches regarding the target uri delivery, and that there > is another > approach described in the latest version of the target-uri > delivery > draft (I am not sure it appears in the archieves, though, for some > reason). Both approaches are based on History-Info, though. > > We haven't yet been able to agree on an approach, so we > thought the best > is to bring it to the list in order for other people to get > involved. > > Regards, > > Christer > > > > -----Original Message----- > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org > ] On > Behalf Of Mary Barnes > Sent: Thursday, June 11, 2009 9:05 PM > To: sipcore@ietf.org > Subject: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Hi folks, > > We have made a few changes to this document which was > submitted last > week just to tie up some loose ends and inconsistencies, some > of which > Shida identified when he reviewed the -00 version. > > The following summarizes the high level changes in the > sipcore-rfc4244bis from the sip-rfc4244bis that we discussed > in San > Francisco: > 1) Renamed the "retarget" parameter to "target" and defined > explicit > tags to reflect the various mechanisms by which a Request is > retargeted. > All entries are now tagged. > 2) Updated redirect server processing as the redirect server must > capture the "target" parameter since it is the entity that > knows the > specific mechanism by which the new target has been determined. > 3) Changed the privacy such that rather than removing entries > based on > the various values of the privacy header, the entries are > recommended to > be anonymized. > 4) Updated security section > 5) Updated examples to reflect the new parameter, use loose > routing and > fix errors/nits. > 6) Editorial changes to remove redundant text and the > convuluted text > around optionality in the non-normative sections, which is now > discussed > appropriately in the context of the histinfo option tag. > > The detailed changes between the versions are summarized in the > document. > > If you're wanting to look at a diff, I would recommend you > diff against > RFC 4244 rather than the earlier 4244bis documents. > > We'd really appreciate feedback on this approach to precisely > tagging > all the entries. We believe it is comprehensive and should > suffice for > all the use cases identified in the target-uri document, as > well as any > others that might arise. > > Thanks, > Mary and Francois. > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org > ] On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, June 11, 2009 12:45 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : An Extension to the Session Initiation > Protocol (SIP) for Request History Information > Author(s) : M. Barnes, F. Audet > Filename : draft-barnes-sipcore-rfc4244bis-01.txt > Pages : 42 > Date : 2009-06-11 > > This document defines a standard mechanism for capturing the > history > information associated with a Session Initiation Protocol > (SIP) request. > This capability enables many enhanced services by providing the > information as to how and why a call arrives at a specific > application > or user. This document defines a new optional SIP header, > History-Info, > for capturing the history information in requests. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01.t > xt > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > From mary.barnes@nortel.com Fri Jun 12 13:30:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2BD43A68A2 for ; Fri, 12 Jun 2009 13:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1jePHnHAmCw for ; Fri, 12 Jun 2009 13:30:50 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 7C48E3A6884 for ; Fri, 12 Jun 2009 13:30:50 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5CKTX118066; Fri, 12 Jun 2009 20:29:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 15:33:08 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E7D8536@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A32B08C.4010308@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: Acnrln1D0/s3ReYfQxWfAFVNh3ufsQAAoPJg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120138y540f7c2bja62adcf942cba3a0@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E787F80@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120824s24f0ddfyb9dc6d6c38651d75@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D809A@zrc2hxm0.corp.nortel.com> <4A32B08C.4010308@gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 20:30:52 -0000 Hi Hans,=20 Just a few comments below [MB]. =20 Thanks, Mary. -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Friday, June 12, 2009 2:46 PM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi Mary, > So, it's just not clear at all to me how you coordinate the addition of the two tags. Perhaps, it's just how that section is written, > but again, this is my point that it's really difficult to understand your solution proposal when it is not described in the context of > the current normative RFC 4244 functionality.=20 The text can definitely be improved, but still the criteria for adding the tags are independent. I will try draft a chapter as it would look like in 4424. [MB] Yes, it would help to understand this in the context of 16.5 where you are determining the targets for the request as I can't quite see how the determination of the tags are independent. And, I say determination because as is, you don't add the tag until you are forwarding the request per section 16.6. The exception is the case of a 3xx and the redirect server has added the tag - at least per the 4244bis specification of redirect server and 3xx handling, which is actually something else missing in target-uri as this does introduce a somewhat special case now that we are adding this level of granularity in terms of the mechanism by which the target(s) are determined. [/MB] > This solution also does not seem to give clear delineation between registered contacts versus configured URIs. I had understood > that to be important for some services. In particular, how will this solution support being able to identify aliases? Regarding the alias concept, I have no problems in adding that. But it is currently not in scope of the target-uri work, if people agree then we can add that requirement. We could reuse the definition that is contained in the 4424bis draft as I think that is a good definition. [MB] I'm puzzled as aliases are identified as a service to be supported by target-uri in section 4.1. That's the exact use case that the "reg-uri-alias" tag in 4244bis will support. [/MB] But what is the essential difference between bindings that came about due to registration and those that are configured? (To me this has nothing todo with aliases, in fact I think it is not a meaningful difference how the binding was made.) But if you have a requirement for that, you should maybe explain it. [MB] I'm not sure we're using the term configured in the same context here as I think you are really talking about the entries that are tagged as "mapped" in 4244bis. The alias concept actually uses both registration and configuration - that's why it's really a separate mechanism by which targets are determined. This is clearly defined in 4244bis in the description of the "reg-uri-alias" tag. [/MB] /Hans Erik Mary Barnes wrote: > Hi Hans, > =20 > My confusion comes from the 3rd paragraph in section 6 (the same one=20 > that confuses in terms of the unconditional addition of two=20 > hi-entries), specifically this text: > " When a home proxy receives a request for a user or resource for which > is abstract location function returns registered contacts or > configured URIs, the proxy adds two History-Info header field values. > The first is the incoming request URI. Since the Request-URI > identifies a user or resource for which it has a registration or > configuration, the Request-URI is an AOR and thus an address for the > user. The proxy adds a History-Info header field parameter, "aor", > which indicates this. Next, the proxy inserts the contact URI which > will be contained in the outgoing Request-URI." > =20 > (Note: this also confuses me because it is combining determining=20 > request targets with the forwarding) > =20 > But, then later in that section, there's the following text (7th > paragraph): > "When a proxy receives a request for a user or resource for which it > is responsible, then when a request URI rewrite occurs that is a > routing translation, then add a History-Info header field parameter > "routed" to the hi-entry recording the incoming request URI. > Otherwise when a request URI rewrite occurs that is a mapping > translation, then add a History-Info header field parameter "mapped" > to the hi-entry recording the incoming request URI. " > =20 > So, it's just not clear at all to me how you coordinate the addition=20 > of the two tags. Perhaps, it's just how that section is written, but=20 > again, this is my point that it's really difficult to understand your=20 > solution proposal when it is not described in the context of the=20 > current normative RFC 4244 functionality. > =20 > This solution also does not seem to give clear delineation between=20 > registered contacts versus configured URIs. I had understood that to=20 > be important for some services. In particular, how will this solution=20 > support being able to identify aliases? > =20 > Thanks, > Mary. > =20 > ---------------------------------------------------------------------- > -- > *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > *Sent:* Friday, June 12, 2009 10:24 AM > *To:* Barnes, Mary (RICH2:AR00) > *Cc:* Christer Holmberg; sipcore@ietf.org > *Subject:* Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Hi Mary, > > I do not understand what you mean with multi stage. All the tagging=20 > can be prepared at the time that the translation is done and added at=20 > the time that 4244 suggests the H-I to be added. If the current text=20 > suggests otherwise, then we might need to fix that. > > BR, > /Hans Erik van Elburg > > > On Fri, Jun 12, 2009 at 4:11 PM, Mary Barnes > wrote: > > Hi Hans, > =20 > A couple comments below [MB]. > =20 > Mary. > > ------------------------------------------------------------------------ > *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com > ] > *Sent:* Friday, June 12, 2009 3:38 AM > > *To:* Barnes, Mary (RICH2:AR00) > *Cc:* Christer Holmberg; sipcore@ietf.org > *Subject:* Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Hi Mary, > > Sure when we agree on the way forward we have to resolve all these > detailed procedures and conform to the 4244 language etc. But we > already agreed to integrate it into 4424bis at the moment that > there is agreement about the solution. > > Regarding the two tag approach that is open for discussion, i > think it is more clean and in general pays off to separate > concepts that are independent from each other. For example a > hi-entry may be routed and not be an AOR, whereas it may also be > routed and also an AOR. The decisions to be taken for additions of > these tags are independent, so there is also no need to intertwine > procedural text for them. (It is also more clear for implementors.)=20 > [MB] This is where my major confusion is in that you say the tags > are independent, BUT where in the normative RFC 3261 processing > does this occur? I'm confused because the logic in section 16.5 > isn't "multi-stage" (for lack of a better term), the incoming > request URI is evaluated and then the new target list is > constructed The tagging in 4244 is based on the mechanism by > which a new target is determined . The previous hi-entry (that in > the incoming request) is tagged at the point the request is being > forwarded. I do agree that in the internal processing that > information needs to exist so that the tagging at the point of > forwarding the request is appropriate. [/MB] > =20 > > > BR, > /Hans Erik van Elburg > > On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes > > wrote: > > Christer, > > I reviewed the updated target-uri draft and have a few > comments - well I > reviewed the diff since there isn't a summary of changes in the > document: > > 1) I had a lot of difficulty picking out the normative > processing for > History-Info in this document. Can you summarize the differences? > > 2) The reason I'm concerned about understanding how this fits > with the > current normative processing is because I'm not seeing > precisely when > these tags are added as the terminology is different than that > used in > RFC 4244 - i.e., are these two terms equivalent: > RFC 4244: > "... hi-entry received in the request being forwarded." > > target-uri: > "...hi-entry recording the incoming request URI." > > There is no reference in terms of current History-Info > processing as to > when in the request processing these tags are added. > > 3) In particular, I'm having difficulty with this text in > section 6: > "When a home proxy receives a request for a user or resource for > which > is abstract location function returns registered contacts or > configured URIs, the proxy adds two History-Info header > field values. > The first is the incoming request URI. Since the Request-URI > identifies a user or resource for which it has a registration or > configuration, the Request-URI is an AOR and thus an address > for the > user. The proxy adds a History-Info header field parameter, > "aor", > which indicates this. Next, the proxy inserts the contact > URI which > will be contained in the outgoing Request-URI." > Currently, in RFC 4244, the proxy only adds that additional > (first) > hi-entry IF there wasn't one in the incoming request, since > the UAC can > initially add one when it builds the request. So, this is > inconsistent > with current RFC 4244. And, I think you need to define "home" > proxy - > that's not an RFC 3261 term - there is the concept of a "home" > domain. > > 4) There is a bug in the Syntax (section 9) - the Index is not > optional > (that is an error we have fixed in the 4244bis). > > 5) I'm really confused about this two-stage tagging - how does > that > happen in the context of the determination of Request Targets > in section > 16.5 of RFC3261? Wouldn't the decisions as to the addition of > the two > different tags occur at the same time and thus what is the > advantage of > the defining the two tags - i.e., why not one tag for each > combination? > Also, are you proposing that the addition of the tags be > mandatory - > there is no normative language in the target-uri document, so it's > impossible to tell. And, if you are proposing they be > mandatory, your > ABNF syntax needs to reflect that, thus defining a single > parameter with > multiple values would be necessary (which is the approach in > 4244bis). > > > 6) What is the difference (or is there a difference?) between the > functionality associated with the tags in 4244bis and the tags > defined > in this document in terms of types of retargets that are being > tagged? > I think this is the crux of what we need to agree - i.e., why > aren't the > 4244bis tags sufficient? If there is no logical difference > and it's > just the words used to define the tags, then we're very close to > agreement. > > Regards, > Mary. > > > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com > ] > Sent: Thursday, June 11, 2009 3:32 PM > To: Christer Holmberg; Barnes, Mary (RICH2:AR00); > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > Here is the link to the latest version of the target-uri draft: > > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00. > txt > =20 > 00.%0Atxt> > > -----Original Message----- > From: Christer Holmberg > Sent: Thursday, June 11, 2009 11:31 PM > To: 'Mary Barnes'; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > Hi, > > I think it is important to mention that there are still different > approaches regarding the target uri delivery, and that there > is another > approach described in the latest version of the target-uri > delivery > draft (I am not sure it appears in the archieves, though, for some > reason). Both approaches are based on History-Info, though. > > We haven't yet been able to agree on an approach, so we > thought the best > is to bring it to the list in order for other people to get > involved. > > Regards, > > Christer > > > > -----Original Message----- > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org > ] On > Behalf Of Mary Barnes > Sent: Thursday, June 11, 2009 9:05 PM > To: sipcore@ietf.org > Subject: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Hi folks, > > We have made a few changes to this document which was > submitted last > week just to tie up some loose ends and inconsistencies, some > of which > Shida identified when he reviewed the -00 version. > > The following summarizes the high level changes in the > sipcore-rfc4244bis from the sip-rfc4244bis that we discussed > in San > Francisco: > 1) Renamed the "retarget" parameter to "target" and defined > explicit > tags to reflect the various mechanisms by which a Request is > retargeted. > All entries are now tagged. > 2) Updated redirect server processing as the redirect server must > capture the "target" parameter since it is the entity that > knows the > specific mechanism by which the new target has been determined. > 3) Changed the privacy such that rather than removing entries > based on > the various values of the privacy header, the entries are > recommended to > be anonymized. > 4) Updated security section > 5) Updated examples to reflect the new parameter, use loose > routing and > fix errors/nits. > 6) Editorial changes to remove redundant text and the > convuluted text > around optionality in the non-normative sections, which is now > discussed > appropriately in the context of the histinfo option tag. > > The detailed changes between the versions are summarized in the > document. > > If you're wanting to look at a diff, I would recommend you > diff against > RFC 4244 rather than the earlier 4244bis documents. > > We'd really appreciate feedback on this approach to precisely > tagging > all the entries. We believe it is comprehensive and should > suffice for > all the use cases identified in the target-uri document, as > well as any > others that might arise. > > Thanks, > Mary and Francois. > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org > ] On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, June 11, 2009 12:45 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : An Extension to the Session Initiation > Protocol (SIP) for Request History Information > Author(s) : M. Barnes, F. Audet > Filename : draft-barnes-sipcore-rfc4244bis-01.txt > Pages : 42 > Date : 2009-06-11 > > This document defines a standard mechanism for capturing the > history > information associated with a Session Initiation Protocol > (SIP) request. > This capability enables many enhanced services by providing the > information as to how and why a call arrives at a specific > application > or user. This document defines a new optional SIP header, > History-Info, > for capturing the history information in requests. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01.t > xt > =20 > 1.t%0Axt> > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > From ietf.hanserik@gmail.com Fri Jun 12 13:39:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC7403A68EB for ; Fri, 12 Jun 2009 13:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NJb991F5vLl for ; Fri, 12 Jun 2009 13:39:54 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 2DA243A68BC for ; Fri, 12 Jun 2009 13:39:53 -0700 (PDT) Received: by ewy6 with SMTP id 6so3318834ewy.37 for ; Fri, 12 Jun 2009 13:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=mF9OtaadxHONLKbWbIGEzoT8gCZ7siLLVesExPr+4Rw=; b=UNoGHl9GOLbZTop0Uq8LnzmwNNAGtYfU2YZ2jpjglmfCP7+M1SoKrFgr+U/Z+GDbow drYVZIMNbSec6pVBQ6JDBAS9HIVm6A49cjON3rUKztL7opbsIbpc02Kksf1RGv/paJ+p Vdmc+c+TdH0N/GKJF0k6QcSLpNtRJt59icgy4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Yh/ToFkjAhsTv4J/9KMHc0QV3FBVXz5oZNkzPUOrgASSEGlOdjPerS1CoTy3ZdBqrl Wq1/YK2zsIkuSylTs4pXlOTKda66xmPHvI64IIeqh4Th5hlYpc7PdpvBWL4RoX3Ne74C 1pkEsn5+7C/wUIjQheMGHdOdhiAt3PUsoDPwQ= Received: by 10.210.130.14 with SMTP id c14mr3633586ebd.55.1244839199403; Fri, 12 Jun 2009 13:39:59 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 23sm376056eya.49.2009.06.12.13.39.58 (version=SSLv3 cipher=RC4-MD5); Fri, 12 Jun 2009 13:39:59 -0700 (PDT) Message-ID: <4A32BD1E.6080206@gmail.com> Date: Fri, 12 Jun 2009 22:39:58 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Mary Barnes References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120138y540f7c2bja62adcf942cba3a0@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E787F80@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120824s24f0ddfyb9dc6d6c38651d75@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D809A@zrc2hxm0.corp.nortel.com> <4A32B08C.4010308@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D8536@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E7D8536@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 20:39:56 -0000 [MB] I'm puzzled as aliases are identified as a service to be supported by target-uri in section 4.1. That's the exact use case that the "reg-uri-alias" tag in 4244bis will support. [/MB] The delivery of the addressed target to the UAS is what we are trying to solve, the alias use case is just showing a case where this information is usefull for the UAS, but destroyed by Request-URI overwriting. Best Regards, /Hans Erik Mary Barnes wrote: > Hi Hans, > > Just a few comments below [MB]. > > Thanks, > Mary. > > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Friday, June 12, 2009 2:46 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Hi Mary, > > >> So, it's just not clear at all to me how you coordinate the addition >> > of the two tags. Perhaps, it's just how that section is written, > >> but again, this is my point that it's really difficult to understand >> > your solution proposal when it is not described in the context of > >> the current normative RFC 4244 functionality. >> > > The text can definitely be improved, but still the criteria for adding > the tags are independent. > > I will try draft a chapter as it would look like in 4424. > [MB] Yes, it would help to understand this in the context of 16.5 where > you are determining the targets for the request as I can't quite see how > the determination of the tags are independent. And, I say determination > because as is, you don't add the tag until you are forwarding the > request per section 16.6. The exception is the case of a 3xx and the > redirect server has added the tag - at least per the 4244bis > specification of redirect server and 3xx handling, which is actually > something else missing in target-uri as this does introduce a somewhat > special case now that we are adding this level of granularity in terms > of the mechanism by which the target(s) are determined. [/MB] > > > >> This solution also does not seem to give clear delineation between >> > registered contacts versus configured URIs. I had understood > that to > be important for some services. In particular, how will this solution > support being able to identify aliases? > > Regarding the alias concept, I have no problems in adding that. But it > is currently not in scope of the target-uri work, if people agree then > we can add that requirement. We could reuse the definition that is > contained in the 4424bis draft as I think that is a good definition. > [MB] I'm puzzled as aliases are identified as a service to be supported > by target-uri in section 4.1. That's the exact use case that the > "reg-uri-alias" tag in 4244bis will support. [/MB] > > But what is the essential difference between bindings that came about > due to registration and those that are configured? (To me this has > nothing todo with aliases, in fact I think it is not a meaningful > difference how the binding was made.) But if you have a requirement for > that, you should maybe explain it. > [MB] I'm not sure we're using the term configured in the same context > here as I think you are really talking about the entries that are tagged > as "mapped" in 4244bis. The alias concept actually uses both > registration and configuration - that's why it's really a separate > mechanism by which targets are determined. This is clearly defined in > 4244bis in the description of the "reg-uri-alias" tag. [/MB] > > > /Hans Erik > > Mary Barnes wrote: > >> Hi Hans, >> >> My confusion comes from the 3rd paragraph in section 6 (the same one >> that confuses in terms of the unconditional addition of two >> hi-entries), specifically this text: >> " When a home proxy receives a request for a user or resource for >> > which > >> is abstract location function returns registered contacts or >> configured URIs, the proxy adds two History-Info header field >> > values. > >> The first is the incoming request URI. Since the Request-URI >> identifies a user or resource for which it has a registration or >> configuration, the Request-URI is an AOR and thus an address for >> > the > >> user. The proxy adds a History-Info header field parameter, "aor", >> which indicates this. Next, the proxy inserts the contact URI >> > which > >> will be contained in the outgoing Request-URI." >> >> (Note: this also confuses me because it is combining determining >> request targets with the forwarding) >> >> But, then later in that section, there's the following text (7th >> paragraph): >> "When a proxy receives a request for a user or resource for which it >> is responsible, then when a request URI rewrite occurs that is a >> routing translation, then add a History-Info header field parameter >> "routed" to the hi-entry recording the incoming request URI. >> Otherwise when a request URI rewrite occurs that is a mapping >> translation, then add a History-Info header field parameter >> > "mapped" > >> to the hi-entry recording the incoming request URI. " >> >> So, it's just not clear at all to me how you coordinate the addition >> of the two tags. Perhaps, it's just how that section is written, but >> again, this is my point that it's really difficult to understand your >> solution proposal when it is not described in the context of the >> current normative RFC 4244 functionality. >> >> This solution also does not seem to give clear delineation between >> registered contacts versus configured URIs. I had understood that to >> be important for some services. In particular, how will this solution >> support being able to identify aliases? >> >> Thanks, >> Mary. >> >> ---------------------------------------------------------------------- >> -- >> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> *Sent:* Friday, June 12, 2009 10:24 AM >> *To:* Barnes, Mary (RICH2:AR00) >> *Cc:* Christer Holmberg; sipcore@ietf.org >> *Subject:* Re: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Hi Mary, >> >> I do not understand what you mean with multi stage. All the tagging >> can be prepared at the time that the translation is done and added at >> the time that 4244 suggests the H-I to be added. If the current text >> suggests otherwise, then we might need to fix that. >> >> BR, >> /Hans Erik van Elburg >> >> >> On Fri, Jun 12, 2009 at 4:11 PM, Mary Barnes > > wrote: >> >> Hi Hans, >> >> A couple comments below [MB]. >> >> Mary. >> >> >> > ------------------------------------------------------------------------ > >> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com >> ] >> *Sent:* Friday, June 12, 2009 3:38 AM >> >> *To:* Barnes, Mary (RICH2:AR00) >> *Cc:* Christer Holmberg; sipcore@ietf.org >> > > >> *Subject:* Re: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Hi Mary, >> >> Sure when we agree on the way forward we have to resolve all these >> detailed procedures and conform to the 4244 language etc. But we >> already agreed to integrate it into 4424bis at the moment that >> there is agreement about the solution. >> >> Regarding the two tag approach that is open for discussion, i >> think it is more clean and in general pays off to separate >> concepts that are independent from each other. For example a >> hi-entry may be routed and not be an AOR, whereas it may also be >> routed and also an AOR. The decisions to be taken for additions of >> these tags are independent, so there is also no need to intertwine >> procedural text for them. (It is also more clear for >> > implementors.) > >> [MB] This is where my major confusion is in that you say the tags >> are independent, BUT where in the normative RFC 3261 processing >> does this occur? I'm confused because the logic in section 16.5 >> isn't "multi-stage" (for lack of a better term), the incoming >> request URI is evaluated and then the new target list is >> constructed The tagging in 4244 is based on the mechanism by >> which a new target is determined . The previous hi-entry (that in >> the incoming request) is tagged at the point the request is being >> forwarded. I do agree that in the internal processing that >> information needs to exist so that the tagging at the point of >> forwarding the request is appropriate. [/MB] >> >> >> >> BR, >> /Hans Erik van Elburg >> >> On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes >> > wrote: >> >> Christer, >> >> I reviewed the updated target-uri draft and have a few >> comments - well I >> reviewed the diff since there isn't a summary of changes in >> > the > >> document: >> >> 1) I had a lot of difficulty picking out the normative >> processing for >> History-Info in this document. Can you summarize the >> > differences? > >> 2) The reason I'm concerned about understanding how this fits >> with the >> current normative processing is because I'm not seeing >> precisely when >> these tags are added as the terminology is different than that >> used in >> RFC 4244 - i.e., are these two terms equivalent: >> RFC 4244: >> "... hi-entry received in the request being forwarded." >> >> target-uri: >> "...hi-entry recording the incoming request URI." >> >> There is no reference in terms of current History-Info >> processing as to >> when in the request processing these tags are added. >> >> 3) In particular, I'm having difficulty with this text in >> section 6: >> "When a home proxy receives a request for a user or resource >> > for > >> which >> is abstract location function returns registered contacts or >> configured URIs, the proxy adds two History-Info header >> field values. >> The first is the incoming request URI. Since the >> > Request-URI > >> identifies a user or resource for which it has a >> > registration or > >> configuration, the Request-URI is an AOR and thus an address >> for the >> user. The proxy adds a History-Info header field parameter, >> "aor", >> which indicates this. Next, the proxy inserts the contact >> URI which >> will be contained in the outgoing Request-URI." >> Currently, in RFC 4244, the proxy only adds that additional >> (first) >> hi-entry IF there wasn't one in the incoming request, since >> the UAC can >> initially add one when it builds the request. So, this is >> inconsistent >> with current RFC 4244. And, I think you need to define "home" >> proxy - >> that's not an RFC 3261 term - there is the concept of a "home" >> domain. >> >> 4) There is a bug in the Syntax (section 9) - the Index is not >> optional >> (that is an error we have fixed in the 4244bis). >> >> 5) I'm really confused about this two-stage tagging - how does >> that >> happen in the context of the determination of Request Targets >> in section >> 16.5 of RFC3261? Wouldn't the decisions as to the addition of >> the two >> different tags occur at the same time and thus what is the >> advantage of >> the defining the two tags - i.e., why not one tag for each >> combination? >> Also, are you proposing that the addition of the tags be >> mandatory - >> there is no normative language in the target-uri document, so >> > it's > >> impossible to tell. And, if you are proposing they be >> mandatory, your >> ABNF syntax needs to reflect that, thus defining a single >> parameter with >> multiple values would be necessary (which is the approach in >> 4244bis). >> >> >> 6) What is the difference (or is there a difference?) between >> > the > >> functionality associated with the tags in 4244bis and the tags >> defined >> in this document in terms of types of retargets that are being >> tagged? >> I think this is the crux of what we need to agree - i.e., why >> aren't the >> 4244bis tags sufficient? If there is no logical difference >> and it's >> just the words used to define the tags, then we're very close >> > to > >> agreement. >> >> Regards, >> Mary. >> >> >> >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com >> ] >> Sent: Thursday, June 11, 2009 3:32 PM >> To: Christer Holmberg; Barnes, Mary (RICH2:AR00); >> sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> Here is the link to the latest version of the target-uri >> > draft: > >> > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00. > >> txt >> >> > 00.%0Atxt> >> >> -----Original Message----- >> From: Christer Holmberg >> Sent: Thursday, June 11, 2009 11:31 PM >> To: 'Mary Barnes'; sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> Hi, >> >> I think it is important to mention that there are still >> > different > >> approaches regarding the target uri delivery, and that there >> is another >> approach described in the latest version of the target-uri >> delivery >> draft (I am not sure it appears in the archieves, though, for >> > some > >> reason). Both approaches are based on History-Info, though. >> >> We haven't yet been able to agree on an approach, so we >> thought the best >> is to bring it to the list in order for other people to get >> involved. >> >> Regards, >> >> Christer >> >> >> >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> >> [mailto:sipcore-bounces@ietf.org >> ] On >> Behalf Of Mary Barnes >> Sent: Thursday, June 11, 2009 9:05 PM >> To: sipcore@ietf.org >> Subject: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Hi folks, >> >> We have made a few changes to this document which was >> submitted last >> week just to tie up some loose ends and inconsistencies, some >> of which >> Shida identified when he reviewed the -00 version. >> >> The following summarizes the high level changes in the >> sipcore-rfc4244bis from the sip-rfc4244bis that we discussed >> in San >> Francisco: >> 1) Renamed the "retarget" parameter to "target" and defined >> explicit >> tags to reflect the various mechanisms by which a Request is >> retargeted. >> All entries are now tagged. >> 2) Updated redirect server processing as the redirect server >> > must > >> capture the "target" parameter since it is the entity that >> knows the >> specific mechanism by which the new target has been >> > determined. > >> 3) Changed the privacy such that rather than removing entries >> based on >> the various values of the privacy header, the entries are >> recommended to >> be anonymized. >> 4) Updated security section >> 5) Updated examples to reflect the new parameter, use loose >> routing and >> fix errors/nits. >> 6) Editorial changes to remove redundant text and the >> convuluted text >> around optionality in the non-normative sections, which is now >> discussed >> appropriately in the context of the histinfo option tag. >> >> The detailed changes between the versions are summarized in >> > the > >> document. >> >> If you're wanting to look at a diff, I would recommend you >> diff against >> RFC 4244 rather than the earlier 4244bis documents. >> >> We'd really appreciate feedback on this approach to precisely >> tagging >> all the entries. We believe it is comprehensive and should >> suffice for >> all the use cases identified in the target-uri document, as >> well as any >> others that might arise. >> >> Thanks, >> Mary and Francois. >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> >> [mailto:i-d-announce-bounces@ietf.org >> ] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: Thursday, June 11, 2009 12:45 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> A New Internet-Draft is available from the on-line >> > Internet-Drafts > >> directories. >> >> Title : An Extension to the Session >> > Initiation > >> Protocol (SIP) for Request History Information >> Author(s) : M. Barnes, F. Audet >> Filename : >> > draft-barnes-sipcore-rfc4244bis-01.txt > >> Pages : 42 >> Date : 2009-06-11 >> >> This document defines a standard mechanism for capturing the >> history >> information associated with a Session Initiation Protocol >> (SIP) request. >> This capability enables many enhanced services by providing >> > the > >> information as to how and why a call arrives at a specific >> application >> or user. This document defines a new optional SIP header, >> History-Info, >> for capturing the history information in requests. >> >> A URL for this Internet-Draft is: >> >> > http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01.t > >> xt >> >> > 1.t%0Axt> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail >> > reader > >> implementation to automatically retrieve the ASCII version of >> > the > >> Internet-Draft. >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> >> From mary.barnes@nortel.com Fri Jun 12 14:04:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 202643A6897 for ; Fri, 12 Jun 2009 14:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0IXv-GCljXp for ; Fri, 12 Jun 2009 14:04:00 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C49153A6884 for ; Fri, 12 Jun 2009 14:03:58 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5CL3qE18642; Fri, 12 Jun 2009 21:03:52 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 16:05:43 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E7D85D4@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A32BD1E.6080206@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: Acnrnfjc0H+z17diRrqLfFuw8B1FnAAAmYHw References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120138y540f7c2bja62adcf942cba3a0@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E787F80@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120824s24f0ddfyb9dc6d6c38651d75@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D809A@zrc2hxm0.corp.nortel.com> <4A32B08C.4010308@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D8536@zrc2hxm0.corp.nortel.com> <4A32BD1E.6080206@gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 21:04:02 -0000 I'm even further puzzled then. The abstract of target-uri states: "This document describes these use cases and defines an extension to the History- Info header field which allows it to be used to support those cases." With the following listed in the TOC:=20 4.1. Unknown Aliases . . . . . . . . . . . . . . . . . . . . . 5 4.2. Unknown GRUU . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Limited Use Addresses . . . . . . . . . . . . . . . . . . 6 4.4. Sub-Addressing . . . . . . . . . . . . . . . . . . . . . . 6 4.5. Service Invocation . . . . . . . . . . . . . . . . . . . . 7 4.6. Toll Free Numbers . . I thought the whole point was to handle ANY of the use cases "where this information is usefull for the UAS, but destroyed by Request-URI overwriting" - i.e, that's the general problem being solved and the solution provided by History-Info is agnostic as to how an application might use that information.=20 I think what we may be butting heads on isn't the History-Info aspects of supporting those services, but rather that the information that some of those services depend on isn't amenable to clear identification in terms of how SIP determines request targets. This is where I was going with my initial suggestion that you may need to add some more service specific looking tags to the request URIs.=20 Mary.=20 -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Friday, June 12, 2009 3:40 PM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt [MB] I'm puzzled as aliases are identified as a service to be supported by target-uri in section 4.1. That's the exact use case that the "reg-uri-alias" tag in 4244bis will support. [/MB] The delivery of the addressed target to the UAS is what we are trying to solve, the alias use case is just showing a case where this information is usefull for the UAS, but destroyed by Request-URI overwriting. Best Regards, /Hans Erik Mary Barnes wrote: > Hi Hans, > > Just a few comments below [MB]. =20 > > Thanks, > Mary. > > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Friday, June 12, 2009 2:46 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Hi Mary, > > =20 >> So, it's just not clear at all to me how you coordinate the addition >> =20 > of the two tags. Perhaps, it's just how that section is written, > =20 >> but again, this is my point that it's really difficult to understand >> =20 > your solution proposal when it is not described in the context of > =20 >> the current normative RFC 4244 functionality.=20 >> =20 > > The text can definitely be improved, but still the criteria for adding > the tags are independent. > > I will try draft a chapter as it would look like in 4424. > [MB] Yes, it would help to understand this in the context of 16.5=20 > where you are determining the targets for the request as I can't quite > see how the determination of the tags are independent. And, I say=20 > determination because as is, you don't add the tag until you are=20 > forwarding the request per section 16.6. The exception is the case of > a 3xx and the redirect server has added the tag - at least per the=20 > 4244bis specification of redirect server and 3xx handling, which is=20 > actually something else missing in target-uri as this does introduce a > somewhat special case now that we are adding this level of granularity > in terms of the mechanism by which the target(s) are determined. [/MB] > > > =20 >> This solution also does not seem to give clear delineation between >> =20 > registered contacts versus configured URIs. I had understood > that to > be important for some services. In particular, how will this solution=20 > support being able to identify aliases? > > Regarding the alias concept, I have no problems in adding that. But it > is currently not in scope of the target-uri work, if people agree then > we can add that requirement. We could reuse the definition that is=20 > contained in the 4424bis draft as I think that is a good definition. > [MB] I'm puzzled as aliases are identified as a service to be=20 > supported by target-uri in section 4.1. That's the exact use case that > the "reg-uri-alias" tag in 4244bis will support. [/MB] > > But what is the essential difference between bindings that came about=20 > due to registration and those that are configured? (To me this has=20 > nothing todo with aliases, in fact I think it is not a meaningful=20 > difference how the binding was made.) But if you have a requirement=20 > for that, you should maybe explain it. > [MB] I'm not sure we're using the term configured in the same context=20 > here as I think you are really talking about the entries that are=20 > tagged as "mapped" in 4244bis. The alias concept actually uses both=20 > registration and configuration - that's why it's really a separate=20 > mechanism by which targets are determined. This is clearly defined in=20 > 4244bis in the description of the "reg-uri-alias" tag. [/MB] > > > /Hans Erik > > Mary Barnes wrote: > =20 >> Hi Hans, >> =20 >> My confusion comes from the 3rd paragraph in section 6 (the same one=20 >> that confuses in terms of the unconditional addition of two=20 >> hi-entries), specifically this text: >> " When a home proxy receives a request for a user or resource for >> =20 > which > =20 >> is abstract location function returns registered contacts or >> configured URIs, the proxy adds two History-Info header field >> =20 > values. > =20 >> The first is the incoming request URI. Since the Request-URI >> identifies a user or resource for which it has a registration or >> configuration, the Request-URI is an AOR and thus an address for >> =20 > the > =20 >> user. The proxy adds a History-Info header field parameter, "aor", >> which indicates this. Next, the proxy inserts the contact URI >> =20 > which > =20 >> will be contained in the outgoing Request-URI." >> =20 >> (Note: this also confuses me because it is combining determining=20 >> request targets with the forwarding) >> =20 >> But, then later in that section, there's the following text (7th >> paragraph): >> "When a proxy receives a request for a user or resource for which it >> is responsible, then when a request URI rewrite occurs that is a >> routing translation, then add a History-Info header field parameter >> "routed" to the hi-entry recording the incoming request URI. >> Otherwise when a request URI rewrite occurs that is a mapping >> translation, then add a History-Info header field parameter >> =20 > "mapped" > =20 >> to the hi-entry recording the incoming request URI. " >> =20 >> So, it's just not clear at all to me how you coordinate the addition=20 >> of the two tags. Perhaps, it's just how that section is written, but >> again, this is my point that it's really difficult to understand your >> solution proposal when it is not described in the context of the=20 >> current normative RFC 4244 functionality. >> =20 >> This solution also does not seem to give clear delineation between=20 >> registered contacts versus configured URIs. I had understood that to=20 >> be important for some services. In particular, how will this solution >> support being able to identify aliases? >> =20 >> Thanks, >> Mary. >> =20 >> --------------------------------------------------------------------- >> - >> -- >> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> *Sent:* Friday, June 12, 2009 10:24 AM >> *To:* Barnes, Mary (RICH2:AR00) >> *Cc:* Christer Holmberg; sipcore@ietf.org >> *Subject:* Re: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Hi Mary, >> >> I do not understand what you mean with multi stage. All the tagging=20 >> can be prepared at the time that the translation is done and added at >> the time that 4244 suggests the H-I to be added. If the current text=20 >> suggests otherwise, then we might need to fix that. >> >> BR, >> /Hans Erik van Elburg >> >> >> On Fri, Jun 12, 2009 at 4:11 PM, Mary Barnes > > wrote: >> >> Hi Hans, >> =20 >> A couple comments below [MB]. >> =20 >> Mary. >> >> >> =20 > ---------------------------------------------------------------------- > -- > =20 >> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com >> ] >> *Sent:* Friday, June 12, 2009 3:38 AM >> >> *To:* Barnes, Mary (RICH2:AR00) >> *Cc:* Christer Holmberg; sipcore@ietf.org >> =20 > > =20 >> *Subject:* Re: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Hi Mary, >> >> Sure when we agree on the way forward we have to resolve all these >> detailed procedures and conform to the 4244 language etc. But we >> already agreed to integrate it into 4424bis at the moment that >> there is agreement about the solution. >> >> Regarding the two tag approach that is open for discussion, i >> think it is more clean and in general pays off to separate >> concepts that are independent from each other. For example a >> hi-entry may be routed and not be an AOR, whereas it may also be >> routed and also an AOR. The decisions to be taken for additions of >> these tags are independent, so there is also no need to intertwine >> procedural text for them. (It is also more clear for >> =20 > implementors.) > =20 >> [MB] This is where my major confusion is in that you say the tags >> are independent, BUT where in the normative RFC 3261 processing >> does this occur? I'm confused because the logic in section 16.5 >> isn't "multi-stage" (for lack of a better term), the incoming >> request URI is evaluated and then the new target list is >> constructed The tagging in 4244 is based on the mechanism by >> which a new target is determined . The previous hi-entry (that in >> the incoming request) is tagged at the point the request is being >> forwarded. I do agree that in the internal processing that >> information needs to exist so that the tagging at the point of >> forwarding the request is appropriate. [/MB] >> =20 >> >> >> BR, >> /Hans Erik van Elburg >> >> On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes >> > wrote: >> >> Christer, >> >> I reviewed the updated target-uri draft and have a few >> comments - well I >> reviewed the diff since there isn't a summary of changes in >> =20 > the > =20 >> document: >> >> 1) I had a lot of difficulty picking out the normative >> processing for >> History-Info in this document. Can you summarize the >> =20 > differences? > =20 >> 2) The reason I'm concerned about understanding how this fits >> with the >> current normative processing is because I'm not seeing >> precisely when >> these tags are added as the terminology is different than that >> used in >> RFC 4244 - i.e., are these two terms equivalent: >> RFC 4244: >> "... hi-entry received in the request being forwarded." >> >> target-uri: >> "...hi-entry recording the incoming request URI." >> >> There is no reference in terms of current History-Info >> processing as to >> when in the request processing these tags are added. >> >> 3) In particular, I'm having difficulty with this text in >> section 6: >> "When a home proxy receives a request for a user or=20 >> resource >> =20 > for > =20 >> which >> is abstract location function returns registered contacts or >> configured URIs, the proxy adds two History-Info header >> field values. >> The first is the incoming request URI. Since the >> =20 > Request-URI > =20 >> identifies a user or resource for which it has a >> =20 > registration or > =20 >> configuration, the Request-URI is an AOR and thus an address >> for the >> user. The proxy adds a History-Info header field parameter, >> "aor", >> which indicates this. Next, the proxy inserts the contact >> URI which >> will be contained in the outgoing Request-URI." >> Currently, in RFC 4244, the proxy only adds that additional >> (first) >> hi-entry IF there wasn't one in the incoming request, since >> the UAC can >> initially add one when it builds the request. So, this is >> inconsistent >> with current RFC 4244. And, I think you need to define "home" >> proxy - >> that's not an RFC 3261 term - there is the concept of a "home" >> domain. >> >> 4) There is a bug in the Syntax (section 9) - the Index is not >> optional >> (that is an error we have fixed in the 4244bis). >> >> 5) I'm really confused about this two-stage tagging - how does >> that >> happen in the context of the determination of Request Targets >> in section >> 16.5 of RFC3261? Wouldn't the decisions as to the addition of >> the two >> different tags occur at the same time and thus what is the >> advantage of >> the defining the two tags - i.e., why not one tag for each >> combination? >> Also, are you proposing that the addition of the tags be >> mandatory - >> there is no normative language in the target-uri document, so >> =20 > it's > =20 >> impossible to tell. And, if you are proposing they be >> mandatory, your >> ABNF syntax needs to reflect that, thus defining a single >> parameter with >> multiple values would be necessary (which is the approach in >> 4244bis). >> >> >> 6) What is the difference (or is there a difference?) between >> =20 > the > =20 >> functionality associated with the tags in 4244bis and the tags >> defined >> in this document in terms of types of retargets that are being >> tagged? >> I think this is the crux of what we need to agree - i.e., why >> aren't the >> 4244bis tags sufficient? If there is no logical difference >> and it's >> just the words used to define the tags, then we're very close >> =20 > to > =20 >> agreement. >> >> Regards, >> Mary. >> >> >> >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com >> ] >> Sent: Thursday, June 11, 2009 3:32 PM >> To: Christer Holmberg; Barnes, Mary (RICH2:AR00); >> sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> Here is the link to the latest version of the target-uri >> =20 > draft: > =20 >> =20 > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00. > =20 >> txt >> =20 >> > - >> 00.%0Atxt> >> >> -----Original Message----- >> From: Christer Holmberg >> Sent: Thursday, June 11, 2009 11:31 PM >> To: 'Mary Barnes'; sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> Hi, >> >> I think it is important to mention that there are still >> =20 > different > =20 >> approaches regarding the target uri delivery, and that there >> is another >> approach described in the latest version of the target-uri >> delivery >> draft (I am not sure it appears in the archieves, though, for >> =20 > some > =20 >> reason). Both approaches are based on History-Info, though. >> >> We haven't yet been able to agree on an approach, so we >> thought the best >> is to bring it to the list in order for other people to get >> involved. >> >> Regards, >> >> Christer >> >> >> >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> >> [mailto:sipcore-bounces@ietf.org >> ] On >> Behalf Of Mary Barnes >> Sent: Thursday, June 11, 2009 9:05 PM >> To: sipcore@ietf.org >> Subject: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Hi folks, >> >> We have made a few changes to this document which was >> submitted last >> week just to tie up some loose ends and inconsistencies, some >> of which >> Shida identified when he reviewed the -00 version. >> >> The following summarizes the high level changes in the >> sipcore-rfc4244bis from the sip-rfc4244bis that we discussed >> in San >> Francisco: >> 1) Renamed the "retarget" parameter to "target" and defined >> explicit >> tags to reflect the various mechanisms by which a Request is >> retargeted. >> All entries are now tagged. >> 2) Updated redirect server processing as the redirect server >> =20 > must > =20 >> capture the "target" parameter since it is the entity that >> knows the >> specific mechanism by which the new target has been >> =20 > determined. > =20 >> 3) Changed the privacy such that rather than removing entries >> based on >> the various values of the privacy header, the entries are >> recommended to >> be anonymized. >> 4) Updated security section >> 5) Updated examples to reflect the new parameter, use loose >> routing and >> fix errors/nits. >> 6) Editorial changes to remove redundant text and the >> convuluted text >> around optionality in the non-normative sections, which is now >> discussed >> appropriately in the context of the histinfo option tag. >> >> The detailed changes between the versions are summarized in >> =20 > the > =20 >> document. >> >> If you're wanting to look at a diff, I would recommend you >> diff against >> RFC 4244 rather than the earlier 4244bis documents. >> >> We'd really appreciate feedback on this approach to precisely >> tagging >> all the entries. We believe it is comprehensive and should >> suffice for >> all the use cases identified in the target-uri document, as >> well as any >> others that might arise. >> >> Thanks, >> Mary and Francois. >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> >> [mailto:i-d-announce-bounces@ietf.org >> ] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: Thursday, June 11, 2009 12:45 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> A New Internet-Draft is available from the on-line >> =20 > Internet-Drafts > =20 >> directories. >> >> Title : An Extension to the Session >> =20 > Initiation > =20 >> Protocol (SIP) for Request History Information >> Author(s) : M. Barnes, F. Audet >> Filename : >> =20 > draft-barnes-sipcore-rfc4244bis-01.txt > =20 >> Pages : 42 >> Date : 2009-06-11 >> >> This document defines a standard mechanism for capturing the >> history >> information associated with a Session Initiation Protocol >> (SIP) request. >> This capability enables many enhanced services by providing >> =20 > the > =20 >> information as to how and why a call arrives at a specific >> application >> or user. This document defines a new optional SIP header, >> History-Info, >> for capturing the history information in requests. >> >> A URL for this Internet-Draft is: >> >> =20 > http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01 > .t > =20 >> xt >> =20 >> > 0 >> 1.t%0Axt> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail >> =20 > reader > =20 >> implementation to automatically retrieve the ASCII version of >> =20 > the > =20 >> Internet-Draft. >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> >> =20 From ietf.hanserik@gmail.com Fri Jun 12 14:04:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2C1E3A6A58 for ; Fri, 12 Jun 2009 14:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BQA8XoJyaQ4 for ; Fri, 12 Jun 2009 14:04:41 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 555173A6884 for ; Fri, 12 Jun 2009 14:04:40 -0700 (PDT) Received: by ewy6 with SMTP id 6so3337151ewy.37 for ; Fri, 12 Jun 2009 14:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=O58B+eAmQWyIeKRFscR/Kb9Z/BN0gagKmCzYRDsyJu0=; b=rRaQtOiMlzzdOrTvPLyIfWm+nFoCrJbPFAlU0yRd2mImQ/3cN6T/0vYUJeWV6a8Hvg S3nshFUp4KK5IMdB6+qwlwIpXdXaJB0baTbrBrBzibwa922Y8uor9M3cMeRjzx+kHv7V SS32t3fZk9sUrDhuWOikIJiaAofO7/UWPlOh0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ejQtisQhg4UGSOQ4cO3KE2NPbXPw6/ofXccRb+fZt/7/nUDDXSawRKtNr769F6yLkV AHBSm3oP+WLtBKqdR+nBTSquDlNRtwYESBFkhM++wtz9GzQwIAT8983GJAu1IC+DF+fu WKevhc8koeTVrQuj302l22ORgcBPBvuxi/43g= Received: by 10.210.128.5 with SMTP id a5mr1272469ebd.85.1244840685600; Fri, 12 Jun 2009 14:04:45 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 5sm440437eyf.58.2009.06.12.14.04.43 (version=SSLv3 cipher=RC4-MD5); Fri, 12 Jun 2009 14:04:44 -0700 (PDT) Message-ID: <4A32C2EB.7070304@gmail.com> Date: Fri, 12 Jun 2009 23:04:43 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Mary Barnes References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120138y540f7c2bja62adcf942cba3a0@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E787F80@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120824s24f0ddfyb9dc6d6c38651d75@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D809A@zrc2hxm0.corp.nortel.com> <4A32B08C.4010308@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D8536@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E7D8536@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 21:04:43 -0000 I'm trying to do it similarly 4.3.3.1.4/[4424bis], but I do not understand how this text works for the forked case. Because for different forks the hi-entry representing the retargeted R-URI could get another tag. The current text does not seem to cover this aspect. How is this intended to be covered by this text? /Hans Erik Mary Barnes wrote: > Hi Hans, > > Just a few comments below [MB]. > > Thanks, > Mary. > > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Friday, June 12, 2009 2:46 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Hi Mary, > > >> So, it's just not clear at all to me how you coordinate the addition >> > of the two tags. Perhaps, it's just how that section is written, > >> but again, this is my point that it's really difficult to understand >> > your solution proposal when it is not described in the context of > >> the current normative RFC 4244 functionality. >> > > The text can definitely be improved, but still the criteria for adding > the tags are independent. > > I will try draft a chapter as it would look like in 4424. > [MB] Yes, it would help to understand this in the context of 16.5 where > you are determining the targets for the request as I can't quite see how > the determination of the tags are independent. And, I say determination > because as is, you don't add the tag until you are forwarding the > request per section 16.6. The exception is the case of a 3xx and the > redirect server has added the tag - at least per the 4244bis > specification of redirect server and 3xx handling, which is actually > something else missing in target-uri as this does introduce a somewhat > special case now that we are adding this level of granularity in terms > of the mechanism by which the target(s) are determined. [/MB] > > > >> This solution also does not seem to give clear delineation between >> > registered contacts versus configured URIs. I had understood > that to > be important for some services. In particular, how will this solution > support being able to identify aliases? > > Regarding the alias concept, I have no problems in adding that. But it > is currently not in scope of the target-uri work, if people agree then > we can add that requirement. We could reuse the definition that is > contained in the 4424bis draft as I think that is a good definition. > [MB] I'm puzzled as aliases are identified as a service to be supported > by target-uri in section 4.1. That's the exact use case that the > "reg-uri-alias" tag in 4244bis will support. [/MB] > > But what is the essential difference between bindings that came about > due to registration and those that are configured? (To me this has > nothing todo with aliases, in fact I think it is not a meaningful > difference how the binding was made.) But if you have a requirement for > that, you should maybe explain it. > [MB] I'm not sure we're using the term configured in the same context > here as I think you are really talking about the entries that are tagged > as "mapped" in 4244bis. The alias concept actually uses both > registration and configuration - that's why it's really a separate > mechanism by which targets are determined. This is clearly defined in > 4244bis in the description of the "reg-uri-alias" tag. [/MB] > > > /Hans Erik > > Mary Barnes wrote: > >> Hi Hans, >> >> My confusion comes from the 3rd paragraph in section 6 (the same one >> that confuses in terms of the unconditional addition of two >> hi-entries), specifically this text: >> " When a home proxy receives a request for a user or resource for >> > which > >> is abstract location function returns registered contacts or >> configured URIs, the proxy adds two History-Info header field >> > values. > >> The first is the incoming request URI. Since the Request-URI >> identifies a user or resource for which it has a registration or >> configuration, the Request-URI is an AOR and thus an address for >> > the > >> user. The proxy adds a History-Info header field parameter, "aor", >> which indicates this. Next, the proxy inserts the contact URI >> > which > >> will be contained in the outgoing Request-URI." >> >> (Note: this also confuses me because it is combining determining >> request targets with the forwarding) >> >> But, then later in that section, there's the following text (7th >> paragraph): >> "When a proxy receives a request for a user or resource for which it >> is responsible, then when a request URI rewrite occurs that is a >> routing translation, then add a History-Info header field parameter >> "routed" to the hi-entry recording the incoming request URI. >> Otherwise when a request URI rewrite occurs that is a mapping >> translation, then add a History-Info header field parameter >> > "mapped" > >> to the hi-entry recording the incoming request URI. " >> >> So, it's just not clear at all to me how you coordinate the addition >> of the two tags. Perhaps, it's just how that section is written, but >> again, this is my point that it's really difficult to understand your >> solution proposal when it is not described in the context of the >> current normative RFC 4244 functionality. >> >> This solution also does not seem to give clear delineation between >> registered contacts versus configured URIs. I had understood that to >> be important for some services. In particular, how will this solution >> support being able to identify aliases? >> >> Thanks, >> Mary. >> >> ---------------------------------------------------------------------- >> -- >> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> *Sent:* Friday, June 12, 2009 10:24 AM >> *To:* Barnes, Mary (RICH2:AR00) >> *Cc:* Christer Holmberg; sipcore@ietf.org >> *Subject:* Re: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Hi Mary, >> >> I do not understand what you mean with multi stage. All the tagging >> can be prepared at the time that the translation is done and added at >> the time that 4244 suggests the H-I to be added. If the current text >> suggests otherwise, then we might need to fix that. >> >> BR, >> /Hans Erik van Elburg >> >> >> On Fri, Jun 12, 2009 at 4:11 PM, Mary Barnes > > wrote: >> >> Hi Hans, >> >> A couple comments below [MB]. >> >> Mary. >> >> >> > ------------------------------------------------------------------------ > >> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com >> ] >> *Sent:* Friday, June 12, 2009 3:38 AM >> >> *To:* Barnes, Mary (RICH2:AR00) >> *Cc:* Christer Holmberg; sipcore@ietf.org >> > > >> *Subject:* Re: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Hi Mary, >> >> Sure when we agree on the way forward we have to resolve all these >> detailed procedures and conform to the 4244 language etc. But we >> already agreed to integrate it into 4424bis at the moment that >> there is agreement about the solution. >> >> Regarding the two tag approach that is open for discussion, i >> think it is more clean and in general pays off to separate >> concepts that are independent from each other. For example a >> hi-entry may be routed and not be an AOR, whereas it may also be >> routed and also an AOR. The decisions to be taken for additions of >> these tags are independent, so there is also no need to intertwine >> procedural text for them. (It is also more clear for >> > implementors.) > >> [MB] This is where my major confusion is in that you say the tags >> are independent, BUT where in the normative RFC 3261 processing >> does this occur? I'm confused because the logic in section 16.5 >> isn't "multi-stage" (for lack of a better term), the incoming >> request URI is evaluated and then the new target list is >> constructed The tagging in 4244 is based on the mechanism by >> which a new target is determined . The previous hi-entry (that in >> the incoming request) is tagged at the point the request is being >> forwarded. I do agree that in the internal processing that >> information needs to exist so that the tagging at the point of >> forwarding the request is appropriate. [/MB] >> >> >> >> BR, >> /Hans Erik van Elburg >> >> On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes >> > wrote: >> >> Christer, >> >> I reviewed the updated target-uri draft and have a few >> comments - well I >> reviewed the diff since there isn't a summary of changes in >> > the > >> document: >> >> 1) I had a lot of difficulty picking out the normative >> processing for >> History-Info in this document. Can you summarize the >> > differences? > >> 2) The reason I'm concerned about understanding how this fits >> with the >> current normative processing is because I'm not seeing >> precisely when >> these tags are added as the terminology is different than that >> used in >> RFC 4244 - i.e., are these two terms equivalent: >> RFC 4244: >> "... hi-entry received in the request being forwarded." >> >> target-uri: >> "...hi-entry recording the incoming request URI." >> >> There is no reference in terms of current History-Info >> processing as to >> when in the request processing these tags are added. >> >> 3) In particular, I'm having difficulty with this text in >> section 6: >> "When a home proxy receives a request for a user or resource >> > for > >> which >> is abstract location function returns registered contacts or >> configured URIs, the proxy adds two History-Info header >> field values. >> The first is the incoming request URI. Since the >> > Request-URI > >> identifies a user or resource for which it has a >> > registration or > >> configuration, the Request-URI is an AOR and thus an address >> for the >> user. The proxy adds a History-Info header field parameter, >> "aor", >> which indicates this. Next, the proxy inserts the contact >> URI which >> will be contained in the outgoing Request-URI." >> Currently, in RFC 4244, the proxy only adds that additional >> (first) >> hi-entry IF there wasn't one in the incoming request, since >> the UAC can >> initially add one when it builds the request. So, this is >> inconsistent >> with current RFC 4244. And, I think you need to define "home" >> proxy - >> that's not an RFC 3261 term - there is the concept of a "home" >> domain. >> >> 4) There is a bug in the Syntax (section 9) - the Index is not >> optional >> (that is an error we have fixed in the 4244bis). >> >> 5) I'm really confused about this two-stage tagging - how does >> that >> happen in the context of the determination of Request Targets >> in section >> 16.5 of RFC3261? Wouldn't the decisions as to the addition of >> the two >> different tags occur at the same time and thus what is the >> advantage of >> the defining the two tags - i.e., why not one tag for each >> combination? >> Also, are you proposing that the addition of the tags be >> mandatory - >> there is no normative language in the target-uri document, so >> > it's > >> impossible to tell. And, if you are proposing they be >> mandatory, your >> ABNF syntax needs to reflect that, thus defining a single >> parameter with >> multiple values would be necessary (which is the approach in >> 4244bis). >> >> >> 6) What is the difference (or is there a difference?) between >> > the > >> functionality associated with the tags in 4244bis and the tags >> defined >> in this document in terms of types of retargets that are being >> tagged? >> I think this is the crux of what we need to agree - i.e., why >> aren't the >> 4244bis tags sufficient? If there is no logical difference >> and it's >> just the words used to define the tags, then we're very close >> > to > >> agreement. >> >> Regards, >> Mary. >> >> >> >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com >> ] >> Sent: Thursday, June 11, 2009 3:32 PM >> To: Christer Holmberg; Barnes, Mary (RICH2:AR00); >> sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> Here is the link to the latest version of the target-uri >> > draft: > >> > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00. > >> txt >> >> > 00.%0Atxt> >> >> -----Original Message----- >> From: Christer Holmberg >> Sent: Thursday, June 11, 2009 11:31 PM >> To: 'Mary Barnes'; sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> Hi, >> >> I think it is important to mention that there are still >> > different > >> approaches regarding the target uri delivery, and that there >> is another >> approach described in the latest version of the target-uri >> delivery >> draft (I am not sure it appears in the archieves, though, for >> > some > >> reason). Both approaches are based on History-Info, though. >> >> We haven't yet been able to agree on an approach, so we >> thought the best >> is to bring it to the list in order for other people to get >> involved. >> >> Regards, >> >> Christer >> >> >> >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> >> [mailto:sipcore-bounces@ietf.org >> ] On >> Behalf Of Mary Barnes >> Sent: Thursday, June 11, 2009 9:05 PM >> To: sipcore@ietf.org >> Subject: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Hi folks, >> >> We have made a few changes to this document which was >> submitted last >> week just to tie up some loose ends and inconsistencies, some >> of which >> Shida identified when he reviewed the -00 version. >> >> The following summarizes the high level changes in the >> sipcore-rfc4244bis from the sip-rfc4244bis that we discussed >> in San >> Francisco: >> 1) Renamed the "retarget" parameter to "target" and defined >> explicit >> tags to reflect the various mechanisms by which a Request is >> retargeted. >> All entries are now tagged. >> 2) Updated redirect server processing as the redirect server >> > must > >> capture the "target" parameter since it is the entity that >> knows the >> specific mechanism by which the new target has been >> > determined. > >> 3) Changed the privacy such that rather than removing entries >> based on >> the various values of the privacy header, the entries are >> recommended to >> be anonymized. >> 4) Updated security section >> 5) Updated examples to reflect the new parameter, use loose >> routing and >> fix errors/nits. >> 6) Editorial changes to remove redundant text and the >> convuluted text >> around optionality in the non-normative sections, which is now >> discussed >> appropriately in the context of the histinfo option tag. >> >> The detailed changes between the versions are summarized in >> > the > >> document. >> >> If you're wanting to look at a diff, I would recommend you >> diff against >> RFC 4244 rather than the earlier 4244bis documents. >> >> We'd really appreciate feedback on this approach to precisely >> tagging >> all the entries. We believe it is comprehensive and should >> suffice for >> all the use cases identified in the target-uri document, as >> well as any >> others that might arise. >> >> Thanks, >> Mary and Francois. >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> >> [mailto:i-d-announce-bounces@ietf.org >> ] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: Thursday, June 11, 2009 12:45 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> A New Internet-Draft is available from the on-line >> > Internet-Drafts > >> directories. >> >> Title : An Extension to the Session >> > Initiation > >> Protocol (SIP) for Request History Information >> Author(s) : M. Barnes, F. Audet >> Filename : >> > draft-barnes-sipcore-rfc4244bis-01.txt > >> Pages : 42 >> Date : 2009-06-11 >> >> This document defines a standard mechanism for capturing the >> history >> information associated with a Session Initiation Protocol >> (SIP) request. >> This capability enables many enhanced services by providing >> > the > >> information as to how and why a call arrives at a specific >> application >> or user. This document defines a new optional SIP header, >> History-Info, >> for capturing the history information in requests. >> >> A URL for this Internet-Draft is: >> >> > http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01.t > >> xt >> >> > 1.t%0Axt> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail >> > reader > >> implementation to automatically retrieve the ASCII version of >> > the > >> Internet-Draft. >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> >> From ietf.hanserik@gmail.com Fri Jun 12 14:13:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E2B13A697C for ; Fri, 12 Jun 2009 14:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-zXvMnso+o0 for ; Fri, 12 Jun 2009 14:13:36 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id BB1CD3A6A0A for ; Fri, 12 Jun 2009 14:13:35 -0700 (PDT) Received: by ewy6 with SMTP id 6so3343841ewy.37 for ; Fri, 12 Jun 2009 14:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=U1UOYFceYwKu8PQbGWMRjuxSTdEQoqUmiPs8N8PKBwg=; b=XuDbujO6B4kg8OTTtcaZ8uyz3PEkoXXZ9abK84WPXPJ0jcjvTyGKC1deiq7PxxK2gL MVQu08Md3Qxpf3FT16tfudqL6tp4D69J8wRxFPuV9C/WQ1RgtZg2qQWjAOkmv07ZSjXE pM4E/97R9tn5JIrp4oLCJp+NfymEbNkZBbuqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=pBuSPOYkUWfKkOzT1dZsq6S4D9GEJGri1uAQWVT5Avyuez/XHzR+m8TyapM/3/7SiO qZCydTX1KBQ//uTD8sEJ+qmAjpBiJuhuJ70TA0StVJXRShdxfilc8ZqCSO5Kw0LTubnS sVcO5/2nC/sctOOBMsZayD4CrtN8avj9dCpNA= Received: by 10.210.37.16 with SMTP id k16mr516846ebk.91.1244841220163; Fri, 12 Jun 2009 14:13:40 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 28sm374000eye.56.2009.06.12.14.13.38 (version=SSLv3 cipher=RC4-MD5); Fri, 12 Jun 2009 14:13:39 -0700 (PDT) Message-ID: <4A32C502.6000401@gmail.com> Date: Fri, 12 Jun 2009 23:13:38 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Mary Barnes References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120138y540f7c2bja62adcf942cba3a0@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E787F80@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120824s24f0ddfyb9dc6d6c38651d75@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D809A@zrc2hxm0.corp.nortel.com> <4A32B08C.4010308@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D8536@zrc2hxm0.corp.nortel.com> <4A32BD1E.6080206@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D85D4@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E7D85D4@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 21:13:38 -0000 Mary Barnes wrote: > I'm even further puzzled then. The abstract of target-uri states: > > "This document > describes these use cases and defines an extension to the History- > Info header field which allows it to be used to support those cases." > > With the following listed in the TOC: > 4.1. Unknown Aliases . . . . . . . . . . . . . . . . . . . . . 5 > 4.2. Unknown GRUU . . . . . . . . . . . . . . . . . . . . . . . 6 > 4.3. Limited Use Addresses . . . . . . . . . . . . . . . . . . 6 > 4.4. Sub-Addressing . . . . . . . . . . . . . . . . . . . . . . 6 > 4.5. Service Invocation . . . . . . . . . . . . . . . . . . . . 7 > 4.6. Toll Free Numbers . . > > I thought the whole point was to handle ANY of the use cases "where this > information is usefull for the UAS, but destroyed by Request-URI > overwriting" - i.e, that's the general problem being solved and the > solution provided by History-Info is agnostic as to how an application > might use that information. > > Exactly. > I think what we may be butting heads on isn't the History-Info aspects > of supporting those services, but rather that the information that some > of those services depend on isn't amenable to clear identification in > terms of how SIP determines request targets. This is where I was going > with my initial suggestion that you may need to add some more service > specific looking tags to the request URIs. > > It is not a service specific thing, but specific services cant be provided because SIP adresses target uri delivery is broken. > Mary. > > > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Friday, June 12, 2009 3:40 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > [MB] I'm puzzled as aliases are identified as a service to be supported > by target-uri in section 4.1. That's the exact use case that the > "reg-uri-alias" tag in 4244bis will support. [/MB] > > The delivery of the addressed target to the UAS is what we are trying to > solve, the alias use case is just showing a case where this information > is usefull for the UAS, but destroyed by Request-URI overwriting. > > Best Regards, > /Hans Erik > > Mary Barnes wrote: > >> Hi Hans, >> >> Just a few comments below [MB]. >> >> Thanks, >> Mary. >> >> -----Original Message----- >> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> Sent: Friday, June 12, 2009 2:46 PM >> To: Barnes, Mary (RICH2:AR00) >> Cc: Christer Holmberg; sipcore@ietf.org >> Subject: Re: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Hi Mary, >> >> >> >>> So, it's just not clear at all to me how you coordinate the addition >>> >>> >> of the two tags. Perhaps, it's just how that section is written, >> >> >>> but again, this is my point that it's really difficult to understand >>> >>> >> your solution proposal when it is not described in the context of >> >> >>> the current normative RFC 4244 functionality. >>> >>> >> The text can definitely be improved, but still the criteria for adding >> > > >> the tags are independent. >> >> I will try draft a chapter as it would look like in 4424. >> [MB] Yes, it would help to understand this in the context of 16.5 >> where you are determining the targets for the request as I can't quite >> > > >> see how the determination of the tags are independent. And, I say >> determination because as is, you don't add the tag until you are >> forwarding the request per section 16.6. The exception is the case of >> > > >> a 3xx and the redirect server has added the tag - at least per the >> 4244bis specification of redirect server and 3xx handling, which is >> actually something else missing in target-uri as this does introduce a >> > > >> somewhat special case now that we are adding this level of granularity >> > > >> in terms of the mechanism by which the target(s) are determined. [/MB] >> >> >> >> >>> This solution also does not seem to give clear delineation between >>> >>> >> registered contacts versus configured URIs. I had understood > that to >> > > >> be important for some services. In particular, how will this solution >> support being able to identify aliases? >> >> Regarding the alias concept, I have no problems in adding that. But it >> > > >> is currently not in scope of the target-uri work, if people agree then >> > > >> we can add that requirement. We could reuse the definition that is >> contained in the 4424bis draft as I think that is a good definition. >> [MB] I'm puzzled as aliases are identified as a service to be >> supported by target-uri in section 4.1. That's the exact use case that >> > > >> the "reg-uri-alias" tag in 4244bis will support. [/MB] >> >> But what is the essential difference between bindings that came about >> due to registration and those that are configured? (To me this has >> nothing todo with aliases, in fact I think it is not a meaningful >> difference how the binding was made.) But if you have a requirement >> for that, you should maybe explain it. >> [MB] I'm not sure we're using the term configured in the same context >> here as I think you are really talking about the entries that are >> tagged as "mapped" in 4244bis. The alias concept actually uses both >> registration and configuration - that's why it's really a separate >> mechanism by which targets are determined. This is clearly defined in >> 4244bis in the description of the "reg-uri-alias" tag. [/MB] >> >> >> /Hans Erik >> >> Mary Barnes wrote: >> >> >>> Hi Hans, >>> >>> My confusion comes from the 3rd paragraph in section 6 (the same one >>> that confuses in terms of the unconditional addition of two >>> hi-entries), specifically this text: >>> " When a home proxy receives a request for a user or resource for >>> >>> >> which >> >> >>> is abstract location function returns registered contacts or >>> configured URIs, the proxy adds two History-Info header field >>> >>> >> values. >> >> >>> The first is the incoming request URI. Since the Request-URI >>> identifies a user or resource for which it has a registration or >>> configuration, the Request-URI is an AOR and thus an address for >>> >>> >> the >> >> >>> user. The proxy adds a History-Info header field parameter, >>> > "aor", > >>> which indicates this. Next, the proxy inserts the contact URI >>> >>> >> which >> >> >>> will be contained in the outgoing Request-URI." >>> >>> (Note: this also confuses me because it is combining determining >>> request targets with the forwarding) >>> >>> But, then later in that section, there's the following text (7th >>> paragraph): >>> "When a proxy receives a request for a user or resource for which >>> > it > >>> is responsible, then when a request URI rewrite occurs that is a >>> routing translation, then add a History-Info header field >>> > parameter > >>> "routed" to the hi-entry recording the incoming request URI. >>> Otherwise when a request URI rewrite occurs that is a mapping >>> translation, then add a History-Info header field parameter >>> >>> >> "mapped" >> >> >>> to the hi-entry recording the incoming request URI. " >>> >>> So, it's just not clear at all to me how you coordinate the addition >>> of the two tags. Perhaps, it's just how that section is written, but >>> > > >>> again, this is my point that it's really difficult to understand your >>> > > >>> solution proposal when it is not described in the context of the >>> current normative RFC 4244 functionality. >>> >>> This solution also does not seem to give clear delineation between >>> registered contacts versus configured URIs. I had understood that to >>> be important for some services. In particular, how will this solution >>> > > >>> support being able to identify aliases? >>> >>> Thanks, >>> Mary. >>> >>> --------------------------------------------------------------------- >>> - >>> -- >>> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >>> *Sent:* Friday, June 12, 2009 10:24 AM >>> *To:* Barnes, Mary (RICH2:AR00) >>> *Cc:* Christer Holmberg; sipcore@ietf.org >>> *Subject:* Re: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> Hi Mary, >>> >>> I do not understand what you mean with multi stage. All the tagging >>> can be prepared at the time that the translation is done and added at >>> > > >>> the time that 4244 suggests the H-I to be added. If the current text >>> suggests otherwise, then we might need to fix that. >>> >>> BR, >>> /Hans Erik van Elburg >>> >>> >>> On Fri, Jun 12, 2009 at 4:11 PM, Mary Barnes >> > wrote: >>> >>> Hi Hans, >>> >>> A couple comments below [MB]. >>> >>> Mary. >>> >>> >>> >>> >> ---------------------------------------------------------------------- >> -- >> >> >>> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com >>> ] >>> *Sent:* Friday, June 12, 2009 3:38 AM >>> >>> *To:* Barnes, Mary (RICH2:AR00) >>> *Cc:* Christer Holmberg; sipcore@ietf.org >>> >>> >> >> >> >>> *Subject:* Re: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> Hi Mary, >>> >>> Sure when we agree on the way forward we have to resolve all >>> > these > >>> detailed procedures and conform to the 4244 language etc. But we >>> already agreed to integrate it into 4424bis at the moment that >>> there is agreement about the solution. >>> >>> Regarding the two tag approach that is open for discussion, i >>> think it is more clean and in general pays off to separate >>> concepts that are independent from each other. For example a >>> hi-entry may be routed and not be an AOR, whereas it may also be >>> routed and also an AOR. The decisions to be taken for additions >>> > of > >>> these tags are independent, so there is also no need to >>> > intertwine > >>> procedural text for them. (It is also more clear for >>> >>> >> implementors.) >> >> >>> [MB] This is where my major confusion is in that you say the tags >>> are independent, BUT where in the normative RFC 3261 processing >>> does this occur? I'm confused because the logic in section 16.5 >>> isn't "multi-stage" (for lack of a better term), the incoming >>> request URI is evaluated and then the new target list is >>> constructed The tagging in 4244 is based on the mechanism by >>> which a new target is determined . The previous hi-entry (that >>> > in > >>> the incoming request) is tagged at the point the request is being >>> forwarded. I do agree that in the internal processing that >>> information needs to exist so that the tagging at the point of >>> forwarding the request is appropriate. [/MB] >>> >>> >>> >>> BR, >>> /Hans Erik van Elburg >>> >>> On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes >>> > wrote: >>> >>> Christer, >>> >>> I reviewed the updated target-uri draft and have a few >>> comments - well I >>> reviewed the diff since there isn't a summary of changes in >>> >>> >> the >> >> >>> document: >>> >>> 1) I had a lot of difficulty picking out the normative >>> processing for >>> History-Info in this document. Can you summarize the >>> >>> >> differences? >> >> >>> 2) The reason I'm concerned about understanding how this fits >>> with the >>> current normative processing is because I'm not seeing >>> precisely when >>> these tags are added as the terminology is different than >>> > that > >>> used in >>> RFC 4244 - i.e., are these two terms equivalent: >>> RFC 4244: >>> "... hi-entry received in the request being forwarded." >>> >>> target-uri: >>> "...hi-entry recording the incoming request URI." >>> >>> There is no reference in terms of current History-Info >>> processing as to >>> when in the request processing these tags are added. >>> >>> 3) In particular, I'm having difficulty with this text in >>> section 6: >>> "When a home proxy receives a request for a user or >>> resource >>> >>> >> for >> >> >>> which >>> is abstract location function returns registered contacts >>> > or > >>> configured URIs, the proxy adds two History-Info header >>> field values. >>> The first is the incoming request URI. Since the >>> >>> >> Request-URI >> >> >>> identifies a user or resource for which it has a >>> >>> >> registration or >> >> >>> configuration, the Request-URI is an AOR and thus an >>> > address > >>> for the >>> user. The proxy adds a History-Info header field >>> > parameter, > >>> "aor", >>> which indicates this. Next, the proxy inserts the contact >>> URI which >>> will be contained in the outgoing Request-URI." >>> Currently, in RFC 4244, the proxy only adds that additional >>> (first) >>> hi-entry IF there wasn't one in the incoming request, since >>> the UAC can >>> initially add one when it builds the request. So, this is >>> inconsistent >>> with current RFC 4244. And, I think you need to define "home" >>> proxy - >>> that's not an RFC 3261 term - there is the concept of a >>> > "home" > >>> domain. >>> >>> 4) There is a bug in the Syntax (section 9) - the Index is >>> > not > >>> optional >>> (that is an error we have fixed in the 4244bis). >>> >>> 5) I'm really confused about this two-stage tagging - how >>> > does > >>> that >>> happen in the context of the determination of Request Targets >>> in section >>> 16.5 of RFC3261? Wouldn't the decisions as to the addition of >>> the two >>> different tags occur at the same time and thus what is the >>> advantage of >>> the defining the two tags - i.e., why not one tag for each >>> combination? >>> Also, are you proposing that the addition of the tags be >>> mandatory - >>> there is no normative language in the target-uri document, so >>> >>> >> it's >> >> >>> impossible to tell. And, if you are proposing they be >>> mandatory, your >>> ABNF syntax needs to reflect that, thus defining a single >>> parameter with >>> multiple values would be necessary (which is the approach in >>> 4244bis). >>> >>> >>> 6) What is the difference (or is there a difference?) between >>> >>> >> the >> >> >>> functionality associated with the tags in 4244bis and the >>> > tags > >>> defined >>> in this document in terms of types of retargets that are >>> > being > >>> tagged? >>> I think this is the crux of what we need to agree - i.e., why >>> aren't the >>> 4244bis tags sufficient? If there is no logical difference >>> and it's >>> just the words used to define the tags, then we're very close >>> >>> >> to >> >> >>> agreement. >>> >>> Regards, >>> Mary. >>> >>> >>> >>> -----Original Message----- >>> From: Christer Holmberg >>> > [mailto:christer.holmberg@ericsson.com > >>> ] >>> Sent: Thursday, June 11, 2009 3:32 PM >>> To: Christer Holmberg; Barnes, Mary (RICH2:AR00); >>> sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> >>> Here is the link to the latest version of the target-uri >>> >>> >> draft: >> >> >>> >>> > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00. > >> >> >>> txt >>> >>> >> - >>> 00.%0Atxt> >>> >>> -----Original Message----- >>> From: Christer Holmberg >>> Sent: Thursday, June 11, 2009 11:31 PM >>> To: 'Mary Barnes'; sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> >>> Hi, >>> >>> I think it is important to mention that there are still >>> >>> >> different >> >> >>> approaches regarding the target uri delivery, and that there >>> is another >>> approach described in the latest version of the target-uri >>> delivery >>> draft (I am not sure it appears in the archieves, though, for >>> >>> >> some >> >> >>> reason). Both approaches are based on History-Info, though. >>> >>> We haven't yet been able to agree on an approach, so we >>> thought the best >>> is to bring it to the list in order for other people to get >>> involved. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org >>> >>> [mailto:sipcore-bounces@ietf.org >>> ] On >>> Behalf Of Mary Barnes >>> Sent: Thursday, June 11, 2009 9:05 PM >>> To: sipcore@ietf.org >>> Subject: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> Hi folks, >>> >>> We have made a few changes to this document which was >>> submitted last >>> week just to tie up some loose ends and inconsistencies, some >>> of which >>> Shida identified when he reviewed the -00 version. >>> >>> The following summarizes the high level changes in the >>> sipcore-rfc4244bis from the sip-rfc4244bis that we discussed >>> in San >>> Francisco: >>> 1) Renamed the "retarget" parameter to "target" and defined >>> explicit >>> tags to reflect the various mechanisms by which a Request is >>> retargeted. >>> All entries are now tagged. >>> 2) Updated redirect server processing as the redirect server >>> >>> >> must >> >> >>> capture the "target" parameter since it is the entity that >>> knows the >>> specific mechanism by which the new target has been >>> >>> >> determined. >> >> >>> 3) Changed the privacy such that rather than removing entries >>> based on >>> the various values of the privacy header, the entries are >>> recommended to >>> be anonymized. >>> 4) Updated security section >>> 5) Updated examples to reflect the new parameter, use loose >>> routing and >>> fix errors/nits. >>> 6) Editorial changes to remove redundant text and the >>> convuluted text >>> around optionality in the non-normative sections, which is >>> > now > >>> discussed >>> appropriately in the context of the histinfo option tag. >>> >>> The detailed changes between the versions are summarized in >>> >>> >> the >> >> >>> document. >>> >>> If you're wanting to look at a diff, I would recommend you >>> diff against >>> RFC 4244 rather than the earlier 4244bis documents. >>> >>> We'd really appreciate feedback on this approach to precisely >>> tagging >>> all the entries. We believe it is comprehensive and should >>> suffice for >>> all the use cases identified in the target-uri document, as >>> well as any >>> others that might arise. >>> >>> Thanks, >>> Mary and Francois. >>> >>> -----Original Message----- >>> From: i-d-announce-bounces@ietf.org >>> >>> [mailto:i-d-announce-bounces@ietf.org >>> ] On Behalf Of >>> Internet-Drafts@ietf.org >>> Sent: Thursday, June 11, 2009 12:45 PM >>> To: i-d-announce@ietf.org >>> Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> A New Internet-Draft is available from the on-line >>> >>> >> Internet-Drafts >> >> >>> directories. >>> >>> Title : An Extension to the Session >>> >>> >> Initiation >> >> >>> Protocol (SIP) for Request History Information >>> Author(s) : M. Barnes, F. Audet >>> Filename : >>> >>> >> draft-barnes-sipcore-rfc4244bis-01.txt >> >> >>> Pages : 42 >>> Date : 2009-06-11 >>> >>> This document defines a standard mechanism for capturing the >>> history >>> information associated with a Session Initiation Protocol >>> (SIP) request. >>> This capability enables many enhanced services by providing >>> >>> >> the >> >> >>> information as to how and why a call arrives at a specific >>> application >>> or user. This document defines a new optional SIP header, >>> History-Info, >>> for capturing the history information in requests. >>> >>> A URL for this Internet-Draft is: >>> >>> >>> >> http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01 >> .t >> >> >>> xt >>> >>> >> 0 >>> 1.t%0Axt> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail >>> >>> >> reader >> >> >>> implementation to automatically retrieve the ASCII version of >>> >>> >> the >> >> >>> Internet-Draft. >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >>> >>> >>> From mary.barnes@nortel.com Fri Jun 12 14:54:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E3B13A6976 for ; Fri, 12 Jun 2009 14:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.473 X-Spam-Level: X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hh22hYxPcfvE for ; Fri, 12 Jun 2009 14:54:49 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 57A543A6847 for ; Fri, 12 Jun 2009 14:54:49 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5CLssE08319; Fri, 12 Jun 2009 21:54:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 16:56:55 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E7D86CF@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A32C2EB.7070304@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnroWyYDPwzVx1NSkqjbHBhyzGKlAAAhCgg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120138y540f7c2bja62adcf942cba3a0@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E787F80@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120824s24f0ddfyb9dc6d6c38651d75@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D809A@zrc2hxm0.corp.nortel.com> <4A32B08C.4010308@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D8536@zrc2hxm0.corp.nortel.com> <4A32C2EB.7070304@gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 21:54:51 -0000 Hi Hans, I think we're making progress - I understand why you do not understand this. We likely need to add some more text to make this clear. The way History-Info works now is that the tags are added to the previous/last hi-entry (i.e., the one in the incoming request) at the point in time that the request is being forwarded. This is what's described in section 4.3.3.1. =20 This means that the proxy needs to keep track of the hi-target that would be applied to that previous/last hi-entry for each target in the target list it builds per section 16.5. Then, as the proxy forwards the request as described in section 4.3.3.1, the proxy has the information as to how to appropriately tag that previous/last hi-entry. That's the only way it will work. But, yes, this is confusing in that section 4.3.3.1.4 is discussing how the information that is used when the request is forwarded is derived.=20 So, I will add some text to clarify this in the next update to 4244bis, I should reword that first paragraph in section 4.3.3.1.4 as follows: OLD: An hi-target attribute MUST be included in a request forwarded by a proxy. The addition of the hi-target parameter MUST occur prior to the forwarding of the request (which may add a new hi-entry with a new hi-targeted-to- uri) as it is associated with the hi-targeted-to- uri that has been retargeted. =20 NEW:=20 An hi-target attribute MUST be included in a request forwarded by a proxy. The addition of the hi-target parameter MUST occur just prior to the forwarding of the request (which may add a new hi-entry with a new hi-targeted-to- uri) as it is associated with the hi-targeted-to- uri that has been retargeted.=20 The value for the hi-target attribute is determined by the proxy when it builds=20 the target list as described in section 16.5 of [RFC3261]. The subsequent paragraphs=20 describe the processing relevant to section 16.5 for determining the value of the=20 hi-target attribute that is associated with a specific target to which a request=20 is to be forwarded and the value to which the hi-target parameter MUST be set when=20 the request is forwarded. Thanks, Mary.=20 -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Friday, June 12, 2009 4:05 PM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt I'm trying to do it similarly 4.3.3.1.4/[4424bis], but I do not understand how this text works for the forked case. Because for different forks the hi-entry representing the retargeted R-URI could get another tag. The current text does not seem to cover this aspect. How is this intended to be covered by this text? /Hans Erik Mary Barnes wrote: > Hi Hans, > > Just a few comments below [MB]. =20 > > Thanks, > Mary. > > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Friday, June 12, 2009 2:46 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Hi Mary, > > =20 >> So, it's just not clear at all to me how you coordinate the addition >> =20 > of the two tags. Perhaps, it's just how that section is written, > =20 >> but again, this is my point that it's really difficult to understand >> =20 > your solution proposal when it is not described in the context of > =20 >> the current normative RFC 4244 functionality.=20 >> =20 > > The text can definitely be improved, but still the criteria for adding > the tags are independent. > > I will try draft a chapter as it would look like in 4424. > [MB] Yes, it would help to understand this in the context of 16.5=20 > where you are determining the targets for the request as I can't quite > see how the determination of the tags are independent. And, I say=20 > determination because as is, you don't add the tag until you are=20 > forwarding the request per section 16.6. The exception is the case of > a 3xx and the redirect server has added the tag - at least per the=20 > 4244bis specification of redirect server and 3xx handling, which is=20 > actually something else missing in target-uri as this does introduce a > somewhat special case now that we are adding this level of granularity > in terms of the mechanism by which the target(s) are determined. [/MB] > > > =20 >> This solution also does not seem to give clear delineation between >> =20 > registered contacts versus configured URIs. I had understood > that to > be important for some services. In particular, how will this solution=20 > support being able to identify aliases? > > Regarding the alias concept, I have no problems in adding that. But it > is currently not in scope of the target-uri work, if people agree then > we can add that requirement. We could reuse the definition that is=20 > contained in the 4424bis draft as I think that is a good definition. > [MB] I'm puzzled as aliases are identified as a service to be=20 > supported by target-uri in section 4.1. That's the exact use case that > the "reg-uri-alias" tag in 4244bis will support. [/MB] > > But what is the essential difference between bindings that came about=20 > due to registration and those that are configured? (To me this has=20 > nothing todo with aliases, in fact I think it is not a meaningful=20 > difference how the binding was made.) But if you have a requirement=20 > for that, you should maybe explain it. > [MB] I'm not sure we're using the term configured in the same context=20 > here as I think you are really talking about the entries that are=20 > tagged as "mapped" in 4244bis. The alias concept actually uses both=20 > registration and configuration - that's why it's really a separate=20 > mechanism by which targets are determined. This is clearly defined in=20 > 4244bis in the description of the "reg-uri-alias" tag. [/MB] > > > /Hans Erik > > Mary Barnes wrote: > =20 >> Hi Hans, >> =20 >> My confusion comes from the 3rd paragraph in section 6 (the same one=20 >> that confuses in terms of the unconditional addition of two=20 >> hi-entries), specifically this text: >> " When a home proxy receives a request for a user or resource for >> =20 > which > =20 >> is abstract location function returns registered contacts or >> configured URIs, the proxy adds two History-Info header field >> =20 > values. > =20 >> The first is the incoming request URI. Since the Request-URI >> identifies a user or resource for which it has a registration or >> configuration, the Request-URI is an AOR and thus an address for >> =20 > the > =20 >> user. The proxy adds a History-Info header field parameter, "aor", >> which indicates this. Next, the proxy inserts the contact URI >> =20 > which > =20 >> will be contained in the outgoing Request-URI." >> =20 >> (Note: this also confuses me because it is combining determining=20 >> request targets with the forwarding) >> =20 >> But, then later in that section, there's the following text (7th >> paragraph): >> "When a proxy receives a request for a user or resource for which it >> is responsible, then when a request URI rewrite occurs that is a >> routing translation, then add a History-Info header field parameter >> "routed" to the hi-entry recording the incoming request URI. >> Otherwise when a request URI rewrite occurs that is a mapping >> translation, then add a History-Info header field parameter >> =20 > "mapped" > =20 >> to the hi-entry recording the incoming request URI. " >> =20 >> So, it's just not clear at all to me how you coordinate the addition=20 >> of the two tags. Perhaps, it's just how that section is written, but >> again, this is my point that it's really difficult to understand your >> solution proposal when it is not described in the context of the=20 >> current normative RFC 4244 functionality. >> =20 >> This solution also does not seem to give clear delineation between=20 >> registered contacts versus configured URIs. I had understood that to=20 >> be important for some services. In particular, how will this solution >> support being able to identify aliases? >> =20 >> Thanks, >> Mary. >> =20 >> --------------------------------------------------------------------- >> - >> -- >> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> *Sent:* Friday, June 12, 2009 10:24 AM >> *To:* Barnes, Mary (RICH2:AR00) >> *Cc:* Christer Holmberg; sipcore@ietf.org >> *Subject:* Re: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Hi Mary, >> >> I do not understand what you mean with multi stage. All the tagging=20 >> can be prepared at the time that the translation is done and added at >> the time that 4244 suggests the H-I to be added. If the current text=20 >> suggests otherwise, then we might need to fix that. >> >> BR, >> /Hans Erik van Elburg >> >> >> On Fri, Jun 12, 2009 at 4:11 PM, Mary Barnes > > wrote: >> >> Hi Hans, >> =20 >> A couple comments below [MB]. >> =20 >> Mary. >> >> >> =20 > ---------------------------------------------------------------------- > -- > =20 >> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com >> ] >> *Sent:* Friday, June 12, 2009 3:38 AM >> >> *To:* Barnes, Mary (RICH2:AR00) >> *Cc:* Christer Holmberg; sipcore@ietf.org >> =20 > > =20 >> *Subject:* Re: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Hi Mary, >> >> Sure when we agree on the way forward we have to resolve all these >> detailed procedures and conform to the 4244 language etc. But we >> already agreed to integrate it into 4424bis at the moment that >> there is agreement about the solution. >> >> Regarding the two tag approach that is open for discussion, i >> think it is more clean and in general pays off to separate >> concepts that are independent from each other. For example a >> hi-entry may be routed and not be an AOR, whereas it may also be >> routed and also an AOR. The decisions to be taken for additions of >> these tags are independent, so there is also no need to intertwine >> procedural text for them. (It is also more clear for >> =20 > implementors.) > =20 >> [MB] This is where my major confusion is in that you say the tags >> are independent, BUT where in the normative RFC 3261 processing >> does this occur? I'm confused because the logic in section 16.5 >> isn't "multi-stage" (for lack of a better term), the incoming >> request URI is evaluated and then the new target list is >> constructed The tagging in 4244 is based on the mechanism by >> which a new target is determined . The previous hi-entry (that in >> the incoming request) is tagged at the point the request is being >> forwarded. I do agree that in the internal processing that >> information needs to exist so that the tagging at the point of >> forwarding the request is appropriate. [/MB] >> =20 >> >> >> BR, >> /Hans Erik van Elburg >> >> On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes >> > wrote: >> >> Christer, >> >> I reviewed the updated target-uri draft and have a few >> comments - well I >> reviewed the diff since there isn't a summary of changes in >> =20 > the > =20 >> document: >> >> 1) I had a lot of difficulty picking out the normative >> processing for >> History-Info in this document. Can you summarize the >> =20 > differences? > =20 >> 2) The reason I'm concerned about understanding how this fits >> with the >> current normative processing is because I'm not seeing >> precisely when >> these tags are added as the terminology is different than that >> used in >> RFC 4244 - i.e., are these two terms equivalent: >> RFC 4244: >> "... hi-entry received in the request being forwarded." >> >> target-uri: >> "...hi-entry recording the incoming request URI." >> >> There is no reference in terms of current History-Info >> processing as to >> when in the request processing these tags are added. >> >> 3) In particular, I'm having difficulty with this text in >> section 6: >> "When a home proxy receives a request for a user or=20 >> resource >> =20 > for > =20 >> which >> is abstract location function returns registered contacts or >> configured URIs, the proxy adds two History-Info header >> field values. >> The first is the incoming request URI. Since the >> =20 > Request-URI > =20 >> identifies a user or resource for which it has a >> =20 > registration or > =20 >> configuration, the Request-URI is an AOR and thus an address >> for the >> user. The proxy adds a History-Info header field parameter, >> "aor", >> which indicates this. Next, the proxy inserts the contact >> URI which >> will be contained in the outgoing Request-URI." >> Currently, in RFC 4244, the proxy only adds that additional >> (first) >> hi-entry IF there wasn't one in the incoming request, since >> the UAC can >> initially add one when it builds the request. So, this is >> inconsistent >> with current RFC 4244. And, I think you need to define "home" >> proxy - >> that's not an RFC 3261 term - there is the concept of a "home" >> domain. >> >> 4) There is a bug in the Syntax (section 9) - the Index is not >> optional >> (that is an error we have fixed in the 4244bis). >> >> 5) I'm really confused about this two-stage tagging - how does >> that >> happen in the context of the determination of Request Targets >> in section >> 16.5 of RFC3261? Wouldn't the decisions as to the addition of >> the two >> different tags occur at the same time and thus what is the >> advantage of >> the defining the two tags - i.e., why not one tag for each >> combination? >> Also, are you proposing that the addition of the tags be >> mandatory - >> there is no normative language in the target-uri document, so >> =20 > it's > =20 >> impossible to tell. And, if you are proposing they be >> mandatory, your >> ABNF syntax needs to reflect that, thus defining a single >> parameter with >> multiple values would be necessary (which is the approach in >> 4244bis). >> >> >> 6) What is the difference (or is there a difference?) between >> =20 > the > =20 >> functionality associated with the tags in 4244bis and the tags >> defined >> in this document in terms of types of retargets that are being >> tagged? >> I think this is the crux of what we need to agree - i.e., why >> aren't the >> 4244bis tags sufficient? If there is no logical difference >> and it's >> just the words used to define the tags, then we're very close >> =20 > to > =20 >> agreement. >> >> Regards, >> Mary. >> >> >> >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com >> ] >> Sent: Thursday, June 11, 2009 3:32 PM >> To: Christer Holmberg; Barnes, Mary (RICH2:AR00); >> sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> Here is the link to the latest version of the target-uri >> =20 > draft: > =20 >> =20 > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00. > =20 >> txt >> =20 >> > - >> 00.%0Atxt> >> >> -----Original Message----- >> From: Christer Holmberg >> Sent: Thursday, June 11, 2009 11:31 PM >> To: 'Mary Barnes'; sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> Hi, >> >> I think it is important to mention that there are still >> =20 > different > =20 >> approaches regarding the target uri delivery, and that there >> is another >> approach described in the latest version of the target-uri >> delivery >> draft (I am not sure it appears in the archieves, though, for >> =20 > some > =20 >> reason). Both approaches are based on History-Info, though. >> >> We haven't yet been able to agree on an approach, so we >> thought the best >> is to bring it to the list in order for other people to get >> involved. >> >> Regards, >> >> Christer >> >> >> >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> >> [mailto:sipcore-bounces@ietf.org >> ] On >> Behalf Of Mary Barnes >> Sent: Thursday, June 11, 2009 9:05 PM >> To: sipcore@ietf.org >> Subject: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Hi folks, >> >> We have made a few changes to this document which was >> submitted last >> week just to tie up some loose ends and inconsistencies, some >> of which >> Shida identified when he reviewed the -00 version. >> >> The following summarizes the high level changes in the >> sipcore-rfc4244bis from the sip-rfc4244bis that we discussed >> in San >> Francisco: >> 1) Renamed the "retarget" parameter to "target" and defined >> explicit >> tags to reflect the various mechanisms by which a Request is >> retargeted. >> All entries are now tagged. >> 2) Updated redirect server processing as the redirect server >> =20 > must > =20 >> capture the "target" parameter since it is the entity that >> knows the >> specific mechanism by which the new target has been >> =20 > determined. > =20 >> 3) Changed the privacy such that rather than removing entries >> based on >> the various values of the privacy header, the entries are >> recommended to >> be anonymized. >> 4) Updated security section >> 5) Updated examples to reflect the new parameter, use loose >> routing and >> fix errors/nits. >> 6) Editorial changes to remove redundant text and the >> convuluted text >> around optionality in the non-normative sections, which is now >> discussed >> appropriately in the context of the histinfo option tag. >> >> The detailed changes between the versions are summarized in >> =20 > the > =20 >> document. >> >> If you're wanting to look at a diff, I would recommend you >> diff against >> RFC 4244 rather than the earlier 4244bis documents. >> >> We'd really appreciate feedback on this approach to precisely >> tagging >> all the entries. We believe it is comprehensive and should >> suffice for >> all the use cases identified in the target-uri document, as >> well as any >> others that might arise. >> >> Thanks, >> Mary and Francois. >> >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org >> >> [mailto:i-d-announce-bounces@ietf.org >> ] On Behalf Of >> Internet-Drafts@ietf.org >> Sent: Thursday, June 11, 2009 12:45 PM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> A New Internet-Draft is available from the on-line >> =20 > Internet-Drafts > =20 >> directories. >> >> Title : An Extension to the Session >> =20 > Initiation > =20 >> Protocol (SIP) for Request History Information >> Author(s) : M. Barnes, F. Audet >> Filename : >> =20 > draft-barnes-sipcore-rfc4244bis-01.txt > =20 >> Pages : 42 >> Date : 2009-06-11 >> >> This document defines a standard mechanism for capturing the >> history >> information associated with a Session Initiation Protocol >> (SIP) request. >> This capability enables many enhanced services by providing >> =20 > the > =20 >> information as to how and why a call arrives at a specific >> application >> or user. This document defines a new optional SIP header, >> History-Info, >> for capturing the history information in requests. >> >> A URL for this Internet-Draft is: >> >> =20 > http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01 > .t > =20 >> xt >> =20 >> > 0 >> 1.t%0Axt> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail >> =20 > reader > =20 >> implementation to automatically retrieve the ASCII version of >> =20 > the > =20 >> Internet-Draft. >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> >> =20 From AUDET@nortel.com Fri Jun 12 15:22:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11FF33A6A66 for ; Fri, 12 Jun 2009 15:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVatjK-ZH-JP for ; Fri, 12 Jun 2009 15:22:05 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 36AF83A68C1 for ; Fri, 12 Jun 2009 15:22:04 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5CMM7E14895; Fri, 12 Jun 2009 22:22:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 12 Jun 2009 17:21:04 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E7D872F@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A32A789.9040802@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnrkR5rvPrnX2dLTFO0q8g5OfLUCgAGjD4w References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <4A32A789.9040802@gmail.com> From: "Francois Audet" To: "Hans Erik van Elburg" Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 22:22:06 -0000 =20 > It is clear that a service or tollfree address if expressed=20 > as a SIP URI is always delivered to the domain that is=20 > expressed in the home part. Yes, we agree on this. > Such service is therefore responsible for that domain. If it=20 > forwards the request to an AOR of another domain, but knows=20 > that this is the same addressed target. Then it can tag the=20 > hi-entry accordingly. This knowledge is inherently linked to=20 > the service being provided, so this can be very reliably=20 > decided by this specific proxy. I don't believe we will get agreement on this point. If I send a request to sip:dude@example.com, and example forwards it to sip:foobar@yoyo.net, I do not think it is reasonable to expect that example.com can assert that sip:dude@example.com and = sip:foobar@yoyo.net are in aliases. This is very different from example.com knowing that = sip:+14085551212@example.com and sip:super.dude@example.com are aliases of sip:dude@example.com. That is the core of the argument. From christer.holmberg@ericsson.com Sat Jun 13 00:42:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C26A3A6AA5 for ; Sat, 13 Jun 2009 00:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.606 X-Spam-Level: X-Spam-Status: No, score=-4.606 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRWu1ZGEvulU for ; Sat, 13 Jun 2009 00:42:34 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 942973A69B1 for ; Sat, 13 Jun 2009 00:42:33 -0700 (PDT) X-AuditID: c1b4fb3e-b7bedae0000062bb-25-4a335870025f Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 21.7D.25275.078533A4; Sat, 13 Jun 2009 09:42:40 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Jun 2009 09:42:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Jun 2009 09:42:40 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E7D828B@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwABgxmCAAFTBxQAAcDIJQ References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D828B@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , "DOLLY, MARTIN C, ATTLABS" , "Mary Barnes" , X-OriginalArrivalTime: 13 Jun 2009 07:42:40.0273 (UTC) FILETIME=[87660010:01C9EBFA] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 07:42:35 -0000 Hi,=20 >This is a lame way to describe the problem without describing what a = service number is. So, maybe we need to agree on that first. We DO have a requirement to = support it, but it is difficult to support it if we don't know what it = is... >Also, it is completely innacurate.=20 So, please correct me. Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Friday, June 12, 2009 01:13 > To: DOLLY, MARTIN C, ATTLABS; Barnes, Mary (RICH2:AR00);=20 > sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi, >=20 > The biggest difference is regarding support of service-number (like=20 > toll-free/freephone) type-of services, where the Request-URI=20 > translation does not change the targeted user or resource. Without=20 > going in to the protocol differences (which aren't that big), my=20 > understanding of the functional differences are the following: >=20 > - 4244bis approach does not distinguish between service-number (like=20 > toll-free/freephone) number translation and diversion. >=20 > - 4244bis approach does not allow a service-number (like > toll-free/freephone) translation for a user which belongs to another=20 > domain. >=20 > - 4244bis requires that all service-numbers for a user/company (like=20 > toll-free/freephone) must be registered (explicitly or implictly),=20 > which means that the translation must be done by an entity (normally=20 > the registrar) which has the registration information for the called=20 > user. >=20 >=20 > The target uri approach does allow translation in another domain, and=20 > does not require toll-free/freephone numbers to be registered for the=20 > called user. >=20 > So, I don't think that the 4244bis approach supports all=20 > service-numbers (like toll-free/freephone) in a sufficient way, and=20 > that it is too restrictive for no good reason. It imposes restrictions = > on the potential business models that are not necessary. >=20 > Regards, >=20 > Christer >=20 >=20 > > -----Original Message----- > > From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > > Sent: 11. kes=E4kuuta 2009 23:40 > > To: Christer Holmberg; Mary Barnes; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > Hello, > >=20 > > Can someone please summarize the differences between the two=20 > > approaches? > >=20 > > Thanks, > >=20 > > Martin > >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: Thursday, June 11, 2009 4:32 PM > > To: Christer Holmberg; Mary Barnes; sipcore@ietf.org > > Subject: Re: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Here is the link to the latest version of the target-uri draft: > >=20 > > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-de > > livery-00. > > txt > >=20 > > -----Original Message----- > > From: Christer Holmberg > > Sent: Thursday, June 11, 2009 11:31 PM > > To: 'Mary Barnes'; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > I think it is important to mention that there are still different=20 > > approaches regarding the target uri delivery, and that there is=20 > > another approach described in the latest version of the target-uri=20 > > delivery draft (I am not sure it appears in the archieves, > though, for > > some reason). Both approaches are based on History-Info, though. > >=20 > > We haven't yet been able to agree on an approach, so we thought the=20 > > best is to bring it to the list in order for other people to get=20 > > involved. > >=20 > > Regards, > >=20 > > Christer > >=20 > > =20 > >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > > Behalf Of Mary Barnes > > Sent: Thursday, June 11, 2009 9:05 PM > > To: sipcore@ietf.org > > Subject: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > Hi folks, > >=20 > > We have made a few changes to this document which was > submitted last > > week just to tie up some loose ends and inconsistencies, > some of which > > Shida identified when he reviewed the -00 version. > >=20 > > The following summarizes the high level changes in the=20 > > sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San > > Francisco: > > 1) Renamed the "retarget" parameter to "target" and defined > explicit > > tags to reflect the various mechanisms by which a Request is=20 > > retargeted. > > All entries are now tagged.=20 > > 2) Updated redirect server processing as the redirect server must=20 > > capture the "target" parameter since it is the entity that > knows the > > specific mechanism by which the new target has been determined. > > 3) Changed the privacy such that rather than removing > entries based on > > the various values of the privacy header, the entries are > recommended > > to be anonymized. > > 4) Updated security section > > 5) Updated examples to reflect the new parameter, use loose routing=20 > > and fix errors/nits. > > 6) Editorial changes to remove redundant text and the > convuluted text > > around optionality in the non-normative sections, which is now=20 > > discussed appropriately in the context of the histinfo option tag. > >=20 > > The detailed changes between the versions are summarized in the=20 > > document. > >=20 > > If you're wanting to look at a diff, I would recommend you diff=20 > > against RFC 4244 rather than the earlier 4244bis documents. > >=20 > > We'd really appreciate feedback on this approach to > precisely tagging > > all the entries. We believe it is comprehensive and should > suffice for > > all the use cases identified in the target-uri document, as well as=20 > > any others that might arise. > >=20 > > Thanks, > > Mary and Francois. > >=20 > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > > Internet-Drafts@ietf.org > > Sent: Thursday, June 11, 2009 12:45 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > >=20 > > Title : An Extension to the Session Initiation > > Protocol (SIP) for Request History Information > > Author(s) : M. Barnes, F. Audet > > Filename : draft-barnes-sipcore-rfc4244bis-01.txt > > Pages : 42 > > Date : 2009-06-11 > >=20 > > This document defines a standard mechanism for capturing > the history > > information associated with a Session Initiation Protocol > > (SIP) request. > > This capability enables many enhanced services by providing the=20 > > information as to how and why a call arrives at a specific > application > > or user. This document defines a new optional SIP header,=20 > > History-Info, for capturing the history information in requests. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc42 > > 44bis-01.t > > xt > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > > _______________________________________________ > > 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 >=20 From christer.holmberg@ericsson.com Sat Jun 13 00:49:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74BB93A6917 for ; Sat, 13 Jun 2009 00:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.674 X-Spam-Level: X-Spam-Status: No, score=-5.674 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdreeu9GN2k1 for ; Sat, 13 Jun 2009 00:49:15 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 497243A6892 for ; Sat, 13 Jun 2009 00:49:15 -0700 (PDT) X-AuditID: c1b4fb3c-b7bbdae0000049e3-10-4a335a02b8c6 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 5F.8D.18915.20A533A4; Sat, 13 Jun 2009 09:49:22 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Jun 2009 09:49:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Jun 2009 09:49:21 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E7D872F@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnrkR5rvPrnX2dLTFO0q8g5OfLUCgAGjD4wABPklIA= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <4A32A789.9040802@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D872F@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , "Hans Erik van Elburg" X-OriginalArrivalTime: 13 Jun 2009 07:49:22.0394 (UTC) FILETIME=[7714CBA0:01C9EBFB] X-Brightmail-Tracker: AAAAAA== Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 07:49:16 -0000 Hi,=20 >>It is clear that a service or tollfree address if expressed as a SIP URI is always delivered to the domain that is expressed in the home part. > >Yes, we agree on this. > >>Such service is therefore responsible for that domain. If it forwards=20 >>the request to an AOR of another domain, but knows that this is the=20 >>same addressed target. Then it can tag the hi-entry accordingly. This >>knowledge is inherently linked to the service being provided, so this=20 >>can be very reliably decided by this specific proxy. > >I don't believe we will get agreement on this point. > >If I send a request to sip:dude@example.com, and example forwards it to sip:foobar@yoyo.net, I do not think it is reasonable to expect that example.com can assert that sip:dude@example.com and=20 >sip:foobar@yoyo.net are in aliases. > >This is very different from example.com knowing that sip:+14085551212@example.com and sip:super.dude@example.com are aliases of sip:dude@example.com. > >That is the core of the argument. Yes. I also think we have different opinions on whether a service number has to be an alias (meaning that the service number is registered for the user). Regards, Christer From christer.holmberg@ericsson.com Sat Jun 13 01:06:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933883A69E1 for ; Sat, 13 Jun 2009 01:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.738 X-Spam-Level: X-Spam-Status: No, score=-5.738 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDyzhpJGYAcl for ; Sat, 13 Jun 2009 01:06:33 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2DD9A3A6892 for ; Sat, 13 Jun 2009 01:06:32 -0700 (PDT) X-AuditID: c1b4fb3e-b7bedae0000062bb-6c-4a335e10d6e4 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id E0.FD.25275.01E533A4; Sat, 13 Jun 2009 10:06:40 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Jun 2009 10:06:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Jun 2009 10:06:39 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHGKxoA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , "DOLLY, MARTIN C, ATTLABS" , "Mary Barnes" , X-OriginalArrivalTime: 13 Jun 2009 08:06:40.0370 (UTC) FILETIME=[E1C35D20:01C9EBFD] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 08:06:34 -0000 Hi,=20 >I'm going to spare details, but the main different is as follows. > >1) RFC 4244bis > >In RFC 4244bis, if the domain is responsible for the URI in the Request-URI and it replacing it with a Contact, it will put a reg-uri flag (if the Request-URI was the AOR used for registration), or reg- >uri-alias (if the Request-URI was an alias for the AOR used in registration). > >If the domain is responsible for the URI and it "maps" it to a different user, then it puts a "mapped" flag. > >If the domain is NOT responsible for the AOR but it changes the Request-URI nevertheless, then it is also marked as "mapped". > > Note: With loose routing, this is not supposed to happen=20 > (at least in theory). > >This next statement is where there is a big difference: > >If the domain is NOT responsible for the URI, the mapping cannot know if the new URI is belongs to the same User than the original one. This is why it is mapping: it is impossible for a proxy NOT=20 >responsible for a URI to change it to something else and "know" if it a different user (retarget) or just a "synonym" for the same user. We don't think it is "impossible", and we see no reason why we should make that restriction without any technical justification. The proxy does not change the URI just for fun, with a value out of the blue - it does it based on some kind of knowledge/configuration. >2) Target-UI > >In target-URI, there is an assumption that a domain NOT responsible for a URI can change the URI to something AND know authoritatively that the new target is a "synonym" for the original target. Correct.=20 And, I assume the difference between "synomym" and "alias" is that a synonym URI is not registered for the called user, right? But, one question for clarification: if the "synonym" translation is done by an entity which IS reponsible for the domain, how is it tagged? ------------- >So this is what it boils down to. I think that is more or less what I was trying to say. >Can a domain NOT responsible for a target change the target AND mark the new target authoritatively as "belonging" to the same user? > >In target-URI, the assumption is yes. > >In 4244bis, the assumption is no (only the domain responsible for the URI can do so).=20 Correct. ------------- >As pointed out by Paul Kyzivat, we probably need to think on how this works with Tel URIs. I think for Tel URI it would be totally different. Yes. You raised that also in our private discussions, but we never discussed it in details. So, before we start discussing the protocol details, I think we need to solve the issues above.=20 Regards, Christer From christer.holmberg@ericsson.com Sat Jun 13 01:19:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD1E3A6838 for ; Sat, 13 Jun 2009 01:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.639 X-Spam-Level: X-Spam-Status: No, score=-4.639 tagged_above=-999 required=5 tests=[AWL=-0.690, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_DELIVY=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIMK+MYh8KY1 for ; Sat, 13 Jun 2009 01:19:58 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9DF2D3A657C for ; Sat, 13 Jun 2009 01:19:57 -0700 (PDT) X-AuditID: c1b4fb3c-b7bbdae0000049e3-21-4a3361340016 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 07.4E.18915.431633A4; Sat, 13 Jun 2009 10:20:04 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Jun 2009 10:20:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Jun 2009 10:20:04 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E78801F@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What is a service number (was RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAQbmAABQZkXAAEAyU8AAAH2HwAABz1WAAAL04sAAlN06w References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787F33@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E78801F@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Mary Barnes" , X-OriginalArrivalTime: 13 Jun 2009 08:20:04.0594 (UTC) FILETIME=[C11E3520:01C9EBFF] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] What is a service number (was RE: FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 08:20:00 -0000 Hi,=20 >I think we're entirely clear on the types of services that need to be = supported. Yes, we seem to agree we need to support service numbers. However, we = seem to have different opinions on what a service number is. 1. Does a service number has to be an alias? 2. Can the service number translation be done by "another" domain? >It is the mechanism that we're debating. And by mechanism, I mean how = information that is meaningful to services (at a UAS) is "lost" = information as a request is retargeted.=20 Yes, and if the service number is meaningful to the UAS it needs to know = what the service number was... Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, June 12, 2009 9:12 AM To: Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi,=20 >So, I am trying to figure out why we have the differences and have=20 >difficulty because I cannot understand how this solution is fitting=20 >with core SIP processing in section 16.5 in terms of determining=20 >Request targets and am confused about the double tagging. So, it is=20 >quite difficult to sift through the differences in the solution=20 >proposal if we are not starting from common ground in terms of how the=20 >hi-entries are added, etc. I think we should start from common ground on what functional = requirements we have... Regards, Christer > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Friday, June 12, 2009 8:58 AM > To: 'Christer Holmberg'; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hi Christer, >=20 > The problem I have is that it is very difficult to discern exactly how = > you all are proposing to tag the entities in terms of core RFC 3261=20 > functionality. Yes, we had a small thread of discussion amongst the=20 > authors with no conclusion, but Francois did put forth the exact=20 > changes proposed in RFC 4244.... >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, June 12, 2009 1:20 AM > To: Barnes, Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi Mary, >=20 > I will look at your comments more in detail later, but just to clarify = > one thing: >=20 > The idea - which you also are very aware about - IS to eventually put = > the normative target uri text into 4244bis. > The reason we haven't done that yet is because we couldn't agree on=20 > the approache, and therefor the decission was to keep one approach in=20 > the target uri draft for now, so that we have both approaches properly = > documented. >=20 > Regards. >=20 > Christer >=20 > =20 >=20 > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: 12. kes=E4kuuta 2009 0:13 > > To: Christer Holmberg; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > Christer, > >=20 > > I reviewed the updated target-uri draft and have a few > comments - well > > I reviewed the diff since there isn't a summary of changes in the > > document: > >=20 > > 1) I had a lot of difficulty picking out the normative > processing for > > History-Info in this document. Can you summarize the differences? > >=20 > > 2) The reason I'm concerned about understanding how this > fits with the > > current normative processing is because I'm not seeing > precisely when > > these tags are added as the terminology is different than > that used in > > RFC 4244 - i.e., are these two terms equivalent: > > RFC 4244: > > "... hi-entry received in the request being forwarded." > >=20 > > target-uri: > > "...hi-entry recording the incoming request URI." > >=20 > > There is no reference in terms of current History-Info > processing as > > to when in the request processing these tags are added. > >=20 > > 3) In particular, I'm having difficulty with this text in > section 6: =20 > > "When a home proxy receives a request for a user or resource for=20 > > which > > is abstract location function returns registered contacts or > > configured URIs, the proxy adds two History-Info header field=20 > > values. > > The first is the incoming request URI. Since the Request-URI > > identifies a user or resource for which it has a registration or > > configuration, the Request-URI is an AOR and thus an address for=20 > > the > > user. The proxy adds a History-Info header field > parameter, "aor", > > which indicates this. Next, the proxy inserts the contact URI=20 > > which > > will be contained in the outgoing Request-URI." > > Currently, in RFC 4244, the proxy only adds that additional > > (first) hi-entry IF there wasn't one in the incoming request, since=20 > > the UAC can initially add one when it builds the request. > So, this is > > inconsistent with current RFC 4244. And, I think you need to define=20 > > "home" proxy - that's not an RFC > > 3261 term - there is the concept of a "home" domain.=20 > >=20 > > 4) There is a bug in the Syntax (section 9) - the Index is not=20 > > optional (that is an error we have fixed in the 4244bis). > >=20 > > 5) I'm really confused about this two-stage tagging - how does that=20 > > happen in the context of the determination of Request Targets in=20 > > section > > 16.5 of RFC3261? Wouldn't the decisions as to the addition > of the two > > different tags occur at the same time and thus what is the > advantage > > of the defining the two tags - i.e., why not one tag for each=20 > > combination? > > Also, are you proposing that the addition of the tags be > mandatory - > > there is no normative language in the target-uri document, so it's=20 > > impossible to tell. And, if you are proposing they be > mandatory, your > > ABNF syntax needs to reflect that, thus defining a single parameter=20 > > with multiple values would be necessary (which is the approach in=20 > > 4244bis). > >=20 > >=20 > > 6) What is the difference (or is there a difference?) between the=20 > > functionality associated with the tags in 4244bis and the > tags defined > > in this document in terms of types of retargets that are > being tagged? > > I think this is the crux of what we need to agree - i.e., > why aren't > > the 4244bis tags sufficient? If there is no logical difference and=20 > > it's just the words used to define the tags, then we're > very close to > > agreement. > >=20 > > Regards, > > Mary.=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Thursday, June 11, 2009 3:32 PM > > To: Christer Holmberg; Barnes, Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Here is the link to the latest version of the target-uri draft: > >=20 > > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-de > livery-00. > > txt > >=20 > > -----Original Message----- > > From: Christer Holmberg > > Sent: Thursday, June 11, 2009 11:31 PM > > To: 'Mary Barnes'; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > I think it is important to mention that there are still different=20 > > approaches regarding the target uri delivery, and that there is=20 > > another approach described in the latest version of the target-uri=20 > > delivery draft (I am not sure it appears in the archieves, > though, for > > some reason). Both approaches are based on History-Info, though. > >=20 > > We haven't yet been able to agree on an approach, so we thought the=20 > > best is to bring it to the list in order for other people to get=20 > > involved. > >=20 > > Regards, > >=20 > > Christer > >=20 > > =20 > >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > > Behalf Of Mary Barnes > > Sent: Thursday, June 11, 2009 9:05 PM > > To: sipcore@ietf.org > > Subject: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > Hi folks, > >=20 > > We have made a few changes to this document which was > submitted last > > week just to tie up some loose ends and inconsistencies, > some of which > > Shida identified when he reviewed the -00 version. > >=20 > > The following summarizes the high level changes in the=20 > > sipcore-rfc4244bis from the sip-rfc4244bis that we discussed in San > > Francisco: > > 1) Renamed the "retarget" parameter to "target" and defined > explicit > > tags to reflect the various mechanisms by which a Request is=20 > > retargeted. > > All entries are now tagged.=20 > > 2) Updated redirect server processing as the redirect server must=20 > > capture the "target" parameter since it is the entity that > knows the > > specific mechanism by which the new target has been determined. > > 3) Changed the privacy such that rather than removing > entries based on > > the various values of the privacy header, the entries are > recommended > > to be anonymized. > > 4) Updated security section > > 5) Updated examples to reflect the new parameter, use loose routing=20 > > and fix errors/nits. > > 6) Editorial changes to remove redundant text and the > convuluted text > > around optionality in the non-normative sections, which is now=20 > > discussed appropriately in the context of the histinfo option tag. > >=20 > > The detailed changes between the versions are summarized in the=20 > > document. > >=20 > > If you're wanting to look at a diff, I would recommend you diff=20 > > against RFC 4244 rather than the earlier 4244bis documents. > >=20 > > We'd really appreciate feedback on this approach to > precisely tagging > > all the entries. We believe it is comprehensive and should > suffice for > > all the use cases identified in the target-uri document, as well as=20 > > any others that might arise. > >=20 > > Thanks, > > Mary and Francois. > >=20 > > -----Original Message----- > > From: i-d-announce-bounces@ietf.org > > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > > Internet-Drafts@ietf.org > > Sent: Thursday, June 11, 2009 12:45 PM > > To: i-d-announce@ietf.org > > Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > > directories. > >=20 > > Title : An Extension to the Session Initiation > > Protocol (SIP) for Request History Information > > Author(s) : M. Barnes, F. Audet > > Filename : draft-barnes-sipcore-rfc4244bis-01.txt > > Pages : 42 > > Date : 2009-06-11 > >=20 > > This document defines a standard mechanism for capturing > the history > > information associated with a Session Initiation Protocol > > (SIP) request. > > This capability enables many enhanced services by providing the=20 > > information as to how and why a call arrives at a specific > application > > or user. This document defines a new optional SIP header,=20 > > History-Info, for capturing the history information in requests. > >=20 > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc42 > 44bis-01.t > > xt > >=20 > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > >=20 > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the=20 > > Internet-Draft. > >=20 >=20 From christer.holmberg@ericsson.com Sat Jun 13 01:21:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C4DF3A6930 for ; Sat, 13 Jun 2009 01:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.726 X-Spam-Level: X-Spam-Status: No, score=-5.726 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2n64R+xTjsG for ; Sat, 13 Jun 2009 01:21:42 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 1A3EE3A6838 for ; Sat, 13 Jun 2009 01:21:41 -0700 (PDT) X-AuditID: c1b4fb3c-b7bbdae0000049e3-95-4a33619d9173 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id EE.4E.18915.D91633A4; Sat, 13 Jun 2009 10:21:49 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 13 Jun 2009 10:21:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Jun 2009 10:21:48 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4A== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , "DOLLY, MARTIN C, ATTLABS" , "Mary Barnes" , X-OriginalArrivalTime: 13 Jun 2009 08:21:48.0932 (UTC) FILETIME=[FF4EEC40:01C9EBFF] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 08:21:43 -0000 Hi,=20 >1) RFC 4244bis > >In RFC 4244bis, if the domain is responsible for the URI in the Request-URI and it replacing it with a Contact, it will put a reg-uri flag (if the Request-URI was the AOR used for registration), or reg- >uri-alias (if the Request-URI was an alias for the AOR used in registration). And if the Request-URI was a "synonym" for the AOR? Regards, Christer From dean.willis@softarmor.com Sat Jun 13 11:48:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 958393A6948 for ; Sat, 13 Jun 2009 11:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poP00aqBwZWE for ; Sat, 13 Jun 2009 11:48:24 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D63413A6840 for ; Sat, 13 Jun 2009 11:48:24 -0700 (PDT) Received: from [192.168.2.2] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n5DImSZv006323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Jun 2009 13:48:30 -0500 Message-ID: <4A33F477.3030901@softarmor.com> Date: Sat, 13 Jun 2009 13:48:23 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A3227D2.4020808@ericsson.com> In-Reply-To: <4A3227D2.4020808@ericsson.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Milestone to revise RFC 3265 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 18:48:25 -0000 Gonzalo Camarillo wrote: > Folks, > > since the publication of RFC 3265, we have gotten significant experience > deploying SIP-based notification systems. It has been proposed to revise > RFC 3265 based on that experience. We have two questions for the WG: > > 1) should we add a milestone to our charter to revise RFC 3265? > > 2) if we add such a milestone, should we take the following draft as the > initial WG item for the milestone? > > http://tools.ietf.org/html/draft-roach-sipcore-rfc3265bis-00 > I believe that RFC 3265 should be revised, and that SIPCORE is the right place to do it. Of course, I feel the same about 3261, 3262, 3263... Adam's draft seems like a very good start. -- Dean From dean.willis@softarmor.com Sat Jun 13 11:51:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A57673A6948 for ; Sat, 13 Jun 2009 11:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlHJ3oiYnFYt for ; Sat, 13 Jun 2009 11:51:21 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D325F3A6840 for ; Sat, 13 Jun 2009 11:51:21 -0700 (PDT) Received: from [192.168.2.2] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n5DIpG7w006383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 Jun 2009 13:51:18 -0500 Message-ID: <4A33F51F.7070405@softarmor.com> Date: Sat, 13 Jun 2009 13:51:11 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Byron Campen References: <109101c9eae2$f8ef9890$eacec9b0$@net> <1EF42B19-CB00-48C3-9EF7-F15A36AE5CF7@estacado.net> <1244821160.3768.13.camel@victoria-pingtel-com.us.nortel.com> <85ED2F6F-EBAC-454D-858B-D3BFAF901CCA@estacado.net> In-Reply-To: <85ED2F6F-EBAC-454D-858B-D3BFAF901CCA@estacado.net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org, Dale Worley Subject: Re: [sipcore] [Sipping] draft-niemi-sipcore-event-rate-control-00 and forcing notifications when state has not changed X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 18:51:22 -0000 Byron Campen wrote: > Indeed, this could be done with etag, and using etag is a far more > efficient mechanism, because you are not gratuitously sending > (potentially very large) documents. My main beef is that this shifts the > job of maintaining soft-state to the server. As a general principle, > this has been the client's job, and this is specifically how SIP events > is supposed to work. Allowing the client to say, "Nah, you're going to > handle recovery now." is a rather fundamental change to the protocol, > that we should only make if there is a compelling reason. I see no such > reason. > I find this argument compelling. It might even be worth expounding on this general concept in rfrc265bis. -- Dean From pkyzivat@cisco.com Sat Jun 13 13:23:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 629843A6C6B for ; Sat, 13 Jun 2009 13:23:40 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frnoIksaeUVb for ; Sat, 13 Jun 2009 13:23:39 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id EC6FF3A6B61 for ; Sat, 13 Jun 2009 13:23:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,215,1243814400"; d="scan'208";a="47263383" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Jun 2009 20:23:47 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5DKNl51020676; Sat, 13 Jun 2009 16:23:47 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5DKNlbV007765; Sat, 13 Jun 2009 20:23:47 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 13 Jun 2009 16:23:47 -0400 Received: from [10.86.254.99] ([10.86.254.99]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 13 Jun 2009 16:23:46 -0400 Message-ID: <4A340ACE.1070803@cisco.com> Date: Sat, 13 Jun 2009 16:23:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jun 2009 20:23:46.0723 (UTC) FILETIME=[DAB94730:01C9EC64] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3826; t=1244924627; x=1245788627; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20The=20functional=20differen ces=20between=204244bis=20and=20target-=0A=20uri=20(was=20FW =3A=20I-D=20Action=3Adraft-barnes-sipcore-rfc4244bis-01.txt) |Sender:=20 |To:=20Christer=20Holmberg=20; bh=jMLNpkJ0vrOi67kDu3fjrJzKhTZdw23sLA9PyCsm+P0=; b=UPt+BEIn0dHGmk+ioh/AzZjmsku+v+D9XqoZz2SK2OPEVnOWTzYRPnlNRf TH5EClyT47V3J08HPZqBaJooUsLFS0cijrlZ+ykwiTMIbZf9LRBA8MLIMt8s yw26VrnMWE; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 20:23:40 -0000 This thing about the freephone services is an ugly one. I've thought for a long time that the mechanism is an entirely brain dead way to designate who should pay for a call. But it is what it is, so I guess we have to cope with it. I wonder if perhaps this is really one of the few circumstances where the recipient of a call ought to make call handling decisions based on the To-uri. The reason I say this is because the "contract" with these numbers is that the caller expects the call will be free based on the form of the number being called. And if the caller is wrong, it is the caller who gets charged. So, while I generally recommend that the To-uri be used for *nothing*, it might be right here. If so, then the whole target-uri/h-i discussion may be irrelevant to it. Thanks, Paul Christer Holmberg wrote: > Hi, > >> I'm going to spare details, but the main different is as follows. >> >> 1) RFC 4244bis >> >> In RFC 4244bis, if the domain is responsible for the URI in the > Request-URI and it replacing it with a Contact, it will put a reg-uri > flag (if the Request-URI was the AOR used for registration), or reg- >> uri-alias (if the Request-URI was an alias for the AOR used in > registration). >> If the domain is responsible for the URI and it "maps" it to a > different user, then it puts a "mapped" flag. >> If the domain is NOT responsible for the AOR but it changes the > Request-URI nevertheless, then it is also marked as "mapped". >> Note: With loose routing, this is not supposed to happen >> (at least in theory). >> >> This next statement is where there is a big difference: >> >> If the domain is NOT responsible for the URI, the mapping cannot know > if the new URI is belongs to the same User than the original one. This > is why it is mapping: it is impossible for a proxy NOT >> responsible for a URI to change it to something else and "know" if it a > different user (retarget) or just a "synonym" for the same user. > > We don't think it is "impossible", and we see no reason why we should > make that restriction without any technical justification. The proxy > does not change the URI just for fun, with a value out of the blue - it > does it based on some kind of knowledge/configuration. > >> 2) Target-UI >> >> In target-URI, there is an assumption that a domain NOT responsible for > a URI can change the URI to something AND know authoritatively that the > new target is a "synonym" for the original target. > > Correct. > > And, I assume the difference between "synomym" and "alias" is that a > synonym URI is not registered for the called user, right? > > But, one question for clarification: if the "synonym" translation is > done by an entity which IS reponsible for the domain, how is it tagged? > > ------------- > >> So this is what it boils down to. > > I think that is more or less what I was trying to say. > >> Can a domain NOT responsible for a target change the target AND mark > the new target authoritatively as "belonging" to the same user? >> In target-URI, the assumption is yes. >> >> In 4244bis, the assumption is no (only the domain responsible for the > URI can do so). > > Correct. > > ------------- > >> As pointed out by Paul Kyzivat, we probably need to think on how this > works with Tel URIs. I think for Tel URI it would be totally different. > > Yes. You raised that also in our private discussions, but we never > discussed it in details. > > So, before we start discussing the protocol details, I think we need to > solve the issues above. > > > Regards, > > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Sat Jun 13 13:39:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D58593A6C51 for ; Sat, 13 Jun 2009 13:39:30 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nb7e7xf4ijZk for ; Sat, 13 Jun 2009 13:39:29 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B893C3A6B61 for ; Sat, 13 Jun 2009 13:39:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,215,1243814400"; d="scan'208";a="47263959" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Jun 2009 20:39:38 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5DKdcQd023876; Sat, 13 Jun 2009 16:39:38 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5DKdcaT007490; Sat, 13 Jun 2009 20:39:38 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 13 Jun 2009 16:39:38 -0400 Received: from [10.86.254.99] ([10.86.254.99]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 13 Jun 2009 16:39:37 -0400 Message-ID: <4A340E82.7090207@cisco.com> Date: Sat, 13 Jun 2009 16:39:30 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dean Willis References: <109101c9eae2$f8ef9890$eacec9b0$@net> <1EF42B19-CB00-48C3-9EF7-F15A36AE5CF7@estacado.net> <1244821160.3768.13.camel@victoria-pingtel-com.us.nortel.com> <85ED2F6F-EBAC-454D-858B-D3BFAF901CCA@estacado.net> <4A33F51F.7070405@softarmor.com> In-Reply-To: <4A33F51F.7070405@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jun 2009 20:39:37.0795 (UTC) FILETIME=[119B5930:01C9EC67] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1350; t=1244925578; x=1245789578; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20[Sipping]=20draft-niemi-sip core-event-rate-control-00=0A=20and=20forcing=09notification s=20when=20state=20has=20not=20changed |Sender:=20 |To:=20Dean=20Willis=20; bh=YYKok/O+KSh5HArUtQkZ6ewNun7EdCfw5twQQU4cj/A=; b=UU6bcSMVmHcAq4T2q8NVK8uFzq16p/Q/oi5vBkG1zM2U4hei9/n6edftu1 Ea8kctHjppUxbsW7OJxxN0ekMN3fg1pl1F7WXHowqkUTuKGOS7/MvKYqr4mz u/gTnVaMVD; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sipcore@ietf.org, Byron Campen , Dale Worley Subject: Re: [sipcore] [Sipping] draft-niemi-sipcore-event-rate-control-00 and forcing notifications when state has not changed X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 20:39:30 -0000 I definitely agree with this as an argument against using rate limiting as a form of "session-timer for subscriptions". I never had the sense that the minimum rate "limit" was being proposed for that purpose. (I have never been able to make any sense for why that was being proposed, but I just decided there was no point in arguing against it just because it made no sense.) Thanks, Paul Dean Willis wrote: > Byron Campen wrote: > >> Indeed, this could be done with etag, and using etag is a far more >> efficient mechanism, because you are not gratuitously sending >> (potentially very large) documents. My main beef is that this shifts the >> job of maintaining soft-state to the server. As a general principle, >> this has been the client's job, and this is specifically how SIP events >> is supposed to work. Allowing the client to say, "Nah, you're going to >> handle recovery now." is a rather fundamental change to the protocol, >> that we should only make if there is a compelling reason. I see no such >> reason. >> > > I find this argument compelling. It might even be worth expounding on > this general concept in rfrc265bis. > > -- > Dean > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From ietf.hanserik@gmail.com Sat Jun 13 13:54:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC30F3A6C00 for ; Sat, 13 Jun 2009 13:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssK5eQ4g9xe8 for ; Sat, 13 Jun 2009 13:54:17 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id AF8AE3A683A for ; Sat, 13 Jun 2009 13:54:16 -0700 (PDT) Received: by ewy6 with SMTP id 6so3941744ewy.37 for ; Sat, 13 Jun 2009 13:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+qZSSbwnycKuWZkj/YAgLC5Dj21HivSD9LClnAH9wlo=; b=VY6XJV1mx0Vgvo9jLUmjQVtUZpF+/2kl8WMh/pZBrFuhL3fXoklZqs5fsZqkX6Eac1 uc9bLc40zioDFb+2G5YXSVVeT3HSn7ZCFcfiXSi3lh1FYwfp1vgLjy+z92UQaUsTDwbO qKfkB7HwRU8CUcwEB0uxTgJNcv5iHJ0f1+ntc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=CTyppUbp+ufY+0F07yjVTD5MxSsBZWkHlx7qi6OYgeDj25djOknyUEPI97P3F1G/0M RyojVd9n0bsdhcZ2LT2W/IoTa+WiJ6/g5zKjHghcOfucwHxaNEPkEorg4pyPiIqjgIh2 8BIFCPEKKS9CXynpCo1slxbHQ+I1VdcczB2Bk= Received: by 10.210.60.8 with SMTP id i8mr5205480eba.28.1244926462924; Sat, 13 Jun 2009 13:54:22 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 10sm2788031eyd.22.2009.06.13.13.54.21 (version=SSLv3 cipher=RC4-MD5); Sat, 13 Jun 2009 13:54:22 -0700 (PDT) Message-ID: <4A3411FF.30005@gmail.com> Date: Sat, 13 Jun 2009 22:54:23 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Mary Barnes References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120138y540f7c2bja62adcf942cba3a0@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E787F80@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120824s24f0ddfyb9dc6d6c38651d75@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D809A@zrc2hxm0.corp.nortel.com> <4A32B08C.4010308@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D8536@zrc2hxm0.corp.nortel.com> <4A32C2EB.7070304@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D86CF@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E7D86CF@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 20:54:19 -0000 Already 4.3.3.1 must be clarified as it says that the proxy must add a hi-entry, but it does not specify what value should be added. Further all this text seems to be written backwards instead of in logical order, which makes it very hard to understand or modify. So why dont we rewrite 4.3.3.1 something like: .3.3.1. Adding the History-Info Header to Requests RFC3261 Section 16.6 describes the procedure executed for each target in the target set, this specification extends that procedure as follows. A proxy conforming to this specification MUST perform the following steps between Step 8 and Step 9 as specified in Section 16.6 of [RFC3261] for each target separately : 1. If a request is received that doesn't include a History-Info header, a proxy conforming to this specification MUST add a History-Info header with a hi-entry with the value of Request-URI from the received request. The index for this hi-entry MUST start at 1. The attributes MUST be set according to the procedure as specified in 4.3.3.1.X. 2. If the incoming request already contains a History-Info header field, and the last hi-entry is not identical to the Request-URI of the received request, MUST add a History-Info header with a hi-entry with the value of Request-URI from the received request. The index for this hi-entry MUST follow the rules specified in 4.3.3.1.3. The attributes MUST be set according to the procedure as specified in 4.3.3.1.X. 3. A proxy conforming to this specification MUST add a hi-entry with the value of the target as it forwards a Request. It is not clear why currently step 2 is somewhere hidden in 4.3.3.1.4. I also think step 1 and 2 should be mandatory evaluated. The current text for step 1 is at MAY strength. If we could agree to rewrite 4.3.3.1 like this it would be much easier to hook in different attribute setting behaviours, even if in the future someone sees the need for a new attribute and writes a separate draft for extending the mechanism. /Hans Erik Mary Barnes wrote: > Hi Hans, > > I think we're making progress - I understand why you do not understand > this. We likely need to add some more text to make this clear. The way > History-Info works now is that the tags are added to the previous/last > hi-entry (i.e., the one in the incoming request) at the point in time > that the request is being forwarded. This is what's described in section > 4.3.3.1. > > This means that the proxy needs to keep track of the hi-target that > would be applied to that previous/last hi-entry for each target in the > target list it builds per section 16.5. Then, as the proxy forwards > the request as described in section 4.3.3.1, the proxy has the > information as to how to appropriately tag that previous/last hi-entry. > That's the only way it will work. But, yes, this is confusing in that > section 4.3.3.1.4 is discussing how the information that is used when > the request is forwarded is derived. > > So, I will add some text to clarify this in the next update to 4244bis, > I should reword that first paragraph in section 4.3.3.1.4 as follows: > OLD: > An hi-target attribute MUST be included in a request forwarded by a > proxy. The addition of the hi-target parameter MUST occur prior to > the forwarding of the request (which may add a new hi-entry with a > new hi-targeted-to- uri) as it is associated with the hi-targeted-to- > uri that has been retargeted. > > NEW: > An hi-target attribute MUST be included in a request forwarded by a > proxy. The addition of the hi-target parameter MUST occur just prior > to > the forwarding of the request (which may add a new hi-entry with a > new hi-targeted-to- uri) as it is associated with the hi-targeted-to- > uri that has been retargeted. > The value for the hi-target attribute is determined by the proxy when > it builds > the target list as described in section 16.5 of [RFC3261]. The > subsequent paragraphs > describe the processing relevant to section 16.5 for determining the > value of the > hi-target attribute that is associated with a specific target to > which a request > is to be forwarded and the value to which the hi-target parameter > MUST be set when > the request is forwarded. > > > Thanks, > Mary. > > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Friday, June 12, 2009 4:05 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > I'm trying to do it similarly 4.3.3.1.4/[4424bis], but I do not > understand how this text works for the forked case. > > Because for different forks the hi-entry representing the retargeted > R-URI could get another tag. The current text does not seem to cover > this aspect. > > How is this intended to be covered by this text? > > /Hans Erik > > Mary Barnes wrote: > >> Hi Hans, >> >> Just a few comments below [MB]. >> >> Thanks, >> Mary. >> >> -----Original Message----- >> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> Sent: Friday, June 12, 2009 2:46 PM >> To: Barnes, Mary (RICH2:AR00) >> Cc: Christer Holmberg; sipcore@ietf.org >> Subject: Re: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Hi Mary, >> >> >> >>> So, it's just not clear at all to me how you coordinate the addition >>> >>> >> of the two tags. Perhaps, it's just how that section is written, >> >> >>> but again, this is my point that it's really difficult to understand >>> >>> >> your solution proposal when it is not described in the context of >> >> >>> the current normative RFC 4244 functionality. >>> >>> >> The text can definitely be improved, but still the criteria for adding >> > > >> the tags are independent. >> >> I will try draft a chapter as it would look like in 4424. >> [MB] Yes, it would help to understand this in the context of 16.5 >> where you are determining the targets for the request as I can't quite >> > > >> see how the determination of the tags are independent. And, I say >> determination because as is, you don't add the tag until you are >> forwarding the request per section 16.6. The exception is the case of >> > > >> a 3xx and the redirect server has added the tag - at least per the >> 4244bis specification of redirect server and 3xx handling, which is >> actually something else missing in target-uri as this does introduce a >> > > >> somewhat special case now that we are adding this level of granularity >> > > >> in terms of the mechanism by which the target(s) are determined. [/MB] >> >> >> >> >>> This solution also does not seem to give clear delineation between >>> >>> >> registered contacts versus configured URIs. I had understood > that to >> > > >> be important for some services. In particular, how will this solution >> support being able to identify aliases? >> >> Regarding the alias concept, I have no problems in adding that. But it >> > > >> is currently not in scope of the target-uri work, if people agree then >> > > >> we can add that requirement. We could reuse the definition that is >> contained in the 4424bis draft as I think that is a good definition. >> [MB] I'm puzzled as aliases are identified as a service to be >> supported by target-uri in section 4.1. That's the exact use case that >> > > >> the "reg-uri-alias" tag in 4244bis will support. [/MB] >> >> But what is the essential difference between bindings that came about >> due to registration and those that are configured? (To me this has >> nothing todo with aliases, in fact I think it is not a meaningful >> difference how the binding was made.) But if you have a requirement >> for that, you should maybe explain it. >> [MB] I'm not sure we're using the term configured in the same context >> here as I think you are really talking about the entries that are >> tagged as "mapped" in 4244bis. The alias concept actually uses both >> registration and configuration - that's why it's really a separate >> mechanism by which targets are determined. This is clearly defined in >> 4244bis in the description of the "reg-uri-alias" tag. [/MB] >> >> >> /Hans Erik >> >> Mary Barnes wrote: >> >> >>> Hi Hans, >>> >>> My confusion comes from the 3rd paragraph in section 6 (the same one >>> that confuses in terms of the unconditional addition of two >>> hi-entries), specifically this text: >>> " When a home proxy receives a request for a user or resource for >>> >>> >> which >> >> >>> is abstract location function returns registered contacts or >>> configured URIs, the proxy adds two History-Info header field >>> >>> >> values. >> >> >>> The first is the incoming request URI. Since the Request-URI >>> identifies a user or resource for which it has a registration or >>> configuration, the Request-URI is an AOR and thus an address for >>> >>> >> the >> >> >>> user. The proxy adds a History-Info header field parameter, >>> > "aor", > >>> which indicates this. Next, the proxy inserts the contact URI >>> >>> >> which >> >> >>> will be contained in the outgoing Request-URI." >>> >>> (Note: this also confuses me because it is combining determining >>> request targets with the forwarding) >>> >>> But, then later in that section, there's the following text (7th >>> paragraph): >>> "When a proxy receives a request for a user or resource for which >>> > it > >>> is responsible, then when a request URI rewrite occurs that is a >>> routing translation, then add a History-Info header field >>> > parameter > >>> "routed" to the hi-entry recording the incoming request URI. >>> Otherwise when a request URI rewrite occurs that is a mapping >>> translation, then add a History-Info header field parameter >>> >>> >> "mapped" >> >> >>> to the hi-entry recording the incoming request URI. " >>> >>> So, it's just not clear at all to me how you coordinate the addition >>> of the two tags. Perhaps, it's just how that section is written, but >>> > > >>> again, this is my point that it's really difficult to understand your >>> > > >>> solution proposal when it is not described in the context of the >>> current normative RFC 4244 functionality. >>> >>> This solution also does not seem to give clear delineation between >>> registered contacts versus configured URIs. I had understood that to >>> be important for some services. In particular, how will this solution >>> > > >>> support being able to identify aliases? >>> >>> Thanks, >>> Mary. >>> >>> --------------------------------------------------------------------- >>> - >>> -- >>> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >>> *Sent:* Friday, June 12, 2009 10:24 AM >>> *To:* Barnes, Mary (RICH2:AR00) >>> *Cc:* Christer Holmberg; sipcore@ietf.org >>> *Subject:* Re: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> Hi Mary, >>> >>> I do not understand what you mean with multi stage. All the tagging >>> can be prepared at the time that the translation is done and added at >>> > > >>> the time that 4244 suggests the H-I to be added. If the current text >>> suggests otherwise, then we might need to fix that. >>> >>> BR, >>> /Hans Erik van Elburg >>> >>> >>> On Fri, Jun 12, 2009 at 4:11 PM, Mary Barnes >> > wrote: >>> >>> Hi Hans, >>> >>> A couple comments below [MB]. >>> >>> Mary. >>> >>> >>> >>> >> ---------------------------------------------------------------------- >> -- >> >> >>> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com >>> ] >>> *Sent:* Friday, June 12, 2009 3:38 AM >>> >>> *To:* Barnes, Mary (RICH2:AR00) >>> *Cc:* Christer Holmberg; sipcore@ietf.org >>> >>> >> >> >> >>> *Subject:* Re: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> Hi Mary, >>> >>> Sure when we agree on the way forward we have to resolve all >>> > these > >>> detailed procedures and conform to the 4244 language etc. But we >>> already agreed to integrate it into 4424bis at the moment that >>> there is agreement about the solution. >>> >>> Regarding the two tag approach that is open for discussion, i >>> think it is more clean and in general pays off to separate >>> concepts that are independent from each other. For example a >>> hi-entry may be routed and not be an AOR, whereas it may also be >>> routed and also an AOR. The decisions to be taken for additions >>> > of > >>> these tags are independent, so there is also no need to >>> > intertwine > >>> procedural text for them. (It is also more clear for >>> >>> >> implementors.) >> >> >>> [MB] This is where my major confusion is in that you say the tags >>> are independent, BUT where in the normative RFC 3261 processing >>> does this occur? I'm confused because the logic in section 16.5 >>> isn't "multi-stage" (for lack of a better term), the incoming >>> request URI is evaluated and then the new target list is >>> constructed The tagging in 4244 is based on the mechanism by >>> which a new target is determined . The previous hi-entry (that >>> > in > >>> the incoming request) is tagged at the point the request is being >>> forwarded. I do agree that in the internal processing that >>> information needs to exist so that the tagging at the point of >>> forwarding the request is appropriate. [/MB] >>> >>> >>> >>> BR, >>> /Hans Erik van Elburg >>> >>> On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes >>> > wrote: >>> >>> Christer, >>> >>> I reviewed the updated target-uri draft and have a few >>> comments - well I >>> reviewed the diff since there isn't a summary of changes in >>> >>> >> the >> >> >>> document: >>> >>> 1) I had a lot of difficulty picking out the normative >>> processing for >>> History-Info in this document. Can you summarize the >>> >>> >> differences? >> >> >>> 2) The reason I'm concerned about understanding how this fits >>> with the >>> current normative processing is because I'm not seeing >>> precisely when >>> these tags are added as the terminology is different than >>> > that > >>> used in >>> RFC 4244 - i.e., are these two terms equivalent: >>> RFC 4244: >>> "... hi-entry received in the request being forwarded." >>> >>> target-uri: >>> "...hi-entry recording the incoming request URI." >>> >>> There is no reference in terms of current History-Info >>> processing as to >>> when in the request processing these tags are added. >>> >>> 3) In particular, I'm having difficulty with this text in >>> section 6: >>> "When a home proxy receives a request for a user or >>> resource >>> >>> >> for >> >> >>> which >>> is abstract location function returns registered contacts >>> > or > >>> configured URIs, the proxy adds two History-Info header >>> field values. >>> The first is the incoming request URI. Since the >>> >>> >> Request-URI >> >> >>> identifies a user or resource for which it has a >>> >>> >> registration or >> >> >>> configuration, the Request-URI is an AOR and thus an >>> > address > >>> for the >>> user. The proxy adds a History-Info header field >>> > parameter, > >>> "aor", >>> which indicates this. Next, the proxy inserts the contact >>> URI which >>> will be contained in the outgoing Request-URI." >>> Currently, in RFC 4244, the proxy only adds that additional >>> (first) >>> hi-entry IF there wasn't one in the incoming request, since >>> the UAC can >>> initially add one when it builds the request. So, this is >>> inconsistent >>> with current RFC 4244. And, I think you need to define "home" >>> proxy - >>> that's not an RFC 3261 term - there is the concept of a >>> > "home" > >>> domain. >>> >>> 4) There is a bug in the Syntax (section 9) - the Index is >>> > not > >>> optional >>> (that is an error we have fixed in the 4244bis). >>> >>> 5) I'm really confused about this two-stage tagging - how >>> > does > >>> that >>> happen in the context of the determination of Request Targets >>> in section >>> 16.5 of RFC3261? Wouldn't the decisions as to the addition of >>> the two >>> different tags occur at the same time and thus what is the >>> advantage of >>> the defining the two tags - i.e., why not one tag for each >>> combination? >>> Also, are you proposing that the addition of the tags be >>> mandatory - >>> there is no normative language in the target-uri document, so >>> >>> >> it's >> >> >>> impossible to tell. And, if you are proposing they be >>> mandatory, your >>> ABNF syntax needs to reflect that, thus defining a single >>> parameter with >>> multiple values would be necessary (which is the approach in >>> 4244bis). >>> >>> >>> 6) What is the difference (or is there a difference?) between >>> >>> >> the >> >> >>> functionality associated with the tags in 4244bis and the >>> > tags > >>> defined >>> in this document in terms of types of retargets that are >>> > being > >>> tagged? >>> I think this is the crux of what we need to agree - i.e., why >>> aren't the >>> 4244bis tags sufficient? If there is no logical difference >>> and it's >>> just the words used to define the tags, then we're very close >>> >>> >> to >> >> >>> agreement. >>> >>> Regards, >>> Mary. >>> >>> >>> >>> -----Original Message----- >>> From: Christer Holmberg >>> > [mailto:christer.holmberg@ericsson.com > >>> ] >>> Sent: Thursday, June 11, 2009 3:32 PM >>> To: Christer Holmberg; Barnes, Mary (RICH2:AR00); >>> sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> >>> Here is the link to the latest version of the target-uri >>> >>> >> draft: >> >> >>> >>> > http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00. > >> >> >>> txt >>> >>> >> - >>> 00.%0Atxt> >>> >>> -----Original Message----- >>> From: Christer Holmberg >>> Sent: Thursday, June 11, 2009 11:31 PM >>> To: 'Mary Barnes'; sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> >>> Hi, >>> >>> I think it is important to mention that there are still >>> >>> >> different >> >> >>> approaches regarding the target uri delivery, and that there >>> is another >>> approach described in the latest version of the target-uri >>> delivery >>> draft (I am not sure it appears in the archieves, though, for >>> >>> >> some >> >> >>> reason). Both approaches are based on History-Info, though. >>> >>> We haven't yet been able to agree on an approach, so we >>> thought the best >>> is to bring it to the list in order for other people to get >>> involved. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org >>> >>> [mailto:sipcore-bounces@ietf.org >>> ] On >>> Behalf Of Mary Barnes >>> Sent: Thursday, June 11, 2009 9:05 PM >>> To: sipcore@ietf.org >>> Subject: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> Hi folks, >>> >>> We have made a few changes to this document which was >>> submitted last >>> week just to tie up some loose ends and inconsistencies, some >>> of which >>> Shida identified when he reviewed the -00 version. >>> >>> The following summarizes the high level changes in the >>> sipcore-rfc4244bis from the sip-rfc4244bis that we discussed >>> in San >>> Francisco: >>> 1) Renamed the "retarget" parameter to "target" and defined >>> explicit >>> tags to reflect the various mechanisms by which a Request is >>> retargeted. >>> All entries are now tagged. >>> 2) Updated redirect server processing as the redirect server >>> >>> >> must >> >> >>> capture the "target" parameter since it is the entity that >>> knows the >>> specific mechanism by which the new target has been >>> >>> >> determined. >> >> >>> 3) Changed the privacy such that rather than removing entries >>> based on >>> the various values of the privacy header, the entries are >>> recommended to >>> be anonymized. >>> 4) Updated security section >>> 5) Updated examples to reflect the new parameter, use loose >>> routing and >>> fix errors/nits. >>> 6) Editorial changes to remove redundant text and the >>> convuluted text >>> around optionality in the non-normative sections, which is >>> > now > >>> discussed >>> appropriately in the context of the histinfo option tag. >>> >>> The detailed changes between the versions are summarized in >>> >>> >> the >> >> >>> document. >>> >>> If you're wanting to look at a diff, I would recommend you >>> diff against >>> RFC 4244 rather than the earlier 4244bis documents. >>> >>> We'd really appreciate feedback on this approach to precisely >>> tagging >>> all the entries. We believe it is comprehensive and should >>> suffice for >>> all the use cases identified in the target-uri document, as >>> well as any >>> others that might arise. >>> >>> Thanks, >>> Mary and Francois. >>> >>> -----Original Message----- >>> From: i-d-announce-bounces@ietf.org >>> >>> [mailto:i-d-announce-bounces@ietf.org >>> ] On Behalf Of >>> Internet-Drafts@ietf.org >>> Sent: Thursday, June 11, 2009 12:45 PM >>> To: i-d-announce@ietf.org >>> Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> A New Internet-Draft is available from the on-line >>> >>> >> Internet-Drafts >> >> >>> directories. >>> >>> Title : An Extension to the Session >>> >>> >> Initiation >> >> >>> Protocol (SIP) for Request History Information >>> Author(s) : M. Barnes, F. Audet >>> Filename : >>> >>> >> draft-barnes-sipcore-rfc4244bis-01.txt >> >> >>> Pages : 42 >>> Date : 2009-06-11 >>> >>> This document defines a standard mechanism for capturing the >>> history >>> information associated with a Session Initiation Protocol >>> (SIP) request. >>> This capability enables many enhanced services by providing >>> >>> >> the >> >> >>> information as to how and why a call arrives at a specific >>> application >>> or user. This document defines a new optional SIP header, >>> History-Info, >>> for capturing the history information in requests. >>> >>> A URL for this Internet-Draft is: >>> >>> >>> >> http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01 >> .t >> >> >>> xt >>> >>> >> 0 >>> 1.t%0Axt> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail >>> >>> >> reader >> >> >>> implementation to automatically retrieve the ASCII version of >>> >>> >> the >> >> >>> Internet-Draft. >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >>> >>> >>> From ietf.hanserik@gmail.com Sat Jun 13 14:02:15 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B46E3A6A32 for ; Sat, 13 Jun 2009 14:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqH-HrNJgHlX for ; Sat, 13 Jun 2009 14:02:14 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 1AA453A683A for ; Sat, 13 Jun 2009 14:02:13 -0700 (PDT) Received: by ewy6 with SMTP id 6so3944851ewy.37 for ; Sat, 13 Jun 2009 14:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=93w2wCdZm/G0L0Z46MlGxzZ3Q9vYJCS6S59xA9B6wCA=; b=dgWwH/JX4/s5MfCTvd38ZOsSiXT7DgsUc4Om9B9kAR8dlPpeKY3wzShw/TDaq3gkws vW5zINNLqKApgnq8bM7e9daBgd1ElWt8QwbO/J84ZEBwTGDkxby1J+js35hLjvO6481x L6ra83RyeuPQ3GQi1MN9rRpF/MqxtaSrsV8lM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=dw0Mbxc73O74Cn77fIfBmpSnzL/9U6msT16TB/sU8CM1SfRurA7GQA9RTHZmsmIQS/ z4o2RDRkYcpuO6fOUnwWI7sMcKu+JM6fT/ZRfmO/R/OnqDwWwsoK1Ae3p0NAIpvT/0lT zd5TCDaY4oR/t+u/HFu+V6XABy+wetpeFrtrc= Received: by 10.210.28.4 with SMTP id b4mr5170197ebb.33.1244926940108; Sat, 13 Jun 2009 14:02:20 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 10sm399791eyz.11.2009.06.13.14.02.18 (version=SSLv3 cipher=RC4-MD5); Sat, 13 Jun 2009 14:02:19 -0700 (PDT) Message-ID: <4A3413DC.208@gmail.com> Date: Sat, 13 Jun 2009 23:02:20 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Paul Kyzivat References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <4A340ACE.1070803@cisco.com> In-Reply-To: <4A340ACE.1070803@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 21:02:15 -0000 Hi Paul, For what would you want to use the To-uri? /Hans Erik Paul Kyzivat wrote: > This thing about the freephone services is an ugly one. > I've thought for a long time that the mechanism is an entirely brain > dead way to designate who should pay for a call. > > But it is what it is, so I guess we have to cope with it. > > I wonder if perhaps this is really one of the few circumstances where > the recipient of a call ought to make call handling decisions based on > the To-uri. The reason I say this is because the "contract" with these > numbers is that the caller expects the call will be free based on the > form of the number being called. And if the caller is wrong, it is the > caller who gets charged. > > So, while I generally recommend that the To-uri be used for *nothing*, > it might be right here. If so, then the whole target-uri/h-i > discussion may be irrelevant to it. > > Thanks, > Paul > > Christer Holmberg wrote: >> Hi, >>> I'm going to spare details, but the main different is as follows. >>> >>> 1) RFC 4244bis >>> >>> In RFC 4244bis, if the domain is responsible for the URI in the >> Request-URI and it replacing it with a Contact, it will put a reg-uri >> flag (if the Request-URI was the AOR used for registration), or reg- >>> uri-alias (if the Request-URI was an alias for the AOR used in >> registration). >>> If the domain is responsible for the URI and it "maps" it to a >> different user, then it puts a "mapped" flag. >>> If the domain is NOT responsible for the AOR but it changes the >> Request-URI nevertheless, then it is also marked as "mapped". >>> Note: With loose routing, this is not supposed to happen (at >>> least in theory). >>> >>> This next statement is where there is a big difference: >>> >>> If the domain is NOT responsible for the URI, the mapping cannot know >> if the new URI is belongs to the same User than the original one. This >> is why it is mapping: it is impossible for a proxy NOT >>> responsible for a URI to change it to something else and "know" if it a >> different user (retarget) or just a "synonym" for the same user. >> >> We don't think it is "impossible", and we see no reason why we should >> make that restriction without any technical justification. The proxy >> does not change the URI just for fun, with a value out of the blue - it >> does it based on some kind of knowledge/configuration. >> >>> 2) Target-UI >>> >>> In target-URI, there is an assumption that a domain NOT responsible for >> a URI can change the URI to something AND know authoritatively that the >> new target is a "synonym" for the original target. >> >> Correct. >> And, I assume the difference between "synomym" and "alias" is that a >> synonym URI is not registered for the called user, right? >> >> But, one question for clarification: if the "synonym" translation is >> done by an entity which IS reponsible for the domain, how is it tagged? >> >> ------------- >> >>> So this is what it boils down to. >> >> I think that is more or less what I was trying to say. >> >>> Can a domain NOT responsible for a target change the target AND mark >> the new target authoritatively as "belonging" to the same user? >>> In target-URI, the assumption is yes. >>> >>> In 4244bis, the assumption is no (only the domain responsible for the >> URI can do so). >> Correct. >> >> ------------- >> >>> As pointed out by Paul Kyzivat, we probably need to think on how this >> works with Tel URIs. I think for Tel URI it would be totally different. >> >> Yes. You raised that also in our private discussions, but we never >> discussed it in details. >> >> So, before we start discussing the protocol details, I think we need to >> solve the issues above. >> >> Regards, >> >> Christer >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Sat Jun 13 14:34:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 579D43A67BD for ; Sat, 13 Jun 2009 14:34:42 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Bfhm+N06yxR for ; Sat, 13 Jun 2009 14:34:41 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 33CEE3A683A for ; Sat, 13 Jun 2009 14:34:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,215,1243814400"; d="scan'208";a="199479283" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 13 Jun 2009 21:34:50 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5DLYnro014149; Sat, 13 Jun 2009 17:34:49 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5DLYnSe016565; Sat, 13 Jun 2009 21:34:49 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 13 Jun 2009 17:34:49 -0400 Received: from [10.86.254.99] ([10.86.254.99]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 13 Jun 2009 17:34:49 -0400 Message-ID: <4A341B74.2070300@cisco.com> Date: Sat, 13 Jun 2009 17:34:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Hans Erik van Elburg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <4A340ACE.1070803@cisco.com> <4A3413DC.208@gmail.com> In-Reply-To: <4A3413DC.208@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jun 2009 21:34:49.0193 (UTC) FILETIME=[C75A9590:01C9EC6E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4499; t=1244928889; x=1245792889; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20The=20functional=20differen ces=20between=204244bis=20and=20target-=0A=20uri=20(was=20FW =3A=20I-D=20Action=3Adraft-barnes-sipcore-rfc4244bis-01.txt) |Sender:=20 |To:=20Hans=20Erik=20van=20Elburg=20; bh=sQz3YsvOTre3I/ijEH2ZlyFJ4MXTexfQy3Np8dOkU8w=; b=Ur0V9sT55EKFxVouD0Rd3rvUUjCm8igGMbglRZRKEYtXA+AAawHl8Qi7lC X8Y/7oAiQckhEU8gUxQ+BhzHwuuToqddKCboCnvO1NBGGbmAeiRvxj37YdiS Asz+dSTuEL; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2009 21:34:42 -0000 Hans Erik van Elburg wrote: > Hi Paul, > > For what would you want to use the To-uri? To decide who/what the caller desired to reach, and hence what treatment to give the call. This seems to be the key thing for the call centers that use freephone numbers. Thanks, Paul > /Hans Erik > > Paul Kyzivat wrote: >> This thing about the freephone services is an ugly one. >> I've thought for a long time that the mechanism is an entirely brain >> dead way to designate who should pay for a call. >> >> But it is what it is, so I guess we have to cope with it. >> >> I wonder if perhaps this is really one of the few circumstances where >> the recipient of a call ought to make call handling decisions based on >> the To-uri. The reason I say this is because the "contract" with these >> numbers is that the caller expects the call will be free based on the >> form of the number being called. And if the caller is wrong, it is the >> caller who gets charged. >> >> So, while I generally recommend that the To-uri be used for *nothing*, >> it might be right here. If so, then the whole target-uri/h-i >> discussion may be irrelevant to it. >> >> Thanks, >> Paul >> >> Christer Holmberg wrote: >>> Hi, >>>> I'm going to spare details, but the main different is as follows. >>>> >>>> 1) RFC 4244bis >>>> >>>> In RFC 4244bis, if the domain is responsible for the URI in the >>> Request-URI and it replacing it with a Contact, it will put a reg-uri >>> flag (if the Request-URI was the AOR used for registration), or reg- >>>> uri-alias (if the Request-URI was an alias for the AOR used in >>> registration). >>>> If the domain is responsible for the URI and it "maps" it to a >>> different user, then it puts a "mapped" flag. >>>> If the domain is NOT responsible for the AOR but it changes the >>> Request-URI nevertheless, then it is also marked as "mapped". >>>> Note: With loose routing, this is not supposed to happen (at >>>> least in theory). >>>> >>>> This next statement is where there is a big difference: >>>> >>>> If the domain is NOT responsible for the URI, the mapping cannot know >>> if the new URI is belongs to the same User than the original one. This >>> is why it is mapping: it is impossible for a proxy NOT >>>> responsible for a URI to change it to something else and "know" if it a >>> different user (retarget) or just a "synonym" for the same user. >>> >>> We don't think it is "impossible", and we see no reason why we should >>> make that restriction without any technical justification. The proxy >>> does not change the URI just for fun, with a value out of the blue - it >>> does it based on some kind of knowledge/configuration. >>> >>>> 2) Target-UI >>>> >>>> In target-URI, there is an assumption that a domain NOT responsible for >>> a URI can change the URI to something AND know authoritatively that the >>> new target is a "synonym" for the original target. >>> >>> Correct. >>> And, I assume the difference between "synomym" and "alias" is that a >>> synonym URI is not registered for the called user, right? >>> >>> But, one question for clarification: if the "synonym" translation is >>> done by an entity which IS reponsible for the domain, how is it tagged? >>> >>> ------------- >>> >>>> So this is what it boils down to. >>> >>> I think that is more or less what I was trying to say. >>> >>>> Can a domain NOT responsible for a target change the target AND mark >>> the new target authoritatively as "belonging" to the same user? >>>> In target-URI, the assumption is yes. >>>> >>>> In 4244bis, the assumption is no (only the domain responsible for the >>> URI can do so). >>> Correct. >>> >>> ------------- >>> >>>> As pointed out by Paul Kyzivat, we probably need to think on how this >>> works with Tel URIs. I think for Tel URI it would be totally different. >>> >>> Yes. You raised that also in our private discussions, but we never >>> discussed it in details. >>> >>> So, before we start discussing the protocol details, I think we need to >>> solve the issues above. >>> >>> Regards, >>> >>> Christer >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > From theo@crazygreek.co.uk Sat Jun 13 18:12:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E7E3A6A19 for ; Sat, 13 Jun 2009 18:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jw5z1wZpRXj0 for ; Sat, 13 Jun 2009 18:12:11 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by core3.amsl.com (Postfix) with SMTP id F378F3A67EB for ; Sat, 13 Jun 2009 18:12:10 -0700 (PDT) Received: from source ([209.85.220.225]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKSjROc6wLllx3ymk8jdsaWdAFG9jrI1f3@postini.com; Sat, 13 Jun 2009 18:12:20 PDT Received: by fxm25 with SMTP id 25so506865fxm.36 for ; Sat, 13 Jun 2009 18:12:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.79.6 with SMTP id c6mr5364100fgb.52.1244941939145; Sat, 13 Jun 2009 18:12:19 -0700 (PDT) In-Reply-To: <4A33F477.3030901@softarmor.com> References: <4A3227D2.4020808@ericsson.com> <4A33F477.3030901@softarmor.com> From: Theo Zourzouvillys Date: Sun, 14 Jun 2009 02:11:59 +0100 Message-ID: <167dfb9b0906131811r341b186bl26582c19c42fad4b@mail.gmail.com> To: Dean Willis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Milestone to revise RFC 3265 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 01:12:12 -0000 On Sat, Jun 13, 2009 at 7:48 PM, Dean Willis wrote: >> 1) should we add a milestone to our charter to revise RFC 3265? >> >> 2) if we add such a milestone, should we take the following draft as the >> initial WG item for the milestone? yes, and yes. > I believe that RFC 3265 should be revised, and that SIPCORE is the right > place to do it. Of course, I feel the same about 3261, 3262, 3263... and i do, too. ~ Theo Sent from Albany, New York, United States From ietf.hanserik@gmail.com Sun Jun 14 00:42:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 038233A6944 for ; Sun, 14 Jun 2009 00:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbHbXhG+1Oui for ; Sun, 14 Jun 2009 00:42:08 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 9F48D3A696A for ; Sun, 14 Jun 2009 00:42:07 -0700 (PDT) Received: by ewy6 with SMTP id 6so4139140ewy.37 for ; Sun, 14 Jun 2009 00:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=VOK7HsBOY4TA6imjn5QlOKTjijZQZrHpxNCBA/9SYj8=; b=xZo3UZxNJYEvNcjKv1CaRHMEixRaB2/PRAwP9iFtrLbrOuL7GOHpIqv+RJPpDvlxWv HKG+tc7rtokXa7UUwpmIvK91Srk6FFdL9XW8gflOXVIDzs9IfSvkIZ7hB60rXiROI0JC Oe7f6o75pusS47DsJ0+WmEx+Ek7BP4mgy46x4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=tSXiAkmpvCU+aUCgv0BPsmIjqr6rberRhvjcJiOoQX+bC99+CHBC+KhBwsyiT078f/ bNMMYOPCkS0InJ8S1ha/tkUmVtr08hea+ySrVie8TFZPKIrKkKKpo6m1/WlD/HU0umUN 603IWqKI1Ptw6y1mBY33/8ESUD67AUR43dcxg= Received: by 10.210.135.20 with SMTP id i20mr2955966ebd.50.1244965332648; Sun, 14 Jun 2009 00:42:12 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 7sm929062eyb.55.2009.06.14.00.42.11 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Jun 2009 00:42:12 -0700 (PDT) Message-ID: <4A34A9D2.7090509@gmail.com> Date: Sun, 14 Jun 2009 09:42:10 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Paul Kyzivat References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <4A340ACE.1070803@cisco.com> <4A3413DC.208@gmail.com> <4A341B74.2070300@cisco.com> In-Reply-To: <4A341B74.2070300@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 07:42:09 -0000 But that does not work when a diversion to that service number takes place. It only works for direct calls to such service number. /Hans Erik Paul Kyzivat wrote: > > > Hans Erik van Elburg wrote: >> Hi Paul, >> >> For what would you want to use the To-uri? > > To decide who/what the caller desired to reach, and hence what > treatment to give the call. This seems to be the key thing for the > call centers that use freephone numbers. > > Thanks, > Paul > >> /Hans Erik >> >> Paul Kyzivat wrote: >>> This thing about the freephone services is an ugly one. >>> I've thought for a long time that the mechanism is an entirely brain >>> dead way to designate who should pay for a call. >>> >>> But it is what it is, so I guess we have to cope with it. >>> >>> I wonder if perhaps this is really one of the few circumstances >>> where the recipient of a call ought to make call handling decisions >>> based on the To-uri. The reason I say this is because the "contract" >>> with these numbers is that the caller expects the call will be free >>> based on the form of the number being called. And if the caller is >>> wrong, it is the caller who gets charged. >>> >>> So, while I generally recommend that the To-uri be used for >>> *nothing*, it might be right here. If so, then the whole >>> target-uri/h-i discussion may be irrelevant to it. >>> >>> Thanks, >>> Paul >>> >>> Christer Holmberg wrote: >>>> Hi, >>>>> I'm going to spare details, but the main different is as follows. >>>>> >>>>> 1) RFC 4244bis >>>>> >>>>> In RFC 4244bis, if the domain is responsible for the URI in the >>>> Request-URI and it replacing it with a Contact, it will put a reg-uri >>>> flag (if the Request-URI was the AOR used for registration), or reg- >>>>> uri-alias (if the Request-URI was an alias for the AOR used in >>>> registration). >>>>> If the domain is responsible for the URI and it "maps" it to a >>>> different user, then it puts a "mapped" flag. >>>>> If the domain is NOT responsible for the AOR but it changes the >>>> Request-URI nevertheless, then it is also marked as "mapped". >>>>> Note: With loose routing, this is not supposed to happen >>>>> (at least in theory). >>>>> >>>>> This next statement is where there is a big difference: >>>>> >>>>> If the domain is NOT responsible for the URI, the mapping cannot know >>>> if the new URI is belongs to the same User than the original one. This >>>> is why it is mapping: it is impossible for a proxy NOT >>>>> responsible for a URI to change it to something else and "know" if >>>>> it a >>>> different user (retarget) or just a "synonym" for the same user. >>>> >>>> We don't think it is "impossible", and we see no reason why we should >>>> make that restriction without any technical justification. The proxy >>>> does not change the URI just for fun, with a value out of the blue >>>> - it >>>> does it based on some kind of knowledge/configuration. >>>> >>>>> 2) Target-UI >>>>> >>>>> In target-URI, there is an assumption that a domain NOT >>>>> responsible for >>>> a URI can change the URI to something AND know authoritatively that >>>> the >>>> new target is a "synonym" for the original target. >>>> >>>> Correct. >>>> And, I assume the difference between "synomym" and "alias" is that a >>>> synonym URI is not registered for the called user, right? >>>> >>>> But, one question for clarification: if the "synonym" translation is >>>> done by an entity which IS reponsible for the domain, how is it >>>> tagged? >>>> >>>> ------------- >>>> >>>>> So this is what it boils down to. >>>> >>>> I think that is more or less what I was trying to say. >>>> >>>>> Can a domain NOT responsible for a target change the target AND mark >>>> the new target authoritatively as "belonging" to the same user? >>>>> In target-URI, the assumption is yes. >>>>> >>>>> In 4244bis, the assumption is no (only the domain responsible for the >>>> URI can do so). >>>> Correct. >>>> >>>> ------------- >>>> >>>>> As pointed out by Paul Kyzivat, we probably need to think on how this >>>> works with Tel URIs. I think for Tel URI it would be totally >>>> different. >>>> >>>> Yes. You raised that also in our private discussions, but we never >>>> discussed it in details. >>>> >>>> So, before we start discussing the protocol details, I think we >>>> need to >>>> solve the issues above. >>>> >>>> Regards, >>>> >>>> Christer >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> From ietf.hanserik@gmail.com Sun Jun 14 00:51:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86C173A6999 for ; Sun, 14 Jun 2009 00:51:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fv9M2cKbYdcu for ; Sun, 14 Jun 2009 00:50:59 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 8C0CF3A67A7 for ; Sun, 14 Jun 2009 00:50:58 -0700 (PDT) Received: by ewy6 with SMTP id 6so4141942ewy.37 for ; Sun, 14 Jun 2009 00:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=6w7W01BwbpkNp0ScEEiz7IomXffRwBNlvLY4FCk6wKc=; b=Jh7Tl6Ht8vjY4/BmennejvftgZVWyMLZCCHkgogOPI2B7YicmgAKlsZu6ilKttm/do khJRviF0Ur1/U5scUfm2UNJwiWhzq7xs/HxmmEog6R1No42eOKpk1FkY/2BCecoE6iV/ CanqzA8ON1gFvpy5D/t9zQAWKxfnCFYNTMIh0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=H8F10SPtzazHPuEcXtZ3TTmDREWx5bweFsmTVxgtCI8nqkx3IzYH1yAwD6aC32vrt6 fzBT2eS1OFNXIU0U8HBBdDmJn1SPV2VE0KUI9bh5zGWtWNWd5TyM6u6HYT7nudF25EzF 1lyjn5hcayxx6O+r0fkNnEJs4CgD5DZj1GWSU= Received: by 10.210.142.10 with SMTP id p10mr6491978ebd.59.1244965862695; Sun, 14 Jun 2009 00:51:02 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 23sm3601609eya.19.2009.06.14.00.51.01 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Jun 2009 00:51:02 -0700 (PDT) Message-ID: <4A34ABE3.7040404@gmail.com> Date: Sun, 14 Jun 2009 09:50:59 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Mary Barnes References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120138y540f7c2bja62adcf942cba3a0@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E787F80@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120824s24f0ddfyb9dc6d6c38651d75@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D809A@zrc2hxm0.corp.nortel.com> <4A32B08C.4010308@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D8536@zrc2hxm0.corp.nortel.com> <4A32C2EB.7070304@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D86CF@zrc2hxm0.corp.nortel.com> <4A3411FF.30005@gmail.com> In-Reply-To: <4A3411FF.30005@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 07:51:01 -0000 Just an update of my previous mail I realised I forgot one step (inserted after step 3). Already 4.3.3.1 must be clarified as it says that the proxy must add a hi-entry, but it does not specify what value should be added. Further all this text seems to be written backwards instead of in logical order, which makes it very hard to understand or modify. So why dont we rewrite 4.3.3.1 something like: 4.3.3.1. Adding the History-Info Header to Requests RFC3261 Section 16.6 describes the procedure executed for each target in the target set, this specification extends that procedure as follows. A proxy conforming to this specification MUST perform the following steps between Step 8 and Step 9 as specified in Section 16.6 of [RFC3261] for each target separately : 1. If a request is received that doesn't include a History-Info header, a proxy conforming to this specification MUST add a History-Info header with a hi-entry with the value of Request-URI from the received request. The index for this hi-entry MUST start at 1. The attributes MUST be set according to the procedure as specified in 4.3.3.1.X. 2. If the incoming request already contains a History-Info header field, and the last hi-entry is not identical to the Request-URI of the received request, MUST add a History-Info header with a hi-entry with the value of Request-URI from the received request. The index for this hi-entry MUST follow the rules specified in 4.3.3.1.3. The attributes MUST be set according to the procedure as specified in 4.3.3.1.X. 3. If the incoming request already contains a History-Info header field, and the last hi-entry is identical to the Request-URI of the received request: the attributes MUST be set according to the procedure as specified in 4.3.3.1.X. 4. A proxy conforming to this specification MUST add a hi-entry with the value of the target as it forwards a Request. It is not clear why currently step 2 is somewhere hidden in 4.3.3.1.4. I also think step 1 and 2 should be mandatory evaluated. The current text for step 1 is at MAY strength. If we could agree to rewrite 4.3.3.1 like this it would be much easier to hook in different attribute setting behaviours, even if in the future someone sees the need for a new attribute and writes a separate draft for extending the mechanism. /Hans Erik Hans Erik van Elburg wrote: > Already 4.3.3.1 must be clarified as it says that the proxy must add a > hi-entry, but it does not specify what value should be added. > > Further all this text seems to be written backwards instead of in > logical order, which makes it very hard to understand or modify. > > So why dont we rewrite 4.3.3.1 something like: > > > > > .3.3.1. Adding the History-Info Header to Requests > > > RFC3261 Section 16.6 describes the procedure executed for each target > in the target set, this specification extends that procedure as follows. > > A proxy conforming to this specification MUST perform the following > steps between > Step 8 and Step 9 as specified in Section 16.6 of [RFC3261] for each > target separately : > 1. If a request is received that doesn't include a History-Info > header, a proxy conforming to this specification MUST add a > History-Info header with a hi-entry with the value of Request-URI > from the received request. The index for this hi-entry MUST start at > 1. The attributes MUST be set according to the procedure as > specified in 4.3.3.1.X. > 2. If the incoming request already contains a History-Info header > field, > and the last hi-entry is not identical to the Request-URI of the > received request, > MUST add a History-Info header with a hi-entry with the value of > Request-URI from the received request. The index for this hi-entry > MUST follow the rules specified in 4.3.3.1.3. The attributes > MUST be set according to the procedure as specified in 4.3.3.1.X. > > 3. A proxy conforming to this specification MUST add a hi-entry with > the value of the target as it forwards a Request. > > > > It is not clear why currently step 2 is somewhere hidden in 4.3.3.1.4. > I also think step 1 and 2 should be mandatory evaluated. The current > text for step 1 is at MAY strength. > > If we could agree to rewrite 4.3.3.1 like this it would be much easier > to hook in different attribute setting behaviours, even if in the > future someone sees the need for a new attribute and writes a separate > draft for extending the mechanism. > > /Hans Erik > Mary Barnes wrote: >> Hi Hans, >> >> I think we're making progress - I understand why you do not understand >> this. We likely need to add some more text to make this clear. The way >> History-Info works now is that the tags are added to the previous/last >> hi-entry (i.e., the one in the incoming request) at the point in time >> that the request is being forwarded. This is what's described in section >> 4.3.3.1. >> This means that the proxy needs to keep track of the hi-target that >> would be applied to that previous/last hi-entry for each target in the >> target list it builds per section 16.5. Then, as the proxy forwards >> the request as described in section 4.3.3.1, the proxy has the >> information as to how to appropriately tag that previous/last hi-entry. >> That's the only way it will work. But, yes, this is confusing in that >> section 4.3.3.1.4 is discussing how the information that is used when >> the request is forwarded is derived. >> So, I will add some text to clarify this in the next update to 4244bis, >> I should reword that first paragraph in section 4.3.3.1.4 as follows: >> OLD: >> An hi-target attribute MUST be included in a request forwarded by a >> proxy. The addition of the hi-target parameter MUST occur prior to >> the forwarding of the request (which may add a new hi-entry with a >> new hi-targeted-to- uri) as it is associated with the hi-targeted-to- >> uri that has been retargeted. >> NEW: An hi-target attribute MUST be included in a request >> forwarded by a >> proxy. The addition of the hi-target parameter MUST occur just prior >> to >> the forwarding of the request (which may add a new hi-entry with a >> new hi-targeted-to- uri) as it is associated with the hi-targeted-to- >> uri that has been retargeted. The value for the hi-target >> attribute is determined by the proxy when >> it builds the target list as described in section 16.5 of >> [RFC3261]. The >> subsequent paragraphs describe the processing relevant to section >> 16.5 for determining the >> value of the hi-target attribute that is associated with a >> specific target to >> which a request is to be forwarded and the value to which the >> hi-target parameter >> MUST be set when the request is forwarded. >> >> >> Thanks, >> Mary. >> -----Original Message----- >> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Sent: >> Friday, June 12, 2009 4:05 PM >> To: Barnes, Mary (RICH2:AR00) >> Cc: Christer Holmberg; sipcore@ietf.org >> Subject: Re: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> I'm trying to do it similarly 4.3.3.1.4/[4424bis], but I do not >> understand how this text works for the forked case. >> >> Because for different forks the hi-entry representing the retargeted >> R-URI could get another tag. The current text does not seem to cover >> this aspect. >> >> How is this intended to be covered by this text? >> >> /Hans Erik >> >> Mary Barnes wrote: >> >>> Hi Hans, >>> >>> Just a few comments below [MB]. >>> Thanks, >>> Mary. >>> >>> -----Original Message----- >>> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >>> Sent: Friday, June 12, 2009 2:46 PM >>> To: Barnes, Mary (RICH2:AR00) >>> Cc: Christer Holmberg; sipcore@ietf.org >>> Subject: Re: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> Hi Mary, >>> >>> >>>> So, it's just not clear at all to me how you coordinate the addition >>>> >>> of the two tags. Perhaps, it's just how that section is written, >>> >>>> but again, this is my point that it's really difficult to understand >>>> >>> your solution proposal when it is not described in the context of >>> >>>> the current normative RFC 4244 functionality. >>> The text can definitely be improved, but still the criteria for adding >>> >> >> >>> the tags are independent. >>> >>> I will try draft a chapter as it would look like in 4424. >>> [MB] Yes, it would help to understand this in the context of 16.5 >>> where you are determining the targets for the request as I can't quite >>> >> >> >>> see how the determination of the tags are independent. And, I say >>> determination because as is, you don't add the tag until you are >>> forwarding the request per section 16.6. The exception is the case of >>> >> >> >>> a 3xx and the redirect server has added the tag - at least per the >>> 4244bis specification of redirect server and 3xx handling, which is >>> actually something else missing in target-uri as this does introduce a >>> >> >> >>> somewhat special case now that we are adding this level of granularity >>> >> >> >>> in terms of the mechanism by which the target(s) are determined. [/MB] >>> >>> >>> >>>> This solution also does not seem to give clear delineation between >>>> >>> registered contacts versus configured URIs. I had understood > that to >>> >> >> >>> be important for some services. In particular, how will this >>> solution support being able to identify aliases? >>> >>> Regarding the alias concept, I have no problems in adding that. But it >>> >> >> >>> is currently not in scope of the target-uri work, if people agree then >>> >> >> >>> we can add that requirement. We could reuse the definition that is >>> contained in the 4424bis draft as I think that is a good definition. >>> [MB] I'm puzzled as aliases are identified as a service to be >>> supported by target-uri in section 4.1. That's the exact use case that >>> >> >> >>> the "reg-uri-alias" tag in 4244bis will support. [/MB] >>> >>> But what is the essential difference between bindings that came >>> about due to registration and those that are configured? (To me this >>> has nothing todo with aliases, in fact I think it is not a >>> meaningful difference how the binding was made.) But if you have a >>> requirement for that, you should maybe explain it. >>> [MB] I'm not sure we're using the term configured in the same >>> context here as I think you are really talking about the entries >>> that are tagged as "mapped" in 4244bis. The alias concept actually >>> uses both registration and configuration - that's why it's really a >>> separate mechanism by which targets are determined. This is clearly >>> defined in 4244bis in the description of the "reg-uri-alias" tag. [/MB] >>> >>> >>> /Hans Erik >>> >>> Mary Barnes wrote: >>> >>>> Hi Hans, >>>> >>>> My confusion comes from the 3rd paragraph in section 6 (the same >>>> one that confuses in terms of the unconditional addition of two >>>> hi-entries), specifically this text: >>>> " When a home proxy receives a request for a user or resource for >>>> >>> which >>> >>>> is abstract location function returns registered contacts or >>>> configured URIs, the proxy adds two History-Info header field >>>> >>> values. >>> >>>> The first is the incoming request URI. Since the Request-URI >>>> identifies a user or resource for which it has a registration or >>>> configuration, the Request-URI is an AOR and thus an address for >>>> >>> the >>> >>>> user. The proxy adds a History-Info header field parameter, >>>> >> "aor", >> >>>> which indicates this. Next, the proxy inserts the contact URI >>>> >>> which >>> >>>> will be contained in the outgoing Request-URI." >>>> >>>> (Note: this also confuses me because it is combining determining >>>> request targets with the forwarding) >>>> >>>> But, then later in that section, there's the following text (7th >>>> paragraph): >>>> "When a proxy receives a request for a user or resource for which >>>> >> it >> >>>> is responsible, then when a request URI rewrite occurs that is a >>>> routing translation, then add a History-Info header field >>>> >> parameter >> >>>> "routed" to the hi-entry recording the incoming request URI. >>>> Otherwise when a request URI rewrite occurs that is a mapping >>>> translation, then add a History-Info header field parameter >>>> >>> "mapped" >>> >>>> to the hi-entry recording the incoming request URI. " >>>> >>>> So, it's just not clear at all to me how you coordinate the >>>> addition of the two tags. Perhaps, it's just how that section is >>>> written, but >>>> >> >> >>>> again, this is my point that it's really difficult to understand your >>>> >> >> >>>> solution proposal when it is not described in the context of the >>>> current normative RFC 4244 functionality. >>>> >>>> This solution also does not seem to give clear delineation between >>>> registered contacts versus configured URIs. I had understood that >>>> to be important for some services. In particular, how will this >>>> solution >>>> >> >> >>>> support being able to identify aliases? >>>> >>>> Thanks, >>>> Mary. >>>> >>>> --------------------------------------------------------------------- >>>> - >>>> -- >>>> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >>>> *Sent:* Friday, June 12, 2009 10:24 AM >>>> *To:* Barnes, Mary (RICH2:AR00) >>>> *Cc:* Christer Holmberg; sipcore@ietf.org >>>> *Subject:* Re: [sipcore] FW: I-D >>>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>>> >>>> Hi Mary, >>>> >>>> I do not understand what you mean with multi stage. All the tagging >>>> can be prepared at the time that the translation is done and added at >>>> >> >> >>>> the time that 4244 suggests the H-I to be added. If the current >>>> text suggests otherwise, then we might need to fix that. >>>> >>>> BR, >>>> /Hans Erik van Elburg >>>> >>>> >>>> On Fri, Jun 12, 2009 at 4:11 PM, Mary Barnes >>>> > wrote: >>>> >>>> Hi Hans, >>>> A couple comments below [MB]. >>>> Mary. >>>> >>>> >>>> >>> ---------------------------------------------------------------------- >>> -- >>> >>>> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com >>>> ] >>>> *Sent:* Friday, June 12, 2009 3:38 AM >>>> >>>> *To:* Barnes, Mary (RICH2:AR00) >>>> *Cc:* Christer Holmberg; sipcore@ietf.org >>>> >>> >>> >>>> *Subject:* Re: [sipcore] FW: I-D >>>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>>> >>>> Hi Mary, >>>> >>>> Sure when we agree on the way forward we have to resolve all >>>> >> these >> >>>> detailed procedures and conform to the 4244 language etc. But we >>>> already agreed to integrate it into 4424bis at the moment that >>>> there is agreement about the solution. >>>> >>>> Regarding the two tag approach that is open for discussion, i >>>> think it is more clean and in general pays off to separate >>>> concepts that are independent from each other. For example a >>>> hi-entry may be routed and not be an AOR, whereas it may also be >>>> routed and also an AOR. The decisions to be taken for additions >>>> >> of >> >>>> these tags are independent, so there is also no need to >>>> >> intertwine >> >>>> procedural text for them. (It is also more clear for >>>> >>> implementors.) >>> >>>> [MB] This is where my major confusion is in that you say the tags >>>> are independent, BUT where in the normative RFC 3261 processing >>>> does this occur? I'm confused because the logic in section 16.5 >>>> isn't "multi-stage" (for lack of a better term), the incoming >>>> request URI is evaluated and then the new target list is >>>> constructed The tagging in 4244 is based on the mechanism by >>>> which a new target is determined . The previous hi-entry (that >>>> >> in >> >>>> the incoming request) is tagged at the point the request is being >>>> forwarded. I do agree that in the internal processing that >>>> information needs to exist so that the tagging at the point of >>>> forwarding the request is appropriate. [/MB] >>>> >>>> >>>> BR, >>>> /Hans Erik van Elburg >>>> >>>> On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes >>>> > wrote: >>>> >>>> Christer, >>>> >>>> I reviewed the updated target-uri draft and have a few >>>> comments - well I >>>> reviewed the diff since there isn't a summary of changes in >>>> >>> the >>> >>>> document: >>>> >>>> 1) I had a lot of difficulty picking out the normative >>>> processing for >>>> History-Info in this document. Can you summarize the >>>> >>> differences? >>> >>>> 2) The reason I'm concerned about understanding how this fits >>>> with the >>>> current normative processing is because I'm not seeing >>>> precisely when >>>> these tags are added as the terminology is different than >>>> >> that >> >>>> used in >>>> RFC 4244 - i.e., are these two terms equivalent: >>>> RFC 4244: >>>> "... hi-entry received in the request being forwarded." >>>> >>>> target-uri: >>>> "...hi-entry recording the incoming request URI." >>>> >>>> There is no reference in terms of current History-Info >>>> processing as to >>>> when in the request processing these tags are added. >>>> >>>> 3) In particular, I'm having difficulty with this text in >>>> section 6: >>>> "When a home proxy receives a request for a user or resource >>>> >>> for >>> >>>> which >>>> is abstract location function returns registered contacts >>>> >> or >> >>>> configured URIs, the proxy adds two History-Info header >>>> field values. >>>> The first is the incoming request URI. Since the >>>> >>> Request-URI >>> >>>> identifies a user or resource for which it has a >>>> >>> registration or >>> >>>> configuration, the Request-URI is an AOR and thus an >>>> >> address >> >>>> for the >>>> user. The proxy adds a History-Info header field >>>> >> parameter, >> >>>> "aor", >>>> which indicates this. Next, the proxy inserts the contact >>>> URI which >>>> will be contained in the outgoing Request-URI." >>>> Currently, in RFC 4244, the proxy only adds that additional >>>> (first) >>>> hi-entry IF there wasn't one in the incoming request, since >>>> the UAC can >>>> initially add one when it builds the request. So, this is >>>> inconsistent >>>> with current RFC 4244. And, I think you need to define "home" >>>> proxy - >>>> that's not an RFC 3261 term - there is the concept of a >>>> >> "home" >> >>>> domain. >>>> >>>> 4) There is a bug in the Syntax (section 9) - the Index is >>>> >> not >> >>>> optional >>>> (that is an error we have fixed in the 4244bis). >>>> >>>> 5) I'm really confused about this two-stage tagging - how >>>> >> does >> >>>> that >>>> happen in the context of the determination of Request Targets >>>> in section >>>> 16.5 of RFC3261? Wouldn't the decisions as to the addition of >>>> the two >>>> different tags occur at the same time and thus what is the >>>> advantage of >>>> the defining the two tags - i.e., why not one tag for each >>>> combination? >>>> Also, are you proposing that the addition of the tags be >>>> mandatory - >>>> there is no normative language in the target-uri document, so >>>> >>> it's >>> >>>> impossible to tell. And, if you are proposing they be >>>> mandatory, your >>>> ABNF syntax needs to reflect that, thus defining a single >>>> parameter with >>>> multiple values would be necessary (which is the approach in >>>> 4244bis). >>>> >>>> >>>> 6) What is the difference (or is there a difference?) between >>>> >>> the >>> >>>> functionality associated with the tags in 4244bis and the >>>> >> tags >> >>>> defined >>>> in this document in terms of types of retargets that are >>>> >> being >> >>>> tagged? >>>> I think this is the crux of what we need to agree - i.e., why >>>> aren't the >>>> 4244bis tags sufficient? If there is no logical difference >>>> and it's >>>> just the words used to define the tags, then we're very close >>>> >>> to >>> >>>> agreement. >>>> >>>> Regards, >>>> Mary. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Christer Holmberg >>>> >> [mailto:christer.holmberg@ericsson.com >> >>>> ] >>>> Sent: Thursday, June 11, 2009 3:32 PM >>>> To: Christer Holmberg; Barnes, Mary (RICH2:AR00); >>>> sipcore@ietf.org >>>> Subject: RE: [sipcore] FW: I-D >>>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>>> >>>> >>>> Here is the link to the latest version of the target-uri >>>> >>> draft: >>> >>>> >> http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00. >> >>> >>>> txt >>>> >>>> >>> - >>>> 00.%0Atxt> >>>> >>>> -----Original Message----- >>>> From: Christer Holmberg >>>> Sent: Thursday, June 11, 2009 11:31 PM >>>> To: 'Mary Barnes'; sipcore@ietf.org >>>> Subject: RE: [sipcore] FW: I-D >>>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>>> >>>> >>>> Hi, >>>> >>>> I think it is important to mention that there are still >>>> >>> different >>> >>>> approaches regarding the target uri delivery, and that there >>>> is another >>>> approach described in the latest version of the target-uri >>>> delivery >>>> draft (I am not sure it appears in the archieves, though, for >>>> >>> some >>> >>>> reason). Both approaches are based on History-Info, though. >>>> >>>> We haven't yet been able to agree on an approach, so we >>>> thought the best >>>> is to bring it to the list in order for other people to get >>>> involved. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> >>>> [mailto:sipcore-bounces@ietf.org >>>> ] On >>>> Behalf Of Mary Barnes >>>> Sent: Thursday, June 11, 2009 9:05 PM >>>> To: sipcore@ietf.org >>>> Subject: [sipcore] FW: I-D >>>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>>> >>>> Hi folks, >>>> >>>> We have made a few changes to this document which was >>>> submitted last >>>> week just to tie up some loose ends and inconsistencies, some >>>> of which >>>> Shida identified when he reviewed the -00 version. >>>> >>>> The following summarizes the high level changes in the >>>> sipcore-rfc4244bis from the sip-rfc4244bis that we discussed >>>> in San >>>> Francisco: >>>> 1) Renamed the "retarget" parameter to "target" and defined >>>> explicit >>>> tags to reflect the various mechanisms by which a Request is >>>> retargeted. >>>> All entries are now tagged. >>>> 2) Updated redirect server processing as the redirect server >>>> >>> must >>> >>>> capture the "target" parameter since it is the entity that >>>> knows the >>>> specific mechanism by which the new target has been >>>> >>> determined. >>> >>>> 3) Changed the privacy such that rather than removing entries >>>> based on >>>> the various values of the privacy header, the entries are >>>> recommended to >>>> be anonymized. >>>> 4) Updated security section >>>> 5) Updated examples to reflect the new parameter, use loose >>>> routing and >>>> fix errors/nits. >>>> 6) Editorial changes to remove redundant text and the >>>> convuluted text >>>> around optionality in the non-normative sections, which is >>>> >> now >> >>>> discussed >>>> appropriately in the context of the histinfo option tag. >>>> >>>> The detailed changes between the versions are summarized in >>>> >>> the >>> >>>> document. >>>> >>>> If you're wanting to look at a diff, I would recommend you >>>> diff against >>>> RFC 4244 rather than the earlier 4244bis documents. >>>> >>>> We'd really appreciate feedback on this approach to precisely >>>> tagging >>>> all the entries. We believe it is comprehensive and should >>>> suffice for >>>> all the use cases identified in the target-uri document, as >>>> well as any >>>> others that might arise. >>>> >>>> Thanks, >>>> Mary and Francois. >>>> >>>> -----Original Message----- >>>> From: i-d-announce-bounces@ietf.org >>>> >>>> [mailto:i-d-announce-bounces@ietf.org >>>> ] On Behalf Of >>>> Internet-Drafts@ietf.org >>>> Sent: Thursday, June 11, 2009 12:45 PM >>>> To: i-d-announce@ietf.org >>>> Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt >>>> >>>> A New Internet-Draft is available from the on-line >>>> >>> Internet-Drafts >>> >>>> directories. >>>> >>>> Title : An Extension to the Session >>>> >>> Initiation >>> >>>> Protocol (SIP) for Request History Information >>>> Author(s) : M. Barnes, F. Audet >>>> Filename : >>>> >>> draft-barnes-sipcore-rfc4244bis-01.txt >>> >>>> Pages : 42 >>>> Date : 2009-06-11 >>>> >>>> This document defines a standard mechanism for capturing the >>>> history >>>> information associated with a Session Initiation Protocol >>>> (SIP) request. >>>> This capability enables many enhanced services by providing >>>> >>> the >>> >>>> information as to how and why a call arrives at a specific >>>> application >>>> or user. This document defines a new optional SIP header, >>>> History-Info, >>>> for capturing the history information in requests. >>>> >>>> A URL for this Internet-Draft is: >>>> >>>> >>> http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01 >>> .t >>> >>>> xt >>>> >>>> >>> 0 >>>> 1.t%0Axt> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail >>>> >>> reader >>> >>>> implementation to automatically retrieve the ASCII version of >>>> >>> the >>> >>>> Internet-Draft. >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >>>> >>>> From christer.holmberg@ericsson.com Sun Jun 14 05:47:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7191F28C0E1 for ; Sun, 14 Jun 2009 05:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.228 X-Spam-Level: X-Spam-Status: No, score=-5.228 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72gY9Ae+iShc for ; Sun, 14 Jun 2009 05:47:21 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id BDFB33A6C61 for ; Sun, 14 Jun 2009 05:47:19 -0700 (PDT) X-AuditID: c1b4fb3e-b7bedae0000062bb-b7-4a34f15fce4c Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 37.6A.25275.F51F43A4; Sun, 14 Jun 2009 14:47:27 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Jun 2009 14:47:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 14 Jun 2009 14:47:26 +0200 Message-ID: In-Reply-To: <4A341B74.2070300@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) Thread-Index: AcnsbsthdFb0aL0wQkKG5FACy9ZwGgAUt0Xw References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <4A340ACE.1070803@cisco.com> <4A3413DC.208@gmail.com> <4A341B74.2070300@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Hans Erik van Elburg" X-OriginalArrivalTime: 14 Jun 2009 12:47:26.0782 (UTC) FILETIME=[456B95E0:01C9ECEE] X-Brightmail-Tracker: AAAAAA== Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 12:47:22 -0000 Hi Paul, I guess you can look at the To-uri if you want to know who/what the caller desired to reach. However, the ua-loose-draft describes why the To-uri approach doesn't work as a general solution for the target delivery problem. Please know that diversion may have taken place before the final target was chosen, so the To-uri may not say anything about the current target.=20 So, even for freephone the To-uri may not contain the freephone number, if the caller first tried to call something/someone else. Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Sunday, June 14, 2009 12:35 AM To: Hans Erik van Elburg Cc: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: Re: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) Hans Erik van Elburg wrote: > Hi Paul, >=20 > For what would you want to use the To-uri? To decide who/what the caller desired to reach, and hence what treatment to give the call. This seems to be the key thing for the call centers that use freephone numbers. Thanks, Paul > /Hans Erik >=20 > Paul Kyzivat wrote: >> This thing about the freephone services is an ugly one. >> I've thought for a long time that the mechanism is an entirely brain=20 >> dead way to designate who should pay for a call. >> >> But it is what it is, so I guess we have to cope with it. >> >> I wonder if perhaps this is really one of the few circumstances where >> the recipient of a call ought to make call handling decisions based=20 >> on the To-uri. The reason I say this is because the "contract" with=20 >> these numbers is that the caller expects the call will be free based=20 >> on the form of the number being called. And if the caller is wrong,=20 >> it is the caller who gets charged. >> >> So, while I generally recommend that the To-uri be used for=20 >> *nothing*, it might be right here. If so, then the whole=20 >> target-uri/h-i discussion may be irrelevant to it. >> >> Thanks, >> Paul >> >> Christer Holmberg wrote: >>> Hi, >>>> I'm going to spare details, but the main different is as follows. >>>> >>>> 1) RFC 4244bis >>>> >>>> In RFC 4244bis, if the domain is responsible for the URI in the >>> Request-URI and it replacing it with a Contact, it will put a=20 >>> reg-uri flag (if the Request-URI was the AOR used for registration), >>> or reg- >>>> uri-alias (if the Request-URI was an alias for the AOR used in >>> registration). >>>> If the domain is responsible for the URI and it "maps" it to a >>> different user, then it puts a "mapped" flag. >>>> If the domain is NOT responsible for the AOR but it changes the >>> Request-URI nevertheless, then it is also marked as "mapped". >>>> Note: With loose routing, this is not supposed to happen (at=20 >>>> least in theory). >>>> >>>> This next statement is where there is a big difference: >>>> >>>> If the domain is NOT responsible for the URI, the mapping cannot=20 >>>> know >>> if the new URI is belongs to the same User than the original one.=20 >>> This is why it is mapping: it is impossible for a proxy NOT >>>> responsible for a URI to change it to something else and "know" if=20 >>>> it a >>> different user (retarget) or just a "synonym" for the same user. >>> >>> We don't think it is "impossible", and we see no reason why we=20 >>> should make that restriction without any technical justification.=20 >>> The proxy does not change the URI just for fun, with a value out of=20 >>> the blue - it does it based on some kind of knowledge/configuration. >>> >>>> 2) Target-UI >>>> >>>> In target-URI, there is an assumption that a domain NOT responsible >>>> for >>> a URI can change the URI to something AND know authoritatively that=20 >>> the new target is a "synonym" for the original target. >>> >>> Correct. >>> And, I assume the difference between "synomym" and "alias" is that a >>> synonym URI is not registered for the called user, right? >>> >>> But, one question for clarification: if the "synonym" translation is >>> done by an entity which IS reponsible for the domain, how is it tagged? >>> >>> ------------- >>> >>>> So this is what it boils down to. >>> >>> I think that is more or less what I was trying to say. >>> >>>> Can a domain NOT responsible for a target change the target AND=20 >>>> mark >>> the new target authoritatively as "belonging" to the same user? >>>> In target-URI, the assumption is yes. >>>> >>>> In 4244bis, the assumption is no (only the domain responsible for=20 >>>> the >>> URI can do so). >>> Correct. >>> >>> ------------- >>> >>>> As pointed out by Paul Kyzivat, we probably need to think on how=20 >>>> this >>> works with Tel URIs. I think for Tel URI it would be totally different. >>> >>> Yes. You raised that also in our private discussions, but we never=20 >>> discussed it in details. >>> >>> So, before we start discussing the protocol details, I think we need >>> to solve the issues above. >>> >>> Regards, >>> >>> Christer >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 From mdolly@att.com Sun Jun 14 05:57:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1F4728C0E1 for ; Sun, 14 Jun 2009 05:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.674 X-Spam-Level: X-Spam-Status: No, score=-105.674 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-CPSf4I96Bk for ; Sun, 14 Jun 2009 05:57:11 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 910BB3A6B32 for ; Sun, 14 Jun 2009 05:57:11 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-2.tower-146.messagelabs.com!1244984241!14717232!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 32269 invoked from network); 14 Jun 2009 12:57:22 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-2.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Jun 2009 12:57:22 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5ECvJkC019210; Sun, 14 Jun 2009 08:57:19 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5ECvEDO019183; Sun, 14 Jun 2009 08:57:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sun, 14 Jun 2009 08:57:14 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD480B@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) Thread-Index: AcnsbsthdFb0aL0wQkKG5FACy9ZwGgAUt0XwAAt+050= From: "DOLLY, MARTIN C, ATTLABS" To: , , Cc: sipcore@ietf.org Subject: Re: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 12:57:13 -0000 V2UgKEFUVCkgYXJlIGV4cGVjdGluZyBISSB0byBjYXB0dXJlIHRoaXMgaW5mb3JtYXRpb24NCg0K LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NClRvOiBQYXVsIEt5eml2YXQgPHBreXppdmF0 QGNpc2NvLmNvbT47IEhhbnMgRXJpayB2YW4gRWxidXJnIDxpZXRmLmhhbnNlcmlrQGdtYWlsLmNv bT4NCkNjOiBET0xMWSwgTUFSVElOIEMsIEFUVExBQlM7IHNpcGNvcmVAaWV0Zi5vcmcgPHNpcGNv cmVAaWV0Zi5vcmc+DQpTZW50OiBTdW4gSnVuIDE0IDA4OjQ3OjI2IDIwMDkNClN1YmplY3Q6IFJF OiBbc2lwY29yZV0gVGhlIGZ1bmN0aW9uYWwgZGlmZmVyZW5jZXMgYmV0d2VlbiA0MjQ0YmlzIGFu ZCB0YXJnZXQtIHVyaSAod2FzIEZXOiBJLUQgQWN0aW9uOmRyYWZ0LWJhcm5lcy1zaXBjb3JlLXJm YzQyNDRiaXMtMDEudHh0KQ0KDQoNCkhpIFBhdWwsDQoNCkkgZ3Vlc3MgeW91IGNhbiBsb29rIGF0 IHRoZSBUby11cmkgaWYgeW91IHdhbnQgdG8ga25vdyB3aG8vd2hhdCB0aGUNCmNhbGxlciBkZXNp cmVkIHRvIHJlYWNoLg0KDQpIb3dldmVyLCB0aGUgdWEtbG9vc2UtZHJhZnQgZGVzY3JpYmVzIHdo eSB0aGUgVG8tdXJpIGFwcHJvYWNoIGRvZXNuJ3QNCndvcmsgYXMgYSBnZW5lcmFsIHNvbHV0aW9u IGZvciB0aGUgdGFyZ2V0IGRlbGl2ZXJ5IHByb2JsZW0uIFBsZWFzZSBrbm93DQp0aGF0IGRpdmVy c2lvbiBtYXkgaGF2ZSB0YWtlbiBwbGFjZSBiZWZvcmUgdGhlIGZpbmFsIHRhcmdldCB3YXMgY2hv c2VuLA0Kc28gdGhlIFRvLXVyaSBtYXkgbm90IHNheSBhbnl0aGluZyBhYm91dCB0aGUgY3VycmVu dCB0YXJnZXQuIA0KDQpTbywgZXZlbiBmb3IgZnJlZXBob25lIHRoZSBUby11cmkgbWF5IG5vdCBj b250YWluIHRoZSBmcmVlcGhvbmUgbnVtYmVyLA0KaWYgdGhlIGNhbGxlciBmaXJzdCB0cmllZCB0 byBjYWxsIHNvbWV0aGluZy9zb21lb25lIGVsc2UuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFBhdWwgS3l6aXZhdCBbbWFpbHRv OnBreXppdmF0QGNpc2NvLmNvbV0gDQpTZW50OiBTdW5kYXksIEp1bmUgMTQsIDIwMDkgMTI6MzUg QU0NClRvOiBIYW5zIEVyaWsgdmFuIEVsYnVyZw0KQ2M6IENocmlzdGVyIEhvbG1iZXJnOyBET0xM WSwgTUFSVElOIEMsIEFUVExBQlM7IHNpcGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2lw Y29yZV0gVGhlIGZ1bmN0aW9uYWwgZGlmZmVyZW5jZXMgYmV0d2VlbiA0MjQ0YmlzIGFuZA0KdGFy Z2V0LSB1cmkgKHdhcyBGVzogSS1EIEFjdGlvbjpkcmFmdC1iYXJuZXMtc2lwY29yZS1yZmM0MjQ0 YmlzLTAxLnR4dCkNCg0KDQoNCkhhbnMgRXJpayB2YW4gRWxidXJnIHdyb3RlOg0KPiBIaSBQYXVs LA0KPiANCj4gRm9yIHdoYXQgd291bGQgeW91IHdhbnQgdG8gdXNlIHRoZSBUby11cmk/DQoNClRv IGRlY2lkZSB3aG8vd2hhdCB0aGUgY2FsbGVyIGRlc2lyZWQgdG8gcmVhY2gsIGFuZCBoZW5jZSB3 aGF0IHRyZWF0bWVudA0KdG8gZ2l2ZSB0aGUgY2FsbC4gVGhpcyBzZWVtcyB0byBiZSB0aGUga2V5 IHRoaW5nIGZvciB0aGUgY2FsbCBjZW50ZXJzDQp0aGF0IHVzZSBmcmVlcGhvbmUgbnVtYmVycy4N Cg0KCVRoYW5rcywNCglQYXVsDQoNCj4gL0hhbnMgRXJpaw0KPiANCj4gUGF1bCBLeXppdmF0IHdy b3RlOg0KPj4gVGhpcyB0aGluZyBhYm91dCB0aGUgZnJlZXBob25lIHNlcnZpY2VzIGlzIGFuIHVn bHkgb25lLg0KPj4gSSd2ZSB0aG91Z2h0IGZvciBhIGxvbmcgdGltZSB0aGF0IHRoZSBtZWNoYW5p c20gaXMgYW4gZW50aXJlbHkgYnJhaW4gDQo+PiBkZWFkIHdheSB0byBkZXNpZ25hdGUgd2hvIHNo b3VsZCBwYXkgZm9yIGEgY2FsbC4NCj4+DQo+PiBCdXQgaXQgaXMgd2hhdCBpdCBpcywgc28gSSBn dWVzcyB3ZSBoYXZlIHRvIGNvcGUgd2l0aCBpdC4NCj4+DQo+PiBJIHdvbmRlciBpZiBwZXJoYXBz IHRoaXMgaXMgcmVhbGx5IG9uZSBvZiB0aGUgZmV3IGNpcmN1bXN0YW5jZXMgd2hlcmUNCg0KPj4g dGhlIHJlY2lwaWVudCBvZiBhIGNhbGwgb3VnaHQgdG8gbWFrZSBjYWxsIGhhbmRsaW5nIGRlY2lz aW9ucyBiYXNlZCANCj4+IG9uIHRoZSBUby11cmkuIFRoZSByZWFzb24gSSBzYXkgdGhpcyBpcyBi ZWNhdXNlIHRoZSAiY29udHJhY3QiIHdpdGggDQo+PiB0aGVzZSBudW1iZXJzIGlzIHRoYXQgdGhl IGNhbGxlciBleHBlY3RzIHRoZSBjYWxsIHdpbGwgYmUgZnJlZSBiYXNlZCANCj4+IG9uIHRoZSBm b3JtIG9mIHRoZSBudW1iZXIgYmVpbmcgY2FsbGVkLiBBbmQgaWYgdGhlIGNhbGxlciBpcyB3cm9u ZywgDQo+PiBpdCBpcyB0aGUgY2FsbGVyIHdobyBnZXRzIGNoYXJnZWQuDQo+Pg0KPj4gU28sIHdo aWxlIEkgZ2VuZXJhbGx5IHJlY29tbWVuZCB0aGF0IHRoZSBUby11cmkgYmUgdXNlZCBmb3IgDQo+ PiAqbm90aGluZyosIGl0IG1pZ2h0IGJlIHJpZ2h0IGhlcmUuIElmIHNvLCB0aGVuIHRoZSB3aG9s ZSANCj4+IHRhcmdldC11cmkvaC1pIGRpc2N1c3Npb24gbWF5IGJlIGlycmVsZXZhbnQgdG8gaXQu DQo+Pg0KPj4gICAgIFRoYW5rcywNCj4+ICAgICBQYXVsDQo+Pg0KPj4gQ2hyaXN0ZXIgSG9sbWJl cmcgd3JvdGU6DQo+Pj4gSGksDQo+Pj4+IEknbSBnb2luZyB0byBzcGFyZSBkZXRhaWxzLCBidXQg dGhlIG1haW4gZGlmZmVyZW50IGlzIGFzIGZvbGxvd3MuDQo+Pj4+DQo+Pj4+IDEpIFJGQyA0MjQ0 YmlzDQo+Pj4+DQo+Pj4+IEluIFJGQyA0MjQ0YmlzLCBpZiB0aGUgZG9tYWluIGlzIHJlc3BvbnNp YmxlIGZvciB0aGUgVVJJIGluIHRoZQ0KPj4+IFJlcXVlc3QtVVJJIGFuZCBpdCByZXBsYWNpbmcg aXQgd2l0aCBhIENvbnRhY3QsIGl0IHdpbGwgcHV0IGEgDQo+Pj4gcmVnLXVyaSBmbGFnIChpZiB0 aGUgUmVxdWVzdC1VUkkgd2FzIHRoZSBBT1IgdXNlZCBmb3IgcmVnaXN0cmF0aW9uKSwNCg0KPj4+ IG9yIHJlZy0NCj4+Pj4gdXJpLWFsaWFzIChpZiB0aGUgUmVxdWVzdC1VUkkgd2FzIGFuIGFsaWFz IGZvciB0aGUgQU9SIHVzZWQgaW4NCj4+PiByZWdpc3RyYXRpb24pLg0KPj4+PiBJZiB0aGUgZG9t YWluIGlzIHJlc3BvbnNpYmxlIGZvciB0aGUgVVJJIGFuZCBpdCAibWFwcyIgaXQgdG8gYQ0KPj4+ IGRpZmZlcmVudCB1c2VyLCB0aGVuIGl0IHB1dHMgYSAibWFwcGVkIiBmbGFnLg0KPj4+PiBJZiB0 aGUgZG9tYWluIGlzIE5PVCByZXNwb25zaWJsZSBmb3IgdGhlIEFPUiBidXQgaXQgY2hhbmdlcyB0 aGUNCj4+PiBSZXF1ZXN0LVVSSSBuZXZlcnRoZWxlc3MsIHRoZW4gaXQgaXMgYWxzbyBtYXJrZWQg YXMgIm1hcHBlZCIuDQo+Pj4+ICAgICBOb3RlOiBXaXRoIGxvb3NlIHJvdXRpbmcsIHRoaXMgaXMg bm90IHN1cHBvc2VkIHRvIGhhcHBlbg0KKGF0IA0KPj4+PiBsZWFzdCBpbiB0aGVvcnkpLg0KPj4+ Pg0KPj4+PiBUaGlzIG5leHQgc3RhdGVtZW50IGlzIHdoZXJlIHRoZXJlIGlzIGEgYmlnIGRpZmZl cmVuY2U6DQo+Pj4+DQo+Pj4+IElmIHRoZSBkb21haW4gaXMgTk9UIHJlc3BvbnNpYmxlIGZvciB0 aGUgVVJJLCB0aGUgbWFwcGluZyBjYW5ub3QgDQo+Pj4+IGtub3cNCj4+PiBpZiB0aGUgbmV3IFVS SSBpcyBiZWxvbmdzIHRvIHRoZSBzYW1lIFVzZXIgdGhhbiB0aGUgb3JpZ2luYWwgb25lLiANCj4+ PiBUaGlzIGlzIHdoeSBpdCBpcyBtYXBwaW5nOiBpdCBpcyBpbXBvc3NpYmxlIGZvciBhIHByb3h5 IE5PVA0KPj4+PiByZXNwb25zaWJsZSBmb3IgYSBVUkkgdG8gY2hhbmdlIGl0IHRvIHNvbWV0aGlu ZyBlbHNlIGFuZCAia25vdyIgaWYgDQo+Pj4+IGl0IGENCj4+PiBkaWZmZXJlbnQgdXNlciAocmV0 YXJnZXQpIG9yIGp1c3QgYSAic3lub255bSIgZm9yIHRoZSBzYW1lIHVzZXIuDQo+Pj4NCj4+PiBX ZSBkb24ndCB0aGluayBpdCBpcyAiaW1wb3NzaWJsZSIsIGFuZCB3ZSBzZWUgbm8gcmVhc29uIHdo eSB3ZSANCj4+PiBzaG91bGQgbWFrZSB0aGF0IHJlc3RyaWN0aW9uIHdpdGhvdXQgYW55IHRlY2hu aWNhbCBqdXN0aWZpY2F0aW9uLiANCj4+PiBUaGUgcHJveHkgZG9lcyBub3QgY2hhbmdlIHRoZSBV UkkganVzdCBmb3IgZnVuLCB3aXRoIGEgdmFsdWUgb3V0IG9mIA0KPj4+IHRoZSBibHVlIC0gaXQg ZG9lcyBpdCBiYXNlZCBvbiBzb21lIGtpbmQgb2Yga25vd2xlZGdlL2NvbmZpZ3VyYXRpb24uDQo+ Pj4NCj4+Pj4gMikgVGFyZ2V0LVVJDQo+Pj4+DQo+Pj4+IEluIHRhcmdldC1VUkksIHRoZXJlIGlz IGFuIGFzc3VtcHRpb24gdGhhdCBhIGRvbWFpbiBOT1QgcmVzcG9uc2libGUNCg0KPj4+PiBmb3IN Cj4+PiBhIFVSSSBjYW4gY2hhbmdlIHRoZSBVUkkgdG8gc29tZXRoaW5nIEFORCBrbm93IGF1dGhv cml0YXRpdmVseSB0aGF0IA0KPj4+IHRoZSBuZXcgdGFyZ2V0IGlzIGEgInN5bm9ueW0iIGZvciB0 aGUgb3JpZ2luYWwgdGFyZ2V0Lg0KPj4+DQo+Pj4gQ29ycmVjdC4NCj4+PiBBbmQsIEkgYXNzdW1l IHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gInN5bm9teW0iIGFuZCAiYWxpYXMiIGlzIHRoYXQgYQ0K DQo+Pj4gc3lub255bSBVUkkgaXMgbm90IHJlZ2lzdGVyZWQgZm9yIHRoZSBjYWxsZWQgdXNlciwg cmlnaHQ/DQo+Pj4NCj4+PiBCdXQsIG9uZSBxdWVzdGlvbiBmb3IgY2xhcmlmaWNhdGlvbjogaWYg dGhlICJzeW5vbnltIiB0cmFuc2xhdGlvbiBpcw0KDQo+Pj4gZG9uZSBieSBhbiBlbnRpdHkgd2hp Y2ggSVMgcmVwb25zaWJsZSBmb3IgdGhlIGRvbWFpbiwgaG93IGlzIGl0DQp0YWdnZWQ/DQo+Pj4N Cj4+PiAtLS0tLS0tLS0tLS0tDQo+Pj4NCj4+Pj4gU28gdGhpcyBpcyB3aGF0IGl0IGJvaWxzIGRv d24gdG8uDQo+Pj4NCj4+PiBJIHRoaW5rIHRoYXQgaXMgbW9yZSBvciBsZXNzIHdoYXQgSSB3YXMg dHJ5aW5nIHRvIHNheS4NCj4+Pg0KPj4+PiBDYW4gYSBkb21haW4gTk9UIHJlc3BvbnNpYmxlIGZv ciBhIHRhcmdldCBjaGFuZ2UgdGhlIHRhcmdldCBBTkQgDQo+Pj4+IG1hcmsNCj4+PiB0aGUgbmV3 IHRhcmdldCBhdXRob3JpdGF0aXZlbHkgYXMgImJlbG9uZ2luZyIgdG8gdGhlIHNhbWUgdXNlcj8N Cj4+Pj4gSW4gdGFyZ2V0LVVSSSwgdGhlIGFzc3VtcHRpb24gaXMgeWVzLg0KPj4+Pg0KPj4+PiBJ biA0MjQ0YmlzLCB0aGUgYXNzdW1wdGlvbiBpcyBubyAob25seSB0aGUgZG9tYWluIHJlc3BvbnNp YmxlIGZvciANCj4+Pj4gdGhlDQo+Pj4gVVJJIGNhbiBkbyBzbykuDQo+Pj4gQ29ycmVjdC4NCj4+ Pg0KPj4+IC0tLS0tLS0tLS0tLS0NCj4+Pg0KPj4+PiBBcyBwb2ludGVkIG91dCBieSBQYXVsIEt5 eml2YXQsIHdlIHByb2JhYmx5IG5lZWQgdG8gdGhpbmsgb24gaG93IA0KPj4+PiB0aGlzDQo+Pj4g d29ya3Mgd2l0aCBUZWwgVVJJcy4gSSB0aGluayBmb3IgVGVsIFVSSSBpdCB3b3VsZCBiZSB0b3Rh bGx5DQpkaWZmZXJlbnQuDQo+Pj4NCj4+PiBZZXMuIFlvdSByYWlzZWQgdGhhdCBhbHNvIGluIG91 ciBwcml2YXRlIGRpc2N1c3Npb25zLCBidXQgd2UgbmV2ZXIgDQo+Pj4gZGlzY3Vzc2VkIGl0IGlu IGRldGFpbHMuDQo+Pj4NCj4+PiBTbywgYmVmb3JlIHdlIHN0YXJ0IGRpc2N1c3NpbmcgdGhlIHBy b3RvY29sIGRldGFpbHMsIEkgdGhpbmsgd2UgbmVlZA0KDQo+Pj4gdG8gc29sdmUgdGhlIGlzc3Vl cyBhYm92ZS4NCj4+Pg0KPj4+IFJlZ2FyZHMsDQo+Pj4NCj4+PiBDaHJpc3Rlcg0KPj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gc2lwY29yZSBt YWlsaW5nIGxpc3QNCj4+PiBzaXBjb3JlQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPj4g c2lwY29yZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaXBjb3JlDQo+IA0K From christer.holmberg@ericsson.com Sun Jun 14 06:18:07 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB07B28C0E1 for ; Sun, 14 Jun 2009 06:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.224 X-Spam-Level: X-Spam-Status: No, score=-5.224 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzlcLngMmSUA for ; Sun, 14 Jun 2009 06:18:06 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 3FF6E3A6821 for ; Sun, 14 Jun 2009 06:18:05 -0700 (PDT) X-AuditID: c1b4fb3e-b7bedae0000062bb-65-4a34f896771f Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id C7.0B.25275.698F43A4; Sun, 14 Jun 2009 15:18:14 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Jun 2009 15:18:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 14 Jun 2009 15:18:13 +0200 Message-ID: In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA02BD480B@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) Thread-Index: AcnsbsthdFb0aL0wQkKG5FACy9ZwGgAUt0XwAAt+050AALMkYA== References: <14C85D6CCBE92743AF33663BF5D24EBA02BD480B@gaalpa1msgusr7e.ugd.att.com> From: "Christer Holmberg" To: "DOLLY, MARTIN C, ATTLABS" , , X-OriginalArrivalTime: 14 Jun 2009 13:18:13.0877 (UTC) FILETIME=[925FEA50:01C9ECF2] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 13:18:08 -0000 Hi,=20 >We (ATT) are expecting HI to capture this information Yes. Both the 4244bis and target-uri approaches are based on HI. Regards, Christer ----- Original Message ----- From: Christer Holmberg To: Paul Kyzivat ; Hans Erik van Elburg Cc: DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Sent: Sun Jun 14 08:47:26 2009 Subject: RE: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) Hi Paul, I guess you can look at the To-uri if you want to know who/what the caller desired to reach. However, the ua-loose-draft describes why the To-uri approach doesn't work as a general solution for the target delivery problem. Please know that diversion may have taken place before the final target was chosen, so the To-uri may not say anything about the current target.=20 So, even for freephone the To-uri may not contain the freephone number, if the caller first tried to call something/someone else. Regards, Christer -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Sunday, June 14, 2009 12:35 AM To: Hans Erik van Elburg Cc: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: Re: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) Hans Erik van Elburg wrote: > Hi Paul, >=20 > For what would you want to use the To-uri? To decide who/what the caller desired to reach, and hence what treatment to give the call. This seems to be the key thing for the call centers that use freephone numbers. Thanks, Paul > /Hans Erik >=20 > Paul Kyzivat wrote: >> This thing about the freephone services is an ugly one. >> I've thought for a long time that the mechanism is an entirely brain=20 >> dead way to designate who should pay for a call. >> >> But it is what it is, so I guess we have to cope with it. >> >> I wonder if perhaps this is really one of the few circumstances where >> the recipient of a call ought to make call handling decisions based=20 >> on the To-uri. The reason I say this is because the "contract" with=20 >> these numbers is that the caller expects the call will be free based=20 >> on the form of the number being called. And if the caller is wrong,=20 >> it is the caller who gets charged. >> >> So, while I generally recommend that the To-uri be used for=20 >> *nothing*, it might be right here. If so, then the whole=20 >> target-uri/h-i discussion may be irrelevant to it. >> >> Thanks, >> Paul >> >> Christer Holmberg wrote: >>> Hi, >>>> I'm going to spare details, but the main different is as follows. >>>> >>>> 1) RFC 4244bis >>>> >>>> In RFC 4244bis, if the domain is responsible for the URI in the >>> Request-URI and it replacing it with a Contact, it will put a=20 >>> reg-uri flag (if the Request-URI was the AOR used for registration), >>> or reg- >>>> uri-alias (if the Request-URI was an alias for the AOR used in >>> registration). >>>> If the domain is responsible for the URI and it "maps" it to a >>> different user, then it puts a "mapped" flag. >>>> If the domain is NOT responsible for the AOR but it changes the >>> Request-URI nevertheless, then it is also marked as "mapped". >>>> Note: With loose routing, this is not supposed to happen (at=20 >>>> least in theory). >>>> >>>> This next statement is where there is a big difference: >>>> >>>> If the domain is NOT responsible for the URI, the mapping cannot=20 >>>> know >>> if the new URI is belongs to the same User than the original one.=20 >>> This is why it is mapping: it is impossible for a proxy NOT >>>> responsible for a URI to change it to something else and "know" if=20 >>>> it a >>> different user (retarget) or just a "synonym" for the same user. >>> >>> We don't think it is "impossible", and we see no reason why we=20 >>> should make that restriction without any technical justification.=20 >>> The proxy does not change the URI just for fun, with a value out of=20 >>> the blue - it does it based on some kind of knowledge/configuration. >>> >>>> 2) Target-UI >>>> >>>> In target-URI, there is an assumption that a domain NOT responsible >>>> for >>> a URI can change the URI to something AND know authoritatively that=20 >>> the new target is a "synonym" for the original target. >>> >>> Correct. >>> And, I assume the difference between "synomym" and "alias" is that a >>> synonym URI is not registered for the called user, right? >>> >>> But, one question for clarification: if the "synonym" translation is >>> done by an entity which IS reponsible for the domain, how is it tagged? >>> >>> ------------- >>> >>>> So this is what it boils down to. >>> >>> I think that is more or less what I was trying to say. >>> >>>> Can a domain NOT responsible for a target change the target AND=20 >>>> mark >>> the new target authoritatively as "belonging" to the same user? >>>> In target-URI, the assumption is yes. >>>> >>>> In 4244bis, the assumption is no (only the domain responsible for=20 >>>> the >>> URI can do so). >>> Correct. >>> >>> ------------- >>> >>>> As pointed out by Paul Kyzivat, we probably need to think on how=20 >>>> this >>> works with Tel URIs. I think for Tel URI it would be totally different. >>> >>> Yes. You raised that also in our private discussions, but we never=20 >>> discussed it in details. >>> >>> So, before we start discussing the protocol details, I think we need >>> to solve the issues above. >>> >>> Regards, >>> >>> Christer >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 From mdolly@att.com Sun Jun 14 07:01:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1205F3A6BA8 for ; Sun, 14 Jun 2009 07:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.635 X-Spam-Level: X-Spam-Status: No, score=-105.635 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCHKyR1xeL6Y for ; Sun, 14 Jun 2009 07:01:34 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id A0D743A69A0 for ; Sun, 14 Jun 2009 07:01:33 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-4.tower-146.messagelabs.com!1244988099!16157174!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 11538 invoked from network); 14 Jun 2009 14:01:39 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-4.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Jun 2009 14:01:39 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5EE1fYs031210; Sun, 14 Jun 2009 10:01:41 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5EE1bbb031201; Sun, 14 Jun 2009 10:01:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sun, 14 Jun 2009 10:01:37 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD480C@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] The functional differences between 4244bis and target-uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) Thread-Index: AcnsbsthdFb0aL0wQkKG5FACy9ZwGgAUt0XwAAt+050AALMkYAABjHlc From: "DOLLY, MARTIN C, ATTLABS" To: , , Cc: sipcore@ietf.org Subject: Re: [sipcore] The functional differences between 4244bis andtarget- uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 14:01:35 -0000 VW5kZXJzdG9vZCwgYnV0IHRoZXkgbmVlZCB0byBjYXB0dXJlIHRvbGwtZnJlZSBhbmQgc2Vydmlj ZSBudW1iZXJzLg0KDQpTZXJ2aWNlIFVSSXMgYXJlIG9ubHkgZ29vZCBmb3IgdGVybWluYXRpbmcg c2VydmljZXMNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogc2lwY29yZS1i b3VuY2VzQGlldGYub3JnIDxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogRE9MTFksIE1B UlRJTiBDLCBBVFRMQUJTOyBwa3l6aXZhdEBjaXNjby5jb20gPHBreXppdmF0QGNpc2NvLmNvbT47 IGlldGYuaGFuc2VyaWtAZ21haWwuY29tIDxpZXRmLmhhbnNlcmlrQGdtYWlsLmNvbT4NCkNjOiBz aXBjb3JlQGlldGYub3JnIDxzaXBjb3JlQGlldGYub3JnPg0KU2VudDogU3VuIEp1biAxNCAwOTox ODoxMyAyMDA5DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFRoZSBmdW5jdGlvbmFsIGRpZmZlcmVu Y2VzIGJldHdlZW4gNDI0NGJpcyBhbmR0YXJnZXQtIHVyaSAod2FzIEZXOiBJLURBY3Rpb246ZHJh ZnQtYmFybmVzLXNpcGNvcmUtcmZjNDI0NGJpcy0wMS50eHQpDQoNCg0KSGksIA0KDQo+V2UgKEFU VCkgYXJlIGV4cGVjdGluZyBISSB0byBjYXB0dXJlIHRoaXMgaW5mb3JtYXRpb24NCg0KWWVzLiBC b3RoIHRoZSA0MjQ0YmlzIGFuZCB0YXJnZXQtdXJpIGFwcHJvYWNoZXMgYXJlIGJhc2VkIG9uIEhJ Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t DQpGcm9tOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29t Pg0KVG86IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAY2lzY28uY29tPjsgSGFucyBFcmlrIHZhbiBF bGJ1cmcNCjxpZXRmLmhhbnNlcmlrQGdtYWlsLmNvbT4NCkNjOiBET0xMWSwgTUFSVElOIEMsIEFU VExBQlM7IHNpcGNvcmVAaWV0Zi5vcmcgPHNpcGNvcmVAaWV0Zi5vcmc+DQpTZW50OiBTdW4gSnVu IDE0IDA4OjQ3OjI2IDIwMDkNClN1YmplY3Q6IFJFOiBbc2lwY29yZV0gVGhlIGZ1bmN0aW9uYWwg ZGlmZmVyZW5jZXMgYmV0d2VlbiA0MjQ0YmlzIGFuZA0KdGFyZ2V0LSB1cmkgKHdhcyBGVzogSS1E IEFjdGlvbjpkcmFmdC1iYXJuZXMtc2lwY29yZS1yZmM0MjQ0YmlzLTAxLnR4dCkNCg0KDQpIaSBQ YXVsLA0KDQpJIGd1ZXNzIHlvdSBjYW4gbG9vayBhdCB0aGUgVG8tdXJpIGlmIHlvdSB3YW50IHRv IGtub3cgd2hvL3doYXQgdGhlDQpjYWxsZXIgZGVzaXJlZCB0byByZWFjaC4NCg0KSG93ZXZlciwg dGhlIHVhLWxvb3NlLWRyYWZ0IGRlc2NyaWJlcyB3aHkgdGhlIFRvLXVyaSBhcHByb2FjaCBkb2Vz bid0DQp3b3JrIGFzIGEgZ2VuZXJhbCBzb2x1dGlvbiBmb3IgdGhlIHRhcmdldCBkZWxpdmVyeSBw cm9ibGVtLiBQbGVhc2Uga25vdw0KdGhhdCBkaXZlcnNpb24gbWF5IGhhdmUgdGFrZW4gcGxhY2Ug YmVmb3JlIHRoZSBmaW5hbCB0YXJnZXQgd2FzIGNob3NlbiwNCnNvIHRoZSBUby11cmkgbWF5IG5v dCBzYXkgYW55dGhpbmcgYWJvdXQgdGhlIGN1cnJlbnQgdGFyZ2V0LiANCg0KU28sIGV2ZW4gZm9y IGZyZWVwaG9uZSB0aGUgVG8tdXJpIG1heSBub3QgY29udGFpbiB0aGUgZnJlZXBob25lIG51bWJl ciwNCmlmIHRoZSBjYWxsZXIgZmlyc3QgdHJpZWQgdG8gY2FsbCBzb21ldGhpbmcvc29tZW9uZSBl bHNlLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6aXZhdEBjaXNjby5jb21dDQpTZW50 OiBTdW5kYXksIEp1bmUgMTQsIDIwMDkgMTI6MzUgQU0NClRvOiBIYW5zIEVyaWsgdmFuIEVsYnVy Zw0KQ2M6IENocmlzdGVyIEhvbG1iZXJnOyBET0xMWSwgTUFSVElOIEMsIEFUVExBQlM7IHNpcGNv cmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gVGhlIGZ1bmN0aW9uYWwgZGlmZmVy ZW5jZXMgYmV0d2VlbiA0MjQ0YmlzIGFuZA0KdGFyZ2V0LSB1cmkgKHdhcyBGVzogSS1EIEFjdGlv bjpkcmFmdC1iYXJuZXMtc2lwY29yZS1yZmM0MjQ0YmlzLTAxLnR4dCkNCg0KDQoNCkhhbnMgRXJp ayB2YW4gRWxidXJnIHdyb3RlOg0KPiBIaSBQYXVsLA0KPiANCj4gRm9yIHdoYXQgd291bGQgeW91 IHdhbnQgdG8gdXNlIHRoZSBUby11cmk/DQoNClRvIGRlY2lkZSB3aG8vd2hhdCB0aGUgY2FsbGVy IGRlc2lyZWQgdG8gcmVhY2gsIGFuZCBoZW5jZSB3aGF0IHRyZWF0bWVudA0KdG8gZ2l2ZSB0aGUg Y2FsbC4gVGhpcyBzZWVtcyB0byBiZSB0aGUga2V5IHRoaW5nIGZvciB0aGUgY2FsbCBjZW50ZXJz DQp0aGF0IHVzZSBmcmVlcGhvbmUgbnVtYmVycy4NCg0KCVRoYW5rcywNCglQYXVsDQoNCj4gL0hh bnMgRXJpaw0KPiANCj4gUGF1bCBLeXppdmF0IHdyb3RlOg0KPj4gVGhpcyB0aGluZyBhYm91dCB0 aGUgZnJlZXBob25lIHNlcnZpY2VzIGlzIGFuIHVnbHkgb25lLg0KPj4gSSd2ZSB0aG91Z2h0IGZv ciBhIGxvbmcgdGltZSB0aGF0IHRoZSBtZWNoYW5pc20gaXMgYW4gZW50aXJlbHkgYnJhaW4gDQo+ PiBkZWFkIHdheSB0byBkZXNpZ25hdGUgd2hvIHNob3VsZCBwYXkgZm9yIGEgY2FsbC4NCj4+DQo+ PiBCdXQgaXQgaXMgd2hhdCBpdCBpcywgc28gSSBndWVzcyB3ZSBoYXZlIHRvIGNvcGUgd2l0aCBp dC4NCj4+DQo+PiBJIHdvbmRlciBpZiBwZXJoYXBzIHRoaXMgaXMgcmVhbGx5IG9uZSBvZiB0aGUg ZmV3IGNpcmN1bXN0YW5jZXMgd2hlcmUNCg0KPj4gdGhlIHJlY2lwaWVudCBvZiBhIGNhbGwgb3Vn aHQgdG8gbWFrZSBjYWxsIGhhbmRsaW5nIGRlY2lzaW9ucyBiYXNlZCANCj4+IG9uIHRoZSBUby11 cmkuIFRoZSByZWFzb24gSSBzYXkgdGhpcyBpcyBiZWNhdXNlIHRoZSAiY29udHJhY3QiIHdpdGgg DQo+PiB0aGVzZSBudW1iZXJzIGlzIHRoYXQgdGhlIGNhbGxlciBleHBlY3RzIHRoZSBjYWxsIHdp bGwgYmUgZnJlZSBiYXNlZCANCj4+IG9uIHRoZSBmb3JtIG9mIHRoZSBudW1iZXIgYmVpbmcgY2Fs bGVkLiBBbmQgaWYgdGhlIGNhbGxlciBpcyB3cm9uZywgDQo+PiBpdCBpcyB0aGUgY2FsbGVyIHdo byBnZXRzIGNoYXJnZWQuDQo+Pg0KPj4gU28sIHdoaWxlIEkgZ2VuZXJhbGx5IHJlY29tbWVuZCB0 aGF0IHRoZSBUby11cmkgYmUgdXNlZCBmb3IgDQo+PiAqbm90aGluZyosIGl0IG1pZ2h0IGJlIHJp Z2h0IGhlcmUuIElmIHNvLCB0aGVuIHRoZSB3aG9sZSANCj4+IHRhcmdldC11cmkvaC1pIGRpc2N1 c3Npb24gbWF5IGJlIGlycmVsZXZhbnQgdG8gaXQuDQo+Pg0KPj4gICAgIFRoYW5rcywNCj4+ICAg ICBQYXVsDQo+Pg0KPj4gQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6DQo+Pj4gSGksDQo+Pj4+IEkn bSBnb2luZyB0byBzcGFyZSBkZXRhaWxzLCBidXQgdGhlIG1haW4gZGlmZmVyZW50IGlzIGFzIGZv bGxvd3MuDQo+Pj4+DQo+Pj4+IDEpIFJGQyA0MjQ0YmlzDQo+Pj4+DQo+Pj4+IEluIFJGQyA0MjQ0 YmlzLCBpZiB0aGUgZG9tYWluIGlzIHJlc3BvbnNpYmxlIGZvciB0aGUgVVJJIGluIHRoZQ0KPj4+ IFJlcXVlc3QtVVJJIGFuZCBpdCByZXBsYWNpbmcgaXQgd2l0aCBhIENvbnRhY3QsIGl0IHdpbGwg cHV0IGEgDQo+Pj4gcmVnLXVyaSBmbGFnIChpZiB0aGUgUmVxdWVzdC1VUkkgd2FzIHRoZSBBT1Ig dXNlZCBmb3IgcmVnaXN0cmF0aW9uKSwNCg0KPj4+IG9yIHJlZy0NCj4+Pj4gdXJpLWFsaWFzIChp ZiB0aGUgUmVxdWVzdC1VUkkgd2FzIGFuIGFsaWFzIGZvciB0aGUgQU9SIHVzZWQgaW4NCj4+PiBy ZWdpc3RyYXRpb24pLg0KPj4+PiBJZiB0aGUgZG9tYWluIGlzIHJlc3BvbnNpYmxlIGZvciB0aGUg VVJJIGFuZCBpdCAibWFwcyIgaXQgdG8gYQ0KPj4+IGRpZmZlcmVudCB1c2VyLCB0aGVuIGl0IHB1 dHMgYSAibWFwcGVkIiBmbGFnLg0KPj4+PiBJZiB0aGUgZG9tYWluIGlzIE5PVCByZXNwb25zaWJs ZSBmb3IgdGhlIEFPUiBidXQgaXQgY2hhbmdlcyB0aGUNCj4+PiBSZXF1ZXN0LVVSSSBuZXZlcnRo ZWxlc3MsIHRoZW4gaXQgaXMgYWxzbyBtYXJrZWQgYXMgIm1hcHBlZCIuDQo+Pj4+ICAgICBOb3Rl OiBXaXRoIGxvb3NlIHJvdXRpbmcsIHRoaXMgaXMgbm90IHN1cHBvc2VkIHRvIGhhcHBlbg0KKGF0 IA0KPj4+PiBsZWFzdCBpbiB0aGVvcnkpLg0KPj4+Pg0KPj4+PiBUaGlzIG5leHQgc3RhdGVtZW50 IGlzIHdoZXJlIHRoZXJlIGlzIGEgYmlnIGRpZmZlcmVuY2U6DQo+Pj4+DQo+Pj4+IElmIHRoZSBk b21haW4gaXMgTk9UIHJlc3BvbnNpYmxlIGZvciB0aGUgVVJJLCB0aGUgbWFwcGluZyBjYW5ub3Qg DQo+Pj4+IGtub3cNCj4+PiBpZiB0aGUgbmV3IFVSSSBpcyBiZWxvbmdzIHRvIHRoZSBzYW1lIFVz ZXIgdGhhbiB0aGUgb3JpZ2luYWwgb25lLiANCj4+PiBUaGlzIGlzIHdoeSBpdCBpcyBtYXBwaW5n OiBpdCBpcyBpbXBvc3NpYmxlIGZvciBhIHByb3h5IE5PVA0KPj4+PiByZXNwb25zaWJsZSBmb3Ig YSBVUkkgdG8gY2hhbmdlIGl0IHRvIHNvbWV0aGluZyBlbHNlIGFuZCAia25vdyIgaWYgDQo+Pj4+ IGl0IGENCj4+PiBkaWZmZXJlbnQgdXNlciAocmV0YXJnZXQpIG9yIGp1c3QgYSAic3lub255bSIg Zm9yIHRoZSBzYW1lIHVzZXIuDQo+Pj4NCj4+PiBXZSBkb24ndCB0aGluayBpdCBpcyAiaW1wb3Nz aWJsZSIsIGFuZCB3ZSBzZWUgbm8gcmVhc29uIHdoeSB3ZSANCj4+PiBzaG91bGQgbWFrZSB0aGF0 IHJlc3RyaWN0aW9uIHdpdGhvdXQgYW55IHRlY2huaWNhbCBqdXN0aWZpY2F0aW9uLiANCj4+PiBU aGUgcHJveHkgZG9lcyBub3QgY2hhbmdlIHRoZSBVUkkganVzdCBmb3IgZnVuLCB3aXRoIGEgdmFs dWUgb3V0IG9mIA0KPj4+IHRoZSBibHVlIC0gaXQgZG9lcyBpdCBiYXNlZCBvbiBzb21lIGtpbmQg b2Yga25vd2xlZGdlL2NvbmZpZ3VyYXRpb24uDQo+Pj4NCj4+Pj4gMikgVGFyZ2V0LVVJDQo+Pj4+ DQo+Pj4+IEluIHRhcmdldC1VUkksIHRoZXJlIGlzIGFuIGFzc3VtcHRpb24gdGhhdCBhIGRvbWFp biBOT1QgcmVzcG9uc2libGUNCg0KPj4+PiBmb3INCj4+PiBhIFVSSSBjYW4gY2hhbmdlIHRoZSBV UkkgdG8gc29tZXRoaW5nIEFORCBrbm93IGF1dGhvcml0YXRpdmVseSB0aGF0IA0KPj4+IHRoZSBu ZXcgdGFyZ2V0IGlzIGEgInN5bm9ueW0iIGZvciB0aGUgb3JpZ2luYWwgdGFyZ2V0Lg0KPj4+DQo+ Pj4gQ29ycmVjdC4NCj4+PiBBbmQsIEkgYXNzdW1lIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gInN5 bm9teW0iIGFuZCAiYWxpYXMiIGlzIHRoYXQgYQ0KDQo+Pj4gc3lub255bSBVUkkgaXMgbm90IHJl Z2lzdGVyZWQgZm9yIHRoZSBjYWxsZWQgdXNlciwgcmlnaHQ/DQo+Pj4NCj4+PiBCdXQsIG9uZSBx dWVzdGlvbiBmb3IgY2xhcmlmaWNhdGlvbjogaWYgdGhlICJzeW5vbnltIiB0cmFuc2xhdGlvbiBp cw0KDQo+Pj4gZG9uZSBieSBhbiBlbnRpdHkgd2hpY2ggSVMgcmVwb25zaWJsZSBmb3IgdGhlIGRv bWFpbiwgaG93IGlzIGl0DQp0YWdnZWQ/DQo+Pj4NCj4+PiAtLS0tLS0tLS0tLS0tDQo+Pj4NCj4+ Pj4gU28gdGhpcyBpcyB3aGF0IGl0IGJvaWxzIGRvd24gdG8uDQo+Pj4NCj4+PiBJIHRoaW5rIHRo YXQgaXMgbW9yZSBvciBsZXNzIHdoYXQgSSB3YXMgdHJ5aW5nIHRvIHNheS4NCj4+Pg0KPj4+PiBD YW4gYSBkb21haW4gTk9UIHJlc3BvbnNpYmxlIGZvciBhIHRhcmdldCBjaGFuZ2UgdGhlIHRhcmdl dCBBTkQgDQo+Pj4+IG1hcmsNCj4+PiB0aGUgbmV3IHRhcmdldCBhdXRob3JpdGF0aXZlbHkgYXMg ImJlbG9uZ2luZyIgdG8gdGhlIHNhbWUgdXNlcj8NCj4+Pj4gSW4gdGFyZ2V0LVVSSSwgdGhlIGFz c3VtcHRpb24gaXMgeWVzLg0KPj4+Pg0KPj4+PiBJbiA0MjQ0YmlzLCB0aGUgYXNzdW1wdGlvbiBp cyBubyAob25seSB0aGUgZG9tYWluIHJlc3BvbnNpYmxlIGZvciANCj4+Pj4gdGhlDQo+Pj4gVVJJ IGNhbiBkbyBzbykuDQo+Pj4gQ29ycmVjdC4NCj4+Pg0KPj4+IC0tLS0tLS0tLS0tLS0NCj4+Pg0K Pj4+PiBBcyBwb2ludGVkIG91dCBieSBQYXVsIEt5eml2YXQsIHdlIHByb2JhYmx5IG5lZWQgdG8g dGhpbmsgb24gaG93IA0KPj4+PiB0aGlzDQo+Pj4gd29ya3Mgd2l0aCBUZWwgVVJJcy4gSSB0aGlu ayBmb3IgVGVsIFVSSSBpdCB3b3VsZCBiZSB0b3RhbGx5DQpkaWZmZXJlbnQuDQo+Pj4NCj4+PiBZ ZXMuIFlvdSByYWlzZWQgdGhhdCBhbHNvIGluIG91ciBwcml2YXRlIGRpc2N1c3Npb25zLCBidXQg d2UgbmV2ZXIgDQo+Pj4gZGlzY3Vzc2VkIGl0IGluIGRldGFpbHMuDQo+Pj4NCj4+PiBTbywgYmVm b3JlIHdlIHN0YXJ0IGRpc2N1c3NpbmcgdGhlIHByb3RvY29sIGRldGFpbHMsIEkgdGhpbmsgd2Ug bmVlZA0KDQo+Pj4gdG8gc29sdmUgdGhlIGlzc3VlcyBhYm92ZS4NCj4+Pg0KPj4+IFJlZ2FyZHMs DQo+Pj4NCj4+PiBDaHJpc3Rlcg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4+PiBzaXBjb3JlQGll dGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3Jl DQo+Pj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPj4gc2lwY29yZUBpZXRmLm9yZw0KPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+IA0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0 DQpzaXBjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NpcGNvcmUNCg== From mary.barnes@nortel.com Sun Jun 14 07:30:14 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DA8D28C0ED for ; Sun, 14 Jun 2009 07:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.935 X-Spam-Level: X-Spam-Status: No, score=-5.935 tagged_above=-999 required=5 tests=[AWL=-0.419, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+-W4UfICOP9 for ; Sun, 14 Jun 2009 07:30:12 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id BC4A428C0E8 for ; Sun, 14 Jun 2009 07:30:11 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5EEStc08786; Sun, 14 Jun 2009 14:28:55 GMT Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 14 Jun 2009 09:32:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E7D890A@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A34ABE3.7040404@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt thread-index: AcnsxOB9MDxrIA9UQiaOl1jvdTyvWQANyJ2A References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E787933@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120138y540f7c2bja62adcf942cba3a0@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E787F80@zrc2hxm0.corp.nortel.com> <9ae56b1e0906120824s24f0ddfyb9dc6d6c38651d75@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D809A@zrc2hxm0.corp.nortel.com> <4A32B08C.4010308@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D8536@zrc2hxm0.corp.nortel.com> <4A32C2EB.7070304@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E7D86CF@zrc2hxm0.corp.nortel.com> <4A3411FF.30005@gmail.com> <4A34ABE3.7040404@gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" Cc: sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 14:30:14 -0000 Hi Hans, This is a good suggestion. The MAY strength was all that could be agreed at that point in time. We have made other MAYs -> MUSTs in the doc and this one should be done as well -i.e., add an entry if the previous hop did not.=20 I will incorporate the change you suggest in the next update.=20 Thanks, Mary.=20 -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Sunday, June 14, 2009 2:51 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Just an update of my previous mail I realised I forgot one step (inserted after step 3). Already 4.3.3.1 must be clarified as it says that the proxy must add a=20 hi-entry, but it does not specify what value should be added. Further all this text seems to be written backwards instead of in=20 logical order, which makes it very hard to understand or modify. So why dont we rewrite 4.3.3.1 something like: 4.3.3.1. Adding the History-Info Header to Requests RFC3261 Section 16.6 describes the procedure executed for each target in the target set, this specification extends that procedure as follows. A proxy conforming to this specification MUST perform the following=20 steps between Step 8 and Step 9 as specified in Section 16.6 of [RFC3261] for each=20 target separately : =20 1. If a request is received that doesn't include a History-Info header,=20 a proxy conforming to this specification MUST add a History-Info=20 header with a hi-entry with the value of Request-URI from the received request. The index for this hi-entry MUST start at 1. The =20 attributes MUST be set according to the procedure as specified in=20 4.3.3.1.X. 2. If the incoming request already contains a History-Info header field, and the last hi-entry is not identical to the Request-URI of the=20 received request, MUST add a History-Info header with a hi-entry with the value of=20 Request-URI from the received request. The index for this hi-entry=20 MUST follow the rules specified in 4.3.3.1.3. The attributes=20 MUST be set according to the procedure as specified in 4.3.3.1.X. 3. If the incoming request already contains a History-Info header field, and the last hi-entry is identical to the Request-URI of the received=20 request: the attributes MUST be set according to the procedure as=20 specified in 4.3.3.1.X. 4. A proxy conforming to this specification MUST add a hi-entry with the value of the target as it forwards a Request. It is not clear why currently step 2 is somewhere hidden in 4.3.3.1.4. I also think step 1 and 2 should be mandatory evaluated. The current text=20 for step 1 is at MAY strength. If we could agree to rewrite 4.3.3.1 like this it would be much easier=20 to hook in different attribute setting behaviours, even if in the=20 future someone sees the need for a new attribute and writes a separate=20 draft for extending the mechanism. /Hans Erik Hans Erik van Elburg wrote: > Already 4.3.3.1 must be clarified as it says that the proxy must add a > hi-entry, but it does not specify what value should be added. > > Further all this text seems to be written backwards instead of in=20 > logical order, which makes it very hard to understand or modify. > > So why dont we rewrite 4.3.3.1 something like: > > > > > .3.3.1. Adding the History-Info Header to Requests > > > RFC3261 Section 16.6 describes the procedure executed for each target=20 > in the target set, this specification extends that procedure as follows. > > A proxy conforming to this specification MUST perform the following=20 > steps between > Step 8 and Step 9 as specified in Section 16.6 of [RFC3261] for each=20 > target separately : > 1. If a request is received that doesn't include a History-Info=20 > header, a proxy conforming to this specification MUST add a=20 > History-Info header with a hi-entry with the value of Request-URI=20 > from the received request. The index for this hi-entry MUST start at > 1. The attributes MUST be set according to the procedure as=20 > specified in 4.3.3.1.X. > 2. If the incoming request already contains a History-Info header=20 > field, > and the last hi-entry is not identical to the Request-URI of the=20 > received request, > MUST add a History-Info header with a hi-entry with the value of=20 > Request-URI from the received request. The index for this hi-entry=20 > MUST follow the rules specified in 4.3.3.1.3. The attributes=20 > MUST be set according to the procedure as specified in 4.3.3.1.X. > > 3. A proxy conforming to this specification MUST add a hi-entry with > the value of the target as it forwards a Request. > > > > It is not clear why currently step 2 is somewhere hidden in 4.3.3.1.4. > I also think step 1 and 2 should be mandatory evaluated. The current=20 > text for step 1 is at MAY strength. > > If we could agree to rewrite 4.3.3.1 like this it would be much easier > to hook in different attribute setting behaviours, even if in the=20 > future someone sees the need for a new attribute and writes a separate > draft for extending the mechanism. > > /Hans Erik > Mary Barnes wrote: >> Hi Hans, >> >> I think we're making progress - I understand why you do not understand >> this. We likely need to add some more text to make this clear. The way >> History-Info works now is that the tags are added to the previous/last >> hi-entry (i.e., the one in the incoming request) at the point in time >> that the request is being forwarded. This is what's described in section >> 4.3.3.1.=20 >> This means that the proxy needs to keep track of the hi-target that >> would be applied to that previous/last hi-entry for each target in the >> target list it builds per section 16.5. Then, as the proxy forwards >> the request as described in section 4.3.3.1, the proxy has the >> information as to how to appropriately tag that previous/last hi-entry. >> That's the only way it will work. But, yes, this is confusing in that >> section 4.3.3.1.4 is discussing how the information that is used when >> the request is forwarded is derived. >> So, I will add some text to clarify this in the next update to 4244bis, >> I should reword that first paragraph in section 4.3.3.1.4 as follows: >> OLD: >> An hi-target attribute MUST be included in a request forwarded by a >> proxy. The addition of the hi-target parameter MUST occur prior to >> the forwarding of the request (which may add a new hi-entry with a >> new hi-targeted-to- uri) as it is associated with the hi-targeted-to- >> uri that has been retargeted.=20 >> NEW: An hi-target attribute MUST be included in a request=20 >> forwarded by a >> proxy. The addition of the hi-target parameter MUST occur just prior >> to >> the forwarding of the request (which may add a new hi-entry with a >> new hi-targeted-to- uri) as it is associated with the hi-targeted-to- >> uri that has been retargeted. The value for the hi-target=20 >> attribute is determined by the proxy when >> it builds the target list as described in section 16.5 of=20 >> [RFC3261]. The >> subsequent paragraphs describe the processing relevant to section=20 >> 16.5 for determining the >> value of the hi-target attribute that is associated with a=20 >> specific target to >> which a request is to be forwarded and the value to which the=20 >> hi-target parameter >> MUST be set when the request is forwarded. >> >> >> Thanks, >> Mary. >> -----Original Message----- >> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Sent:=20 >> Friday, June 12, 2009 4:05 PM >> To: Barnes, Mary (RICH2:AR00) >> Cc: Christer Holmberg; sipcore@ietf.org >> Subject: Re: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> I'm trying to do it similarly 4.3.3.1.4/[4424bis], but I do not >> understand how this text works for the forked case. >> >> Because for different forks the hi-entry representing the retargeted >> R-URI could get another tag. The current text does not seem to cover >> this aspect. >> >> How is this intended to be covered by this text? >> >> /Hans Erik >> >> Mary Barnes wrote: >> =20 >>> Hi Hans, >>> >>> Just a few comments below [MB]. =20 >>> Thanks, >>> Mary. >>> >>> -----Original Message----- >>> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >>> Sent: Friday, June 12, 2009 2:46 PM >>> To: Barnes, Mary (RICH2:AR00) >>> Cc: Christer Holmberg; sipcore@ietf.org >>> Subject: Re: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> Hi Mary, >>> >>> =20 >>>> So, it's just not clear at all to me how you coordinate the addition >>>> =20 >>> of the two tags. Perhaps, it's just how that section is written, >>> =20 >>>> but again, this is my point that it's really difficult to understand >>>> =20 >>> your solution proposal when it is not described in the context of >>> =20 >>>> the current normative RFC 4244 functionality. =20 >>> The text can definitely be improved, but still the criteria for adding >>> =20 >> >> =20 >>> the tags are independent. >>> >>> I will try draft a chapter as it would look like in 4424. >>> [MB] Yes, it would help to understand this in the context of 16.5=20 >>> where you are determining the targets for the request as I can't quite >>> =20 >> >> =20 >>> see how the determination of the tags are independent. And, I say=20 >>> determination because as is, you don't add the tag until you are=20 >>> forwarding the request per section 16.6. The exception is the case of >>> =20 >> >> =20 >>> a 3xx and the redirect server has added the tag - at least per the=20 >>> 4244bis specification of redirect server and 3xx handling, which is=20 >>> actually something else missing in target-uri as this does introduce a >>> =20 >> >> =20 >>> somewhat special case now that we are adding this level of granularity >>> =20 >> >> =20 >>> in terms of the mechanism by which the target(s) are determined. [/MB] >>> >>> >>> =20 >>>> This solution also does not seem to give clear delineation between >>>> =20 >>> registered contacts versus configured URIs. I had understood > that to >>> =20 >> >> =20 >>> be important for some services. In particular, how will this=20 >>> solution support being able to identify aliases? >>> >>> Regarding the alias concept, I have no problems in adding that. But it >>> =20 >> >> =20 >>> is currently not in scope of the target-uri work, if people agree then >>> =20 >> >> =20 >>> we can add that requirement. We could reuse the definition that is=20 >>> contained in the 4424bis draft as I think that is a good definition. >>> [MB] I'm puzzled as aliases are identified as a service to be=20 >>> supported by target-uri in section 4.1. That's the exact use case that >>> =20 >> >> =20 >>> the "reg-uri-alias" tag in 4244bis will support. [/MB] >>> >>> But what is the essential difference between bindings that came=20 >>> about due to registration and those that are configured? (To me this >>> has nothing todo with aliases, in fact I think it is not a=20 >>> meaningful difference how the binding was made.) But if you have a=20 >>> requirement for that, you should maybe explain it. >>> [MB] I'm not sure we're using the term configured in the same=20 >>> context here as I think you are really talking about the entries=20 >>> that are tagged as "mapped" in 4244bis. The alias concept actually=20 >>> uses both registration and configuration - that's why it's really a=20 >>> separate mechanism by which targets are determined. This is clearly=20 >>> defined in 4244bis in the description of the "reg-uri-alias" tag. [/MB] >>> >>> >>> /Hans Erik >>> >>> Mary Barnes wrote: >>> =20 >>>> Hi Hans, >>>> =20 >>>> My confusion comes from the 3rd paragraph in section 6 (the same=20 >>>> one that confuses in terms of the unconditional addition of two=20 >>>> hi-entries), specifically this text: >>>> " When a home proxy receives a request for a user or resource for >>>> =20 >>> which >>> =20 >>>> is abstract location function returns registered contacts or >>>> configured URIs, the proxy adds two History-Info header field >>>> =20 >>> values. >>> =20 >>>> The first is the incoming request URI. Since the Request-URI >>>> identifies a user or resource for which it has a registration or >>>> configuration, the Request-URI is an AOR and thus an address for >>>> =20 >>> the >>> =20 >>>> user. The proxy adds a History-Info header field parameter, >>>> =20 >> "aor", >> =20 >>>> which indicates this. Next, the proxy inserts the contact URI >>>> =20 >>> which >>> =20 >>>> will be contained in the outgoing Request-URI." >>>> =20 >>>> (Note: this also confuses me because it is combining determining=20 >>>> request targets with the forwarding) >>>> =20 >>>> But, then later in that section, there's the following text (7th >>>> paragraph): >>>> "When a proxy receives a request for a user or resource for which >>>> =20 >> it >> =20 >>>> is responsible, then when a request URI rewrite occurs that is a >>>> routing translation, then add a History-Info header field >>>> =20 >> parameter >> =20 >>>> "routed" to the hi-entry recording the incoming request URI. >>>> Otherwise when a request URI rewrite occurs that is a mapping >>>> translation, then add a History-Info header field parameter >>>> =20 >>> "mapped" >>> =20 >>>> to the hi-entry recording the incoming request URI. " >>>> =20 >>>> So, it's just not clear at all to me how you coordinate the=20 >>>> addition of the two tags. Perhaps, it's just how that section is=20 >>>> written, but >>>> =20 >> >> =20 >>>> again, this is my point that it's really difficult to understand your >>>> =20 >> >> =20 >>>> solution proposal when it is not described in the context of the=20 >>>> current normative RFC 4244 functionality. >>>> =20 >>>> This solution also does not seem to give clear delineation between=20 >>>> registered contacts versus configured URIs. I had understood that=20 >>>> to be important for some services. In particular, how will this=20 >>>> solution >>>> =20 >> >> =20 >>>> support being able to identify aliases? >>>> =20 >>>> Thanks, >>>> Mary. >>>> =20 >>>> --------------------------------------------------------------------- >>>> - >>>> --=20 >>>> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >>>> *Sent:* Friday, June 12, 2009 10:24 AM >>>> *To:* Barnes, Mary (RICH2:AR00) >>>> *Cc:* Christer Holmberg; sipcore@ietf.org >>>> *Subject:* Re: [sipcore] FW: I-D >>>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>>> >>>> Hi Mary, >>>> >>>> I do not understand what you mean with multi stage. All the tagging >>>> can be prepared at the time that the translation is done and added at >>>> =20 >> >> =20 >>>> the time that 4244 suggests the H-I to be added. If the current=20 >>>> text suggests otherwise, then we might need to fix that. >>>> >>>> BR, >>>> /Hans Erik van Elburg >>>> >>>> >>>> On Fri, Jun 12, 2009 at 4:11 PM, Mary Barnes=20 >>>> > wrote: >>>> >>>> Hi Hans, >>>> A couple comments below [MB]. >>>> Mary. >>>> >>>> >>>> =20 >>> ---------------------------------------------------------------------- >>> --=20 >>> =20 >>>> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com >>>> ] >>>> *Sent:* Friday, June 12, 2009 3:38 AM >>>> >>>> *To:* Barnes, Mary (RICH2:AR00) >>>> *Cc:* Christer Holmberg; sipcore@ietf.org >>>> =20 >>> >>> =20 >>>> *Subject:* Re: [sipcore] FW: I-D >>>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>>> >>>> Hi Mary, >>>> >>>> Sure when we agree on the way forward we have to resolve all >>>> =20 >> these >> =20 >>>> detailed procedures and conform to the 4244 language etc. But we >>>> already agreed to integrate it into 4424bis at the moment that >>>> there is agreement about the solution. >>>> >>>> Regarding the two tag approach that is open for discussion, i >>>> think it is more clean and in general pays off to separate >>>> concepts that are independent from each other. For example a >>>> hi-entry may be routed and not be an AOR, whereas it may also be >>>> routed and also an AOR. The decisions to be taken for additions >>>> =20 >> of >> =20 >>>> these tags are independent, so there is also no need to >>>> =20 >> intertwine >> =20 >>>> procedural text for them. (It is also more clear for >>>> =20 >>> implementors.) >>> =20 >>>> [MB] This is where my major confusion is in that you say the tags >>>> are independent, BUT where in the normative RFC 3261 processing >>>> does this occur? I'm confused because the logic in section 16.5 >>>> isn't "multi-stage" (for lack of a better term), the incoming >>>> request URI is evaluated and then the new target list is >>>> constructed The tagging in 4244 is based on the mechanism by >>>> which a new target is determined . The previous hi-entry (that >>>> =20 >> in >> =20 >>>> the incoming request) is tagged at the point the request is being >>>> forwarded. I do agree that in the internal processing that >>>> information needs to exist so that the tagging at the point of >>>> forwarding the request is appropriate. [/MB] >>>> =20 >>>> >>>> BR, >>>> /Hans Erik van Elburg >>>> >>>> On Thu, Jun 11, 2009 at 11:13 PM, Mary Barnes >>>> > wrote: >>>> >>>> Christer, >>>> >>>> I reviewed the updated target-uri draft and have a few >>>> comments - well I >>>> reviewed the diff since there isn't a summary of changes in >>>> =20 >>> the >>> =20 >>>> document: >>>> >>>> 1) I had a lot of difficulty picking out the normative >>>> processing for >>>> History-Info in this document. Can you summarize the >>>> =20 >>> differences? >>> =20 >>>> 2) The reason I'm concerned about understanding how this fits >>>> with the >>>> current normative processing is because I'm not seeing >>>> precisely when >>>> these tags are added as the terminology is different than >>>> =20 >> that >> =20 >>>> used in >>>> RFC 4244 - i.e., are these two terms equivalent: >>>> RFC 4244: >>>> "... hi-entry received in the request being forwarded." >>>> >>>> target-uri: >>>> "...hi-entry recording the incoming request URI." >>>> >>>> There is no reference in terms of current History-Info >>>> processing as to >>>> when in the request processing these tags are added. >>>> >>>> 3) In particular, I'm having difficulty with this text in >>>> section 6: >>>> "When a home proxy receives a request for a user or resource >>>> =20 >>> for >>> =20 >>>> which >>>> is abstract location function returns registered contacts >>>> =20 >> or >> =20 >>>> configured URIs, the proxy adds two History-Info header >>>> field values. >>>> The first is the incoming request URI. Since the >>>> =20 >>> Request-URI >>> =20 >>>> identifies a user or resource for which it has a >>>> =20 >>> registration or >>> =20 >>>> configuration, the Request-URI is an AOR and thus an >>>> =20 >> address >> =20 >>>> for the >>>> user. The proxy adds a History-Info header field >>>> =20 >> parameter, >> =20 >>>> "aor", >>>> which indicates this. Next, the proxy inserts the contact >>>> URI which >>>> will be contained in the outgoing Request-URI." >>>> Currently, in RFC 4244, the proxy only adds that additional >>>> (first) >>>> hi-entry IF there wasn't one in the incoming request, since >>>> the UAC can >>>> initially add one when it builds the request. So, this is >>>> inconsistent >>>> with current RFC 4244. And, I think you need to define "home" >>>> proxy - >>>> that's not an RFC 3261 term - there is the concept of a >>>> =20 >> "home" >> =20 >>>> domain. >>>> >>>> 4) There is a bug in the Syntax (section 9) - the Index is >>>> =20 >> not >> =20 >>>> optional >>>> (that is an error we have fixed in the 4244bis). >>>> >>>> 5) I'm really confused about this two-stage tagging - how >>>> =20 >> does >> =20 >>>> that >>>> happen in the context of the determination of Request Targets >>>> in section >>>> 16.5 of RFC3261? Wouldn't the decisions as to the addition of >>>> the two >>>> different tags occur at the same time and thus what is the >>>> advantage of >>>> the defining the two tags - i.e., why not one tag for each >>>> combination? >>>> Also, are you proposing that the addition of the tags be >>>> mandatory - >>>> there is no normative language in the target-uri document, so >>>> =20 >>> it's >>> =20 >>>> impossible to tell. And, if you are proposing they be >>>> mandatory, your >>>> ABNF syntax needs to reflect that, thus defining a single >>>> parameter with >>>> multiple values would be necessary (which is the approach in >>>> 4244bis). >>>> >>>> >>>> 6) What is the difference (or is there a difference?) between >>>> =20 >>> the >>> =20 >>>> functionality associated with the tags in 4244bis and the >>>> =20 >> tags >> =20 >>>> defined >>>> in this document in terms of types of retargets that are >>>> =20 >> being >> =20 >>>> tagged? >>>> I think this is the crux of what we need to agree - i.e., why >>>> aren't the >>>> 4244bis tags sufficient? If there is no logical difference >>>> and it's >>>> just the words used to define the tags, then we're very close >>>> =20 >>> to >>> =20 >>>> agreement. >>>> >>>> Regards, >>>> Mary. >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Christer Holmberg >>>> =20 >> [mailto:christer.holmberg@ericsson.com >> =20 >>>> ] >>>> Sent: Thursday, June 11, 2009 3:32 PM >>>> To: Christer Holmberg; Barnes, Mary (RICH2:AR00); >>>> sipcore@ietf.org >>>> Subject: RE: [sipcore] FW: I-D >>>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>>> >>>> >>>> Here is the link to the latest version of the target-uri >>>> =20 >>> draft: >>> =20 >>>> =20 >> http://tools.ietf.org/id/draft-rosenberg-sipcore-target-uri-delivery-00. >> =20 >>> =20 >>>> txt >>>> =20 >>>> >>> - >>>> 00.%0Atxt> >>>> >>>> -----Original Message----- >>>> From: Christer Holmberg >>>> Sent: Thursday, June 11, 2009 11:31 PM >>>> To: 'Mary Barnes'; sipcore@ietf.org >>>> Subject: RE: [sipcore] FW: I-D >>>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>>> >>>> >>>> Hi, >>>> >>>> I think it is important to mention that there are still >>>> =20 >>> different >>> =20 >>>> approaches regarding the target uri delivery, and that there >>>> is another >>>> approach described in the latest version of the target-uri >>>> delivery >>>> draft (I am not sure it appears in the archieves, though, for >>>> =20 >>> some >>> =20 >>>> reason). Both approaches are based on History-Info, though. >>>> >>>> We haven't yet been able to agree on an approach, so we >>>> thought the best >>>> is to bring it to the list in order for other people to get >>>> involved. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> >>>> [mailto:sipcore-bounces@ietf.org >>>> ] On >>>> Behalf Of Mary Barnes >>>> Sent: Thursday, June 11, 2009 9:05 PM >>>> To: sipcore@ietf.org >>>> Subject: [sipcore] FW: I-D >>>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>>> >>>> Hi folks, >>>> >>>> We have made a few changes to this document which was >>>> submitted last >>>> week just to tie up some loose ends and inconsistencies, some >>>> of which >>>> Shida identified when he reviewed the -00 version. >>>> >>>> The following summarizes the high level changes in the >>>> sipcore-rfc4244bis from the sip-rfc4244bis that we discussed >>>> in San >>>> Francisco: >>>> 1) Renamed the "retarget" parameter to "target" and defined >>>> explicit >>>> tags to reflect the various mechanisms by which a Request is >>>> retargeted. >>>> All entries are now tagged. >>>> 2) Updated redirect server processing as the redirect server >>>> =20 >>> must >>> =20 >>>> capture the "target" parameter since it is the entity that >>>> knows the >>>> specific mechanism by which the new target has been >>>> =20 >>> determined. >>> =20 >>>> 3) Changed the privacy such that rather than removing entries >>>> based on >>>> the various values of the privacy header, the entries are >>>> recommended to >>>> be anonymized. >>>> 4) Updated security section >>>> 5) Updated examples to reflect the new parameter, use loose >>>> routing and >>>> fix errors/nits. >>>> 6) Editorial changes to remove redundant text and the >>>> convuluted text >>>> around optionality in the non-normative sections, which is >>>> =20 >> now >> =20 >>>> discussed >>>> appropriately in the context of the histinfo option tag. >>>> >>>> The detailed changes between the versions are summarized in >>>> =20 >>> the >>> =20 >>>> document. >>>> >>>> If you're wanting to look at a diff, I would recommend you >>>> diff against >>>> RFC 4244 rather than the earlier 4244bis documents. >>>> >>>> We'd really appreciate feedback on this approach to precisely >>>> tagging >>>> all the entries. We believe it is comprehensive and should >>>> suffice for >>>> all the use cases identified in the target-uri document, as >>>> well as any >>>> others that might arise. >>>> >>>> Thanks, >>>> Mary and Francois. >>>> >>>> -----Original Message----- >>>> From: i-d-announce-bounces@ietf.org >>>> >>>> [mailto:i-d-announce-bounces@ietf.org >>>> ] On Behalf Of >>>> Internet-Drafts@ietf.org >>>> Sent: Thursday, June 11, 2009 12:45 PM >>>> To: i-d-announce@ietf.org >>>> Subject: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt >>>> >>>> A New Internet-Draft is available from the on-line >>>> =20 >>> Internet-Drafts >>> =20 >>>> directories. >>>> >>>> Title : An Extension to the Session >>>> =20 >>> Initiation >>> =20 >>>> Protocol (SIP) for Request History Information >>>> Author(s) : M. Barnes, F. Audet >>>> Filename : >>>> =20 >>> draft-barnes-sipcore-rfc4244bis-01.txt >>> =20 >>>> Pages : 42 >>>> Date : 2009-06-11 >>>> >>>> This document defines a standard mechanism for capturing the >>>> history >>>> information associated with a Session Initiation Protocol >>>> (SIP) request. >>>> This capability enables many enhanced services by providing >>>> =20 >>> the >>> =20 >>>> information as to how and why a call arrives at a specific >>>> application >>>> or user. This document defines a new optional SIP header, >>>> History-Info, >>>> for capturing the history information in requests. >>>> >>>> A URL for this Internet-Draft is: >>>> >>>> =20 >>> http://www.ietf.org/internet-drafts/draft-barnes-sipcore-rfc4244bis-01 >>> .t >>> =20 >>>> xt >>>> =20 >>>> >>> 0 >>>> 1.t%0Axt> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail >>>> =20 >>> reader >>> =20 >>>> implementation to automatically retrieve the ASCII version of >>>> =20 >>> the >>> =20 >>>> Internet-Draft. >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >>>> >>>> =20 From pkyzivat@cisco.com Sun Jun 14 14:28:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D4493A67EA for ; Sun, 14 Jun 2009 14:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.058 X-Spam-Level: X-Spam-Status: No, score=-6.058 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0xHVcsFpT5k for ; Sun, 14 Jun 2009 14:28:26 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 32CE53A65A6 for ; Sun, 14 Jun 2009 14:28:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,218,1243814400"; d="scan'208";a="47319587" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Jun 2009 21:28:35 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5ELSZHc021670; Sun, 14 Jun 2009 17:28:35 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5ELSZcC023734; Sun, 14 Jun 2009 21:28:35 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 14 Jun 2009 17:28:35 -0400 Received: from [10.86.254.99] ([10.86.254.99]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 14 Jun 2009 17:28:34 -0400 Message-ID: <4A356B81.3030906@cisco.com> Date: Sun, 14 Jun 2009 17:28:33 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Hans Erik van Elburg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <4A340ACE.1070803@cisco.com> <4A3413DC.208@gmail.com> <4A341B74.2070300@cisco.com> <4A34A9D2.7090509@gmail.com> In-Reply-To: <4A34A9D2.7090509@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2009 21:28:34.0905 (UTC) FILETIME=[12AC8490:01C9ED37] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5458; t=1245014915; x=1245878915; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20The=20functional=20differen ces=20between=204244bis=20and=20target-=0A=20uri=20(was=20FW =3A=20I-D=20Action=3Adraft-barnes-sipcore-rfc4244bis-01.txt) |Sender:=20 |To:=20Hans=20Erik=20van=20Elburg=20; bh=qlDhJFBJBeJMN2JrYI9CyQ9GVYY1S52XpXWzGSuKgMo=; b=ZXSQBVL0sX6TzYYfB07cY1/c661F6QJ5rWWwYJjjBAMYTvf6go/HRKirKk 5P4/xYE7OVYlGkzNeJjK5z7jGx4QNX3QBR2V4fYGurTLGBq48ZYmEsD9bsu8 il1eh2Jkiy; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 21:28:27 -0000 Hans Erik van Elburg wrote: > But that does not work when a diversion to that service number takes > place. It only works for direct calls to such service number. Perhaps. That depends on *if* that is a reasonable scenario, and if so precisely what you want to happen in that case. For instance, does it really make sense for you to call me, and for me to then divert you to an 800 number? If so, is that supposed to behave as if you had called the 800 number? I realize there are many possible desired outcomes, so many strategies may be used from case to case. Thanks, Paul > /Hans Erik > > Paul Kyzivat wrote: >> >> >> Hans Erik van Elburg wrote: >>> Hi Paul, >>> >>> For what would you want to use the To-uri? >> >> To decide who/what the caller desired to reach, and hence what >> treatment to give the call. This seems to be the key thing for the >> call centers that use freephone numbers. >> >> Thanks, >> Paul >> >>> /Hans Erik >>> >>> Paul Kyzivat wrote: >>>> This thing about the freephone services is an ugly one. >>>> I've thought for a long time that the mechanism is an entirely brain >>>> dead way to designate who should pay for a call. >>>> >>>> But it is what it is, so I guess we have to cope with it. >>>> >>>> I wonder if perhaps this is really one of the few circumstances >>>> where the recipient of a call ought to make call handling decisions >>>> based on the To-uri. The reason I say this is because the "contract" >>>> with these numbers is that the caller expects the call will be free >>>> based on the form of the number being called. And if the caller is >>>> wrong, it is the caller who gets charged. >>>> >>>> So, while I generally recommend that the To-uri be used for >>>> *nothing*, it might be right here. If so, then the whole >>>> target-uri/h-i discussion may be irrelevant to it. >>>> >>>> Thanks, >>>> Paul >>>> >>>> Christer Holmberg wrote: >>>>> Hi, >>>>>> I'm going to spare details, but the main different is as follows. >>>>>> >>>>>> 1) RFC 4244bis >>>>>> >>>>>> In RFC 4244bis, if the domain is responsible for the URI in the >>>>> Request-URI and it replacing it with a Contact, it will put a reg-uri >>>>> flag (if the Request-URI was the AOR used for registration), or reg- >>>>>> uri-alias (if the Request-URI was an alias for the AOR used in >>>>> registration). >>>>>> If the domain is responsible for the URI and it "maps" it to a >>>>> different user, then it puts a "mapped" flag. >>>>>> If the domain is NOT responsible for the AOR but it changes the >>>>> Request-URI nevertheless, then it is also marked as "mapped". >>>>>> Note: With loose routing, this is not supposed to happen >>>>>> (at least in theory). >>>>>> >>>>>> This next statement is where there is a big difference: >>>>>> >>>>>> If the domain is NOT responsible for the URI, the mapping cannot know >>>>> if the new URI is belongs to the same User than the original one. This >>>>> is why it is mapping: it is impossible for a proxy NOT >>>>>> responsible for a URI to change it to something else and "know" if >>>>>> it a >>>>> different user (retarget) or just a "synonym" for the same user. >>>>> >>>>> We don't think it is "impossible", and we see no reason why we should >>>>> make that restriction without any technical justification. The proxy >>>>> does not change the URI just for fun, with a value out of the blue >>>>> - it >>>>> does it based on some kind of knowledge/configuration. >>>>> >>>>>> 2) Target-UI >>>>>> >>>>>> In target-URI, there is an assumption that a domain NOT >>>>>> responsible for >>>>> a URI can change the URI to something AND know authoritatively that >>>>> the >>>>> new target is a "synonym" for the original target. >>>>> >>>>> Correct. >>>>> And, I assume the difference between "synomym" and "alias" is that a >>>>> synonym URI is not registered for the called user, right? >>>>> >>>>> But, one question for clarification: if the "synonym" translation is >>>>> done by an entity which IS reponsible for the domain, how is it >>>>> tagged? >>>>> >>>>> ------------- >>>>> >>>>>> So this is what it boils down to. >>>>> >>>>> I think that is more or less what I was trying to say. >>>>> >>>>>> Can a domain NOT responsible for a target change the target AND mark >>>>> the new target authoritatively as "belonging" to the same user? >>>>>> In target-URI, the assumption is yes. >>>>>> >>>>>> In 4244bis, the assumption is no (only the domain responsible for the >>>>> URI can do so). >>>>> Correct. >>>>> >>>>> ------------- >>>>> >>>>>> As pointed out by Paul Kyzivat, we probably need to think on how this >>>>> works with Tel URIs. I think for Tel URI it would be totally >>>>> different. >>>>> >>>>> Yes. You raised that also in our private discussions, but we never >>>>> discussed it in details. >>>>> >>>>> So, before we start discussing the protocol details, I think we >>>>> need to >>>>> solve the issues above. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>> > From christer.holmberg@ericsson.com Sun Jun 14 22:14:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D288B3A6B39 for ; Sun, 14 Jun 2009 22:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.761 X-Spam-Level: X-Spam-Status: No, score=-5.761 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muEoPNkswOvV for ; Sun, 14 Jun 2009 22:14:41 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 1B50B3A6AC7 for ; Sun, 14 Jun 2009 22:14:40 -0700 (PDT) X-AuditID: c1b4fb3e-b7bedae0000062bb-2c-4a35d8c9093a Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 11.8B.25275.9C8D53A4; Mon, 15 Jun 2009 07:14:49 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jun 2009 07:14:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 07:14:48 +0200 Message-ID: In-Reply-To: <4A356B81.3030906@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) Thread-Index: AcntNxUoVneSHm0WQsSmwX2YZ7goFwAQNnTQ References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <4A340ACE.1070803@cisco.com> <4A3413DC.208@gmail.com> <4A341B74.2070300@cisco.com> <4A34A9D2.7090509@gmail.com> <4A356B81.3030906@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Hans Erik van Elburg" X-OriginalArrivalTime: 15 Jun 2009 05:14:49.0153 (UTC) FILETIME=[34A00310:01C9ED78] X-Brightmail-Tracker: AAAAAA== Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 05:14:43 -0000 Hi Paul, I am sure To-uri may work in some cases (eventhough I don't know how the = UAS would know). But, we agreed a long time ago (when Jonathan submitted = the ua-loose-route draft) that we were going to work on a more generic = solution... Regards, Christer =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 15. kes=E4kuuta 2009 0:29 > To: Hans Erik van Elburg > Cc: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org > Subject: Re: [sipcore] The functional differences between=20 > 4244bis and target- uri (was FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt) >=20 >=20 >=20 > Hans Erik van Elburg wrote: > > But that does not work when a diversion to that service=20 > number takes=20 > > place. It only works for direct calls to such service number. >=20 > Perhaps. That depends on *if* that is a reasonable scenario,=20 > and if so precisely what you want to happen in that case. >=20 > For instance, does it really make sense for you to call me,=20 > and for me to then divert you to an 800 number? If so, is=20 > that supposed to behave as if you had called the 800 number? >=20 > I realize there are many possible desired outcomes, so many=20 > strategies may be used from case to case. >=20 > Thanks, > Paul >=20 > > /Hans Erik > >=20 > > Paul Kyzivat wrote: > >> > >> > >> Hans Erik van Elburg wrote: > >>> Hi Paul, > >>> > >>> For what would you want to use the To-uri? > >> > >> To decide who/what the caller desired to reach, and hence what=20 > >> treatment to give the call. This seems to be the key thing for the=20 > >> call centers that use freephone numbers. > >> > >> Thanks, > >> Paul > >> > >>> /Hans Erik > >>> > >>> Paul Kyzivat wrote: > >>>> This thing about the freephone services is an ugly one. > >>>> I've thought for a long time that the mechanism is an entirely=20 > >>>> brain dead way to designate who should pay for a call. > >>>> > >>>> But it is what it is, so I guess we have to cope with it. > >>>> > >>>> I wonder if perhaps this is really one of the few circumstances=20 > >>>> where the recipient of a call ought to make call=20 > handling decisions=20 > >>>> based on the To-uri. The reason I say this is because=20 > the "contract" > >>>> with these numbers is that the caller expects the call=20 > will be free=20 > >>>> based on the form of the number being called. And if the=20 > caller is=20 > >>>> wrong, it is the caller who gets charged. > >>>> > >>>> So, while I generally recommend that the To-uri be used for=20 > >>>> *nothing*, it might be right here. If so, then the whole=20 > >>>> target-uri/h-i discussion may be irrelevant to it. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> Christer Holmberg wrote: > >>>>> Hi, > >>>>>> I'm going to spare details, but the main different is=20 > as follows. > >>>>>> > >>>>>> 1) RFC 4244bis > >>>>>> > >>>>>> In RFC 4244bis, if the domain is responsible for the URI in the > >>>>> Request-URI and it replacing it with a Contact, it will put a=20 > >>>>> reg-uri flag (if the Request-URI was the AOR used for=20 > >>>>> registration), or reg- > >>>>>> uri-alias (if the Request-URI was an alias for the AOR used in > >>>>> registration). > >>>>>> If the domain is responsible for the URI and it "maps" it to a > >>>>> different user, then it puts a "mapped" flag. > >>>>>> If the domain is NOT responsible for the AOR but it changes the > >>>>> Request-URI nevertheless, then it is also marked as "mapped". > >>>>>> Note: With loose routing, this is not supposed to=20 > happen =20 > >>>>>> (at least in theory). > >>>>>> > >>>>>> This next statement is where there is a big difference: > >>>>>> > >>>>>> If the domain is NOT responsible for the URI, the=20 > mapping cannot=20 > >>>>>> know > >>>>> if the new URI is belongs to the same User than the=20 > original one.=20 > >>>>> This is why it is mapping: it is impossible for a proxy NOT > >>>>>> responsible for a URI to change it to something else=20 > and "know"=20 > >>>>>> if it a > >>>>> different user (retarget) or just a "synonym" for the same user. > >>>>> > >>>>> We don't think it is "impossible", and we see no reason why we=20 > >>>>> should make that restriction without any technical=20 > justification.=20 > >>>>> The proxy does not change the URI just for fun, with a=20 > value out=20 > >>>>> of the blue > >>>>> - it > >>>>> does it based on some kind of knowledge/configuration. > >>>>> > >>>>>> 2) Target-UI > >>>>>> > >>>>>> In target-URI, there is an assumption that a domain NOT=20 > >>>>>> responsible for > >>>>> a URI can change the URI to something AND know authoritatively=20 > >>>>> that the new target is a "synonym" for the original target. > >>>>> > >>>>> Correct. > >>>>> And, I assume the difference between "synomym" and=20 > "alias" is that=20 > >>>>> a synonym URI is not registered for the called user, right? > >>>>> > >>>>> But, one question for clarification: if the "synonym"=20 > translation=20 > >>>>> is done by an entity which IS reponsible for the=20 > domain, how is it=20 > >>>>> tagged? > >>>>> > >>>>> ------------- > >>>>> > >>>>>> So this is what it boils down to. > >>>>> > >>>>> I think that is more or less what I was trying to say. > >>>>> > >>>>>> Can a domain NOT responsible for a target change the=20 > target AND=20 > >>>>>> mark > >>>>> the new target authoritatively as "belonging" to the same user? > >>>>>> In target-URI, the assumption is yes. > >>>>>> > >>>>>> In 4244bis, the assumption is no (only the domain=20 > responsible for=20 > >>>>>> the > >>>>> URI can do so). > >>>>> Correct. > >>>>> > >>>>> ------------- > >>>>> > >>>>>> As pointed out by Paul Kyzivat, we probably need to=20 > think on how=20 > >>>>>> this > >>>>> works with Tel URIs. I think for Tel URI it would be totally=20 > >>>>> different. > >>>>> > >>>>> Yes. You raised that also in our private discussions,=20 > but we never=20 > >>>>> discussed it in details. > >>>>> > >>>>> So, before we start discussing the protocol details, I think we=20 > >>>>> need to solve the issues above. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Christer > >>>>> _______________________________________________ > >>>>> sipcore mailing list > >>>>> sipcore@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>>> > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >=20 >=20 From pkyzivat@cisco.com Mon Jun 15 05:58:15 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 119023A6CCA for ; Mon, 15 Jun 2009 05:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKxGL2NJoMHr for ; Mon, 15 Jun 2009 05:58:13 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9A5CF3A691A for ; Mon, 15 Jun 2009 05:58:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,222,1243814400"; d="scan'208";a="47386876" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 15 Jun 2009 12:58:20 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5FCwKe0011274; Mon, 15 Jun 2009 08:58:20 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5FCwMrW019228; Mon, 15 Jun 2009 12:58:22 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 08:58:20 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 08:58:19 -0400 Message-ID: <4A364562.9030408@cisco.com> Date: Mon, 15 Jun 2009 08:58:10 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <4A340ACE.1070803@cisco.com> <4A3413DC.208@gmail.com> <4A341B74.2070300@cisco.com> <4A34A9D2.7090509@gmail.com> <4A356B81.3030906@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Jun 2009 12:58:19.0832 (UTC) FILETIME=[F514DB80:01C9EDB8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6909; t=1245070700; x=1245934700; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20The=20functional=20differen ces=20between=204244bis=20and=20target-=0A=20uri=20(was=20FW =3A=20I-D=20Action=3Adraft-barnes-sipcore-rfc4244bis-01.txt) |Sender:=20 |To:=20Christer=20Holmberg=20; bh=oz++uZxj9Wj+XVMeukzEGpz9tmHFBsAa+BnEKq7IhQU=; b=eOJZhbXfsUeTB6HeprQ1cyAnYnV4fnHjLPGphT57rBSAsczZoDpIe2suSY ccfm+dqd/b3n7sbJvUzAvFNt4701/C/mqbTZH/HtStWKo5wu7txS3Nf/U+qH l/FN3m/lqR; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 12:58:15 -0000 Christer Holmberg wrote: > Hi Paul, > > I am sure To-uri may work in some cases (eventhough I don't know how the UAS would know). But, we agreed a long time ago (when Jonathan submitted the ua-loose-route draft) that we were going to work on a more generic solution... I wasn't suggesting it as a general solution. I know we need one of those. I was suggesting that using To might be the right thing to do in a *few* cases, perhaps the freephone case. Its just another trick in the bag of tricks. As to how you would tell, I think that is a policy decision for the receiving service. Thanks, Paul > Regards, > > Christer > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: 15. kesäkuuta 2009 0:29 >> To: Hans Erik van Elburg >> Cc: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org >> Subject: Re: [sipcore] The functional differences between >> 4244bis and target- uri (was FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt) >> >> >> >> Hans Erik van Elburg wrote: >>> But that does not work when a diversion to that service >> number takes >>> place. It only works for direct calls to such service number. >> Perhaps. That depends on *if* that is a reasonable scenario, >> and if so precisely what you want to happen in that case. >> >> For instance, does it really make sense for you to call me, >> and for me to then divert you to an 800 number? If so, is >> that supposed to behave as if you had called the 800 number? >> >> I realize there are many possible desired outcomes, so many >> strategies may be used from case to case. >> >> Thanks, >> Paul >> >>> /Hans Erik >>> >>> Paul Kyzivat wrote: >>>> >>>> Hans Erik van Elburg wrote: >>>>> Hi Paul, >>>>> >>>>> For what would you want to use the To-uri? >>>> To decide who/what the caller desired to reach, and hence what >>>> treatment to give the call. This seems to be the key thing for the >>>> call centers that use freephone numbers. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> /Hans Erik >>>>> >>>>> Paul Kyzivat wrote: >>>>>> This thing about the freephone services is an ugly one. >>>>>> I've thought for a long time that the mechanism is an entirely >>>>>> brain dead way to designate who should pay for a call. >>>>>> >>>>>> But it is what it is, so I guess we have to cope with it. >>>>>> >>>>>> I wonder if perhaps this is really one of the few circumstances >>>>>> where the recipient of a call ought to make call >> handling decisions >>>>>> based on the To-uri. The reason I say this is because >> the "contract" >>>>>> with these numbers is that the caller expects the call >> will be free >>>>>> based on the form of the number being called. And if the >> caller is >>>>>> wrong, it is the caller who gets charged. >>>>>> >>>>>> So, while I generally recommend that the To-uri be used for >>>>>> *nothing*, it might be right here. If so, then the whole >>>>>> target-uri/h-i discussion may be irrelevant to it. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> Christer Holmberg wrote: >>>>>>> Hi, >>>>>>>> I'm going to spare details, but the main different is >> as follows. >>>>>>>> 1) RFC 4244bis >>>>>>>> >>>>>>>> In RFC 4244bis, if the domain is responsible for the URI in the >>>>>>> Request-URI and it replacing it with a Contact, it will put a >>>>>>> reg-uri flag (if the Request-URI was the AOR used for >>>>>>> registration), or reg- >>>>>>>> uri-alias (if the Request-URI was an alias for the AOR used in >>>>>>> registration). >>>>>>>> If the domain is responsible for the URI and it "maps" it to a >>>>>>> different user, then it puts a "mapped" flag. >>>>>>>> If the domain is NOT responsible for the AOR but it changes the >>>>>>> Request-URI nevertheless, then it is also marked as "mapped". >>>>>>>> Note: With loose routing, this is not supposed to >> happen >>>>>>>> (at least in theory). >>>>>>>> >>>>>>>> This next statement is where there is a big difference: >>>>>>>> >>>>>>>> If the domain is NOT responsible for the URI, the >> mapping cannot >>>>>>>> know >>>>>>> if the new URI is belongs to the same User than the >> original one. >>>>>>> This is why it is mapping: it is impossible for a proxy NOT >>>>>>>> responsible for a URI to change it to something else >> and "know" >>>>>>>> if it a >>>>>>> different user (retarget) or just a "synonym" for the same user. >>>>>>> >>>>>>> We don't think it is "impossible", and we see no reason why we >>>>>>> should make that restriction without any technical >> justification. >>>>>>> The proxy does not change the URI just for fun, with a >> value out >>>>>>> of the blue >>>>>>> - it >>>>>>> does it based on some kind of knowledge/configuration. >>>>>>> >>>>>>>> 2) Target-UI >>>>>>>> >>>>>>>> In target-URI, there is an assumption that a domain NOT >>>>>>>> responsible for >>>>>>> a URI can change the URI to something AND know authoritatively >>>>>>> that the new target is a "synonym" for the original target. >>>>>>> >>>>>>> Correct. >>>>>>> And, I assume the difference between "synomym" and >> "alias" is that >>>>>>> a synonym URI is not registered for the called user, right? >>>>>>> >>>>>>> But, one question for clarification: if the "synonym" >> translation >>>>>>> is done by an entity which IS reponsible for the >> domain, how is it >>>>>>> tagged? >>>>>>> >>>>>>> ------------- >>>>>>> >>>>>>>> So this is what it boils down to. >>>>>>> I think that is more or less what I was trying to say. >>>>>>> >>>>>>>> Can a domain NOT responsible for a target change the >> target AND >>>>>>>> mark >>>>>>> the new target authoritatively as "belonging" to the same user? >>>>>>>> In target-URI, the assumption is yes. >>>>>>>> >>>>>>>> In 4244bis, the assumption is no (only the domain >> responsible for >>>>>>>> the >>>>>>> URI can do so). >>>>>>> Correct. >>>>>>> >>>>>>> ------------- >>>>>>> >>>>>>>> As pointed out by Paul Kyzivat, we probably need to >> think on how >>>>>>>> this >>>>>>> works with Tel URIs. I think for Tel URI it would be totally >>>>>>> different. >>>>>>> >>>>>>> Yes. You raised that also in our private discussions, >> but we never >>>>>>> discussed it in details. >>>>>>> >>>>>>> So, before we start discussing the protocol details, I think we >>>>>>> need to solve the issues above. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> _______________________________________________ >>>>>>> sipcore mailing list >>>>>>> sipcore@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>> >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore > From salvatore.loreto@ericsson.com Mon Jun 15 06:07:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A0E93A6B4C for ; Mon, 15 Jun 2009 06:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.974 X-Spam-Level: X-Spam-Status: No, score=-6.974 tagged_above=-999 required=5 tests=[AWL=-0.725, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkjgfHr2vYNl for ; Mon, 15 Jun 2009 06:07:43 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D53AE3A6A28 for ; Mon, 15 Jun 2009 06:07:42 -0700 (PDT) X-AuditID: c1b4fb3c-b7b0bae00000673a-3a-4a364796f090 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id DB.FB.26426.697463A4; Mon, 15 Jun 2009 15:07:35 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jun 2009 15:07:34 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jun 2009 15:07:34 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1C46128A2; Mon, 15 Jun 2009 16:07:34 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CDAC0219FF; Mon, 15 Jun 2009 16:07:33 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 744F3219CD; Mon, 15 Jun 2009 16:07:33 +0300 (EEST) Message-ID: <4A364794.4050408@ericsson.com> Date: Mon, 15 Jun 2009 16:07:32 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Byron Campen References: <109101c9eae2$f8ef9890$eacec9b0$@net> <1EF42B19-CB00-48C3-9EF7-F15A36AE5CF7@estacado.net> <1244821160.3768.13.camel@victoria-pingtel-com.us.nortel.com> <85ED2F6F-EBAC-454D-858B-D3BFAF901CCA@estacado.net> <1244824893.3768.19.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 15 Jun 2009 13:07:34.0307 (UTC) FILETIME=[3F930730:01C9EDBA] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Dale Worley Subject: Re: [sipcore] [Sipping] draft-niemi-sipcore-event-rate-control-00 and forcing notifications when state has not changed X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 13:07:44 -0000 Hi there, the original idea behind the force mechanism, is that there could be situation where the client needs to receive periodically, whenever the time since the most recent notification exceeds a specified value, a full NOTIFY. That is especially true for subscriber implementations that choose to operate in semi-stateless mode, in which they immediately upon receiving and processing the NOTIFY forget the resource state. In general etags mechanism work well for : - an event package that generates few state changes, and is refreshed relatively often the majority of traffic generated may be related to subscription maintenance. -fetching and polling of resource state but I don't think it could work in general, I mean in a long Subscribe that does not generate few state changes. best regards Sal Byron Campen wrote: > > I also should have noted that I don't object to there being a force > mechanism at all; I only object to it forcing notifications to be sent > when the state is exactly the same as the last NOTIFY (I also object > to it forcing a full-state notification; if the client wants full > state, it should send a SUBSCRIBE). If you have mechanisms that can > suppress notifications, a force mechanism is a nice thing to have. I > just see no value in having doubly gratuitous full-state notifications. > > Best regards, > Byron Campen > > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From bcampen@estacado.net Mon Jun 15 07:02:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E12B3A6A16 for ; Mon, 15 Jun 2009 07:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80oeLEJ9x2gs for ; Mon, 15 Jun 2009 07:02:08 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id F0F623A68F3 for ; Mon, 15 Jun 2009 07:02:07 -0700 (PDT) Received: from dn3-233.estacado.net (dn3-233.estacado.net [172.16.3.233]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n5FE2Cd2004441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 15 Jun 2009 09:02:13 -0500 (CDT) (envelope-from bcampen@estacado.net) Message-Id: <824AEC33-1A34-47D1-9C37-34278BF9CD29@estacado.net> From: Byron Campen To: Salvatore Loreto In-Reply-To: <4A364794.4050408@ericsson.com> Content-Type: multipart/signed; boundary=Apple-Mail-21-479360347; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 15 Jun 2009 09:02:08 -0500 References: <109101c9eae2$f8ef9890$eacec9b0$@net> <1EF42B19-CB00-48C3-9EF7-F15A36AE5CF7@estacado.net> <1244821160.3768.13.camel@victoria-pingtel-com.us.nortel.com> <85ED2F6F-EBAC-454D-858B-D3BFAF901CCA@estacado.net> <1244824893.3768.19.camel@victoria-pingtel-com.us.nortel.com> <4A364794.4050408@ericsson.com> X-Mailer: Apple Mail (2.935.3) Cc: sipcore@ietf.org, Dale Worley Subject: Re: [sipcore] [Sipping] draft-niemi-sipcore-event-rate-control-00 and forcing notifications when state has not changed X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 14:02:09 -0000 --Apple-Mail-21-479360347 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit This is what refresh SUBSCRIBEs are for. Best regards, Byron Campen > Hi there, > > the original idea behind the force mechanism, is that there could be > situation where the client needs to receive periodically, whenever > the time since the most recent notification exceeds > a specified value, a full NOTIFY. That is especially true for > subscriber implementations that choose to operate in semi-stateless > mode, in which they immediately upon receiving and processing the > NOTIFY forget the resource state. > > In general etags mechanism work well for : > - an event package that generates few state changes, and is > refreshed relatively often the majority of traffic generated may be > related to subscription maintenance. > -fetching and polling of resource state > > but I don't think it could work in general, I mean in a long > Subscribe that does not generate few state changes. > > best regards > Sal > > Byron Campen wrote: >> > >> I also should have noted that I don't object to there being a >> force mechanism at all; I only object to it forcing notifications >> to be sent when the state is exactly the same as the last NOTIFY (I >> also object to it forcing a full-state notification; if the client >> wants full state, it should send a SUBSCRIBE). If you have >> mechanisms that can suppress notifications, a force mechanism is a >> nice thing to have. I just see no value in having doubly gratuitous >> full-state notifications. >> >> Best regards, >> Byron Campen >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > --Apple-Mail-21-479360347 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGZDCCAx0w ggKGoAMCAQICEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDkyMzA0MzgwNFoXDTA5MDkyMzA0Mzgw NFowazEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQxIzAhBgkqhkiG9w0BCQEWFGRvY2ZhcmFkYXlAZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIGiyvzQgsqDjR3TiFTO4nkc/VRo/eX6xKu ky4CR2QtnIPEWhNLbU5UgXdGzU3YWx/cRj5alT0auKVQ/BnjCbf3bFSzP5mIfV6KlJV89dpxKQQA 3FaDYxE3whiRPIjQh3nmqxSacBTLohlt/g8MlFyiHoNs3XcH83M3QMjMxU8pD7SgXUDaXdtqC8vV +7g3rzPmlONdJ+4vac159wuZe37WVTsFI4sYL3p/KvqT1NZhmn1cmOVWKfCVAdGLk8VEUZtWuSeM NU5CLnFvenxaSPkDeVR5h0qDpw4DQyHfWXQuKvRs1WgVeHASz87EPgncyp90yiByetvE0WIBGKiz 0QIDAQABo0cwRTA1BgNVHREELjAsgRRiY2FtcGVuQGVzdGFjYWRvLm5ldIEUZG9jZmFyYWRheUBn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQANmDZo4t+1SrO9nb8KfjN4 QtlV1gzaAa2jEsAZ369PBXdsxVz32a1JIa1KudXFfMMxtF1NRDJ0Z3ib/qq+L8B28IpkYgRWtRr+ WWm6LzJ6rm1Q85cC0VSqoIRr+NoRZjaBdqWbJC4QsPnwVSXN9jLMLkFkjcxVDSxQtEx6v1PF9zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUP SAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0Eu Y3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2f Ni/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH 1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQW7SrCyoCwnsms5MfcqmjmzAJBgUr DgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2 MTUxNDAyMDlaMCMGCSqGSIb3DQEJBDEWBBQNhw4MoIdmWlRpjmmWXOPGCWxgIDCBhQYJKwYBBAGC NxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsq AsJ7JrOTH3Kpo5swgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEBBQAEggEAMd9b KdqR6XxgO8m//2yB932OSlskxVJlkIYuQrMXne9tNRjWno8QkL5Q3wStADz3QYAOeO+qNleBW0AR AT3YZGNVSstm3wjimJNofm4JRsGzPviCfmMVrdsEd082EcKPGMa3dJK0P0WABADQpTToJUEN12uJ SjUggaprYjiokRGrr9ggZ+Qbo9HdB06F/D98XwPo3RdtHFAv/qIg5fBl4V3JzOMmgfGoW4k8UjP4 kOWFtLvivfJ3MxM8O9mFr10OtkdEYr+LAH8GqusJA3024/BcBEZxlopj4bMW8NYccx6WTnwy155o 4h+Ov9ZGpwCO7G4BYXJoFFx3F0iz2id7BAAAAAAAAA== --Apple-Mail-21-479360347-- From AUDET@nortel.com Mon Jun 15 08:36:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 998C53A6A21 for ; Mon, 15 Jun 2009 08:36:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.312 X-Spam-Level: X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iptaq18BXbMd for ; Mon, 15 Jun 2009 08:36:07 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 64DBD3A6877 for ; Mon, 15 Jun 2009 08:36:07 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5FFZmd14853; Mon, 15 Jun 2009 15:35:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 10:35:46 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E83D2CD@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) thread-index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHGKxoAB0y00w References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Christer Holmberg" , "DOLLY, MARTIN C, ATTLABS" , "Mary Barnes" , Subject: Re: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 15:36:08 -0000 Ok, this is good. At least we have a common understanding of the main sticking point. Let me think about it a little bit and see how we could address the = issue. =20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Saturday, June 13, 2009 01:07 > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS;=20 > Barnes, Mary (RICH2:AR00); sipcore@ietf.org > Subject: The functional differences between 4244bis and=20 > target- uri (was FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt) >=20 >=20 > Hi,=20 >=20 > >I'm going to spare details, but the main different is as follows. > > > >1) RFC 4244bis > > > >In RFC 4244bis, if the domain is responsible for the URI in the > Request-URI and it replacing it with a Contact, it will put a=20 > reg-uri flag (if the Request-URI was the AOR used for=20 > registration), or reg- > >uri-alias (if the Request-URI was an alias for the AOR used in > registration). > > > >If the domain is responsible for the URI and it "maps" it to a > different user, then it puts a "mapped" flag. > > > >If the domain is NOT responsible for the AOR but it changes the > Request-URI nevertheless, then it is also marked as "mapped". > > > > Note: With loose routing, this is not supposed to happen=20 > > (at least in theory). > > > >This next statement is where there is a big difference: > > > >If the domain is NOT responsible for the URI, the mapping cannot know > if the new URI is belongs to the same User than the original=20 > one. This is why it is mapping: it is impossible for a proxy NOT=20 > >responsible for a URI to change it to something else and=20 > "know" if it a > different user (retarget) or just a "synonym" for the same user. >=20 > We don't think it is "impossible", and we see no reason why=20 > we should make that restriction without any technical=20 > justification. The proxy does not change the URI just for=20 > fun, with a value out of the blue - it does it based on some=20 > kind of knowledge/configuration. >=20 > >2) Target-UI > > > >In target-URI, there is an assumption that a domain NOT=20 > responsible for > a URI can change the URI to something AND know=20 > authoritatively that the new target is a "synonym" for the=20 > original target. >=20 > Correct.=20 >=20 > And, I assume the difference between "synomym" and "alias" is=20 > that a synonym URI is not registered for the called user, right? >=20 > But, one question for clarification: if the "synonym"=20 > translation is done by an entity which IS reponsible for the=20 > domain, how is it tagged? >=20 > ------------- >=20 > >So this is what it boils down to. >=20 > I think that is more or less what I was trying to say. >=20 > >Can a domain NOT responsible for a target change the target AND mark > the new target authoritatively as "belonging" to the same user? > > > >In target-URI, the assumption is yes. > > > >In 4244bis, the assumption is no (only the domain responsible for the > URI can do so).=20 >=20 > Correct. >=20 > ------------- >=20 > >As pointed out by Paul Kyzivat, we probably need to think on how this > works with Tel URIs. I think for Tel URI it would be totally=20 > different. >=20 > Yes. You raised that also in our private discussions, but we=20 > never discussed it in details. >=20 > So, before we start discussing the protocol details, I think=20 > we need to solve the issues above.=20 >=20 >=20 > Regards, >=20 > Christer >=20 From AUDET@nortel.com Mon Jun 15 08:55:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CF0D3A6D17 for ; Mon, 15 Jun 2009 08:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuFbTeoXcjCL for ; Mon, 15 Jun 2009 08:55:47 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 069443A687D for ; Mon, 15 Jun 2009 08:55:46 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5FFpSd19486; Mon, 15 Jun 2009 15:51:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 10:51:24 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E83D36A@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A340ACE.1070803@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) thread-index: AcnsZOEvld+EcOFWRL2Op+PHvn1JyQBbDAZw References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <4A340ACE.1070803@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" , "Christer Holmberg" Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 15:55:48 -0000 Perhaps you are correct. I must admit I'm having trouble understanding the sutleties of the = freephone service.=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Saturday, June 13, 2009 13:24 > To: Christer Holmberg > Cc: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS;=20 > Barnes, Mary (RICH2:AR00); sipcore@ietf.org > Subject: Re: [sipcore] The functional differences between=20 > 4244bis and target- uri (was FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt) >=20 > This thing about the freephone services is an ugly one. > I've thought for a long time that the mechanism is an=20 > entirely brain dead way to designate who should pay for a call. >=20 > But it is what it is, so I guess we have to cope with it. >=20 > I wonder if perhaps this is really one of the few=20 > circumstances where the recipient of a call ought to make=20 > call handling decisions based on the To-uri. The reason I say=20 > this is because the "contract" with these numbers is that the=20 > caller expects the call will be free based on the form of the=20 > number being called. And if the caller is wrong, it is the=20 > caller who gets charged. >=20 > So, while I generally recommend that the To-uri be used for=20 > *nothing*, it might be right here. If so, then the whole=20 > target-uri/h-i discussion may be irrelevant to it. >=20 > Thanks, > Paul >=20 > Christer Holmberg wrote: > > Hi, > >=20 > >> I'm going to spare details, but the main different is as follows. > >> > >> 1) RFC 4244bis > >> > >> In RFC 4244bis, if the domain is responsible for the URI in the > > Request-URI and it replacing it with a Contact, it will put=20 > a reg-uri=20 > > flag (if the Request-URI was the AOR used for registration), or reg- > >> uri-alias (if the Request-URI was an alias for the AOR used in > > registration). > >> If the domain is responsible for the URI and it "maps" it to a > > different user, then it puts a "mapped" flag. > >> If the domain is NOT responsible for the AOR but it changes the > > Request-URI nevertheless, then it is also marked as "mapped". > >> Note: With loose routing, this is not supposed to happen=20 > >> (at least in theory). > >> > >> This next statement is where there is a big difference: > >> > >> If the domain is NOT responsible for the URI, the mapping=20 > cannot know > > if the new URI is belongs to the same User than the=20 > original one. This=20 > > is why it is mapping: it is impossible for a proxy NOT > >> responsible for a URI to change it to something else and=20 > "know" if it=20 > >> a > > different user (retarget) or just a "synonym" for the same user. > >=20 > > We don't think it is "impossible", and we see no reason why=20 > we should=20 > > make that restriction without any technical justification.=20 > The proxy=20 > > does not change the URI just for fun, with a value out of=20 > the blue -=20 > > it does it based on some kind of knowledge/configuration. > >=20 > >> 2) Target-UI > >> > >> In target-URI, there is an assumption that a domain NOT=20 > responsible=20 > >> for > > a URI can change the URI to something AND know authoritatively that=20 > > the new target is a "synonym" for the original target. > >=20 > > Correct.=20 > >=20 > > And, I assume the difference between "synomym" and "alias"=20 > is that a=20 > > synonym URI is not registered for the called user, right? > >=20 > > But, one question for clarification: if the "synonym"=20 > translation is=20 > > done by an entity which IS reponsible for the domain, how=20 > is it tagged? > >=20 > > ------------- > >=20 > >> So this is what it boils down to. > >=20 > > I think that is more or less what I was trying to say. > >=20 > >> Can a domain NOT responsible for a target change the=20 > target AND mark > > the new target authoritatively as "belonging" to the same user? > >> In target-URI, the assumption is yes. > >> > >> In 4244bis, the assumption is no (only the domain=20 > responsible for the > > URI can do so).=20 > >=20 > > Correct. > >=20 > > ------------- > >=20 > >> As pointed out by Paul Kyzivat, we probably need to think=20 > on how this > > works with Tel URIs. I think for Tel URI it would be=20 > totally different. > >=20 > > Yes. You raised that also in our private discussions, but we never=20 > > discussed it in details. > >=20 > > So, before we start discussing the protocol details, I=20 > think we need=20 > > to solve the issues above. > >=20 > >=20 > > Regards, > >=20 > > Christer > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 >=20 From AUDET@nortel.com Mon Jun 15 09:02:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB7328C176 for ; Mon, 15 Jun 2009 09:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LP0Y0yq0Wu2l for ; Mon, 15 Jun 2009 09:02:40 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0115F28C0E2 for ; Mon, 15 Jun 2009 09:02:39 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5FFn9x26586; Mon, 15 Jun 2009 15:49:09 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 10:50:28 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt thread-index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Christer Holmberg" , "DOLLY, MARTIN C, ATTLABS" , "Mary Barnes" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 16:02:41 -0000 then reg-uri-alias.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Saturday, June 13, 2009 01:22 > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS;=20 > Barnes, Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi,=20 >=20 > >1) RFC 4244bis > > > >In RFC 4244bis, if the domain is responsible for the URI in the > Request-URI and it replacing it with a Contact, it will put a=20 > reg-uri flag (if the Request-URI was the AOR used for=20 > registration), or reg- > >uri-alias (if the Request-URI was an alias for the AOR used in > registration). >=20 > And if the Request-URI was a "synonym" for the AOR? >=20 > Regards, >=20 > Christer >=20 >=20 From christer.holmberg@ericsson.com Mon Jun 15 10:16:46 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E2283A6AAA for ; Mon, 15 Jun 2009 10:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.793 X-Spam-Level: X-Spam-Status: No, score=-5.793 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dby773VbMLAR for ; Mon, 15 Jun 2009 10:16:45 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 40C373A69C6 for ; Mon, 15 Jun 2009 10:16:44 -0700 (PDT) X-AuditID: c1b4fb3c-b7b0bae00000673a-84-4a368205d3d4 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id D3.A3.26426.502863A4; Mon, 15 Jun 2009 19:16:54 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jun 2009 19:16:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 19:16:53 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIA= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , "DOLLY, MARTIN C, ATTLABS" , "Mary Barnes" , X-OriginalArrivalTime: 15 Jun 2009 17:16:53.0378 (UTC) FILETIME=[13E01E20:01C9EDDD] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 17:16:46 -0000 But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 -----Original Message----- From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Monday, June 15, 2009 6:50 PM To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt then reg-uri-alias.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Saturday, June 13, 2009 01:22 > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi, >=20 > >1) RFC 4244bis > > > >In RFC 4244bis, if the domain is responsible for the URI in the > Request-URI and it replacing it with a Contact, it will put a reg-uri=20 > flag (if the Request-URI was the AOR used for registration), or reg- > >uri-alias (if the Request-URI was an alias for the AOR used in > registration). >=20 > And if the Request-URI was a "synonym" for the AOR? >=20 > Regards, >=20 > Christer >=20 >=20 From pkyzivat@cisco.com Mon Jun 15 10:23:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 289643A6D27 for ; Mon, 15 Jun 2009 10:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.523 X-Spam-Level: X-Spam-Status: No, score=-6.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNPda-xL0VLf for ; Mon, 15 Jun 2009 10:23:29 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 108C73A6D1D for ; Mon, 15 Jun 2009 10:23:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,224,1243814400"; d="scan'208";a="324340367" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 15 Jun 2009 17:23:39 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5FHNd2x023291; Mon, 15 Jun 2009 10:23:39 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n5FHNcpZ025398; Mon, 15 Jun 2009 17:23:39 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 13:23:33 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 13:23:32 -0400 Message-ID: <4A368394.8050401@cisco.com> Date: Mon, 15 Jun 2009 13:23:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Shida Schubert References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <4A340ACE.1070803@cisco.com> <4A3413DC.208@gmail.com> <4A341B74.2070300@cisco.com> <4A34A9D2.7090509@gmail.com> <4A356B81.3030906@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2009 17:23:32.0631 (UTC) FILETIME=[01D94A70:01C9EDDE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6979; t=1245086619; x=1245950619; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20The=20functional=20differen ces=20between=204244bis=20and=20target-=0A=20uri=20(was=20FW =3A=20I-D=20Action=3Adraft-barnes-sipcore-rfc4244bis-01.txt) |Sender:=20; bh=mDtmg8cvVKRykUP1nlwZPc1KOm+uSvakF1C1Yjq7mOo=; b=2ah4hv9R8Wbk0OqLDIWN7TdjUFZyHENpCNEt1NrUuW/In5j23QOby4pL5F I/Inf04kMtbCDoZ2MxQUiZ4Y0AKBtIgwe3pav5fyqOAPGVtfTfb5bgweU5cW TgWcjY7WUP; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 17:23:30 -0000 This discussion is probably not worth having. I agree there are all sorts of cases where something else is needed. I was only thinking of freephone (800) service which is somewhat peculiar. But even then I don't know all the nuances that people may want to work. Lets just forget it. Thanks, Paul Shida Schubert wrote: > > I don't think it's a special case for free-dial alone. > > If service URN is used to deliver a service request such as emergency call > or directory assistance request to a local call-center, and takes a similar > approach to what's defined in phoneBCP to support devices not compliant to > service URN, the translation to service URN from the dial string will be > done > by the proxy. But the translation from 911 to "sos" will only be seen in > request URI > and not in the To header. > > So To header even without diversion is not dependable. > > Regards > Shida > > On 15-Jun-09, at 6:28 AM, Paul Kyzivat wrote: > >> >> >> Hans Erik van Elburg wrote: >>> But that does not work when a diversion to that service number takes >>> place. It only works for direct calls to such service number. >> >> Perhaps. That depends on *if* that is a reasonable scenario, and if so >> precisely what you want to happen in that case. >> >> For instance, does it really make sense for you to call me, and for me >> to then divert you to an 800 number? If so, is that supposed to behave >> as if you had called the 800 number? >> >> I realize there are many possible desired outcomes, so many strategies >> may be used from case to case. >> >> Thanks, >> Paul >> >>> /Hans Erik >>> Paul Kyzivat wrote: >>>> >>>> >>>> Hans Erik van Elburg wrote: >>>>> Hi Paul, >>>>> >>>>> For what would you want to use the To-uri? >>>> >>>> To decide who/what the caller desired to reach, and hence what >>>> treatment to give the call. This seems to be the key thing for the >>>> call centers that use freephone numbers. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> /Hans Erik >>>>> >>>>> Paul Kyzivat wrote: >>>>>> This thing about the freephone services is an ugly one. >>>>>> I've thought for a long time that the mechanism is an entirely >>>>>> brain dead way to designate who should pay for a call. >>>>>> >>>>>> But it is what it is, so I guess we have to cope with it. >>>>>> >>>>>> I wonder if perhaps this is really one of the few circumstances >>>>>> where the recipient of a call ought to make call handling >>>>>> decisions based on the To-uri. The reason I say this is because >>>>>> the "contract" with these numbers is that the caller expects the >>>>>> call will be free based on the form of the number being called. >>>>>> And if the caller is wrong, it is the caller who gets charged. >>>>>> >>>>>> So, while I generally recommend that the To-uri be used for >>>>>> *nothing*, it might be right here. If so, then the whole >>>>>> target-uri/h-i discussion may be irrelevant to it. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> Christer Holmberg wrote: >>>>>>> Hi, >>>>>>>> I'm going to spare details, but the main different is as follows. >>>>>>>> >>>>>>>> 1) RFC 4244bis >>>>>>>> >>>>>>>> In RFC 4244bis, if the domain is responsible for the URI in the >>>>>>> Request-URI and it replacing it with a Contact, it will put a >>>>>>> reg-uri >>>>>>> flag (if the Request-URI was the AOR used for registration), or reg- >>>>>>>> uri-alias (if the Request-URI was an alias for the AOR used in >>>>>>> registration). >>>>>>>> If the domain is responsible for the URI and it "maps" it to a >>>>>>> different user, then it puts a "mapped" flag. >>>>>>>> If the domain is NOT responsible for the AOR but it changes the >>>>>>> Request-URI nevertheless, then it is also marked as "mapped". >>>>>>>> Note: With loose routing, this is not supposed to happen >>>>>>>> (at least in theory). >>>>>>>> >>>>>>>> This next statement is where there is a big difference: >>>>>>>> >>>>>>>> If the domain is NOT responsible for the URI, the mapping cannot >>>>>>>> know >>>>>>> if the new URI is belongs to the same User than the original one. >>>>>>> This >>>>>>> is why it is mapping: it is impossible for a proxy NOT >>>>>>>> responsible for a URI to change it to something else and "know" >>>>>>>> if it a >>>>>>> different user (retarget) or just a "synonym" for the same user. >>>>>>> >>>>>>> We don't think it is "impossible", and we see no reason why we >>>>>>> should >>>>>>> make that restriction without any technical justification. The proxy >>>>>>> does not change the URI just for fun, with a value out of the >>>>>>> blue - it >>>>>>> does it based on some kind of knowledge/configuration. >>>>>>> >>>>>>>> 2) Target-UI >>>>>>>> >>>>>>>> In target-URI, there is an assumption that a domain NOT >>>>>>>> responsible for >>>>>>> a URI can change the URI to something AND know authoritatively >>>>>>> that the >>>>>>> new target is a "synonym" for the original target. >>>>>>> >>>>>>> Correct. >>>>>>> And, I assume the difference between "synomym" and "alias" is that a >>>>>>> synonym URI is not registered for the called user, right? >>>>>>> >>>>>>> But, one question for clarification: if the "synonym" translation is >>>>>>> done by an entity which IS reponsible for the domain, how is it >>>>>>> tagged? >>>>>>> >>>>>>> ------------- >>>>>>> >>>>>>>> So this is what it boils down to. >>>>>>> >>>>>>> I think that is more or less what I was trying to say. >>>>>>> >>>>>>>> Can a domain NOT responsible for a target change the target AND >>>>>>>> mark >>>>>>> the new target authoritatively as "belonging" to the same user? >>>>>>>> In target-URI, the assumption is yes. >>>>>>>> >>>>>>>> In 4244bis, the assumption is no (only the domain responsible >>>>>>>> for the >>>>>>> URI can do so). >>>>>>> Correct. >>>>>>> >>>>>>> ------------- >>>>>>> >>>>>>>> As pointed out by Paul Kyzivat, we probably need to think on how >>>>>>>> this >>>>>>> works with Tel URIs. I think for Tel URI it would be totally >>>>>>> different. >>>>>>> >>>>>>> Yes. You raised that also in our private discussions, but we never >>>>>>> discussed it in details. >>>>>>> >>>>>>> So, before we start discussing the protocol details, I think we >>>>>>> need to >>>>>>> solve the issues above. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> _______________________________________________ >>>>>>> sipcore mailing list >>>>>>> sipcore@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>> >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > From AUDET@nortel.com Mon Jun 15 10:47:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD8CB3A6BC2 for ; Mon, 15 Jun 2009 10:47:04 -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.164, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8MVvXn3wtkM3 for ; Mon, 15 Jun 2009 10:47:04 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id BAA683A67F9 for ; Mon, 15 Jun 2009 10:47:03 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5FHkr726633; Mon, 15 Jun 2009 17:46:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 12:46:52 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt thread-index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Christer Holmberg" , "DOLLY, MARTIN C, ATTLABS" , "Mary Barnes" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 17:47:04 -0000 Yes, we need to sort out what to do for that.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Monday, June 15, 2009 10:17 > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS;=20 > Barnes, Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 >=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, June 15, 2009 6:50 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > then reg-uri-alias.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Saturday, June 13, 2009 01:22 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > >1) RFC 4244bis > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > Request-URI and it replacing it with a Contact, it will put=20 > a reg-uri=20 > > flag (if the Request-URI was the AOR used for registration), or reg- > > >uri-alias (if the Request-URI was an alias for the AOR used in > > registration). > >=20 > > And if the Request-URI was a "synonym" for the AOR? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 >=20 From mary.barnes@nortel.com Mon Jun 15 11:10:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 080193A68CE for ; Mon, 15 Jun 2009 11:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYs6BD23LRqX for ; Mon, 15 Jun 2009 11:10:50 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E67FB3A6981 for ; Mon, 15 Jun 2009 11:10:49 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5FIAh706216; Mon, 15 Jun 2009 18:10:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 13:13:11 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt thread-index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQ References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Francois Audet" , "Christer Holmberg" , "DOLLY, MARTIN C, ATTLABS" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 18:10:51 -0000 It seems to me that the gist of this discussion has been based on the expectation that independent of how the 800 number is configured, registered or whatever at a proxy, that there is an expectation of deterministic behavior in terms of how it's tagged. So, if 800 numbers are special and they can end up tagged as either reg-uri-alias or as mapped, then perhaps the service has to know that it needs to look for either of those. ISTM that if there is a reason to preserve that it's an 800 number (i.e., and not format as a service specific uri), the service at the UAS knows that it's special, thus it would need to check the request-URIs associated with both reg-uri-alias and mapped hi-entries. I can't see how we can make it work any other way without being prescriptive of how proxy's MUST tag these entries, which is not a good idea IMHO. However, I think these numbers are either special cases at proxies or something that services know about.=20 Mary.=20 -----Original Message----- From: Audet, Francois (SC100:3055)=20 Sent: Monday, June 15, 2009 12:47 PM To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Yes, we need to sort out what to do for that.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 10:17 > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 >=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, June 15, 2009 6:50 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > then reg-uri-alias.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Saturday, June 13, 2009 01:22 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > >1) RFC 4244bis > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > Request-URI and it replacing it with a Contact, it will put > a reg-uri > > flag (if the Request-URI was the AOR used for registration), or reg- > > >uri-alias (if the Request-URI was an alias for the AOR used in > > registration). > >=20 > > And if the Request-URI was a "synonym" for the AOR? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 >=20 From christer.holmberg@ericsson.com Mon Jun 15 11:22:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298CE3A68F8 for ; Mon, 15 Jun 2009 11:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.822 X-Spam-Level: X-Spam-Status: No, score=-5.822 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeFGuXAxZC4f for ; Mon, 15 Jun 2009 11:22:42 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id D3E963A67F9 for ; Mon, 15 Jun 2009 11:22:41 -0700 (PDT) X-AuditID: c1b4fb3e-b7b1dae000006c99-5a-4a36917a3377 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 1E.0E.27801.A71963A4; Mon, 15 Jun 2009 20:22:50 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jun 2009 20:22:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 20:22:49 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexA= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Mary Barnes" , "Francois Audet" , "DOLLY, MARTIN C, ATTLABS" , X-OriginalArrivalTime: 15 Jun 2009 18:22:49.0971 (UTC) FILETIME=[4A304C30:01C9EDE6] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 18:22:43 -0000 Hi Mary, Proxies will tag entries based on the functionality they perform. Let's leave req-uri-alias for the moment. As I said earlier, one of the issues we have with 4244bis, is that "mapped" seems to be used BOTH for diversion and when an AOR is replaced with another AOR pointing to the same user - e.g. freephone. So, it is not possible to distinguish between diversion and freephone. We think one MUST be able to make that distinguishment, because you may have cases where both diversion and service number translation (e.g. freephone) occurs, and the UAS needs to know which is which. Regards, Christer =20 -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: Monday, June 15, 2009 9:13 PM To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt It seems to me that the gist of this discussion has been based on the expectation that independent of how the 800 number is configured, registered or whatever at a proxy, that there is an expectation of deterministic behavior in terms of how it's tagged. So, if 800 numbers are special and they can end up tagged as either reg-uri-alias or as mapped, then perhaps the service has to know that it needs to look for either of those. ISTM that if there is a reason to preserve that it's an 800 number (i.e., and not format as a service specific uri), the service at the UAS knows that it's special, thus it would need to check the request-URIs associated with both reg-uri-alias and mapped hi-entries. I can't see how we can make it work any other way without being prescriptive of how proxy's MUST tag these entries, which is not a good idea IMHO. However, I think these numbers are either special cases at proxies or something that services know about.=20 Mary.=20 -----Original Message----- From: Audet, Francois (SC100:3055) Sent: Monday, June 15, 2009 12:47 PM To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Yes, we need to sort out what to do for that.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 10:17 > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 >=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, June 15, 2009 6:50 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > then reg-uri-alias.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Saturday, June 13, 2009 01:22 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > >1) RFC 4244bis > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > Request-URI and it replacing it with a Contact, it will put > a reg-uri > > flag (if the Request-URI was the AOR used for registration), or reg- > > >uri-alias (if the Request-URI was an alias for the AOR used in > > registration). > >=20 > > And if the Request-URI was a "synonym" for the AOR? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 >=20 From pkyzivat@cisco.com Mon Jun 15 11:49:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 401B43A6827 for ; Mon, 15 Jun 2009 11:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihUi5ehCwVBp for ; Mon, 15 Jun 2009 11:49:44 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5CADF3A67B3 for ; Mon, 15 Jun 2009 11:49:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,224,1243814400"; d="scan'208";a="47396427" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 15 Jun 2009 18:47:23 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5FIlM6C004179; Mon, 15 Jun 2009 14:47:22 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5FIlNxT013939; Mon, 15 Jun 2009 18:47:23 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 14:47:23 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 14:47:22 -0400 Message-ID: <4A36973A.5010903@cisco.com> Date: Mon, 15 Jun 2009 14:47:22 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2009 18:47:22.0676 (UTC) FILETIME=[B7FD3F40:01C9EDE9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4372; t=1245091642; x=1245955642; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20FW=3A=20I-D=20Action=3Adraf t-barnes-sipcore-rfc4244bis-01.txt |Sender:=20 |To:=20Christer=20Holmberg=20; bh=VraniMdxnRCdKB4Rnhm7nkpgFrRxpzhyS+VLCb6s5vw=; b=EjbsETm+xP0Ao/K6yWi5CRKxIKV7w3Z2GoHty01+io4zubOXiuz7p3/vSS m3B6KNE6DXyei/PRf/XIZvreyMIJF97WsUgODCFPPkuJJuXEHkdhV044/h0L hrfidlBaUC; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 18:49:45 -0000 Do I get this right? We need to be able to tag an R-URI replacement as being any one of three different types? Yet I gather we can't all agree on what the semantics of those three types is. Is it possible that there could be *more* than three types? Thanks, Paul Christer Holmberg wrote: > Hi Mary, > > Proxies will tag entries based on the functionality they perform. > > Let's leave req-uri-alias for the moment. > > As I said earlier, one of the issues we have with 4244bis, is that > "mapped" seems to be used BOTH for diversion and when an AOR is replaced > with another AOR pointing to the same user - e.g. freephone. So, it is > not possible to distinguish between diversion and freephone. > > We think one MUST be able to make that distinguishment, because you may > have cases where both diversion and service number translation (e.g. > freephone) occurs, and the UAS needs to know which is which. > > Regards, > > Christer > > > > > > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 9:13 PM > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > It seems to me that the gist of this discussion has been based on the > expectation that independent of how the 800 number is configured, > registered or whatever at a proxy, that there is an expectation of > deterministic behavior in terms of how it's tagged. So, if 800 numbers > are special and they can end up tagged as either reg-uri-alias or as > mapped, then perhaps the service has to know that it needs to look for > either of those. ISTM that if there is a reason to preserve that it's an > 800 number (i.e., and not format as a service specific uri), the service > at the UAS knows that it's special, thus it would need to check the > request-URIs associated with both reg-uri-alias and mapped hi-entries. > I can't see how we can make it work any other way without being > prescriptive of how proxy's MUST tag these entries, which is not a good > idea IMHO. However, I think these numbers are either special cases at > proxies or something that services know about. > > Mary. > > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 12:47 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary > (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Yes, we need to sort out what to do for that. > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Monday, June 15, 2009 10:17 >> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes, >> Mary (RICH2:AR00); sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> But if it is NOT an alias (=implicitly/explicitly registered)? >> >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> Sent: Monday, June 15, 2009 6:50 PM >> To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes; >> sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> then reg-uri-alias. >> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Saturday, June 13, 2009 01:22 >>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes, >>> Mary (RICH2:AR00); sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> >>> Hi, >>> >>>> 1) RFC 4244bis >>>> >>>> In RFC 4244bis, if the domain is responsible for the URI in the >>> Request-URI and it replacing it with a Contact, it will put >> a reg-uri >>> flag (if the Request-URI was the AOR used for registration), or reg- >>>> uri-alias (if the Request-URI was an alias for the AOR used in >>> registration). >>> >>> And if the Request-URI was a "synonym" for the AOR? >>> >>> Regards, >>> >>> Christer >>> >>> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.barnes@nortel.com Mon Jun 15 11:50:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17D563A6825 for ; Mon, 15 Jun 2009 11:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.219 X-Spam-Level: X-Spam-Status: No, score=-5.219 tagged_above=-999 required=5 tests=[AWL=-1.120, BAYES_00=-2.599, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlGUjM3WQo79 for ; Mon, 15 Jun 2009 11:50:53 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id D403A3A6A6F for ; Mon, 15 Jun 2009 11:50:52 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5FIoj717196; Mon, 15 Jun 2009 18:50:45 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 13:53:15 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt thread-index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Christer Holmberg" , "Francois Audet" , "DOLLY, MARTIN C, ATTLABS" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 18:50:54 -0000 Correct. But, what I am suggesting is that you distinguish it at the UAS - I'm assuming that the target Request-URI that arrives at the UAS is something that identifies a client that handles 800 numbers. That client could be configured such that it knows to look for the original 800 number in the mapped URIs or in the reg-alias-URIs or both. Again, if you're making these 800 numbers special and allowing proxies to change them in multiple ways (i.e., non-deterministic), then if you want them tagged special, then you need special logic in the proxies to do this. That doesn't make sense to me, although you could do it that way in a closed network, in which case you can make sure to always tag them as whatever you think they should be - so we could define an additional value for the tag. But, this is what I don't think is right in terms of normal SIP request routing and forwarding, which is what the current 4244bis tags have been defined to represent.=20 Mary.=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Monday, June 15, 2009 1:23 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi Mary, Proxies will tag entries based on the functionality they perform. Let's leave req-uri-alias for the moment. As I said earlier, one of the issues we have with 4244bis, is that "mapped" seems to be used BOTH for diversion and when an AOR is replaced with another AOR pointing to the same user - e.g. freephone. So, it is not possible to distinguish between diversion and freephone. We think one MUST be able to make that distinguishment, because you may have cases where both diversion and service number translation (e.g. freephone) occurs, and the UAS needs to know which is which. Regards, Christer =20 -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Monday, June 15, 2009 9:13 PM To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt It seems to me that the gist of this discussion has been based on the expectation that independent of how the 800 number is configured, registered or whatever at a proxy, that there is an expectation of deterministic behavior in terms of how it's tagged. So, if 800 numbers are special and they can end up tagged as either reg-uri-alias or as mapped, then perhaps the service has to know that it needs to look for either of those. ISTM that if there is a reason to preserve that it's an 800 number (i.e., and not format as a service specific uri), the service at the UAS knows that it's special, thus it would need to check the request-URIs associated with both reg-uri-alias and mapped hi-entries. I can't see how we can make it work any other way without being prescriptive of how proxy's MUST tag these entries, which is not a good idea IMHO. However, I think these numbers are either special cases at proxies or something that services know about.=20 Mary.=20 -----Original Message----- From: Audet, Francois (SC100:3055) Sent: Monday, June 15, 2009 12:47 PM To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Yes, we need to sort out what to do for that.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 10:17 > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 >=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, June 15, 2009 6:50 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > then reg-uri-alias.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Saturday, June 13, 2009 01:22 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > >1) RFC 4244bis > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > Request-URI and it replacing it with a Contact, it will put > a reg-uri > > flag (if the Request-URI was the AOR used for registration), or reg- > > >uri-alias (if the Request-URI was an alias for the AOR used in > > registration). > >=20 > > And if the Request-URI was a "synonym" for the AOR? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 >=20 From mary.barnes@nortel.com Mon Jun 15 11:51:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 374F93A6A6F for ; Mon, 15 Jun 2009 11:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id latxTbaz+4bV for ; Mon, 15 Jun 2009 11:51:33 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 1259B3A69F6 for ; Mon, 15 Jun 2009 11:51:32 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5FInox16733; Mon, 15 Jun 2009 18:49:51 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 13:53:41 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E83D8DB@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A36973A.5010903@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt thread-index: Acnt6clpfuUNR3vXTMOrTDGwZ87wQgAAMkyg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <4A36973A.5010903@cisco.com> From: "Mary Barnes" To: "Paul Kyzivat" , "Christer Holmberg" Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 18:51:34 -0000 Yes. See my response ;) -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Monday, June 15, 2009 1:47 PM To: Christer Holmberg Cc: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Do I get this right? We need to be able to tag an R-URI replacement as being any one of three different types? Yet I gather we can't all agree on what the semantics of those three types is. Is it possible that there could be *more* than three types? Thanks, Paul Christer Holmberg wrote: > Hi Mary, >=20 > Proxies will tag entries based on the functionality they perform. >=20 > Let's leave req-uri-alias for the moment. >=20 > As I said earlier, one of the issues we have with 4244bis, is that=20 > "mapped" seems to be used BOTH for diversion and when an AOR is=20 > replaced with another AOR pointing to the same user - e.g. freephone.=20 > So, it is not possible to distinguish between diversion and freephone. >=20 > We think one MUST be able to make that distinguishment, because you=20 > may have cases where both diversion and service number translation (e.g. > freephone) occurs, and the UAS needs to know which is which. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > =20 >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 9:13 PM > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > It seems to me that the gist of this discussion has been based on the=20 > expectation that independent of how the 800 number is configured,=20 > registered or whatever at a proxy, that there is an expectation of=20 > deterministic behavior in terms of how it's tagged. So, if 800=20 > numbers are special and they can end up tagged as either reg-uri-alias > or as mapped, then perhaps the service has to know that it needs to=20 > look for either of those. ISTM that if there is a reason to preserve=20 > that it's an 800 number (i.e., and not format as a service specific=20 > uri), the service at the UAS knows that it's special, thus it would=20 > need to check the request-URIs associated with both reg-uri-alias and mapped hi-entries. > I can't see how we can make it work any other way without being=20 > prescriptive of how proxy's MUST tag these entries, which is not a=20 > good idea IMHO. However, I think these numbers are either special=20 > cases at proxies or something that services know about. >=20 > Mary.=20 >=20 > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 12:47 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary=20 > (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Yes, we need to sort out what to do for that.=20 >=20 >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Monday, June 15, 2009 10:17 >> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 >> Mary (RICH2:AR00); sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 >> >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> Sent: Monday, June 15, 2009 6:50 PM >> To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 >> sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> then reg-uri-alias.=20 >> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Saturday, June 13, 2009 01:22 >>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 >>> Mary (RICH2:AR00); sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> >>> Hi, >>> >>>> 1) RFC 4244bis >>>> >>>> In RFC 4244bis, if the domain is responsible for the URI in the >>> Request-URI and it replacing it with a Contact, it will put >> a reg-uri >>> flag (if the Request-URI was the AOR used for registration), or reg- >>>> uri-alias (if the Request-URI was an alias for the AOR used in >>> registration). >>> >>> And if the Request-URI was a "synonym" for the AOR? >>> >>> Regards, >>> >>> Christer >>> >>> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From shida@agnada.com Mon Jun 15 05:20:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE233A68D3 for ; Mon, 15 Jun 2009 05:20:57 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jqjz1P8gkQR for ; Mon, 15 Jun 2009 05:20:56 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [67.18.34.23]) by core3.amsl.com (Postfix) with SMTP id EE9443A6CD4 for ; Mon, 15 Jun 2009 05:20:55 -0700 (PDT) Received: (qmail 25992 invoked from network); 15 Jun 2009 12:25:02 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway03.websitewelcome.com with SMTP; 15 Jun 2009 12:25:02 -0000 Received: from flh1ajn231.tky.mesh.ad.jp ([125.195.59.231]:54937 helo=[192.168.1.5]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MGBAf-0004RZ-A2; Mon, 15 Jun 2009 07:20:17 -0500 Message-Id: From: Shida Schubert To: Paul Kyzivat In-Reply-To: <4A356B81.3030906@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 15 Jun 2009 21:20:15 +0900 References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <4A340ACE.1070803@cisco.com> <4A3413DC.208@gmail.com> <4A341B74.2070300@cisco.com> <4A34A9D2.7090509@gmail.com> <4A356B81.3030906@cisco.com> X-Mailer: Apple Mail (2.935.3) 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-Mailman-Approved-At: Mon, 15 Jun 2009 11:53:01 -0700 Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 12:20:57 -0000 I don't think it's a special case for free-dial alone. If service URN is used to deliver a service request such as emergency call or directory assistance request to a local call-center, and takes a similar approach to what's defined in phoneBCP to support devices not compliant to service URN, the translation to service URN from the dial string will be done by the proxy. But the translation from 911 to "sos" will only be seen in request URI and not in the To header. So To header even without diversion is not dependable. Regards Shida On 15-Jun-09, at 6:28 AM, Paul Kyzivat wrote: > > > Hans Erik van Elburg wrote: >> But that does not work when a diversion to that service number >> takes place. It only works for direct calls to such service number. > > Perhaps. That depends on *if* that is a reasonable scenario, and if > so precisely what you want to happen in that case. > > For instance, does it really make sense for you to call me, and for > me to then divert you to an 800 number? If so, is that supposed to > behave as if you had called the 800 number? > > I realize there are many possible desired outcomes, so many > strategies may be used from case to case. > > Thanks, > Paul > >> /Hans Erik >> Paul Kyzivat wrote: >>> >>> >>> Hans Erik van Elburg wrote: >>>> Hi Paul, >>>> >>>> For what would you want to use the To-uri? >>> >>> To decide who/what the caller desired to reach, and hence what >>> treatment to give the call. This seems to be the key thing for the >>> call centers that use freephone numbers. >>> >>> Thanks, >>> Paul >>> >>>> /Hans Erik >>>> >>>> Paul Kyzivat wrote: >>>>> This thing about the freephone services is an ugly one. >>>>> I've thought for a long time that the mechanism is an entirely >>>>> brain dead way to designate who should pay for a call. >>>>> >>>>> But it is what it is, so I guess we have to cope with it. >>>>> >>>>> I wonder if perhaps this is really one of the few circumstances >>>>> where the recipient of a call ought to make call handling >>>>> decisions based on the To-uri. The reason I say this is because >>>>> the "contract" with these numbers is that the caller expects the >>>>> call will be free based on the form of the number being called. >>>>> And if the caller is wrong, it is the caller who gets charged. >>>>> >>>>> So, while I generally recommend that the To-uri be used for >>>>> *nothing*, it might be right here. If so, then the whole target- >>>>> uri/h-i discussion may be irrelevant to it. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> Christer Holmberg wrote: >>>>>> Hi, >>>>>>> I'm going to spare details, but the main different is as >>>>>>> follows. >>>>>>> >>>>>>> 1) RFC 4244bis >>>>>>> >>>>>>> In RFC 4244bis, if the domain is responsible for the URI in the >>>>>> Request-URI and it replacing it with a Contact, it will put a >>>>>> reg-uri >>>>>> flag (if the Request-URI was the AOR used for registration), or >>>>>> reg- >>>>>>> uri-alias (if the Request-URI was an alias for the AOR used in >>>>>> registration). >>>>>>> If the domain is responsible for the URI and it "maps" it to a >>>>>> different user, then it puts a "mapped" flag. >>>>>>> If the domain is NOT responsible for the AOR but it changes the >>>>>> Request-URI nevertheless, then it is also marked as "mapped". >>>>>>> Note: With loose routing, this is not supposed to >>>>>>> happen (at least in theory). >>>>>>> >>>>>>> This next statement is where there is a big difference: >>>>>>> >>>>>>> If the domain is NOT responsible for the URI, the mapping >>>>>>> cannot know >>>>>> if the new URI is belongs to the same User than the original >>>>>> one. This >>>>>> is why it is mapping: it is impossible for a proxy NOT >>>>>>> responsible for a URI to change it to something else and >>>>>>> "know" if it a >>>>>> different user (retarget) or just a "synonym" for the same user. >>>>>> >>>>>> We don't think it is "impossible", and we see no reason why we >>>>>> should >>>>>> make that restriction without any technical justification. The >>>>>> proxy >>>>>> does not change the URI just for fun, with a value out of the >>>>>> blue - it >>>>>> does it based on some kind of knowledge/configuration. >>>>>> >>>>>>> 2) Target-UI >>>>>>> >>>>>>> In target-URI, there is an assumption that a domain NOT >>>>>>> responsible for >>>>>> a URI can change the URI to something AND know authoritatively >>>>>> that the >>>>>> new target is a "synonym" for the original target. >>>>>> >>>>>> Correct. >>>>>> And, I assume the difference between "synomym" and "alias" is >>>>>> that a >>>>>> synonym URI is not registered for the called user, right? >>>>>> >>>>>> But, one question for clarification: if the "synonym" >>>>>> translation is >>>>>> done by an entity which IS reponsible for the domain, how is it >>>>>> tagged? >>>>>> >>>>>> ------------- >>>>>> >>>>>>> So this is what it boils down to. >>>>>> >>>>>> I think that is more or less what I was trying to say. >>>>>> >>>>>>> Can a domain NOT responsible for a target change the target >>>>>>> AND mark >>>>>> the new target authoritatively as "belonging" to the same user? >>>>>>> In target-URI, the assumption is yes. >>>>>>> >>>>>>> In 4244bis, the assumption is no (only the domain responsible >>>>>>> for the >>>>>> URI can do so). >>>>>> Correct. >>>>>> >>>>>> ------------- >>>>>> >>>>>>> As pointed out by Paul Kyzivat, we probably need to think on >>>>>>> how this >>>>>> works with Tel URIs. I think for Tel URI it would be totally >>>>>> different. >>>>>> >>>>>> Yes. You raised that also in our private discussions, but we >>>>>> never >>>>>> discussed it in details. >>>>>> >>>>>> So, before we start discussing the protocol details, I think we >>>>>> need to >>>>>> solve the issues above. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From mdolly@att.com Mon Jun 15 11:58:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 822253A6CCD for ; Mon, 15 Jun 2009 11:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.152 X-Spam-Level: X-Spam-Status: No, score=-106.152 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgtW-Cy7cVyG for ; Mon, 15 Jun 2009 11:58:32 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 5F6323A6B41 for ; Mon, 15 Jun 2009 11:58:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-6.tower-120.messagelabs.com!1245092320!38314832!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 11122 invoked from network); 15 Jun 2009 18:58:41 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-6.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Jun 2009 18:58:41 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5FIwef4020187 for ; Mon, 15 Jun 2009 14:58:40 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5FIwZYs020115 for ; Mon, 15 Jun 2009 14:58:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 15 Jun 2009 14:58:34 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD4812@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] The functional differences between 4244bis andtarget- uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) Thread-Index: Acnt6o0tK2T5ZCZ6Qaq77or1EwURGAAALvDp From: "DOLLY, MARTIN C, ATTLABS" To: , Cc: sipcore@ietf.org Subject: Re: [sipcore] The functional differences between 4244bis andtarget- uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 18:58:33 -0000 U2ltcGxlIHJlcXVpcmVtZW50OiBjYXB0dXJlIEFMTCByZXRhcmdldCBpbmZvcm1hdGlvbiBpbiBI SS4gUGVyaW9kDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IHNpcGNvcmUt Ym91bmNlc0BpZXRmLm9yZyA8c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPg0KVG86IFBhdWwgS3l6 aXZhdCA8cGt5eml2YXRAY2lzY28uY29tPg0KQ2M6IERPTExZLCBNQVJUSU4gQywgQVRUTEFCUzsg c2lwY29yZUBpZXRmLm9yZyA8c2lwY29yZUBpZXRmLm9yZz4NClNlbnQ6IE1vbiBKdW4gMTUgMDg6 MjA6MTUgMjAwOQ0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBUaGUgZnVuY3Rpb25hbCBkaWZmZXJl bmNlcyBiZXR3ZWVuIDQyNDRiaXMgYW5kdGFyZ2V0LSB1cmkgKHdhcyBGVzogSS1EQWN0aW9uOmRy YWZ0LWJhcm5lcy1zaXBjb3JlLXJmYzQyNDRiaXMtMDEudHh0KQ0KDQoNCiAgSSBkb24ndCB0aGlu ayBpdCdzIGEgc3BlY2lhbCBjYXNlIGZvciBmcmVlLWRpYWwgYWxvbmUuDQoNCiAgSWYgc2Vydmlj ZSBVUk4gaXMgdXNlZCB0byBkZWxpdmVyIGEgc2VydmljZSByZXF1ZXN0IHN1Y2ggYXMgIA0KZW1l cmdlbmN5IGNhbGwNCm9yIGRpcmVjdG9yeSBhc3Npc3RhbmNlIHJlcXVlc3QgdG8gYSBsb2NhbCBj YWxsLWNlbnRlciwgYW5kIHRha2VzIGEgIA0Kc2ltaWxhcg0KYXBwcm9hY2ggdG8gd2hhdCdzIGRl ZmluZWQgaW4gcGhvbmVCQ1AgdG8gc3VwcG9ydCBkZXZpY2VzIG5vdCAgDQpjb21wbGlhbnQgdG8N CnNlcnZpY2UgVVJOLCB0aGUgdHJhbnNsYXRpb24gdG8gc2VydmljZSBVUk4gZnJvbSB0aGUgZGlh bCBzdHJpbmcgd2lsbCAgDQpiZSBkb25lDQpieSB0aGUgcHJveHkuIEJ1dCB0aGUgdHJhbnNsYXRp b24gZnJvbSA5MTEgdG8gInNvcyIgd2lsbCBvbmx5IGJlIHNlZW4gIA0KaW4gcmVxdWVzdCBVUkkN CmFuZCBub3QgaW4gdGhlIFRvIGhlYWRlci4NCg0KICBTbyBUbyBoZWFkZXIgZXZlbiB3aXRob3V0 IGRpdmVyc2lvbiBpcyBub3QgZGVwZW5kYWJsZS4NCg0KICBSZWdhcmRzDQogICBTaGlkYQ0KDQpP biAxNS1KdW4tMDksIGF0IDY6MjggQU0sIFBhdWwgS3l6aXZhdCB3cm90ZToNCg0KPg0KPg0KPiBI YW5zIEVyaWsgdmFuIEVsYnVyZyB3cm90ZToNCj4+IEJ1dCB0aGF0IGRvZXMgbm90IHdvcmsgd2hl biBhIGRpdmVyc2lvbiB0byB0aGF0IHNlcnZpY2UgbnVtYmVyICANCj4+IHRha2VzIHBsYWNlLiBJ dCBvbmx5IHdvcmtzIGZvciBkaXJlY3QgY2FsbHMgdG8gc3VjaCBzZXJ2aWNlIG51bWJlci4NCj4N Cj4gUGVyaGFwcy4gVGhhdCBkZXBlbmRzIG9uICppZiogdGhhdCBpcyBhIHJlYXNvbmFibGUgc2Nl bmFyaW8sIGFuZCBpZiAgDQo+IHNvIHByZWNpc2VseSB3aGF0IHlvdSB3YW50IHRvIGhhcHBlbiBp biB0aGF0IGNhc2UuDQo+DQo+IEZvciBpbnN0YW5jZSwgZG9lcyBpdCByZWFsbHkgbWFrZSBzZW5z ZSBmb3IgeW91IHRvIGNhbGwgbWUsIGFuZCBmb3IgIA0KPiBtZSB0byB0aGVuIGRpdmVydCB5b3Ug dG8gYW4gODAwIG51bWJlcj8gSWYgc28sIGlzIHRoYXQgc3VwcG9zZWQgdG8gIA0KPiBiZWhhdmUg YXMgaWYgeW91IGhhZCBjYWxsZWQgdGhlIDgwMCBudW1iZXI/DQo+DQo+IEkgcmVhbGl6ZSB0aGVy ZSBhcmUgbWFueSBwb3NzaWJsZSBkZXNpcmVkIG91dGNvbWVzLCBzbyBtYW55ICANCj4gc3RyYXRl Z2llcyBtYXkgYmUgdXNlZCBmcm9tIGNhc2UgdG8gY2FzZS4NCj4NCj4gCVRoYW5rcywNCj4gCVBh dWwNCj4NCj4+IC9IYW5zIEVyaWsNCj4+IFBhdWwgS3l6aXZhdCB3cm90ZToNCj4+Pg0KPj4+DQo+ Pj4gSGFucyBFcmlrIHZhbiBFbGJ1cmcgd3JvdGU6DQo+Pj4+IEhpIFBhdWwsDQo+Pj4+DQo+Pj4+ IEZvciB3aGF0IHdvdWxkIHlvdSB3YW50IHRvIHVzZSB0aGUgVG8tdXJpPw0KPj4+DQo+Pj4gVG8g ZGVjaWRlIHdoby93aGF0IHRoZSBjYWxsZXIgZGVzaXJlZCB0byByZWFjaCwgYW5kIGhlbmNlIHdo YXQgIA0KPj4+IHRyZWF0bWVudCB0byBnaXZlIHRoZSBjYWxsLiBUaGlzIHNlZW1zIHRvIGJlIHRo ZSBrZXkgdGhpbmcgZm9yIHRoZSAgDQo+Pj4gY2FsbCBjZW50ZXJzIHRoYXQgdXNlIGZyZWVwaG9u ZSBudW1iZXJzLg0KPj4+DQo+Pj4gICAgVGhhbmtzLA0KPj4+ICAgIFBhdWwNCj4+Pg0KPj4+PiAv SGFucyBFcmlrDQo+Pj4+DQo+Pj4+IFBhdWwgS3l6aXZhdCB3cm90ZToNCj4+Pj4+IFRoaXMgdGhp bmcgYWJvdXQgdGhlIGZyZWVwaG9uZSBzZXJ2aWNlcyBpcyBhbiB1Z2x5IG9uZS4NCj4+Pj4+IEkn dmUgdGhvdWdodCBmb3IgYSBsb25nIHRpbWUgdGhhdCB0aGUgbWVjaGFuaXNtIGlzIGFuIGVudGly ZWx5ICANCj4+Pj4+IGJyYWluIGRlYWQgd2F5IHRvIGRlc2lnbmF0ZSB3aG8gc2hvdWxkIHBheSBm b3IgYSBjYWxsLg0KPj4+Pj4NCj4+Pj4+IEJ1dCBpdCBpcyB3aGF0IGl0IGlzLCBzbyBJIGd1ZXNz IHdlIGhhdmUgdG8gY29wZSB3aXRoIGl0Lg0KPj4+Pj4NCj4+Pj4+IEkgd29uZGVyIGlmIHBlcmhh cHMgdGhpcyBpcyByZWFsbHkgb25lIG9mIHRoZSBmZXcgY2lyY3Vtc3RhbmNlcyAgDQo+Pj4+PiB3 aGVyZSB0aGUgcmVjaXBpZW50IG9mIGEgY2FsbCBvdWdodCB0byBtYWtlIGNhbGwgaGFuZGxpbmcg IA0KPj4+Pj4gZGVjaXNpb25zIGJhc2VkIG9uIHRoZSBUby11cmkuIFRoZSByZWFzb24gSSBzYXkg dGhpcyBpcyBiZWNhdXNlICANCj4+Pj4+IHRoZSAiY29udHJhY3QiIHdpdGggdGhlc2UgbnVtYmVy cyBpcyB0aGF0IHRoZSBjYWxsZXIgZXhwZWN0cyB0aGUgIA0KPj4+Pj4gY2FsbCB3aWxsIGJlIGZy ZWUgYmFzZWQgb24gdGhlIGZvcm0gb2YgdGhlIG51bWJlciBiZWluZyBjYWxsZWQuICANCj4+Pj4+ IEFuZCBpZiB0aGUgY2FsbGVyIGlzIHdyb25nLCBpdCBpcyB0aGUgY2FsbGVyIHdobyBnZXRzIGNo YXJnZWQuDQo+Pj4+Pg0KPj4+Pj4gU28sIHdoaWxlIEkgZ2VuZXJhbGx5IHJlY29tbWVuZCB0aGF0 IHRoZSBUby11cmkgYmUgdXNlZCBmb3IgIA0KPj4+Pj4gKm5vdGhpbmcqLCBpdCBtaWdodCBiZSBy aWdodCBoZXJlLiBJZiBzbywgdGhlbiB0aGUgd2hvbGUgdGFyZ2V0LSANCj4+Pj4+IHVyaS9oLWkg ZGlzY3Vzc2lvbiBtYXkgYmUgaXJyZWxldmFudCB0byBpdC4NCj4+Pj4+DQo+Pj4+PiAgICBUaGFu a3MsDQo+Pj4+PiAgICBQYXVsDQo+Pj4+Pg0KPj4+Pj4gQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6 DQo+Pj4+Pj4gSGksDQo+Pj4+Pj4+IEknbSBnb2luZyB0byBzcGFyZSBkZXRhaWxzLCBidXQgdGhl IG1haW4gZGlmZmVyZW50IGlzIGFzICANCj4+Pj4+Pj4gZm9sbG93cy4NCj4+Pj4+Pj4NCj4+Pj4+ Pj4gMSkgUkZDIDQyNDRiaXMNCj4+Pj4+Pj4NCj4+Pj4+Pj4gSW4gUkZDIDQyNDRiaXMsIGlmIHRo ZSBkb21haW4gaXMgcmVzcG9uc2libGUgZm9yIHRoZSBVUkkgaW4gdGhlDQo+Pj4+Pj4gUmVxdWVz dC1VUkkgYW5kIGl0IHJlcGxhY2luZyBpdCB3aXRoIGEgQ29udGFjdCwgaXQgd2lsbCBwdXQgYSAg DQo+Pj4+Pj4gcmVnLXVyaQ0KPj4+Pj4+IGZsYWcgKGlmIHRoZSBSZXF1ZXN0LVVSSSB3YXMgdGhl IEFPUiB1c2VkIGZvciByZWdpc3RyYXRpb24pLCBvciAgDQo+Pj4+Pj4gcmVnLQ0KPj4+Pj4+PiB1 cmktYWxpYXMgKGlmIHRoZSBSZXF1ZXN0LVVSSSB3YXMgYW4gYWxpYXMgZm9yIHRoZSBBT1IgdXNl ZCBpbg0KPj4+Pj4+IHJlZ2lzdHJhdGlvbikuDQo+Pj4+Pj4+IElmIHRoZSBkb21haW4gaXMgcmVz cG9uc2libGUgZm9yIHRoZSBVUkkgYW5kIGl0ICJtYXBzIiBpdCB0byBhDQo+Pj4+Pj4gZGlmZmVy ZW50IHVzZXIsIHRoZW4gaXQgcHV0cyBhICJtYXBwZWQiIGZsYWcuDQo+Pj4+Pj4+IElmIHRoZSBk b21haW4gaXMgTk9UIHJlc3BvbnNpYmxlIGZvciB0aGUgQU9SIGJ1dCBpdCBjaGFuZ2VzIHRoZQ0K Pj4+Pj4+IFJlcXVlc3QtVVJJIG5ldmVydGhlbGVzcywgdGhlbiBpdCBpcyBhbHNvIG1hcmtlZCBh cyAibWFwcGVkIi4NCj4+Pj4+Pj4gICAgTm90ZTogV2l0aCBsb29zZSByb3V0aW5nLCB0aGlzIGlz IG5vdCBzdXBwb3NlZCB0byAgDQo+Pj4+Pj4+IGhhcHBlbiAgICAgKGF0IGxlYXN0IGluIHRoZW9y eSkuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoaXMgbmV4dCBzdGF0ZW1lbnQgaXMgd2hlcmUgdGhlcmUg aXMgYSBiaWcgZGlmZmVyZW5jZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4gSWYgdGhlIGRvbWFpbiBpcyBO T1QgcmVzcG9uc2libGUgZm9yIHRoZSBVUkksIHRoZSBtYXBwaW5nICANCj4+Pj4+Pj4gY2Fubm90 IGtub3cNCj4+Pj4+PiBpZiB0aGUgbmV3IFVSSSBpcyBiZWxvbmdzIHRvIHRoZSBzYW1lIFVzZXIg dGhhbiB0aGUgb3JpZ2luYWwgIA0KPj4+Pj4+IG9uZS4gVGhpcw0KPj4+Pj4+IGlzIHdoeSBpdCBp cyBtYXBwaW5nOiBpdCBpcyBpbXBvc3NpYmxlIGZvciBhIHByb3h5IE5PVA0KPj4+Pj4+PiByZXNw b25zaWJsZSBmb3IgYSBVUkkgdG8gY2hhbmdlIGl0IHRvIHNvbWV0aGluZyBlbHNlIGFuZCAgDQo+ Pj4+Pj4+ICJrbm93IiBpZiBpdCBhDQo+Pj4+Pj4gZGlmZmVyZW50IHVzZXIgKHJldGFyZ2V0KSBv ciBqdXN0IGEgInN5bm9ueW0iIGZvciB0aGUgc2FtZSB1c2VyLg0KPj4+Pj4+DQo+Pj4+Pj4gV2Ug ZG9uJ3QgdGhpbmsgaXQgaXMgImltcG9zc2libGUiLCBhbmQgd2Ugc2VlIG5vIHJlYXNvbiB3aHkg d2UgIA0KPj4+Pj4+IHNob3VsZA0KPj4+Pj4+IG1ha2UgdGhhdCByZXN0cmljdGlvbiB3aXRob3V0 IGFueSB0ZWNobmljYWwganVzdGlmaWNhdGlvbi4gVGhlICANCj4+Pj4+PiBwcm94eQ0KPj4+Pj4+ IGRvZXMgbm90IGNoYW5nZSB0aGUgVVJJIGp1c3QgZm9yIGZ1biwgd2l0aCBhIHZhbHVlIG91dCBv ZiB0aGUgIA0KPj4+Pj4+IGJsdWUgLSBpdA0KPj4+Pj4+IGRvZXMgaXQgYmFzZWQgb24gc29tZSBr aW5kIG9mIGtub3dsZWRnZS9jb25maWd1cmF0aW9uLg0KPj4+Pj4+DQo+Pj4+Pj4+IDIpIFRhcmdl dC1VSQ0KPj4+Pj4+Pg0KPj4+Pj4+PiBJbiB0YXJnZXQtVVJJLCB0aGVyZSBpcyBhbiBhc3N1bXB0 aW9uIHRoYXQgYSBkb21haW4gTk9UICANCj4+Pj4+Pj4gcmVzcG9uc2libGUgZm9yDQo+Pj4+Pj4g YSBVUkkgY2FuIGNoYW5nZSB0aGUgVVJJIHRvIHNvbWV0aGluZyBBTkQga25vdyBhdXRob3JpdGF0 aXZlbHkgIA0KPj4+Pj4+IHRoYXQgdGhlDQo+Pj4+Pj4gbmV3IHRhcmdldCBpcyBhICJzeW5vbnlt IiBmb3IgdGhlIG9yaWdpbmFsIHRhcmdldC4NCj4+Pj4+Pg0KPj4+Pj4+IENvcnJlY3QuDQo+Pj4+ Pj4gQW5kLCBJIGFzc3VtZSB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuICJzeW5vbXltIiBhbmQgImFs aWFzIiBpcyAgDQo+Pj4+Pj4gdGhhdCBhDQo+Pj4+Pj4gc3lub255bSBVUkkgaXMgbm90IHJlZ2lz dGVyZWQgZm9yIHRoZSBjYWxsZWQgdXNlciwgcmlnaHQ/DQo+Pj4+Pj4NCj4+Pj4+PiBCdXQsIG9u ZSBxdWVzdGlvbiBmb3IgY2xhcmlmaWNhdGlvbjogaWYgdGhlICJzeW5vbnltIiAgDQo+Pj4+Pj4g dHJhbnNsYXRpb24gaXMNCj4+Pj4+PiBkb25lIGJ5IGFuIGVudGl0eSB3aGljaCBJUyByZXBvbnNp YmxlIGZvciB0aGUgZG9tYWluLCBob3cgaXMgaXQgIA0KPj4+Pj4+IHRhZ2dlZD8NCj4+Pj4+Pg0K Pj4+Pj4+IC0tLS0tLS0tLS0tLS0NCj4+Pj4+Pg0KPj4+Pj4+PiBTbyB0aGlzIGlzIHdoYXQgaXQg Ym9pbHMgZG93biB0by4NCj4+Pj4+Pg0KPj4+Pj4+IEkgdGhpbmsgdGhhdCBpcyBtb3JlIG9yIGxl c3Mgd2hhdCBJIHdhcyB0cnlpbmcgdG8gc2F5Lg0KPj4+Pj4+DQo+Pj4+Pj4+IENhbiBhIGRvbWFp biBOT1QgcmVzcG9uc2libGUgZm9yIGEgdGFyZ2V0IGNoYW5nZSB0aGUgdGFyZ2V0ICANCj4+Pj4+ Pj4gQU5EIG1hcmsNCj4+Pj4+PiB0aGUgbmV3IHRhcmdldCBhdXRob3JpdGF0aXZlbHkgYXMgImJl bG9uZ2luZyIgdG8gdGhlIHNhbWUgdXNlcj8NCj4+Pj4+Pj4gSW4gdGFyZ2V0LVVSSSwgdGhlIGFz c3VtcHRpb24gaXMgeWVzLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBJbiA0MjQ0YmlzLCB0aGUgYXNzdW1w dGlvbiBpcyBubyAob25seSB0aGUgZG9tYWluIHJlc3BvbnNpYmxlICANCj4+Pj4+Pj4gZm9yIHRo ZQ0KPj4+Pj4+IFVSSSBjYW4gZG8gc28pLg0KPj4+Pj4+IENvcnJlY3QuDQo+Pj4+Pj4NCj4+Pj4+ PiAtLS0tLS0tLS0tLS0tDQo+Pj4+Pj4NCj4+Pj4+Pj4gQXMgcG9pbnRlZCBvdXQgYnkgUGF1bCBL eXppdmF0LCB3ZSBwcm9iYWJseSBuZWVkIHRvIHRoaW5rIG9uICANCj4+Pj4+Pj4gaG93IHRoaXMN Cj4+Pj4+PiB3b3JrcyB3aXRoIFRlbCBVUklzLiBJIHRoaW5rIGZvciBUZWwgVVJJIGl0IHdvdWxk IGJlIHRvdGFsbHkgIA0KPj4+Pj4+IGRpZmZlcmVudC4NCj4+Pj4+Pg0KPj4+Pj4+IFllcy4gWW91 IHJhaXNlZCB0aGF0IGFsc28gaW4gb3VyIHByaXZhdGUgZGlzY3Vzc2lvbnMsIGJ1dCB3ZSAgDQo+ Pj4+Pj4gbmV2ZXINCj4+Pj4+PiBkaXNjdXNzZWQgaXQgaW4gZGV0YWlscy4NCj4+Pj4+Pg0KPj4+ Pj4+IFNvLCBiZWZvcmUgd2Ugc3RhcnQgZGlzY3Vzc2luZyB0aGUgcHJvdG9jb2wgZGV0YWlscywg SSB0aGluayB3ZSAgDQo+Pj4+Pj4gbmVlZCB0bw0KPj4+Pj4+IHNvbHZlIHRoZSBpc3N1ZXMgYWJv dmUuDQo+Pj4+Pj4NCj4+Pj4+PiBSZWdhcmRzLA0KPj4+Pj4+DQo+Pj4+Pj4gQ2hyaXN0ZXINCj4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ Pj4+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gc2lwY29yZUBpZXRmLm9yZw0KPj4+Pj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPj4+Pj4+DQo+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ Pj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNpcGNvcmVAaWV0Zi5vcmcNCj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPj4+Pg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzaXBjb3JlIG1h aWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K From ietf.hanserik@gmail.com Mon Jun 15 11:59:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E215F3A6A07 for ; Mon, 15 Jun 2009 11:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[AWL=-1.130, BAYES_00=-2.599, MANGLED_REGALS=2.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uaqLxJfN8fB for ; Mon, 15 Jun 2009 11:59:29 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 7F9763A6900 for ; Mon, 15 Jun 2009 11:59:29 -0700 (PDT) Received: by ewy6 with SMTP id 6so5282842ewy.37 for ; Mon, 15 Jun 2009 11:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=qhFA9ZYQtGIkzay4Z3h+tYAg2og6UyjXP58nCDjkX5c=; b=WBKKfhF7gT4tdI2AHvxF+DQmV5VJvdO3Nb1r/8OYk5jpDQq5FYDzCGTXyPQmLm9n6q 9YgqyNmxy6fRtkI+BW/hINOVZ/j+cbGYmZ61AMUumwddMZTs7fI2lcvhOLLDDhUeoUz4 LS0iFbSaUADOBos7zsMNrft7myJZBiSmWYP3U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=kdPiaVgr/ariTkkNTrwLO/t9XyJZFV9uzuM2655a0L7sYBQQrZZSCYAuwtTLHCLwwO DbX29C8N/T9h65CNcQbeTayWtBroqKBH/Kqb/6b9e4ZtlJyi2UYKlWGNUqVxNoCL7QKu HKb1cOE5YXQzPVsh1qfuE2QfP24BlDtm7z2q4= Received: by 10.210.137.17 with SMTP id k17mr5030590ebd.52.1245092366374; Mon, 15 Jun 2009 11:59:26 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 5sm123162eyh.20.2009.06.15.11.59.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Jun 2009 11:59:25 -0700 (PDT) Message-ID: <4A369A0C.2090404@gmail.com> Date: Mon, 15 Jun 2009 20:59:24 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mary Barnes References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 18:59:31 -0000 The UAS has no knowledge about freephone service it is only interested in extracting the addressed target. The freephone service is just an example case where this poses currently a problem. A proxy that performs a certain service can by configuration know that it performs kind of a synonym mapping and tag accordingly. This is totally deterministic. /Hans Erik Mary Barnes wrote: > Correct. But, what I am suggesting is that you distinguish it at the UAS > - I'm assuming that the target Request-URI that arrives at the UAS is > something that identifies a client that handles 800 numbers. That > client could be configured such that it knows to look for the original > 800 number in the mapped URIs or in the reg-alias-URIs or both. Again, > if you're making these 800 numbers special and allowing proxies to > change them in multiple ways (i.e., non-deterministic), then if you want > them tagged special, then you need special logic in the proxies to do > this. That doesn't make sense to me, although you could do it that way > in a closed network, in which case you can make sure to always tag them > as whatever you think they should be - so we could define an additional > value for the tag. But, this is what I don't think is right in terms of > normal SIP request routing and forwarding, which is what the current > 4244bis tags have been defined to represent. > > Mary. > > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 1:23 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > Hi Mary, > > Proxies will tag entries based on the functionality they perform. > > Let's leave req-uri-alias for the moment. > > As I said earlier, one of the issues we have with 4244bis, is that > "mapped" seems to be used BOTH for diversion and when an AOR is replaced > with another AOR pointing to the same user - e.g. freephone. So, it is > not possible to distinguish between diversion and freephone. > > We think one MUST be able to make that distinguishment, because you may > have cases where both diversion and service number translation (e.g. > freephone) occurs, and the UAS needs to know which is which. > > Regards, > > Christer > > > > > > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 9:13 PM > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > It seems to me that the gist of this discussion has been based on the > expectation that independent of how the 800 number is configured, > registered or whatever at a proxy, that there is an expectation of > deterministic behavior in terms of how it's tagged. So, if 800 numbers > are special and they can end up tagged as either reg-uri-alias or as > mapped, then perhaps the service has to know that it needs to look for > either of those. ISTM that if there is a reason to preserve that it's an > 800 number (i.e., and not format as a service specific uri), the service > at the UAS knows that it's special, thus it would need to check the > request-URIs associated with both reg-uri-alias and mapped hi-entries. > I can't see how we can make it work any other way without being > prescriptive of how proxy's MUST tag these entries, which is not a good > idea IMHO. However, I think these numbers are either special cases at > proxies or something that services know about. > > Mary. > > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 12:47 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary > (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Yes, we need to sort out what to do for that. > > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Monday, June 15, 2009 10:17 >> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes, >> Mary (RICH2:AR00); sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> But if it is NOT an alias (=implicitly/explicitly registered)? >> >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> Sent: Monday, June 15, 2009 6:50 PM >> To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes; >> sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> then reg-uri-alias. >> >> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Saturday, June 13, 2009 01:22 >>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes, >>> Mary (RICH2:AR00); sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> >>> Hi, >>> >>> >>>> 1) RFC 4244bis >>>> >>>> In RFC 4244bis, if the domain is responsible for the URI in the >>>> >>> Request-URI and it replacing it with a Contact, it will put >>> >> a reg-uri >> >>> flag (if the Request-URI was the AOR used for registration), or reg- >>> >>>> uri-alias (if the Request-URI was an alias for the AOR used in >>>> >>> registration). >>> >>> And if the Request-URI was a "synonym" for the AOR? >>> >>> Regards, >>> >>> Christer >>> >>> >>> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.barnes@nortel.com Mon Jun 15 12:05:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514463A6C39 for ; Mon, 15 Jun 2009 12:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.197 X-Spam-Level: X-Spam-Status: No, score=-5.197 tagged_above=-999 required=5 tests=[AWL=-1.098, BAYES_00=-2.599, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6xY8bYB2Vly for ; Mon, 15 Jun 2009 12:05:23 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0347A3A6900 for ; Mon, 15 Jun 2009 12:05:22 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5FJ5R724616; Mon, 15 Jun 2009 19:05:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 14:07:41 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E83D943@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A369A0C.2090404@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt thread-index: Acnt63hFHEb6QsMfS1aJupC8Wjqk1wAAQZ/g References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <4A369A0C.2090404@gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 19:05:24 -0000 See the response to Paul on defining an additional tag for this. =20 -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Monday, June 15, 2009 1:59 PM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt The UAS has no knowledge about freephone service it is only interested in extracting the addressed target. The freephone service is just an example case where this poses currently a problem. A proxy that performs a certain service can by configuration know that it performs kind of a synonym mapping and tag accordingly. This is totally deterministic. /Hans Erik Mary Barnes wrote: > Correct. But, what I am suggesting is that you distinguish it at the=20 > UAS > - I'm assuming that the target Request-URI that arrives at the UAS is=20 > something that identifies a client that handles 800 numbers. That=20 > client could be configured such that it knows to look for the original > 800 number in the mapped URIs or in the reg-alias-URIs or both. =20 > Again, if you're making these 800 numbers special and allowing proxies > to change them in multiple ways (i.e., non-deterministic), then if you > want them tagged special, then you need special logic in the proxies=20 > to do this. That doesn't make sense to me, although you could do it=20 > that way in a closed network, in which case you can make sure to=20 > always tag them as whatever you think they should be - so we could=20 > define an additional value for the tag. But, this is what I don't=20 > think is right in terms of normal SIP request routing and forwarding,=20 > which is what the current 4244bis tags have been defined to represent. > > Mary.=20 > > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 1:23 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,=20 > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > Hi Mary, > > Proxies will tag entries based on the functionality they perform. > > Let's leave req-uri-alias for the moment. > > As I said earlier, one of the issues we have with 4244bis, is that=20 > "mapped" seems to be used BOTH for diversion and when an AOR is=20 > replaced with another AOR pointing to the same user - e.g. freephone.=20 > So, it is not possible to distinguish between diversion and freephone. > > We think one MUST be able to make that distinguishment, because you=20 > may have cases where both diversion and service number translation (e.g. > freephone) occurs, and the UAS needs to know which is which. > > Regards, > > Christer > > > > > > =20 > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 9:13 PM > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > It seems to me that the gist of this discussion has been based on the=20 > expectation that independent of how the 800 number is configured,=20 > registered or whatever at a proxy, that there is an expectation of=20 > deterministic behavior in terms of how it's tagged. So, if 800=20 > numbers are special and they can end up tagged as either reg-uri-alias > or as mapped, then perhaps the service has to know that it needs to=20 > look for either of those. ISTM that if there is a reason to preserve=20 > that it's an 800 number (i.e., and not format as a service specific=20 > uri), the service at the UAS knows that it's special, thus it would=20 > need to check the request-URIs associated with both reg-uri-alias and mapped hi-entries. > I can't see how we can make it work any other way without being=20 > prescriptive of how proxy's MUST tag these entries, which is not a=20 > good idea IMHO. However, I think these numbers are either special=20 > cases at proxies or something that services know about. > > Mary.=20 > > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 12:47 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary=20 > (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Yes, we need to sort out what to do for that.=20 > > =20 >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Monday, June 15, 2009 10:17 >> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 >> Mary (RICH2:AR00); sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 >> >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> Sent: Monday, June 15, 2009 6:50 PM >> To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 >> sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> then reg-uri-alias.=20 >> >> =20 >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Saturday, June 13, 2009 01:22 >>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 >>> Mary (RICH2:AR00); sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> >>> Hi, >>> >>> =20 >>>> 1) RFC 4244bis >>>> >>>> In RFC 4244bis, if the domain is responsible for the URI in the >>>> =20 >>> Request-URI and it replacing it with a Contact, it will put >>> =20 >> a reg-uri >> =20 >>> flag (if the Request-URI was the AOR used for registration), or reg- >>> =20 >>>> uri-alias (if the Request-URI was an alias for the AOR used in >>>> =20 >>> registration). >>> >>> And if the Request-URI was a "synonym" for the AOR? >>> >>> Regards, >>> >>> Christer >>> >>> >>> =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > =20 From ietf.hanserik@gmail.com Mon Jun 15 12:05:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B789E3A6CD4 for ; Mon, 15 Jun 2009 12:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbijXI1zEfWt for ; Mon, 15 Jun 2009 12:05:57 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 435103A6CDC for ; Mon, 15 Jun 2009 12:05:57 -0700 (PDT) Received: by ewy6 with SMTP id 6so5288072ewy.37 for ; Mon, 15 Jun 2009 12:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=iB7o19p/rwCF3xAUOSGC7KHjcC5eBZDmNe4T2m/NqTc=; b=cmVN8Vu2MR1H3D8HWw0ANsr8ISyqh8bA+QutH4LXbQn474iz0DqiXOX9FbnqP1QdOK Z2dX4ISBguWnPCKv4ozbwbgaeNgwbiTMim4KZwvcABqx7z1B9nImNSQgL+TQXyJu52JE 8fNe3kk40OcOqE2KrGrItuhXwKR1+cpqsi+6k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=L46VieGgXD2XEvoOM/J3sp7LrM3pNUw+jjGhbLft6kR5j1agknixg/GU+4lDIxXPrs 69oCrX3XNL04kgFYaXzPLilh1HCv1UxVCXteFLDkS4L8kygjEqhR6Lil11C0Si4kcDt1 gBZWqrgbwBOR3mDMj3UtLOZkE89cHNrKf5rvg= Received: by 10.210.67.4 with SMTP id p4mr5062239eba.36.1245092765051; Mon, 15 Jun 2009 12:06:05 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 10sm30223eyd.57.2009.06.15.12.06.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Jun 2009 12:06:04 -0700 (PDT) Message-ID: <4A369B9B.3070502@gmail.com> Date: Mon, 15 Jun 2009 21:06:03 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Paul Kyzivat References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <4A36973A.5010903@cisco.com> In-Reply-To: <4A36973A.5010903@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 19:05:58 -0000 Yes, I think we can, if we introduce the third category. We have now: - mapping translation (aor1->aor2, where aor2 is not configured as synonym for aor1) - routing translation (noop, predetermined, aor->contact) maybe we need a third, something like: - synonym translation (aor1->aor2, where aor2 is a onfigured synonym for aor1) Mapping and synonym, would only be performed by proxies that are configured to do so. This makes this entirely deterministic. /Hans Erik Paul Kyzivat wrote: > Do I get this right? > We need to be able to tag an R-URI replacement as being any one of > three different types? Yet I gather we can't all agree on what the > semantics of those three types is. Is it possible that there could be > *more* than three types? > > Thanks, > Paul > > Christer Holmberg wrote: >> Hi Mary, >> >> Proxies will tag entries based on the functionality they perform. >> >> Let's leave req-uri-alias for the moment. >> >> As I said earlier, one of the issues we have with 4244bis, is that >> "mapped" seems to be used BOTH for diversion and when an AOR is replaced >> with another AOR pointing to the same user - e.g. freephone. So, it is >> not possible to distinguish between diversion and freephone. >> >> We think one MUST be able to make that distinguishment, because you may >> have cases where both diversion and service number translation (e.g. >> freephone) occurs, and the UAS needs to know which is which. >> >> Regards, >> >> Christer >> >> >> >> >> >> >> >> -----Original Message----- >> From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Monday, June >> 15, 2009 9:13 PM >> To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; >> sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> It seems to me that the gist of this discussion has been based on the >> expectation that independent of how the 800 number is configured, >> registered or whatever at a proxy, that there is an expectation of >> deterministic behavior in terms of how it's tagged. So, if 800 numbers >> are special and they can end up tagged as either reg-uri-alias or as >> mapped, then perhaps the service has to know that it needs to look for >> either of those. ISTM that if there is a reason to preserve that it's an >> 800 number (i.e., and not format as a service specific uri), the service >> at the UAS knows that it's special, thus it would need to check the >> request-URIs associated with both reg-uri-alias and mapped hi-entries. >> I can't see how we can make it work any other way without being >> prescriptive of how proxy's MUST tag these entries, which is not a good >> idea IMHO. However, I think these numbers are either special cases at >> proxies or something that services know about. >> Mary. >> -----Original Message----- >> From: Audet, Francois (SC100:3055) >> Sent: Monday, June 15, 2009 12:47 PM >> To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary >> (RICH2:AR00); sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Yes, we need to sort out what to do for that. >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Monday, June 15, 2009 10:17 >>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes, >>> Mary (RICH2:AR00); sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> >>> But if it is NOT an alias (=implicitly/explicitly registered)? >>> -----Original Message----- >>> From: Francois Audet [mailto:audet@nortel.com] >>> Sent: Monday, June 15, 2009 6:50 PM >>> To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes; >>> sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> then reg-uri-alias. >>>> -----Original Message----- >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: Saturday, June 13, 2009 01:22 >>>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes, >>>> Mary (RICH2:AR00); sipcore@ietf.org >>>> Subject: RE: [sipcore] FW: I-D >>>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>>> >>>> >>>> Hi, >>>> >>>>> 1) RFC 4244bis >>>>> >>>>> In RFC 4244bis, if the domain is responsible for the URI in the >>>> Request-URI and it replacing it with a Contact, it will put >>> a reg-uri >>>> flag (if the Request-URI was the AOR used for registration), or reg- >>>>> uri-alias (if the Request-URI was an alias for the AOR used in >>>> registration). >>>> >>>> And if the Request-URI was a "synonym" for the AOR? >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From AUDET@nortel.com Mon Jun 15 12:08:05 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57CA83A6D17 for ; Mon, 15 Jun 2009 12:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DMLJvIPQhBQL for ; Mon, 15 Jun 2009 12:08:04 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id C35FA3A6C58 for ; Mon, 15 Jun 2009 12:08:03 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5FJ6hx24523; Mon, 15 Jun 2009 19:06:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 14:08:03 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E83D95B@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt thread-index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAAdwn4A== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Christer Holmberg" , "Mary Barnes" , "DOLLY, MARTIN C, ATTLABS" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 19:08:05 -0000 So Christer, Who is in a position to determine that an address is "mapped to same = user"? Is it the the proxy that retargets to the new address, or is it the = proxy who receives that request that determines "yeah, Bob is same as = 1800-5551212". (I'm talking about the case where the 1800 number is in a different = domain as Bob).=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Monday, June 15, 2009 11:23 > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055);=20 > DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi Mary, >=20 > Proxies will tag entries based on the functionality they perform. >=20 > Let's leave req-uri-alias for the moment. >=20 > As I said earlier, one of the issues we have with 4244bis, is=20 > that "mapped" seems to be used BOTH for diversion and when an=20 > AOR is replaced with another AOR pointing to the same user -=20 > e.g. freephone. So, it is not possible to distinguish between=20 > diversion and freephone. >=20 > We think one MUST be able to make that distinguishment,=20 > because you may have cases where both diversion and service=20 > number translation (e.g. > freephone) occurs, and the UAS needs to know which is which. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > =20 >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 9:13 PM > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C,=20 > ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > It seems to me that the gist of this discussion has been=20 > based on the expectation that independent of how the 800=20 > number is configured, registered or whatever at a proxy, that=20 > there is an expectation of deterministic behavior in terms of=20 > how it's tagged. So, if 800 numbers are special and they can=20 > end up tagged as either reg-uri-alias or as mapped, then=20 > perhaps the service has to know that it needs to look for=20 > either of those. ISTM that if there is a reason to preserve=20 > that it's an 800 number (i.e., and not format as a service=20 > specific uri), the service at the UAS knows that it's=20 > special, thus it would need to check the request-URIs=20 > associated with both reg-uri-alias and mapped hi-entries. > I can't see how we can make it work any other way without=20 > being prescriptive of how proxy's MUST tag these entries,=20 > which is not a good idea IMHO. However, I think these=20 > numbers are either special cases at proxies or something that=20 > services know about.=20 >=20 > Mary.=20 >=20 > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 12:47 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary=20 > (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Yes, we need to sort out what to do for that.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, June 15, 2009 10:17 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 > >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, June 15, 2009 6:50 PM > > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > > sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > then reg-uri-alias.=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Saturday, June 13, 2009 01:22 > > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C,=20 > ATTLABS; Barnes,=20 > > > Mary (RICH2:AR00); sipcore@ietf.org > > > Subject: RE: [sipcore] FW: I-D > > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > >=20 > > >=20 > > > Hi, > > >=20 > > > >1) RFC 4244bis > > > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > > Request-URI and it replacing it with a Contact, it will put > > a reg-uri > > > flag (if the Request-URI was the AOR used for=20 > registration), or reg- > > > >uri-alias (if the Request-URI was an alias for the AOR used in > > > registration). > > >=20 > > > And if the Request-URI was a "synonym" for the AOR? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > >=20 >=20 From ietf.hanserik@gmail.com Mon Jun 15 12:11:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7F813A6D00 for ; Mon, 15 Jun 2009 12:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, MANGLED_REGALS=2.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zyby3-BASqgx for ; Mon, 15 Jun 2009 12:11:31 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 510A03A6C86 for ; Mon, 15 Jun 2009 12:11:31 -0700 (PDT) Received: by ewy6 with SMTP id 6so5292247ewy.37 for ; Mon, 15 Jun 2009 12:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ggzMdx7NklPG0fdY8FC/34qrctpi4Ouywva96cB0BsE=; b=j1+xUTXXhDdfMqcshTO+jofq+TPj8ht94qn8uh9WExehoOAHNDwcvxGboymray13iP faHgF2iDdKo1lRd2kvyKUHlAKtYCCCmM77vc3yO9pLn+fLj4Ste2fKVhoVacfJyuVIIH /bqUS35C95RsENHcnJL+tJaBJmCsp8wXIB+9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=hDp2fCra46vqxG/fzty/XwlfDA2SKffvO0YYldAWJ/RCplbMEOc6jEDoSz93V941Ur ugbs+MtYGuJEtNkrPDo9fErN1wKpPj3it3OPoe4ou58dQjWWZG11f/7GrFMuWuQaV15T qQ9t9qulIRq41joQRuuz1PDEawZkVWao0dxIY= Received: by 10.211.178.8 with SMTP id f8mr2385298ebp.51.1245093088612; Mon, 15 Jun 2009 12:11:28 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 5sm61702eyh.40.2009.06.15.12.11.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Jun 2009 12:11:28 -0700 (PDT) Message-ID: <4A369CDE.8030105@gmail.com> Date: Mon, 15 Jun 2009 21:11:26 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mary Barnes References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 19:11:32 -0000 I disagree that the UAS needs to be aware about such services. It is only interested in extracting the addressed target in a generic way. /Hans Erik Mary Barnes wrote: > Correct. But, what I am suggesting is that you distinguish it at the UAS > - I'm assuming that the target Request-URI that arrives at the UAS is > something that identifies a client that handles 800 numbers. That > client could be configured such that it knows to look for the original > 800 number in the mapped URIs or in the reg-alias-URIs or both. Again, > if you're making these 800 numbers special and allowing proxies to > change them in multiple ways (i.e., non-deterministic), then if you want > them tagged special, then you need special logic in the proxies to do > this. That doesn't make sense to me, although you could do it that way > in a closed network, in which case you can make sure to always tag them > as whatever you think they should be - so we could define an additional > value for the tag. But, this is what I don't think is right in terms of > normal SIP request routing and forwarding, which is what the current > 4244bis tags have been defined to represent. > > Mary. > > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 1:23 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > Hi Mary, > > Proxies will tag entries based on the functionality they perform. > > Let's leave req-uri-alias for the moment. > > As I said earlier, one of the issues we have with 4244bis, is that > "mapped" seems to be used BOTH for diversion and when an AOR is replaced > with another AOR pointing to the same user - e.g. freephone. So, it is > not possible to distinguish between diversion and freephone. > > We think one MUST be able to make that distinguishment, because you may > have cases where both diversion and service number translation (e.g. > freephone) occurs, and the UAS needs to know which is which. > > Regards, > > Christer > > > > > > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 9:13 PM > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > It seems to me that the gist of this discussion has been based on the > expectation that independent of how the 800 number is configured, > registered or whatever at a proxy, that there is an expectation of > deterministic behavior in terms of how it's tagged. So, if 800 numbers > are special and they can end up tagged as either reg-uri-alias or as > mapped, then perhaps the service has to know that it needs to look for > either of those. ISTM that if there is a reason to preserve that it's an > 800 number (i.e., and not format as a service specific uri), the service > at the UAS knows that it's special, thus it would need to check the > request-URIs associated with both reg-uri-alias and mapped hi-entries. > I can't see how we can make it work any other way without being > prescriptive of how proxy's MUST tag these entries, which is not a good > idea IMHO. However, I think these numbers are either special cases at > proxies or something that services know about. > > Mary. > > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 12:47 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary > (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Yes, we need to sort out what to do for that. > > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Monday, June 15, 2009 10:17 >> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes, >> Mary (RICH2:AR00); sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> But if it is NOT an alias (=implicitly/explicitly registered)? >> >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> Sent: Monday, June 15, 2009 6:50 PM >> To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes; >> sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> then reg-uri-alias. >> >> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Saturday, June 13, 2009 01:22 >>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes, >>> Mary (RICH2:AR00); sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> >>> Hi, >>> >>> >>>> 1) RFC 4244bis >>>> >>>> In RFC 4244bis, if the domain is responsible for the URI in the >>>> >>> Request-URI and it replacing it with a Contact, it will put >>> >> a reg-uri >> >>> flag (if the Request-URI was the AOR used for registration), or reg- >>> >>>> uri-alias (if the Request-URI was an alias for the AOR used in >>>> >>> registration). >>> >>> And if the Request-URI was a "synonym" for the AOR? >>> >>> Regards, >>> >>> Christer >>> >>> >>> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From AUDET@nortel.com Mon Jun 15 12:13:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFA743A6A4B for ; Mon, 15 Jun 2009 12:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.221 X-Spam-Level: X-Spam-Status: No, score=-5.221 tagged_above=-999 required=5 tests=[AWL=-1.122, BAYES_00=-2.599, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwXa3LgNy7B4 for ; Mon, 15 Jun 2009 12:13:50 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 648C03A681A for ; Mon, 15 Jun 2009 12:13:50 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5FJDL726605; Mon, 15 Jun 2009 19:13:22 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 14:13:20 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E83D981@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A369CDE.8030105@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt thread-index: Acnt7RsRHUSsbN/ASeqVu18eJjPgsgAACZOQ References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <4A369CDE.8030105@gmail.com> From: "Francois Audet" To: "Hans Erik van Elburg" , "Mary Barnes" Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 19:13:51 -0000 So... Then why do we need the difference between mapped-to-new-guy and this-is-just-an-alias-aor again?=20 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 > Sent: Monday, June 15, 2009 12:11 > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Audet, Francois (SC100:3055); DOLLY,=20 > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > I disagree that the UAS needs to be aware about such=20 > services. It is only interested in extracting the addressed=20 > target in a generic way. >=20 > /Hans Erik >=20 > Mary Barnes wrote: > > Correct. But, what I am suggesting is that you distinguish=20 > it at the=20 > > UAS > > - I'm assuming that the target Request-URI that arrives at=20 > the UAS is=20 > > something that identifies a client that handles 800 numbers. That=20 > > client could be configured such that it knows to look for=20 > the original=20 > > 800 number in the mapped URIs or in the reg-alias-URIs or both. =20 > > Again, if you're making these 800 numbers special and=20 > allowing proxies=20 > > to change them in multiple ways (i.e., non-deterministic),=20 > then if you=20 > > want them tagged special, then you need special logic in=20 > the proxies=20 > > to do this. That doesn't make sense to me, although you=20 > could do it=20 > > that way in a closed network, in which case you can make sure to=20 > > always tag them as whatever you think they should be - so we could=20 > > define an additional value for the tag. But, this is what I don't=20 > > think is right in terms of normal SIP request routing and=20 > forwarding,=20 > > which is what the current 4244bis tags have been defined to=20 > represent. > > > > Mary.=20 > > > > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, June 15, 2009 1:23 PM > > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,=20 > > MARTIN C, ATTLABS; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > > > > Hi Mary, > > > > Proxies will tag entries based on the functionality they perform. > > > > Let's leave req-uri-alias for the moment. > > > > As I said earlier, one of the issues we have with 4244bis, is that=20 > > "mapped" seems to be used BOTH for diversion and when an AOR is=20 > > replaced with another AOR pointing to the same user - e.g.=20 > freephone.=20 > > So, it is not possible to distinguish between diversion and=20 > freephone. > > > > We think one MUST be able to make that distinguishment, because you=20 > > may have cases where both diversion and service number=20 > translation (e.g. > > freephone) occurs, and the UAS needs to know which is which. > > > > Regards, > > > > Christer > > > > > > > > > > > > =20 > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: Monday, June 15, 2009 9:13 PM > > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;=20 > > sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > > It seems to me that the gist of this discussion has been=20 > based on the=20 > > expectation that independent of how the 800 number is configured,=20 > > registered or whatever at a proxy, that there is an expectation of=20 > > deterministic behavior in terms of how it's tagged. So, if 800=20 > > numbers are special and they can end up tagged as either=20 > reg-uri-alias=20 > > or as mapped, then perhaps the service has to know that it needs to=20 > > look for either of those. ISTM that if there is a reason to=20 > preserve=20 > > that it's an 800 number (i.e., and not format as a service specific=20 > > uri), the service at the UAS knows that it's special, thus it would=20 > > need to check the request-URIs associated with both=20 > reg-uri-alias and mapped hi-entries. > > I can't see how we can make it work any other way without being=20 > > prescriptive of how proxy's MUST tag these entries, which is not a=20 > > good idea IMHO. However, I think these numbers are either special=20 > > cases at proxies or something that services know about. > > > > Mary.=20 > > > > -----Original Message----- > > From: Audet, Francois (SC100:3055) > > Sent: Monday, June 15, 2009 12:47 PM > > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary=20 > > (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > > Yes, we need to sort out what to do for that.=20 > > > > =20 > >> -----Original Message----- > >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >> Sent: Monday, June 15, 2009 10:17 > >> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C,=20 > ATTLABS; Barnes,=20 > >> Mary (RICH2:AR00); sipcore@ietf.org > >> Subject: RE: [sipcore] FW: I-D > >> Action:draft-barnes-sipcore-rfc4244bis-01.txt > >> > >> > >> But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 > >> > >> -----Original Message----- > >> From: Francois Audet [mailto:audet@nortel.com] > >> Sent: Monday, June 15, 2009 6:50 PM > >> To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > >> sipcore@ietf.org > >> Subject: RE: [sipcore] FW: I-D > >> Action:draft-barnes-sipcore-rfc4244bis-01.txt > >> > >> then reg-uri-alias.=20 > >> > >> =20 > >>> -----Original Message----- > >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > >>> Sent: Saturday, June 13, 2009 01:22 > >>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C,=20 > ATTLABS; Barnes,=20 > >>> Mary (RICH2:AR00); sipcore@ietf.org > >>> Subject: RE: [sipcore] FW: I-D > >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt > >>> > >>> > >>> Hi, > >>> > >>> =20 > >>>> 1) RFC 4244bis > >>>> > >>>> In RFC 4244bis, if the domain is responsible for the URI in the > >>>> =20 > >>> Request-URI and it replacing it with a Contact, it will put > >>> =20 > >> a reg-uri > >> =20 > >>> flag (if the Request-URI was the AOR used for=20 > registration), or reg- > >>> =20 > >>>> uri-alias (if the Request-URI was an alias for the AOR used in > >>>> =20 > >>> registration). > >>> > >>> And if the Request-URI was a "synonym" for the AOR? > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> =20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > =20 >=20 From pkyzivat@cisco.com Mon Jun 15 12:14:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23A4C3A6C86 for ; Mon, 15 Jun 2009 12:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vCl08MwWSE5 for ; Mon, 15 Jun 2009 12:13:59 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id F0D773A6A74 for ; Mon, 15 Jun 2009 12:13:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,224,1243814400"; d="scan'208";a="47400326" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Jun 2009 19:13:37 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5FJDYAW004486; Mon, 15 Jun 2009 15:13:34 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5FJDZPh025909; Mon, 15 Jun 2009 19:13:35 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 15:13:35 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 15:13:34 -0400 Message-ID: <4A369D5E.1040408@cisco.com> Date: Mon, 15 Jun 2009 15:13:34 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "DOLLY, MARTIN C, ATTLABS" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4812@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA02BD4812@gaalpa1msgusr7e.ugd.att.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jun 2009 19:13:34.0666 (UTC) FILETIME=[60F7E2A0:01C9EDED] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7854; t=1245093214; x=1245957214; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20The=20functional=20differen ces=20between=204244bis=20andtarget-=0A=20uri=20(was=20FW=3A =20I-DAction=3Adraft-barnes-sipcore-rfc4244bis-01.txt) |Sender:=20 |To:=20=22DOLLY,=20MARTIN=20C,=20ATTLABS=22=20; bh=4kth8/GB26BfYOR1VbtM0T24Dz8R9nkUJF9QH6kPDmI=; b=LcbuJK8OUzt1lwMAp7Sxw0X6TqwobKVaFLbxkfZtlgy3mLUg2eq/JNB73Z Ubp2d6Tyhzl/orbZwiiihU4w6vFnVOFWIsH7mDK7PCtBGmaGKa8mz5QYnVUu 7qOKQrtCpB; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] The functional differences between 4244bis andtarget- uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 19:14:01 -0000 DOLLY, MARTIN C, ATTLABS wrote: > Simple requirement: capture ALL retarget information in HI. Period We have had the ability to capture all retargeting with H-I since it was first published. The new requirement is to distinguish different sorts of retargeting. If so its very important that everybody understand the meaning of each type and how to determine that type each time a request is retargeted. I was getting the impression (may be wrong about it) that a third type of retargeting was now being identified. We need to agree on what it is that we are capturing. Thanks, Paul > ----- Original Message ----- > From: sipcore-bounces@ietf.org > To: Paul Kyzivat > Cc: DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org > Sent: Mon Jun 15 08:20:15 2009 > Subject: Re: [sipcore] The functional differences between 4244bis andtarget- uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) > > > I don't think it's a special case for free-dial alone. > > If service URN is used to deliver a service request such as > emergency call > or directory assistance request to a local call-center, and takes a > similar > approach to what's defined in phoneBCP to support devices not > compliant to > service URN, the translation to service URN from the dial string will > be done > by the proxy. But the translation from 911 to "sos" will only be seen > in request URI > and not in the To header. > > So To header even without diversion is not dependable. > > Regards > Shida > > On 15-Jun-09, at 6:28 AM, Paul Kyzivat wrote: > >> >> Hans Erik van Elburg wrote: >>> But that does not work when a diversion to that service number >>> takes place. It only works for direct calls to such service number. >> Perhaps. That depends on *if* that is a reasonable scenario, and if >> so precisely what you want to happen in that case. >> >> For instance, does it really make sense for you to call me, and for >> me to then divert you to an 800 number? If so, is that supposed to >> behave as if you had called the 800 number? >> >> I realize there are many possible desired outcomes, so many >> strategies may be used from case to case. >> >> Thanks, >> Paul >> >>> /Hans Erik >>> Paul Kyzivat wrote: >>>> >>>> Hans Erik van Elburg wrote: >>>>> Hi Paul, >>>>> >>>>> For what would you want to use the To-uri? >>>> To decide who/what the caller desired to reach, and hence what >>>> treatment to give the call. This seems to be the key thing for the >>>> call centers that use freephone numbers. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> /Hans Erik >>>>> >>>>> Paul Kyzivat wrote: >>>>>> This thing about the freephone services is an ugly one. >>>>>> I've thought for a long time that the mechanism is an entirely >>>>>> brain dead way to designate who should pay for a call. >>>>>> >>>>>> But it is what it is, so I guess we have to cope with it. >>>>>> >>>>>> I wonder if perhaps this is really one of the few circumstances >>>>>> where the recipient of a call ought to make call handling >>>>>> decisions based on the To-uri. The reason I say this is because >>>>>> the "contract" with these numbers is that the caller expects the >>>>>> call will be free based on the form of the number being called. >>>>>> And if the caller is wrong, it is the caller who gets charged. >>>>>> >>>>>> So, while I generally recommend that the To-uri be used for >>>>>> *nothing*, it might be right here. If so, then the whole target- >>>>>> uri/h-i discussion may be irrelevant to it. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> Christer Holmberg wrote: >>>>>>> Hi, >>>>>>>> I'm going to spare details, but the main different is as >>>>>>>> follows. >>>>>>>> >>>>>>>> 1) RFC 4244bis >>>>>>>> >>>>>>>> In RFC 4244bis, if the domain is responsible for the URI in the >>>>>>> Request-URI and it replacing it with a Contact, it will put a >>>>>>> reg-uri >>>>>>> flag (if the Request-URI was the AOR used for registration), or >>>>>>> reg- >>>>>>>> uri-alias (if the Request-URI was an alias for the AOR used in >>>>>>> registration). >>>>>>>> If the domain is responsible for the URI and it "maps" it to a >>>>>>> different user, then it puts a "mapped" flag. >>>>>>>> If the domain is NOT responsible for the AOR but it changes the >>>>>>> Request-URI nevertheless, then it is also marked as "mapped". >>>>>>>> Note: With loose routing, this is not supposed to >>>>>>>> happen (at least in theory). >>>>>>>> >>>>>>>> This next statement is where there is a big difference: >>>>>>>> >>>>>>>> If the domain is NOT responsible for the URI, the mapping >>>>>>>> cannot know >>>>>>> if the new URI is belongs to the same User than the original >>>>>>> one. This >>>>>>> is why it is mapping: it is impossible for a proxy NOT >>>>>>>> responsible for a URI to change it to something else and >>>>>>>> "know" if it a >>>>>>> different user (retarget) or just a "synonym" for the same user. >>>>>>> >>>>>>> We don't think it is "impossible", and we see no reason why we >>>>>>> should >>>>>>> make that restriction without any technical justification. The >>>>>>> proxy >>>>>>> does not change the URI just for fun, with a value out of the >>>>>>> blue - it >>>>>>> does it based on some kind of knowledge/configuration. >>>>>>> >>>>>>>> 2) Target-UI >>>>>>>> >>>>>>>> In target-URI, there is an assumption that a domain NOT >>>>>>>> responsible for >>>>>>> a URI can change the URI to something AND know authoritatively >>>>>>> that the >>>>>>> new target is a "synonym" for the original target. >>>>>>> >>>>>>> Correct. >>>>>>> And, I assume the difference between "synomym" and "alias" is >>>>>>> that a >>>>>>> synonym URI is not registered for the called user, right? >>>>>>> >>>>>>> But, one question for clarification: if the "synonym" >>>>>>> translation is >>>>>>> done by an entity which IS reponsible for the domain, how is it >>>>>>> tagged? >>>>>>> >>>>>>> ------------- >>>>>>> >>>>>>>> So this is what it boils down to. >>>>>>> I think that is more or less what I was trying to say. >>>>>>> >>>>>>>> Can a domain NOT responsible for a target change the target >>>>>>>> AND mark >>>>>>> the new target authoritatively as "belonging" to the same user? >>>>>>>> In target-URI, the assumption is yes. >>>>>>>> >>>>>>>> In 4244bis, the assumption is no (only the domain responsible >>>>>>>> for the >>>>>>> URI can do so). >>>>>>> Correct. >>>>>>> >>>>>>> ------------- >>>>>>> >>>>>>>> As pointed out by Paul Kyzivat, we probably need to think on >>>>>>>> how this >>>>>>> works with Tel URIs. I think for Tel URI it would be totally >>>>>>> different. >>>>>>> >>>>>>> Yes. You raised that also in our private discussions, but we >>>>>>> never >>>>>>> discussed it in details. >>>>>>> >>>>>>> So, before we start discussing the protocol details, I think we >>>>>>> need to >>>>>>> solve the issues above. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> _______________________________________________ >>>>>>> sipcore mailing list >>>>>>> sipcore@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>> >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From mdolly@att.com Mon Jun 15 12:16:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 381C43A6A74 for ; Mon, 15 Jun 2009 12:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.227 X-Spam-Level: X-Spam-Status: No, score=-106.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiDBzXBuBrG0 for ; Mon, 15 Jun 2009 12:16:53 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id CD5803A681A for ; Mon, 15 Jun 2009 12:16:52 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-12.tower-167.messagelabs.com!1245093377!21829484!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 19821 invoked from network); 15 Jun 2009 19:16:18 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-12.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Jun 2009 19:16:18 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5FJGHhO000595 for ; Mon, 15 Jun 2009 15:16:17 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5FJGD6T000541 for ; Mon, 15 Jun 2009 15:16:13 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 15 Jun 2009 15:16:12 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD4813@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] The functional differences between 4244bis andtarget- uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) Thread-Index: Acnt7WzRHQsf0D0uRdupn7uzFfgKewAAFKSB From: "DOLLY, MARTIN C, ATTLABS" To: Cc: sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] The functional differences between 4244bis andtarget- uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 19:16:54 -0000 MS4gVHJhbnNsYXRpb24NCjIuIFJldGFyZ2V0DQozLiBSZWRpcmVjdA0KDQotLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBQYXVsIEt5eml2YXQgPHBreXppdmF0QGNpc2NvLmNvbT4N ClRvOiBET0xMWSwgTUFSVElOIEMsIEFUVExBQlMNCkNjOiBzaGlkYUBhZ25hZGEuY29tIDxzaGlk YUBhZ25hZGEuY29tPjsgc2lwY29yZUBpZXRmLm9yZyA8c2lwY29yZUBpZXRmLm9yZz4NClNlbnQ6 IE1vbiBKdW4gMTUgMTU6MTM6MzQgMjAwOQ0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBUaGUgZnVu Y3Rpb25hbCBkaWZmZXJlbmNlcyBiZXR3ZWVuIDQyNDRiaXMgYW5kdGFyZ2V0LSB1cmkgKHdhcyBG VzogSS1EQWN0aW9uOmRyYWZ0LWJhcm5lcy1zaXBjb3JlLXJmYzQyNDRiaXMtMDEudHh0KQ0KDQoN Cg0KRE9MTFksIE1BUlRJTiBDLCBBVFRMQUJTIHdyb3RlOg0KPiBTaW1wbGUgcmVxdWlyZW1lbnQ6 IGNhcHR1cmUgQUxMIHJldGFyZ2V0IGluZm9ybWF0aW9uIGluIEhJLiBQZXJpb2QNCg0KV2UgaGF2 ZSBoYWQgdGhlIGFiaWxpdHkgdG8gY2FwdHVyZSBhbGwgcmV0YXJnZXRpbmcgd2l0aCBILUkgc2lu Y2UgaXQgd2FzIA0KZmlyc3QgcHVibGlzaGVkLiBUaGUgbmV3IHJlcXVpcmVtZW50IGlzIHRvIGRp c3Rpbmd1aXNoIGRpZmZlcmVudCBzb3J0cyANCm9mIHJldGFyZ2V0aW5nLiBJZiBzbyBpdHMgdmVy eSBpbXBvcnRhbnQgdGhhdCBldmVyeWJvZHkgdW5kZXJzdGFuZCB0aGUgDQptZWFuaW5nIG9mIGVh Y2ggdHlwZSBhbmQgaG93IHRvIGRldGVybWluZSB0aGF0IHR5cGUgZWFjaCB0aW1lIGEgcmVxdWVz dCANCmlzIHJldGFyZ2V0ZWQuIEkgd2FzIGdldHRpbmcgdGhlIGltcHJlc3Npb24gKG1heSBiZSB3 cm9uZyBhYm91dCBpdCkgdGhhdCANCmEgdGhpcmQgdHlwZSBvZiByZXRhcmdldGluZyB3YXMgbm93 IGJlaW5nIGlkZW50aWZpZWQuDQoNCldlIG5lZWQgdG8gYWdyZWUgb24gd2hhdCBpdCBpcyB0aGF0 IHdlIGFyZSBjYXB0dXJpbmcuDQoNCglUaGFua3MsDQoJUGF1bA0KDQo+IC0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0NCj4gRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIDxzaXBjb3Jl LWJvdW5jZXNAaWV0Zi5vcmc+DQo+IFRvOiBQYXVsIEt5eml2YXQgPHBreXppdmF0QGNpc2NvLmNv bT4NCj4gQ2M6IERPTExZLCBNQVJUSU4gQywgQVRUTEFCUzsgc2lwY29yZUBpZXRmLm9yZyA8c2lw Y29yZUBpZXRmLm9yZz4NCj4gU2VudDogTW9uIEp1biAxNSAwODoyMDoxNSAyMDA5DQo+IFN1Ympl Y3Q6IFJlOiBbc2lwY29yZV0gVGhlIGZ1bmN0aW9uYWwgZGlmZmVyZW5jZXMgYmV0d2VlbiA0MjQ0 YmlzIGFuZHRhcmdldC0gdXJpICh3YXMgRlc6IEktREFjdGlvbjpkcmFmdC1iYXJuZXMtc2lwY29y ZS1yZmM0MjQ0YmlzLTAxLnR4dCkNCj4gDQo+IA0KPiAgIEkgZG9uJ3QgdGhpbmsgaXQncyBhIHNw ZWNpYWwgY2FzZSBmb3IgZnJlZS1kaWFsIGFsb25lLg0KPiANCj4gICBJZiBzZXJ2aWNlIFVSTiBp cyB1c2VkIHRvIGRlbGl2ZXIgYSBzZXJ2aWNlIHJlcXVlc3Qgc3VjaCBhcyAgDQo+IGVtZXJnZW5j eSBjYWxsDQo+IG9yIGRpcmVjdG9yeSBhc3Npc3RhbmNlIHJlcXVlc3QgdG8gYSBsb2NhbCBjYWxs LWNlbnRlciwgYW5kIHRha2VzIGEgIA0KPiBzaW1pbGFyDQo+IGFwcHJvYWNoIHRvIHdoYXQncyBk ZWZpbmVkIGluIHBob25lQkNQIHRvIHN1cHBvcnQgZGV2aWNlcyBub3QgIA0KPiBjb21wbGlhbnQg dG8NCj4gc2VydmljZSBVUk4sIHRoZSB0cmFuc2xhdGlvbiB0byBzZXJ2aWNlIFVSTiBmcm9tIHRo ZSBkaWFsIHN0cmluZyB3aWxsICANCj4gYmUgZG9uZQ0KPiBieSB0aGUgcHJveHkuIEJ1dCB0aGUg dHJhbnNsYXRpb24gZnJvbSA5MTEgdG8gInNvcyIgd2lsbCBvbmx5IGJlIHNlZW4gIA0KPiBpbiBy ZXF1ZXN0IFVSSQ0KPiBhbmQgbm90IGluIHRoZSBUbyBoZWFkZXIuDQo+IA0KPiAgIFNvIFRvIGhl YWRlciBldmVuIHdpdGhvdXQgZGl2ZXJzaW9uIGlzIG5vdCBkZXBlbmRhYmxlLg0KPiANCj4gICBS ZWdhcmRzDQo+ICAgIFNoaWRhDQo+IA0KPiBPbiAxNS1KdW4tMDksIGF0IDY6MjggQU0sIFBhdWwg S3l6aXZhdCB3cm90ZToNCj4gDQo+Pg0KPj4gSGFucyBFcmlrIHZhbiBFbGJ1cmcgd3JvdGU6DQo+ Pj4gQnV0IHRoYXQgZG9lcyBub3Qgd29yayB3aGVuIGEgZGl2ZXJzaW9uIHRvIHRoYXQgc2Vydmlj ZSBudW1iZXIgIA0KPj4+IHRha2VzIHBsYWNlLiBJdCBvbmx5IHdvcmtzIGZvciBkaXJlY3QgY2Fs bHMgdG8gc3VjaCBzZXJ2aWNlIG51bWJlci4NCj4+IFBlcmhhcHMuIFRoYXQgZGVwZW5kcyBvbiAq aWYqIHRoYXQgaXMgYSByZWFzb25hYmxlIHNjZW5hcmlvLCBhbmQgaWYgIA0KPj4gc28gcHJlY2lz ZWx5IHdoYXQgeW91IHdhbnQgdG8gaGFwcGVuIGluIHRoYXQgY2FzZS4NCj4+DQo+PiBGb3IgaW5z dGFuY2UsIGRvZXMgaXQgcmVhbGx5IG1ha2Ugc2Vuc2UgZm9yIHlvdSB0byBjYWxsIG1lLCBhbmQg Zm9yICANCj4+IG1lIHRvIHRoZW4gZGl2ZXJ0IHlvdSB0byBhbiA4MDAgbnVtYmVyPyBJZiBzbywg aXMgdGhhdCBzdXBwb3NlZCB0byAgDQo+PiBiZWhhdmUgYXMgaWYgeW91IGhhZCBjYWxsZWQgdGhl IDgwMCBudW1iZXI/DQo+Pg0KPj4gSSByZWFsaXplIHRoZXJlIGFyZSBtYW55IHBvc3NpYmxlIGRl c2lyZWQgb3V0Y29tZXMsIHNvIG1hbnkgIA0KPj4gc3RyYXRlZ2llcyBtYXkgYmUgdXNlZCBmcm9t IGNhc2UgdG8gY2FzZS4NCj4+DQo+PiAJVGhhbmtzLA0KPj4gCVBhdWwNCj4+DQo+Pj4gL0hhbnMg RXJpaw0KPj4+IFBhdWwgS3l6aXZhdCB3cm90ZToNCj4+Pj4NCj4+Pj4gSGFucyBFcmlrIHZhbiBF bGJ1cmcgd3JvdGU6DQo+Pj4+PiBIaSBQYXVsLA0KPj4+Pj4NCj4+Pj4+IEZvciB3aGF0IHdvdWxk IHlvdSB3YW50IHRvIHVzZSB0aGUgVG8tdXJpPw0KPj4+PiBUbyBkZWNpZGUgd2hvL3doYXQgdGhl IGNhbGxlciBkZXNpcmVkIHRvIHJlYWNoLCBhbmQgaGVuY2Ugd2hhdCAgDQo+Pj4+IHRyZWF0bWVu dCB0byBnaXZlIHRoZSBjYWxsLiBUaGlzIHNlZW1zIHRvIGJlIHRoZSBrZXkgdGhpbmcgZm9yIHRo ZSAgDQo+Pj4+IGNhbGwgY2VudGVycyB0aGF0IHVzZSBmcmVlcGhvbmUgbnVtYmVycy4NCj4+Pj4N Cj4+Pj4gICAgVGhhbmtzLA0KPj4+PiAgICBQYXVsDQo+Pj4+DQo+Pj4+PiAvSGFucyBFcmlrDQo+ Pj4+Pg0KPj4+Pj4gUGF1bCBLeXppdmF0IHdyb3RlOg0KPj4+Pj4+IFRoaXMgdGhpbmcgYWJvdXQg dGhlIGZyZWVwaG9uZSBzZXJ2aWNlcyBpcyBhbiB1Z2x5IG9uZS4NCj4+Pj4+PiBJJ3ZlIHRob3Vn aHQgZm9yIGEgbG9uZyB0aW1lIHRoYXQgdGhlIG1lY2hhbmlzbSBpcyBhbiBlbnRpcmVseSAgDQo+ Pj4+Pj4gYnJhaW4gZGVhZCB3YXkgdG8gZGVzaWduYXRlIHdobyBzaG91bGQgcGF5IGZvciBhIGNh bGwuDQo+Pj4+Pj4NCj4+Pj4+PiBCdXQgaXQgaXMgd2hhdCBpdCBpcywgc28gSSBndWVzcyB3ZSBo YXZlIHRvIGNvcGUgd2l0aCBpdC4NCj4+Pj4+Pg0KPj4+Pj4+IEkgd29uZGVyIGlmIHBlcmhhcHMg dGhpcyBpcyByZWFsbHkgb25lIG9mIHRoZSBmZXcgY2lyY3Vtc3RhbmNlcyAgDQo+Pj4+Pj4gd2hl cmUgdGhlIHJlY2lwaWVudCBvZiBhIGNhbGwgb3VnaHQgdG8gbWFrZSBjYWxsIGhhbmRsaW5nICAN Cj4+Pj4+PiBkZWNpc2lvbnMgYmFzZWQgb24gdGhlIFRvLXVyaS4gVGhlIHJlYXNvbiBJIHNheSB0 aGlzIGlzIGJlY2F1c2UgIA0KPj4+Pj4+IHRoZSAiY29udHJhY3QiIHdpdGggdGhlc2UgbnVtYmVy cyBpcyB0aGF0IHRoZSBjYWxsZXIgZXhwZWN0cyB0aGUgIA0KPj4+Pj4+IGNhbGwgd2lsbCBiZSBm cmVlIGJhc2VkIG9uIHRoZSBmb3JtIG9mIHRoZSBudW1iZXIgYmVpbmcgY2FsbGVkLiAgDQo+Pj4+ Pj4gQW5kIGlmIHRoZSBjYWxsZXIgaXMgd3JvbmcsIGl0IGlzIHRoZSBjYWxsZXIgd2hvIGdldHMg Y2hhcmdlZC4NCj4+Pj4+Pg0KPj4+Pj4+IFNvLCB3aGlsZSBJIGdlbmVyYWxseSByZWNvbW1lbmQg dGhhdCB0aGUgVG8tdXJpIGJlIHVzZWQgZm9yICANCj4+Pj4+PiAqbm90aGluZyosIGl0IG1pZ2h0 IGJlIHJpZ2h0IGhlcmUuIElmIHNvLCB0aGVuIHRoZSB3aG9sZSB0YXJnZXQtIA0KPj4+Pj4+IHVy aS9oLWkgZGlzY3Vzc2lvbiBtYXkgYmUgaXJyZWxldmFudCB0byBpdC4NCj4+Pj4+Pg0KPj4+Pj4+ ICAgIFRoYW5rcywNCj4+Pj4+PiAgICBQYXVsDQo+Pj4+Pj4NCj4+Pj4+PiBDaHJpc3RlciBIb2xt YmVyZyB3cm90ZToNCj4+Pj4+Pj4gSGksDQo+Pj4+Pj4+PiBJJ20gZ29pbmcgdG8gc3BhcmUgZGV0 YWlscywgYnV0IHRoZSBtYWluIGRpZmZlcmVudCBpcyBhcyAgDQo+Pj4+Pj4+PiBmb2xsb3dzLg0K Pj4+Pj4+Pj4NCj4+Pj4+Pj4+IDEpIFJGQyA0MjQ0YmlzDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gSW4g UkZDIDQyNDRiaXMsIGlmIHRoZSBkb21haW4gaXMgcmVzcG9uc2libGUgZm9yIHRoZSBVUkkgaW4g dGhlDQo+Pj4+Pj4+IFJlcXVlc3QtVVJJIGFuZCBpdCByZXBsYWNpbmcgaXQgd2l0aCBhIENvbnRh Y3QsIGl0IHdpbGwgcHV0IGEgIA0KPj4+Pj4+PiByZWctdXJpDQo+Pj4+Pj4+IGZsYWcgKGlmIHRo ZSBSZXF1ZXN0LVVSSSB3YXMgdGhlIEFPUiB1c2VkIGZvciByZWdpc3RyYXRpb24pLCBvciAgDQo+ Pj4+Pj4+IHJlZy0NCj4+Pj4+Pj4+IHVyaS1hbGlhcyAoaWYgdGhlIFJlcXVlc3QtVVJJIHdhcyBh biBhbGlhcyBmb3IgdGhlIEFPUiB1c2VkIGluDQo+Pj4+Pj4+IHJlZ2lzdHJhdGlvbikuDQo+Pj4+ Pj4+PiBJZiB0aGUgZG9tYWluIGlzIHJlc3BvbnNpYmxlIGZvciB0aGUgVVJJIGFuZCBpdCAibWFw cyIgaXQgdG8gYQ0KPj4+Pj4+PiBkaWZmZXJlbnQgdXNlciwgdGhlbiBpdCBwdXRzIGEgIm1hcHBl ZCIgZmxhZy4NCj4+Pj4+Pj4+IElmIHRoZSBkb21haW4gaXMgTk9UIHJlc3BvbnNpYmxlIGZvciB0 aGUgQU9SIGJ1dCBpdCBjaGFuZ2VzIHRoZQ0KPj4+Pj4+PiBSZXF1ZXN0LVVSSSBuZXZlcnRoZWxl c3MsIHRoZW4gaXQgaXMgYWxzbyBtYXJrZWQgYXMgIm1hcHBlZCIuDQo+Pj4+Pj4+PiAgICBOb3Rl OiBXaXRoIGxvb3NlIHJvdXRpbmcsIHRoaXMgaXMgbm90IHN1cHBvc2VkIHRvICANCj4+Pj4+Pj4+ IGhhcHBlbiAgICAgKGF0IGxlYXN0IGluIHRoZW9yeSkuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhp cyBuZXh0IHN0YXRlbWVudCBpcyB3aGVyZSB0aGVyZSBpcyBhIGJpZyBkaWZmZXJlbmNlOg0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+IElmIHRoZSBkb21haW4gaXMgTk9UIHJlc3BvbnNpYmxlIGZvciB0aGUg VVJJLCB0aGUgbWFwcGluZyAgDQo+Pj4+Pj4+PiBjYW5ub3Qga25vdw0KPj4+Pj4+PiBpZiB0aGUg bmV3IFVSSSBpcyBiZWxvbmdzIHRvIHRoZSBzYW1lIFVzZXIgdGhhbiB0aGUgb3JpZ2luYWwgIA0K Pj4+Pj4+PiBvbmUuIFRoaXMNCj4+Pj4+Pj4gaXMgd2h5IGl0IGlzIG1hcHBpbmc6IGl0IGlzIGlt cG9zc2libGUgZm9yIGEgcHJveHkgTk9UDQo+Pj4+Pj4+PiByZXNwb25zaWJsZSBmb3IgYSBVUkkg dG8gY2hhbmdlIGl0IHRvIHNvbWV0aGluZyBlbHNlIGFuZCAgDQo+Pj4+Pj4+PiAia25vdyIgaWYg aXQgYQ0KPj4+Pj4+PiBkaWZmZXJlbnQgdXNlciAocmV0YXJnZXQpIG9yIGp1c3QgYSAic3lub255 bSIgZm9yIHRoZSBzYW1lIHVzZXIuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFdlIGRvbid0IHRoaW5rIGl0 IGlzICJpbXBvc3NpYmxlIiwgYW5kIHdlIHNlZSBubyByZWFzb24gd2h5IHdlICANCj4+Pj4+Pj4g c2hvdWxkDQo+Pj4+Pj4+IG1ha2UgdGhhdCByZXN0cmljdGlvbiB3aXRob3V0IGFueSB0ZWNobmlj YWwganVzdGlmaWNhdGlvbi4gVGhlICANCj4+Pj4+Pj4gcHJveHkNCj4+Pj4+Pj4gZG9lcyBub3Qg Y2hhbmdlIHRoZSBVUkkganVzdCBmb3IgZnVuLCB3aXRoIGEgdmFsdWUgb3V0IG9mIHRoZSAgDQo+ Pj4+Pj4+IGJsdWUgLSBpdA0KPj4+Pj4+PiBkb2VzIGl0IGJhc2VkIG9uIHNvbWUga2luZCBvZiBr bm93bGVkZ2UvY29uZmlndXJhdGlvbi4NCj4+Pj4+Pj4NCj4+Pj4+Pj4+IDIpIFRhcmdldC1VSQ0K Pj4+Pj4+Pj4NCj4+Pj4+Pj4+IEluIHRhcmdldC1VUkksIHRoZXJlIGlzIGFuIGFzc3VtcHRpb24g dGhhdCBhIGRvbWFpbiBOT1QgIA0KPj4+Pj4+Pj4gcmVzcG9uc2libGUgZm9yDQo+Pj4+Pj4+IGEg VVJJIGNhbiBjaGFuZ2UgdGhlIFVSSSB0byBzb21ldGhpbmcgQU5EIGtub3cgYXV0aG9yaXRhdGl2 ZWx5ICANCj4+Pj4+Pj4gdGhhdCB0aGUNCj4+Pj4+Pj4gbmV3IHRhcmdldCBpcyBhICJzeW5vbnlt IiBmb3IgdGhlIG9yaWdpbmFsIHRhcmdldC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQ29ycmVjdC4NCj4+ Pj4+Pj4gQW5kLCBJIGFzc3VtZSB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuICJzeW5vbXltIiBhbmQg ImFsaWFzIiBpcyAgDQo+Pj4+Pj4+IHRoYXQgYQ0KPj4+Pj4+PiBzeW5vbnltIFVSSSBpcyBub3Qg cmVnaXN0ZXJlZCBmb3IgdGhlIGNhbGxlZCB1c2VyLCByaWdodD8NCj4+Pj4+Pj4NCj4+Pj4+Pj4g QnV0LCBvbmUgcXVlc3Rpb24gZm9yIGNsYXJpZmljYXRpb246IGlmIHRoZSAic3lub255bSIgIA0K Pj4+Pj4+PiB0cmFuc2xhdGlvbiBpcw0KPj4+Pj4+PiBkb25lIGJ5IGFuIGVudGl0eSB3aGljaCBJ UyByZXBvbnNpYmxlIGZvciB0aGUgZG9tYWluLCBob3cgaXMgaXQgIA0KPj4+Pj4+PiB0YWdnZWQ/ DQo+Pj4+Pj4+DQo+Pj4+Pj4+IC0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4NCj4+Pj4+Pj4+IFNvIHRo aXMgaXMgd2hhdCBpdCBib2lscyBkb3duIHRvLg0KPj4+Pj4+PiBJIHRoaW5rIHRoYXQgaXMgbW9y ZSBvciBsZXNzIHdoYXQgSSB3YXMgdHJ5aW5nIHRvIHNheS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4+IENh biBhIGRvbWFpbiBOT1QgcmVzcG9uc2libGUgZm9yIGEgdGFyZ2V0IGNoYW5nZSB0aGUgdGFyZ2V0 ICANCj4+Pj4+Pj4+IEFORCBtYXJrDQo+Pj4+Pj4+IHRoZSBuZXcgdGFyZ2V0IGF1dGhvcml0YXRp dmVseSBhcyAiYmVsb25naW5nIiB0byB0aGUgc2FtZSB1c2VyPw0KPj4+Pj4+Pj4gSW4gdGFyZ2V0 LVVSSSwgdGhlIGFzc3VtcHRpb24gaXMgeWVzLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEluIDQyNDRi aXMsIHRoZSBhc3N1bXB0aW9uIGlzIG5vIChvbmx5IHRoZSBkb21haW4gcmVzcG9uc2libGUgIA0K Pj4+Pj4+Pj4gZm9yIHRoZQ0KPj4+Pj4+PiBVUkkgY2FuIGRvIHNvKS4NCj4+Pj4+Pj4gQ29ycmVj dC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gQXMg cG9pbnRlZCBvdXQgYnkgUGF1bCBLeXppdmF0LCB3ZSBwcm9iYWJseSBuZWVkIHRvIHRoaW5rIG9u ICANCj4+Pj4+Pj4+IGhvdyB0aGlzDQo+Pj4+Pj4+IHdvcmtzIHdpdGggVGVsIFVSSXMuIEkgdGhp bmsgZm9yIFRlbCBVUkkgaXQgd291bGQgYmUgdG90YWxseSAgDQo+Pj4+Pj4+IGRpZmZlcmVudC4N Cj4+Pj4+Pj4NCj4+Pj4+Pj4gWWVzLiBZb3UgcmFpc2VkIHRoYXQgYWxzbyBpbiBvdXIgcHJpdmF0 ZSBkaXNjdXNzaW9ucywgYnV0IHdlICANCj4+Pj4+Pj4gbmV2ZXINCj4+Pj4+Pj4gZGlzY3Vzc2Vk IGl0IGluIGRldGFpbHMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFNvLCBiZWZvcmUgd2Ugc3RhcnQgZGlz Y3Vzc2luZyB0aGUgcHJvdG9jb2wgZGV0YWlscywgSSB0aGluayB3ZSAgDQo+Pj4+Pj4+IG5lZWQg dG8NCj4+Pj4+Pj4gc29sdmUgdGhlIGlzc3VlcyBhYm92ZS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gUmVn YXJkcywNCj4+Pj4+Pj4NCj4+Pj4+Pj4gQ2hyaXN0ZXINCj4+Pj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4gc2lwY29yZSBtYWlsaW5n IGxpc3QNCj4+Pj4+Pj4gc2lwY29yZUBpZXRmLm9yZw0KPj4+Pj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4+Pj4+Pj4NCj4+Pj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IHNpcGNvcmUgbWFp bGluZyBsaXN0DQo+Pj4+Pj4gc2lwY29yZUBpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+PiBz aXBjb3JlQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NpcGNvcmUNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo= From ietf.hanserik@gmail.com Mon Jun 15 12:18:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27B323A6C86 for ; Mon, 15 Jun 2009 12:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[AWL=-0.951, BAYES_00=-2.599, MANGLED_REGALS=2.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfSAv4vCunjf for ; Mon, 15 Jun 2009 12:18:05 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 6E73C3A6D08 for ; Mon, 15 Jun 2009 12:18:04 -0700 (PDT) Received: by ewy6 with SMTP id 6so5297102ewy.37 for ; Mon, 15 Jun 2009 12:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Zq6SQm5XtWUucdsN7XzibA/wrELHAiSJrvZbrT8iTtw=; b=HWBTo3vA8A9GQ/tgCL9N4sm6j1UBhO6ZyUKvwpd6lVSETvxyS/OldTtA5KtDj7zzzB cTTWevZGPeM+DABI0viaB4G9haci9tncw/FDH2c58oj/DKA8GRaqVllCqouoYM/MW6Fv X1IEhJ2/zsnGje+bGTGffKQNPq9U+Zd5yD5+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=jkRN5y6QZxOWnBXA7ChD0ZOMWjD4tWF1dQAt9+kIeR12DbgSzmQBuOVnvvkW9O67dN fr9nHWMwX1cG5JHysbQbL5MFNJ83b3lvVQkG5Es8sunqF1Yep5da9YnYltJKQfVC+srA Ll0YwQVLJbcbxzzyykvoEMSpVmI7yEKTO8eZc= Received: by 10.210.119.5 with SMTP id r5mr7602939ebc.88.1245093457211; Mon, 15 Jun 2009 12:17:37 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 24sm96208eyx.33.2009.06.15.12.17.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Jun 2009 12:17:36 -0700 (PDT) Message-ID: <4A369E4F.5050305@gmail.com> Date: Mon, 15 Jun 2009 21:17:35 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Francois Audet References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <4A369CDE.8030105@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83D981@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83D981@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 19:18:06 -0000 For an alias you do not translate to another AOR, you will just rewrite with the contact. The UAS is in this case interested with which AOR it was being reached, not whether this is an alias. It might be interested in that, but we haven't defined a requirement for that. /Hans Erik Francois Audet wrote: > So... Then why do we need the difference between mapped-to-new-guy > and this-is-just-an-alias-aor again? > > >> -----Original Message----- >> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> Sent: Monday, June 15, 2009 12:11 >> To: Barnes, Mary (RICH2:AR00) >> Cc: Christer Holmberg; Audet, Francois (SC100:3055); DOLLY, >> MARTIN C, ATTLABS; sipcore@ietf.org >> Subject: Re: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> I disagree that the UAS needs to be aware about such >> services. It is only interested in extracting the addressed >> target in a generic way. >> >> /Hans Erik >> >> Mary Barnes wrote: >> >>> Correct. But, what I am suggesting is that you distinguish >>> >> it at the >> >>> UAS >>> - I'm assuming that the target Request-URI that arrives at >>> >> the UAS is >> >>> something that identifies a client that handles 800 numbers. That >>> client could be configured such that it knows to look for >>> >> the original >> >>> 800 number in the mapped URIs or in the reg-alias-URIs or both. >>> Again, if you're making these 800 numbers special and >>> >> allowing proxies >> >>> to change them in multiple ways (i.e., non-deterministic), >>> >> then if you >> >>> want them tagged special, then you need special logic in >>> >> the proxies >> >>> to do this. That doesn't make sense to me, although you >>> >> could do it >> >>> that way in a closed network, in which case you can make sure to >>> always tag them as whatever you think they should be - so we could >>> define an additional value for the tag. But, this is what I don't >>> think is right in terms of normal SIP request routing and >>> >> forwarding, >> >>> which is what the current 4244bis tags have been defined to >>> >> represent. >> >>> Mary. >>> >>> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Monday, June 15, 2009 1:23 PM >>> To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, >>> MARTIN C, ATTLABS; sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> >>> Hi Mary, >>> >>> Proxies will tag entries based on the functionality they perform. >>> >>> Let's leave req-uri-alias for the moment. >>> >>> As I said earlier, one of the issues we have with 4244bis, is that >>> "mapped" seems to be used BOTH for diversion and when an AOR is >>> replaced with another AOR pointing to the same user - e.g. >>> >> freephone. >> >>> So, it is not possible to distinguish between diversion and >>> >> freephone. >> >>> We think one MUST be able to make that distinguishment, because you >>> may have cases where both diversion and service number >>> >> translation (e.g. >> >>> freephone) occurs, and the UAS needs to know which is which. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Mary Barnes [mailto:mary.barnes@nortel.com] >>> Sent: Monday, June 15, 2009 9:13 PM >>> To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; >>> sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> It seems to me that the gist of this discussion has been >>> >> based on the >> >>> expectation that independent of how the 800 number is configured, >>> registered or whatever at a proxy, that there is an expectation of >>> deterministic behavior in terms of how it's tagged. So, if 800 >>> numbers are special and they can end up tagged as either >>> >> reg-uri-alias >> >>> or as mapped, then perhaps the service has to know that it needs to >>> look for either of those. ISTM that if there is a reason to >>> >> preserve >> >>> that it's an 800 number (i.e., and not format as a service specific >>> uri), the service at the UAS knows that it's special, thus it would >>> need to check the request-URIs associated with both >>> >> reg-uri-alias and mapped hi-entries. >> >>> I can't see how we can make it work any other way without being >>> prescriptive of how proxy's MUST tag these entries, which is not a >>> good idea IMHO. However, I think these numbers are either special >>> cases at proxies or something that services know about. >>> >>> Mary. >>> >>> -----Original Message----- >>> From: Audet, Francois (SC100:3055) >>> Sent: Monday, June 15, 2009 12:47 PM >>> To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary >>> (RICH2:AR00); sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> Yes, we need to sort out what to do for that. >>> >>> >>> >>>> -----Original Message----- >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: Monday, June 15, 2009 10:17 >>>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, >>>> >> ATTLABS; Barnes, >> >>>> Mary (RICH2:AR00); sipcore@ietf.org >>>> Subject: RE: [sipcore] FW: I-D >>>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>>> >>>> >>>> But if it is NOT an alias (=implicitly/explicitly registered)? >>>> >>>> -----Original Message----- >>>> From: Francois Audet [mailto:audet@nortel.com] >>>> Sent: Monday, June 15, 2009 6:50 PM >>>> To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes; >>>> sipcore@ietf.org >>>> Subject: RE: [sipcore] FW: I-D >>>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>>> >>>> then reg-uri-alias. >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>>> Sent: Saturday, June 13, 2009 01:22 >>>>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, >>>>> >> ATTLABS; Barnes, >> >>>>> Mary (RICH2:AR00); sipcore@ietf.org >>>>> Subject: RE: [sipcore] FW: I-D >>>>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>>> 1) RFC 4244bis >>>>>> >>>>>> In RFC 4244bis, if the domain is responsible for the URI in the >>>>>> >>>>>> >>>>> Request-URI and it replacing it with a Contact, it will put >>>>> >>>>> >>>> a reg-uri >>>> >>>> >>>>> flag (if the Request-URI was the AOR used for >>>>> >> registration), or reg- >> >>>>> >>>>> >>>>>> uri-alias (if the Request-URI was an alias for the AOR used in >>>>>> >>>>>> >>>>> registration). >>>>> >>>>> And if the Request-URI was a "synonym" for the AOR? >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> From mary.barnes@nortel.com Mon Jun 15 12:19:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E83628C0FD for ; Mon, 15 Jun 2009 12:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.422 X-Spam-Level: X-Spam-Status: No, score=-6.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJOQym0XhPSA for ; Mon, 15 Jun 2009 12:19:24 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 3D7BE3A6900 for ; Mon, 15 Jun 2009 12:19:24 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5FJHOx26247; Mon, 15 Jun 2009 19:17:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 14:21:16 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E83D9A3@zrc2hxm0.corp.nortel.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA02BD4813@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] The functional differences between 4244bis andtarget-uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) thread-index: Acnt7WzRHQsf0D0uRdupn7uzFfgKewAAFKSBAAApVaA= References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4813@gaalpa1msgusr7e.ugd.att.com> From: "Mary Barnes" To: "DOLLY, MARTIN C, ATTLABS" , Cc: sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] The functional differences between 4244bis andtarget-uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 19:19:25 -0000 And, how do you map those to the tags in 4244bis and target-uri? =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C, ATTLABS Sent: Monday, June 15, 2009 2:16 PM To: pkyzivat@cisco.com Cc: sipcore@ietf.org; shida@agnada.com Subject: Re: [sipcore] The functional differences between 4244bis andtarget-uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) 1. Translation 2. Retarget 3. Redirect ----- Original Message ----- From: Paul Kyzivat To: DOLLY, MARTIN C, ATTLABS Cc: shida@agnada.com ; sipcore@ietf.org Sent: Mon Jun 15 15:13:34 2009 Subject: Re: [sipcore] The functional differences between 4244bis andtarget- uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) DOLLY, MARTIN C, ATTLABS wrote: > Simple requirement: capture ALL retarget information in HI. Period We have had the ability to capture all retargeting with H-I since it was first published. The new requirement is to distinguish different sorts of retargeting. If so its very important that everybody understand the meaning of each type and how to determine that type each time a request is retargeted. I was getting the impression (may be wrong about it) that a third type of retargeting was now being identified. We need to agree on what it is that we are capturing. Thanks, Paul > ----- Original Message ----- > From: sipcore-bounces@ietf.org > To: Paul Kyzivat > Cc: DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org > Sent: Mon Jun 15 08:20:15 2009 > Subject: Re: [sipcore] The functional differences between 4244bis=20 > andtarget- uri (was FW:=20 > I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) >=20 >=20 > I don't think it's a special case for free-dial alone. >=20 > If service URN is used to deliver a service request such as=20 > emergency call or directory assistance request to a local call-center, > and takes a similar approach to what's defined in phoneBCP to support=20 > devices not compliant to service URN, the translation to service URN=20 > from the dial string will be done by the proxy. But the translation=20 > from 911 to "sos" will only be seen in request URI and not in the To=20 > header. >=20 > So To header even without diversion is not dependable. >=20 > Regards > Shida >=20 > On 15-Jun-09, at 6:28 AM, Paul Kyzivat wrote: >=20 >> >> Hans Erik van Elburg wrote: >>> But that does not work when a diversion to that service number takes >>> place. It only works for direct calls to such service number. >> Perhaps. That depends on *if* that is a reasonable scenario, and if=20 >> so precisely what you want to happen in that case. >> >> For instance, does it really make sense for you to call me, and for=20 >> me to then divert you to an 800 number? If so, is that supposed to=20 >> behave as if you had called the 800 number? >> >> I realize there are many possible desired outcomes, so many=20 >> strategies may be used from case to case. >> >> Thanks, >> Paul >> >>> /Hans Erik >>> Paul Kyzivat wrote: >>>> >>>> Hans Erik van Elburg wrote: >>>>> Hi Paul, >>>>> >>>>> For what would you want to use the To-uri? >>>> To decide who/what the caller desired to reach, and hence what=20 >>>> treatment to give the call. This seems to be the key thing for the=20 >>>> call centers that use freephone numbers. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> /Hans Erik >>>>> >>>>> Paul Kyzivat wrote: >>>>>> This thing about the freephone services is an ugly one. >>>>>> I've thought for a long time that the mechanism is an entirely=20 >>>>>> brain dead way to designate who should pay for a call. >>>>>> >>>>>> But it is what it is, so I guess we have to cope with it. >>>>>> >>>>>> I wonder if perhaps this is really one of the few circumstances=20 >>>>>> where the recipient of a call ought to make call handling=20 >>>>>> decisions based on the To-uri. The reason I say this is because=20 >>>>>> the "contract" with these numbers is that the caller expects the=20 >>>>>> call will be free based on the form of the number being called. >>>>>> And if the caller is wrong, it is the caller who gets charged. >>>>>> >>>>>> So, while I generally recommend that the To-uri be used for=20 >>>>>> *nothing*, it might be right here. If so, then the whole target-=20 >>>>>> uri/h-i discussion may be irrelevant to it. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> Christer Holmberg wrote: >>>>>>> Hi, >>>>>>>> I'm going to spare details, but the main different is as=20 >>>>>>>> follows. >>>>>>>> >>>>>>>> 1) RFC 4244bis >>>>>>>> >>>>>>>> In RFC 4244bis, if the domain is responsible for the URI in the >>>>>>> Request-URI and it replacing it with a Contact, it will put a=20 >>>>>>> reg-uri flag (if the Request-URI was the AOR used for=20 >>>>>>> registration), or >>>>>>> reg- >>>>>>>> uri-alias (if the Request-URI was an alias for the AOR used in >>>>>>> registration). >>>>>>>> If the domain is responsible for the URI and it "maps" it to a >>>>>>> different user, then it puts a "mapped" flag. >>>>>>>> If the domain is NOT responsible for the AOR but it changes the >>>>>>> Request-URI nevertheless, then it is also marked as "mapped". >>>>>>>> Note: With loose routing, this is not supposed to =20 >>>>>>>> happen (at least in theory). >>>>>>>> >>>>>>>> This next statement is where there is a big difference: >>>>>>>> >>>>>>>> If the domain is NOT responsible for the URI, the mapping=20 >>>>>>>> cannot know >>>>>>> if the new URI is belongs to the same User than the original=20 >>>>>>> one. This is why it is mapping: it is impossible for a proxy NOT >>>>>>>> responsible for a URI to change it to something else and "know" >>>>>>>> if it a >>>>>>> different user (retarget) or just a "synonym" for the same user. >>>>>>> >>>>>>> We don't think it is "impossible", and we see no reason why we=20 >>>>>>> should make that restriction without any technical=20 >>>>>>> justification. The proxy does not change the URI just for fun,=20 >>>>>>> with a value out of the blue - it does it based on some kind of=20 >>>>>>> knowledge/configuration. >>>>>>> >>>>>>>> 2) Target-UI >>>>>>>> >>>>>>>> In target-URI, there is an assumption that a domain NOT=20 >>>>>>>> responsible for >>>>>>> a URI can change the URI to something AND know authoritatively=20 >>>>>>> that the new target is a "synonym" for the original target. >>>>>>> >>>>>>> Correct. >>>>>>> And, I assume the difference between "synomym" and "alias" is=20 >>>>>>> that a synonym URI is not registered for the called user, right? >>>>>>> >>>>>>> But, one question for clarification: if the "synonym" =20 >>>>>>> translation is >>>>>>> done by an entity which IS reponsible for the domain, how is it=20 >>>>>>> tagged? >>>>>>> >>>>>>> ------------- >>>>>>> >>>>>>>> So this is what it boils down to. >>>>>>> I think that is more or less what I was trying to say. >>>>>>> >>>>>>>> Can a domain NOT responsible for a target change the target AND >>>>>>>> mark >>>>>>> the new target authoritatively as "belonging" to the same user? >>>>>>>> In target-URI, the assumption is yes. >>>>>>>> >>>>>>>> In 4244bis, the assumption is no (only the domain responsible=20 >>>>>>>> for the >>>>>>> URI can do so). >>>>>>> Correct. >>>>>>> >>>>>>> ------------- >>>>>>> >>>>>>>> As pointed out by Paul Kyzivat, we probably need to think on=20 >>>>>>>> how this >>>>>>> works with Tel URIs. I think for Tel URI it would be totally=20 >>>>>>> different. >>>>>>> >>>>>>> Yes. You raised that also in our private discussions, but we=20 >>>>>>> never discussed it in details. >>>>>>> >>>>>>> So, before we start discussing the protocol details, I think we=20 >>>>>>> need to solve the issues above. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> _______________________________________________ >>>>>>> sipcore mailing list >>>>>>> sipcore@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>> >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > 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 mdolly@att.com Mon Jun 15 12:27:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 186953A6900 for ; Mon, 15 Jun 2009 12:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.28 X-Spam-Level: X-Spam-Status: No, score=-106.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3E9GGQNGw+VN for ; Mon, 15 Jun 2009 12:27:20 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id A8CAB3A681A for ; Mon, 15 Jun 2009 12:27:20 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-12.tower-161.messagelabs.com!1245094049!25882261!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 13672 invoked from network); 15 Jun 2009 19:27:30 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-12.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Jun 2009 19:27:30 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5FJRTvJ008100 for ; Mon, 15 Jun 2009 15:27:29 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5FJRQGU008076 for ; Mon, 15 Jun 2009 15:27:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 15 Jun 2009 15:27:25 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD4814@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] The functional differences between 4244bis andtarget-uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) Thread-Index: Acnt7WzRHQsf0D0uRdupn7uzFfgKewAAFKSBAAApVaAAADrrXw== From: "DOLLY, MARTIN C, ATTLABS" To: , Cc: sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] The functional differences between 4244bis andtarget-uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 19:27:25 -0000 VGhlc2UgbWFrZSBzZW5zZSB0byBtZS4gSSBkbyBub3Qga25vdyBhYm91dCB5b3VyIHRhZ3M/DQoN Ci0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IE1hcnkgQmFybmVzIDxtYXJ5LmJh cm5lc0Bub3J0ZWwuY29tPg0KVG86IERPTExZLCBNQVJUSU4gQywgQVRUTEFCUzsgcGt5eml2YXRA Y2lzY28uY29tIDxwa3l6aXZhdEBjaXNjby5jb20+DQpDYzogc2lwY29yZUBpZXRmLm9yZyA8c2lw Y29yZUBpZXRmLm9yZz47IHNoaWRhQGFnbmFkYS5jb20gPHNoaWRhQGFnbmFkYS5jb20+DQpTZW50 OiBNb24gSnVuIDE1IDE1OjIxOjE2IDIwMDkNClN1YmplY3Q6IFJFOiBbc2lwY29yZV0gVGhlIGZ1 bmN0aW9uYWwgZGlmZmVyZW5jZXMgYmV0d2VlbiA0MjQ0YmlzIGFuZHRhcmdldC11cmkgKHdhcyBG VzogSS1EQWN0aW9uOmRyYWZ0LWJhcm5lcy1zaXBjb3JlLXJmYzQyNDRiaXMtMDEudHh0KQ0KDQpB bmQsIGhvdyBkbyB5b3UgbWFwIHRob3NlIHRvIHRoZSB0YWdzIGluIDQyNDRiaXMgYW5kIHRhcmdl dC11cmk/ICANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNpcGNvcmUtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24NCkJlaGFs ZiBPZiBET0xMWSwgTUFSVElOIEMsIEFUVExBQlMNClNlbnQ6IE1vbmRheSwgSnVuZSAxNSwgMjAw OSAyOjE2IFBNDQpUbzogcGt5eml2YXRAY2lzY28uY29tDQpDYzogc2lwY29yZUBpZXRmLm9yZzsg c2hpZGFAYWduYWRhLmNvbQ0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBUaGUgZnVuY3Rpb25hbCBk aWZmZXJlbmNlcyBiZXR3ZWVuIDQyNDRiaXMNCmFuZHRhcmdldC11cmkgKHdhcyBGVzogSS1EQWN0 aW9uOmRyYWZ0LWJhcm5lcy1zaXBjb3JlLXJmYzQyNDRiaXMtMDEudHh0KQ0KDQoxLiBUcmFuc2xh dGlvbg0KMi4gUmV0YXJnZXQNCjMuIFJlZGlyZWN0DQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0NCkZyb206IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAY2lzY28uY29tPg0KVG86IERPTExZ LCBNQVJUSU4gQywgQVRUTEFCUw0KQ2M6IHNoaWRhQGFnbmFkYS5jb20gPHNoaWRhQGFnbmFkYS5j b20+OyBzaXBjb3JlQGlldGYub3JnDQo8c2lwY29yZUBpZXRmLm9yZz4NClNlbnQ6IE1vbiBKdW4g MTUgMTU6MTM6MzQgMjAwOQ0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBUaGUgZnVuY3Rpb25hbCBk aWZmZXJlbmNlcyBiZXR3ZWVuIDQyNDRiaXMNCmFuZHRhcmdldC0gdXJpICh3YXMgRlc6DQpJLURB Y3Rpb246ZHJhZnQtYmFybmVzLXNpcGNvcmUtcmZjNDI0NGJpcy0wMS50eHQpDQoNCg0KDQpET0xM WSwgTUFSVElOIEMsIEFUVExBQlMgd3JvdGU6DQo+IFNpbXBsZSByZXF1aXJlbWVudDogY2FwdHVy ZSBBTEwgcmV0YXJnZXQgaW5mb3JtYXRpb24gaW4gSEkuIFBlcmlvZA0KDQpXZSBoYXZlIGhhZCB0 aGUgYWJpbGl0eSB0byBjYXB0dXJlIGFsbCByZXRhcmdldGluZyB3aXRoIEgtSSBzaW5jZSBpdCB3 YXMNCmZpcnN0IHB1Ymxpc2hlZC4gVGhlIG5ldyByZXF1aXJlbWVudCBpcyB0byBkaXN0aW5ndWlz aCBkaWZmZXJlbnQgc29ydHMNCm9mIHJldGFyZ2V0aW5nLiBJZiBzbyBpdHMgdmVyeSBpbXBvcnRh bnQgdGhhdCBldmVyeWJvZHkgdW5kZXJzdGFuZCB0aGUNCm1lYW5pbmcgb2YgZWFjaCB0eXBlIGFu ZCBob3cgdG8gZGV0ZXJtaW5lIHRoYXQgdHlwZSBlYWNoIHRpbWUgYSByZXF1ZXN0DQppcyByZXRh cmdldGVkLiBJIHdhcyBnZXR0aW5nIHRoZSBpbXByZXNzaW9uIChtYXkgYmUgd3JvbmcgYWJvdXQg aXQpIHRoYXQNCmEgdGhpcmQgdHlwZSBvZiByZXRhcmdldGluZyB3YXMgbm93IGJlaW5nIGlkZW50 aWZpZWQuDQoNCldlIG5lZWQgdG8gYWdyZWUgb24gd2hhdCBpdCBpcyB0aGF0IHdlIGFyZSBjYXB0 dXJpbmcuDQoNCglUaGFua3MsDQoJUGF1bA0KDQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0NCj4gRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIDxzaXBjb3JlLWJvdW5jZXNAaWV0 Zi5vcmc+DQo+IFRvOiBQYXVsIEt5eml2YXQgPHBreXppdmF0QGNpc2NvLmNvbT4NCj4gQ2M6IERP TExZLCBNQVJUSU4gQywgQVRUTEFCUzsgc2lwY29yZUBpZXRmLm9yZyA8c2lwY29yZUBpZXRmLm9y Zz4NCj4gU2VudDogTW9uIEp1biAxNSAwODoyMDoxNSAyMDA5DQo+IFN1YmplY3Q6IFJlOiBbc2lw Y29yZV0gVGhlIGZ1bmN0aW9uYWwgZGlmZmVyZW5jZXMgYmV0d2VlbiA0MjQ0YmlzIA0KPiBhbmR0 YXJnZXQtIHVyaSAod2FzIEZXOiANCj4gSS1EQWN0aW9uOmRyYWZ0LWJhcm5lcy1zaXBjb3JlLXJm YzQyNDRiaXMtMDEudHh0KQ0KPiANCj4gDQo+ICAgSSBkb24ndCB0aGluayBpdCdzIGEgc3BlY2lh bCBjYXNlIGZvciBmcmVlLWRpYWwgYWxvbmUuDQo+IA0KPiAgIElmIHNlcnZpY2UgVVJOIGlzIHVz ZWQgdG8gZGVsaXZlciBhIHNlcnZpY2UgcmVxdWVzdCBzdWNoIGFzIA0KPiBlbWVyZ2VuY3kgY2Fs bCBvciBkaXJlY3RvcnkgYXNzaXN0YW5jZSByZXF1ZXN0IHRvIGEgbG9jYWwgY2FsbC1jZW50ZXIs DQoNCj4gYW5kIHRha2VzIGEgc2ltaWxhciBhcHByb2FjaCB0byB3aGF0J3MgZGVmaW5lZCBpbiBw aG9uZUJDUCB0byBzdXBwb3J0IA0KPiBkZXZpY2VzIG5vdCBjb21wbGlhbnQgdG8gc2VydmljZSBV Uk4sIHRoZSB0cmFuc2xhdGlvbiB0byBzZXJ2aWNlIFVSTiANCj4gZnJvbSB0aGUgZGlhbCBzdHJp bmcgd2lsbCBiZSBkb25lIGJ5IHRoZSBwcm94eS4gQnV0IHRoZSB0cmFuc2xhdGlvbiANCj4gZnJv bSA5MTEgdG8gInNvcyIgd2lsbCBvbmx5IGJlIHNlZW4gaW4gcmVxdWVzdCBVUkkgYW5kIG5vdCBp biB0aGUgVG8gDQo+IGhlYWRlci4NCj4gDQo+ICAgU28gVG8gaGVhZGVyIGV2ZW4gd2l0aG91dCBk aXZlcnNpb24gaXMgbm90IGRlcGVuZGFibGUuDQo+IA0KPiAgIFJlZ2FyZHMNCj4gICAgU2hpZGEN Cj4gDQo+IE9uIDE1LUp1bi0wOSwgYXQgNjoyOCBBTSwgUGF1bCBLeXppdmF0IHdyb3RlOg0KPiAN Cj4+DQo+PiBIYW5zIEVyaWsgdmFuIEVsYnVyZyB3cm90ZToNCj4+PiBCdXQgdGhhdCBkb2VzIG5v dCB3b3JrIHdoZW4gYSBkaXZlcnNpb24gdG8gdGhhdCBzZXJ2aWNlIG51bWJlciB0YWtlcw0KDQo+ Pj4gcGxhY2UuIEl0IG9ubHkgd29ya3MgZm9yIGRpcmVjdCBjYWxscyB0byBzdWNoIHNlcnZpY2Ug bnVtYmVyLg0KPj4gUGVyaGFwcy4gVGhhdCBkZXBlbmRzIG9uICppZiogdGhhdCBpcyBhIHJlYXNv bmFibGUgc2NlbmFyaW8sIGFuZCBpZiANCj4+IHNvIHByZWNpc2VseSB3aGF0IHlvdSB3YW50IHRv IGhhcHBlbiBpbiB0aGF0IGNhc2UuDQo+Pg0KPj4gRm9yIGluc3RhbmNlLCBkb2VzIGl0IHJlYWxs eSBtYWtlIHNlbnNlIGZvciB5b3UgdG8gY2FsbCBtZSwgYW5kIGZvciANCj4+IG1lIHRvIHRoZW4g ZGl2ZXJ0IHlvdSB0byBhbiA4MDAgbnVtYmVyPyBJZiBzbywgaXMgdGhhdCBzdXBwb3NlZCB0byAN Cj4+IGJlaGF2ZSBhcyBpZiB5b3UgaGFkIGNhbGxlZCB0aGUgODAwIG51bWJlcj8NCj4+DQo+PiBJ IHJlYWxpemUgdGhlcmUgYXJlIG1hbnkgcG9zc2libGUgZGVzaXJlZCBvdXRjb21lcywgc28gbWFu eSANCj4+IHN0cmF0ZWdpZXMgbWF5IGJlIHVzZWQgZnJvbSBjYXNlIHRvIGNhc2UuDQo+Pg0KPj4g CVRoYW5rcywNCj4+IAlQYXVsDQo+Pg0KPj4+IC9IYW5zIEVyaWsNCj4+PiBQYXVsIEt5eml2YXQg d3JvdGU6DQo+Pj4+DQo+Pj4+IEhhbnMgRXJpayB2YW4gRWxidXJnIHdyb3RlOg0KPj4+Pj4gSGkg UGF1bCwNCj4+Pj4+DQo+Pj4+PiBGb3Igd2hhdCB3b3VsZCB5b3Ugd2FudCB0byB1c2UgdGhlIFRv LXVyaT8NCj4+Pj4gVG8gZGVjaWRlIHdoby93aGF0IHRoZSBjYWxsZXIgZGVzaXJlZCB0byByZWFj aCwgYW5kIGhlbmNlIHdoYXQgDQo+Pj4+IHRyZWF0bWVudCB0byBnaXZlIHRoZSBjYWxsLiBUaGlz IHNlZW1zIHRvIGJlIHRoZSBrZXkgdGhpbmcgZm9yIHRoZSANCj4+Pj4gY2FsbCBjZW50ZXJzIHRo YXQgdXNlIGZyZWVwaG9uZSBudW1iZXJzLg0KPj4+Pg0KPj4+PiAgICBUaGFua3MsDQo+Pj4+ICAg IFBhdWwNCj4+Pj4NCj4+Pj4+IC9IYW5zIEVyaWsNCj4+Pj4+DQo+Pj4+PiBQYXVsIEt5eml2YXQg d3JvdGU6DQo+Pj4+Pj4gVGhpcyB0aGluZyBhYm91dCB0aGUgZnJlZXBob25lIHNlcnZpY2VzIGlz IGFuIHVnbHkgb25lLg0KPj4+Pj4+IEkndmUgdGhvdWdodCBmb3IgYSBsb25nIHRpbWUgdGhhdCB0 aGUgbWVjaGFuaXNtIGlzIGFuIGVudGlyZWx5IA0KPj4+Pj4+IGJyYWluIGRlYWQgd2F5IHRvIGRl c2lnbmF0ZSB3aG8gc2hvdWxkIHBheSBmb3IgYSBjYWxsLg0KPj4+Pj4+DQo+Pj4+Pj4gQnV0IGl0 IGlzIHdoYXQgaXQgaXMsIHNvIEkgZ3Vlc3Mgd2UgaGF2ZSB0byBjb3BlIHdpdGggaXQuDQo+Pj4+ Pj4NCj4+Pj4+PiBJIHdvbmRlciBpZiBwZXJoYXBzIHRoaXMgaXMgcmVhbGx5IG9uZSBvZiB0aGUg ZmV3IGNpcmN1bXN0YW5jZXMgDQo+Pj4+Pj4gd2hlcmUgdGhlIHJlY2lwaWVudCBvZiBhIGNhbGwg b3VnaHQgdG8gbWFrZSBjYWxsIGhhbmRsaW5nIA0KPj4+Pj4+IGRlY2lzaW9ucyBiYXNlZCBvbiB0 aGUgVG8tdXJpLiBUaGUgcmVhc29uIEkgc2F5IHRoaXMgaXMgYmVjYXVzZSANCj4+Pj4+PiB0aGUg ImNvbnRyYWN0IiB3aXRoIHRoZXNlIG51bWJlcnMgaXMgdGhhdCB0aGUgY2FsbGVyIGV4cGVjdHMg dGhlIA0KPj4+Pj4+IGNhbGwgd2lsbCBiZSBmcmVlIGJhc2VkIG9uIHRoZSBmb3JtIG9mIHRoZSBu dW1iZXIgYmVpbmcgY2FsbGVkLg0KPj4+Pj4+IEFuZCBpZiB0aGUgY2FsbGVyIGlzIHdyb25nLCBp dCBpcyB0aGUgY2FsbGVyIHdobyBnZXRzIGNoYXJnZWQuDQo+Pj4+Pj4NCj4+Pj4+PiBTbywgd2hp bGUgSSBnZW5lcmFsbHkgcmVjb21tZW5kIHRoYXQgdGhlIFRvLXVyaSBiZSB1c2VkIGZvciANCj4+ Pj4+PiAqbm90aGluZyosIGl0IG1pZ2h0IGJlIHJpZ2h0IGhlcmUuIElmIHNvLCB0aGVuIHRoZSB3 aG9sZSB0YXJnZXQtIA0KPj4+Pj4+IHVyaS9oLWkgZGlzY3Vzc2lvbiBtYXkgYmUgaXJyZWxldmFu dCB0byBpdC4NCj4+Pj4+Pg0KPj4+Pj4+ICAgIFRoYW5rcywNCj4+Pj4+PiAgICBQYXVsDQo+Pj4+ Pj4NCj4+Pj4+PiBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4+Pj4+Pj4gSGksDQo+Pj4+Pj4+ PiBJJ20gZ29pbmcgdG8gc3BhcmUgZGV0YWlscywgYnV0IHRoZSBtYWluIGRpZmZlcmVudCBpcyBh cyANCj4+Pj4+Pj4+IGZvbGxvd3MuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gMSkgUkZDIDQyNDRiaXMN Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBJbiBSRkMgNDI0NGJpcywgaWYgdGhlIGRvbWFpbiBpcyByZXNw b25zaWJsZSBmb3IgdGhlIFVSSSBpbiB0aGUNCj4+Pj4+Pj4gUmVxdWVzdC1VUkkgYW5kIGl0IHJl cGxhY2luZyBpdCB3aXRoIGEgQ29udGFjdCwgaXQgd2lsbCBwdXQgYSANCj4+Pj4+Pj4gcmVnLXVy aSBmbGFnIChpZiB0aGUgUmVxdWVzdC1VUkkgd2FzIHRoZSBBT1IgdXNlZCBmb3IgDQo+Pj4+Pj4+ IHJlZ2lzdHJhdGlvbiksIG9yDQo+Pj4+Pj4+IHJlZy0NCj4+Pj4+Pj4+IHVyaS1hbGlhcyAoaWYg dGhlIFJlcXVlc3QtVVJJIHdhcyBhbiBhbGlhcyBmb3IgdGhlIEFPUiB1c2VkIGluDQo+Pj4+Pj4+ IHJlZ2lzdHJhdGlvbikuDQo+Pj4+Pj4+PiBJZiB0aGUgZG9tYWluIGlzIHJlc3BvbnNpYmxlIGZv ciB0aGUgVVJJIGFuZCBpdCAibWFwcyIgaXQgdG8gYQ0KPj4+Pj4+PiBkaWZmZXJlbnQgdXNlciwg dGhlbiBpdCBwdXRzIGEgIm1hcHBlZCIgZmxhZy4NCj4+Pj4+Pj4+IElmIHRoZSBkb21haW4gaXMg Tk9UIHJlc3BvbnNpYmxlIGZvciB0aGUgQU9SIGJ1dCBpdCBjaGFuZ2VzIHRoZQ0KPj4+Pj4+PiBS ZXF1ZXN0LVVSSSBuZXZlcnRoZWxlc3MsIHRoZW4gaXQgaXMgYWxzbyBtYXJrZWQgYXMgIm1hcHBl ZCIuDQo+Pj4+Pj4+PiAgICBOb3RlOiBXaXRoIGxvb3NlIHJvdXRpbmcsIHRoaXMgaXMgbm90IHN1 cHBvc2VkIHRvICANCj4+Pj4+Pj4+IGhhcHBlbiAgICAgKGF0IGxlYXN0IGluIHRoZW9yeSkuDQo+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhpcyBuZXh0IHN0YXRlbWVudCBpcyB3aGVyZSB0aGVyZSBpcyBh IGJpZyBkaWZmZXJlbmNlOg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IElmIHRoZSBkb21haW4gaXMgTk9U IHJlc3BvbnNpYmxlIGZvciB0aGUgVVJJLCB0aGUgbWFwcGluZyANCj4+Pj4+Pj4+IGNhbm5vdCBr bm93DQo+Pj4+Pj4+IGlmIHRoZSBuZXcgVVJJIGlzIGJlbG9uZ3MgdG8gdGhlIHNhbWUgVXNlciB0 aGFuIHRoZSBvcmlnaW5hbCANCj4+Pj4+Pj4gb25lLiBUaGlzIGlzIHdoeSBpdCBpcyBtYXBwaW5n OiBpdCBpcyBpbXBvc3NpYmxlIGZvciBhIHByb3h5IE5PVA0KPj4+Pj4+Pj4gcmVzcG9uc2libGUg Zm9yIGEgVVJJIHRvIGNoYW5nZSBpdCB0byBzb21ldGhpbmcgZWxzZSBhbmQgImtub3ciDQoNCj4+ Pj4+Pj4+IGlmIGl0IGENCj4+Pj4+Pj4gZGlmZmVyZW50IHVzZXIgKHJldGFyZ2V0KSBvciBqdXN0 IGEgInN5bm9ueW0iIGZvciB0aGUgc2FtZSB1c2VyLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBXZSBkb24n dCB0aGluayBpdCBpcyAiaW1wb3NzaWJsZSIsIGFuZCB3ZSBzZWUgbm8gcmVhc29uIHdoeSB3ZSAN Cj4+Pj4+Pj4gc2hvdWxkIG1ha2UgdGhhdCByZXN0cmljdGlvbiB3aXRob3V0IGFueSB0ZWNobmlj YWwgDQo+Pj4+Pj4+IGp1c3RpZmljYXRpb24uIFRoZSBwcm94eSBkb2VzIG5vdCBjaGFuZ2UgdGhl IFVSSSBqdXN0IGZvciBmdW4sIA0KPj4+Pj4+PiB3aXRoIGEgdmFsdWUgb3V0IG9mIHRoZSBibHVl IC0gaXQgZG9lcyBpdCBiYXNlZCBvbiBzb21lIGtpbmQgb2YgDQo+Pj4+Pj4+IGtub3dsZWRnZS9j b25maWd1cmF0aW9uLg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gMikgVGFyZ2V0LVVJDQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4gSW4gdGFyZ2V0LVVSSSwgdGhlcmUgaXMgYW4gYXNzdW1wdGlvbiB0aGF0IGEgZG9t YWluIE5PVCANCj4+Pj4+Pj4+IHJlc3BvbnNpYmxlIGZvcg0KPj4+Pj4+PiBhIFVSSSBjYW4gY2hh bmdlIHRoZSBVUkkgdG8gc29tZXRoaW5nIEFORCBrbm93IGF1dGhvcml0YXRpdmVseSANCj4+Pj4+ Pj4gdGhhdCB0aGUgbmV3IHRhcmdldCBpcyBhICJzeW5vbnltIiBmb3IgdGhlIG9yaWdpbmFsIHRh cmdldC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQ29ycmVjdC4NCj4+Pj4+Pj4gQW5kLCBJIGFzc3VtZSB0 aGUgZGlmZmVyZW5jZSBiZXR3ZWVuICJzeW5vbXltIiBhbmQgImFsaWFzIiBpcyANCj4+Pj4+Pj4g dGhhdCBhIHN5bm9ueW0gVVJJIGlzIG5vdCByZWdpc3RlcmVkIGZvciB0aGUgY2FsbGVkIHVzZXIs IHJpZ2h0Pw0KPj4+Pj4+Pg0KPj4+Pj4+PiBCdXQsIG9uZSBxdWVzdGlvbiBmb3IgY2xhcmlmaWNh dGlvbjogaWYgdGhlICJzeW5vbnltIiAgDQo+Pj4+Pj4+IHRyYW5zbGF0aW9uIGlzDQo+Pj4+Pj4+ IGRvbmUgYnkgYW4gZW50aXR5IHdoaWNoIElTIHJlcG9uc2libGUgZm9yIHRoZSBkb21haW4sIGhv dyBpcyBpdCANCj4+Pj4+Pj4gdGFnZ2VkPw0KPj4+Pj4+Pg0KPj4+Pj4+PiAtLS0tLS0tLS0tLS0t DQo+Pj4+Pj4+DQo+Pj4+Pj4+PiBTbyB0aGlzIGlzIHdoYXQgaXQgYm9pbHMgZG93biB0by4NCj4+ Pj4+Pj4gSSB0aGluayB0aGF0IGlzIG1vcmUgb3IgbGVzcyB3aGF0IEkgd2FzIHRyeWluZyB0byBz YXkuDQo+Pj4+Pj4+DQo+Pj4+Pj4+PiBDYW4gYSBkb21haW4gTk9UIHJlc3BvbnNpYmxlIGZvciBh IHRhcmdldCBjaGFuZ2UgdGhlIHRhcmdldCBBTkQNCg0KPj4+Pj4+Pj4gbWFyaw0KPj4+Pj4+PiB0 aGUgbmV3IHRhcmdldCBhdXRob3JpdGF0aXZlbHkgYXMgImJlbG9uZ2luZyIgdG8gdGhlIHNhbWUg dXNlcj8NCj4+Pj4+Pj4+IEluIHRhcmdldC1VUkksIHRoZSBhc3N1bXB0aW9uIGlzIHllcy4NCj4+ Pj4+Pj4+DQo+Pj4+Pj4+PiBJbiA0MjQ0YmlzLCB0aGUgYXNzdW1wdGlvbiBpcyBubyAob25seSB0 aGUgZG9tYWluIHJlc3BvbnNpYmxlIA0KPj4+Pj4+Pj4gZm9yIHRoZQ0KPj4+Pj4+PiBVUkkgY2Fu IGRvIHNvKS4NCj4+Pj4+Pj4gQ29ycmVjdC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gLS0tLS0tLS0tLS0t LQ0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gQXMgcG9pbnRlZCBvdXQgYnkgUGF1bCBLeXppdmF0LCB3ZSBw cm9iYWJseSBuZWVkIHRvIHRoaW5rIG9uIA0KPj4+Pj4+Pj4gaG93IHRoaXMNCj4+Pj4+Pj4gd29y a3Mgd2l0aCBUZWwgVVJJcy4gSSB0aGluayBmb3IgVGVsIFVSSSBpdCB3b3VsZCBiZSB0b3RhbGx5 IA0KPj4+Pj4+PiBkaWZmZXJlbnQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFllcy4gWW91IHJhaXNlZCB0 aGF0IGFsc28gaW4gb3VyIHByaXZhdGUgZGlzY3Vzc2lvbnMsIGJ1dCB3ZSANCj4+Pj4+Pj4gbmV2 ZXIgZGlzY3Vzc2VkIGl0IGluIGRldGFpbHMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFNvLCBiZWZvcmUg d2Ugc3RhcnQgZGlzY3Vzc2luZyB0aGUgcHJvdG9jb2wgZGV0YWlscywgSSB0aGluayB3ZSANCj4+ Pj4+Pj4gbmVlZCB0byBzb2x2ZSB0aGUgaXNzdWVzIGFib3ZlLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBS ZWdhcmRzLA0KPj4+Pj4+Pg0KPj4+Pj4+PiBDaHJpc3Rlcg0KPj4+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PiBzaXBjb3JlIG1haWxp bmcgbGlzdA0KPj4+Pj4+PiBzaXBjb3JlQGlldGYub3JnDQo+Pj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPj4+Pj4+Pg0KPj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gc2lwY29yZSBt YWlsaW5nIGxpc3QNCj4+Pj4+PiBzaXBjb3JlQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4+ IHNpcGNvcmVAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lwY29yZQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlz dA0Kc2lwY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaXBjb3JlDQo= From christer.holmberg@ericsson.com Mon Jun 15 12:33:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A93193A67B3 for ; Mon, 15 Jun 2009 12:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.597 X-Spam-Level: X-Spam-Status: No, score=-4.597 tagged_above=-999 required=5 tests=[AWL=-0.848, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGqi8-cQ4r+A for ; Mon, 15 Jun 2009 12:33:29 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id AF88E3A68DD for ; Mon, 15 Jun 2009 12:33:28 -0700 (PDT) X-AuditID: c1b4fb3e-b7b1dae000006c99-75-4a36a211a8b6 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 45.FF.27801.112A63A4; Mon, 15 Jun 2009 21:33:37 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jun 2009 21:33:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 21:33:36 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYA References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Mary Barnes" , "Francois Audet" , "DOLLY, MARTIN C, ATTLABS" , X-OriginalArrivalTime: 15 Jun 2009 19:33:37.0482 (UTC) FILETIME=[2DE70AA0:01C9EDF0] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 19:33:30 -0000 Hi,=20 >Correct. But, what I am suggesting is that you distinguish it at the UAS >- I'm assuming that the target Request-URI that arrives at the UAS is something that identifies a client that handles 800 numbers. That client could be configured such that it knows to look for the=20 >original 800 number in the mapped URIs or in the reg-alias-URIs or both.=20 800 numbers is just one example.=20 Why should the UAS have to be configured with this information??? I think that is very limiting and unpractical. >Again, if you're making these 800 numbers special and allowing proxies to change them in multiple ways (i.e., non-deterministic), then if you want them tagged special, then you need special logic in the=20 >proxies to do this. The logic is that the AOR is replaced with another AOR, which belongs to the same user.=20 It's not only for 800 numbers - they are just an example where it would be useful. And, the proxy is configured to do this - it doesn't do it because it "thinks" it has to do it :) >That doesn't make sense to me, although you could do it that way in a closed network, in which case you can make sure to always tag them as whatever you think they should be - so we could define an=20 >additional value for the tag. But, this is what I don't think is right in terms of normal SIP request routing and forwarding, which is what the current 4244bis tags have been defined to represent.=20 I really don't understand wht this "normal SIP request routing and forwarding" is all about. Normal SIP request routing and forwarding has issues, which were presented in the ua-loose-route draft - and that is why we are now working on a solution to solve those issues. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 15, 2009 1:23 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi Mary, Proxies will tag entries based on the functionality they perform. Let's leave req-uri-alias for the moment. As I said earlier, one of the issues we have with 4244bis, is that "mapped" seems to be used BOTH for diversion and when an AOR is replaced with another AOR pointing to the same user - e.g. freephone. So, it is not possible to distinguish between diversion and freephone. We think one MUST be able to make that distinguishment, because you may have cases where both diversion and service number translation (e.g. freephone) occurs, and the UAS needs to know which is which. Regards, Christer =20 -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Monday, June 15, 2009 9:13 PM To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt It seems to me that the gist of this discussion has been based on the expectation that independent of how the 800 number is configured, registered or whatever at a proxy, that there is an expectation of deterministic behavior in terms of how it's tagged. So, if 800 numbers are special and they can end up tagged as either reg-uri-alias or as mapped, then perhaps the service has to know that it needs to look for either of those. ISTM that if there is a reason to preserve that it's an 800 number (i.e., and not format as a service specific uri), the service at the UAS knows that it's special, thus it would need to check the request-URIs associated with both reg-uri-alias and mapped hi-entries. I can't see how we can make it work any other way without being prescriptive of how proxy's MUST tag these entries, which is not a good idea IMHO. However, I think these numbers are either special cases at proxies or something that services know about.=20 Mary.=20 -----Original Message----- From: Audet, Francois (SC100:3055) Sent: Monday, June 15, 2009 12:47 PM To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Yes, we need to sort out what to do for that.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 10:17 > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 >=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, June 15, 2009 6:50 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > then reg-uri-alias.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Saturday, June 13, 2009 01:22 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > >1) RFC 4244bis > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > Request-URI and it replacing it with a Contact, it will put > a reg-uri > > flag (if the Request-URI was the AOR used for registration), or reg- > > >uri-alias (if the Request-URI was an alias for the AOR used in > > registration). > >=20 > > And if the Request-URI was a "synonym" for the AOR? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 >=20 From christer.holmberg@ericsson.com Mon Jun 15 12:39:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 440E43A68AA for ; Mon, 15 Jun 2009 12:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jtw8RoSNUQg for ; Mon, 15 Jun 2009 12:39:51 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 65D263A681A for ; Mon, 15 Jun 2009 12:39:50 -0700 (PDT) X-AuditID: c1b4fb3c-b7b0bae00000673a-b7-4a36a38eab93 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 92.D7.26426.E83A63A4; Mon, 15 Jun 2009 21:39:59 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jun 2009 21:39:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 21:39:58 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83D95B@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAAdwn4AABA+Yw References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D95B@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , "Mary Barnes" , "DOLLY, MARTIN C, ATTLABS" , X-OriginalArrivalTime: 15 Jun 2009 19:39:58.0672 (UTC) FILETIME=[111C0500:01C9EDF1] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 19:39:52 -0000 Hi,=20 >Who is in a position to determine that an address is "mapped to same user"? > >Is it the the proxy that retargets to the new address, or is it the proxy who receives that request that determines "yeah, Bob is same as 1800-5551212". It is the entity which translates 1800-1551212 to Bob. So, in this case it is the entity which implements the freephone service. >(I'm talking about the case where the 1800 number is in a different domain as Bob).=20 In that case it will of course only be done if there is some kind of agreement between the domains, so that the entity in the "1800 domain" KNOWS that the 1800 number points to Bob. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 11:23 > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,=20 > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi Mary, >=20 > Proxies will tag entries based on the functionality they perform. >=20 > Let's leave req-uri-alias for the moment. >=20 > As I said earlier, one of the issues we have with 4244bis, is that=20 > "mapped" seems to be used BOTH for diversion and when an AOR is=20 > replaced with another AOR pointing to the same user - e.g. freephone.=20 > So, it is not possible to distinguish between diversion and freephone. >=20 > We think one MUST be able to make that distinguishment, because you=20 > may have cases where both diversion and service number translation=20 > (e.g. > freephone) occurs, and the UAS needs to know which is which. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > =20 >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 9:13 PM > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > It seems to me that the gist of this discussion has been based on the=20 > expectation that independent of how the 800 number is configured,=20 > registered or whatever at a proxy, that there is an expectation of=20 > deterministic behavior in terms of how it's tagged. So, if 800=20 > numbers are special and they can end up tagged as either reg-uri-alias > or as mapped, then perhaps the service has to know that it needs to=20 > look for either of those. ISTM that if there is a reason to preserve=20 > that it's an 800 number (i.e., and not format as a service specific=20 > uri), the service at the UAS knows that it's special, thus it would=20 > need to check the request-URIs associated with both reg-uri-alias and=20 > mapped hi-entries. > I can't see how we can make it work any other way without being=20 > prescriptive of how proxy's MUST tag these entries, which is not a=20 > good idea IMHO. However, I think these numbers are either special=20 > cases at proxies or something that services know about. >=20 > Mary.=20 >=20 > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 12:47 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary=20 > (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Yes, we need to sort out what to do for that.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, June 15, 2009 10:17 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 > >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, June 15, 2009 6:50 PM > > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > > sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > then reg-uri-alias.=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Saturday, June 13, 2009 01:22 > > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, > ATTLABS; Barnes, > > > Mary (RICH2:AR00); sipcore@ietf.org > > > Subject: RE: [sipcore] FW: I-D > > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > >=20 > > >=20 > > > Hi, > > >=20 > > > >1) RFC 4244bis > > > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > > Request-URI and it replacing it with a Contact, it will put > > a reg-uri > > > flag (if the Request-URI was the AOR used for > registration), or reg- > > > >uri-alias (if the Request-URI was an alias for the AOR used in > > > registration). > > >=20 > > > And if the Request-URI was a "synonym" for the AOR? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > >=20 >=20 From mary.barnes@nortel.com Mon Jun 15 12:46:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AECC3A6D0D for ; Mon, 15 Jun 2009 12:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cY6Fyj4igoTP for ; Mon, 15 Jun 2009 12:46:19 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 99B703A68CB for ; Mon, 15 Jun 2009 12:46:19 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5FJibx01339; Mon, 15 Jun 2009 19:44:37 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 14:48:17 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E83DA6C@zrc2hxm0.corp.nortel.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA02BD4814@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] The functional differences between 4244bis andtarget-uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) thread-index: Acnt7WzRHQsf0D0uRdupn7uzFfgKewAAFKSBAAApVaAAADrrXwAAIOSQ References: <14C85D6CCBE92743AF33663BF5D24EBA02BD4814@gaalpa1msgusr7e.ugd.att.com> From: "Mary Barnes" To: "DOLLY, MARTIN C, ATTLABS" , Cc: sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] The functional differences between 4244bis andtarget-uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 19:46:21 -0000 Here's the two sets that we're currently discussing: 4244bis (based entirely on RFC 3261 based request routing and forwarding, which is why it's not entirely clear what your labels imply: * "noop": There is no change whatsoever in the target. The Request-URI is unchanged. This would apply for example when a proxy merely forwards a request to a next hop proxy and loose routing is used. * "predetermined": This is the case where retargeting is predetermined by the content of the request itself, i.e., the Request-URI contained a maddr, the domain of the Request-URI indicates a domain the proxy is not responsible for, or strict routing is used and the request is forwarded to another proxy. * "reg-uri": The Request-URI is replaced with a registered Contact bound to the AOR indicated by the Request-URI. For example, if the REGISTER message had a To header field with the AOR , and a Contact header field of , the Request-URI would be changed to . * "reg-uri-alias": The Request-URI is replaced with a registered Contact bound to an AOR that is an alias of the Request-URI. An AOR is an Alias of another AOR if both entities belong to the same implicit registration set, are linked to the same profile and have the same data configured. For example, if and are configured as aliases for the AOR sip:bob@example.com> (where the registered Contact of is bound to , a Request-URI of or would be changed to . * "mapped": The Request-URI is replaced with another URI that is not a Contact associated with the AOR in the Request-URI or one of its aliases. For example, this would apply when the request is retargeted to a different user. And here's the ones in target-uri, which is based on a combination of tags: o aor, mapped: AOR that was translated (using an abstract location service) to an AOR belonging to a different user or resource o aor, routed: AOR that was translated (using an abstract location service) to a different AOR or contact address belonging to the same user or resource o routed: Request URI was rewritten for routing purposes (including strict routing, no-op/loose-routing, maddr) So, we're debating here the differences between the "aor,mapped" and "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I think that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed". And, I think one could consider the "aor,mapped" as predetermined. But, again 4244bis tags the entries entirely based on what SIP does and if the 800 number translations (or whatever services) are setup differently in different proxies, then you can't determine if the "aor,routed" cases might be "reg-uri-alias" or "reg-uri". Although, I am personally confused as to whether an 800 number would always be "aor, mapped" or "aor, routed" - i.e., I just don't see this being deterministic and I think that if a service can reach a UAS through different SIP retargeting mechanisms, then the UAS needs to be aware.=20 Also, as I'm going through this, I think we need 3 more tags if we want the proxy to do the tagging - i.e., I think we need to add "-aor" to the "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that the proxy will mark in this manner.=20 Mary.=20 -----Original Message----- From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]=20 Sent: Monday, June 15, 2009 2:27 PM To: Barnes, Mary (RICH2:AR00); pkyzivat@cisco.com Cc: sipcore@ietf.org; shida@agnada.com Subject: Re: [sipcore] The functional differences between 4244bis andtarget-uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) These make sense to me. I do not know about your tags? ----- Original Message ----- From: Mary Barnes To: DOLLY, MARTIN C, ATTLABS; pkyzivat@cisco.com Cc: sipcore@ietf.org ; shida@agnada.com Sent: Mon Jun 15 15:21:16 2009 Subject: RE: [sipcore] The functional differences between 4244bis andtarget-uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) And, how do you map those to the tags in 4244bis and target-uri? =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, MARTIN C, ATTLABS Sent: Monday, June 15, 2009 2:16 PM To: pkyzivat@cisco.com Cc: sipcore@ietf.org; shida@agnada.com Subject: Re: [sipcore] The functional differences between 4244bis andtarget-uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) 1. Translation 2. Retarget 3. Redirect ----- Original Message ----- From: Paul Kyzivat To: DOLLY, MARTIN C, ATTLABS Cc: shida@agnada.com ; sipcore@ietf.org Sent: Mon Jun 15 15:13:34 2009 Subject: Re: [sipcore] The functional differences between 4244bis andtarget- uri (was FW: I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) DOLLY, MARTIN C, ATTLABS wrote: > Simple requirement: capture ALL retarget information in HI. Period We have had the ability to capture all retargeting with H-I since it was first published. The new requirement is to distinguish different sorts of retargeting. If so its very important that everybody understand the meaning of each type and how to determine that type each time a request is retargeted. I was getting the impression (may be wrong about it) that a third type of retargeting was now being identified. We need to agree on what it is that we are capturing. Thanks, Paul > ----- Original Message ----- > From: sipcore-bounces@ietf.org > To: Paul Kyzivat > Cc: DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org > Sent: Mon Jun 15 08:20:15 2009 > Subject: Re: [sipcore] The functional differences between 4244bis > andtarget- uri (was FW:=20 > I-DAction:draft-barnes-sipcore-rfc4244bis-01.txt) >=20 >=20 > I don't think it's a special case for free-dial alone. >=20 > If service URN is used to deliver a service request such as=20 > emergency call or directory assistance request to a local call-center, > and takes a similar approach to what's defined in phoneBCP to support=20 > devices not compliant to service URN, the translation to service URN=20 > from the dial string will be done by the proxy. But the translation=20 > from 911 to "sos" will only be seen in request URI and not in the To=20 > header. >=20 > So To header even without diversion is not dependable. >=20 > Regards > Shida >=20 > On 15-Jun-09, at 6:28 AM, Paul Kyzivat wrote: >=20 >> >> Hans Erik van Elburg wrote: >>> But that does not work when a diversion to that service number takes >>> place. It only works for direct calls to such service number. >> Perhaps. That depends on *if* that is a reasonable scenario, and if=20 >> so precisely what you want to happen in that case. >> >> For instance, does it really make sense for you to call me, and for=20 >> me to then divert you to an 800 number? If so, is that supposed to=20 >> behave as if you had called the 800 number? >> >> I realize there are many possible desired outcomes, so many=20 >> strategies may be used from case to case. >> >> Thanks, >> Paul >> >>> /Hans Erik >>> Paul Kyzivat wrote: >>>> >>>> Hans Erik van Elburg wrote: >>>>> Hi Paul, >>>>> >>>>> For what would you want to use the To-uri? >>>> To decide who/what the caller desired to reach, and hence what=20 >>>> treatment to give the call. This seems to be the key thing for the=20 >>>> call centers that use freephone numbers. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> /Hans Erik >>>>> >>>>> Paul Kyzivat wrote: >>>>>> This thing about the freephone services is an ugly one. >>>>>> I've thought for a long time that the mechanism is an entirely=20 >>>>>> brain dead way to designate who should pay for a call. >>>>>> >>>>>> But it is what it is, so I guess we have to cope with it. >>>>>> >>>>>> I wonder if perhaps this is really one of the few circumstances=20 >>>>>> where the recipient of a call ought to make call handling=20 >>>>>> decisions based on the To-uri. The reason I say this is because=20 >>>>>> the "contract" with these numbers is that the caller expects the=20 >>>>>> call will be free based on the form of the number being called. >>>>>> And if the caller is wrong, it is the caller who gets charged. >>>>>> >>>>>> So, while I generally recommend that the To-uri be used for=20 >>>>>> *nothing*, it might be right here. If so, then the whole target-=20 >>>>>> uri/h-i discussion may be irrelevant to it. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> Christer Holmberg wrote: >>>>>>> Hi, >>>>>>>> I'm going to spare details, but the main different is as=20 >>>>>>>> follows. >>>>>>>> >>>>>>>> 1) RFC 4244bis >>>>>>>> >>>>>>>> In RFC 4244bis, if the domain is responsible for the URI in the >>>>>>> Request-URI and it replacing it with a Contact, it will put a=20 >>>>>>> reg-uri flag (if the Request-URI was the AOR used for=20 >>>>>>> registration), or >>>>>>> reg- >>>>>>>> uri-alias (if the Request-URI was an alias for the AOR used in >>>>>>> registration). >>>>>>>> If the domain is responsible for the URI and it "maps" it to a >>>>>>> different user, then it puts a "mapped" flag. >>>>>>>> If the domain is NOT responsible for the AOR but it changes the >>>>>>> Request-URI nevertheless, then it is also marked as "mapped". >>>>>>>> Note: With loose routing, this is not supposed to =20 >>>>>>>> happen (at least in theory). >>>>>>>> >>>>>>>> This next statement is where there is a big difference: >>>>>>>> >>>>>>>> If the domain is NOT responsible for the URI, the mapping=20 >>>>>>>> cannot know >>>>>>> if the new URI is belongs to the same User than the original=20 >>>>>>> one. This is why it is mapping: it is impossible for a proxy NOT >>>>>>>> responsible for a URI to change it to something else and "know" >>>>>>>> if it a >>>>>>> different user (retarget) or just a "synonym" for the same user. >>>>>>> >>>>>>> We don't think it is "impossible", and we see no reason why we=20 >>>>>>> should make that restriction without any technical=20 >>>>>>> justification. The proxy does not change the URI just for fun,=20 >>>>>>> with a value out of the blue - it does it based on some kind of=20 >>>>>>> knowledge/configuration. >>>>>>> >>>>>>>> 2) Target-UI >>>>>>>> >>>>>>>> In target-URI, there is an assumption that a domain NOT=20 >>>>>>>> responsible for >>>>>>> a URI can change the URI to something AND know authoritatively=20 >>>>>>> that the new target is a "synonym" for the original target. >>>>>>> >>>>>>> Correct. >>>>>>> And, I assume the difference between "synomym" and "alias" is=20 >>>>>>> that a synonym URI is not registered for the called user, right? >>>>>>> >>>>>>> But, one question for clarification: if the "synonym" =20 >>>>>>> translation is >>>>>>> done by an entity which IS reponsible for the domain, how is it=20 >>>>>>> tagged? >>>>>>> >>>>>>> ------------- >>>>>>> >>>>>>>> So this is what it boils down to. >>>>>>> I think that is more or less what I was trying to say. >>>>>>> >>>>>>>> Can a domain NOT responsible for a target change the target AND >>>>>>>> mark >>>>>>> the new target authoritatively as "belonging" to the same user? >>>>>>>> In target-URI, the assumption is yes. >>>>>>>> >>>>>>>> In 4244bis, the assumption is no (only the domain responsible=20 >>>>>>>> for the >>>>>>> URI can do so). >>>>>>> Correct. >>>>>>> >>>>>>> ------------- >>>>>>> >>>>>>>> As pointed out by Paul Kyzivat, we probably need to think on=20 >>>>>>>> how this >>>>>>> works with Tel URIs. I think for Tel URI it would be totally=20 >>>>>>> different. >>>>>>> >>>>>>> Yes. You raised that also in our private discussions, but we=20 >>>>>>> never discussed it in details. >>>>>>> >>>>>>> So, before we start discussing the protocol details, I think we=20 >>>>>>> need to solve the issues above. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> _______________________________________________ >>>>>>> sipcore mailing list >>>>>>> sipcore@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>>> >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > 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 mary.barnes@nortel.com Mon Jun 15 12:50:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91D9B3A6C86 for ; Mon, 15 Jun 2009 12:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.18 X-Spam-Level: X-Spam-Status: No, score=-5.18 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOdfFl79LS78 for ; Mon, 15 Jun 2009 12:50:28 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 22BDB28C138 for ; Mon, 15 Jun 2009 12:50:27 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5FJnBx02136; Mon, 15 Jun 2009 19:49:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 14:52:58 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E83DA92@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt thread-index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYAAADaOvA= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Christer Holmberg" , "Francois Audet" , "DOLLY, MARTIN C, ATTLABS" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 19:50:29 -0000 Christer,=20 On your last point, the objective here was to make use of History-Info WITHOUT changing any core SIP functionality - it's a whole different ballgame if we want to do the latter IMHO. However, here's the snippet from the end of the response I just sent to Martin (summarizing the current set of tags), which you may not read: " So, we're debating here the differences between the "aor,mapped" and "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I think that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed". And, I think one could consider the "aor,mapped" as predetermined. But, again 4244bis tags the entries entirely based on what SIP does and if the 800 number translations (or whatever services) are setup differently in different proxies, then you can't determine if the "aor,routed" cases might be "reg-uri-alias" or "reg-uri". Although, I am personally confused as to whether an 800 number would always be "aor, mapped" or "aor, routed" - i.e., I just don't see this being deterministic and I think that if a service can reach a UAS through different SIP retargeting mechanisms, then the UAS needs to be aware.=20 Also, as I'm going through this, I think we need 3 more tags if we want the proxy to do the tagging - i.e., I think we need to add "-aor" to the "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that the proxy will mark in this manner. " Mary.=20 P.S. Also, I do not think it's a burden to put logic in the UAS - that was the original intent for SIP - services in the endpoints - SIP is just the signalling to carry the relevant information. But, I can see that since the sort of service you mention that does not have a standard SIP URI (i.e., user@domain) introduces something that isn't accomodated in the basic SIP model, so we may need to add additional logic to the proxies (I don't like it though).=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Monday, June 15, 2009 2:34 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi,=20 >Correct. But, what I am suggesting is that you distinguish it at the UAS >- I'm assuming that the target Request-URI that arrives at the UAS is something that identifies a client that handles 800 numbers. That client could be configured such that it knows to look for the=20 >original 800 number in the mapped URIs or in the reg-alias-URIs or both.=20 800 numbers is just one example.=20 Why should the UAS have to be configured with this information??? I think that is very limiting and unpractical. >Again, if you're making these 800 numbers special and allowing proxies to change them in multiple ways (i.e., non-deterministic), then if you want them tagged special, then you need special logic in the=20 >proxies to do this. The logic is that the AOR is replaced with another AOR, which belongs to the same user.=20 It's not only for 800 numbers - they are just an example where it would be useful. And, the proxy is configured to do this - it doesn't do it because it "thinks" it has to do it :) >That doesn't make sense to me, although you could do it that way in a closed network, in which case you can make sure to always tag them as whatever you think they should be - so we could define an=20 >additional value for the tag. But, this is what I don't think is right in terms of normal SIP request routing and forwarding, which is what the current 4244bis tags have been defined to represent.=20 I really don't understand wht this "normal SIP request routing and forwarding" is all about. Normal SIP request routing and forwarding has issues, which were presented in the ua-loose-route draft - and that is why we are now working on a solution to solve those issues. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 15, 2009 1:23 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi Mary, Proxies will tag entries based on the functionality they perform. Let's leave req-uri-alias for the moment. As I said earlier, one of the issues we have with 4244bis, is that "mapped" seems to be used BOTH for diversion and when an AOR is replaced with another AOR pointing to the same user - e.g. freephone. So, it is not possible to distinguish between diversion and freephone. We think one MUST be able to make that distinguishment, because you may have cases where both diversion and service number translation (e.g. freephone) occurs, and the UAS needs to know which is which. Regards, Christer =20 -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Monday, June 15, 2009 9:13 PM To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt It seems to me that the gist of this discussion has been based on the expectation that independent of how the 800 number is configured, registered or whatever at a proxy, that there is an expectation of deterministic behavior in terms of how it's tagged. So, if 800 numbers are special and they can end up tagged as either reg-uri-alias or as mapped, then perhaps the service has to know that it needs to look for either of those. ISTM that if there is a reason to preserve that it's an 800 number (i.e., and not format as a service specific uri), the service at the UAS knows that it's special, thus it would need to check the request-URIs associated with both reg-uri-alias and mapped hi-entries. I can't see how we can make it work any other way without being prescriptive of how proxy's MUST tag these entries, which is not a good idea IMHO. However, I think these numbers are either special cases at proxies or something that services know about.=20 Mary.=20 -----Original Message----- From: Audet, Francois (SC100:3055) Sent: Monday, June 15, 2009 12:47 PM To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Yes, we need to sort out what to do for that.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 10:17 > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 >=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, June 15, 2009 6:50 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > then reg-uri-alias.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Saturday, June 13, 2009 01:22 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > >1) RFC 4244bis > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > Request-URI and it replacing it with a Contact, it will put > a reg-uri > > flag (if the Request-URI was the AOR used for registration), or reg- > > >uri-alias (if the Request-URI was an alias for the AOR used in > > registration). > >=20 > > And if the Request-URI was a "synonym" for the AOR? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 >=20 From mary.barnes@nortel.com Mon Jun 15 12:58:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37D453A6A07 for ; Mon, 15 Jun 2009 12:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.157 X-Spam-Level: X-Spam-Status: No, score=-5.157 tagged_above=-999 required=5 tests=[AWL=-1.058, BAYES_00=-2.599, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM34jDkGHSZH for ; Mon, 15 Jun 2009 12:58:40 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id AD9733A6825 for ; Mon, 15 Jun 2009 12:58:40 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5FJvDx03928; Mon, 15 Jun 2009 19:57:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 15:01:06 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt thread-index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYAAADaOvAAAEZYIA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Mary Barnes" , "Christer Holmberg" , "Francois Audet" , "DOLLY, MARTIN C, ATTLABS" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 19:58:42 -0000 But, still with this approach, I do not think you can get away with not looking for multiple tags with the way you envision doing your services. I think there are others that will implement services on the UAS that will not need the differentiation that you do - i.e, they care about the difference between "reg-uri" and "reg-uri-alias". Mary.=20 -----Original Message----- From: Barnes, Mary (RICH2:AR00)=20 Sent: Monday, June 15, 2009 2:53 PM To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Christer,=20 On your last point, the objective here was to make use of History-Info WITHOUT changing any core SIP functionality - it's a whole different ballgame if we want to do the latter IMHO. However, here's the snippet from the end of the response I just sent to Martin (summarizing the current set of tags), which you may not read: " So, we're debating here the differences between the "aor,mapped" and "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I think that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed". And, I think one could consider the "aor,mapped" as predetermined. But, again 4244bis tags the entries entirely based on what SIP does and if the 800 number translations (or whatever services) are setup differently in different proxies, then you can't determine if the "aor,routed" cases might be "reg-uri-alias" or "reg-uri". Although, I am personally confused as to whether an 800 number would always be "aor, mapped" or "aor, routed" - i.e., I just don't see this being deterministic and I think that if a service can reach a UAS through different SIP retargeting mechanisms, then the UAS needs to be aware.=20 Also, as I'm going through this, I think we need 3 more tags if we want the proxy to do the tagging - i.e., I think we need to add "-aor" to the "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that the proxy will mark in this manner. " Mary.=20 P.S. Also, I do not think it's a burden to put logic in the UAS - that was the original intent for SIP - services in the endpoints - SIP is just the signalling to carry the relevant information. But, I can see that since the sort of service you mention that does not have a standard SIP URI (i.e., user@domain) introduces something that isn't accomodated in the basic SIP model, so we may need to add additional logic to the proxies (I don't like it though).=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 15, 2009 2:34 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi,=20 >Correct. But, what I am suggesting is that you distinguish it at the UAS >- I'm assuming that the target Request-URI that arrives at the UAS is something that identifies a client that handles 800 numbers. That client could be configured such that it knows to look for the=20 >original 800 number in the mapped URIs or in the reg-alias-URIs or both.=20 800 numbers is just one example.=20 Why should the UAS have to be configured with this information??? I think that is very limiting and unpractical. >Again, if you're making these 800 numbers special and allowing proxies to change them in multiple ways (i.e., non-deterministic), then if you want them tagged special, then you need special logic in the=20 >proxies to do this. The logic is that the AOR is replaced with another AOR, which belongs to the same user.=20 It's not only for 800 numbers - they are just an example where it would be useful. And, the proxy is configured to do this - it doesn't do it because it "thinks" it has to do it :) >That doesn't make sense to me, although you could do it that way in a closed network, in which case you can make sure to always tag them as whatever you think they should be - so we could define an=20 >additional value for the tag. But, this is what I don't think is right in terms of normal SIP request routing and forwarding, which is what the current 4244bis tags have been defined to represent.=20 I really don't understand wht this "normal SIP request routing and forwarding" is all about. Normal SIP request routing and forwarding has issues, which were presented in the ua-loose-route draft - and that is why we are now working on a solution to solve those issues. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 15, 2009 1:23 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi Mary, Proxies will tag entries based on the functionality they perform. Let's leave req-uri-alias for the moment. As I said earlier, one of the issues we have with 4244bis, is that "mapped" seems to be used BOTH for diversion and when an AOR is replaced with another AOR pointing to the same user - e.g. freephone. So, it is not possible to distinguish between diversion and freephone. We think one MUST be able to make that distinguishment, because you may have cases where both diversion and service number translation (e.g. freephone) occurs, and the UAS needs to know which is which. Regards, Christer =20 -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Monday, June 15, 2009 9:13 PM To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt It seems to me that the gist of this discussion has been based on the expectation that independent of how the 800 number is configured, registered or whatever at a proxy, that there is an expectation of deterministic behavior in terms of how it's tagged. So, if 800 numbers are special and they can end up tagged as either reg-uri-alias or as mapped, then perhaps the service has to know that it needs to look for either of those. ISTM that if there is a reason to preserve that it's an 800 number (i.e., and not format as a service specific uri), the service at the UAS knows that it's special, thus it would need to check the request-URIs associated with both reg-uri-alias and mapped hi-entries. I can't see how we can make it work any other way without being prescriptive of how proxy's MUST tag these entries, which is not a good idea IMHO. However, I think these numbers are either special cases at proxies or something that services know about.=20 Mary.=20 -----Original Message----- From: Audet, Francois (SC100:3055) Sent: Monday, June 15, 2009 12:47 PM To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Yes, we need to sort out what to do for that.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 10:17 > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 >=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, June 15, 2009 6:50 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > then reg-uri-alias.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Saturday, June 13, 2009 01:22 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > >1) RFC 4244bis > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > Request-URI and it replacing it with a Contact, it will put > a reg-uri > > flag (if the Request-URI was the AOR used for registration), or reg- > > >uri-alias (if the Request-URI was an alias for the AOR used in > > registration). > >=20 > > And if the Request-URI was a "synonym" for the AOR? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 >=20 From christer.holmberg@ericsson.com Mon Jun 15 13:06:00 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A03D93A6CEE for ; Mon, 15 Jun 2009 13:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.574 X-Spam-Level: X-Spam-Status: No, score=-4.574 tagged_above=-999 required=5 tests=[AWL=-0.825, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voZVUexz8+yP for ; Mon, 15 Jun 2009 13:05:59 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A43263A6D1D for ; Mon, 15 Jun 2009 13:05:58 -0700 (PDT) X-AuditID: c1b4fb3c-b7b0bae00000673a-e9-4a36a9af64d6 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 9F.78.26426.FA9A63A4; Mon, 15 Jun 2009 22:06:07 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jun 2009 22:06:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 22:06:07 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83DA92@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYAAADaOvAAABnmcA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DA92@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Mary Barnes" , "Francois Audet" , "DOLLY, MARTIN C, ATTLABS" , X-OriginalArrivalTime: 15 Jun 2009 20:06:07.0537 (UTC) FILETIME=[B839D210:01C9EDF4] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 20:06:00 -0000 =20 Hi, >On your last point, the objective here was to make use of History-Info WITHOUT changing any core SIP functionality - it's a whole different ballgame if we want to do the latter IMHO. However, here's the=20 >snippet from the end of the response I just sent to Martin (summarizing the current set of tags), which you may not read: I don't see this as a change to any core SIP functionality. >" So, we're debating here the differences between the "aor,mapped" and "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I think that "reg-uri-alias" and "reg-uri" are equivalent to "aor,=20 >routed". >And, I think one could consider the "aor,mapped" as predetermined. But, again 4244bis tags the entries entirely based on what SIP does and if the 800 number translations (or whatever services) are setup=20 >differently in different proxies, then you can't determine if the "aor,routed" cases might be "reg-uri-alias" or "reg-uri". Although, I am personally confused as to whether an 800 number would always be=20 >"aor, mapped" or "aor, routed" - i.e., I just don't see this being deterministic and I think that if a service can reach a UAS through different SIP retargeting mechanisms, then the UAS needs to be=20 >aware.=20 I think we are still debating the requirements. I think Hans Erik's proposal (copied below) was very clear. If we can agree on that, then we can start discussing the protocol. I think it is useless to do a beauty contest on tags before we are clear on the requirements... ------- We have now: - mapping translation (aor1->aor2, where aor2 is not configured as synonym for aor1) - routing translation (noop, predetermined, aor->contact) maybe we need a third, something like: - synonym translation (aor1->aor2, where aor2 is a onfigured synonym for aor1) Mapping and synonym, would only be performed by proxies that are configured to do so. This makes this entirely deterministic. ------ >Also, as I'm going through this, I think we need 3 more tags if we want the proxy to do the tagging - i.e., I think we need to add "-aor" to the "predetermined", "reg-uri" and "reg-uri-alias" IF we agree=20 >that the proxy will mark in this manner. " >Mary.=20 >P.S. Also, I do not think it's a burden to put logic in the UAS - that was the original intent for SIP - services in the endpoints - SIP is just the signalling to carry the relevant information. This is not about putting the serivce in the UAS (the translation may still be done in the network). This is about having to configure the UAS in order to somehow figure out what has happended - when we instead can define a protocol mechanism to carry that information (as you said yourself :) Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 15, 2009 2:34 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi,=20 >Correct. But, what I am suggesting is that you distinguish it at the UAS >- I'm assuming that the target Request-URI that arrives at the UAS is something that identifies a client that handles 800 numbers. That client could be configured such that it knows to look for the=20 >original 800 number in the mapped URIs or in the reg-alias-URIs or both.=20 800 numbers is just one example.=20 Why should the UAS have to be configured with this information??? I think that is very limiting and unpractical. >Again, if you're making these 800 numbers special and allowing proxies to change them in multiple ways (i.e., non-deterministic), then if you want them tagged special, then you need special logic in the=20 >proxies to do this. The logic is that the AOR is replaced with another AOR, which belongs to the same user.=20 It's not only for 800 numbers - they are just an example where it would be useful. And, the proxy is configured to do this - it doesn't do it because it "thinks" it has to do it :) >That doesn't make sense to me, although you could do it that way in a closed network, in which case you can make sure to always tag them as whatever you think they should be - so we could define an=20 >additional value for the tag. But, this is what I don't think is right in terms of normal SIP request routing and forwarding, which is what the current 4244bis tags have been defined to represent.=20 I really don't understand wht this "normal SIP request routing and forwarding" is all about. Normal SIP request routing and forwarding has issues, which were presented in the ua-loose-route draft - and that is why we are now working on a solution to solve those issues. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 15, 2009 1:23 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi Mary, Proxies will tag entries based on the functionality they perform. Let's leave req-uri-alias for the moment. As I said earlier, one of the issues we have with 4244bis, is that "mapped" seems to be used BOTH for diversion and when an AOR is replaced with another AOR pointing to the same user - e.g. freephone. So, it is not possible to distinguish between diversion and freephone. We think one MUST be able to make that distinguishment, because you may have cases where both diversion and service number translation (e.g. freephone) occurs, and the UAS needs to know which is which. Regards, Christer =20 -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Monday, June 15, 2009 9:13 PM To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt It seems to me that the gist of this discussion has been based on the expectation that independent of how the 800 number is configured, registered or whatever at a proxy, that there is an expectation of deterministic behavior in terms of how it's tagged. So, if 800 numbers are special and they can end up tagged as either reg-uri-alias or as mapped, then perhaps the service has to know that it needs to look for either of those. ISTM that if there is a reason to preserve that it's an 800 number (i.e., and not format as a service specific uri), the service at the UAS knows that it's special, thus it would need to check the request-URIs associated with both reg-uri-alias and mapped hi-entries. I can't see how we can make it work any other way without being prescriptive of how proxy's MUST tag these entries, which is not a good idea IMHO. However, I think these numbers are either special cases at proxies or something that services know about.=20 Mary.=20 -----Original Message----- From: Audet, Francois (SC100:3055) Sent: Monday, June 15, 2009 12:47 PM To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Yes, we need to sort out what to do for that.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 10:17 > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 >=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, June 15, 2009 6:50 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > then reg-uri-alias.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Saturday, June 13, 2009 01:22 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > >1) RFC 4244bis > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > Request-URI and it replacing it with a Contact, it will put > a reg-uri > > flag (if the Request-URI was the AOR used for registration), or reg- > > >uri-alias (if the Request-URI was an alias for the AOR used in > > registration). > >=20 > > And if the Request-URI was a "synonym" for the AOR? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 >=20 From ietf.hanserik@gmail.com Mon Jun 15 13:08:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BED93A6C70 for ; Mon, 15 Jun 2009 13:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[AWL=-0.878, BAYES_00=-2.599, MANGLED_REGALS=2.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kqjvj+TGGf7o for ; Mon, 15 Jun 2009 13:08:49 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 50C4F3A69EB for ; Mon, 15 Jun 2009 13:08:48 -0700 (PDT) Received: by ewy6 with SMTP id 6so5338716ewy.37 for ; Mon, 15 Jun 2009 13:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=jRqGp84aP+qXOh9TbXhf22aYUykpmiwHnp3KgryRwQY=; b=vC7LlQ5LhtQQws+9sjHHpRSf37QU4yCYyZibWiE3DZLIVLIIcr6kV/hqY8aEXMJgcM MPJQbbURLYKo4e9qMcqPdWDG+AwIhUXlR8kP8bMH9ExP4VAUZBuRGwCqQxB6C/vlYPfl 1nJaAgdHQnKTtyDHbqxOIAi4MKdSLx9r4Pb70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=o8F6fIpd7QVHHVxkKsrha/PYX9CdOMbBwLKm07WZqt1WfBSmLye1BA7A6ntMNppVfQ cDMaI3ZXux2mdr4xxhEsW+6bDtn8HEabMvJeTakG8P6KVexGWnFHA9KyVZMmBzzKDmMv /HdpsbB+GQQRwx0Nj82Igv3qXmRiFDbAzIzdM= Received: by 10.210.118.13 with SMTP id q13mr46288ebc.40.1245096536162; Mon, 15 Jun 2009 13:08:56 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 24sm214460eyx.33.2009.06.15.13.08.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Jun 2009 13:08:55 -0700 (PDT) Message-ID: <4A36AA56.2000600@gmail.com> Date: Mon, 15 Jun 2009 22:08:54 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mary Barnes References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 20:08:50 -0000 I think this is a new requirement. 4244bis has introduced this distinction, so maybe you have a some requirement in mind. Maybe you can explain why it is needed? /Hans Erik Mary Barnes wrote: > But, still with this approach, I do not think you can get away with not > looking for multiple tags with the way you envision doing your services. > I think there are others that will implement services on the UAS that > will not need the differentiation that you do - i.e, they care about the > difference between "reg-uri" and "reg-uri-alias". > > Mary. > > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Monday, June 15, 2009 2:53 PM > To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN C, > ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Christer, > > On your last point, the objective here was to make use of History-Info > WITHOUT changing any core SIP functionality - it's a whole different > ballgame if we want to do the latter IMHO. However, here's the snippet > from the end of the response I just sent to Martin (summarizing the > current set of tags), which you may not read: > > " So, we're debating here the differences between the "aor,mapped" and > "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I think > that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed". > And, I think one could consider the "aor,mapped" as predetermined. But, > again 4244bis tags the entries entirely based on what SIP does and if > the 800 number translations (or whatever services) are setup differently > in different proxies, then you can't determine if the "aor,routed" cases > might be "reg-uri-alias" or "reg-uri". Although, I am personally > confused as to whether an 800 number would always be "aor, mapped" or > "aor, routed" - i.e., I just don't see this being deterministic and I > think that if a service can reach a UAS through different SIP > retargeting mechanisms, then the UAS needs to be aware. > > Also, as I'm going through this, I think we need 3 more tags if we want > the proxy to do the tagging - i.e., I think we need to add "-aor" to the > "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that the > proxy will mark in this manner. " > > > Mary. > P.S. Also, I do not think it's a burden to put logic in the UAS - that > was the original intent for SIP - services in the endpoints - SIP is > just the signalling to carry the relevant information. But, I can see > that since the sort of service you mention that does not have a standard > SIP URI (i.e., user@domain) introduces something that isn't accomodated > in the basic SIP model, so we may need to add additional logic to the > proxies (I don't like it though). > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 2:34 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > Hi, > > >> Correct. But, what I am suggesting is that you distinguish it at the >> > UAS > >> - I'm assuming that the target Request-URI that arrives at the UAS is >> > something that identifies a client that handles 800 numbers. That > client could be configured such that it knows to look for the > >> original 800 number in the mapped URIs or in the reg-alias-URIs or >> > both. > > 800 numbers is just one example. > > Why should the UAS have to be configured with this information??? I > think that is very limiting and unpractical. > > >> Again, if you're making these 800 numbers special and allowing proxies >> > to change them in multiple ways (i.e., non-deterministic), then if you > want them tagged special, then you need special logic in the > >> proxies to do this. >> > > The logic is that the AOR is replaced with another AOR, which belongs to > the same user. > > It's not only for 800 numbers - they are just an example where it would > be useful. > > And, the proxy is configured to do this - it doesn't do it because it > "thinks" it has to do it :) > > >> That doesn't make sense to me, although you could do it that way in a >> > closed network, in which case you can make sure to always tag them as > whatever you think they should be - so we could define an > >> additional value for the tag. But, this is what I don't think is right >> > in terms of normal SIP request routing and forwarding, which is what the > current 4244bis tags have been defined to represent. > > I really don't understand wht this "normal SIP request routing and > forwarding" is all about. Normal SIP request routing and forwarding has > issues, which were presented in the ua-loose-route draft - and that is > why we are now working on a solution to solve those issues. > > Regards, > > Christer > > > > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 1:23 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > Hi Mary, > > Proxies will tag entries based on the functionality they perform. > > Let's leave req-uri-alias for the moment. > > As I said earlier, one of the issues we have with 4244bis, is that > "mapped" seems to be used BOTH for diversion and when an AOR is replaced > with another AOR pointing to the same user - e.g. freephone. So, it is > not possible to distinguish between diversion and freephone. > > We think one MUST be able to make that distinguishment, because you may > have cases where both diversion and service number translation (e.g. > freephone) occurs, and the UAS needs to know which is which. > > Regards, > > Christer > > > > > > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 9:13 PM > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > It seems to me that the gist of this discussion has been based on the > expectation that independent of how the 800 number is configured, > registered or whatever at a proxy, that there is an expectation of > deterministic behavior in terms of how it's tagged. So, if 800 numbers > are special and they can end up tagged as either reg-uri-alias or as > mapped, then perhaps the service has to know that it needs to look for > either of those. ISTM that if there is a reason to preserve that it's an > 800 number (i.e., and not format as a service specific uri), the service > at the UAS knows that it's special, thus it would need to check the > request-URIs associated with both reg-uri-alias and mapped hi-entries. > I can't see how we can make it work any other way without being > prescriptive of how proxy's MUST tag these entries, which is not a good > idea IMHO. However, I think these numbers are either special cases at > proxies or something that services know about. > > Mary. > > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 12:47 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary > (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Yes, we need to sort out what to do for that. > > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Monday, June 15, 2009 10:17 >> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes, >> Mary (RICH2:AR00); sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> But if it is NOT an alias (=implicitly/explicitly registered)? >> >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> Sent: Monday, June 15, 2009 6:50 PM >> To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes; >> sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> then reg-uri-alias. >> >> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Saturday, June 13, 2009 01:22 >>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes, >>> Mary (RICH2:AR00); sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> >>> Hi, >>> >>> >>>> 1) RFC 4244bis >>>> >>>> In RFC 4244bis, if the domain is responsible for the URI in the >>>> >>> Request-URI and it replacing it with a Contact, it will put >>> >> a reg-uri >> >>> flag (if the Request-URI was the AOR used for registration), or reg- >>> >>>> uri-alias (if the Request-URI was an alias for the AOR used in >>>> >>> registration). >>> >>> And if the Request-URI was a "synonym" for the AOR? >>> >>> Regards, >>> >>> Christer >>> >>> >>> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Mon Jun 15 13:13:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF0083A6923 for ; Mon, 15 Jun 2009 13:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[AWL=-0.783, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVa0a4T31Qdy for ; Mon, 15 Jun 2009 13:13:51 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 0B3433A687A for ; Mon, 15 Jun 2009 13:13:50 -0700 (PDT) X-AuditID: c1b4fb3e-b7b1dae000006c99-36-4a36ab878501 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 34.41.27801.78BA63A4; Mon, 15 Jun 2009 22:13:59 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jun 2009 22:13:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 22:13:48 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYAAADaOvAAAEZYIAAAZd2g References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Mary Barnes" , "Francois Audet" , "DOLLY, MARTIN C, ATTLABS" , X-OriginalArrivalTime: 15 Jun 2009 20:13:59.0689 (UTC) FILETIME=[D1A67F90:01C9EDF5] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 20:13:53 -0000 Hi,=20 >But, still with this approach, I do not think you can get away with not looking for multiple tags with the way you envision doing your services. Maybe not - that depends on the service. But, then it will at least be possible to figure out what has happended. >I think there are others that will implement services on the UAS that will not need the differentiation that you do - i.e, they care about the difference between "reg-uri" and "reg-uri-alias". My differentiation is based on my understanding of the requirements that we have. If you think we need to differentiate between req-uri and req-uri-alias, then we should agree on such requirement. Let's not mix it with the freephone requirement. Regards, Christer -----Original Message----- From: Barnes, Mary (RICH2:AR00) Sent: Monday, June 15, 2009 2:53 PM To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Christer,=20 On your last point, the objective here was to make use of History-Info WITHOUT changing any core SIP functionality - it's a whole different ballgame if we want to do the latter IMHO. However, here's the snippet from the end of the response I just sent to Martin (summarizing the current set of tags), which you may not read: " So, we're debating here the differences between the "aor,mapped" and "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I think that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed". And, I think one could consider the "aor,mapped" as predetermined. But, again 4244bis tags the entries entirely based on what SIP does and if the 800 number translations (or whatever services) are setup differently in different proxies, then you can't determine if the "aor,routed" cases might be "reg-uri-alias" or "reg-uri". Although, I am personally confused as to whether an 800 number would always be "aor, mapped" or "aor, routed" - i.e., I just don't see this being deterministic and I think that if a service can reach a UAS through different SIP retargeting mechanisms, then the UAS needs to be aware.=20 Also, as I'm going through this, I think we need 3 more tags if we want the proxy to do the tagging - i.e., I think we need to add "-aor" to the "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that the proxy will mark in this manner. " Mary.=20 P.S. Also, I do not think it's a burden to put logic in the UAS - that was the original intent for SIP - services in the endpoints - SIP is just the signalling to carry the relevant information. But, I can see that since the sort of service you mention that does not have a standard SIP URI (i.e., user@domain) introduces something that isn't accomodated in the basic SIP model, so we may need to add additional logic to the proxies (I don't like it though).=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 15, 2009 2:34 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi,=20 >Correct. But, what I am suggesting is that you distinguish it at the UAS >- I'm assuming that the target Request-URI that arrives at the UAS is something that identifies a client that handles 800 numbers. That client could be configured such that it knows to look for the=20 >original 800 number in the mapped URIs or in the reg-alias-URIs or both.=20 800 numbers is just one example.=20 Why should the UAS have to be configured with this information??? I think that is very limiting and unpractical. >Again, if you're making these 800 numbers special and allowing proxies to change them in multiple ways (i.e., non-deterministic), then if you want them tagged special, then you need special logic in the=20 >proxies to do this. The logic is that the AOR is replaced with another AOR, which belongs to the same user.=20 It's not only for 800 numbers - they are just an example where it would be useful. And, the proxy is configured to do this - it doesn't do it because it "thinks" it has to do it :) >That doesn't make sense to me, although you could do it that way in a closed network, in which case you can make sure to always tag them as whatever you think they should be - so we could define an=20 >additional value for the tag. But, this is what I don't think is right in terms of normal SIP request routing and forwarding, which is what the current 4244bis tags have been defined to represent.=20 I really don't understand wht this "normal SIP request routing and forwarding" is all about. Normal SIP request routing and forwarding has issues, which were presented in the ua-loose-route draft - and that is why we are now working on a solution to solve those issues. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 15, 2009 1:23 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi Mary, Proxies will tag entries based on the functionality they perform. Let's leave req-uri-alias for the moment. As I said earlier, one of the issues we have with 4244bis, is that "mapped" seems to be used BOTH for diversion and when an AOR is replaced with another AOR pointing to the same user - e.g. freephone. So, it is not possible to distinguish between diversion and freephone. We think one MUST be able to make that distinguishment, because you may have cases where both diversion and service number translation (e.g. freephone) occurs, and the UAS needs to know which is which. Regards, Christer =20 -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Monday, June 15, 2009 9:13 PM To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt It seems to me that the gist of this discussion has been based on the expectation that independent of how the 800 number is configured, registered or whatever at a proxy, that there is an expectation of deterministic behavior in terms of how it's tagged. So, if 800 numbers are special and they can end up tagged as either reg-uri-alias or as mapped, then perhaps the service has to know that it needs to look for either of those. ISTM that if there is a reason to preserve that it's an 800 number (i.e., and not format as a service specific uri), the service at the UAS knows that it's special, thus it would need to check the request-URIs associated with both reg-uri-alias and mapped hi-entries. I can't see how we can make it work any other way without being prescriptive of how proxy's MUST tag these entries, which is not a good idea IMHO. However, I think these numbers are either special cases at proxies or something that services know about.=20 Mary.=20 -----Original Message----- From: Audet, Francois (SC100:3055) Sent: Monday, June 15, 2009 12:47 PM To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Yes, we need to sort out what to do for that.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 10:17 > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 >=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, June 15, 2009 6:50 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > then reg-uri-alias.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Saturday, June 13, 2009 01:22 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > >1) RFC 4244bis > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > Request-URI and it replacing it with a Contact, it will put > a reg-uri > > flag (if the Request-URI was the AOR used for registration), or reg- > > >uri-alias (if the Request-URI was an alias for the AOR used in > > registration). > >=20 > > And if the Request-URI was a "synonym" for the AOR? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 >=20 From ietf.hanserik@gmail.com Mon Jun 15 13:18:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96D53A6C68 for ; Mon, 15 Jun 2009 13:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.915 X-Spam-Level: X-Spam-Status: No, score=-0.915 tagged_above=-999 required=5 tests=[AWL=-0.816, BAYES_00=-2.599, MANGLED_REGALS=2.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRHoANmaCW4K for ; Mon, 15 Jun 2009 13:18:34 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id B66733A6D17 for ; Mon, 15 Jun 2009 13:18:33 -0700 (PDT) Received: by ewy6 with SMTP id 6so5346473ewy.37 for ; Mon, 15 Jun 2009 13:18:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=LIMEgEJi3LnjxBWn2l5LVfIdPixa3YvLH9NaiHF4boc=; b=Lw1qCTi53YYt1ky0LaWzF+0zL3AkNsKwg//1An0dMjowj3fXMqXBsvqQz0d2jqyINs BQTsP51saMUl0+5CH61M27jP+dFwXjlvgpW2M/oFZusWy6hvnCCkfxSqnzxPw/bz9T34 GWzF+r4mc6HJrsMdg2+4ZxUuAZ3q/bAv1jisA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=TGnFC/s/z+DhSnwj9Bt8XU9EqCc4da+yoCyiLP388wkW3T79FaBw9Jdo0MIducP79c q2AARdoaRjKnk+bjoSCG1z0LzX+4Ld3BiSTxOKMOOkS+FZkf3HT6WF8FxQlxsvbTtbry KfqXwIAQF0XQwf2t6GaiQU24Esynv2LgjQMZA= Received: by 10.210.129.19 with SMTP id b19mr66307ebd.30.1245097118373; Mon, 15 Jun 2009 13:18:38 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 7sm79110eyb.45.2009.06.15.13.18.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Jun 2009 13:18:37 -0700 (PDT) Message-ID: <4A36AC9C.3060509@gmail.com> Date: Mon, 15 Jun 2009 22:18:36 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 20:18:36 -0000 Just a subtle correction. The requirement is the delivery of the addressed target to the UAS, in order for it to be able to extract it. We dont have a freephone service requirement, the freephone service is a scenario that is a testcase which our solution should be able to cope with. /Hans Erik Christer Holmberg wrote: > Hi, > > >> But, still with this approach, I do not think you can get away with not >> > looking for multiple tags with the way you envision doing your services. > > Maybe not - that depends on the service. But, then it will at least be > possible to figure out what has happended. > > >> I think there are others that will implement services on the UAS that >> > will not need the differentiation that you do - i.e, they care about the > difference between "reg-uri" and "reg-uri-alias". > > My differentiation is based on my understanding of the requirements that > we have. > > If you think we need to differentiate between req-uri and req-uri-alias, > then we should agree on such requirement. Let's not mix it with the > freephone requirement. > > Regards, > > Christer > > > > > > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Monday, June 15, 2009 2:53 PM > To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN C, > ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Christer, > > On your last point, the objective here was to make use of History-Info > WITHOUT changing any core SIP functionality - it's a whole different > ballgame if we want to do the latter IMHO. However, here's the snippet > from the end of the response I just sent to Martin (summarizing the > current set of tags), which you may not read: > > " So, we're debating here the differences between the "aor,mapped" and > "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I think > that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed". > And, I think one could consider the "aor,mapped" as predetermined. But, > again 4244bis tags the entries entirely based on what SIP does and if > the 800 number translations (or whatever services) are setup differently > in different proxies, then you can't determine if the "aor,routed" cases > might be "reg-uri-alias" or "reg-uri". Although, I am personally > confused as to whether an 800 number would always be "aor, mapped" or > "aor, routed" - i.e., I just don't see this being deterministic and I > think that if a service can reach a UAS through different SIP > retargeting mechanisms, then the UAS needs to be aware. > > Also, as I'm going through this, I think we need 3 more tags if we want > the proxy to do the tagging - i.e., I think we need to add "-aor" to the > "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that the > proxy will mark in this manner. " > > > Mary. > P.S. Also, I do not think it's a burden to put logic in the UAS - that > was the original intent for SIP - services in the endpoints - SIP is > just the signalling to carry the relevant information. But, I can see > that since the sort of service you mention that does not have a standard > SIP URI (i.e., user@domain) introduces something that isn't accomodated > in the basic SIP model, so we may need to add additional logic to the > proxies (I don't like it though). > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 2:34 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > Hi, > > >> Correct. But, what I am suggesting is that you distinguish it at the >> > UAS > >> - I'm assuming that the target Request-URI that arrives at the UAS is >> > something that identifies a client that handles 800 numbers. That > client could be configured such that it knows to look for the > >> original 800 number in the mapped URIs or in the reg-alias-URIs or >> > both. > > 800 numbers is just one example. > > Why should the UAS have to be configured with this information??? I > think that is very limiting and unpractical. > > >> Again, if you're making these 800 numbers special and allowing proxies >> > to change them in multiple ways (i.e., non-deterministic), then if you > want them tagged special, then you need special logic in the > >> proxies to do this. >> > > The logic is that the AOR is replaced with another AOR, which belongs to > the same user. > > It's not only for 800 numbers - they are just an example where it would > be useful. > > And, the proxy is configured to do this - it doesn't do it because it > "thinks" it has to do it :) > > >> That doesn't make sense to me, although you could do it that way in a >> > closed network, in which case you can make sure to always tag them as > whatever you think they should be - so we could define an > >> additional value for the tag. But, this is what I don't think is right >> > in terms of normal SIP request routing and forwarding, which is what the > current 4244bis tags have been defined to represent. > > I really don't understand wht this "normal SIP request routing and > forwarding" is all about. Normal SIP request routing and forwarding has > issues, which were presented in the ua-loose-route draft - and that is > why we are now working on a solution to solve those issues. > > Regards, > > Christer > > > > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 1:23 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > Hi Mary, > > Proxies will tag entries based on the functionality they perform. > > Let's leave req-uri-alias for the moment. > > As I said earlier, one of the issues we have with 4244bis, is that > "mapped" seems to be used BOTH for diversion and when an AOR is replaced > with another AOR pointing to the same user - e.g. freephone. So, it is > not possible to distinguish between diversion and freephone. > > We think one MUST be able to make that distinguishment, because you may > have cases where both diversion and service number translation (e.g. > freephone) occurs, and the UAS needs to know which is which. > > Regards, > > Christer > > > > > > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 9:13 PM > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > It seems to me that the gist of this discussion has been based on the > expectation that independent of how the 800 number is configured, > registered or whatever at a proxy, that there is an expectation of > deterministic behavior in terms of how it's tagged. So, if 800 numbers > are special and they can end up tagged as either reg-uri-alias or as > mapped, then perhaps the service has to know that it needs to look for > either of those. ISTM that if there is a reason to preserve that it's an > 800 number (i.e., and not format as a service specific uri), the service > at the UAS knows that it's special, thus it would need to check the > request-URIs associated with both reg-uri-alias and mapped hi-entries. > I can't see how we can make it work any other way without being > prescriptive of how proxy's MUST tag these entries, which is not a good > idea IMHO. However, I think these numbers are either special cases at > proxies or something that services know about. > > Mary. > > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 12:47 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary > (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Yes, we need to sort out what to do for that. > > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Monday, June 15, 2009 10:17 >> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes, >> Mary (RICH2:AR00); sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> But if it is NOT an alias (=implicitly/explicitly registered)? >> >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> Sent: Monday, June 15, 2009 6:50 PM >> To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes; >> sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> then reg-uri-alias. >> >> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Saturday, June 13, 2009 01:22 >>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes, >>> Mary (RICH2:AR00); sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> >>> Hi, >>> >>> >>>> 1) RFC 4244bis >>>> >>>> In RFC 4244bis, if the domain is responsible for the URI in the >>>> >>> Request-URI and it replacing it with a Contact, it will put >>> >> a reg-uri >> >>> flag (if the Request-URI was the AOR used for registration), or reg- >>> >>>> uri-alias (if the Request-URI was an alias for the AOR used in >>>> >>> registration). >>> >>> And if the Request-URI was a "synonym" for the AOR? >>> >>> Regards, >>> >>> Christer >>> >>> >>> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Mon Jun 15 13:22:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8022F28C0FD for ; Mon, 15 Jun 2009 13:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[AWL=-0.746, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+GMtbxdgj0h for ; Mon, 15 Jun 2009 13:22:23 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 380D63A6858 for ; Mon, 15 Jun 2009 13:22:21 -0700 (PDT) X-AuditID: c1b4fb3c-b7b0bae00000673a-3b-4a36ad62fb8d Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id CD.D8.26426.26DA63A4; Mon, 15 Jun 2009 22:21:54 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jun 2009 22:21:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 22:21:53 +0200 Message-ID: In-Reply-To: <4A36AC9C.3060509@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFieg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> <4A36AC9 C.3060509@gmail.com> From: "Christer Holmberg" To: "Hans Erik van Elburg" X-OriginalArrivalTime: 15 Jun 2009 20:21:54.0054 (UTC) FILETIME=[EC64DA60:01C9EDF6] X-Brightmail-Tracker: AAAAAA== Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 20:22:24 -0000 Correct. Regards, Christer=20 -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Monday, June 15, 2009 11:19 PM To: Christer Holmberg Cc: Mary Barnes; Francois Audet; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Just a subtle correction. The requirement is the delivery of the addressed target to the UAS, in order for it to be able to extract it. We dont have a freephone service requirement, the freephone service is a scenario that is a testcase which our solution should be able to cope with. /Hans Erik Christer Holmberg wrote: > Hi, > > =20 >> But, still with this approach, I do not think you can get away with=20 >> not >> =20 > looking for multiple tags with the way you envision doing your services. > > Maybe not - that depends on the service. But, then it will at least be > possible to figure out what has happended. > > =20 >> I think there are others that will implement services on the UAS that >> =20 > will not need the differentiation that you do - i.e, they care about=20 > the difference between "reg-uri" and "reg-uri-alias". > > My differentiation is based on my understanding of the requirements=20 > that we have. > > If you think we need to differentiate between req-uri and=20 > req-uri-alias, then we should agree on such requirement. Let's not mix > it with the freephone requirement. > > Regards, > > Christer > > > > > > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Monday, June 15, 2009 2:53 PM > To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN=20 > C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Christer, > > On your last point, the objective here was to make use of History-Info > WITHOUT changing any core SIP functionality - it's a whole different=20 > ballgame if we want to do the latter IMHO. However, here's the snippet > from the end of the response I just sent to Martin (summarizing the=20 > current set of tags), which you may not read: > > " So, we're debating here the differences between the "aor,mapped" and > "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I=20 > think that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed". > And, I think one could consider the "aor,mapped" as predetermined.=20 > But, again 4244bis tags the entries entirely based on what SIP does=20 > and if the 800 number translations (or whatever services) are setup=20 > differently in different proxies, then you can't determine if the=20 > "aor,routed" cases might be "reg-uri-alias" or "reg-uri". Although, I > am personally confused as to whether an 800 number would always be=20 > "aor, mapped" or "aor, routed" - i.e., I just don't see this being=20 > deterministic and I think that if a service can reach a UAS through=20 > different SIP retargeting mechanisms, then the UAS needs to be aware. > > Also, as I'm going through this, I think we need 3 more tags if we=20 > want the proxy to do the tagging - i.e., I think we need to add "-aor" > to the "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that > the proxy will mark in this manner. " > > > Mary.=20 > P.S. Also, I do not think it's a burden to put logic in the UAS - that > was the original intent for SIP - services in the endpoints - SIP is=20 > just the signalling to carry the relevant information. But, I can see=20 > that since the sort of service you mention that does not have a=20 > standard SIP URI (i.e., user@domain) introduces something that isn't=20 > accomodated in the basic SIP model, so we may need to add additional=20 > logic to the proxies (I don't like it though). > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 2:34 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,=20 > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > Hi, > > =20 >> Correct. But, what I am suggesting is that you distinguish it at the >> =20 > UAS > =20 >> - I'm assuming that the target Request-URI that arrives at the UAS is >> =20 > something that identifies a client that handles 800 numbers. That=20 > client could be configured such that it knows to look for the > =20 >> original 800 number in the mapped URIs or in the reg-alias-URIs or >> =20 > both.=20 > > 800 numbers is just one example.=20 > > Why should the UAS have to be configured with this information??? I=20 > think that is very limiting and unpractical. > > =20 >> Again, if you're making these 800 numbers special and allowing=20 >> proxies >> =20 > to change them in multiple ways (i.e., non-deterministic), then if you > want them tagged special, then you need special logic in the > =20 >> proxies to do this. >> =20 > > The logic is that the AOR is replaced with another AOR, which belongs=20 > to the same user. > > It's not only for 800 numbers - they are just an example where it=20 > would be useful. > > And, the proxy is configured to do this - it doesn't do it because it > "thinks" it has to do it :) > > =20 >> That doesn't make sense to me, although you could do it that way in a >> =20 > closed network, in which case you can make sure to always tag them as=20 > whatever you think they should be - so we could define an > =20 >> additional value for the tag. But, this is what I don't think is=20 >> right >> =20 > in terms of normal SIP request routing and forwarding, which is what=20 > the current 4244bis tags have been defined to represent. > > I really don't understand wht this "normal SIP request routing and=20 > forwarding" is all about. Normal SIP request routing and forwarding=20 > has issues, which were presented in the ua-loose-route draft - and=20 > that is why we are now working on a solution to solve those issues. > > Regards, > > Christer > > > > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 1:23 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,=20 > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > Hi Mary, > > Proxies will tag entries based on the functionality they perform. > > Let's leave req-uri-alias for the moment. > > As I said earlier, one of the issues we have with 4244bis, is that=20 > "mapped" seems to be used BOTH for diversion and when an AOR is=20 > replaced with another AOR pointing to the same user - e.g. freephone.=20 > So, it is not possible to distinguish between diversion and freephone. > > We think one MUST be able to make that distinguishment, because you=20 > may have cases where both diversion and service number translation (e.g. > freephone) occurs, and the UAS needs to know which is which. > > Regards, > > Christer > > > > > > =20 > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 9:13 PM > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > It seems to me that the gist of this discussion has been based on the=20 > expectation that independent of how the 800 number is configured,=20 > registered or whatever at a proxy, that there is an expectation of=20 > deterministic behavior in terms of how it's tagged. So, if 800=20 > numbers are special and they can end up tagged as either reg-uri-alias > or as mapped, then perhaps the service has to know that it needs to=20 > look for either of those. ISTM that if there is a reason to preserve=20 > that it's an 800 number (i.e., and not format as a service specific=20 > uri), the service at the UAS knows that it's special, thus it would=20 > need to check the request-URIs associated with both reg-uri-alias and mapped hi-entries. > I can't see how we can make it work any other way without being=20 > prescriptive of how proxy's MUST tag these entries, which is not a=20 > good idea IMHO. However, I think these numbers are either special=20 > cases at proxies or something that services know about. > > Mary.=20 > > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 12:47 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary=20 > (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Yes, we need to sort out what to do for that.=20 > > =20 >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Monday, June 15, 2009 10:17 >> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 >> Mary (RICH2:AR00); sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 >> >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> Sent: Monday, June 15, 2009 6:50 PM >> To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 >> sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> then reg-uri-alias.=20 >> >> =20 >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Saturday, June 13, 2009 01:22 >>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 >>> Mary (RICH2:AR00); sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> >>> Hi, >>> >>> =20 >>>> 1) RFC 4244bis >>>> >>>> In RFC 4244bis, if the domain is responsible for the URI in the >>>> =20 >>> Request-URI and it replacing it with a Contact, it will put >>> =20 >> a reg-uri >> =20 >>> flag (if the Request-URI was the AOR used for registration), or reg- >>> =20 >>>> uri-alias (if the Request-URI was an alias for the AOR used in >>>> =20 >>> registration). >>> >>> And if the Request-URI was a "synonym" for the AOR? >>> >>> Regards, >>> >>> Christer >>> >>> >>> =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > =20 From mary.barnes@nortel.com Mon Jun 15 13:34:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3BA13A6D17 for ; Mon, 15 Jun 2009 13:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.136 X-Spam-Level: X-Spam-Status: No, score=-5.136 tagged_above=-999 required=5 tests=[AWL=-1.037, BAYES_00=-2.599, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ra6W7AOyr8M for ; Mon, 15 Jun 2009 13:34:29 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0FD573A6A8D for ; Mon, 15 Jun 2009 13:34:28 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5FKX0x15495; Mon, 15 Jun 2009 20:33:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 15:36:51 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E83DBEA@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A36AA56.2000600@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt thread-index: Acnt9SHRGozyo0XtRWiw+zqrEjfk6AAA7lUQ References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! <4A36AA56 .2000600@gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 20:34:30 -0000 Debug/diagnostics - we've talked about this from day 1.=20 -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Monday, June 15, 2009 3:09 PM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt I think this is a new requirement. 4244bis has introduced this distinction, so maybe you have a some requirement in mind. Maybe you can explain why it is needed? /Hans Erik Mary Barnes wrote: > But, still with this approach, I do not think you can get away with=20 > not looking for multiple tags with the way you envision doing your services. > I think there are others that will implement services on the UAS that=20 > will not need the differentiation that you do - i.e, they care about=20 > the difference between "reg-uri" and "reg-uri-alias". > > Mary.=20 > > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Monday, June 15, 2009 2:53 PM > To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN=20 > C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Christer, > > On your last point, the objective here was to make use of History-Info > WITHOUT changing any core SIP functionality - it's a whole different=20 > ballgame if we want to do the latter IMHO. However, here's the snippet > from the end of the response I just sent to Martin (summarizing the=20 > current set of tags), which you may not read: > > " So, we're debating here the differences between the "aor,mapped" and > "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I=20 > think that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed". > And, I think one could consider the "aor,mapped" as predetermined.=20 > But, again 4244bis tags the entries entirely based on what SIP does=20 > and if the 800 number translations (or whatever services) are setup=20 > differently in different proxies, then you can't determine if the=20 > "aor,routed" cases might be "reg-uri-alias" or "reg-uri". Although, I > am personally confused as to whether an 800 number would always be=20 > "aor, mapped" or "aor, routed" - i.e., I just don't see this being=20 > deterministic and I think that if a service can reach a UAS through=20 > different SIP retargeting mechanisms, then the UAS needs to be aware. > > Also, as I'm going through this, I think we need 3 more tags if we=20 > want the proxy to do the tagging - i.e., I think we need to add "-aor" > to the "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that > the proxy will mark in this manner. " > > > Mary.=20 > P.S. Also, I do not think it's a burden to put logic in the UAS - that > was the original intent for SIP - services in the endpoints - SIP is=20 > just the signalling to carry the relevant information. But, I can see=20 > that since the sort of service you mention that does not have a=20 > standard SIP URI (i.e., user@domain) introduces something that isn't=20 > accomodated in the basic SIP model, so we may need to add additional=20 > logic to the proxies (I don't like it though). > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 2:34 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,=20 > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > Hi, > > =20 >> Correct. But, what I am suggesting is that you distinguish it at the >> =20 > UAS > =20 >> - I'm assuming that the target Request-URI that arrives at the UAS is >> =20 > something that identifies a client that handles 800 numbers. That=20 > client could be configured such that it knows to look for the > =20 >> original 800 number in the mapped URIs or in the reg-alias-URIs or >> =20 > both.=20 > > 800 numbers is just one example.=20 > > Why should the UAS have to be configured with this information??? I=20 > think that is very limiting and unpractical. > > =20 >> Again, if you're making these 800 numbers special and allowing=20 >> proxies >> =20 > to change them in multiple ways (i.e., non-deterministic), then if you > want them tagged special, then you need special logic in the > =20 >> proxies to do this. >> =20 > > The logic is that the AOR is replaced with another AOR, which belongs=20 > to the same user. > > It's not only for 800 numbers - they are just an example where it=20 > would be useful. > > And, the proxy is configured to do this - it doesn't do it because it > "thinks" it has to do it :) > > =20 >> That doesn't make sense to me, although you could do it that way in a >> =20 > closed network, in which case you can make sure to always tag them as=20 > whatever you think they should be - so we could define an > =20 >> additional value for the tag. But, this is what I don't think is=20 >> right >> =20 > in terms of normal SIP request routing and forwarding, which is what=20 > the current 4244bis tags have been defined to represent. > > I really don't understand wht this "normal SIP request routing and=20 > forwarding" is all about. Normal SIP request routing and forwarding=20 > has issues, which were presented in the ua-loose-route draft - and=20 > that is why we are now working on a solution to solve those issues. > > Regards, > > Christer > > > > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 1:23 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,=20 > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > Hi Mary, > > Proxies will tag entries based on the functionality they perform. > > Let's leave req-uri-alias for the moment. > > As I said earlier, one of the issues we have with 4244bis, is that=20 > "mapped" seems to be used BOTH for diversion and when an AOR is=20 > replaced with another AOR pointing to the same user - e.g. freephone.=20 > So, it is not possible to distinguish between diversion and freephone. > > We think one MUST be able to make that distinguishment, because you=20 > may have cases where both diversion and service number translation (e.g. > freephone) occurs, and the UAS needs to know which is which. > > Regards, > > Christer > > > > > > =20 > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 9:13 PM > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > It seems to me that the gist of this discussion has been based on the=20 > expectation that independent of how the 800 number is configured,=20 > registered or whatever at a proxy, that there is an expectation of=20 > deterministic behavior in terms of how it's tagged. So, if 800=20 > numbers are special and they can end up tagged as either reg-uri-alias > or as mapped, then perhaps the service has to know that it needs to=20 > look for either of those. ISTM that if there is a reason to preserve=20 > that it's an 800 number (i.e., and not format as a service specific=20 > uri), the service at the UAS knows that it's special, thus it would=20 > need to check the request-URIs associated with both reg-uri-alias and mapped hi-entries. > I can't see how we can make it work any other way without being=20 > prescriptive of how proxy's MUST tag these entries, which is not a=20 > good idea IMHO. However, I think these numbers are either special=20 > cases at proxies or something that services know about. > > Mary.=20 > > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 12:47 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary=20 > (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > Yes, we need to sort out what to do for that.=20 > > =20 >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Monday, June 15, 2009 10:17 >> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 >> Mary (RICH2:AR00); sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 >> >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> Sent: Monday, June 15, 2009 6:50 PM >> To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 >> sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> then reg-uri-alias.=20 >> >> =20 >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Saturday, June 13, 2009 01:22 >>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 >>> Mary (RICH2:AR00); sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> >>> Hi, >>> >>> =20 >>>> 1) RFC 4244bis >>>> >>>> In RFC 4244bis, if the domain is responsible for the URI in the >>>> =20 >>> Request-URI and it replacing it with a Contact, it will put >>> =20 >> a reg-uri >> =20 >>> flag (if the Request-URI was the AOR used for registration), or reg- >>> =20 >>>> uri-alias (if the Request-URI was an alias for the AOR used in >>>> =20 >>> registration). >>> >>> And if the Request-URI was a "synonym" for the AOR? >>> >>> Regards, >>> >>> Christer >>> >>> >>> =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > =20 From mary.barnes@nortel.com Mon Jun 15 13:35:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEEB03A6CD4 for ; Mon, 15 Jun 2009 13:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.115 X-Spam-Level: X-Spam-Status: No, score=-5.115 tagged_above=-999 required=5 tests=[AWL=-1.016, BAYES_00=-2.599, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Vebe+DleMmW for ; Mon, 15 Jun 2009 13:35:26 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 3468E28C147 for ; Mon, 15 Jun 2009 13:35:26 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5FKY3x15643; Mon, 15 Jun 2009 20:34:03 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 15:37:53 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E83DBEB@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt thread-index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYAAADaOvAAAEZYIAAAZd2gAAEEtLA= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>! From: "Mary Barnes" To: "Christer Holmberg" , "Francois Audet" , "DOLLY, MARTIN C, ATTLABS" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 20:35:27 -0000 But, the freephone service can be implemented also with a reg-uri or reg-uri-alias - NOW if a specific service treats them the same, no big deal. The UAS then looks for any of a set of tags to grab the appropriate hi-entry.=20 Mary. -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Monday, June 15, 2009 3:14 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi,=20 >But, still with this approach, I do not think you can get away with not looking for multiple tags with the way you envision doing your services. Maybe not - that depends on the service. But, then it will at least be possible to figure out what has happended. >I think there are others that will implement services on the UAS that will not need the differentiation that you do - i.e, they care about the difference between "reg-uri" and "reg-uri-alias". My differentiation is based on my understanding of the requirements that we have. If you think we need to differentiate between req-uri and req-uri-alias, then we should agree on such requirement. Let's not mix it with the freephone requirement. Regards, Christer -----Original Message----- From: Barnes, Mary (RICH2:AR00) Sent: Monday, June 15, 2009 2:53 PM To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Christer,=20 On your last point, the objective here was to make use of History-Info WITHOUT changing any core SIP functionality - it's a whole different ballgame if we want to do the latter IMHO. However, here's the snippet from the end of the response I just sent to Martin (summarizing the current set of tags), which you may not read: " So, we're debating here the differences between the "aor,mapped" and "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I think that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed". And, I think one could consider the "aor,mapped" as predetermined. But, again 4244bis tags the entries entirely based on what SIP does and if the 800 number translations (or whatever services) are setup differently in different proxies, then you can't determine if the "aor,routed" cases might be "reg-uri-alias" or "reg-uri". Although, I am personally confused as to whether an 800 number would always be "aor, mapped" or "aor, routed" - i.e., I just don't see this being deterministic and I think that if a service can reach a UAS through different SIP retargeting mechanisms, then the UAS needs to be aware.=20 Also, as I'm going through this, I think we need 3 more tags if we want the proxy to do the tagging - i.e., I think we need to add "-aor" to the "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that the proxy will mark in this manner. " Mary.=20 P.S. Also, I do not think it's a burden to put logic in the UAS - that was the original intent for SIP - services in the endpoints - SIP is just the signalling to carry the relevant information. But, I can see that since the sort of service you mention that does not have a standard SIP URI (i.e., user@domain) introduces something that isn't accomodated in the basic SIP model, so we may need to add additional logic to the proxies (I don't like it though).=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 15, 2009 2:34 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi,=20 >Correct. But, what I am suggesting is that you distinguish it at the UAS >- I'm assuming that the target Request-URI that arrives at the UAS is something that identifies a client that handles 800 numbers. That client could be configured such that it knows to look for the=20 >original 800 number in the mapped URIs or in the reg-alias-URIs or both.=20 800 numbers is just one example.=20 Why should the UAS have to be configured with this information??? I think that is very limiting and unpractical. >Again, if you're making these 800 numbers special and allowing proxies to change them in multiple ways (i.e., non-deterministic), then if you want them tagged special, then you need special logic in the=20 >proxies to do this. The logic is that the AOR is replaced with another AOR, which belongs to the same user.=20 It's not only for 800 numbers - they are just an example where it would be useful. And, the proxy is configured to do this - it doesn't do it because it "thinks" it has to do it :) >That doesn't make sense to me, although you could do it that way in a closed network, in which case you can make sure to always tag them as whatever you think they should be - so we could define an=20 >additional value for the tag. But, this is what I don't think is right in terms of normal SIP request routing and forwarding, which is what the current 4244bis tags have been defined to represent.=20 I really don't understand wht this "normal SIP request routing and forwarding" is all about. Normal SIP request routing and forwarding has issues, which were presented in the ua-loose-route draft - and that is why we are now working on a solution to solve those issues. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 15, 2009 1:23 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi Mary, Proxies will tag entries based on the functionality they perform. Let's leave req-uri-alias for the moment. As I said earlier, one of the issues we have with 4244bis, is that "mapped" seems to be used BOTH for diversion and when an AOR is replaced with another AOR pointing to the same user - e.g. freephone. So, it is not possible to distinguish between diversion and freephone. We think one MUST be able to make that distinguishment, because you may have cases where both diversion and service number translation (e.g. freephone) occurs, and the UAS needs to know which is which. Regards, Christer =20 -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Monday, June 15, 2009 9:13 PM To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt It seems to me that the gist of this discussion has been based on the expectation that independent of how the 800 number is configured, registered or whatever at a proxy, that there is an expectation of deterministic behavior in terms of how it's tagged. So, if 800 numbers are special and they can end up tagged as either reg-uri-alias or as mapped, then perhaps the service has to know that it needs to look for either of those. ISTM that if there is a reason to preserve that it's an 800 number (i.e., and not format as a service specific uri), the service at the UAS knows that it's special, thus it would need to check the request-URIs associated with both reg-uri-alias and mapped hi-entries. I can't see how we can make it work any other way without being prescriptive of how proxy's MUST tag these entries, which is not a good idea IMHO. However, I think these numbers are either special cases at proxies or something that services know about.=20 Mary.=20 -----Original Message----- From: Audet, Francois (SC100:3055) Sent: Monday, June 15, 2009 12:47 PM To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Yes, we need to sort out what to do for that.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 10:17 > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 >=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, June 15, 2009 6:50 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > then reg-uri-alias.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Saturday, June 13, 2009 01:22 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > >1) RFC 4244bis > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > Request-URI and it replacing it with a Contact, it will put > a reg-uri > > flag (if the Request-URI was the AOR used for registration), or reg- > > >uri-alias (if the Request-URI was an alias for the AOR used in > > registration). > >=20 > > And if the Request-URI was a "synonym" for the AOR? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 >=20 From ietf.hanserik@gmail.com Mon Jun 15 13:40:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D841F3A6CD4 for ; Mon, 15 Jun 2009 13:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.86 X-Spam-Level: X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[AWL=-0.761, BAYES_00=-2.599, MANGLED_REGALS=2.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpXxiJkzOKss for ; Mon, 15 Jun 2009 13:40:24 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 1E22D3A6D27 for ; Mon, 15 Jun 2009 13:40:23 -0700 (PDT) Received: by ewy6 with SMTP id 6so5363707ewy.37 for ; Mon, 15 Jun 2009 13:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=fj2sj8MRne9KGQt5YUm8V93hOchq2osC6IjQUIZE1YI=; b=RCKbYZQawaxJWPXb9mL333/QhGzNP2kCskooRdbcVLcFXVp32LXeaIPlP17AJZSoCC lTvsdZvmf+F85WRhxgSyeU2YMVHG1FeYw72U50ISeFtV4A3wW1nLsZPJV3QFeqrvWAbC PUJTz2oivZ4Vp3czGA7GbxpJPUbC4rAgvJuk0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=OYg7Pn3g9F6wCbwC0VaMX1UtieuaSY4IGjE7KoSA3FmSNkbbezXGm/7bk9mJ93WOqr 1bhtsI7xbM/l6h866bRMZkDmMRlS7zSfYBvuscaoWV9euL/BcL/wPj4BiLF/ZCIJC4lS hLeLCzOwnNxhUizzUuiFuW+qUIFdk9WVD9eSk= Received: by 10.210.28.18 with SMTP id b18mr8733830ebb.22.1245098406599; Mon, 15 Jun 2009 13:40:06 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 5sm1931eyf.18.2009.06.15.13.40.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 15 Jun 2009 13:40:03 -0700 (PDT) Message-ID: <4A36B1A2.6040407@gmail.com> Date: Mon, 15 Jun 2009 22:40:02 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mary Barnes References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! <4A36AA56 .2000600@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DBEA@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83DBEA@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 20:40:25 -0000 Ok, so this is a 4244bis requirement, not a target-uri requirement. Thats fine. i have no problem with covering that, but Id like to be explicit on what requirement we are covering when. BR, /Hans Erik Mary Barnes wrote: > Debug/diagnostics - we've talked about this from day 1. > > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Monday, June 15, 2009 3:09 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Audet, Francois (SC100:3055); DOLLY, MARTIN C, > ATTLABS; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > I think this is a new requirement. > > 4244bis has introduced this distinction, so maybe you have a some > requirement in mind. > Maybe you can explain why it is needed? > > /Hans Erik > > Mary Barnes wrote: > >> But, still with this approach, I do not think you can get away with >> not looking for multiple tags with the way you envision doing your >> > services. > >> I think there are others that will implement services on the UAS that >> will not need the differentiation that you do - i.e, they care about >> the difference between "reg-uri" and "reg-uri-alias". >> >> Mary. >> >> -----Original Message----- >> From: Barnes, Mary (RICH2:AR00) >> Sent: Monday, June 15, 2009 2:53 PM >> To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN >> C, ATTLABS; sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Christer, >> >> On your last point, the objective here was to make use of History-Info >> > > >> WITHOUT changing any core SIP functionality - it's a whole different >> ballgame if we want to do the latter IMHO. However, here's the snippet >> > > >> from the end of the response I just sent to Martin (summarizing the >> current set of tags), which you may not read: >> >> " So, we're debating here the differences between the "aor,mapped" and >> > > >> "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I >> think that "reg-uri-alias" and "reg-uri" are equivalent to "aor, >> > routed". > >> And, I think one could consider the "aor,mapped" as predetermined. >> But, again 4244bis tags the entries entirely based on what SIP does >> and if the 800 number translations (or whatever services) are setup >> differently in different proxies, then you can't determine if the >> "aor,routed" cases might be "reg-uri-alias" or "reg-uri". Although, I >> > > >> am personally confused as to whether an 800 number would always be >> "aor, mapped" or "aor, routed" - i.e., I just don't see this being >> deterministic and I think that if a service can reach a UAS through >> different SIP retargeting mechanisms, then the UAS needs to be aware. >> >> Also, as I'm going through this, I think we need 3 more tags if we >> want the proxy to do the tagging - i.e., I think we need to add "-aor" >> > > >> to the "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that >> > > >> the proxy will mark in this manner. " >> >> >> Mary. >> P.S. Also, I do not think it's a burden to put logic in the UAS - that >> > > >> was the original intent for SIP - services in the endpoints - SIP is >> just the signalling to carry the relevant information. But, I can see >> that since the sort of service you mention that does not have a >> standard SIP URI (i.e., user@domain) introduces something that isn't >> accomodated in the basic SIP model, so we may need to add additional >> logic to the proxies (I don't like it though). >> >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Monday, June 15, 2009 2:34 PM >> To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, >> MARTIN C, ATTLABS; sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> Hi, >> >> >> >>> Correct. But, what I am suggesting is that you distinguish it at the >>> >>> >> UAS >> >> >>> - I'm assuming that the target Request-URI that arrives at the UAS is >>> >>> >> something that identifies a client that handles 800 numbers. That >> client could be configured such that it knows to look for the >> >> >>> original 800 number in the mapped URIs or in the reg-alias-URIs or >>> >>> >> both. >> >> 800 numbers is just one example. >> >> Why should the UAS have to be configured with this information??? I >> think that is very limiting and unpractical. >> >> >> >>> Again, if you're making these 800 numbers special and allowing >>> proxies >>> >>> >> to change them in multiple ways (i.e., non-deterministic), then if you >> > > >> want them tagged special, then you need special logic in the >> >> >>> proxies to do this. >>> >>> >> The logic is that the AOR is replaced with another AOR, which belongs >> to the same user. >> >> It's not only for 800 numbers - they are just an example where it >> would be useful. >> >> And, the proxy is configured to do this - it doesn't do it because it >> > > >> "thinks" it has to do it :) >> >> >> >>> That doesn't make sense to me, although you could do it that way in a >>> >>> >> closed network, in which case you can make sure to always tag them as >> whatever you think they should be - so we could define an >> >> >>> additional value for the tag. But, this is what I don't think is >>> right >>> >>> >> in terms of normal SIP request routing and forwarding, which is what >> the current 4244bis tags have been defined to represent. >> >> I really don't understand wht this "normal SIP request routing and >> forwarding" is all about. Normal SIP request routing and forwarding >> has issues, which were presented in the ua-loose-route draft - and >> that is why we are now working on a solution to solve those issues. >> >> Regards, >> >> Christer >> >> >> >> >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Monday, June 15, 2009 1:23 PM >> To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, >> MARTIN C, ATTLABS; sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> Hi Mary, >> >> Proxies will tag entries based on the functionality they perform. >> >> Let's leave req-uri-alias for the moment. >> >> As I said earlier, one of the issues we have with 4244bis, is that >> "mapped" seems to be used BOTH for diversion and when an AOR is >> replaced with another AOR pointing to the same user - e.g. freephone. >> So, it is not possible to distinguish between diversion and freephone. >> >> We think one MUST be able to make that distinguishment, because you >> may have cases where both diversion and service number translation >> > (e.g. > >> freephone) occurs, and the UAS needs to know which is which. >> >> Regards, >> >> Christer >> >> >> >> >> >> >> >> -----Original Message----- >> From: Mary Barnes [mailto:mary.barnes@nortel.com] >> Sent: Monday, June 15, 2009 9:13 PM >> To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; >> sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> It seems to me that the gist of this discussion has been based on the >> expectation that independent of how the 800 number is configured, >> registered or whatever at a proxy, that there is an expectation of >> deterministic behavior in terms of how it's tagged. So, if 800 >> numbers are special and they can end up tagged as either reg-uri-alias >> > > >> or as mapped, then perhaps the service has to know that it needs to >> look for either of those. ISTM that if there is a reason to preserve >> that it's an 800 number (i.e., and not format as a service specific >> uri), the service at the UAS knows that it's special, thus it would >> need to check the request-URIs associated with both reg-uri-alias and >> > mapped hi-entries. > >> I can't see how we can make it work any other way without being >> prescriptive of how proxy's MUST tag these entries, which is not a >> good idea IMHO. However, I think these numbers are either special >> cases at proxies or something that services know about. >> >> Mary. >> >> -----Original Message----- >> From: Audet, Francois (SC100:3055) >> Sent: Monday, June 15, 2009 12:47 PM >> To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary >> (RICH2:AR00); sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Yes, we need to sort out what to do for that. >> >> >> >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Monday, June 15, 2009 10:17 >>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes, >>> Mary (RICH2:AR00); sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> >>> But if it is NOT an alias (=implicitly/explicitly registered)? >>> >>> -----Original Message----- >>> From: Francois Audet [mailto:audet@nortel.com] >>> Sent: Monday, June 15, 2009 6:50 PM >>> To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes; >>> sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> then reg-uri-alias. >>> >>> >>> >>>> -----Original Message----- >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: Saturday, June 13, 2009 01:22 >>>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes, >>>> Mary (RICH2:AR00); sipcore@ietf.org >>>> Subject: RE: [sipcore] FW: I-D >>>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>>> 1) RFC 4244bis >>>>> >>>>> In RFC 4244bis, if the domain is responsible for the URI in the >>>>> >>>>> >>>> Request-URI and it replacing it with a Contact, it will put >>>> >>>> >>> a reg-uri >>> >>> >>>> flag (if the Request-URI was the AOR used for registration), or reg- >>>> >>>> >>>>> uri-alias (if the Request-URI was an alias for the AOR used in >>>>> >>>>> >>>> registration). >>>> >>>> And if the Request-URI was a "synonym" for the AOR? >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> >>>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> From christer.holmberg@ericsson.com Mon Jun 15 13:44:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B84F43A6947 for ; Mon, 15 Jun 2009 13:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.461 X-Spam-Level: X-Spam-Status: No, score=-4.461 tagged_above=-999 required=5 tests=[AWL=-0.712, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vn103NFz581y for ; Mon, 15 Jun 2009 13:44:09 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C2DA43A67E1 for ; Mon, 15 Jun 2009 13:44:07 -0700 (PDT) X-AuditID: c1b4fb3c-b7b0bae00000673a-51-4a36b2a19775 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 29.59.26426.1A2B63A4; Mon, 15 Jun 2009 22:44:17 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jun 2009 22:44:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 22:44:16 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83DBEB@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYAAADaOvAAAEZYIAAAZd2gAAEEtLAAACFWAA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>! <1ECE0EB50388174790F9694F77522CCF1E83DBEB@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Mary Barnes" , "Francois Audet" , "DOLLY, MARTIN C, ATTLABS" , X-OriginalArrivalTime: 15 Jun 2009 20:44:16.0823 (UTC) FILETIME=[0CBF2470:01C9EDFA] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 20:44:10 -0000 Hi,=20 >But, the freephone service can be implemented also with a reg-uri or reg-uri-alias - NOW if a specific service treats them the same, no big deal. The UAS then looks for any of a set of tags to grab the=20 >appropriate hi-entry.=20 Req-uri and req-uri-alias replaces an AOR with a registered contact. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 15, 2009 3:14 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi,=20 >But, still with this approach, I do not think you can get away with not looking for multiple tags with the way you envision doing your services. Maybe not - that depends on the service. But, then it will at least be possible to figure out what has happended. >I think there are others that will implement services on the UAS that will not need the differentiation that you do - i.e, they care about the difference between "reg-uri" and "reg-uri-alias". My differentiation is based on my understanding of the requirements that we have. If you think we need to differentiate between req-uri and req-uri-alias, then we should agree on such requirement. Let's not mix it with the freephone requirement. Regards, Christer -----Original Message----- From: Barnes, Mary (RICH2:AR00) Sent: Monday, June 15, 2009 2:53 PM To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Christer,=20 On your last point, the objective here was to make use of History-Info WITHOUT changing any core SIP functionality - it's a whole different ballgame if we want to do the latter IMHO. However, here's the snippet from the end of the response I just sent to Martin (summarizing the current set of tags), which you may not read: " So, we're debating here the differences between the "aor,mapped" and "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I think that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed". And, I think one could consider the "aor,mapped" as predetermined. But, again 4244bis tags the entries entirely based on what SIP does and if the 800 number translations (or whatever services) are setup differently in different proxies, then you can't determine if the "aor,routed" cases might be "reg-uri-alias" or "reg-uri". Although, I am personally confused as to whether an 800 number would always be "aor, mapped" or "aor, routed" - i.e., I just don't see this being deterministic and I think that if a service can reach a UAS through different SIP retargeting mechanisms, then the UAS needs to be aware.=20 Also, as I'm going through this, I think we need 3 more tags if we want the proxy to do the tagging - i.e., I think we need to add "-aor" to the "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that the proxy will mark in this manner. " Mary.=20 P.S. Also, I do not think it's a burden to put logic in the UAS - that was the original intent for SIP - services in the endpoints - SIP is just the signalling to carry the relevant information. But, I can see that since the sort of service you mention that does not have a standard SIP URI (i.e., user@domain) introduces something that isn't accomodated in the basic SIP model, so we may need to add additional logic to the proxies (I don't like it though).=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 15, 2009 2:34 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi,=20 >Correct. But, what I am suggesting is that you distinguish it at the UAS >- I'm assuming that the target Request-URI that arrives at the UAS is something that identifies a client that handles 800 numbers. That client could be configured such that it knows to look for the=20 >original 800 number in the mapped URIs or in the reg-alias-URIs or both.=20 800 numbers is just one example.=20 Why should the UAS have to be configured with this information??? I think that is very limiting and unpractical. >Again, if you're making these 800 numbers special and allowing proxies to change them in multiple ways (i.e., non-deterministic), then if you want them tagged special, then you need special logic in the=20 >proxies to do this. The logic is that the AOR is replaced with another AOR, which belongs to the same user.=20 It's not only for 800 numbers - they are just an example where it would be useful. And, the proxy is configured to do this - it doesn't do it because it "thinks" it has to do it :) >That doesn't make sense to me, although you could do it that way in a closed network, in which case you can make sure to always tag them as whatever you think they should be - so we could define an=20 >additional value for the tag. But, this is what I don't think is right in terms of normal SIP request routing and forwarding, which is what the current 4244bis tags have been defined to represent.=20 I really don't understand wht this "normal SIP request routing and forwarding" is all about. Normal SIP request routing and forwarding has issues, which were presented in the ua-loose-route draft - and that is why we are now working on a solution to solve those issues. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 15, 2009 1:23 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi Mary, Proxies will tag entries based on the functionality they perform. Let's leave req-uri-alias for the moment. As I said earlier, one of the issues we have with 4244bis, is that "mapped" seems to be used BOTH for diversion and when an AOR is replaced with another AOR pointing to the same user - e.g. freephone. So, it is not possible to distinguish between diversion and freephone. We think one MUST be able to make that distinguishment, because you may have cases where both diversion and service number translation (e.g. freephone) occurs, and the UAS needs to know which is which. Regards, Christer =20 -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Monday, June 15, 2009 9:13 PM To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt It seems to me that the gist of this discussion has been based on the expectation that independent of how the 800 number is configured, registered or whatever at a proxy, that there is an expectation of deterministic behavior in terms of how it's tagged. So, if 800 numbers are special and they can end up tagged as either reg-uri-alias or as mapped, then perhaps the service has to know that it needs to look for either of those. ISTM that if there is a reason to preserve that it's an 800 number (i.e., and not format as a service specific uri), the service at the UAS knows that it's special, thus it would need to check the request-URIs associated with both reg-uri-alias and mapped hi-entries. I can't see how we can make it work any other way without being prescriptive of how proxy's MUST tag these entries, which is not a good idea IMHO. However, I think these numbers are either special cases at proxies or something that services know about.=20 Mary.=20 -----Original Message----- From: Audet, Francois (SC100:3055) Sent: Monday, June 15, 2009 12:47 PM To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Yes, we need to sort out what to do for that.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 10:17 > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 >=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, June 15, 2009 6:50 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > then reg-uri-alias.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Saturday, June 13, 2009 01:22 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > >1) RFC 4244bis > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > Request-URI and it replacing it with a Contact, it will put > a reg-uri > > flag (if the Request-URI was the AOR used for registration), or reg- > > >uri-alias (if the Request-URI was an alias for the AOR used in > > registration). > >=20 > > And if the Request-URI was a "synonym" for the AOR? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 >=20 From christer.holmberg@ericsson.com Mon Jun 15 13:49:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7577F3A67E1 for ; Mon, 15 Jun 2009 13:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.43 X-Spam-Level: X-Spam-Status: No, score=-4.43 tagged_above=-999 required=5 tests=[AWL=-0.681, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4CT3X0+zL4t for ; Mon, 15 Jun 2009 13:49:37 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 548613A6833 for ; Mon, 15 Jun 2009 13:49:36 -0700 (PDT) X-AuditID: c1b4fb3e-b7b1dae000006c99-28-4a36b3e98b48 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 16.22.27801.9E3B63A4; Mon, 15 Jun 2009 22:49:45 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jun 2009 22:49:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 22:49:44 +0200 Message-ID: In-Reply-To: <4A36B1A2.6040407@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: Acnt+XiKTHT03LUaT4OI8n78/WFudQAAP8Ug References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! <4A36AA56 .2000600@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DBEA@zrc2hxm0.corp.nortel.com> <4A36B1A2.6040407@gmail.com> From: "Christer Holmberg" To: "Hans Erik van Elburg" , "Mary Barnes" X-OriginalArrivalTime: 15 Jun 2009 20:49:44.0844 (UTC) FILETIME=[D0432CC0:01C9EDFA] X-Brightmail-Tracker: AAAAAA== Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 20:49:38 -0000 So, if we decided upon the alias separation, could we use Hans Erik's earlier proposal as base? We would then modify it so that it covers the alias separation. But, I agree with Hans Erik that we should have some requirement/scenario which is covered, to show people why it is useful to implement.=20 Regards, Christer -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Monday, June 15, 2009 11:40 PM To: Mary Barnes Cc: Christer Holmberg; Francois Audet; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Ok, so this is a 4244bis requirement, not a target-uri requirement.=20 Thats fine. i have no problem with covering that, but Id like to be explicit on what requirement we are covering when. BR, /Hans Erik Mary Barnes wrote: > Debug/diagnostics - we've talked about this from day 1.=20 > > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Monday, June 15, 2009 3:09 PM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Audet, Francois (SC100:3055); DOLLY, MARTIN C,=20 > ATTLABS; sipcore@ietf.org > Subject: Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > I think this is a new requirement. > > 4244bis has introduced this distinction, so maybe you have a some=20 > requirement in mind. > Maybe you can explain why it is needed? > > /Hans Erik > > Mary Barnes wrote: > =20 >> But, still with this approach, I do not think you can get away with=20 >> not looking for multiple tags with the way you envision doing your >> =20 > services. > =20 >> I think there are others that will implement services on the UAS that >> will not need the differentiation that you do - i.e, they care about=20 >> the difference between "reg-uri" and "reg-uri-alias". >> >> Mary.=20 >> >> -----Original Message----- >> From: Barnes, Mary (RICH2:AR00) >> Sent: Monday, June 15, 2009 2:53 PM >> To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN=20 >> C, ATTLABS; sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Christer, >> >> On your last point, the objective here was to make use of=20 >> History-Info >> =20 > > =20 >> WITHOUT changing any core SIP functionality - it's a whole different=20 >> ballgame if we want to do the latter IMHO. However, here's the=20 >> snippet >> =20 > > =20 >> from the end of the response I just sent to Martin (summarizing the=20 >> current set of tags), which you may not read: >> >> " So, we're debating here the differences between the "aor,mapped"=20 >> and >> =20 > > =20 >> "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I=20 >> think that "reg-uri-alias" and "reg-uri" are equivalent to "aor, >> =20 > routed". > =20 >> And, I think one could consider the "aor,mapped" as predetermined.=20 >> But, again 4244bis tags the entries entirely based on what SIP does=20 >> and if the 800 number translations (or whatever services) are setup=20 >> differently in different proxies, then you can't determine if the=20 >> "aor,routed" cases might be "reg-uri-alias" or "reg-uri". Although,=20 >> I >> =20 > > =20 >> am personally confused as to whether an 800 number would always be=20 >> "aor, mapped" or "aor, routed" - i.e., I just don't see this being=20 >> deterministic and I think that if a service can reach a UAS through=20 >> different SIP retargeting mechanisms, then the UAS needs to be aware. >> >> Also, as I'm going through this, I think we need 3 more tags if we=20 >> want the proxy to do the tagging - i.e., I think we need to add "-aor" >> =20 > > =20 >> to the "predetermined", "reg-uri" and "reg-uri-alias" IF we agree=20 >> that >> =20 > > =20 >> the proxy will mark in this manner. " >> >> >> Mary.=20 >> P.S. Also, I do not think it's a burden to put logic in the UAS -=20 >> that >> =20 > > =20 >> was the original intent for SIP - services in the endpoints - SIP is=20 >> just the signalling to carry the relevant information. But, I can see >> that since the sort of service you mention that does not have a=20 >> standard SIP URI (i.e., user@domain) introduces something that isn't=20 >> accomodated in the basic SIP model, so we may need to add additional=20 >> logic to the proxies (I don't like it though). >> >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Monday, June 15, 2009 2:34 PM >> To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,=20 >> MARTIN C, ATTLABS; sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> Hi, >> >> =20 >> =20 >>> Correct. But, what I am suggesting is that you distinguish it at the >>> =20 >>> =20 >> UAS >> =20 >> =20 >>> - I'm assuming that the target Request-URI that arrives at the UAS=20 >>> is >>> =20 >>> =20 >> something that identifies a client that handles 800 numbers. That=20 >> client could be configured such that it knows to look for the >> =20 >> =20 >>> original 800 number in the mapped URIs or in the reg-alias-URIs or >>> =20 >>> =20 >> both.=20 >> >> 800 numbers is just one example.=20 >> >> Why should the UAS have to be configured with this information??? I=20 >> think that is very limiting and unpractical. >> >> =20 >> =20 >>> Again, if you're making these 800 numbers special and allowing=20 >>> proxies >>> =20 >>> =20 >> to change them in multiple ways (i.e., non-deterministic), then if=20 >> you >> =20 > > =20 >> want them tagged special, then you need special logic in the >> =20 >> =20 >>> proxies to do this. >>> =20 >>> =20 >> The logic is that the AOR is replaced with another AOR, which belongs >> to the same user. >> >> It's not only for 800 numbers - they are just an example where it=20 >> would be useful. >> >> And, the proxy is configured to do this - it doesn't do it because=20 >> it >> =20 > > =20 >> "thinks" it has to do it :) >> >> =20 >> =20 >>> That doesn't make sense to me, although you could do it that way in=20 >>> a >>> =20 >>> =20 >> closed network, in which case you can make sure to always tag them as >> whatever you think they should be - so we could define an >> =20 >> =20 >>> additional value for the tag. But, this is what I don't think is=20 >>> right >>> =20 >>> =20 >> in terms of normal SIP request routing and forwarding, which is what=20 >> the current 4244bis tags have been defined to represent. >> >> I really don't understand wht this "normal SIP request routing and=20 >> forwarding" is all about. Normal SIP request routing and forwarding=20 >> has issues, which were presented in the ua-loose-route draft - and=20 >> that is why we are now working on a solution to solve those issues. >> >> Regards, >> >> Christer >> >> >> >> >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Monday, June 15, 2009 1:23 PM >> To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,=20 >> MARTIN C, ATTLABS; sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> >> Hi Mary, >> >> Proxies will tag entries based on the functionality they perform. >> >> Let's leave req-uri-alias for the moment. >> >> As I said earlier, one of the issues we have with 4244bis, is that=20 >> "mapped" seems to be used BOTH for diversion and when an AOR is=20 >> replaced with another AOR pointing to the same user - e.g. freephone. >> So, it is not possible to distinguish between diversion and freephone. >> >> We think one MUST be able to make that distinguishment, because you=20 >> may have cases where both diversion and service number translation >> =20 > (e.g. > =20 >> freephone) occurs, and the UAS needs to know which is which. >> >> Regards, >> >> Christer >> >> >> >> >> >> =20 >> >> -----Original Message----- >> From: Mary Barnes [mailto:mary.barnes@nortel.com] >> Sent: Monday, June 15, 2009 9:13 PM >> To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;=20 >> sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> It seems to me that the gist of this discussion has been based on the >> expectation that independent of how the 800 number is configured,=20 >> registered or whatever at a proxy, that there is an expectation of=20 >> deterministic behavior in terms of how it's tagged. So, if 800=20 >> numbers are special and they can end up tagged as either=20 >> reg-uri-alias >> =20 > > =20 >> or as mapped, then perhaps the service has to know that it needs to=20 >> look for either of those. ISTM that if there is a reason to preserve=20 >> that it's an 800 number (i.e., and not format as a service specific=20 >> uri), the service at the UAS knows that it's special, thus it would=20 >> need to check the request-URIs associated with both reg-uri-alias and >> =20 > mapped hi-entries. > =20 >> I can't see how we can make it work any other way without being=20 >> prescriptive of how proxy's MUST tag these entries, which is not a=20 >> good idea IMHO. However, I think these numbers are either special=20 >> cases at proxies or something that services know about. >> >> Mary.=20 >> >> -----Original Message----- >> From: Audet, Francois (SC100:3055) >> Sent: Monday, June 15, 2009 12:47 PM >> To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary=20 >> (RICH2:AR00); sipcore@ietf.org >> Subject: RE: [sipcore] FW: I-D >> Action:draft-barnes-sipcore-rfc4244bis-01.txt >> >> Yes, we need to sort out what to do for that.=20 >> >> =20 >> =20 >>> -----Original Message----- >>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>> Sent: Monday, June 15, 2009 10:17 >>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 >>> Mary (RICH2:AR00); sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> >>> But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 >>> >>> -----Original Message----- >>> From: Francois Audet [mailto:audet@nortel.com] >>> Sent: Monday, June 15, 2009 6:50 PM >>> To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 >>> sipcore@ietf.org >>> Subject: RE: [sipcore] FW: I-D >>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>> >>> then reg-uri-alias.=20 >>> >>> =20 >>> =20 >>>> -----Original Message----- >>>> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >>>> Sent: Saturday, June 13, 2009 01:22 >>>> To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes, >>>> Mary (RICH2:AR00); sipcore@ietf.org >>>> Subject: RE: [sipcore] FW: I-D >>>> Action:draft-barnes-sipcore-rfc4244bis-01.txt >>>> >>>> >>>> Hi, >>>> >>>> =20 >>>> =20 >>>>> 1) RFC 4244bis >>>>> >>>>> In RFC 4244bis, if the domain is responsible for the URI in the >>>>> =20 >>>>> =20 >>>> Request-URI and it replacing it with a Contact, it will put >>>> =20 >>>> =20 >>> a reg-uri >>> =20 >>> =20 >>>> flag (if the Request-URI was the AOR used for registration), or=20 >>>> reg- >>>> =20 >>>> =20 >>>>> uri-alias (if the Request-URI was an alias for the AOR used in >>>>> =20 >>>>> =20 >>>> registration). >>>> >>>> And if the Request-URI was a "synonym" for the AOR? >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> =20 >>>> =20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> =20 >> =20 From mdolly@att.com Mon Jun 15 14:10:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28E7D28C110 for ; Mon, 15 Jun 2009 14:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.07 X-Spam-Level: X-Spam-Status: No, score=-105.07 tagged_above=-999 required=5 tests=[AWL=-0.971, BAYES_00=-2.599, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bghJ3MgPv9J for ; Mon, 15 Jun 2009 14:10:10 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 9E87E3A6812 for ; Mon, 15 Jun 2009 14:10:10 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-3.tower-161.messagelabs.com!1245100208!10830412!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 20477 invoked from network); 15 Jun 2009 21:10:08 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-3.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Jun 2009 21:10:08 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5FLA8DO012465 for ; Mon, 15 Jun 2009 17:10:08 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5FLA5DY012452 for ; Mon, 15 Jun 2009 17:10:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 17:10:02 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA0375EC26@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83DBEB@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYAAADaOvAAAEZYIAAAZd2gAAEEtLAAASSLAA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>! <1ECE0EB50388174790F9694F77522CCF1E83DBEB@zrc2hxm0.corp.nortel.com> From: "DOLLY, MARTIN C, ATTLABS" To: "Mary Barnes" , "Christer Holmberg" , "Francois Audet" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 21:10:12 -0000 no -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: Monday, June 15, 2009 4:38 PM To: Christer Holmberg; Francois Audet; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt But, the freephone service can be implemented also with a reg-uri or reg-uri-alias - NOW if a specific service treats them the same, no big deal. The UAS then looks for any of a set of tags to grab the appropriate hi-entry.=20 Mary. -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Monday, June 15, 2009 3:14 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi,=20 >But, still with this approach, I do not think you can get away with not looking for multiple tags with the way you envision doing your services. Maybe not - that depends on the service. But, then it will at least be possible to figure out what has happended. >I think there are others that will implement services on the UAS that will not need the differentiation that you do - i.e, they care about the difference between "reg-uri" and "reg-uri-alias". My differentiation is based on my understanding of the requirements that we have. If you think we need to differentiate between req-uri and req-uri-alias, then we should agree on such requirement. Let's not mix it with the freephone requirement. Regards, Christer -----Original Message----- From: Barnes, Mary (RICH2:AR00) Sent: Monday, June 15, 2009 2:53 PM To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Christer,=20 On your last point, the objective here was to make use of History-Info WITHOUT changing any core SIP functionality - it's a whole different ballgame if we want to do the latter IMHO. However, here's the snippet from the end of the response I just sent to Martin (summarizing the current set of tags), which you may not read: " So, we're debating here the differences between the "aor,mapped" and "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I think that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed". And, I think one could consider the "aor,mapped" as predetermined. But, again 4244bis tags the entries entirely based on what SIP does and if the 800 number translations (or whatever services) are setup differently in different proxies, then you can't determine if the "aor,routed" cases might be "reg-uri-alias" or "reg-uri". Although, I am personally confused as to whether an 800 number would always be "aor, mapped" or "aor, routed" - i.e., I just don't see this being deterministic and I think that if a service can reach a UAS through different SIP retargeting mechanisms, then the UAS needs to be aware.=20 Also, as I'm going through this, I think we need 3 more tags if we want the proxy to do the tagging - i.e., I think we need to add "-aor" to the "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that the proxy will mark in this manner. " Mary.=20 P.S. Also, I do not think it's a burden to put logic in the UAS - that was the original intent for SIP - services in the endpoints - SIP is just the signalling to carry the relevant information. But, I can see that since the sort of service you mention that does not have a standard SIP URI (i.e., user@domain) introduces something that isn't accomodated in the basic SIP model, so we may need to add additional logic to the proxies (I don't like it though).=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 15, 2009 2:34 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi,=20 >Correct. But, what I am suggesting is that you distinguish it at the UAS >- I'm assuming that the target Request-URI that arrives at the UAS is something that identifies a client that handles 800 numbers. That client could be configured such that it knows to look for the=20 >original 800 number in the mapped URIs or in the reg-alias-URIs or both.=20 800 numbers is just one example.=20 Why should the UAS have to be configured with this information??? I think that is very limiting and unpractical. >Again, if you're making these 800 numbers special and allowing proxies to change them in multiple ways (i.e., non-deterministic), then if you want them tagged special, then you need special logic in the=20 >proxies to do this. The logic is that the AOR is replaced with another AOR, which belongs to the same user.=20 It's not only for 800 numbers - they are just an example where it would be useful. And, the proxy is configured to do this - it doesn't do it because it "thinks" it has to do it :) >That doesn't make sense to me, although you could do it that way in a closed network, in which case you can make sure to always tag them as whatever you think they should be - so we could define an=20 >additional value for the tag. But, this is what I don't think is right in terms of normal SIP request routing and forwarding, which is what the current 4244bis tags have been defined to represent.=20 I really don't understand wht this "normal SIP request routing and forwarding" is all about. Normal SIP request routing and forwarding has issues, which were presented in the ua-loose-route draft - and that is why we are now working on a solution to solve those issues. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 15, 2009 1:23 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi Mary, Proxies will tag entries based on the functionality they perform. Let's leave req-uri-alias for the moment. As I said earlier, one of the issues we have with 4244bis, is that "mapped" seems to be used BOTH for diversion and when an AOR is replaced with another AOR pointing to the same user - e.g. freephone. So, it is not possible to distinguish between diversion and freephone. We think one MUST be able to make that distinguishment, because you may have cases where both diversion and service number translation (e.g. freephone) occurs, and the UAS needs to know which is which. Regards, Christer =20 -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Monday, June 15, 2009 9:13 PM To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt It seems to me that the gist of this discussion has been based on the expectation that independent of how the 800 number is configured, registered or whatever at a proxy, that there is an expectation of deterministic behavior in terms of how it's tagged. So, if 800 numbers are special and they can end up tagged as either reg-uri-alias or as mapped, then perhaps the service has to know that it needs to look for either of those. ISTM that if there is a reason to preserve that it's an 800 number (i.e., and not format as a service specific uri), the service at the UAS knows that it's special, thus it would need to check the request-URIs associated with both reg-uri-alias and mapped hi-entries. I can't see how we can make it work any other way without being prescriptive of how proxy's MUST tag these entries, which is not a good idea IMHO. However, I think these numbers are either special cases at proxies or something that services know about.=20 Mary.=20 -----Original Message----- From: Audet, Francois (SC100:3055) Sent: Monday, June 15, 2009 12:47 PM To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Yes, we need to sort out what to do for that.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 10:17 > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 >=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, June 15, 2009 6:50 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > then reg-uri-alias.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Saturday, June 13, 2009 01:22 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > >1) RFC 4244bis > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > Request-URI and it replacing it with a Contact, it will put > a reg-uri > > flag (if the Request-URI was the AOR used for registration), or reg- > > >uri-alias (if the Request-URI was an alias for the AOR used in > > registration). > >=20 > > And if the Request-URI was a "synonym" for the AOR? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 >=20 From AUDET@nortel.com Mon Jun 15 18:43:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7DC3A69F6 for ; Mon, 15 Jun 2009 18:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9q-IvqwHbTo for ; Mon, 15 Jun 2009 18:43:56 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 239053A68DB for ; Mon, 15 Jun 2009 18:43:55 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5G1hoI13463; Tue, 16 Jun 2009 01:43:50 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Jun 2009 20:43:45 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri thread-index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFA= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! <4A36A C9C.3060509@ gmail.com> From: "Francois Audet" To: "Christer Holmberg" , "Hans Erik van Elburg" , "Mary Barnes" , "Shida Schubert" Cc: sipcore@ietf.org Subject: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 01:43:57 -0000 All right guys, I've been thinking about this. It seems to me that what we want to capture is: 1) If the target is an AOR, a contact, or a routing URI (maddr, noop = intra-domain, or noop forward to next domain, or strict routing). 2) In the case that the target is an AOR, then if that AOR is known to = be an alias for the previous one, or if it is mapped to another AOR. It seems to me that a Proxy should mark a Previous entry in H-I with aor = if it determines that it=20 owns this AOR. Just as Hans's current target-uri draft. Now, for the mapped vs routed (versus reg-contact, etc.), instead of = marking the Previous entry, we should mark the OUTGOING (i.e., New) entry instead. This would make = the procedures of 7.2.1 & 7.2.2 of target-URI draft clearer. Specifically, the logic would be: When proxy receives an incoming request with H-I, it adds an ;aor tag to = that incoming entry if it determines that it is responsible for the AOR and.=20 Also, if there was no Hi-entry at all (i.e., it came from a UAC), and = the Proxy creates=20 then two entries, the first one in this case would also have the ;aor = tag associated to it. For the Outgoing entry, I would see the following tags: rc : The entry is an explicit registered contact (i.e., it was provided = in a REGISTER message) ic : The entry is an implicit registered contact (i.e., it's exactly as = a registered contact, but was not discovered using SIP Registration: it could have been = manually configured or done with a proprietary mechanism). (TBD: we could debate if we need both rc and irc, but I think we do). mp : The request-URI is changed to a new URI that represent another = user. rt : The entry is "routed", i.e., it is either a no-opt like a proxy = forwarding within a domain, predetermined by a maddr in the Request-URI, or when proxy = is NOT responsible for domain, or the address is an alias for the incoming URI. So, to give an example.=20 Say Alice calls Bob. Bob is forwarded to freephone. Freephone routes to = Carol.=20 The History-info at Carol would look like this: Alice -> example.com Nothing because UAC typically doesn't send H-I (otherwise, it would be as per Index 1 in next entry, but without the AOR. example.com -> freephone@example.net History-Info: ;index=3D1;aor History-Info: ;index=3D1.1;mp example.net -> carol@example.net History-Info: ;index=3D1;aor =20 History-Info: ;index=3D1.1;mp;aor <- aor is = added History-Info: ;index=3D1.1.1;rt;aor } Two = entries are History-Info: ;index=3D1.1.1.1;rc } added = at same time Also, I don't think we need to define an equivalent to the = "reg-uri-alias" anymore. If Freephone was configured to go to +14085551212 instead of the = registered Contact (assuming +14085551212 was an Alias AOR for carol@example.net), the last = H-I entries would look like this instead: example.net -> carol@example.net History-Info: ;index=3D1;aor =20 History-Info: = ;index=3D1.1;mp;aor <- aor is = added=20 History-Info: ;index=3D1.1.1;rt;aor <- aor = is added History-Info: ;index=3D1.1.1.1;rt;aor } Two = entries are History-Info: ;index=3D1.1.1.1.1;rc } added = at same time From dean.willis@softarmor.com Mon Jun 15 21:58:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965C53A684A for ; Mon, 15 Jun 2009 21:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6VY4EWJwtey for ; Mon, 15 Jun 2009 21:58:42 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 90F883A6830 for ; Mon, 15 Jun 2009 21:58:42 -0700 (PDT) Received: from [192.168.2.102] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n5G4wHgo027197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Jun 2009 23:58:19 -0500 Message-ID: <4A37266A.7050504@softarmor.com> Date: Mon, 15 Jun 2009 23:58:18 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <4A340ACE.1070803@cisco.com> <4A3413DC.208@gmail.com> <4A341B74.2070300@cisco.com> <4A34A9D2.7090509@gmail.com> <4A356B81.3030906@cisco.com> In-Reply-To: <4A356B81.3030906@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 04:58:43 -0000 Paul Kyzivat wrote: > For instance, does it really make sense for you to call me, and for me > to then divert you to an 800 number? If so, is that supposed to behave > as if you had called the 800 number? Yes. I do this on a fairly regular basis. It's a way to get my inbound SIP calls forwarded to a free-phone number that's billed differently than my SIP gateway service is. I sometimes se it to get US toll-free access when calling from Europe. I set my in-country SIP-provider number to forward to the US 800 number I need to reach, make the GSTN call to the in-country local number, and get routed to the US 800 number call center as desired. Oddly enough, this all works without H-I. -- Dean From R.Jesske@telekom.de Mon Jun 15 22:01:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B1B93A6830 for ; Mon, 15 Jun 2009 22:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.551 X-Spam-Level: * X-Spam-Status: No, score=1.551 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_LOAN=2.3, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRRU9tRWpooP for ; Mon, 15 Jun 2009 22:01:24 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 1AAB43A6805 for ; Mon, 15 Jun 2009 22:01:23 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 16 Jun 2009 07:01:29 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 07:01:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 07:01:30 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD404827AB8@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0375EC26@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYAAADaOvAAAEZYIAAAZd2gAAEEtLAAASSLAAAQUjFA References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com><1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>!<1ECE0EB50388174790F9694F77522CCF1E83DBEB@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA0375EC26@gaalpa1msgusr7e.ugd.att.com> From: To: , , , , X-OriginalArrivalTime: 16 Jun 2009 05:01:29.0400 (UTC) FILETIME=[82592380:01C9EE3F] Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 05:01:26 -0000 Hi, Why not to adopt the cause-parameter principle of RFC 4458 and extend it = for other service approaches. The have a general cause-param for services other then call diversion = and to have explicit cause parameters for free phone, "IN-services", = calling card ect. Such indications where asked a couples of times from other service = providers. BR, Roland=20 -----Urspr=FCngliche Nachricht----- Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im = Auftrag von DOLLY, MARTIN C, ATTLABS Gesendet: Montag, 15. Juni 2009 23:10 An: Mary Barnes; Christer Holmberg; Francois Audet; sipcore@ietf.org Betreff: Re: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt no -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: Monday, June 15, 2009 4:38 PM To: Christer Holmberg; Francois Audet; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt But, the freephone service can be implemented also with a reg-uri or reg-uri-alias - NOW if a specific service treats them the same, no big deal. The UAS then looks for any of a set of tags to grab the appropriate hi-entry.=20 Mary. -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Monday, June 15, 2009 3:14 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi,=20 >But, still with this approach, I do not think you can get away with not looking for multiple tags with the way you envision doing your services. Maybe not - that depends on the service. But, then it will at least be possible to figure out what has happended. >I think there are others that will implement services on the UAS that will not need the differentiation that you do - i.e, they care about the difference between "reg-uri" and "reg-uri-alias". My differentiation is based on my understanding of the requirements that we have. If you think we need to differentiate between req-uri and req-uri-alias, then we should agree on such requirement. Let's not mix it with the freephone requirement. Regards, Christer -----Original Message----- From: Barnes, Mary (RICH2:AR00) Sent: Monday, June 15, 2009 2:53 PM To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Christer,=20 On your last point, the objective here was to make use of History-Info WITHOUT changing any core SIP functionality - it's a whole different ballgame if we want to do the latter IMHO. However, here's the snippet from the end of the response I just sent to Martin (summarizing the current set of tags), which you may not read: " So, we're debating here the differences between the "aor,mapped" and "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I think that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed". And, I think one could consider the "aor,mapped" as predetermined. But, again 4244bis tags the entries entirely based on what SIP does and if the 800 number translations (or whatever services) are setup differently in different proxies, then you can't determine if the "aor,routed" cases might be "reg-uri-alias" or "reg-uri". Although, I am personally confused as to whether an 800 number would always be "aor, mapped" or "aor, routed" - i.e., I just don't see this being deterministic and I think that if a service can reach a UAS through different SIP retargeting mechanisms, then the UAS needs to be aware.=20 Also, as I'm going through this, I think we need 3 more tags if we want the proxy to do the tagging - i.e., I think we need to add "-aor" to the "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that the proxy will mark in this manner. " Mary.=20 P.S. Also, I do not think it's a burden to put logic in the UAS - that was the original intent for SIP - services in the endpoints - SIP is just the signalling to carry the relevant information. But, I can see that since the sort of service you mention that does not have a standard SIP URI (i.e., user@domain) introduces something that isn't accomodated in the basic SIP model, so we may need to add additional logic to the proxies (I don't like it though).=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 15, 2009 2:34 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi,=20 >Correct. But, what I am suggesting is that you distinguish it at the UAS >- I'm assuming that the target Request-URI that arrives at the UAS is something that identifies a client that handles 800 numbers. That client could be configured such that it knows to look for the=20 >original 800 number in the mapped URIs or in the reg-alias-URIs or both.=20 800 numbers is just one example.=20 Why should the UAS have to be configured with this information??? I think that is very limiting and unpractical. >Again, if you're making these 800 numbers special and allowing proxies to change them in multiple ways (i.e., non-deterministic), then if you want them tagged special, then you need special logic in the=20 >proxies to do this. The logic is that the AOR is replaced with another AOR, which belongs to the same user.=20 It's not only for 800 numbers - they are just an example where it would be useful. And, the proxy is configured to do this - it doesn't do it because it "thinks" it has to do it :) >That doesn't make sense to me, although you could do it that way in a closed network, in which case you can make sure to always tag them as whatever you think they should be - so we could define an=20 >additional value for the tag. But, this is what I don't think is right in terms of normal SIP request routing and forwarding, which is what the current 4244bis tags have been defined to represent.=20 I really don't understand wht this "normal SIP request routing and forwarding" is all about. Normal SIP request routing and forwarding has issues, which were presented in the ua-loose-route draft - and that is why we are now working on a solution to solve those issues. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 15, 2009 1:23 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi Mary, Proxies will tag entries based on the functionality they perform. Let's leave req-uri-alias for the moment. As I said earlier, one of the issues we have with 4244bis, is that "mapped" seems to be used BOTH for diversion and when an AOR is replaced with another AOR pointing to the same user - e.g. freephone. So, it is not possible to distinguish between diversion and freephone. We think one MUST be able to make that distinguishment, because you may have cases where both diversion and service number translation (e.g. freephone) occurs, and the UAS needs to know which is which. Regards, Christer =20 -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Monday, June 15, 2009 9:13 PM To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt It seems to me that the gist of this discussion has been based on the expectation that independent of how the 800 number is configured, registered or whatever at a proxy, that there is an expectation of deterministic behavior in terms of how it's tagged. So, if 800 numbers are special and they can end up tagged as either reg-uri-alias or as mapped, then perhaps the service has to know that it needs to look for either of those. ISTM that if there is a reason to preserve that it's an 800 number (i.e., and not format as a service specific uri), the service at the UAS knows that it's special, thus it would need to check the request-URIs associated with both reg-uri-alias and mapped hi-entries. I can't see how we can make it work any other way without being prescriptive of how proxy's MUST tag these entries, which is not a good idea IMHO. However, I think these numbers are either special cases at proxies or something that services know about.=20 Mary.=20 -----Original Message----- From: Audet, Francois (SC100:3055) Sent: Monday, June 15, 2009 12:47 PM To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Yes, we need to sort out what to do for that.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 10:17 > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 >=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, June 15, 2009 6:50 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > then reg-uri-alias.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Saturday, June 13, 2009 01:22 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > >1) RFC 4244bis > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > Request-URI and it replacing it with a Contact, it will put > a reg-uri > > flag (if the Request-URI was the AOR used for registration), or reg- > > >uri-alias (if the Request-URI was an alias for the AOR used in > > registration). > >=20 > > And if the Request-URI was a "synonym" for the AOR? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From R.Jesske@telekom.de Mon Jun 15 22:38:03 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04573A685F for ; Mon, 15 Jun 2009 22:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=2.400, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOlYJLr1Co+n for ; Mon, 15 Jun 2009 22:38:03 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 56A903A685D for ; Mon, 15 Jun 2009 22:38:01 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 16 Jun 2009 07:38:07 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 07:38:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 07:38:08 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD404827ACF@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAEsEiwA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>!! <4A36A C9C.3060509 @ gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> From: To: , , , , X-OriginalArrivalTime: 16 Jun 2009 05:38:06.0884 (UTC) FILETIME=[A0269640:01C9EE44] Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 05:38:04 -0000 Such values looks good and gives more guideline why the entry was = included. My question would be if there is a different network behaviour foreseen = for the History mechanism. Perhaps some of the networks needs the history only to indicate where = the URI were mapped ("mp") and others would really track the whole = history of each SIP proxy. Or is it only seen either to support history full or not. BR, Roland =20 -----Urspr=FCngliche Nachricht----- Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im = Auftrag von Francois Audet Gesendet: Dienstag, 16. Juni 2009 03:44 An: Christer Holmberg; Hans Erik van Elburg; Mary Barnes; Shida Schubert Cc: sipcore@ietf.org Betreff: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri All right guys, I've been thinking about this. It seems to me that what we want to capture is: 1) If the target is an AOR, a contact, or a routing URI (maddr, noop = intra-domain, or noop forward to next domain, or strict routing). 2) In the case that the target is an AOR, then if that AOR is known to = be an alias for the previous one, or if it is mapped to another AOR. It seems to me that a Proxy should mark a Previous entry in H-I with aor = if it determines that it=20 owns this AOR. Just as Hans's current target-uri draft. Now, for the mapped vs routed (versus reg-contact, etc.), instead of = marking the Previous entry, we should mark the OUTGOING (i.e., New) entry instead. This would make = the procedures of 7.2.1 & 7.2.2 of target-URI draft clearer. Specifically, the logic would be: When proxy receives an incoming request with H-I, it adds an ;aor tag to = that incoming entry if it determines that it is responsible for the AOR and.=20 Also, if there was no Hi-entry at all (i.e., it came from a UAC), and = the Proxy creates=20 then two entries, the first one in this case would also have the ;aor = tag associated to it. For the Outgoing entry, I would see the following tags: rc : The entry is an explicit registered contact (i.e., it was provided = in a REGISTER message) ic : The entry is an implicit registered contact (i.e., it's exactly as = a registered contact, but was not discovered using SIP Registration: it could have been = manually configured or done with a proprietary mechanism). (TBD: we could debate if we need both rc and irc, but I think we do). mp : The request-URI is changed to a new URI that represent another = user. rt : The entry is "routed", i.e., it is either a no-opt like a proxy = forwarding within a domain, predetermined by a maddr in the Request-URI, or when proxy = is NOT responsible for domain, or the address is an alias for the incoming URI. So, to give an example.=20 Say Alice calls Bob. Bob is forwarded to freephone. Freephone routes to = Carol.=20 The History-info at Carol would look like this: Alice -> example.com Nothing because UAC typically doesn't send H-I (otherwise, it would be as per Index 1 in next entry, but without the AOR. example.com -> freephone@example.net History-Info: ;index=3D1;aor History-Info: ;index=3D1.1;mp example.net -> carol@example.net History-Info: ;index=3D1;aor =20 History-Info: ;index=3D1.1;mp;aor <- aor is = added History-Info: ;index=3D1.1.1;rt;aor } Two = entries are History-Info: ;index=3D1.1.1.1;rc } added = at same time Also, I don't think we need to define an equivalent to the = "reg-uri-alias" anymore. If Freephone was configured to go to +14085551212 instead of the = registered Contact (assuming +14085551212 was an Alias AOR for carol@example.net), the last = H-I entries would look like this instead: example.net -> carol@example.net History-Info: ;index=3D1;aor =20 History-Info: = ;index=3D1.1;mp;aor <- aor is = added=20 History-Info: ;index=3D1.1.1;rt;aor <- aor = is added History-Info: ;index=3D1.1.1.1;rt;aor } Two = entries are History-Info: ;index=3D1.1.1.1.1;rc } added = at same time _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From dean.willis@softarmor.com Mon Jun 15 22:52:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148123A68E0 for ; Mon, 15 Jun 2009 22:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jz1Djjgf086U for ; Mon, 15 Jun 2009 22:52:47 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4892B3A6830 for ; Mon, 15 Jun 2009 22:52:47 -0700 (PDT) Received: from [192.168.2.102] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n5G5qpD6027574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Jun 2009 00:52:52 -0500 Message-ID: <4A37332D.2070401@softarmor.com> Date: Tue, 16 Jun 2009 00:52:45 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <4A340ACE.1070803@cisco.com> <1ECE0EB50388174790F9694F77522CCF1E83D36A@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83D36A@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] The functional differences between 4244bis and target- uri (was FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 05:52:48 -0000 Francois Audet wrote: > Perhaps you are correct. > > I must admit I'm having trouble understanding the sutleties of the freephone service. > It's not that complicated. Think of it as an AOR (the freephone number) to which a contact (the service nuumber) is registered. Unfortunately, said contact is also registered to other AORs, and the B2BUA that terminates the call needs to know which AOR was used so it can figure out 1) how to bill for the call, and 2) how to route the call within the call center and what to display on the UAS. My proposal: This is an obtuse legacy. Don't build SIP-based systems on the same model; contacts are cheap, locally-mintable, and you can use a different one for every AOR. If you THINK you have a freephone problem that needs a specification extension to deal with it, you probably just have a badly designed deployment. Rethink the problem without forcibly holding your head in a bell shape. Remember, this is not your mother's phone network. -- Dean From dean.willis@softarmor.com Mon Jun 15 23:49:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88E0C28C174 for ; Mon, 15 Jun 2009 23:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yrq+H99yHpkc for ; Mon, 15 Jun 2009 23:49:09 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5D08128C170 for ; Mon, 15 Jun 2009 23:49:09 -0700 (PDT) Received: from [192.168.2.102] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n5G6n0x1027875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 16 Jun 2009 01:49:01 -0500 Message-ID: <4A374056.6050001@softarmor.com> Date: Tue, 16 Jun 2009 01:48:54 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "sipcore@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] Another approach to preservation of targeting information on a proxy-rewrite of request URI (Request URI Replacement) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 06:49:10 -0000 Poxies sometimes replace an incoming request-URI with another request-URI. I'll cal this operation a "Request-URI Replacement", or RUR for now. Note that this should not be confused with an RUS, or "Rodent of Unusal Size", which is an entirely different order of pest, although I understand that both are likely to carry the fleas that spread plague. Some of our discussion threads (and drafts) seem to be bogged down on the "whys" and "what kind of URI was that" discussion. For example, was that RUR caused by an aliasing operation (replacement of one AOR with another) or a contact-routing operation (replacement of an AOR with a contact). We also have a "and WHY did we do this" discussion, that includes such potential excuses as "The previous number was busy", "the previous number forwrded to this number", "I found a registration that sort-of matched", and "The devil made me do it." This whole family of argument assumes that we have different kinds of URIs, different kinds of replacement operations, and different reasons for doing replacements. Further, it presumes that each of these sets of things is finite, bounded, and definable in a standardized, interoperable way, and that the proxy performing the RUR intimately understands the full gamut of possibilities and therefore ay encode the new URI, its type, and its causality in a universally standard way that will be understood by the UAS. Although I've previously offered to model wherein RUR operations can be classified as "retargeting" vs "rerouting" based on the continuity of response-identity across the RUR (retargets change response identity, reroutes don't), I'm not sure I believe any of the other above presumptions about RUR discriminations to be demonstrably true. And I'm not sure we need them anyhow. I'm especially not sure that I believe that there is a finite and well-definable set of "why" operations that can be used to forward-explain all possible service logics. But I am certain that there are use-cases for which a UAS supports multiple identities and needs to know which identity applies to a received request. One approach is to assign each UAS a discrete URI for each identity. Then if an upstream proxy does an RUR, the UAS can work backwards from the resulting request-URI in order to figure out which identity is being targeted. This is exactly how we have always thought of a multi-user UAS, which typiclaly uses a set of URIs where the right-hand-side is the host name or address and the left-hand-side is the identity discriminator: for example "sip:ext1@gateway.example.com" vs "sip:ext2@gateway.example.org". or "sip:alice@pbx.example.org" vs. "sip:bib@pbx.example.org" This model works nicely for lots of cases. For example, it can support proxies that do RUR based on configuration tables, dynamic registration, business policy matching, TRIP aggregation, etc. All it requires is that the UAS support multiple URIs and be able to distinguish between them. Some people would argue that it 1) requires that each UAS be provisioned with the entire possible set of request-URIs, or that this would result in very large registration databases. Again, I'm not sure I completely buy this. We could also encode the replaced URI into the new URI in a "You can throw this away if you don't understand it" sort of way by using a URI parameter appended to the r-URI resulting from the RUR. For example, A proxy receiving a request for "sip:alice@example.com" might replace that URI with "sip@line1@192.168.1.1;rur=sip:alice@example.com" If Alice's UAS (which she might share with Bob) understands the RUR header field encoded in the r-URI, it can make up its own mind about the translation type and how to render the request URI. A nesting syntax should allow quite elaborate constructions. This approach simplifies proxy operation by taking the proxy out of the provisioning and translation loops as much as possible. The proxy doens't know whether a given RUR is a retarget or a reroute; all it knows is that the pre-RUR URI is appended to the post-RUR URI in a fixed manner. The UAS can, if it cares, deal with the implications. So what else do we really need and understand well enough to quantify without arguing about it until the end of time? -- Dean From christer.holmberg@ericsson.com Tue Jun 16 00:40:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 683223A69B9 for ; Tue, 16 Jun 2009 00:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.652 X-Spam-Level: X-Spam-Status: No, score=-5.652 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlL7-8GJqQz7 for ; Tue, 16 Jun 2009 00:40:57 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id DA2503A659C for ; Tue, 16 Jun 2009 00:40:56 -0700 (PDT) X-AuditID: c1b4fb3c-b7b0bae00000673a-36-4a374c1c1e6b Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 1E.A6.26426.C1C473A4; Tue, 16 Jun 2009 09:39:09 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 09:38:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 09:38:56 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAFn+ocA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! <4A3 6AC9C.306050 9@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , "Hans Erik van Elburg" , "Mary Barnes" , "Shida Schubert" X-OriginalArrivalTime: 16 Jun 2009 07:38:57.0989 (UTC) FILETIME=[82256750:01C9EE55] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 07:40:58 -0000 Hi Francois, "rc" and "ic" look rather ok. But, for "ic" you need to change "but was = not discovered using SIP Registration", because you may discover it = using the P-Associated-URI header (if you support it). So, I propose = something like: ic : The entry is an implicit registered contact (i.e., it's exactly as = a registered contact, but was not provided in a REGISTER request: it could have been = manually configured or done with a proprietary mechanism). But, I think there is a small missunderstading for the AOR-to-AOR cases. We don't think you need to know whether the new AOR is an alias or not. = You need to know whether the new AOR belongs to the same user or not. So, in case of diversion, where the user is changed, I assume "mp" is = used. For freephone, where the user is not changed, one could use "rt". But, I = don't think it matters in which domain the translation takes place, or = whether the new AOR is an alias or not. So, my proposal would be something like: rt : The entry is "routed", i.e., it is either a no-opt like a proxy = forwarding within a domain, predetermined by a maddr in the Request-URI, or when the = request-URI is changed to a new URI that represent the same user. Regards, Christer =20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: 16. kes=E4kuuta 2009 4:44 > To: Christer Holmberg; Hans Erik van Elburg; Mary Barnes;=20 > Shida Schubert > Cc: sipcore@ietf.org > Subject: draft-barnes-sipcore-rfc4244bis and target-uri >=20 > All right guys, >=20 > I've been thinking about this. >=20 > It seems to me that what we want to capture is: > 1) If the target is an AOR, a contact, or a routing URI=20 > (maddr, noop intra-domain, or noop > forward to next domain, or strict routing). > 2) In the case that the target is an AOR, then if that AOR is=20 > known to be an alias for the previous > one, or if it is mapped to another AOR. >=20 > It seems to me that a Proxy should mark a Previous entry in=20 > H-I with aor if it determines that it owns this AOR. Just as=20 > Hans's current target-uri draft. >=20 > Now, for the mapped vs routed (versus reg-contact, etc.),=20 > instead of marking the Previous entry, we should mark the=20 > OUTGOING (i.e., New) entry instead. This would make the procedures of > 7.2.1 & 7.2.2 of target-URI draft clearer. >=20 > Specifically, the logic would be: >=20 > When proxy receives an incoming request with H-I, it adds an=20 > ;aor tag to that incoming entry if it determines that it is=20 > responsible for the AOR and.=20 >=20 > Also, if there was no Hi-entry at all (i.e., it came from a=20 > UAC), and the Proxy creates then two entries, the first one=20 > in this case would also have the ;aor tag associated to it. >=20 > For the Outgoing entry, I would see the following tags: >=20 > rc : The entry is an explicit registered contact=20 > (i.e., it was provided in a REGISTER message) >=20 > ic : The entry is an implicit registered contact=20 > (i.e., it's exactly as a registered contact, > but was not discovered using SIP Registration:=20 > it could have been manually configured > or done with a proprietary mechanism). >=20 > (TBD: we could debate if we need both rc and=20 > irc, but I think we do). >=20 > mp : The request-URI is changed to a new URI that=20 > represent another user. >=20 > rt : The entry is "routed", i.e., it is either a=20 > no-opt like a proxy forwarding within > a domain, predetermined by a maddr in the=20 > Request-URI, or when proxy is NOT responsible > for domain, or the address is an alias for the=20 > incoming URI. >=20 > So, to give an example.=20 >=20 > Say Alice calls Bob. Bob is forwarded to freephone. Freephone=20 > routes to Carol.=20 >=20 > The History-info at Carol would look like this: >=20 > Alice -> example.com > Nothing because UAC typically doesn't send H-I (otherwise, it=20 > would be as per Index 1 in next entry, but without the AOR. >=20 > example.com -> freephone@example.net > History-Info: ;index=3D1;aor > History-Info: ;index=3D1.1;mp >=20 > example.net -> carol@example.net > History-Info: ;index=3D1;aor =20 > History-Info: ;index=3D1.1;mp;aor =20 > <- aor is added > History-Info: ;index=3D1.1.1;rt;aor }=20 > Two entries are > History-Info: ;index=3D1.1.1.1;rc }=20 > added at same time >=20 > Also, I don't think we need to define an equivalent to the=20 > "reg-uri-alias" anymore. > If Freephone was configured to go to +14085551212 instead of=20 > the registered Contact (assuming +14085551212 was an Alias=20 > AOR for carol@example.net), the last H-I entries would look=20 > like this instead: >=20 > example.net -> carol@example.net > History-Info: ;index=3D1;aor =20 > History-Info:=20 > ;index=3D1.1;mp;aor <-=20 > aor is added > History-Info: ;index=3D1.1.1;rt;aor =20 > <- aor is added > History-Info: ;index=3D1.1.1.1;rt;aor =20 > } Two entries are > History-Info: ;index=3D1.1.1.1.1;rc =20 > } added at same time >=20 From hanserik.van.elburg@ericsson.com Tue Jun 16 00:53:00 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0F273A6A17 for ; Tue, 16 Jun 2009 00:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2ZK206GPB8l for ; Tue, 16 Jun 2009 00:53:00 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 820263A6C7E for ; Tue, 16 Jun 2009 00:52:59 -0700 (PDT) X-AuditID: c1b4fb3e-b7b1dae000006c99-6b-4a374f521be1 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 66.FD.27801.25F473A4; Tue, 16 Jun 2009 09:52:50 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 09:52:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 09:52:45 +0200 Message-ID: <7BC22A525D51C54295349A7D9D854919016FF5FD@esealmw109.eemea.ericsson.se> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAF3i9AA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! <4A3 6AC9C.306050 9@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> From: "Hans Erik van Elburg" To: "Francois Audet" , "Christer Holmberg" , "Hans Erik van Elburg" , "Mary Barnes" , "Shida Schubert" X-OriginalArrivalTime: 16 Jun 2009 07:52:47.0134 (UTC) FILETIME=[705AE3E0:01C9EE57] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 07:53:01 -0000 Hi Francois, I think this tagging of the outgoing entry might actually be a good idea. Also the tagging of the contacts seems very intuitive and clear. Also the procedure for the UAS trying to extract the adressed target will become much simpler and intuitive. I like where this is heading and I agree with Christers improvement proposals. Thanks, /Hans Erik -----Original Message----- From: Francois Audet [mailto:audet@nortel.com]=20 Sent: Tuesday, June 16, 2009 3:44 AM To: Christer Holmberg; Hans Erik van Elburg; Mary Barnes; Shida Schubert Cc: sipcore@ietf.org Subject: draft-barnes-sipcore-rfc4244bis and target-uri All right guys, I've been thinking about this. It seems to me that what we want to capture is: 1) If the target is an AOR, a contact, or a routing URI (maddr, noop intra-domain, or noop forward to next domain, or strict routing). 2) In the case that the target is an AOR, then if that AOR is known to be an alias for the previous one, or if it is mapped to another AOR. It seems to me that a Proxy should mark a Previous entry in H-I with aor if it determines that it owns this AOR. Just as Hans's current target-uri draft. Now, for the mapped vs routed (versus reg-contact, etc.), instead of marking the Previous entry, we should mark the OUTGOING (i.e., New) entry instead. This would make the procedures of 7.2.1 & 7.2.2 of target-URI draft clearer. Specifically, the logic would be: When proxy receives an incoming request with H-I, it adds an ;aor tag to that incoming entry if it determines that it is responsible for the AOR and.=20 Also, if there was no Hi-entry at all (i.e., it came from a UAC), and the Proxy creates then two entries, the first one in this case would also have the ;aor tag associated to it. For the Outgoing entry, I would see the following tags: rc : The entry is an explicit registered contact (i.e., it was provided in a REGISTER message) ic : The entry is an implicit registered contact (i.e., it's exactly as a registered contact, but was not discovered using SIP Registration: it could have been manually configured or done with a proprietary mechanism). (TBD: we could debate if we need both rc and irc, but I think we do). mp : The request-URI is changed to a new URI that represent another user. rt : The entry is "routed", i.e., it is either a no-opt like a proxy forwarding within a domain, predetermined by a maddr in the Request-URI, or when proxy is NOT responsible for domain, or the address is an alias for the incoming URI. So, to give an example.=20 Say Alice calls Bob. Bob is forwarded to freephone. Freephone routes to Carol.=20 The History-info at Carol would look like this: Alice -> example.com Nothing because UAC typically doesn't send H-I (otherwise, it would be as per Index 1 in next entry, but without the AOR. example.com -> freephone@example.net History-Info: ;index=3D1;aor History-Info: ;index=3D1.1;mp example.net -> carol@example.net History-Info: ;index=3D1;aor =20 History-Info: ;index=3D1.1;mp;aor <- aor is added History-Info: ;index=3D1.1.1;rt;aor } Two entries are History-Info: ;index=3D1.1.1.1;rc } added = at same time Also, I don't think we need to define an equivalent to the "reg-uri-alias" anymore. If Freephone was configured to go to +14085551212 instead of the registered Contact (assuming +14085551212 was an Alias AOR for carol@example.net), the last H-I entries would look like this instead: example.net -> carol@example.net History-Info: ;index=3D1;aor =20 History-Info: = ;index=3D1.1;mp;aor <- aor is added History-Info: ;index=3D1.1.1;rt;aor <- aor = is added History-Info: ;index=3D1.1.1.1;rt;aor } Two entries are History-Info: ;index=3D1.1.1.1.1;rc } added at same time From bruno.chatras@orange-ftgroup.com Tue Jun 16 03:12:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28B6B3A6AAD for ; Tue, 16 Jun 2009 03:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.551 X-Spam-Level: ** X-Spam-Status: No, score=2.551 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_LOAN=2.3, MANGLED_REGALS=2.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBrP34-dJEsN for ; Tue, 16 Jun 2009 03:12:36 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 19BD63A6A5E for ; Tue, 16 Jun 2009 03:12:35 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 12:12:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 12:12:11 +0200 Message-ID: <9ECCF01B52E7AB408A7EB853526421412F59C6@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD404827AB8@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYAAADaOvAAAEZYIAAAZd2gAAEEtLAAASSLAAAQUjFAAAQ6qeA= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com><1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>!<1ECE0EB50388174790F9694F77522CCF1E83DBEB@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA0375EC26@gaalpa1msgusr7e.ugd.att.com> <9886E5FCA6D76549A3011068483A4BD404827AB8@S4DE8PSAAQB.mitte.t-com.de> From: To: , , , , , X-OriginalArrivalTime: 16 Jun 2009 10:12:10.0064 (UTC) FILETIME=[E90CBD00:01C9EE6A] Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 10:12:38 -0000 I would go even further. There are cases where it is useful to keep = track of the services invoked during the establishment of a session, = irrespective of whether these services have modified the R-URI or not. = To achieve this, an application server providing service X would insert = an entry in the History-Info header field with hi-target=3Dnoop, an = unmodified R-URI and an extended cause-param set to a value representing = service "X". BC=20 -----Message d'origine----- De : sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] De la = part de R.Jesske@telekom.de Envoy=E9 : mardi 16 juin 2009 07:02 =C0 : mdolly@att.com; mary.barnes@nortel.com; = christer.holmberg@ericsson.com; audet@nortel.com; sipcore@ietf.org Objet : Re: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi, Why not to adopt the cause-parameter principle of RFC 4458 and extend it = for other service approaches. The have a general cause-param for services other then call diversion = and to have explicit cause parameters for free phone, "IN-services", = calling card ect. Such indications where asked a couples of times from other service = providers. BR, Roland=20 -----Urspr=FCngliche Nachricht----- Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im = Auftrag von DOLLY, MARTIN C, ATTLABS Gesendet: Montag, 15. Juni 2009 23:10 An: Mary Barnes; Christer Holmberg; Francois Audet; sipcore@ietf.org Betreff: Re: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt no -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Monday, June 15, 2009 4:38 PM To: Christer Holmberg; Francois Audet; DOLLY, MARTIN C, ATTLABS; = sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt But, the freephone service can be implemented also with a reg-uri or reg-uri-alias - NOW if a specific service treats them the same, no big deal. The UAS then looks for any of a set of tags to grab the appropriate hi-entry.=20 Mary. -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Monday, June 15, 2009 3:14 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi,=20 >But, still with this approach, I do not think you can get away with not looking for multiple tags with the way you envision doing your services. Maybe not - that depends on the service. But, then it will at least be possible to figure out what has happended. >I think there are others that will implement services on the UAS that will not need the differentiation that you do - i.e, they care about the difference between "reg-uri" and "reg-uri-alias". My differentiation is based on my understanding of the requirements that we have. If you think we need to differentiate between req-uri and req-uri-alias, then we should agree on such requirement. Let's not mix it with the freephone requirement. Regards, Christer -----Original Message----- From: Barnes, Mary (RICH2:AR00) Sent: Monday, June 15, 2009 2:53 PM To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Christer,=20 On your last point, the objective here was to make use of History-Info WITHOUT changing any core SIP functionality - it's a whole different ballgame if we want to do the latter IMHO. However, here's the snippet from the end of the response I just sent to Martin (summarizing the current set of tags), which you may not read: " So, we're debating here the differences between the "aor,mapped" and "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I think that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed". And, I think one could consider the "aor,mapped" as predetermined. But, again 4244bis tags the entries entirely based on what SIP does and if the 800 number translations (or whatever services) are setup differently in different proxies, then you can't determine if the "aor,routed" cases might be "reg-uri-alias" or "reg-uri". Although, I am personally confused as to whether an 800 number would always be "aor, mapped" or "aor, routed" - i.e., I just don't see this being deterministic and I think that if a service can reach a UAS through different SIP retargeting mechanisms, then the UAS needs to be aware.=20 Also, as I'm going through this, I think we need 3 more tags if we want the proxy to do the tagging - i.e., I think we need to add "-aor" to the "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that the proxy will mark in this manner. " Mary.=20 P.S. Also, I do not think it's a burden to put logic in the UAS - that was the original intent for SIP - services in the endpoints - SIP is just the signalling to carry the relevant information. But, I can see that since the sort of service you mention that does not have a standard SIP URI (i.e., user@domain) introduces something that isn't accomodated in the basic SIP model, so we may need to add additional logic to the proxies (I don't like it though).=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 15, 2009 2:34 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi,=20 >Correct. But, what I am suggesting is that you distinguish it at the UAS >- I'm assuming that the target Request-URI that arrives at the UAS is something that identifies a client that handles 800 numbers. That client could be configured such that it knows to look for the=20 >original 800 number in the mapped URIs or in the reg-alias-URIs or both.=20 800 numbers is just one example.=20 Why should the UAS have to be configured with this information??? I think that is very limiting and unpractical. >Again, if you're making these 800 numbers special and allowing proxies to change them in multiple ways (i.e., non-deterministic), then if you want them tagged special, then you need special logic in the=20 >proxies to do this. The logic is that the AOR is replaced with another AOR, which belongs to the same user.=20 It's not only for 800 numbers - they are just an example where it would be useful. And, the proxy is configured to do this - it doesn't do it because it "thinks" it has to do it :) >That doesn't make sense to me, although you could do it that way in a closed network, in which case you can make sure to always tag them as whatever you think they should be - so we could define an=20 >additional value for the tag. But, this is what I don't think is right in terms of normal SIP request routing and forwarding, which is what the current 4244bis tags have been defined to represent.=20 I really don't understand wht this "normal SIP request routing and forwarding" is all about. Normal SIP request routing and forwarding has issues, which were presented in the ua-loose-route draft - and that is why we are now working on a solution to solve those issues. Regards, Christer -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, June 15, 2009 1:23 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi Mary, Proxies will tag entries based on the functionality they perform. Let's leave req-uri-alias for the moment. As I said earlier, one of the issues we have with 4244bis, is that "mapped" seems to be used BOTH for diversion and when an AOR is replaced with another AOR pointing to the same user - e.g. freephone. So, it is not possible to distinguish between diversion and freephone. We think one MUST be able to make that distinguishment, because you may have cases where both diversion and service number translation (e.g. freephone) occurs, and the UAS needs to know which is which. Regards, Christer =20 -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Monday, June 15, 2009 9:13 PM To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt It seems to me that the gist of this discussion has been based on the expectation that independent of how the 800 number is configured, registered or whatever at a proxy, that there is an expectation of deterministic behavior in terms of how it's tagged. So, if 800 numbers are special and they can end up tagged as either reg-uri-alias or as mapped, then perhaps the service has to know that it needs to look for either of those. ISTM that if there is a reason to preserve that it's an 800 number (i.e., and not format as a service specific uri), the service at the UAS knows that it's special, thus it would need to check the request-URIs associated with both reg-uri-alias and mapped hi-entries. I can't see how we can make it work any other way without being prescriptive of how proxy's MUST tag these entries, which is not a good idea IMHO. However, I think these numbers are either special cases at proxies or something that services know about.=20 Mary.=20 -----Original Message----- From: Audet, Francois (SC100:3055) Sent: Monday, June 15, 2009 12:47 PM To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Yes, we need to sort out what to do for that.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 10:17 > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > Mary (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 >=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, June 15, 2009 6:50 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > then reg-uri-alias.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Saturday, June 13, 2009 01:22 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > >1) RFC 4244bis > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > Request-URI and it replacing it with a Contact, it will put > a reg-uri > > flag (if the Request-URI was the AOR used for registration), or reg- > > >uri-alias (if the Request-URI was an alias for the AOR used in > > registration). > >=20 > > And if the Request-URI was a "synonym" for the AOR? > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Tue Jun 16 03:32:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2533A6D52 for ; Tue, 16 Jun 2009 03:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.276 X-Spam-Level: X-Spam-Status: No, score=-3.276 tagged_above=-999 required=5 tests=[AWL=-1.827, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_LOAN=2.3, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9+WbxVc-R9E for ; Tue, 16 Jun 2009 03:32:21 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 48B333A6B46 for ; Tue, 16 Jun 2009 03:32:20 -0700 (PDT) X-AuditID: c1b4fb3e-b7b1dae000006c99-05-4a377462b010 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id D9.B5.27801.264773A4; Tue, 16 Jun 2009 12:30:58 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 12:30:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 12:30:57 +0200 Message-ID: In-Reply-To: <9ECCF01B52E7AB408A7EB853526421412F59C6@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYAAADaOvAAAEZYIAAAZd2gAAEEtLAAASSLAAAQUjFAAAQ6qeAABxuA8A== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com><1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>!<1ECE0EB50388174790F9694F77522CCF1E83DBEB@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA0375EC26@gaalpa1msgusr7e.ugd.att.com> <9886E5FCA6D76549A3011068483A4BD404827AB8@S4DE8PSAAQB.mitte.t-com.de> <9ECCF01B52E7AB408A7EB853526421412F59C6@ftrdmel0.rd.francetelecom.fr> From: "Christer Holmberg" To: , , , , , X-OriginalArrivalTime: 16 Jun 2009 10:30:58.0133 (UTC) FILETIME=[896E6850:01C9EE6D] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 10:32:22 -0000 Hi, >I would go even further. There are cases where it is useful=20 >to keep track of the services invoked during the=20 >establishment of a session, irrespective of whether these=20 >services have modified the R-URI or not. To achieve this, an=20 >application server providing service X would insert an entry=20 >in the History-Info header field with hi-target=3Dnoop, an=20 >unmodified R-URI and an extended cause-param set to a value=20 >representing service "X". I think that should be a completely separate discussion. It is an interesting topic, but I think you would need to start it in = DISPATCH or BLISS, because I think it is far beyond the scope of both = 4244bis and target delivery :) Regards, Christer > -----Message d'origine----- > De : sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] De la part de=20 > R.Jesske@telekom.de Envoy=E9 : mardi 16 juin 2009 07:02 =C0 :=20 > mdolly@att.com; mary.barnes@nortel.com;=20 > christer.holmberg@ericsson.com; audet@nortel.com;=20 > sipcore@ietf.org Objet : Re: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hi, > Why not to adopt the cause-parameter principle of RFC 4458=20 > and extend it for other service approaches. > The have a general cause-param for services other then call=20 > diversion and to have explicit cause parameters for free=20 > phone, "IN-services", calling card ect. > Such indications where asked a couples of times from other=20 > service providers. >=20 > BR, >=20 > Roland=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] Im Auftrag von DOLLY,=20 > MARTIN C, ATTLABS > Gesendet: Montag, 15. Juni 2009 23:10 > An: Mary Barnes; Christer Holmberg; Francois Audet; sipcore@ietf.org > Betreff: Re: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > no >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 4:38 PM > To: Christer Holmberg; Francois Audet; DOLLY, MARTIN C,=20 > ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But, the freephone service can be implemented also with a=20 > reg-uri or reg-uri-alias - NOW if a specific service treats=20 > them the same, no big deal. The UAS then looks for any of a=20 > set of tags to grab the appropriate hi-entry.=20 >=20 > Mary. >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 3:14 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055);=20 > DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi,=20 >=20 > >But, still with this approach, I do not think you can get=20 > away with not > looking for multiple tags with the way you envision doing=20 > your services. >=20 > Maybe not - that depends on the service. But, then it will at least be > possible to figure out what has happended. >=20 > >I think there are others that will implement services on the UAS that > will not need the differentiation that you do - i.e, they=20 > care about the > difference between "reg-uri" and "reg-uri-alias". >=20 > My differentiation is based on my understanding of the=20 > requirements that > we have. >=20 > If you think we need to differentiate between req-uri and=20 > req-uri-alias, > then we should agree on such requirement. Let's not mix it with the > freephone requirement. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Monday, June 15, 2009 2:53 PM > To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY,=20 > MARTIN C, > ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Christer,=20 >=20 > On your last point, the objective here was to make use of History-Info > WITHOUT changing any core SIP functionality - it's a whole different > ballgame if we want to do the latter IMHO. However, here's the snippet > from the end of the response I just sent to Martin (summarizing the > current set of tags), which you may not read: >=20 > " So, we're debating here the differences between the "aor,mapped" and > "aor,routed" vs "predetermined", "reg-uri" and=20 > "reg-uri-alias". I think > that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed". > And, I think one could consider the "aor,mapped" as=20 > predetermined. But, > again 4244bis tags the entries entirely based on what SIP does and if > the 800 number translations (or whatever services) are setup=20 > differently > in different proxies, then you can't determine if the=20 > "aor,routed" cases > might be "reg-uri-alias" or "reg-uri". Although, I am personally > confused as to whether an 800 number would always be "aor, mapped" or > "aor, routed" - i.e., I just don't see this being deterministic and I > think that if a service can reach a UAS through different SIP > retargeting mechanisms, then the UAS needs to be aware.=20 >=20 > Also, as I'm going through this, I think we need 3 more tags=20 > if we want > the proxy to do the tagging - i.e., I think we need to add=20 > "-aor" to the > "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that the > proxy will mark in this manner. " >=20 >=20 > Mary.=20 > P.S. Also, I do not think it's a burden to put logic in the UAS - that > was the original intent for SIP - services in the endpoints - SIP is > just the signalling to carry the relevant information. But, I can see > that since the sort of service you mention that does not have=20 > a standard > SIP URI (i.e., user@domain) introduces something that isn't=20 > accomodated > in the basic SIP model, so we may need to add additional logic to the > proxies (I don't like it though).=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 2:34 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi,=20 >=20 > >Correct. But, what I am suggesting is that you distinguish it at the > UAS > >- I'm assuming that the target Request-URI that arrives at the UAS is > something that identifies a client that handles 800 numbers. That > client could be configured such that it knows to look for the=20 > >original 800 number in the mapped URIs or in the reg-alias-URIs or > both.=20 >=20 > 800 numbers is just one example.=20 >=20 > Why should the UAS have to be configured with this information??? I > think that is very limiting and unpractical. >=20 > >Again, if you're making these 800 numbers special and=20 > allowing proxies > to change them in multiple ways (i.e., non-deterministic), then if you > want them tagged special, then you need special logic in the=20 > >proxies to do this. >=20 > The logic is that the AOR is replaced with another AOR, which=20 > belongs to > the same user.=20 >=20 > It's not only for 800 numbers - they are just an example=20 > where it would > be useful. >=20 > And, the proxy is configured to do this - it doesn't do it because it > "thinks" it has to do it :) >=20 > >That doesn't make sense to me, although you could do it that way in a > closed network, in which case you can make sure to always tag them as > whatever you think they should be - so we could define an=20 > >additional value for the tag. But, this is what I don't=20 > think is right > in terms of normal SIP request routing and forwarding, which=20 > is what the > current 4244bis tags have been defined to represent.=20 >=20 > I really don't understand wht this "normal SIP request routing and > forwarding" is all about. Normal SIP request routing and=20 > forwarding has > issues, which were presented in the ua-loose-route draft - and that is > why we are now working on a solution to solve those issues. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 1:23 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi Mary, >=20 > Proxies will tag entries based on the functionality they perform. >=20 > Let's leave req-uri-alias for the moment. >=20 > As I said earlier, one of the issues we have with 4244bis, is that > "mapped" seems to be used BOTH for diversion and when an AOR=20 > is replaced > with another AOR pointing to the same user - e.g. freephone. So, it is > not possible to distinguish between diversion and freephone. >=20 > We think one MUST be able to make that distinguishment,=20 > because you may > have cases where both diversion and service number translation (e.g. > freephone) occurs, and the UAS needs to know which is which. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > =20 >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 9:13 PM > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > It seems to me that the gist of this discussion has been based on the > expectation that independent of how the 800 number is configured, > registered or whatever at a proxy, that there is an expectation of > deterministic behavior in terms of how it's tagged. So, if=20 > 800 numbers > are special and they can end up tagged as either reg-uri-alias or as > mapped, then perhaps the service has to know that it needs to look for > either of those. ISTM that if there is a reason to preserve=20 > that it's an > 800 number (i.e., and not format as a service specific uri),=20 > the service > at the UAS knows that it's special, thus it would need to check the > request-URIs associated with both reg-uri-alias and mapped hi-entries. > I can't see how we can make it work any other way without being > prescriptive of how proxy's MUST tag these entries, which is=20 > not a good > idea IMHO. However, I think these numbers are either special cases at > proxies or something that services know about.=20 >=20 > Mary.=20 >=20 > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 12:47 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary > (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Yes, we need to sort out what to do for that.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, June 15, 2009 10:17 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 > >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, June 15, 2009 6:50 PM > > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > > sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > then reg-uri-alias.=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Saturday, June 13, 2009 01:22 > > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C,=20 > ATTLABS; Barnes,=20 > > > Mary (RICH2:AR00); sipcore@ietf.org > > > Subject: RE: [sipcore] FW: I-D > > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > >=20 > > >=20 > > > Hi, > > >=20 > > > >1) RFC 4244bis > > > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > > Request-URI and it replacing it with a Contact, it will put > > a reg-uri > > > flag (if the Request-URI was the AOR used for=20 > registration), or reg- > > > >uri-alias (if the Request-URI was an alias for the AOR used in > > > registration). > > >=20 > > > And if the Request-URI was a "synonym" for the AOR? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From mary.barnes@nortel.com Tue Jun 16 06:25:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C935C3A698B for ; Tue, 16 Jun 2009 06:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.345 X-Spam-Level: X-Spam-Status: No, score=-6.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06QzFp9glcbH for ; Tue, 16 Jun 2009 06:25:11 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 05BAB3A6A5E for ; Tue, 16 Jun 2009 06:25:10 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5GDP6c06357; Tue, 16 Jun 2009 13:25:07 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 08:27:36 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E83E210@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A374056.6050001@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Another approach to preservation of targeting information on a proxy-rewrite of request URI (Request URI Replacement) thread-index: AcnuTpb83+QFDCWNQVau2u0D9NxIQQANzohA References: <4A374056.6050001@softarmor.com> From: "Mary Barnes" To: "Dean Willis" , Subject: Re: [sipcore] Another approach to preservation of targeting information on a proxy-rewrite of request URI (Request URI Replacement) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 13:25:12 -0000 Dean, I do like the idea of using the URI parameter, but I've been consistently outvoted on that one.=20 I think with the latest proposal that Francois posted we capture three things you identify: 1) why - this is how we'll tag the "old" hi-entry - i.e., the mechanism by which the new URI was determined. 2) what kind of URI - that's how we'll tag the "new" hi-entry 3) why did we do this - this is already covered by the reason header Mary.=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis Sent: Tuesday, June 16, 2009 1:49 AM To: sipcore@ietf.org Subject: [sipcore] Another approach to preservation of targeting information on a proxy-rewrite of request URI (Request URI Replacement) Poxies sometimes replace an incoming request-URI with another request-URI. I'll cal this operation a "Request-URI Replacement", or RUR for now. Note that this should not be confused with an RUS, or "Rodent of Unusal Size", which is an entirely different order of pest, although I understand that both are likely to carry the fleas that spread plague. Some of our discussion threads (and drafts) seem to be bogged down on the "whys" and "what kind of URI was that" discussion. For example, was that RUR caused by an aliasing operation (replacement of one AOR with another) or a contact-routing operation (replacement of an AOR with a contact). We also have a "and WHY did we do this" discussion, that includes such potential excuses as "The previous number was busy", "the previous number forwrded to this number", "I found a registration that sort-of matched", and "The devil made me do it." This whole family of argument assumes that we have different kinds of URIs, different kinds of replacement operations, and different reasons for doing replacements. Further, it presumes that each of these sets of things is finite, bounded, and definable in a standardized, interoperable way, and that the proxy performing the RUR intimately understands the full gamut of possibilities and therefore ay encode the new URI, its type, and its causality in a universally standard way that will be understood by the UAS. Although I've previously offered to model wherein RUR operations can be classified as "retargeting" vs "rerouting" based on the continuity of response-identity across the RUR (retargets change response identity, reroutes don't), I'm not sure I believe any of the other above presumptions about RUR discriminations to be demonstrably true. And I'm not sure we need them anyhow. I'm especially not sure that I believe that there is a finite and well-definable set of "why" operations that can be used to forward-explain all possible service logics. But I am certain that there are use-cases for which a UAS supports multiple identities and needs to know which identity applies to a received request. One approach is to assign each UAS a discrete URI for each identity.=20 Then if an upstream proxy does an RUR, the UAS can work backwards from the resulting request-URI in order to figure out which identity is being targeted. This is exactly how we have always thought of a multi-user UAS, which typiclaly uses a set of URIs where the right-hand-side is the host name or address and the left-hand-side is the identity discriminator: for example "sip:ext1@gateway.example.com" vs "sip:ext2@gateway.example.org". or "sip:alice@pbx.example.org" vs.=20 "sip:bib@pbx.example.org" This model works nicely for lots of cases. For example, it can support proxies that do RUR based on configuration tables, dynamic registration, business policy matching, TRIP aggregation, etc. All it requires is that the UAS support multiple URIs and be able to distinguish between them. Some people would argue that it 1) requires that each UAS be provisioned with the entire possible set of request-URIs, or that this would result in very large registration databases. Again, I'm not sure I completely buy this. We could also encode the replaced URI into the new URI in a "You can throw this away if you don't understand it" sort of way by using a URI parameter appended to the r-URI resulting from the RUR. For example, A proxy receiving a request for "sip:alice@example.com" might replace that URI with "sip@line1@192.168.1.1;rur=3Dsip:alice@example.com" If Alice's UAS (which she might share with Bob) understands the RUR header field encoded in the r-URI, it can make up its own mind about the translation type and how to render the request URI. A nesting syntax should allow quite elaborate constructions. This approach simplifies proxy operation by taking the proxy out of the provisioning and translation loops as much as possible. The proxy doens't know whether a given RUR is a retarget or a reroute; all it knows is that the pre-RUR URI is appended to the post-RUR URI in a fixed manner. The UAS can, if it cares, deal with the implications. So what else do we really need and understand well enough to quantify without arguing about it until the end of time? -- Dean _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Tue Jun 16 06:28:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 037E83A6AEC for ; Tue, 16 Jun 2009 06:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4BTNs-mxjyd for ; Tue, 16 Jun 2009 06:28:22 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7D38B3A698B for ; Tue, 16 Jun 2009 06:28:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,228,1243814400"; d="scan'208";a="200715655" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 16 Jun 2009 13:27:49 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5GDRone019701; Tue, 16 Jun 2009 06:27:50 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n5GDRbF4017075; Tue, 16 Jun 2009 13:27:50 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 09:27:47 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 09:27:47 -0400 Message-ID: <4A379DD1.20600@cisco.com> Date: Tue, 16 Jun 2009 09:27:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! <4A3 6AC9C.306050 9@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Jun 2009 13:27:47.0621 (UTC) FILETIME=[3D2DCD50:01C9EE86] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7378; t=1245158870; x=1246022870; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20draft-barnes-sipcore-rfc424 4bis=20and=20target-uri |Sender:=20; bh=G4IzQKmKaEzetbvBqoqFXfFW865SMTQtl6gPXLMC7Jo=; b=dmsaWIML62wPckuJ5DlEZohsYJuVoNjwcJqqz2Rj/T3chIMK3/1vVQmPbe kyoWc8vH3xkEIqjUaPYQ6VW5dTW8W5gaelXtrfEaLKZhyFEbe2UMd4T6pMmg PvHCo6yqef; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 13:28:24 -0000 Christer Holmberg wrote: > > Hi Francois, > > "rc" and "ic" look rather ok. But, for "ic" you need to change "but was not discovered using SIP Registration", because you may discover it using the P-Associated-URI header (if you support it). So, I propose something like: > > ic : The entry is an implicit registered contact (i.e., it's exactly as a registered contact, > but was not provided in a REGISTER request: it could have been manually configured > or done with a proprietary mechanism). > > > But, I think there is a small missunderstading for the AOR-to-AOR cases. > > We don't think you need to know whether the new AOR is an alias or not. You need to know whether the new AOR belongs to the same user or not. This concept is still bugging me. Precisely what do you mean by "new AOR *belongs* to the same user"? And why does that matter? You have said that these might reside in different domains, and that the tagging will simply be configured. In the end it isn't the one doing the tagging that cares, rather it is the one receiving the tagged entry that cares isn't it? So in some sense this is a matter of the "owner" of the downstream URI instructing the owner of the upstream URI to tag the entry in a way that the downstream URI will recognize. Yet doing it *that* abstractly is likely to lead to a tower of babel. I'm still groping for the semantic meaning of the tag. And in practice remain unconvinced that it is needed at all. If the owner of the downstream URI has requested the mapping from the owner of the upstream URI, doesn't it know what upstream URIs map to it? Can't it check them by value, without a tag? Overall, what I am looking for is a complete partitioning of the space into disjoint subspaces covering the whole space. In the past, this partitioning as been done informally and incompletely as "AOR" vs. "Contact". We all knew that wasn't either disjoint or complete. And we have always acted as if this is an inherent property of a URI, rather than a usage context. But of course it isn't that simple - one person's AOR can be another person's Contact. The current approach is about describing the role of a URI in context, which at least has a chance to be determinable, so its at least on the right track. The trouble with H-I in this regard is that there seems no good reason to believe that middleboxes will preserve the entries that will ultimately be required. Thanks, Paul > So, in case of diversion, where the user is changed, I assume "mp" is used. > > For freephone, where the user is not changed, one could use "rt". But, I don't think it matters in which domain the translation takes place, or whether the new AOR is an alias or not. > > So, my proposal would be something like: > > rt : The entry is "routed", i.e., it is either a no-opt like a proxy forwarding within > a domain, predetermined by a maddr in the Request-URI, or when the request-URI is changed to a new URI that represent the same user. > > Regards, > > Christer > > > > > > > > > > > > > > > > > > >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> Sent: 16. kesäkuuta 2009 4:44 >> To: Christer Holmberg; Hans Erik van Elburg; Mary Barnes; >> Shida Schubert >> Cc: sipcore@ietf.org >> Subject: draft-barnes-sipcore-rfc4244bis and target-uri >> >> All right guys, >> >> I've been thinking about this. >> >> It seems to me that what we want to capture is: >> 1) If the target is an AOR, a contact, or a routing URI >> (maddr, noop intra-domain, or noop >> forward to next domain, or strict routing). >> 2) In the case that the target is an AOR, then if that AOR is >> known to be an alias for the previous >> one, or if it is mapped to another AOR. >> >> It seems to me that a Proxy should mark a Previous entry in >> H-I with aor if it determines that it owns this AOR. Just as >> Hans's current target-uri draft. >> >> Now, for the mapped vs routed (versus reg-contact, etc.), >> instead of marking the Previous entry, we should mark the >> OUTGOING (i.e., New) entry instead. This would make the procedures of >> 7.2.1 & 7.2.2 of target-URI draft clearer. >> >> Specifically, the logic would be: >> >> When proxy receives an incoming request with H-I, it adds an >> ;aor tag to that incoming entry if it determines that it is >> responsible for the AOR and. >> >> Also, if there was no Hi-entry at all (i.e., it came from a >> UAC), and the Proxy creates then two entries, the first one >> in this case would also have the ;aor tag associated to it. >> >> For the Outgoing entry, I would see the following tags: >> >> rc : The entry is an explicit registered contact >> (i.e., it was provided in a REGISTER message) >> >> ic : The entry is an implicit registered contact >> (i.e., it's exactly as a registered contact, >> but was not discovered using SIP Registration: >> it could have been manually configured >> or done with a proprietary mechanism). >> >> (TBD: we could debate if we need both rc and >> irc, but I think we do). >> >> mp : The request-URI is changed to a new URI that >> represent another user. >> >> rt : The entry is "routed", i.e., it is either a >> no-opt like a proxy forwarding within >> a domain, predetermined by a maddr in the >> Request-URI, or when proxy is NOT responsible >> for domain, or the address is an alias for the >> incoming URI. >> >> So, to give an example. >> >> Say Alice calls Bob. Bob is forwarded to freephone. Freephone >> routes to Carol. >> >> The History-info at Carol would look like this: >> >> Alice -> example.com >> Nothing because UAC typically doesn't send H-I (otherwise, it >> would be as per Index 1 in next entry, but without the AOR. >> >> example.com -> freephone@example.net >> History-Info: ;index=1;aor >> History-Info: ;index=1.1;mp >> >> example.net -> carol@example.net >> History-Info: ;index=1;aor >> History-Info: ;index=1.1;mp;aor >> <- aor is added >> History-Info: ;index=1.1.1;rt;aor } >> Two entries are >> History-Info: ;index=1.1.1.1;rc } >> added at same time >> >> Also, I don't think we need to define an equivalent to the >> "reg-uri-alias" anymore. >> If Freephone was configured to go to +14085551212 instead of >> the registered Contact (assuming +14085551212 was an Alias >> AOR for carol@example.net), the last H-I entries would look >> like this instead: >> >> example.net -> carol@example.net >> History-Info: ;index=1;aor >> History-Info: >> ;index=1.1;mp;aor <- >> aor is added >> History-Info: ;index=1.1.1;rt;aor >> <- aor is added >> History-Info: ;index=1.1.1.1;rt;aor >> } Two entries are >> History-Info: ;index=1.1.1.1.1;rc >> } added at same time >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Tue Jun 16 06:41:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 635723A6AEC for ; Tue, 16 Jun 2009 06:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ki3q70hP7IRm for ; Tue, 16 Jun 2009 06:41:03 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4E9773A6B6A for ; Tue, 16 Jun 2009 06:41:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,228,1243814400"; d="scan'208";a="324976297" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 16 Jun 2009 13:40:45 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5GDej3n022495; Tue, 16 Jun 2009 06:40:45 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5GDeeb0018048; Tue, 16 Jun 2009 13:40:45 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 09:40:44 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 09:40:44 -0400 Message-ID: <4A37A0D9.1080506@cisco.com> Date: Tue, 16 Jun 2009 09:40:41 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dean Willis References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <4A340ACE.1070803@cisco.com> <1ECE0EB50388174790F9694F77522CCF1E83D36A@zrc2hxm0.corp.nortel.com> <4A37332D.2070401@softarmor.com> In-Reply-To: <4A37332D.2070401@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2009 13:40:44.0524 (UTC) FILETIME=[0C3FCAC0:01C9EE88] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2016; t=1245159645; x=1246023645; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Freephone=20discussion=20(W as=3A=20The=20functional=20differences=0A=20between=204244bi s=20and=09target-=20uri) |Sender:=20; bh=OfRt7HwZe9bs3c8V6kizvnvHolqN98oQwky1G9AOrNw=; b=GS0pe2LweyT3qaCqaQMzYlEacKgBFz5c8xK6C0J1iH8I+1TgcWuxonLj6a BxwIBuxbJcSOJA9Bqgi5V3Bvw5pGLRVnmTM07HtvRLq7RQmyTPid1t7ozyjA aLDH0PFCWT2X1wM7m3YTPuthFXNNmGpSzEs+J6Y0tDBXHrIjMx8/g=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] Freephone discussion (Was: The functional differences between 4244bis and target- uri) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 13:41:04 -0000 (I changed the subject again) On one hand I agree with Dean that the freephone semantics are legacy baggage that are inextricably entwined with the legacy implementation. There is little we can do to "fix" it. But when interoperating with the legacy telephone network it will continue to be an elephant in the room and cannot simply be ignored. We could no doubt devise some much more useful alternatives to the "800" style of freephone service when the call is sip end to end. (I've thought for a long time that "who pays" should be negotiated in much the way that QoS is. Perhaps preconditions could be used to do it - even the e2e vs segmented models make sense.) But we will not be doing that in ietf since we never discuss billing in ietf. In Dean's example below, what is free? And who would have been billed for it if it hadn't been free? Thanks, Paul Dean Willis wrote: > Francois Audet wrote: >> Perhaps you are correct. >> >> I must admit I'm having trouble understanding the sutleties of the >> freephone service. > > It's not that complicated. > > Think of it as an AOR (the freephone number) to which a contact (the > service nuumber) is registered. > > Unfortunately, said contact is also registered to other AORs, and the > B2BUA that terminates the call needs to know which AOR was used so it > can figure out 1) how to bill for the call, and 2) how to route the call > within the call center and what to display on the UAS. > > My proposal: This is an obtuse legacy. Don't build SIP-based systems on > the same model; contacts are cheap, locally-mintable, and you can use a > different one for every AOR. > > If you THINK you have a freephone problem that needs a specification > extension to deal with it, you probably just have a badly designed > deployment. Rethink the problem without forcibly holding your head in a > bell shape. > > Remember, this is not your mother's phone network. > > -- > Dean > > From mary.barnes@nortel.com Tue Jun 16 06:52:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2FAE3A6AA4 for ; Tue, 16 Jun 2009 06:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[AWL=-1.001, BAYES_00=-2.599, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgQzJOcqRHCF for ; Tue, 16 Jun 2009 06:52:58 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 867433A6A7D for ; Tue, 16 Jun 2009 06:52:58 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5GDojc17869; Tue, 16 Jun 2009 13:50:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 08:52:18 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E88DA09@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri thread-index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAI5l3MA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! <4A36A C9C.3060509@ gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Francois Audet" , "Christer Holmberg" , "Hans Erik van Elburg" , "Shida Schubert" Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 13:52:59 -0000 So, to summarize: - the old entry is tagged with the "type of URI" - the new entry is tagged with the mechanism by which the URI was determined Is that correct? That's actually backwards from what I just told Dean, but does make sense since you don't know anything about the "type of URI" until it reaches a domain that is responsible for it.=20 I have a couple comments/questions embedded below to make sure I understand, as this is slightly different than what I had envisioned when we discussed it yesterday.=20 Mary.=20 -----Original Message----- From: Audet, Francois (SC100:3055)=20 Sent: Monday, June 15, 2009 8:44 PM To: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary (RICH2:AR00); Shida Schubert Cc: sipcore@ietf.org Subject: draft-barnes-sipcore-rfc4244bis and target-uri All right guys, I've been thinking about this. It seems to me that what we want to capture is: 1) If the target is an AOR, a contact, or a routing URI (maddr, noop intra-domain, or noop forward to next domain, or strict routing). 2) In the case that the target is an AOR, then if that AOR is known to be an alias for the previous one, or if it is mapped to another AOR. It seems to me that a Proxy should mark a Previous entry in H-I with aor if it determines that it owns this AOR. Just as Hans's current target-uri draft. Now, for the mapped vs routed (versus reg-contact, etc.), instead of marking the Previous entry, we should mark the OUTGOING (i.e., New) entry instead. This would make the procedures of 7.2.1 & 7.2.2 of target-URI draft clearer. [MB] I think this gets to the concern I had earlier about it looking to be "two stage". [/MB] Specifically, the logic would be: When proxy receives an incoming request with H-I, it adds an ;aor tag to that incoming entry if it determines that it is responsible for the AOR and.=20 Also, if there was no Hi-entry at all (i.e., it came from a UAC), and the Proxy creates then two entries, the first one in this case would also have the ;aor tag associated to it. For the Outgoing entry, I would see the following tags: rc : The entry is an explicit registered contact (i.e., it was provided in a REGISTER message) ic : The entry is an implicit registered contact (i.e., it's exactly as a registered contact, but was not discovered using SIP Registration: it could have been manually configured or done with a proprietary mechanism). (TBD: we could debate if we need both rc and irc, but I think we do). mp : The request-URI is changed to a new URI that represent another user. rt : The entry is "routed", i.e., it is either a no-opt like a proxy forwarding within a domain, predetermined by a maddr in the Request-URI, or when proxy is NOT responsible for domain, or the address is an alias for the incoming URI. [MB] I'm slightly confused as to why alias are in this bucket - aren't aliases also registered contacts? =20 Also, I would prefer to tag these explictly as we did with the current definition of hi-target in 4244bis. I don't think it costs anything and I think it could be useful for debug/diagnostics. Also, I would prefer we expand the labels a tad, something like: reg-exp reg-imp mapped route=20 reg-alias I could live without the alias, but per my comment above, it's not clear to me that these are "routed".=20 [/MB] So, to give an example.=20 Say Alice calls Bob. Bob is forwarded to freephone. Freephone routes to Carol.=20 The History-info at Carol would look like this: Alice -> example.com Nothing because UAC typically doesn't send H-I (otherwise, it would be as per Index 1 in next entry, but without the AOR. example.com -> freephone@example.net History-Info: ;index=3D1;aor History-Info: ;index=3D1.1;mp example.net -> carol@example.net History-Info: ;index=3D1;aor =20 History-Info: ;index=3D1.1;mp;aor <- aor is added History-Info: ;index=3D1.1.1;rt;aor } Two entries are History-Info: ;index=3D1.1.1.1;rc } added = at same time Also, I don't think we need to define an equivalent to the "reg-uri-alias" anymore. [MB] I'm not entirely comfortable with losing the alias concept. I would think it could be useful for debug/diagnostic use cases. [/MB] If Freephone was configured to go to +14085551212 instead of the registered Contact (assuming +14085551212 was an Alias AOR for carol@example.net), the last H-I entries would look like this instead: example.net -> carol@example.net History-Info: ;index=3D1;aor =20 History-Info: = ;index=3D1.1;mp;aor <- aor is added History-Info: ;index=3D1.1.1;rt;aor <- aor = is added History-Info: ;index=3D1.1.1.1;rt;aor } Two entries are History-Info: ;index=3D1.1.1.1.1;rc } added at same time From bruno.chatras@orange-ftgroup.com Tue Jun 16 07:55:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52CBB3A6D78 for ; Tue, 16 Jun 2009 07:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.551 X-Spam-Level: ** X-Spam-Status: No, score=2.551 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_LOAN=2.3, MANGLED_REGALS=2.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fz+K86dF0Wvv for ; Tue, 16 Jun 2009 07:55:51 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 1640D3A6D71 for ; Tue, 16 Jun 2009 07:55:50 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 16:53:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 16:53:49 +0200 Message-ID: <9ECCF01B52E7AB408A7EB853526421412F5E64@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYAAADaOvAAAEZYIAAAZd2gAAEEtLAAASSLAAAQUjFAAAQ6qeAABxuA8AAJKoOA References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com><1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>!<1ECE0EB50388174790F9694F77522CCF1E83DBEB@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA0375EC26@gaalpa1msgusr7e.ugd.att.com> <9886E5FCA6D76549A3011068483A4BD404827AB8@S4DE8PSAAQB.mitte.t-com.de> <9ECCF01B52E7AB408A7EB853526421412F59C6@ftrdmel0.rd.francetelecom.fr> From: To: , , , , , X-OriginalArrivalTime: 16 Jun 2009 14:53:46.0607 (UTC) FILETIME=[402C97F0:01C9EE92] Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 14:55:53 -0000 =20 -----Message d'origine----- De : Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Envoy=E9 : mardi 16 juin 2009 12:31 =C0 : CHATRAS Bruno RD-CORE-ISS; R.Jesske@telekom.de; mdolly@att.com; = mary.barnes@nortel.com; audet@nortel.com; sipcore@ietf.org Objet : RE: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi, >I would go even further. There are cases where it is useful to keep=20 >track of the services invoked during the establishment of a session,=20 >irrespective of whether these services have modified the R-URI or not.=20 >To achieve this, an application server providing service X would insert = >an entry in the History-Info header field with hi-target=3Dnoop, an=20 >unmodified R-URI and an extended cause-param set to a value=20 >representing service "X". I think that should be a completely separate discussion. It is an interesting topic, but I think you would need to start it in = DISPATCH or BLISS, because I think it is far beyond the scope of both = 4244bis and target delivery :) =3D=3D>BC: It's indeed different from the current focus of the = discussion but I would not say that it a completely separate discussion = as it may well be that 4244bis can provide a solution with minimum = changes to 4.3.3.1.2 (Reason) in the current draft. Regards, Christer > -----Message d'origine----- > De : sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] De la part de R.Jesske@telekom.de=20 > Envoy=E9 : mardi 16 juin 2009 07:02 =C0 : > mdolly@att.com; mary.barnes@nortel.com;=20 > christer.holmberg@ericsson.com; audet@nortel.com; sipcore@ietf.org=20 > Objet : Re: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hi, > Why not to adopt the cause-parameter principle of RFC 4458 and extend=20 > it for other service approaches. > The have a general cause-param for services other then call diversion=20 > and to have explicit cause parameters for free phone, "IN-services",=20 > calling card ect. > Such indications where asked a couples of times from other service=20 > providers. >=20 > BR, >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] Im Auftrag von DOLLY, MARTIN C,=20 > ATTLABS > Gesendet: Montag, 15. Juni 2009 23:10 > An: Mary Barnes; Christer Holmberg; Francois Audet; sipcore@ietf.org > Betreff: Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > no >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 4:38 PM > To: Christer Holmberg; Francois Audet; DOLLY, MARTIN C, ATTLABS;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But, the freephone service can be implemented also with a reg-uri or=20 > reg-uri-alias - NOW if a specific service treats them the same, no big = > deal. The UAS then looks for any of a set of tags to grab the=20 > appropriate hi-entry. >=20 > Mary. >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 3:14 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,=20 > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi, >=20 > >But, still with this approach, I do not think you can get > away with not > looking for multiple tags with the way you envision doing your=20 > services. >=20 > Maybe not - that depends on the service. But, then it will at least be = > possible to figure out what has happended. >=20 > >I think there are others that will implement services on the UAS that > will not need the differentiation that you do - i.e, they care about=20 > the difference between "reg-uri" and "reg-uri-alias". >=20 > My differentiation is based on my understanding of the requirements=20 > that we have. >=20 > If you think we need to differentiate between req-uri and=20 > req-uri-alias, then we should agree on such requirement. Let's not mix = > it with the freephone requirement. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Monday, June 15, 2009 2:53 PM > To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN=20 > C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Christer, >=20 > On your last point, the objective here was to make use of History-Info = > WITHOUT changing any core SIP functionality - it's a whole different=20 > ballgame if we want to do the latter IMHO. However, here's the snippet = > from the end of the response I just sent to Martin (summarizing the=20 > current set of tags), which you may not read: >=20 > " So, we're debating here the differences between the "aor,mapped" and = > "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I=20 > think that "reg-uri-alias" and "reg-uri" are equivalent to "aor,=20 > routed". > And, I think one could consider the "aor,mapped" as predetermined.=20 > But, again 4244bis tags the entries entirely based on what SIP does=20 > and if the 800 number translations (or whatever services) are setup=20 > differently in different proxies, then you can't determine if the=20 > "aor,routed" cases might be "reg-uri-alias" or "reg-uri". Although, I = > am personally confused as to whether an 800 number would always be=20 > "aor, mapped" or "aor, routed" - i.e., I just don't see this being=20 > deterministic and I think that if a service can reach a UAS through=20 > different SIP retargeting mechanisms, then the UAS needs to be aware. >=20 > Also, as I'm going through this, I think we need 3 more tags if we=20 > want the proxy to do the tagging - i.e., I think we need to add "-aor" = > to the "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that = > the proxy will mark in this manner. " >=20 >=20 > Mary.=20 > P.S. Also, I do not think it's a burden to put logic in the UAS - that > was the original intent for SIP - services in the endpoints - SIP is > just the signalling to carry the relevant information. But, I can see > that since the sort of service you mention that does not have=20 > a standard > SIP URI (i.e., user@domain) introduces something that isn't=20 > accomodated > in the basic SIP model, so we may need to add additional logic to the > proxies (I don't like it though).=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 2:34 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi,=20 >=20 > >Correct. But, what I am suggesting is that you distinguish it at the > UAS > >- I'm assuming that the target Request-URI that arrives at the UAS is > something that identifies a client that handles 800 numbers. That > client could be configured such that it knows to look for the=20 > >original 800 number in the mapped URIs or in the reg-alias-URIs or > both.=20 >=20 > 800 numbers is just one example.=20 >=20 > Why should the UAS have to be configured with this information??? I > think that is very limiting and unpractical. >=20 > >Again, if you're making these 800 numbers special and=20 > allowing proxies > to change them in multiple ways (i.e., non-deterministic), then if you > want them tagged special, then you need special logic in the=20 > >proxies to do this. >=20 > The logic is that the AOR is replaced with another AOR, which=20 > belongs to > the same user.=20 >=20 > It's not only for 800 numbers - they are just an example=20 > where it would > be useful. >=20 > And, the proxy is configured to do this - it doesn't do it because it > "thinks" it has to do it :) >=20 > >That doesn't make sense to me, although you could do it that way in a > closed network, in which case you can make sure to always tag them as > whatever you think they should be - so we could define an=20 > >additional value for the tag. But, this is what I don't=20 > think is right > in terms of normal SIP request routing and forwarding, which=20 > is what the > current 4244bis tags have been defined to represent.=20 >=20 > I really don't understand wht this "normal SIP request routing and > forwarding" is all about. Normal SIP request routing and=20 > forwarding has > issues, which were presented in the ua-loose-route draft - and that is > why we are now working on a solution to solve those issues. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 1:23 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi Mary, >=20 > Proxies will tag entries based on the functionality they perform. >=20 > Let's leave req-uri-alias for the moment. >=20 > As I said earlier, one of the issues we have with 4244bis, is that > "mapped" seems to be used BOTH for diversion and when an AOR=20 > is replaced > with another AOR pointing to the same user - e.g. freephone. So, it is > not possible to distinguish between diversion and freephone. >=20 > We think one MUST be able to make that distinguishment,=20 > because you may > have cases where both diversion and service number translation (e.g. > freephone) occurs, and the UAS needs to know which is which. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > =20 >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 9:13 PM > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > It seems to me that the gist of this discussion has been based on the > expectation that independent of how the 800 number is configured, > registered or whatever at a proxy, that there is an expectation of > deterministic behavior in terms of how it's tagged. So, if=20 > 800 numbers > are special and they can end up tagged as either reg-uri-alias or as > mapped, then perhaps the service has to know that it needs to look for > either of those. ISTM that if there is a reason to preserve=20 > that it's an > 800 number (i.e., and not format as a service specific uri),=20 > the service > at the UAS knows that it's special, thus it would need to check the > request-URIs associated with both reg-uri-alias and mapped hi-entries. > I can't see how we can make it work any other way without being > prescriptive of how proxy's MUST tag these entries, which is=20 > not a good > idea IMHO. However, I think these numbers are either special cases at > proxies or something that services know about.=20 >=20 > Mary.=20 >=20 > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 12:47 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary > (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Yes, we need to sort out what to do for that.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, June 15, 2009 10:17 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 > >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, June 15, 2009 6:50 PM > > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > > sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > then reg-uri-alias.=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Saturday, June 13, 2009 01:22 > > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C,=20 > ATTLABS; Barnes,=20 > > > Mary (RICH2:AR00); sipcore@ietf.org > > > Subject: RE: [sipcore] FW: I-D > > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > >=20 > > >=20 > > > Hi, > > >=20 > > > >1) RFC 4244bis > > > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > > Request-URI and it replacing it with a Contact, it will put > > a reg-uri > > > flag (if the Request-URI was the AOR used for=20 > registration), or reg- > > > >uri-alias (if the Request-URI was an alias for the AOR used in > > > registration). > > >=20 > > > And if the Request-URI was a "synonym" for the AOR? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From AUDET@nortel.com Tue Jun 16 08:00:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B68A228C18E for ; Tue, 16 Jun 2009 08:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-PJ4E2UI8Qi for ; Tue, 16 Jun 2009 08:00:10 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id CF9A928C18C for ; Tue, 16 Jun 2009 08:00:09 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5GEuna27155; Tue, 16 Jun 2009 14:56:49 GMT Received: from 47.102.153.241 ([47.102.153.241]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Tue, 16 Jun 2009 14:56:31 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 16 Jun 2009 07:55:18 -0700 From: "Francois Audet" To: Paul Kyzivat , Christer Holmberg Message-ID: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: AcnuknamgsIUSjmxRHKhwzxd/mDPFg== In-Reply-To: <4A379DD1.20600@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 15:00:11 -0000 On Jun16 2009 06:27 , "Paul Kyzivat" wrote: > This concept is still bugging me. > Precisely what do you mean by "new AOR *belongs* to the same user"? It means you believe they are aliases of each others. > And why does that matter? You have said that these might reside in > different domains, and that the tagging will simply be configured. > In the end it isn't the one doing the tagging that cares, rather it is > the one receiving the tagged entry that cares isn't it? So in some sense > this is a matter of the "owner" of the downstream URI instructing the > owner of the upstream URI to tag the entry in a way that the downstream > URI will recognize. I'm not totally convinced myself to be honest. I'm trying to please my coauthors. Basically, it allows you to distinguish between "routing" (i.e., call progresses towards the called user, using various AORs that are aliases of each other), and "retargeting" where call bounces off from one user to another. Why would you want to do that? To provide services that people grew accustomed to such as Freephone, Voicemail, Contact center, and so forth. And yes, there are probably other ways to do so. Fact is, none of these services are exciting enough to justify spending braincells trying to do in a completely different way, so most operators just copy their existing designs. It also makes it easier to interop with existing systems. (Again, I'm also not totally convinced). > Yet doing it *that* abstractly is likely to lead to a tower of babel. > I'm still groping for the semantic meaning of the tag. And in practice > remain unconvinced that it is needed at all. If the owner of the > downstream URI has requested the mapping from the owner of the upstream > URI, doesn't it know what upstream URIs map to it? Can't it check them > by value, without a tag? I think I agree with you here. Maybe Christer or Hans can explain. I don't understand why its needed. > Overall, what I am looking for is a complete partitioning of the space > into disjoint subspaces covering the whole space. In the past, this > partitioning as been done informally and incompletely as "AOR" vs. > "Contact". We all knew that wasn't either disjoint or complete. And we > have always acted as if this is an inherent property of a URI, rather > than a usage context. But of course it isn't that simple - one person's > AOR can be another person's Contact. The current approach is about > describing the role of a URI in context, which at least has a chance to > be determinable, so its at least on the right track. >=20 > The trouble with H-I in this regard is that there seems no good reason > to believe that middleboxes will preserve the entries that will > ultimately be required. We actually fixed that particular problem in 4244bis by making the entries mandatory, and relying on anonymizing entries when privacy is required. > Thanks, > Paul >=20 >> So, in case of diversion, where the user is changed, I assume "mp" is us= ed. >>=20 >> For freephone, where the user is not changed, one could use "rt". But, I >> don't think it matters in which domain the translation takes place, or >> whether the new AOR is an alias or not. >>=20 >> So, my proposal would be something like: >>=20 >> rt : The entry is "routed", i.e., it is either a no-opt like a proxy >> forwarding within >> a domain, predetermined by a maddr in the Request-URI, or when the >> request-URI is changed to a new URI that represent the same user. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> =20 >>=20 >>> -----Original Message----- >>> From: Francois Audet [mailto:audet@nortel.com] >>> Sent: 16. kes=E4kuuta 2009 4:44 >>> To: Christer Holmberg; Hans Erik van Elburg; Mary Barnes; >>> Shida Schubert >>> Cc: sipcore@ietf.org >>> Subject: draft-barnes-sipcore-rfc4244bis and target-uri >>>=20 >>> All right guys, >>>=20 >>> I've been thinking about this. >>>=20 >>> It seems to me that what we want to capture is: >>> 1) If the target is an AOR, a contact, or a routing URI >>> (maddr, noop intra-domain, or noop >>> forward to next domain, or strict routing). >>> 2) In the case that the target is an AOR, then if that AOR is >>> known to be an alias for the previous >>> one, or if it is mapped to another AOR. >>>=20 >>> It seems to me that a Proxy should mark a Previous entry in >>> H-I with aor if it determines that it owns this AOR. Just as >>> Hans's current target-uri draft. >>>=20 >>> Now, for the mapped vs routed (versus reg-contact, etc.), >>> instead of marking the Previous entry, we should mark the >>> OUTGOING (i.e., New) entry instead. This would make the procedures of >>> 7.2.1 & 7.2.2 of target-URI draft clearer. >>>=20 >>> Specifically, the logic would be: >>>=20 >>> When proxy receives an incoming request with H-I, it adds an >>> ;aor tag to that incoming entry if it determines that it is >>> responsible for the AOR and. >>>=20 >>> Also, if there was no Hi-entry at all (i.e., it came from a >>> UAC), and the Proxy creates then two entries, the first one >>> in this case would also have the ;aor tag associated to it. >>>=20 >>> For the Outgoing entry, I would see the following tags: >>>=20 >>> rc : The entry is an explicit registered contact >>> (i.e., it was provided in a REGISTER message) >>>=20 >>> ic : The entry is an implicit registered contact >>> (i.e., it's exactly as a registered contact, >>> but was not discovered using SIP Registration: >>> it could have been manually configured >>> or done with a proprietary mechanism). >>>=20 >>> (TBD: we could debate if we need both rc and >>> irc, but I think we do). >>>=20 >>> mp : The request-URI is changed to a new URI that >>> represent another user. >>>=20 >>> rt : The entry is "routed", i.e., it is either a >>> no-opt like a proxy forwarding within >>> a domain, predetermined by a maddr in the >>> Request-URI, or when proxy is NOT responsible >>> for domain, or the address is an alias for the >>> incoming URI. >>>=20 >>> So, to give an example. >>>=20 >>> Say Alice calls Bob. Bob is forwarded to freephone. Freephone >>> routes to Carol. >>>=20 >>> The History-info at Carol would look like this: >>>=20 >>> Alice -> example.com >>> Nothing because UAC typically doesn't send H-I (otherwise, it >>> would be as per Index 1 in next entry, but without the AOR. >>>=20 >>> example.com -> freephone@example.net >>> History-Info: ;index=3D1;aor >>> History-Info: ;index=3D1.1;mp >>>=20 >>> example.net -> carol@example.net >>> History-Info: ;index=3D1;aor >>> History-Info: ;index=3D1.1;mp;aor >>> <- aor is added >>> History-Info: ;index=3D1.1.1;rt;aor } >>> Two entries are >>> History-Info: ;index=3D1.1.1.1;rc } >>> added at same time >>>=20 >>> Also, I don't think we need to define an equivalent to the >>> "reg-uri-alias" anymore. >>> If Freephone was configured to go to +14085551212 instead of >>> the registered Contact (assuming +14085551212 was an Alias >>> AOR for carol@example.net), the last H-I entries would look >>> like this instead: >>>=20 >>> example.net -> carol@example.net >>> History-Info: ;index=3D1;aor >>> History-Info:=20 >>> ;index=3D1.1;mp;aor <- >>> aor is added >>> History-Info: ;index=3D1.1.1;rt;aor >>> <- aor is added >>> History-Info: ;index=3D1.1.1.1;rt;aor >>> } Two entries are >>> History-Info: ;index=3D1.1.1.1.1;rc >>> } added at same time >>>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>=20 From AUDET@nortel.com Tue Jun 16 08:01:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90B803A69C4 for ; Tue, 16 Jun 2009 08:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.282 X-Spam-Level: X-Spam-Status: No, score=-4.282 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, GB_I_LETTER=-2, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDxehvSw-DWz for ; Tue, 16 Jun 2009 08:01:38 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 338483A6B97 for ; Tue, 16 Jun 2009 08:01:38 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5GExcc21060; Tue, 16 Jun 2009 14:59:39 GMT Received: from 47.102.153.241 ([47.102.153.241]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Tue, 16 Jun 2009 14:57:56 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 16 Jun 2009 07:27:23 -0700 From: "Francois Audet" To: "Mary Barnes" , Christer Holmberg , Hans Erik van Elburg , Shida Schubert Message-ID: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAI5l3MAAB8/aW In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88DA09@zrc2hxm0.corp.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 15:01:39 -0000 Correct. To be more precise, the "Type of URI" has only two values, AOR, and "nothing" (i.e., you don't recognize it as a URI). You are correct about the "two-stages". And the aliases I have at the bottom are NOT registered contact necessarily. When an alias is programmed (typically in a Proxy), say, for a freephone service, it doesn't know if it will be a registered contact, or something else. Normally, it would be another AOR. For example, 18005551212@example.com;user=phone could be mapped to an alias of bob@example.com. On the issue of why "short two-letter names", the official reason would be to shorten the length of the headers (HI can be quite large), save the planet etc. (The "real' reason are: 1- To facilitate my life when writing the call flows by increasing the chances that the entries fit on one line :-) 2- UNIX geekiness :-) ) Finally, on the "alias" concept: the aliases are not lost. I've entered them as a specific entry. In the last example: History-Info: ;index=1.1;mp;aor <- aor is added History-Info: ;index=1.1.1;rt;aor <- aor is added The same could apply at the end of sequence. For example, if I register with To: and is an alias, in the HI there would be an entry for followed by one for , both flagged as ;aor. On Jun16 2009 06:52 , "Barnes, Mary (RICH2:AR00)" wrote: > So, to summarize: > - the old entry is tagged with the "type of URI" > - the new entry is tagged with the mechanism by which the URI was > determined > > Is that correct? That's actually backwards from what I just told Dean, > but does make sense since you don't know anything about the "type of > URI" until it reaches a domain that is responsible for it. > > I have a couple comments/questions embedded below to make sure I > understand, as this is slightly different than what I had envisioned > when we discussed it yesterday. > > Mary. > > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 8:44 PM > To: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary (RICH2:AR00); > Shida Schubert > Cc: sipcore@ietf.org > Subject: draft-barnes-sipcore-rfc4244bis and target-uri > > All right guys, > > I've been thinking about this. > > It seems to me that what we want to capture is: > 1) If the target is an AOR, a contact, or a routing URI (maddr, noop > intra-domain, or noop > forward to next domain, or strict routing). > 2) In the case that the target is an AOR, then if that AOR is known to > be an alias for the previous > one, or if it is mapped to another AOR. > > It seems to me that a Proxy should mark a Previous entry in H-I with aor > if it determines that it owns this AOR. Just as Hans's current > target-uri draft. > > Now, for the mapped vs routed (versus reg-contact, etc.), instead of > marking the Previous entry, we should mark the OUTGOING (i.e., New) > entry instead. This would make the procedures of > 7.2.1 & 7.2.2 of target-URI draft clearer. > > [MB] I think this gets to the concern I had earlier about it looking to > be "two stage". [/MB] > > Specifically, the logic would be: > > When proxy receives an incoming request with H-I, it adds an ;aor tag to > that incoming entry if it determines that it is responsible for the AOR > and. > > Also, if there was no Hi-entry at all (i.e., it came from a UAC), and > the Proxy creates then two entries, the first one in this case would > also have the ;aor tag associated to it. > > For the Outgoing entry, I would see the following tags: > > rc : The entry is an explicit registered contact (i.e., it > was provided in a REGISTER message) > > ic : The entry is an implicit registered contact (i.e., it's > exactly as a registered contact, > but was not discovered using SIP Registration: it could > have been manually configured > or done with a proprietary mechanism). > > (TBD: we could debate if we need both rc and irc, but I > think we do). > > mp : The request-URI is changed to a new URI that represent > another user. > > rt : The entry is "routed", i.e., it is either a no-opt like > a proxy forwarding within > a domain, predetermined by a maddr in the Request-URI, > or when proxy is NOT responsible > for domain, or the address is an alias for the incoming > URI. > [MB] I'm slightly confused as to why alias are in this bucket - aren't > aliases also registered contacts? > > Also, I would prefer to tag these explictly as we did with the current > definition of hi-target in 4244bis. I don't think it costs anything and > I think it could be useful for debug/diagnostics. Also, I would prefer > we expand the labels a tad, something like: > reg-exp > reg-imp > mapped > route > reg-alias > > I could live without the alias, but per my comment above, it's not clear > to me that these are "routed". > [/MB] > > So, to give an example. > > Say Alice calls Bob. Bob is forwarded to freephone. Freephone routes to > Carol. > > The History-info at Carol would look like this: > > Alice -> example.com > Nothing because UAC typically doesn't send H-I (otherwise, it would be > as per Index 1 in next entry, but without the AOR. > > example.com -> freephone@example.net > History-Info: ;index=1;aor > History-Info: ;index=1.1;mp > > example.net -> carol@example.net > History-Info: ;index=1;aor > History-Info: ;index=1.1;mp;aor <- aor is > added > History-Info: ;index=1.1.1;rt;aor } Two > entries are > History-Info: ;index=1.1.1.1;rc } added at > same time > > Also, I don't think we need to define an equivalent to the > "reg-uri-alias" anymore. > [MB] I'm not entirely comfortable with losing the alias concept. I would > think it could be useful for debug/diagnostic use cases. [/MB] > > If Freephone was configured to go to +14085551212 instead of the > registered Contact (assuming +14085551212 was an Alias AOR for > carol@example.net), the last H-I entries would look like this instead: > > example.net -> carol@example.net > History-Info: ;index=1;aor > History-Info: ;index=1.1;mp;aor > <- aor is added > History-Info: ;index=1.1.1;rt;aor <- aor is > added > History-Info: ;index=1.1.1.1;rt;aor } Two > entries are > History-Info: ;index=1.1.1.1.1;rc } added > at same time From AUDET@nortel.com Tue Jun 16 08:04:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBA633A69C4 for ; Tue, 16 Jun 2009 08:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.449 X-Spam-Level: X-Spam-Status: No, score=-4.449 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qr0wSVtrqNhZ for ; Tue, 16 Jun 2009 08:04:42 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0F99D28C19B for ; Tue, 16 Jun 2009 08:04:35 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5GExnc21115; Tue, 16 Jun 2009 14:59:50 GMT Received: from 47.102.153.241 ([47.102.153.241]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Tue, 16 Jun 2009 14:57:57 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 16 Jun 2009 07:46:03 -0700 From: "Francois Audet" To: Paul Kyzivat , Dean Willis Message-ID: Thread-Topic: [sipcore] Freephone discussion (Was: The functional differences between 4244bis and target- uri) Thread-Index: AcnukSvXZzigAiMzTSu/xhObGlyJoA== In-Reply-To: <4A37A0D9.1080506@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "DOLLY, MARTIN C, ATTLABS" , sipcore@ietf.org Subject: Re: [sipcore] Freephone discussion (Was: The functional differences between 4244bis and target- uri) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 15:04:42 -0000 Freephone is just a form of target diversion where the forwarder knows that the new target represents the same user. Call Forwarding (using PSTN terminology) is a form of target diversion where the forwarder does not know if the new target represents the same user (chances are it is not the same user, although people often forward their calls to another phone number they have, even if these phone numbers are not correlated anywhere). In my proposal, I'm handling the difference with the presence of the ;mp tag (mapped) which means the second case, i.e., you have no knowledge that the two URIs belong to the same user. How service providers use it to charge or not is totally irrelevant and outside the scope of a technical spec. I will also note that there are free versions of similar services out there. On Jun16 2009 06:40 , "Paul Kyzivat" wrote: > (I changed the subject again) > > On one hand I agree with Dean that the freephone semantics are legacy > baggage that are inextricably entwined with the legacy implementation. > There is little we can do to "fix" it. But when interoperating with the > legacy telephone network it will continue to be an elephant in the room > and cannot simply be ignored. > > We could no doubt devise some much more useful alternatives to the "800" > style of freephone service when the call is sip end to end. (I've > thought for a long time that "who pays" should be negotiated in much the > way that QoS is. Perhaps preconditions could be used to do it - even the > e2e vs segmented models make sense.) But we will not be doing that in > ietf since we never discuss billing in ietf. > > In Dean's example below, what is free? And who would have been billed > for it if it hadn't been free? > > Thanks, > Paul > > Dean Willis wrote: >> Francois Audet wrote: >>> Perhaps you are correct. >>> >>> I must admit I'm having trouble understanding the sutleties of the >>> freephone service. >> >> It's not that complicated. >> >> Think of it as an AOR (the freephone number) to which a contact (the >> service nuumber) is registered. >> >> Unfortunately, said contact is also registered to other AORs, and the >> B2BUA that terminates the call needs to know which AOR was used so it >> can figure out 1) how to bill for the call, and 2) how to route the call >> within the call center and what to display on the UAS. >> >> My proposal: This is an obtuse legacy. Don't build SIP-based systems on >> the same model; contacts are cheap, locally-mintable, and you can use a >> different one for every AOR. >> >> If you THINK you have a freephone problem that needs a specification >> extension to deal with it, you probably just have a badly designed >> deployment. Rethink the problem without forcibly holding your head in a >> bell shape. >> >> Remember, this is not your mother's phone network. >> >> -- >> Dean >> >> From dean.willis@softarmor.com Tue Jun 16 09:51:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693F23A6AFF for ; Tue, 16 Jun 2009 09:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxtAZS9gjvm5 for ; Tue, 16 Jun 2009 09:51:28 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6ED843A695F for ; Tue, 16 Jun 2009 09:51:28 -0700 (PDT) Received: from [192.168.2.2] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n5GGpNZi000364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Jun 2009 11:51:25 -0500 Message-ID: <4A37CD86.7080505@softarmor.com> Date: Tue, 16 Jun 2009 11:51:18 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Mary Barnes References: <4A374056.6050001@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1E83E210@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E83E210@zrc2hxm0.corp.nortel.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Another approach to preservation of targeting information on a proxy-rewrite of request URI (Request URI Replacement) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 16:51:29 -0000 Mary Barnes wrote: > Dean, > > I do like the idea of using the URI parameter, but I've been > consistently outvoted on that one. > > I think with the latest proposal that Francois posted we capture three > things you identify: > 1) why - this is how we'll tag the "old" hi-entry - i.e., the mechanism > by which the new URI was determined. > 2) what kind of URI - that's how we'll tag the "new" hi-entry > 3) why did we do this - this is already covered by the reason header I believe there are instances of 1, 2, and 3 that don't exist in the current draft, possibly because we haven't invented them yet. We will be extending this thing forever. But do properly constructed applications really need this information encoded in this way? I have always held that they do not; this is yet another holdover of PSTN call processing logic, and we do ourselves and the Internet a disservice by perpetuating it. For specific applications in which the proxy has the relevant information and for which the UAS has a need for this information, the rewritten request URI allows us to encode the information from proxy to UAS without any particular need for standardization. It's arguable as to whether previous-Request-URI encoding even needs standardization, although doing so is fairly straightforward. In other words, History-Info, despite being a clever solution, is solving the wrong problem and thereby encouraging PSTN-style processing logic. Yes, we have some general consensus to go that way, but it's still not an approach I like. We also had general consensus to do a lot of other PSTN-like things, including early media, reliable provisional preconditions, etc. almost all of which have turned out to be implementation and functionality nightmares because they assume an entirely different operating environment from the Internet. We should really try to learn from our mistakes. -- Dean From pkyzivat@cisco.com Tue Jun 16 10:17:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3B543A6BEF for ; Tue, 16 Jun 2009 10:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgqXEAEOBzrK for ; Tue, 16 Jun 2009 10:17:49 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AAB363A6ACC for ; Tue, 16 Jun 2009 10:17:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,230,1243814400"; d="scan'208";a="325145445" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 16 Jun 2009 17:18:00 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5GHI01h012280; Tue, 16 Jun 2009 10:18:00 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n5GHHwOO010610; Tue, 16 Jun 2009 17:18:00 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 13:18:00 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 13:17:59 -0400 Message-ID: <4A37D3C7.4050705@cisco.com> Date: Tue, 16 Jun 2009 13:17:59 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dean Willis References: <4A374056.6050001@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1E83E210@zrc2hxm0.corp.nortel.com> <4A37CD86.7080505@softarmor.com> In-Reply-To: <4A37CD86.7080505@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2009 17:17:59.0485 (UTC) FILETIME=[65B0FED0:01C9EEA6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2914; t=1245172680; x=1246036680; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Another=20approach=20to=20p reservation=20of=20targeting=20information=0A=20on=20a=20pro xy-rewrite=20of=20request=20URI=20(Request=20URI=20Replaceme nt) |Sender:=20; bh=f5sCNSFatrgwHpRCWInWQS04F92Awsve1syQxRIFQHo=; b=NQgU33WFUI7fAC2cQAKlzbhf5skBhoDW9js0/ho1RI4jXxEtQZI363qH5T 5jPWu66S3/VnqZhZcBjKQvg7nMjAB4c1DjZ1y8T8t4jmM08fn0WpoHi1YfCF xJvYfEkD+V; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sipcore@ietf.org Subject: Re: [sipcore] Another approach to preservation of targeting information on a proxy-rewrite of request URI (Request URI Replacement) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:17:51 -0000 Dean Willis wrote: > Mary Barnes wrote: >> Dean, >> >> I do like the idea of using the URI parameter, but I've been >> consistently outvoted on that one. >> >> I think with the latest proposal that Francois posted we capture three >> things you identify: >> 1) why - this is how we'll tag the "old" hi-entry - i.e., the mechanism >> by which the new URI was determined. >> 2) what kind of URI - that's how we'll tag the "new" hi-entry >> 3) why did we do this - this is already covered by the reason header > > I believe there are instances of 1, 2, and 3 that don't exist in the > current draft, possibly because we haven't invented them yet. We will > be extending this thing forever. > > But do properly constructed applications really need this information > encoded in this way? I have always held that they do not; this is yet > another holdover of PSTN call processing logic, and we do ourselves and > the Internet a disservice by perpetuating it. > > For specific applications in which the proxy has the relevant > information and for which the UAS has a need for this information, the > rewritten request URI allows us to encode the information from proxy to > UAS without any particular need for standardization. It's arguable as to > whether previous-Request-URI encoding even needs standardization, > although doing so is fairly straightforward. While I like the approach, I think you are over-promising. It still *does* require standardization: - the rur parameter would need to be standardized - that would include when it should be used, and what it means if its found in a request you receive. And then I suppose people would want different parameters to express nuances about why the rur url is there. And it would run up against implementations that can't handle long R-URIs. (I don't have much sympathy for them, but they continue to exist.) Aside from syntax, this is basically just a subset of H-I. But it can only encode one path through the tree - 1, 1.1, 1.1.1, ... (Or course that is usually the path you care about.) Thanks, Paul > In other words, History-Info, despite being a clever solution, is > solving the wrong problem and thereby encouraging PSTN-style processing > logic. Yes, we have some general consensus to go that way, but it's > still not an approach I like. We also had general consensus to do a lot > of other PSTN-like things, including early media, reliable provisional > preconditions, etc. almost all of which have turned out to be > implementation and functionality nightmares because they assume an > entirely different operating environment from the Internet. We should > really try to learn from our mistakes. > > -- > Dean > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From AUDET@nortel.com Tue Jun 16 10:20:17 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCA13A6D77 for ; Tue, 16 Jun 2009 10:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNC5w1zFReJO for ; Tue, 16 Jun 2009 10:20:16 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 5B0D33A6BEF for ; Tue, 16 Jun 2009 10:20:16 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5GHKJc10959; Tue, 16 Jun 2009 17:20:19 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 12:19:27 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri thread-index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAFn+ocAAVBjIQ References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! <4 A36AC9C.3060 509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Christer Holmberg" , "Hans Erik van Elburg" , "Mary Barnes" , "Shida Schubert" Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:20:17 -0000 See below.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Tuesday, June 16, 2009 00:39 > To: Audet, Francois (SC100:3055); Hans Erik van Elburg;=20 > Barnes, Mary (RICH2:AR00); Shida Schubert > Cc: sipcore@ietf.org > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 >=20 >=20 > Hi Francois, >=20 > "rc" and "ic" look rather ok. But, for "ic" you need to=20 > change "but was not discovered using SIP Registration",=20 > because you may discover it using the P-Associated-URI header=20 > (if you support it). So, I propose something like: >=20 > ic : The entry is an implicit registered contact=20 > (i.e., it's exactly as a registered contact, > but was not provided in a REGISTER request: it=20 > could have been manually configured > or done with a proprietary mechanism). >=20 >=20 > But, I think there is a small missunderstading for the=20 > AOR-to-AOR cases. >=20 > We don't think you need to know whether the new AOR is an=20 > alias or not. You need to know whether the new AOR belongs to=20 > the same user or not. To me, that is the definition of an alias. > So, in case of diversion, where the user is changed, I assume=20 > "mp" is used. Correct. > For freephone, where the user is not changed, one could use=20 > "rt". But, I don't think it matters in which domain the=20 > translation takes place, or whether the new AOR is an alias or not. Correct: it would be rt. > So, my proposal would be something like: >=20 > rt : The entry is "routed", i.e., it is either a=20 > no-opt like a proxy forwarding within > a domain, predetermined by a maddr in the=20 > Request-URI, or when the request-URI is changed to a new URI=20 > that represent the same user. I'm ok with that. From mary.barnes@nortel.com Tue Jun 16 10:22:14 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA5D73A6DA1 for ; Tue, 16 Jun 2009 10:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.331 X-Spam-Level: X-Spam-Status: No, score=-6.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6j7dt11xuKT for ; Tue, 16 Jun 2009 10:22:14 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id C766F3A6D9F for ; Tue, 16 Jun 2009 10:22:13 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5GHKha02684; Tue, 16 Jun 2009 17:20:43 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 12:24:32 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E88E100@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A37CD86.7080505@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Another approach to preservation of targeting information on a proxy-rewrite of request URI (Request URI Replacement) thread-index: AcnuorqQSh45kKAmTmaHvTPdw3DxRwAAnsYg References: <4A374056.6050001@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1E83E210@zrc2hxm0.corp.nortel.com> <4A37CD86.7080505@softarmor.com> From: "Mary Barnes" To: "Dean Willis" Cc: sipcore@ietf.org Subject: Re: [sipcore] Another approach to preservation of targeting information on a proxy-rewrite of request URI (Request URI Replacement) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:22:15 -0000 Dean, We definitely do not want to extend this forever, which is why the proposed solution is to completely tag the things now - the 1), which is actually what we are tagging the new with (I was backwards in my initial response), is based upon the mechanisms that are currently described in RFC 3261 in terms of how the new target(s) for the request are determined. =20 The 2) is also not so far from core SIP - we're tagging that the entry is an aor for the intended recipient user - we know that because we know how the Proxy handles that incoming request URI - i.e., it belongs to the domain and the proxy can use a variety of mechanisms to determine the new Request URI (per the mechanism tag). =20 What these tags mean in terms of the end application is out of scope for 4244bis, but would be described in the target-uri document (IF we agree to the approach - right now both docs have solution proposals). But, yes, we are providing the enabler for (ugly) PSTNish applications and that was the primary reason why there was so much opposition to History-Info in the first place eons ago.=20 Now, I fully agree that the fact that not all of the URIs are of the form user@domain makes things ugly, but that's an ugliness we are living with across the board and a fact of (network) life for a while - and yes, the model is not Internet - this 800 junk and any of the phone numbers in the URIs and the handling thereof is modeled after the translations done by PSTN switches. And, I would absolutely love to be able to say that the 800 number MUST be converted at the gateway to a user@domain form with whatever URI parameters are necessary for an end application to map it to these PSTNish features. But, I don't think I'll win that battle, although I do agree it makes things very ugly and hacky.=20 I really, really think this sort of debate would make a great Dr. Phil show. I can try to arrange something for LA next March - I have some local connections ;) Mary.=20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Tuesday, June 16, 2009 11:51 AM To: Barnes, Mary (RICH2:AR00) Cc: sipcore@ietf.org Subject: Re: [sipcore] Another approach to preservation of targeting information on a proxy-rewrite of request URI (Request URI Replacement) Mary Barnes wrote: > Dean, >=20 > I do like the idea of using the URI parameter, but I've been=20 > consistently outvoted on that one. >=20 > I think with the latest proposal that Francois posted we capture three > things you identify: > 1) why - this is how we'll tag the "old" hi-entry - i.e., the=20 > mechanism by which the new URI was determined. > 2) what kind of URI - that's how we'll tag the "new" hi-entry > 3) why did we do this - this is already covered by the reason header I believe there are instances of 1, 2, and 3 that don't exist in the current draft, possibly because we haven't invented them yet. We will be extending this thing forever. But do properly constructed applications really need this information encoded in this way? I have always held that they do not; this is yet another holdover of PSTN call processing logic, and we do ourselves and the Internet a disservice by perpetuating it. For specific applications in which the proxy has the relevant information and for which the UAS has a need for this information, the rewritten request URI allows us to encode the information from proxy to UAS without any particular need for standardization. It's arguable as to whether previous-Request-URI encoding even needs standardization, although doing so is fairly straightforward. In other words, History-Info, despite being a clever solution, is solving the wrong problem and thereby encouraging PSTN-style processing logic. Yes, we have some general consensus to go that way, but it's still not an approach I like. We also had general consensus to do a lot of other PSTN-like things, including early media, reliable provisional preconditions, etc. almost all of which have turned out to be implementation and functionality nightmares because they assume an entirely different operating environment from the Internet. We should really try to learn from our mistakes. -- Dean From AUDET@nortel.com Tue Jun 16 10:24:07 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A93C3A6DA6 for ; Tue, 16 Jun 2009 10:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=-2.200, BAYES_00=-2.599, MANGLED_LOAN=2.3, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXKWPMO5cHCq for ; Tue, 16 Jun 2009 10:24:05 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 3A48D28C196 for ; Tue, 16 Jun 2009 10:23:43 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5GHNZc11922; Tue, 16 Jun 2009 17:23:35 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 12:23:18 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E88E10D@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt thread-index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYAAADaOvAAAEZYIAAAZd2gAAEEtLAAASSLAAAQUjFAAAQ6qeAABxuA8AAOtKhg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com><1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>!<1ECE0EB50388174790F9694F77522CCF1E83DBEB@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA0375EC26@gaalpa1msgusr7e.ugd.att.com> <9886E5FCA6D76549A3011068483A4BD404827AB8@S4DE8PSAAQB.mitte.t-com.de> <9ECCF01B52E7AB408A7EB853526421412F59C6@ftrdmel0.rd.francetelecom.fr> From: "Francois Audet" To: "Christer Holmberg" , , , , "Mary Barnes" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:24:07 -0000 I agree with christer. (Holy Cow! Twice in 5 minutes!)=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Tuesday, June 16, 2009 03:31 > To: bruno.chatras@orange-ftgroup.com; R.Jesske@telekom.de;=20 > mdolly@att.com; Barnes, Mary (RICH2:AR00); Audet, Francois=20 > (SC100:3055); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi, >=20 > >I would go even further. There are cases where it is useful to keep=20 > >track of the services invoked during the establishment of a session,=20 > >irrespective of whether these services have modified the=20 > R-URI or not.=20 > >To achieve this, an application server providing service X=20 > would insert=20 > >an entry in the History-Info header field with hi-target=3Dnoop, an=20 > >unmodified R-URI and an extended cause-param set to a value=20 > >representing service "X". >=20 > I think that should be a completely separate discussion. >=20 > It is an interesting topic, but I think you would need to=20 > start it in DISPATCH or BLISS, because I think it is far=20 > beyond the scope of both 4244bis and target delivery :) >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > > -----Message d'origine----- > > De : sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] De la part de R.Jesske@telekom.de=20 > > Envoy=E9 : mardi 16 juin 2009 07:02 =C0 : > > mdolly@att.com; mary.barnes@nortel.com;=20 > > christer.holmberg@ericsson.com; audet@nortel.com; sipcore@ietf.org=20 > > Objet : Re: [sipcore] FW: I-D=20 > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > Hi, > > Why not to adopt the cause-parameter principle of RFC 4458=20 > and extend=20 > > it for other service approaches. > > The have a general cause-param for services other then call=20 > diversion=20 > > and to have explicit cause parameters for free phone,=20 > "IN-services",=20 > > calling card ect. > > Such indications where asked a couples of times from other service=20 > > providers. > >=20 > > BR, > >=20 > > Roland > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] Im Auftrag von DOLLY, MARTIN C,=20 > > ATTLABS > > Gesendet: Montag, 15. Juni 2009 23:10 > > An: Mary Barnes; Christer Holmberg; Francois Audet; sipcore@ietf.org > > Betreff: Re: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > no > >=20 > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: Monday, June 15, 2009 4:38 PM > > To: Christer Holmberg; Francois Audet; DOLLY, MARTIN C, ATTLABS;=20 > > sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > But, the freephone service can be implemented also with a=20 > reg-uri or=20 > > reg-uri-alias - NOW if a specific service treats them the=20 > same, no big=20 > > deal. The UAS then looks for any of a set of tags to grab the=20 > > appropriate hi-entry. > >=20 > > Mary. > >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, June 15, 2009 3:14 PM > > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,=20 > > MARTIN C, ATTLABS; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi, > >=20 > > >But, still with this approach, I do not think you can get > > away with not > > looking for multiple tags with the way you envision doing your=20 > > services. > >=20 > > Maybe not - that depends on the service. But, then it will=20 > at least be=20 > > possible to figure out what has happended. > >=20 > > >I think there are others that will implement services on=20 > the UAS that > > will not need the differentiation that you do - i.e, they=20 > care about=20 > > the difference between "reg-uri" and "reg-uri-alias". > >=20 > > My differentiation is based on my understanding of the requirements=20 > > that we have. > >=20 > > If you think we need to differentiate between req-uri and=20 > > req-uri-alias, then we should agree on such requirement.=20 > Let's not mix=20 > > it with the freephone requirement. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Barnes, Mary (RICH2:AR00) > > Sent: Monday, June 15, 2009 2:53 PM > > To: 'Christer Holmberg'; Audet, Francois (SC100:3055);=20 > DOLLY, MARTIN=20 > > C, ATTLABS; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > Christer, > >=20 > > On your last point, the objective here was to make use of=20 > History-Info=20 > > WITHOUT changing any core SIP functionality - it's a whole=20 > different=20 > > ballgame if we want to do the latter IMHO. However, here's=20 > the snippet=20 > > from the end of the response I just sent to Martin (summarizing the=20 > > current set of tags), which you may not read: > >=20 > > " So, we're debating here the differences between the=20 > "aor,mapped" and=20 > > "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I=20 > > think that "reg-uri-alias" and "reg-uri" are equivalent to "aor,=20 > > routed". > > And, I think one could consider the "aor,mapped" as predetermined.=20 > > But, again 4244bis tags the entries entirely based on what SIP does=20 > > and if the 800 number translations (or whatever services) are setup=20 > > differently in different proxies, then you can't determine if the=20 > > "aor,routed" cases might be "reg-uri-alias" or "reg-uri". =20 > Although, I=20 > > am personally confused as to whether an 800 number would always be=20 > > "aor, mapped" or "aor, routed" - i.e., I just don't see this being=20 > > deterministic and I think that if a service can reach a UAS through=20 > > different SIP retargeting mechanisms, then the UAS needs to=20 > be aware. > >=20 > > Also, as I'm going through this, I think we need 3 more tags if we=20 > > want the proxy to do the tagging - i.e., I think we need to=20 > add "-aor"=20 > > to the "predetermined", "reg-uri" and "reg-uri-alias" IF we=20 > agree that=20 > > the proxy will mark in this manner. " > >=20 > >=20 > > Mary.=20 > > P.S. Also, I do not think it's a burden to put logic in the=20 > UAS - that > > was the original intent for SIP - services in the endpoints - SIP is > > just the signalling to carry the relevant information. But,=20 > I can see > > that since the sort of service you mention that does not have=20 > > a standard > > SIP URI (i.e., user@domain) introduces something that isn't=20 > > accomodated > > in the basic SIP model, so we may need to add additional=20 > logic to the > > proxies (I don't like it though).=20 > >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, June 15, 2009 2:34 PM > > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > > MARTIN C, ATTLABS; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi,=20 > >=20 > > >Correct. But, what I am suggesting is that you distinguish=20 > it at the > > UAS > > >- I'm assuming that the target Request-URI that arrives at=20 > the UAS is > > something that identifies a client that handles 800 numbers. That > > client could be configured such that it knows to look for the=20 > > >original 800 number in the mapped URIs or in the reg-alias-URIs or > > both.=20 > >=20 > > 800 numbers is just one example.=20 > >=20 > > Why should the UAS have to be configured with this information??? I > > think that is very limiting and unpractical. > >=20 > > >Again, if you're making these 800 numbers special and=20 > > allowing proxies > > to change them in multiple ways (i.e., non-deterministic),=20 > then if you > > want them tagged special, then you need special logic in the=20 > > >proxies to do this. > >=20 > > The logic is that the AOR is replaced with another AOR, which=20 > > belongs to > > the same user.=20 > >=20 > > It's not only for 800 numbers - they are just an example=20 > > where it would > > be useful. > >=20 > > And, the proxy is configured to do this - it doesn't do it=20 > because it > > "thinks" it has to do it :) > >=20 > > >That doesn't make sense to me, although you could do it=20 > that way in a > > closed network, in which case you can make sure to always=20 > tag them as > > whatever you think they should be - so we could define an=20 > > >additional value for the tag. But, this is what I don't=20 > > think is right > > in terms of normal SIP request routing and forwarding, which=20 > > is what the > > current 4244bis tags have been defined to represent.=20 > >=20 > > I really don't understand wht this "normal SIP request routing and > > forwarding" is all about. Normal SIP request routing and=20 > > forwarding has > > issues, which were presented in the ua-loose-route draft -=20 > and that is > > why we are now working on a solution to solve those issues. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, June 15, 2009 1:23 PM > > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > > MARTIN C, ATTLABS; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi Mary, > >=20 > > Proxies will tag entries based on the functionality they perform. > >=20 > > Let's leave req-uri-alias for the moment. > >=20 > > As I said earlier, one of the issues we have with 4244bis, is that > > "mapped" seems to be used BOTH for diversion and when an AOR=20 > > is replaced > > with another AOR pointing to the same user - e.g.=20 > freephone. So, it is > > not possible to distinguish between diversion and freephone. > >=20 > > We think one MUST be able to make that distinguishment,=20 > > because you may > > have cases where both diversion and service number translation (e.g. > > freephone) occurs, and the UAS needs to know which is which. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > > =20 > >=20 > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: Monday, June 15, 2009 9:13 PM > > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; > > sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > It seems to me that the gist of this discussion has been=20 > based on the > > expectation that independent of how the 800 number is configured, > > registered or whatever at a proxy, that there is an expectation of > > deterministic behavior in terms of how it's tagged. So, if=20 > > 800 numbers > > are special and they can end up tagged as either reg-uri-alias or as > > mapped, then perhaps the service has to know that it needs=20 > to look for > > either of those. ISTM that if there is a reason to preserve=20 > > that it's an > > 800 number (i.e., and not format as a service specific uri),=20 > > the service > > at the UAS knows that it's special, thus it would need to check the > > request-URIs associated with both reg-uri-alias and mapped=20 > hi-entries. > > I can't see how we can make it work any other way without being > > prescriptive of how proxy's MUST tag these entries, which is=20 > > not a good > > idea IMHO. However, I think these numbers are either=20 > special cases at > > proxies or something that services know about.=20 > >=20 > > Mary.=20 > >=20 > > -----Original Message----- > > From: Audet, Francois (SC100:3055) > > Sent: Monday, June 15, 2009 12:47 PM > > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary > > (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > Yes, we need to sort out what to do for that.=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Monday, June 15, 2009 10:17 > > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C,=20 > ATTLABS; Barnes,=20 > > > Mary (RICH2:AR00); sipcore@ietf.org > > > Subject: RE: [sipcore] FW: I-D > > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > >=20 > > >=20 > > > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 > > >=20 > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: Monday, June 15, 2009 6:50 PM > > > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > > > sipcore@ietf.org > > > Subject: RE: [sipcore] FW: I-D > > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > >=20 > > > then reg-uri-alias.=20 > > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > > Sent: Saturday, June 13, 2009 01:22 > > > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C,=20 > > ATTLABS; Barnes,=20 > > > > Mary (RICH2:AR00); sipcore@ietf.org > > > > Subject: RE: [sipcore] FW: I-D > > > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > >1) RFC 4244bis > > > > > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > > > Request-URI and it replacing it with a Contact, it will put > > > a reg-uri > > > > flag (if the Request-URI was the AOR used for=20 > > registration), or reg- > > > > >uri-alias (if the Request-URI was an alias for the AOR used in > > > > registration). > > > >=20 > > > > And if the Request-URI was a "synonym" for the AOR? > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > >=20 > > > >=20 > > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 >=20 From christer.holmberg@ericsson.com Tue Jun 16 10:29:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8621E3A6D77 for ; Tue, 16 Jun 2009 10:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.605 X-Spam-Level: X-Spam-Status: No, score=-5.605 tagged_above=-999 required=5 tests=[AWL=0.644, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4vZcOX-XvmN for ; Tue, 16 Jun 2009 10:29:52 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5B2DA3A6D83 for ; Tue, 16 Jun 2009 10:29:51 -0700 (PDT) X-AuditID: c1b4fb3e-b7b1dae000006c99-74-4a37d690141e Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id E0.21.27801.096D73A4; Tue, 16 Jun 2009 19:29:52 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 19:29:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 19:29:51 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAFn+ocAAVBjIQAABMeEA= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! <4A36AC9C.30 60509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , "Hans Erik van Elburg" , "Mary Barnes" , "Shida Schubert" X-OriginalArrivalTime: 16 Jun 2009 17:29:51.0602 (UTC) FILETIME=[0E256D20:01C9EEA8] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:29:53 -0000 Hi, >>But, I think there is a small missunderstading for the AOR-to-AOR cases. >>=20 >>We don't think you need to know whether the new AOR is an alias or=20 >>not. You need to know whether the new AOR belongs to the same user or=20 >>not. > >To me, that is the definition of an alias. Fine, but that is not the current definition in 4244bis, which says that an alias is an implictity/explicitly registered AOR... With your new definition an alias may be registered, or it may not. It may be an AOR, or it may not. Regards, Christer From AUDET@nortel.com Tue Jun 16 10:32:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C17CC3A6DA0 for ; Tue, 16 Jun 2009 10:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.23 X-Spam-Level: X-Spam-Status: No, score=-6.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOovMbEniKS8 for ; Tue, 16 Jun 2009 10:32:51 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id B82263A6D83 for ; Tue, 16 Jun 2009 10:32:50 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5GHVNa04339; Tue, 16 Jun 2009 17:31:23 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 12:32:09 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri thread-index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAFn+ocAAVBjIQAABMeEAAACJowA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! ! ! <4A36AC9C. 3060509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Christer Holmberg" , "Hans Erik van Elburg" , "Mary Barnes" , "Shida Schubert" Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:32:51 -0000 Yeah, I would fix that. So.... So, it looks like we are in agreement. I think I should up-issue the = document. Agreed? > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Tuesday, June 16, 2009 10:30 > To: Audet, Francois (SC100:3055); Hans Erik van Elburg;=20 > Barnes, Mary (RICH2:AR00); Shida Schubert > Cc: sipcore@ietf.org > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 >=20 > Hi, >=20 > >>But, I think there is a small missunderstading for the AOR-to-AOR > cases. > >>=20 > >>We don't think you need to know whether the new AOR is an alias or=20 > >>not. You need to know whether the new AOR belongs to the=20 > same user or=20 > >>not. > > > >To me, that is the definition of an alias. >=20 > Fine, but that is not the current definition in 4244bis,=20 > which says that an alias is an implictity/explicitly=20 > registered AOR... With your new definition an alias may be=20 > registered, or it may not. It may be an AOR, or it may not. >=20 > Regards, >=20 > Christer >=20 >=20 From mdolly@att.com Tue Jun 16 10:38:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EC2B28C19B for ; Tue, 16 Jun 2009 10:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.212 X-Spam-Level: X-Spam-Status: No, score=-106.212 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xV3Ri6fK5yT for ; Tue, 16 Jun 2009 10:38:24 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 7F6AE3A6DAB for ; Tue, 16 Jun 2009 10:38:23 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-2.tower-120.messagelabs.com!1245173867!24082807!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 16924 invoked from network); 16 Jun 2009 17:37:48 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-2.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Jun 2009 17:37:48 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5GHblUV002452; Tue, 16 Jun 2009 13:37:47 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5GHbcW7002355; Tue, 16 Jun 2009 13:37:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 13:37:38 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA0375F0A4@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAFn+ocAAVBjIQAABMeEAAACJowAAAOjjQ References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>!! ! ! ! ! <4A36AC9C. 3060509@gmail.com><1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> From: "DOLLY, MARTIN C, ATTLABS" To: "Francois Audet" , "Christer Holmberg" , "Hans Erik van Elburg" , "Mary Barnes" , "Shida Schubert" Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:38:26 -0000 And in summary.... -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Francois Audet Sent: Tuesday, June 16, 2009 1:32 PM To: Christer Holmberg; Hans Erik van Elburg; Mary Barnes; Shida Schubert Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Yeah, I would fix that. So.... So, it looks like we are in agreement. I think I should up-issue the document. Agreed? > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Tuesday, June 16, 2009 10:30 > To: Audet, Francois (SC100:3055); Hans Erik van Elburg;=20 > Barnes, Mary (RICH2:AR00); Shida Schubert > Cc: sipcore@ietf.org > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 >=20 > Hi, >=20 > >>But, I think there is a small missunderstading for the AOR-to-AOR > cases. > >>=20 > >>We don't think you need to know whether the new AOR is an alias or=20 > >>not. You need to know whether the new AOR belongs to the=20 > same user or=20 > >>not. > > > >To me, that is the definition of an alias. >=20 > Fine, but that is not the current definition in 4244bis,=20 > which says that an alias is an implictity/explicitly=20 > registered AOR... With your new definition an alias may be=20 > registered, or it may not. It may be an AOR, or it may not. >=20 > Regards, >=20 > Christer >=20 >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From mary.barnes@nortel.com Tue Jun 16 10:38:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CAEF28C197 for ; Tue, 16 Jun 2009 10:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siRuobUOp092 for ; Tue, 16 Jun 2009 10:38:52 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 88A893A6C1B for ; Tue, 16 Jun 2009 10:38:51 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5GHcLc15630; Tue, 16 Jun 2009 17:38:21 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 12:40:51 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri thread-index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAFn+ocAAVBjIQAABMeEAAACJowAAAUkGw References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! ! ! <4A36AC9C. 3060509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Francois Audet" , "Christer Holmberg" , "Hans Erik van Elburg" , "Shida Schubert" Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:38:53 -0000 Now, I'm confused as I thought the alias must be an AOR. I'm in the midst of a response to another email on this topic. =20 -----Original Message----- From: Audet, Francois (SC100:3055)=20 Sent: Tuesday, June 16, 2009 12:32 PM To: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary (RICH2:AR00); Shida Schubert Cc: sipcore@ietf.org Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri Yeah, I would fix that. So.... So, it looks like we are in agreement. I think I should up-issue the document. Agreed? > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, June 16, 2009 10:30 > To: Audet, Francois (SC100:3055); Hans Erik van Elburg; Barnes, Mary=20 > (RICH2:AR00); Shida Schubert > Cc: sipcore@ietf.org > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 >=20 > Hi, >=20 > >>But, I think there is a small missunderstading for the AOR-to-AOR > cases. > >>=20 > >>We don't think you need to know whether the new AOR is an alias or=20 > >>not. You need to know whether the new AOR belongs to the > same user or > >>not. > > > >To me, that is the definition of an alias. >=20 > Fine, but that is not the current definition in 4244bis, which says=20 > that an alias is an implictity/explicitly registered AOR... With your=20 > new definition an alias may be registered, or it may not. It may be an > AOR, or it may not. >=20 > Regards, >=20 > Christer >=20 >=20 From mary.barnes@nortel.com Tue Jun 16 10:40:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C114828C193 for ; Tue, 16 Jun 2009 10:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.091 X-Spam-Level: X-Spam-Status: No, score=-6.091 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, GB_I_LETTER=-2, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oy4QmWgK-BTH for ; Tue, 16 Jun 2009 10:40:37 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 6EB223A68BC for ; Tue, 16 Jun 2009 10:40:37 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5GHe5c16027; Tue, 16 Jun 2009 17:40:05 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 12:41:23 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E88E17D@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri thread-index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAI5l3MAAB8/aWAAFHyfA= References: <1ECE0EB50388174790F9694F77522CCF1E88DA09@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Francois Audet" , "Christer Holmberg" , "Hans Erik van Elburg" , "Shida Schubert" Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:40:38 -0000 I can live with the short names (I guess), as long as it doesn't bother anyone else. So, the aliases then are "implicit" versus "explicit" - i.e., you'll know that it's an alias because it will be labeled with the ..;rt;aor tags? Mary.=20 -----Original Message----- From: Audet, Francois (SC100:3055)=20 Sent: Tuesday, June 16, 2009 9:58 AM To: Barnes, Mary (RICH2:AR00); Christer Holmberg; Hans Erik van Elburg; Shida Schubert Cc: sipcore@ietf.org Subject: Re: draft-barnes-sipcore-rfc4244bis and target-uri Correct. To be more precise, the "Type of URI" has only two values, AOR, and "nothing" (i.e., you don't recognize it as a URI). You are correct about the "two-stages". And the aliases I have at the bottom are NOT registered contact necessarily. When an alias is programmed (typically in a Proxy), say, for a freephone service, it doesn't know if it will be a registered contact, or something else. Normally, it would be another AOR. For example, 18005551212@example.com;user=3Dphone could be mapped to an alias of bob@example.com. On the issue of why "short two-letter names", the official reason would be to shorten the length of the headers (HI can be quite large), save the planet etc. (The "real' reason are: 1- To facilitate my life when writing the call flows by increasing the chances that the entries fit on one line :-) 2- UNIX geekiness :-) ) Finally, on the "alias" concept: the aliases are not lost. I've entered them as a specific entry. In the last example: History-Info: = ;index=3D1.1;mp;aor <- aor is added History-Info: ;index=3D1.1.1;rt;aor <- aor = is added The same could apply at the end of sequence. For example, if I register with To: and is an alias, in the HI there would be an entry for = followed by one for , both flagged as ;aor. On Jun16 2009 06:52 , "Barnes, Mary (RICH2:AR00)" wrote: > So, to summarize: > - the old entry is tagged with the "type of URI" > - the new entry is tagged with the mechanism by which the URI was=20 > determined >=20 > Is that correct? That's actually backwards from what I just told=20 > Dean, but does make sense since you don't know anything about the=20 > "type of URI" until it reaches a domain that is responsible for it. >=20 > I have a couple comments/questions embedded below to make sure I=20 > understand, as this is slightly different than what I had envisioned=20 > when we discussed it yesterday. >=20 > Mary.=20 >=20 > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 8:44 PM > To: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary=20 > (RICH2:AR00); Shida Schubert > Cc: sipcore@ietf.org > Subject: draft-barnes-sipcore-rfc4244bis and target-uri >=20 > All right guys, >=20 > I've been thinking about this. >=20 > It seems to me that what we want to capture is: > 1) If the target is an AOR, a contact, or a routing URI (maddr, noop=20 > intra-domain, or noop > forward to next domain, or strict routing). > 2) In the case that the target is an AOR, then if that AOR is known to > be an alias for the previous > one, or if it is mapped to another AOR. >=20 > It seems to me that a Proxy should mark a Previous entry in H-I with=20 > aor if it determines that it owns this AOR. Just as Hans's current=20 > target-uri draft. >=20 > Now, for the mapped vs routed (versus reg-contact, etc.), instead of=20 > marking the Previous entry, we should mark the OUTGOING (i.e., New)=20 > entry instead. This would make the procedures of > 7.2.1 & 7.2.2 of target-URI draft clearer. >=20 > [MB] I think this gets to the concern I had earlier about it looking=20 > to be "two stage". [/MB] >=20 > Specifically, the logic would be: >=20 > When proxy receives an incoming request with H-I, it adds an ;aor tag=20 > to that incoming entry if it determines that it is responsible for the > AOR and. >=20 > Also, if there was no Hi-entry at all (i.e., it came from a UAC), and=20 > the Proxy creates then two entries, the first one in this case would=20 > also have the ;aor tag associated to it. >=20 > For the Outgoing entry, I would see the following tags: >=20 > rc : The entry is an explicit registered contact (i.e., it was=20 > provided in a REGISTER message) >=20 > ic : The entry is an implicit registered contact (i.e., it's exactly=20 > as a registered contact, but was not discovered using SIP=20 > Registration: it could have been manually configured or done with a=20 > proprietary mechanism). >=20 > (TBD: we could debate if we need both rc and irc, but I think we do). >=20 > mp : The request-URI is changed to a new URI that represent another=20 > user. >=20 > rt : The entry is "routed", i.e., it is either a no-opt like a proxy=20 > forwarding within a domain, predetermined by a maddr in the=20 > Request-URI, or when proxy is NOT responsible for domain, or the=20 > address is an alias for the incoming URI. > [MB] I'm slightly confused as to why alias are in this bucket - aren't > aliases also registered contacts? >=20 > Also, I would prefer to tag these explictly as we did with the current > definition of hi-target in 4244bis. I don't think it costs anything=20 > and I think it could be useful for debug/diagnostics. Also, I would=20 > prefer we expand the labels a tad, something like: > reg-exp > reg-imp > mapped > route > reg-alias >=20 > I could live without the alias, but per my comment above, it's not=20 > clear to me that these are "routed". > [/MB] >=20 > So, to give an example. >=20 > Say Alice calls Bob. Bob is forwarded to freephone. Freephone routes=20 > to Carol. >=20 > The History-info at Carol would look like this: >=20 > Alice -> example.com > Nothing because UAC typically doesn't send H-I (otherwise, it would be > as per Index 1 in next entry, but without the AOR. >=20 > example.com -> freephone@example.net > History-Info: ;index=3D1;aor > History-Info: ;index=3D1.1;mp >=20 > example.net -> carol@example.net > History-Info: ;index=3D1;aor > History-Info: ;index=3D1.1;mp;aor <- aor = is=20 > added > History-Info: ;index=3D1.1.1;rt;aor } Two > entries are > History-Info: ;index=3D1.1.1.1;rc } added at > same time >=20 > Also, I don't think we need to define an equivalent to the=20 > "reg-uri-alias" anymore. > [MB] I'm not entirely comfortable with losing the alias concept. I=20 > would think it could be useful for debug/diagnostic use cases. [/MB] >=20 > If Freephone was configured to go to +14085551212 instead of the=20 > registered Contact (assuming +14085551212 was an Alias AOR for=20 > carol@example.net), the last H-I entries would look like this instead: >=20 > example.net -> carol@example.net > History-Info: ;index=3D1;aor > History-Info:=20 > ;index=3D1.1;mp;aor > <- aor is added > History-Info: ;index=3D1.1.1;rt;aor <- aor = > is added > History-Info: ;index=3D1.1.1.1;rt;aor } Two > entries are > History-Info: ;index=3D1.1.1.1.1;rc } = added > at same time From AUDET@nortel.com Tue Jun 16 10:41:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F82128C1A3 for ; Tue, 16 Jun 2009 10:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pMm6U6bLNxf for ; Tue, 16 Jun 2009 10:41:27 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 7020428C123 for ; Tue, 16 Jun 2009 10:41:27 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5GHdxc15995; Tue, 16 Jun 2009 17:39:59 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 12:39:48 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E88E185@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri thread-index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAFn+ocAAVBjIQAABMeEAAACJowAAAUkGwAAAHb7A= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! ! ! <4A36AC9C. 3060509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Mary Barnes" , "Christer Holmberg" , "Hans Erik van Elburg" , "Shida Schubert" Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:41:28 -0000 It is. But the "guy" who forwards to an AOR doesn't know that it's necessarily an AOR. That's why it gets tagged as AOR later.=20 > -----Original Message----- > From: Barnes, Mary (RICH2:AR00)=20 > Sent: Tuesday, June 16, 2009 10:41 > To: Audet, Francois (SC100:3055); 'Christer Holmberg'; 'Hans=20 > Erik van Elburg'; 'Shida Schubert' > Cc: 'sipcore@ietf.org' > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Now, I'm confused as I thought the alias must be an AOR. I'm=20 > in the midst of a response to another email on this topic. =20 >=20 > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Tuesday, June 16, 2009 12:32 PM > To: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary=20 > (RICH2:AR00); Shida Schubert > Cc: sipcore@ietf.org > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Yeah, I would fix that. >=20 > So.... >=20 > So, it looks like we are in agreement. I think I should=20 > up-issue the document. >=20 > Agreed? >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, June 16, 2009 10:30 > > To: Audet, Francois (SC100:3055); Hans Erik van Elburg;=20 > Barnes, Mary=20 > > (RICH2:AR00); Shida Schubert > > Cc: sipcore@ietf.org > > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri > >=20 > >=20 > > Hi, > >=20 > > >>But, I think there is a small missunderstading for the AOR-to-AOR > > cases. > > >>=20 > > >>We don't think you need to know whether the new AOR is an=20 > alias or=20 > > >>not. You need to know whether the new AOR belongs to the > > same user or > > >>not. > > > > > >To me, that is the definition of an alias. > >=20 > > Fine, but that is not the current definition in 4244bis, which says=20 > > that an alias is an implictity/explicitly registered AOR...=20 > With your=20 > > new definition an alias may be registered, or it may not.=20 > It may be an=20 > > AOR, or it may not. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 >=20 From AUDET@nortel.com Tue Jun 16 10:42:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91BFD28C1A7 for ; Tue, 16 Jun 2009 10:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.279 X-Spam-Level: X-Spam-Status: No, score=-6.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqrPAYaWbCYw for ; Tue, 16 Jun 2009 10:42:31 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 955F928C19C for ; Tue, 16 Jun 2009 10:42:31 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5GHfwc16565; Tue, 16 Jun 2009 17:41:59 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 12:41:19 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E88E190@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88E17D@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri thread-index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAI5l3MAAB8/aWAAFHyfAABXd5UA== References: <1ECE0EB50388174790F9694F77522CCF1E88DA09@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E17D@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Mary Barnes" , "Christer Holmberg" , "Hans Erik van Elburg" , "Shida Schubert" Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:42:32 -0000 Correct: you will know they are AOR when they get tagged as such by the domain who owns the AOR. That works well when going through multiple hops. > -----Original Message----- > From: Barnes, Mary (RICH2:AR00)=20 > Sent: Tuesday, June 16, 2009 10:41 > To: Audet, Francois (SC100:3055); Christer Holmberg; Hans=20 > Erik van Elburg; Shida Schubert > Cc: sipcore@ietf.org > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 > I can live with the short names (I guess), as long as it=20 > doesn't bother anyone else. So, the aliases then are=20 > "implicit" versus "explicit" - i.e., you'll know that it's an=20 > alias because it will be labeled with the ..;rt;aor tags? >=20 > Mary.=20 From AUDET@nortel.com Tue Jun 16 10:43:17 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1AA3A6D89 for ; Tue, 16 Jun 2009 10:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHI78Vrb032r for ; Tue, 16 Jun 2009 10:43:16 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 79F713A6AA6 for ; Tue, 16 Jun 2009 10:43:16 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5GHKQa02644; Tue, 16 Jun 2009 17:20:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 12:21:36 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E88E0FE@zrc2hxm0.corp.nortel.com> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD404827ACF@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri thread-index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAEsEiwAAY2eFw References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>!! ! ! <4A3 6A C9C.30605 09@ gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404827ACF@S4DE8PSAAQB.mitte.t-com.de> From: "Francois Audet" To: , , , "Mary Barnes" , Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:43:17 -0000 In the new draft, the entries are always there and never removed. It = makes HI much more reliable. If entries need to be anonymous, they are anonymized but the entry is = still there.=20 > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 > Sent: Monday, June 15, 2009 22:38 > To: Audet, Francois (SC100:3055);=20 > christer.holmberg@ericsson.com; ietf.hanserik@gmail.com;=20 > Barnes, Mary (RICH2:AR00); shida@agnada.com > Cc: sipcore@ietf.org > Subject: AW: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Such values looks good and gives more guideline why the entry=20 > was included. > My question would be if there is a different network=20 > behaviour foreseen for the History mechanism. > Perhaps some of the networks needs the history only to=20 > indicate where the URI were mapped ("mp") and others would=20 > really track the whole history of each SIP proxy. > Or is it only seen either to support history full or not. >=20 > BR, >=20 > Roland =20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Francois Audet > Gesendet: Dienstag, 16. Juni 2009 03:44 > An: Christer Holmberg; Hans Erik van Elburg; Mary Barnes;=20 > Shida Schubert > Cc: sipcore@ietf.org > Betreff: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >=20 > All right guys, >=20 > I've been thinking about this. >=20 > It seems to me that what we want to capture is: > 1) If the target is an AOR, a contact, or a routing URI=20 > (maddr, noop intra-domain, or noop > forward to next domain, or strict routing). > 2) In the case that the target is an AOR, then if that AOR is=20 > known to be an alias for the previous > one, or if it is mapped to another AOR. >=20 > It seems to me that a Proxy should mark a Previous entry in=20 > H-I with aor if it determines that it owns this AOR. Just as=20 > Hans's current target-uri draft. >=20 > Now, for the mapped vs routed (versus reg-contact, etc.),=20 > instead of marking the Previous entry, we should mark the=20 > OUTGOING (i.e., New) entry instead. This would make the procedures of > 7.2.1 & 7.2.2 of target-URI draft clearer. >=20 > Specifically, the logic would be: >=20 > When proxy receives an incoming request with H-I, it adds an=20 > ;aor tag to that incoming entry if it determines that it is=20 > responsible for the AOR and.=20 >=20 > Also, if there was no Hi-entry at all (i.e., it came from a=20 > UAC), and the Proxy creates then two entries, the first one=20 > in this case would also have the ;aor tag associated to it. >=20 > For the Outgoing entry, I would see the following tags: >=20 > rc : The entry is an explicit registered contact=20 > (i.e., it was provided in a REGISTER message) >=20 > ic : The entry is an implicit registered contact=20 > (i.e., it's exactly as a registered contact, > but was not discovered using SIP Registration:=20 > it could have been manually configured > or done with a proprietary mechanism). >=20 > (TBD: we could debate if we need both rc and=20 > irc, but I think we do). >=20 > mp : The request-URI is changed to a new URI that=20 > represent another user. >=20 > rt : The entry is "routed", i.e., it is either a=20 > no-opt like a proxy forwarding within > a domain, predetermined by a maddr in the=20 > Request-URI, or when proxy is NOT responsible > for domain, or the address is an alias for the=20 > incoming URI. >=20 > So, to give an example.=20 >=20 > Say Alice calls Bob. Bob is forwarded to freephone. Freephone=20 > routes to Carol.=20 >=20 > The History-info at Carol would look like this: >=20 > Alice -> example.com > Nothing because UAC typically doesn't send H-I (otherwise, it=20 > would be as per Index 1 in next entry, but without the AOR. >=20 > example.com -> freephone@example.net > History-Info: ;index=3D1;aor > History-Info: ;index=3D1.1;mp >=20 > example.net -> carol@example.net > History-Info: ;index=3D1;aor =20 > History-Info: ;index=3D1.1;mp;aor =20 > <- aor is added > History-Info: ;index=3D1.1.1;rt;aor }=20 > Two entries are > History-Info: ;index=3D1.1.1.1;rc }=20 > added at same time >=20 > Also, I don't think we need to define an equivalent to the=20 > "reg-uri-alias" anymore. > If Freephone was configured to go to +14085551212 instead of=20 > the registered Contact (assuming +14085551212 was an Alias=20 > AOR for carol@example.net), the last H-I entries would look=20 > like this instead: >=20 > example.net -> carol@example.net > History-Info: ;index=3D1;aor =20 > History-Info:=20 > ;index=3D1.1;mp;aor <-=20 > aor is added > History-Info: ;index=3D1.1.1;rt;aor =20 > <- aor is added > History-Info: ;index=3D1.1.1.1;rt;aor =20 > } Two entries are > History-Info: ;index=3D1.1.1.1.1;rc =20 > } added at same time > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Tue Jun 16 10:44:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25A423A68D8 for ; Tue, 16 Jun 2009 10:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.629 X-Spam-Level: X-Spam-Status: No, score=-5.629 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGQSrORJhRlS for ; Tue, 16 Jun 2009 10:44:03 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 1BB483A6AA6 for ; Tue, 16 Jun 2009 10:44:02 -0700 (PDT) X-AuditID: c1b4fb3e-b7b1dae000006c99-4e-4a37d9d43273 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id A4.B1.27801.4D9D73A4; Tue, 16 Jun 2009 19:43:48 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 19:43:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 19:43:47 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAFn+ocAAVBjIQAABMeEAAACJowAAAX5cA References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! ! ! <4A36AC9 C.3060509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , "Hans Erik van Elburg" , "Mary Barnes" , "Shida Schubert" X-OriginalArrivalTime: 16 Jun 2009 17:43:47.0990 (UTC) FILETIME=[00AC1B60:01C9EEAA] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:44:04 -0000 =20 >Yeah, I would fix that. Then I think you should add a note saying that your definition of "alias" is different than the definition in 3GPP - to avoid confusion. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, June 16, 2009 10:30 > To: Audet, Francois (SC100:3055); Hans Erik van Elburg; Barnes, Mary=20 > (RICH2:AR00); Shida Schubert > Cc: sipcore@ietf.org > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 >=20 > Hi, >=20 > >>But, I think there is a small missunderstading for the AOR-to-AOR > cases. > >>=20 > >>We don't think you need to know whether the new AOR is an alias or=20 > >>not. You need to know whether the new AOR belongs to the > same user or > >>not. > > > >To me, that is the definition of an alias. >=20 > Fine, but that is not the current definition in 4244bis, which says=20 > that an alias is an implictity/explicitly registered AOR... With your=20 > new definition an alias may be registered, or it may not. It may be an > AOR, or it may not. >=20 > Regards, >=20 > Christer >=20 >=20 From pkyzivat@cisco.com Tue Jun 16 10:44:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2BB73A6AA6 for ; Tue, 16 Jun 2009 10:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.542 X-Spam-Level: X-Spam-Status: No, score=-6.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZARZeqHn8BAR for ; Tue, 16 Jun 2009 10:44:11 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B516F3A67B5 for ; Tue, 16 Jun 2009 10:44:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,230,1243814400"; d="scan'208";a="47523029" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 Jun 2009 17:44:02 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5GHi2nU001066; Tue, 16 Jun 2009 13:44:02 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5GHi2D9010447; Tue, 16 Jun 2009 17:44:02 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 13:44:02 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 13:44:02 -0400 Message-ID: <4A37D9E1.1040001@cisco.com> Date: Tue, 16 Jun 2009 13:44:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Francois Audet References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! <4 A36AC9C.3060 509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2009 17:44:02.0121 (UTC) FILETIME=[09185390:01C9EEAA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=690; t=1245174242; x=1246038242; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20draft-barnes-sipcore-rfc424 4bis=20and=20target-uri |Sender:=20 |To:=20Francois=20Audet=20; bh=MlsH+IxWqLoWxiS4ryNg6aDcqsm2+qYi2slcKp4APaM=; b=lzDKiL1LNup8mj0qe6eBesOl1iPgan/LDGNPJv3pZZFD2itHpHjs78LQGR nI/C62ioOoEuwsizcQ5yCgCnV7Fmk9WPBtUtA6tkZwakQUVtCyRX+emudY/n +6xRvs1czQ; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:44:12 -0000 Francois Audet wrote: >> But, I think there is a small missunderstading for the >> AOR-to-AOR cases. >> >> We don't think you need to know whether the new AOR is an >> alias or not. You need to know whether the new AOR belongs to >> the same user or not. > > To me, that is the definition of an alias. I have to differ here. I may own a bunch of AORs. Some of them may be aliases, others may not be. For instance: - sip:pkyzivat@example.net and paul.kyzivat@example.net might be aliases. - sip:pkyzivat.ietf@example.net and sip:pkyzivat.junk@example.net may be designed to bucket specific kinds of traffic, and so not be aliases. Thanks, Paul From mary.barnes@nortel.com Tue Jun 16 10:45:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF2683A6AA6 for ; Tue, 16 Jun 2009 10:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RylgtGGERTD4 for ; Tue, 16 Jun 2009 10:45:41 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id CD5DF28C1A4 for ; Tue, 16 Jun 2009 10:45:40 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5GHjTc17939; Tue, 16 Jun 2009 17:45:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 12:46:46 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E88E1A4@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88E185@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri thread-index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAFn+ocAAVBjIQAABMeEAAACJowAAAUkGwAAAHb7AAACK4MA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! ! ! <4A36AC9C. 3060509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E185@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Francois Audet" , "Christer Holmberg" , "Hans Erik van Elburg" , "Shida Schubert" Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:45:42 -0000 Correct - this is what I tried to summarize in this email: http://www.ietf.org/mail-archive/web/sipcore/current/msg00429.html And, we are getting the threads all mixed, so maybe a summary of where we are now would be helpful. Thanks, Mary.=20 -----Original Message----- From: Audet, Francois (SC100:3055)=20 Sent: Tuesday, June 16, 2009 12:40 PM To: Barnes, Mary (RICH2:AR00); 'Christer Holmberg'; 'Hans Erik van Elburg'; 'Shida Schubert' Cc: 'sipcore@ietf.org' Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri It is. But the "guy" who forwards to an AOR doesn't know that it's necessarily an AOR. That's why it gets tagged as AOR later.=20 > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Tuesday, June 16, 2009 10:41 > To: Audet, Francois (SC100:3055); 'Christer Holmberg'; 'Hans Erik van=20 > Elburg'; 'Shida Schubert' > Cc: 'sipcore@ietf.org' > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Now, I'm confused as I thought the alias must be an AOR. I'm=20 > in the midst of a response to another email on this topic. =20 >=20 > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Tuesday, June 16, 2009 12:32 PM > To: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary=20 > (RICH2:AR00); Shida Schubert > Cc: sipcore@ietf.org > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Yeah, I would fix that. >=20 > So.... >=20 > So, it looks like we are in agreement. I think I should up-issue the=20 > document. >=20 > Agreed? >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, June 16, 2009 10:30 > > To: Audet, Francois (SC100:3055); Hans Erik van Elburg; > Barnes, Mary > > (RICH2:AR00); Shida Schubert > > Cc: sipcore@ietf.org > > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri > >=20 > >=20 > > Hi, > >=20 > > >>But, I think there is a small missunderstading for the AOR-to-AOR > > cases. > > >>=20 > > >>We don't think you need to know whether the new AOR is an > alias or > > >>not. You need to know whether the new AOR belongs to the > > same user or > > >>not. > > > > > >To me, that is the definition of an alias. > >=20 > > Fine, but that is not the current definition in 4244bis, which says=20 > > that an alias is an implictity/explicitly registered AOR... > With your > > new definition an alias may be registered, or it may not.=20 > It may be an > > AOR, or it may not. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 >=20 From ietf.hanserik@gmail.com Tue Jun 16 10:52:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61DBF28C193 for ; Tue, 16 Jun 2009 10:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0ftcnSHH+fN for ; Tue, 16 Jun 2009 10:52:20 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 7131428C1A4 for ; Tue, 16 Jun 2009 10:52:19 -0700 (PDT) Received: by ewy6 with SMTP id 6so6226610ewy.37 for ; Tue, 16 Jun 2009 10:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=HZfKS6CP6rjVrSqGYo0VaKho/zIQSGk3fnpwrPBieVo=; b=DpQlfU4opi/JBcyydj0Zrg+nez9iUsNAGHwlxTOZBra4aOMFGCrfu5PdGM2vHgNM/D 0jBkbJUiIrBXnQRRJ9HvUlnWAz871scC0n05fAX6MWuFuwiGKvpcq8RafQCJN4yuyNPA SVMnWuqY//Gxf42heRfYcwjdN6DE3HznbnBS4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=qBXgF239pCpdRFfMtKiwyMcNpR38aPcvqO/RG0U3LYKBT7OydmdlvBSF6bCiQOyOPX b0RQJ/jMEFjeeuGWOO6IQsYkgvsKQrtUGqhtpNgY8Siw4UmCJZ1ybYB/+V3U+BUP5Pxh 57l6s8BSGkhrvTWzaEtUnzkKfdjJKpkN++kLQ= Received: by 10.210.27.14 with SMTP id a14mr1526269eba.35.1245174721360; Tue, 16 Jun 2009 10:52:01 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 5sm198320eyh.40.2009.06.16.10.51.59 (version=SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 10:52:00 -0700 (PDT) Message-ID: <4A37DBBE.5000600@gmail.com> Date: Tue, 16 Jun 2009 19:51:58 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Francois Audet References: <1ECE0EB50388174790F9694F77522CCF1E88DA09@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E17D@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E1A2@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88E1A2@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:52:21 -0000 short names are fine /Hans Erik Francois Audet wrote: > Do people prefer short names or long names? > > I don't care much. I was just in a short name a-la ;lr type > of mood. > > >> -----Original Message----- >> From: Barnes, Mary (RICH2:AR00) >> Sent: Tuesday, June 16, 2009 10:41 >> To: Audet, Francois (SC100:3055); Christer Holmberg; Hans >> Erik van Elburg; Shida Schubert >> Cc: sipcore@ietf.org >> Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >> >> I can live with the short names (I guess), as long as it >> doesn't bother anyone else. So, the aliases then are >> "implicit" versus "explicit" - i.e., you'll know that it's an >> alias because it will be labeled with the ..;rt;aor tags? >> From christer.holmberg@ericsson.com Tue Jun 16 10:52:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D3A28C1A4 for ; Tue, 16 Jun 2009 10:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.651 X-Spam-Level: X-Spam-Status: No, score=-5.651 tagged_above=-999 required=5 tests=[AWL=0.598, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dh52XI+yB1xk for ; Tue, 16 Jun 2009 10:52:25 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4876C28C1A9 for ; Tue, 16 Jun 2009 10:52:25 -0700 (PDT) X-AuditID: c1b4fb3e-b7b1dae000006c99-cb-4a37dbc7f8be Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 15.F1.27801.7CBD73A4; Tue, 16 Jun 2009 19:52:07 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 19:52:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 19:52:06 +0200 Message-ID: In-Reply-To: <4A37D9E1.1040001@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: Acnuqgr8BIccQ0FqSea0C7Cz99PV5AAAHzKw References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! <4 A36AC9C.3060 509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> <4A37D9E1.1040001@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Francois Audet" X-OriginalArrivalTime: 16 Jun 2009 17:52:06.0856 (UTC) FILETIME=[2A050480:01C9EEAB] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:52:26 -0000 >> But, I think there is a small missunderstading for the AOR-to-AOR=20 >> cases. >> >> We don't think you need to know whether the new AOR is an alias or=20 >> not. You need to know whether the new AOR belongs to the same user or >> not. >=20 > To me, that is the definition of an alias. > >I have to differ here. > >I may own a bunch of AORs. Some of them may be aliases, others may not be. For instance: > >- sip:pkyzivat@example.net and paul.kyzivat@example.net > might be aliases. > >- sip:pkyzivat.ietf@example.net and sip:pkyzivat.junk@example.net > may be designed to bucket specific kinds of traffic, and so > not be aliases. That is why I like the 3GPP definition of alias, which 4244bis currently also uses. But, again, based on that definition a freephone number does not have to be an alias: the 1-800 number is not necessarily registered for the called user. Regards, Christer From AUDET@nortel.com Tue Jun 16 10:53:13 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F21063A6AA6 for ; Tue, 16 Jun 2009 10:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.317 X-Spam-Level: X-Spam-Status: No, score=-6.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYRujb0HGwbT for ; Tue, 16 Jun 2009 10:53:12 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id ED0F33A68D8 for ; Tue, 16 Jun 2009 10:53:11 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5GHr9c19470; Tue, 16 Jun 2009 17:53:09 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 12:52:44 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E88E1D5@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A37D9E1.1040001@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri thread-index: Acnuqg7m8ZMXHe+ATD2iPJkGudS/lgAAPjhQ References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! <4 A36AC9C.3060 509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> <4A37D9E1.1040001@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:53:13 -0000 I'm thinking it's the first case we are talking about. The second case IMHO is multiple logical users. But I see your point. We need to word this carefully. Christer, I still don't get what's wrong with the=20 3GPP terminology. Can you clarify?=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Tuesday, June 16, 2009 10:44 > To: Audet, Francois (SC100:3055) > Cc: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary=20 > (RICH2:AR00); Shida Schubert; sipcore@ietf.org > Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Francois Audet wrote: >=20 > >> But, I think there is a small missunderstading for the AOR-to-AOR=20 > >> cases. > >> > >> We don't think you need to know whether the new AOR is an alias or=20 > >> not. You need to know whether the new AOR belongs to the=20 > same user or=20 > >> not. > >=20 > > To me, that is the definition of an alias. >=20 > I have to differ here. >=20 > I may own a bunch of AORs. Some of them may be aliases,=20 > others may not be. For instance: >=20 > - sip:pkyzivat@example.net and paul.kyzivat@example.net > might be aliases. >=20 > - sip:pkyzivat.ietf@example.net and sip:pkyzivat.junk@example.net > may be designed to bucket specific kinds of traffic, and so > not be aliases. >=20 > Thanks, > Paul >=20 From christer.holmberg@ericsson.com Tue Jun 16 10:57:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8885228C1A3 for ; Tue, 16 Jun 2009 10:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.672 X-Spam-Level: X-Spam-Status: No, score=-5.672 tagged_above=-999 required=5 tests=[AWL=0.577, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPwQyWSyflEJ for ; Tue, 16 Jun 2009 10:57:37 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2C87C28C19E for ; Tue, 16 Jun 2009 10:57:36 -0700 (PDT) X-AuditID: c1b4fb3e-b7b1dae000006c99-90-4a37dd1b7af2 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 42.22.27801.B1DD73A4; Tue, 16 Jun 2009 19:57:47 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 19:57:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 19:57:46 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88E1D5@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: Acnuqg7m8ZMXHe+ATD2iPJkGudS/lgAAPjhQAAAX5zA= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! <4 A36AC9C.3060 509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> <4A37D9E1.1040001@cisco.com> <1E CE0EB503 88174790F9694F77522CCF1E88E1D5@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , "Paul Kyzivat" X-OriginalArrivalTime: 16 Jun 2009 17:57:46.0579 (UTC) FILETIME=[F482A230:01C9EEAB] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 17:57:38 -0000 =20 >I'm thinking it's the first case we are talking about. > >The second case IMHO is multiple logical users. > >But I see your point. We need to word this carefully. > >Christer, I still don't get what's wrong with the 3GPP terminology. Can you clarify?=20 I think the 3GPP terminology is just fine :) What I am saying is that a freephone number is not necessarily an alias - based on the 3GPP terminology. The 1-800 number is not necessarily implicitly registered for the AOR it is translated into. Regards, Christer > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, June 16, 2009 10:44 > To: Audet, Francois (SC100:3055) > Cc: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary=20 > (RICH2:AR00); Shida Schubert; sipcore@ietf.org > Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Francois Audet wrote: >=20 > >> But, I think there is a small missunderstading for the AOR-to-AOR=20 > >> cases. > >> > >> We don't think you need to know whether the new AOR is an alias or=20 > >> not. You need to know whether the new AOR belongs to the > same user or > >> not. > >=20 > > To me, that is the definition of an alias. >=20 > I have to differ here. >=20 > I may own a bunch of AORs. Some of them may be aliases, others may not > be. For instance: >=20 > - sip:pkyzivat@example.net and paul.kyzivat@example.net > might be aliases. >=20 > - sip:pkyzivat.ietf@example.net and sip:pkyzivat.junk@example.net > may be designed to bucket specific kinds of traffic, and so > not be aliases. >=20 > Thanks, > Paul >=20 From ietf.hanserik@gmail.com Tue Jun 16 11:00:17 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D80A83A6A02 for ; Tue, 16 Jun 2009 11:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0XMHimvsSgp for ; Tue, 16 Jun 2009 11:00:16 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 2D4F23A6AA6 for ; Tue, 16 Jun 2009 11:00:16 -0700 (PDT) Received: by ewy6 with SMTP id 6so6233686ewy.37 for ; Tue, 16 Jun 2009 11:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=QCNAaQn9VUkDMos9pJ4kri+cf7oathkMBZX4MuoZwAQ=; b=m58KLcn0PaCXxuyroXTJCQaZR895p79Rnd3qWnuRDmnHpQT2KIjHA3JTdQW0yTgI7R 0JYTrZxzRHUNi5z0iYDaaNHMWs2Jrsws9dProw9FlC3D6s7jT17/1PloaTZ85kUneNwm N55R24RtIw2Jp2yQBfiVerYIURZvUY2HstYgc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=WFJEn0tNG4ajHWj3PFIasBLekt6YpqgDwDxyP6CYYT+Uk0UAAts4fUACR/4FgjflLz GhOdkjOdkv6mzboIpczIH1jZX8JadiA+opAt6lu93iKCt77TU5fJcDiGYfzIeHy26hYz KtvZp4J44TvKfcGjLVk4OnLsc0avolWHhxEWM= Received: by 10.210.89.4 with SMTP id m4mr2547922ebb.6.1245175224894; Tue, 16 Jun 2009 11:00:24 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 23sm221595eya.29.2009.06.16.11.00.23 (version=SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 11:00:24 -0700 (PDT) Message-ID: <4A37DDB6.6040004@gmail.com> Date: Tue, 16 Jun 2009 20:00:22 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Francois Audet References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! <4 A36AC9C.3060 509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> <4A37D9E1.1040001@cisco.com> <1ECE0EB50388174790F9694F77522CCF1E88E1D5@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88E1D5@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 18:00:17 -0000 Bringing back the 3gpp definition: *Alias Public User Identities:* A Public User Identity is an alias of another Public User Identity if both identities belong to the same implicit registration set, are linked to the same service profile and have the same service data configured for each and every service. In this sense the freephone number that I have is not an alias of my normal AOR, because different service logic is invoked and different service data applies. You had a similar definition in 4244bis. BR, /Hans Erik Francois Audet wrote: > I'm thinking it's the first case we are talking about. > > The second case IMHO is multiple logical users. > > But I see your point. We need to word this carefully. > > > Christer, I still don't get what's wrong with the > 3GPP terminology. Can you clarify? > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, June 16, 2009 10:44 >> To: Audet, Francois (SC100:3055) >> Cc: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary >> (RICH2:AR00); Shida Schubert; sipcore@ietf.org >> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >> >> Francois Audet wrote: >> >> >>>> But, I think there is a small missunderstading for the AOR-to-AOR >>>> cases. >>>> >>>> We don't think you need to know whether the new AOR is an alias or >>>> not. You need to know whether the new AOR belongs to the >>>> >> same user or >> >>>> not. >>>> >>> To me, that is the definition of an alias. >>> >> I have to differ here. >> >> I may own a bunch of AORs. Some of them may be aliases, >> others may not be. For instance: >> >> - sip:pkyzivat@example.net and paul.kyzivat@example.net >> might be aliases. >> >> - sip:pkyzivat.ietf@example.net and sip:pkyzivat.junk@example.net >> may be designed to bucket specific kinds of traffic, and so >> not be aliases. >> >> Thanks, >> Paul >> >> From AUDET@nortel.com Tue Jun 16 11:02:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 136BE3A6A7D for ; Tue, 16 Jun 2009 11:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.332 X-Spam-Level: X-Spam-Status: No, score=-6.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9O0dGeAgoO6 for ; Tue, 16 Jun 2009 11:02:31 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 2AAE33A6A02 for ; Tue, 16 Jun 2009 11:02:31 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5GHgRa06001; Tue, 16 Jun 2009 17:42:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 12:43:45 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E88E1A2@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88E17D@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri thread-index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAI5l3MAAB8/aWAAFHyfAABYzJAA== References: <1ECE0EB50388174790F9694F77522CCF1E88DA09@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E17D@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Mary Barnes" , "Christer Holmberg" , "Hans Erik van Elburg" , "Shida Schubert" Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 18:02:32 -0000 Do people prefer short names or long names? I don't care much. I was just in a short name a-la ;lr type of mood. > -----Original Message----- > From: Barnes, Mary (RICH2:AR00)=20 > Sent: Tuesday, June 16, 2009 10:41 > To: Audet, Francois (SC100:3055); Christer Holmberg; Hans=20 > Erik van Elburg; Shida Schubert > Cc: sipcore@ietf.org > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 > I can live with the short names (I guess), as long as it=20 > doesn't bother anyone else. So, the aliases then are=20 > "implicit" versus "explicit" - i.e., you'll know that it's an=20 > alias because it will be labeled with the ..;rt;aor tags? From mdolly@att.com Tue Jun 16 11:02:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 496F33A6BA6 for ; Tue, 16 Jun 2009 11:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.251 X-Spam-Level: X-Spam-Status: No, score=-106.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrdFcHYt3-qu for ; Tue, 16 Jun 2009 11:02:50 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 535123A6A02 for ; Tue, 16 Jun 2009 11:02:50 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-7.tower-129.messagelabs.com!1245175380!20398578!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 20160 invoked from network); 16 Jun 2009 18:03:00 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-7.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Jun 2009 18:03:00 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5GI2xVR024758; Tue, 16 Jun 2009 14:03:00 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5GI2ql1024610; Tue, 16 Jun 2009 14:02:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Tue, 16 Jun 2009 14:02:51 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD4819@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: AcnurGINPcbFwCRBR7GVzYI3uZKtoAAAEhzf From: "DOLLY, MARTIN C, ATTLABS" To: , Cc: sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 18:02:51 -0000 SSBkbyBub3QgdGhpbmsgdG9sbCBmcmVlIGlzIGEgM0dQUCB0ZXJtDQoNCi0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0NCkZyb206IHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyA8c2lwY29yZS1i b3VuY2VzQGlldGYub3JnPg0KVG86IEZyYW5jb2lzIEF1ZGV0IDxhdWRldEBub3J0ZWwuY29tPg0K Q2M6IHNpcGNvcmVAaWV0Zi5vcmcgPHNpcGNvcmVAaWV0Zi5vcmc+OyBTaGlkYSBTY2h1YmVydCA8 c2hpZGFAYWduYWRhLmNvbT4NClNlbnQ6IFR1ZSBKdW4gMTYgMTQ6MDA6MjIgMjAwOQ0KU3ViamVj dDogUmU6IFtzaXBjb3JlXSBkcmFmdC1iYXJuZXMtc2lwY29yZS1yZmM0MjQ0YmlzIGFuZCB0YXJn ZXQtdXJpDQoNCkJyaW5naW5nIGJhY2sgdGhlIDNncHAgZGVmaW5pdGlvbjoNCg0KKkFsaWFzIFB1 YmxpYyBVc2VyIElkZW50aXRpZXM6KiBBIFB1YmxpYyBVc2VyIElkZW50aXR5IGlzIGFuIGFsaWFz IG9mIA0KYW5vdGhlciBQdWJsaWMgVXNlciBJZGVudGl0eSBpZiBib3RoIGlkZW50aXRpZXMgYmVs b25nIHRvIHRoZSBzYW1lIA0KaW1wbGljaXQgcmVnaXN0cmF0aW9uIHNldCwgYXJlIGxpbmtlZCB0 byB0aGUgc2FtZSBzZXJ2aWNlIHByb2ZpbGUgYW5kIA0KaGF2ZSB0aGUgc2FtZSBzZXJ2aWNlIGRh dGEgY29uZmlndXJlZCBmb3IgZWFjaCBhbmQgZXZlcnkgc2VydmljZS4NCg0KDQpJbiB0aGlzIHNl bnNlIHRoZSBmcmVlcGhvbmUgbnVtYmVyIHRoYXQgSSBoYXZlIGlzIG5vdCBhbiBhbGlhcyBvZiBt eSANCm5vcm1hbCBBT1IsIGJlY2F1c2UgZGlmZmVyZW50IHNlcnZpY2UgbG9naWMgaXMgaW52b2tl ZCBhbmQgZGlmZmVyZW50IA0Kc2VydmljZSBkYXRhIGFwcGxpZXMuDQoNCllvdSBoYWQgYSBzaW1p bGFyIGRlZmluaXRpb24gaW4gNDI0NGJpcy4NCg0KQlIsDQovSGFucyBFcmlrDQoNCg0KDQpGcmFu Y29pcyBBdWRldCB3cm90ZToNCj4gSSdtIHRoaW5raW5nIGl0J3MgdGhlIGZpcnN0IGNhc2Ugd2Ug YXJlIHRhbGtpbmcgYWJvdXQuDQo+DQo+IFRoZSBzZWNvbmQgY2FzZSBJTUhPIGlzIG11bHRpcGxl IGxvZ2ljYWwgdXNlcnMuDQo+DQo+IEJ1dCBJIHNlZSB5b3VyIHBvaW50LiBXZSBuZWVkIHRvIHdv cmQgdGhpcyBjYXJlZnVsbHkuDQo+DQo+DQo+IENocmlzdGVyLCBJIHN0aWxsIGRvbid0IGdldCB3 aGF0J3Mgd3Jvbmcgd2l0aCB0aGUgDQo+IDNHUFAgdGVybWlub2xvZ3kuIENhbiB5b3UgY2xhcmlm eT8gDQo+DQo+ICAgDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogUGF1 bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRAY2lzY28uY29tXSANCj4+IFNlbnQ6IFR1ZXNkYXks IEp1bmUgMTYsIDIwMDkgMTA6NDQNCj4+IFRvOiBBdWRldCwgRnJhbmNvaXMgKFNDMTAwOjMwNTUp DQo+PiBDYzogQ2hyaXN0ZXIgSG9sbWJlcmc7IEhhbnMgRXJpayB2YW4gRWxidXJnOyBCYXJuZXMs IE1hcnkgDQo+PiAoUklDSDI6QVIwMCk7IFNoaWRhIFNjaHViZXJ0OyBzaXBjb3JlQGlldGYub3Jn DQo+PiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIGRyYWZ0LWJhcm5lcy1zaXBjb3JlLXJmYzQyNDRi aXMgYW5kIHRhcmdldC11cmkNCj4+DQo+PiBGcmFuY29pcyBBdWRldCB3cm90ZToNCj4+DQo+PiAg ICAgDQo+Pj4+IEJ1dCwgSSB0aGluayB0aGVyZSBpcyBhIHNtYWxsIG1pc3N1bmRlcnN0YWRpbmcg Zm9yIHRoZSBBT1ItdG8tQU9SIA0KPj4+PiBjYXNlcy4NCj4+Pj4NCj4+Pj4gV2UgZG9uJ3QgdGhp bmsgeW91IG5lZWQgdG8ga25vdyB3aGV0aGVyIHRoZSBuZXcgQU9SIGlzIGFuIGFsaWFzIG9yIA0K Pj4+PiBub3QuIFlvdSBuZWVkIHRvIGtub3cgd2hldGhlciB0aGUgbmV3IEFPUiBiZWxvbmdzIHRv IHRoZSANCj4+Pj4gICAgICAgICANCj4+IHNhbWUgdXNlciBvciANCj4+ICAgICANCj4+Pj4gbm90 Lg0KPj4+PiAgICAgICAgIA0KPj4+IFRvIG1lLCB0aGF0IGlzIHRoZSBkZWZpbml0aW9uIG9mIGFu IGFsaWFzLg0KPj4+ICAgICAgIA0KPj4gSSBoYXZlIHRvIGRpZmZlciBoZXJlLg0KPj4NCj4+IEkg bWF5IG93biBhIGJ1bmNoIG9mIEFPUnMuIFNvbWUgb2YgdGhlbSBtYXkgYmUgYWxpYXNlcywgDQo+ PiBvdGhlcnMgbWF5IG5vdCBiZS4gRm9yIGluc3RhbmNlOg0KPj4NCj4+IC0gc2lwOnBreXppdmF0 QGV4YW1wbGUubmV0IGFuZCBwYXVsLmt5eml2YXRAZXhhbXBsZS5uZXQNCj4+ICAgIG1pZ2h0IGJl IGFsaWFzZXMuDQo+Pg0KPj4gLSBzaXA6cGt5eml2YXQuaWV0ZkBleGFtcGxlLm5ldCBhbmQgc2lw OnBreXppdmF0Lmp1bmtAZXhhbXBsZS5uZXQNCj4+ICAgIG1heSBiZSBkZXNpZ25lZCB0byBidWNr ZXQgc3BlY2lmaWMga2luZHMgb2YgdHJhZmZpYywgYW5kIHNvDQo+PiAgICBub3QgYmUgYWxpYXNl cy4NCj4+DQo+PiAJVGhhbmtzLA0KPj4gCVBhdWwNCj4+DQo+PiAgICAgDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QN CnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2lwY29yZQ0K From pkyzivat@cisco.com Tue Jun 16 11:14:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADD513A6BA6 for ; Tue, 16 Jun 2009 11:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.545 X-Spam-Level: X-Spam-Status: No, score=-6.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msPi7WuifcRk for ; Tue, 16 Jun 2009 11:14:26 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 73A703A6B80 for ; Tue, 16 Jun 2009 11:14:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,230,1243814400"; d="scan'208";a="47576793" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Jun 2009 18:14:30 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5GIEUCT006335; Tue, 16 Jun 2009 14:14:30 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5GIEUA2010961; Tue, 16 Jun 2009 18:14:30 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 14:14:30 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 14:14:29 -0400 Message-ID: <4A37E105.3010000@cisco.com> Date: Tue, 16 Jun 2009 14:14:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! <4 A36AC9C.3060 509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> <4A37D9E1.1040001@cisco.com> <1ECE0EB503 88174790F9694F77522CCF1E88E1D5@zrc2hxm0.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2009 18:14:29.0682 (UTC) FILETIME=[4A680120:01C9EEAE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2517; t=1245176070; x=1246040070; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20draft-barnes-sipcore-rfc424 4bis=20and=20target-uri |Sender:=20 |To:=20Christer=20Holmberg=20; bh=HNXttMIUmPSmStgZe4xq9ZCBxB+DWDnE3H1bvoS/Fj0=; b=Y7sXmAKc9mn47J7mPijycLRggrmvHWGtzuWyy4HoNzSdqdGRuBKZvBVzNF UV+5LYtDLKqa/VCaWE//YKvM69rA3ICOOpbVrAeIo8RdR7Yi78eylAA7cBUp Gs5t4N0D5H; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 18:14:27 -0000 If I understand 3gpp terminology correctly, then I think that definition of alias is really problematic here. Specifically, in 3pgg AFAIK there is no real distinction between a primary AOR and its aliases - there are just a bunch of URIs that are siblings. When you register with any one of the siblings, it shares the registered contacts with the others. So when a request arrives addressed to one of the siblings, then it is immediately retargeted to the registered contacts. There is no translation from the "alias" to the "real AOR" and then to the contacts. So any H-I tagging that implied such a translation would be problematic. Or have things changed since I was last paying attention to 3gpp? (Which has been a couple of years now.) Thanks, Paul Christer Holmberg wrote: > > >> I'm thinking it's the first case we are talking about. >> >> The second case IMHO is multiple logical users. >> >> But I see your point. We need to word this carefully. >> >> Christer, I still don't get what's wrong with the 3GPP terminology. Can > you clarify? > > I think the 3GPP terminology is just fine :) > > What I am saying is that a freephone number is not necessarily an alias > - based on the 3GPP terminology. > > The 1-800 number is not necessarily implicitly registered for the AOR it > is translated into. > > Regards, > > Christer > > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Tuesday, June 16, 2009 10:44 >> To: Audet, Francois (SC100:3055) >> Cc: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary >> (RICH2:AR00); Shida Schubert; sipcore@ietf.org >> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >> >> Francois Audet wrote: >> >>>> But, I think there is a small missunderstading for the AOR-to-AOR >>>> cases. >>>> >>>> We don't think you need to know whether the new AOR is an alias or >>>> not. You need to know whether the new AOR belongs to the >> same user or >>>> not. >>> To me, that is the definition of an alias. >> I have to differ here. >> >> I may own a bunch of AORs. Some of them may be aliases, others may not > >> be. For instance: >> >> - sip:pkyzivat@example.net and paul.kyzivat@example.net >> might be aliases. >> >> - sip:pkyzivat.ietf@example.net and sip:pkyzivat.junk@example.net >> may be designed to bucket specific kinds of traffic, and so >> not be aliases. >> >> Thanks, >> Paul >> > From pkyzivat@cisco.com Tue Jun 16 11:17:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A1A03A6A91 for ; Tue, 16 Jun 2009 11:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.547 X-Spam-Level: X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8D9XAWwJA7uZ for ; Tue, 16 Jun 2009 11:17:52 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 9C60C3A6B73 for ; Tue, 16 Jun 2009 11:17:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,230,1243814400"; d="scan'208";a="170423768" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 16 Jun 2009 18:18:03 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5GII3YU021785; Tue, 16 Jun 2009 11:18:03 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5GII1jk001844; Tue, 16 Jun 2009 18:18:03 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 14:18:03 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 14:18:02 -0400 Message-ID: <4A37E1D9.4090902@cisco.com> Date: Tue, 16 Jun 2009 14:18:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Francois Audet References: <1ECE0EB50388174790F9694F77522CCF1E88DA09@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E17D@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E1A2@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88E1A2@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2009 18:18:02.0820 (UTC) FILETIME=[C9724840:01C9EEAE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1070; t=1245176283; x=1246040283; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20draft-barnes-sipcore-rfc424 4bis=20and=20target-uri |Sender:=20; bh=xVu8npYwXyFc+PLycHdLBHnTmlDWywhLPDZN/JNKZt8=; b=OgrJ68VxsIPTJaoS6ZQNt3pk01Vaq/uwG1MvS4cnGcNwZIDVgsE8hkjZl1 seJPmbAK8xUFUn4cgCvFVFOW23bHEv1Lekfg3fjqLztaLJjUQ1q3wGwW7k8b BoSVXsSeNS; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 18:17:53 -0000 Francois Audet wrote: > Do people prefer short names or long names? > > I don't care much. I was just in a short name a-la ;lr type > of mood. While I don't like really-really-long-names for this sort of use, I don't love really short ones either. IMO best would be short words or acronyms that make some sense without being memorized. Thanks, Paul >> -----Original Message----- >> From: Barnes, Mary (RICH2:AR00) >> Sent: Tuesday, June 16, 2009 10:41 >> To: Audet, Francois (SC100:3055); Christer Holmberg; Hans >> Erik van Elburg; Shida Schubert >> Cc: sipcore@ietf.org >> Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >> >> I can live with the short names (I guess), as long as it >> doesn't bother anyone else. So, the aliases then are >> "implicit" versus "explicit" - i.e., you'll know that it's an >> alias because it will be labeled with the ..;rt;aor tags? > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From ietf.hanserik@gmail.com Tue Jun 16 11:22:18 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B3F93A6BDA for ; Tue, 16 Jun 2009 11:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.122 X-Spam-Level: X-Spam-Status: No, score=-2.122 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnhJwAk6Oyej for ; Tue, 16 Jun 2009 11:22:17 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id DF87B3A6D7B for ; Tue, 16 Jun 2009 11:22:16 -0700 (PDT) Received: by ewy6 with SMTP id 6so6251457ewy.37 for ; Tue, 16 Jun 2009 11:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=NQWNTBTb+i68B+XHFTdBwOf8fid7pqo+91FDkbQEEd8=; b=RBYGWS89qjaptWoY1oc2123lOxdNKhVkP1fAAn3bvXru3vqZmPPQ7JH2/5XI330wbx 7wZetwmGm1f5NDktqoocQ5VMnBv6+aCNqCkWc4RLmSFrKgRTfWnQl+Rdtru/UzG/nAe1 CPE39Ott7Log/5DXfV1S36LCvIkwa53wMJNqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Py5pT1WmKPPUisJz2NvXZRYRvLIYxGjTaVWSzQEkKPM28Et29TQijPSyMgv7sRikeH EGiGONSOalw38wHXDP5UWjWh4I/gKTVPgVWDprWgHxAFCWDYj3aXeelhDx0PXHyXmAKK qLts+Ek0u5RDVMWxw1yunK3II/kmFrYQIa0Ss= Received: by 10.210.131.6 with SMTP id e6mr1557294ebd.81.1245176544862; Tue, 16 Jun 2009 11:22:24 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 23sm173913eya.19.2009.06.16.11.22.21 (version=SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 11:22:22 -0700 (PDT) Message-ID: <4A37E2DC.8020204@gmail.com> Date: Tue, 16 Jun 2009 20:22:20 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Paul Kyzivat References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! <4 A36AC9C.3060 509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> <4A37D9E1.1040001@cisco.com> <1ECE0EB503 88174790F9694F77522CCF1E88E1D5@zrc2hxm0.corp.nortel.com> <4A37E105.3010000@cisco.com> In-Reply-To: <4A37E105.3010000@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 18:22:18 -0000 Exactly it is confusing, to use this term for AOR -> AOR translations where both AOR's belong to the same user. There is no need for special tagging in this case, as the UA knows with which AOR it registered. In IMS the AOR that was called is delivered to the UA in the P-Called-Party-ID, in the solution that Francois sketched it would be the last hi-entry that is tagged "aor". /Hans Erik Paul Kyzivat wrote: > If I understand 3gpp terminology correctly, then I think that > definition of alias is really problematic here. > > Specifically, in 3pgg AFAIK there is no real distinction between a > primary AOR and its aliases - there are just a bunch of URIs that are > siblings. When you register with any one of the siblings, it shares > the registered contacts with the others. > > So when a request arrives addressed to one of the siblings, then it is > immediately retargeted to the registered contacts. There is no > translation from the "alias" to the "real AOR" and then to the > contacts. So any H-I tagging that implied such a translation would be > problematic. > > Or have things changed since I was last paying attention to 3gpp? > (Which has been a couple of years now.) > > Thanks, > Paul > > Christer Holmberg wrote: >> >> >>> I'm thinking it's the first case we are talking about. >>> >>> The second case IMHO is multiple logical users. >>> >>> But I see your point. We need to word this carefully. >>> >>> Christer, I still don't get what's wrong with the 3GPP terminology. Can >> you clarify? >> I think the 3GPP terminology is just fine :) >> >> What I am saying is that a freephone number is not necessarily an alias >> - based on the 3GPP terminology. >> >> The 1-800 number is not necessarily implicitly registered for the AOR it >> is translated into. >> >> Regards, >> >> Christer >> >> >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>> Sent: Tuesday, June 16, 2009 10:44 >>> To: Audet, Francois (SC100:3055) >>> Cc: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary >>> (RICH2:AR00); Shida Schubert; sipcore@ietf.org >>> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >>> >>> Francois Audet wrote: >>> >>>>> But, I think there is a small missunderstading for the AOR-to-AOR >>>>> cases. >>>>> >>>>> We don't think you need to know whether the new AOR is an alias or >>>>> not. You need to know whether the new AOR belongs to the >>> same user or >>>>> not. >>>> To me, that is the definition of an alias. >>> I have to differ here. >>> >>> I may own a bunch of AORs. Some of them may be aliases, others may not >> >>> be. For instance: >>> >>> - sip:pkyzivat@example.net and paul.kyzivat@example.net >>> might be aliases. >>> >>> - sip:pkyzivat.ietf@example.net and sip:pkyzivat.junk@example.net >>> may be designed to bucket specific kinds of traffic, and so >>> not be aliases. >>> >>> Thanks, >>> Paul >>> >> From drage@alcatel-lucent.com Tue Jun 16 11:22:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755603A6BA4 for ; Tue, 16 Jun 2009 11:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.864 X-Spam-Level: X-Spam-Status: No, score=-4.864 tagged_above=-999 required=5 tests=[AWL=1.385, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDGutZFPesxt for ; Tue, 16 Jun 2009 11:22:27 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 5D0BA3A6A91 for ; Tue, 16 Jun 2009 11:22:27 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n5GIMWiP025732 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 16 Jun 2009 20:22:33 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 16 Jun 2009 20:22:32 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , Francois Audet Date: Tue, 16 Jun 2009 20:22:30 +0200 Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: AcnuruDnulcUlKUNQ4qVhZQqH6AOdQAACzEw Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1E88DA09@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E17D@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E1A2@zrc2hxm0.corp.nortel.com> <4A37E1D9.4090902@cisco.com> In-Reply-To: <4A37E1D9.4090902@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.57 on 155.132.188.13 Cc: "sipcore@ietf.org" , Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 18:22:28 -0000 I prefer something longer than two characters. Two characters does not even= aid my failing memory in trying to work out what it is. I don't believe it= needs to be fixed length either. Providing we don't get exceedingly long e= ither - lets just say they should not exceed 20 per cent of average URI len= gth (plucking figures out of the air). With two characters you might just a= s well use a bitstring or some other binary concept. Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, June 16, 2009 7:18 PM > To: Francois Audet > Cc: sipcore@ietf.org; Shida Schubert > Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >=20 >=20 > Francois Audet wrote: > > Do people prefer short names or long names? > >=20 > > I don't care much. I was just in a short name a-la ;lr type of mood. >=20 > While I don't like really-really-long-names for this sort of=20 > use, I don't love really short ones either. IMO best would be=20 > short words or acronyms that make some sense without being memorized. >=20 > Thanks, > Paul >=20 >=20 > >> -----Original Message----- > >> From: Barnes, Mary (RICH2:AR00) > >> Sent: Tuesday, June 16, 2009 10:41 > >> To: Audet, Francois (SC100:3055); Christer Holmberg; Hans Erik van=20 > >> Elburg; Shida Schubert > >> Cc: sipcore@ietf.org > >> Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri > >> > >> I can live with the short names (I guess), as long as it doesn't=20 > >> bother anyone else. So, the aliases then are "implicit" versus=20 > >> "explicit" - i.e., you'll know that it's an alias because=20 > it will be=20 > >> labeled with the ..;rt;aor tags? > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Tue Jun 16 11:29:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 521FC3A6BDD for ; Tue, 16 Jun 2009 11:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.691 X-Spam-Level: X-Spam-Status: No, score=-5.691 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2N8ZRPmDqMX for ; Tue, 16 Jun 2009 11:29:08 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A673A3A6D8A for ; Tue, 16 Jun 2009 11:29:00 -0700 (PDT) X-AuditID: c1b4fb3c-b7b0bae00000673a-dd-4a37aaddf3a6 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 62.C8.26426.DDAA73A4; Tue, 16 Jun 2009 16:23:25 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 16:23:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 16:23:24 +0200 Message-ID: In-Reply-To: <4A379DD1.20600@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: AcnuhkLj+WQ260zeTwWccGXgip80LgAAqUkg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! <4A3 6AC9C.306050 9@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <4A379DD1.20600@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 16 Jun 2009 14:23:24.0819 (UTC) FILETIME=[024DCE30:01C9EE8E] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 18:29:09 -0000 Hi,=20 >>"rc" and "ic" look rather ok. But, for "ic" you need to change "but = was not discovered using SIP Registration",=20 >>because you may discover it using the P-Associated-URI header (if you = support it). So, I propose something like: >>=20 >> ic : The entry is an implicit registered contact=20 >>(i.e., it's exactly as a registered contact, >> but was not provided in a REGISTER request: it=20 >>could have been manually configured >> or done with a proprietary mechanism). >>=20 >>=20 >>But, I think there is a small missunderstading for the AOR-to-AOR = cases. >>=20 >>We don't think you need to know whether the new AOR is an alias or = not. You need to know whether the new AOR belongs to=20 >>the same user or not. >=20 >This concept is still bugging me. >Precisely what do you mean by "new AOR *belongs* to the same user"? Mabye bad wording. Is a synonym to the same user. Both AORs point to the = same user. I call 1-800-DUDE, which is translated by a freephone service to = christer@sip.com.=20 >And why does that matter? You have said that these might=20 >reside in different domains, and that the tagging will simply=20 >be configured. The translation will be configured, as part of the service, yes. >In the end it isn't the one doing the tagging that cares,=20 >rather it is the one receiving the tagged entry that cares=20 >isn't it? Yes. The tagging is done so that the receiver knows what/where has = happended. >So in some sense this is a matter of the "owner" of=20 >the downstream URI instructing the owner of the upstream URI=20 >to tag the entry in a way that the downstream URI will recognize. >=20 >Yet doing it *that* abstractly is likely to lead to a tower of babel.=20 >I'm still groping for the semantic meaning of the tag. And in=20 >practice remain unconvinced that it is needed at all. If the=20 >owner of the downstream URI has requested the mapping from=20 >the owner of the upstream URI, doesn't it know what upstream=20 >URIs map to it? Can't it check them by value, without a tag? You are making the assumption that the called user has all the = information, but we don't think that should be mandated. Also, if you have some kind of gateway which needs the information, and = the gateway serves thousands of users, you would have to configure all = that information for each and every user served by the gateway. So, why should one be mandated to use configuration for this, when it = can be indicated in the signalling? Regards, Christer >=20 > Overall, what I am looking for is a complete partitioning of=20 > the space into disjoint subspaces covering the whole space.=20 > In the past, this partitioning as been done informally and=20 > incompletely as "AOR" vs.=20 > "Contact". We all knew that wasn't either disjoint or=20 > complete. And we have always acted as if this is an inherent=20 > property of a URI, rather than a usage context. But of course=20 > it isn't that simple - one person's AOR can be another=20 > person's Contact. The current approach is about describing=20 > the role of a URI in context, which at least has a chance to=20 > be determinable, so its at least on the right track. >=20 > The trouble with H-I in this regard is that there seems no=20 > good reason to believe that middleboxes will preserve the=20 > entries that will ultimately be required. >=20 > Thanks, > Paul >=20 > > So, in case of diversion, where the user is changed, I=20 > assume "mp" is used. > >=20 > > For freephone, where the user is not changed, one could use=20 > "rt". But, I don't think it matters in which domain the=20 > translation takes place, or whether the new AOR is an alias or not. > >=20 > > So, my proposal would be something like: > >=20 > > rt : The entry is "routed", i.e., it is either a=20 > no-opt like a proxy forwarding within > > a domain, predetermined by a maddr in the=20 > Request-URI, or when the request-URI is changed to a new URI=20 > that represent the same user. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > =20 > >=20 > >> -----Original Message----- > >> From: Francois Audet [mailto:audet@nortel.com] > >> Sent: 16. kes=E4kuuta 2009 4:44 > >> To: Christer Holmberg; Hans Erik van Elburg; Mary Barnes; Shida=20 > >> Schubert > >> Cc: sipcore@ietf.org > >> Subject: draft-barnes-sipcore-rfc4244bis and target-uri > >> > >> All right guys, > >> > >> I've been thinking about this. > >> > >> It seems to me that what we want to capture is: > >> 1) If the target is an AOR, a contact, or a routing URI=20 > (maddr, noop=20 > >> intra-domain, or noop > >> forward to next domain, or strict routing). > >> 2) In the case that the target is an AOR, then if that AOR=20 > is known=20 > >> to be an alias for the previous > >> one, or if it is mapped to another AOR. > >> > >> It seems to me that a Proxy should mark a Previous entry=20 > in H-I with=20 > >> aor if it determines that it owns this AOR. Just as Hans's current=20 > >> target-uri draft. > >> > >> Now, for the mapped vs routed (versus reg-contact, etc.),=20 > instead of=20 > >> marking the Previous entry, we should mark the OUTGOING=20 > (i.e., New)=20 > >> entry instead. This would make the procedures of > >> 7.2.1 & 7.2.2 of target-URI draft clearer. > >> > >> Specifically, the logic would be: > >> > >> When proxy receives an incoming request with H-I, it adds=20 > an ;aor tag=20 > >> to that incoming entry if it determines that it is responsible for=20 > >> the AOR and. > >> > >> Also, if there was no Hi-entry at all (i.e., it came from=20 > a UAC), and=20 > >> the Proxy creates then two entries, the first one in this=20 > case would=20 > >> also have the ;aor tag associated to it. > >> > >> For the Outgoing entry, I would see the following tags: > >> > >> rc : The entry is an explicit registered contact=20 > >> (i.e., it was provided in a REGISTER message) > >> > >> ic : The entry is an implicit registered contact=20 > >> (i.e., it's exactly as a registered contact, > >> but was not discovered using SIP Registration:=20 > >> it could have been manually configured > >> or done with a proprietary mechanism). > >> > >> (TBD: we could debate if we need both rc and=20 > irc, but I think we=20 > >> do). > >> > >> mp : The request-URI is changed to a new URI that=20 > >> represent another user. > >> > >> rt : The entry is "routed", i.e., it is either a=20 > >> no-opt like a proxy forwarding within > >> a domain, predetermined by a maddr in the=20 > Request-URI, or when=20 > >> proxy is NOT responsible > >> for domain, or the address is an alias for the=20 > incoming URI. > >> > >> So, to give an example.=20 > >> > >> Say Alice calls Bob. Bob is forwarded to freephone.=20 > Freephone routes=20 > >> to Carol. > >> > >> The History-info at Carol would look like this: > >> > >> Alice -> example.com > >> Nothing because UAC typically doesn't send H-I (otherwise,=20 > it would=20 > >> be as per Index 1 in next entry, but without the AOR. > >> > >> example.com -> freephone@example.net > >> History-Info: ;index=3D1;aor > >> History-Info: ;index=3D1.1;mp > >> > >> example.net -> carol@example.net > >> History-Info: ;index=3D1;aor =20 > >> History-Info: ;index=3D1.1;mp;aor > >> <- aor is added > >> History-Info: ;index=3D1.1.1;rt;aor }=20 > >> Two entries are > >> History-Info: ;index=3D1.1.1.1;rc }=20 > >> added at same time > >> > >> Also, I don't think we need to define an equivalent to the=20 > >> "reg-uri-alias" anymore. > >> If Freephone was configured to go to +14085551212 instead of the=20 > >> registered Contact (assuming +14085551212 was an Alias AOR for=20 > >> carol@example.net), the last H-I entries would look like this=20 > >> instead: > >> > >> example.net -> carol@example.net > >> History-Info: ;index=3D1;aor =20 > >> History-Info:=20 > >> ;index=3D1.1;mp;aor=20 > <- aor is=20 > >> added > >> History-Info: ;index=3D1.1.1;rt;aor > >> <- aor is added > >> History-Info: ;index=3D1.1.1.1;rt;aor =20 > >> } Two entries are > >> History-Info: ;index=3D1.1.1.1.1;rc =20 > >> } added at same time > >> > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 >=20 From pkyzivat@cisco.com Tue Jun 16 11:29:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AED93A6A02 for ; Tue, 16 Jun 2009 11:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9vRWyuh71jD for ; Tue, 16 Jun 2009 11:29:28 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B38DE3A6A91 for ; Tue, 16 Jun 2009 11:29:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,230,1243814400"; d="scan'208";a="47530923" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 16 Jun 2009 18:29:38 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5GITc0J013901; Tue, 16 Jun 2009 14:29:38 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5GITcjS006507; Tue, 16 Jun 2009 18:29:38 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 14:29:38 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 14:29:37 -0400 Message-ID: <4A37E491.1090405@cisco.com> Date: Tue, 16 Jun 2009 14:29:37 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Hans Erik van Elburg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! <4 A36AC9C.3060 509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> <4A37D9E1.1040001@cisco.com> <1ECE0EB503 88174790F9694F77522CCF1E88E1D5@zrc2hxm0.corp.nortel.com> <4A37E105.3010000@cisco.com> <4A37E2DC.8020204@gmail.com> In-Reply-To: <4A37E2DC.8020204@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2009 18:29:37.0827 (UTC) FILETIME=[67B3EF30:01C9EEB0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3283; t=1245176978; x=1246040978; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20draft-barnes-sipcore-rfc424 4bis=20and=20target-uri |Sender:=20 |To:=20Hans=20Erik=20van=20Elburg=20; bh=RQw0cL/w9+/UOQXu67JJARLxnXEvzopIZVZJOMNAbag=; b=bEf4k2UqYH1617nIDBHeobUxko5nLOzmbysshr+oLXDR77ja9rQxWsqZY+ ZbwXAslOqb/jc7ZPtPACHDtqBEIrxt+cpFOMVfL5ljmT54mVPK96g6Q8SrFI oUYBojQBkJ; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 18:29:29 -0000 Hans Erik van Elburg wrote: > Exactly it is confusing, to use this term for AOR -> AOR translations > where both AOR's belong to the same user. > > There is no need for special tagging in this case, as the UA knows with > which AOR it registered. > > In IMS the AOR that was called is delivered to the UA in the > P-Called-Party-ID, in the solution that Francois sketched it would be > the last hi-entry that is tagged "aor". Then we shouldn't be using the 3gpp definition of alias in this discussion. Thanks, Paul > /Hans Erik > > Paul Kyzivat wrote: >> If I understand 3gpp terminology correctly, then I think that >> definition of alias is really problematic here. >> >> Specifically, in 3pgg AFAIK there is no real distinction between a >> primary AOR and its aliases - there are just a bunch of URIs that are >> siblings. When you register with any one of the siblings, it shares >> the registered contacts with the others. >> >> So when a request arrives addressed to one of the siblings, then it is >> immediately retargeted to the registered contacts. There is no >> translation from the "alias" to the "real AOR" and then to the >> contacts. So any H-I tagging that implied such a translation would be >> problematic. >> >> Or have things changed since I was last paying attention to 3gpp? >> (Which has been a couple of years now.) >> >> Thanks, >> Paul >> >> Christer Holmberg wrote: >>> >>> >>>> I'm thinking it's the first case we are talking about. >>>> >>>> The second case IMHO is multiple logical users. >>>> >>>> But I see your point. We need to word this carefully. >>>> >>>> Christer, I still don't get what's wrong with the 3GPP terminology. Can >>> you clarify? >>> I think the 3GPP terminology is just fine :) >>> >>> What I am saying is that a freephone number is not necessarily an alias >>> - based on the 3GPP terminology. >>> >>> The 1-800 number is not necessarily implicitly registered for the AOR it >>> is translated into. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Tuesday, June 16, 2009 10:44 >>>> To: Audet, Francois (SC100:3055) >>>> Cc: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary >>>> (RICH2:AR00); Shida Schubert; sipcore@ietf.org >>>> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >>>> >>>> Francois Audet wrote: >>>> >>>>>> But, I think there is a small missunderstading for the AOR-to-AOR >>>>>> cases. >>>>>> >>>>>> We don't think you need to know whether the new AOR is an alias or >>>>>> not. You need to know whether the new AOR belongs to the >>>> same user or >>>>>> not. >>>>> To me, that is the definition of an alias. >>>> I have to differ here. >>>> >>>> I may own a bunch of AORs. Some of them may be aliases, others may not >>> >>>> be. For instance: >>>> >>>> - sip:pkyzivat@example.net and paul.kyzivat@example.net >>>> might be aliases. >>>> >>>> - sip:pkyzivat.ietf@example.net and sip:pkyzivat.junk@example.net >>>> may be designed to bucket specific kinds of traffic, and so >>>> not be aliases. >>>> >>>> Thanks, >>>> Paul >>>> >>> > From drage@alcatel-lucent.com Tue Jun 16 11:33:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79B123A6A91 for ; Tue, 16 Jun 2009 11:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.963 X-Spam-Level: X-Spam-Status: No, score=-2.963 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeRb6CqV8rOs for ; Tue, 16 Jun 2009 11:33:26 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by core3.amsl.com (Postfix) with ESMTP id 64F7B3A6A2F for ; Tue, 16 Jun 2009 11:33:26 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n5GIXUXr002294 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 16 Jun 2009 20:33:30 +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; Tue, 16 Jun 2009 20:33:31 +0200 From: "DRAGE, Keith (Keith)" To: Mary Barnes , Francois Audet , Christer Holmberg , Hans Erik van Elburg , Shida Schubert Date: Tue, 16 Jun 2009 20:33:29 +0200 Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAFn+ocAAVBjIQAABMeEAAACJowAAAUkGwAAHQjbA= Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! ! ! <4A36AC9C. 3060509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.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.57 on 155.132.188.84 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 18:33:27 -0000 Can we also not have a history-info specific meaning for the word "alias". It gets used in RFC 3325 without formal definition (if I recall correctly) = and in a number of other documents as well. By giving it a more specific meaning here, you may end up changing the mean= ing of other RFCs. regards Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: Tuesday, June 16, 2009 6:41 PM > To: Francois Audet; Christer Holmberg; Hans Erik van Elburg;=20 > Shida Schubert > Cc: sipcore@ietf.org > Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Now, I'm confused as I thought the alias must be an AOR. I'm in the > midst of a response to another email on this topic. =20 >=20 > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Tuesday, June 16, 2009 12:32 PM > To: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary=20 > (RICH2:AR00); Shida Schubert > Cc: sipcore@ietf.org > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Yeah, I would fix that. >=20 > So.... >=20 > So, it looks like we are in agreement. I think I should=20 > up-issue the document. >=20 > Agreed? >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, June 16, 2009 10:30 > > To: Audet, Francois (SC100:3055); Hans Erik van Elburg;=20 > Barnes, Mary=20 > > (RICH2:AR00); Shida Schubert > > Cc: sipcore@ietf.org > > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri > >=20 > >=20 > > Hi, > >=20 > > >>But, I think there is a small missunderstading for the AOR-to-AOR > > cases. > > >>=20 > > >>We don't think you need to know whether the new AOR is an=20 > alias or=20 > > >>not. You need to know whether the new AOR belongs to the > > same user or > > >>not. > > > > > >To me, that is the definition of an alias. > >=20 > > Fine, but that is not the current definition in 4244bis, which says=20 > > that an alias is an implictity/explicitly registered AOR...=20 > With your=20 > > new definition an alias may be registered, or it may not.=20 > It may be an >=20 > > AOR, or it may not. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From mary.barnes@nortel.com Tue Jun 16 12:00:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214353A6DB2 for ; Tue, 16 Jun 2009 12:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.346 X-Spam-Level: X-Spam-Status: No, score=-6.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOURaz1i6Ity for ; Tue, 16 Jun 2009 12:00:04 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 72AEC3A6DC2 for ; Tue, 16 Jun 2009 12:00:04 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5GJ0Bc10975; Tue, 16 Jun 2009 19:00:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 14:02:38 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E88E3A8@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri thread-index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAFn+ocAAVBjIQAABMeEAAACJowAAAUkGwAAHQjbAAAGGn0A== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com><1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>! ! ! ! ! ! ! <4A36AC9C . 3060509@gm ail.com><1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "DRAGE, Keith (Keith)" , "Francois Audet" , "Christer Holmberg" , "Hans Erik van Elburg" , "Shida Schubert" Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 19:00:06 -0000 Keith,=20 The term "alias" is not used in RFC 3325. It is used once in RFC 3324 and I can't see that the proposed definition is confusing or conflicting as it is used in a fairly general sense. The term alias is used once in GRUU: "In cases where the UA uses a tel URI (as defiend in [11]) to populate the From header field, the UA typically has a SIP AOR that is treated as an alias for the tel URI." And, the reference [11] does not use the term alias.=20 Identity (RFC 4474) does use the term alias (once): "It must be possible for a user to have multiple AoRs (i.e., accounts or aliases) that it is authorized to use within a domain..." The most prolific user of the term alias is connection-reuse, where the term is defined, but that context is entirely different than what we are talking about here, so I don't see a problem.=20 And, I don't see any more suspects of concern when I google: draft-ietf-sip alias I found one enum document that talks about aliasing with DNS. Digging down to the 3rd page of hits, Hannes does use it in one of his docs about SPIT, but again the usage is consistent with the usage in Identity. And, if you dig down to the fourth page, you can find an interesting patent that uses the term. One thing I have found with google is that you do get different results with different browsers - I used IE. So, I don't see the concern, since the most explicit usage in Identity is exactly what I thought we were talking about. Once we finally agree these terms, we are proposing to write an update to section 16.5 in RFC 3261 since the plan is to define precise terms for the mechanisms by which the targets are determined.=20 Regards, Mary -----Original Message----- From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 Sent: Tuesday, June 16, 2009 1:33 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Christer Holmberg; Hans Erik van Elburg; Shida Schubert Cc: sipcore@ietf.org Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri Can we also not have a history-info specific meaning for the word "alias". It gets used in RFC 3325 without formal definition (if I recall correctly) and in a number of other documents as well. By giving it a more specific meaning here, you may end up changing the meaning of other RFCs. regards Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: Tuesday, June 16, 2009 6:41 PM > To: Francois Audet; Christer Holmberg; Hans Erik van Elburg; Shida=20 > Schubert > Cc: sipcore@ietf.org > Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Now, I'm confused as I thought the alias must be an AOR. I'm in the > midst of a response to another email on this topic. =20 >=20 > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Tuesday, June 16, 2009 12:32 PM > To: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary=20 > (RICH2:AR00); Shida Schubert > Cc: sipcore@ietf.org > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Yeah, I would fix that. >=20 > So.... >=20 > So, it looks like we are in agreement. I think I should up-issue the=20 > document. >=20 > Agreed? >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, June 16, 2009 10:30 > > To: Audet, Francois (SC100:3055); Hans Erik van Elburg; > Barnes, Mary > > (RICH2:AR00); Shida Schubert > > Cc: sipcore@ietf.org > > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri > >=20 > >=20 > > Hi, > >=20 > > >>But, I think there is a small missunderstading for the AOR-to-AOR > > cases. > > >>=20 > > >>We don't think you need to know whether the new AOR is an > alias or > > >>not. You need to know whether the new AOR belongs to the > > same user or > > >>not. > > > > > >To me, that is the definition of an alias. > >=20 > > Fine, but that is not the current definition in 4244bis, which says=20 > > that an alias is an implictity/explicitly registered AOR... > With your > > new definition an alias may be registered, or it may not.=20 > It may be an >=20 > > AOR, or it may not. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Tue Jun 16 12:42:21 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 009913A6B92 for ; Tue, 16 Jun 2009 12:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcRd1kdQtfAV for ; Tue, 16 Jun 2009 12:42:20 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 775EF3A69A6 for ; Tue, 16 Jun 2009 12:42:19 -0700 (PDT) X-AuditID: c1b4fb3c-b7b0bae00000673a-76-4a37f5692af0 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 04.D8.26426.965F73A4; Tue, 16 Jun 2009 21:41:29 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 21:41:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 21:41:28 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88E3A8@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAFn+ocAAVBjIQAABMeEAAACJowAAAUkGwAAHQjbAAAGGn0AABtk/Q References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com><1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>! ! ! ! ! ! ! <4A36AC 9C. 3060509@ gmail.com><1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E3A8@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Mary Barnes" , "DRAGE, Keith (Keith)" , "Francois Audet" , "Hans Erik van Elburg" , "Shida Schubert" X-OriginalArrivalTime: 16 Jun 2009 19:41:28.0615 (UTC) FILETIME=[7121FB70:01C9EEBA] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 19:42:21 -0000 Hi, draft-rosenberg-sipcore-target-uri-delivery-00 also talks about aliases (the text origins from the ua-loose-route draft). In chapter 4.1 the 3GPP definition is used. Chapter 4.6 (Toll free numbers) talks about "aliases in the PSTN network", but there is no real definition of what it really means. So, why can't we use the 3GPP definition for "alias", and when we talk about something else we could use "synonym"? Francois has already used that term. Using that terminology, in the freephone case the 1-800 number would be replaced by a synonym - not an alias. Regards, Christer =20 -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: Tuesday, June 16, 2009 10:03 PM To: DRAGE, Keith (Keith); Francois Audet; Christer Holmberg; Hans Erik van Elburg; Shida Schubert Cc: sipcore@ietf.org Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri Keith,=20 The term "alias" is not used in RFC 3325. It is used once in RFC 3324 and I can't see that the proposed definition is confusing or conflicting as it is used in a fairly general sense. The term alias is used once in GRUU: "In cases where the UA uses a tel URI (as defiend in [11]) to populate the From header field, the UA typically has a SIP AOR that is treated as an alias for the tel URI." And, the reference [11] does not use the term alias.=20 Identity (RFC 4474) does use the term alias (once): "It must be possible for a user to have multiple AoRs (i.e., accounts or aliases) that it is authorized to use within a domain..." The most prolific user of the term alias is connection-reuse, where the term is defined, but that context is entirely different than what we are talking about here, so I don't see a problem.=20 And, I don't see any more suspects of concern when I google: draft-ietf-sip alias I found one enum document that talks about aliasing with DNS. Digging down to the 3rd page of hits, Hannes does use it in one of his docs about SPIT, but again the usage is consistent with the usage in Identity. And, if you dig down to the fourth page, you can find an interesting patent that uses the term. One thing I have found with google is that you do get different results with different browsers - I used IE. So, I don't see the concern, since the most explicit usage in Identity is exactly what I thought we were talking about. Once we finally agree these terms, we are proposing to write an update to section 16.5 in RFC 3261 since the plan is to define precise terms for the mechanisms by which the targets are determined.=20 Regards, Mary -----Original Message----- From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] Sent: Tuesday, June 16, 2009 1:33 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Christer Holmberg; Hans Erik van Elburg; Shida Schubert Cc: sipcore@ietf.org Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri Can we also not have a history-info specific meaning for the word "alias". It gets used in RFC 3325 without formal definition (if I recall correctly) and in a number of other documents as well. By giving it a more specific meaning here, you may end up changing the meaning of other RFCs. regards Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: Tuesday, June 16, 2009 6:41 PM > To: Francois Audet; Christer Holmberg; Hans Erik van Elburg; Shida=20 > Schubert > Cc: sipcore@ietf.org > Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Now, I'm confused as I thought the alias must be an AOR. I'm in the > midst of a response to another email on this topic. =20 >=20 > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Tuesday, June 16, 2009 12:32 PM > To: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary=20 > (RICH2:AR00); Shida Schubert > Cc: sipcore@ietf.org > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Yeah, I would fix that. >=20 > So.... >=20 > So, it looks like we are in agreement. I think I should up-issue the=20 > document. >=20 > Agreed? >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, June 16, 2009 10:30 > > To: Audet, Francois (SC100:3055); Hans Erik van Elburg; > Barnes, Mary > > (RICH2:AR00); Shida Schubert > > Cc: sipcore@ietf.org > > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri > >=20 > >=20 > > Hi, > >=20 > > >>But, I think there is a small missunderstading for the AOR-to-AOR > > cases. > > >>=20 > > >>We don't think you need to know whether the new AOR is an > alias or > > >>not. You need to know whether the new AOR belongs to the > > same user or > > >>not. > > > > > >To me, that is the definition of an alias. > >=20 > > Fine, but that is not the current definition in 4244bis, which says=20 > > that an alias is an implictity/explicitly registered AOR... > With your > > new definition an alias may be registered, or it may not.=20 > It may be an >=20 > > AOR, or it may not. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Tue Jun 16 12:44:07 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56EAB28C1B7 for ; Tue, 16 Jun 2009 12:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.726 X-Spam-Level: X-Spam-Status: No, score=-5.726 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pdqVonSM1Yc for ; Tue, 16 Jun 2009 12:44:06 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 2B92828C1BA for ; Tue, 16 Jun 2009 12:43:45 -0700 (PDT) X-AuditID: c1b4fb3e-b7b1dae000006c99-62-4a37f5c49dd1 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 19.45.27801.4C5F73A4; Tue, 16 Jun 2009 21:43:00 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 21:42:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 21:42:36 +0200 Message-ID: In-Reply-To: <4A37E491.1090405@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: AcnusGl85zQt5LjiQ3Kgm2UiA3QXYgAChQPg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! <4 A36AC9C.3060 509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> <4A37D9E1.1040001@cisco.com> <1ECE0EB503 88174790F9694F77522CCF1E88E1D5@zrc2hxm0.corp.nortel.com> <4A37E105.3010000@cisco.com> <4A37E2DC.8020204@gmail.com> <4A37E491.10 90405@ci sco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Hans Erik van Elburg" X-OriginalArrivalTime: 16 Jun 2009 19:42:36.0425 (UTC) FILETIME=[998CF790:01C9EEBA] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 19:44:07 -0000 >> Exactly it is confusing, to use this term for AOR -> AOR translations >> where both AOR's belong to the same user. >>=20 >> There is no need for special tagging in this case, as the UA knows=20 >> with which AOR it registered. >>=20 >> In IMS the AOR that was called is delivered to the UA in the=20 >> P-Called-Party-ID, in the solution that Francois sketched it would be >> the last hi-entry that is tagged "aor". > >Then we shouldn't be using the 3gpp definition of alias in this discussion. I think we can use it. But, when we talk about something else we should use another word. Regards, Christer > /Hans Erik >=20 > Paul Kyzivat wrote: >> If I understand 3gpp terminology correctly, then I think that=20 >> definition of alias is really problematic here. >> >> Specifically, in 3pgg AFAIK there is no real distinction between a=20 >> primary AOR and its aliases - there are just a bunch of URIs that are >> siblings. When you register with any one of the siblings, it shares=20 >> the registered contacts with the others. >> >> So when a request arrives addressed to one of the siblings, then it=20 >> is immediately retargeted to the registered contacts. There is no=20 >> translation from the "alias" to the "real AOR" and then to the=20 >> contacts. So any H-I tagging that implied such a translation would be >> problematic. >> >> Or have things changed since I was last paying attention to 3gpp?=20 >> (Which has been a couple of years now.) >> >> Thanks, >> Paul >> >> Christer Holmberg wrote: >>> =20 >>> >>>> I'm thinking it's the first case we are talking about. >>>> >>>> The second case IMHO is multiple logical users. >>>> >>>> But I see your point. We need to word this carefully. >>>> >>>> Christer, I still don't get what's wrong with the 3GPP terminology. >>>> Can >>> you clarify? >>> I think the 3GPP terminology is just fine :) >>> >>> What I am saying is that a freephone number is not necessarily an=20 >>> alias >>> - based on the 3GPP terminology. >>> >>> The 1-800 number is not necessarily implicitly registered for the=20 >>> AOR it is translated into. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >>>> Sent: Tuesday, June 16, 2009 10:44 >>>> To: Audet, Francois (SC100:3055) >>>> Cc: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary=20 >>>> (RICH2:AR00); Shida Schubert; sipcore@ietf.org >>>> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and=20 >>>> target-uri >>>> >>>> Francois Audet wrote: >>>> >>>>>> But, I think there is a small missunderstading for the AOR-to-AOR >>>>>> cases. >>>>>> >>>>>> We don't think you need to know whether the new AOR is an alias=20 >>>>>> or not. You need to know whether the new AOR belongs to the >>>> same user or >>>>>> not. >>>>> To me, that is the definition of an alias. >>>> I have to differ here. >>>> >>>> I may own a bunch of AORs. Some of them may be aliases, others may=20 >>>> not >>> >>>> be. For instance: >>>> >>>> - sip:pkyzivat@example.net and paul.kyzivat@example.net >>>> might be aliases. >>>> >>>> - sip:pkyzivat.ietf@example.net and sip:pkyzivat.junk@example.net >>>> may be designed to bucket specific kinds of traffic, and so >>>> not be aliases. >>>> >>>> Thanks, >>>> Paul >>>> >>> >=20 From AUDET@nortel.com Tue Jun 16 12:58:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB4663A690C for ; Tue, 16 Jun 2009 12:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.346 X-Spam-Level: X-Spam-Status: No, score=-6.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANEd64AYLeBA for ; Tue, 16 Jun 2009 12:58:01 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 722433A68B1 for ; Tue, 16 Jun 2009 12:58:01 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5GJurc27212; Tue, 16 Jun 2009 19:56:53 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 14:56:45 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E88E54E@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri thread-index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAFn+ocAAVBjIQAABMeEAAACJowAAAUkGwAAHQjbAAAGGn0AABtk/QAADd9uA= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com><1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>! ! ! ! ! ! ! ! ! <4A36 AC9C. 306050 9@gmail.com><1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E3A8@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Christer Holmberg" , "Mary Barnes" , "DRAGE, Keith (Keith)" , "Hans Erik van Elburg" , "Shida Schubert" Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 19:58:02 -0000 That works for me.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Tuesday, June 16, 2009 12:41 > To: Barnes, Mary (RICH2:AR00); DRAGE, Keith (Keith); Audet,=20 > Francois (SC100:3055); Hans Erik van Elburg; Shida Schubert > Cc: sipcore@ietf.org > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 >=20 > Hi, >=20 > draft-rosenberg-sipcore-target-uri-delivery-00 also talks=20 > about aliases (the text origins from the ua-loose-route draft). >=20 > In chapter 4.1 the 3GPP definition is used. >=20 > Chapter 4.6 (Toll free numbers) talks about "aliases in the=20 > PSTN network", but there is no real definition of what it=20 > really means. >=20 > So, why can't we use the 3GPP definition for "alias", and=20 > when we talk about something else we could use "synonym"?=20 > Francois has already used that term. >=20 > Using that terminology, in the freephone case the 1-800=20 > number would be replaced by a synonym - not an alias. >=20 > Regards, >=20 > Christer >=20 > =20 >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Tuesday, June 16, 2009 10:03 PM > To: DRAGE, Keith (Keith); Francois Audet; Christer Holmberg;=20 > Hans Erik van Elburg; Shida Schubert > Cc: sipcore@ietf.org > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Keith,=20 >=20 > The term "alias" is not used in RFC 3325. It is used once in=20 > RFC 3324 and I can't see that the proposed definition is=20 > confusing or conflicting as it is used in a fairly general=20 > sense. The term alias is used once in > GRUU: > "In cases where the UA uses a tel URI (as > defiend in [11]) to populate the From header field, the UA=20 > typically > has a SIP AOR that is treated as an alias for the tel URI." > And, the reference [11] does not use the term alias.=20 >=20 > Identity (RFC 4474) does use the term alias (once): > "It must be possible for a user to have multiple AoRs (i.e., > accounts or aliases) that it is authorized to use within a > domain..." >=20 > The most prolific user of the term alias is connection-reuse,=20 > where the term is defined, but that context is entirely=20 > different than what we are talking about here, so I don't see=20 > a problem.=20 >=20 > And, I don't see any more suspects of concern when I google: > draft-ietf-sip alias I found one enum document that talks=20 > about aliasing with DNS. Digging down to the 3rd page of=20 > hits, Hannes does use it in one of his docs about SPIT, but=20 > again the usage is consistent with the usage in Identity. =20 > And, if you dig down to the fourth page, you can find an=20 > interesting patent that uses the term. One thing I have found=20 > with google is that you do get different results with=20 > different browsers > - I used IE. >=20 > So, I don't see the concern, since the most explicit usage in=20 > Identity is exactly what I thought we were talking about. =20 > Once we finally agree these terms, we are proposing to write=20 > an update to section 16.5 in RFC > 3261 since the plan is to define precise terms for the=20 > mechanisms by which the targets are determined.=20 >=20 > Regards, > Mary >=20 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com] > Sent: Tuesday, June 16, 2009 1:33 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055);=20 > Christer Holmberg; Hans Erik van Elburg; Shida Schubert > Cc: sipcore@ietf.org > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Can we also not have a history-info specific meaning for the=20 > word "alias". >=20 > It gets used in RFC 3325 without formal definition (if I recall > correctly) and in a number of other documents as well. >=20 > By giving it a more specific meaning here, you may end up=20 > changing the meaning of other RFCs. >=20 > regards >=20 > Keith=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > > Sent: Tuesday, June 16, 2009 6:41 PM > > To: Francois Audet; Christer Holmberg; Hans Erik van Elburg; Shida=20 > > Schubert > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and=20 > target-uri > >=20 > > Now, I'm confused as I thought the alias must be an AOR. I'm in the > > midst of a response to another email on this topic. =20 > >=20 > > -----Original Message----- > > From: Audet, Francois (SC100:3055) > > Sent: Tuesday, June 16, 2009 12:32 PM > > To: Christer Holmberg; Hans Erik van Elburg; Barnes, Mary=20 > > (RICH2:AR00); Shida Schubert > > Cc: sipcore@ietf.org > > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri > >=20 > > Yeah, I would fix that. > >=20 > > So.... > >=20 > > So, it looks like we are in agreement. I think I should=20 > up-issue the=20 > > document. > >=20 > > Agreed? > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Tuesday, June 16, 2009 10:30 > > > To: Audet, Francois (SC100:3055); Hans Erik van Elburg; > > Barnes, Mary > > > (RICH2:AR00); Shida Schubert > > > Cc: sipcore@ietf.org > > > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri > > >=20 > > >=20 > > > Hi, > > >=20 > > > >>But, I think there is a small missunderstading for the=20 > AOR-to-AOR > > > cases. > > > >>=20 > > > >>We don't think you need to know whether the new AOR is an > > alias or > > > >>not. You need to know whether the new AOR belongs to the > > > same user or > > > >>not. > > > > > > > >To me, that is the definition of an alias. > > >=20 > > > Fine, but that is not the current definition in 4244bis,=20 > which says=20 > > > that an alias is an implictity/explicitly registered AOR... > > With your > > > new definition an alias may be registered, or it may not.=20 > > It may be an > >=20 > > > AOR, or it may not. > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 >=20 From dean.willis@softarmor.com Tue Jun 16 13:12:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 716BE3A6C31 for ; Tue, 16 Jun 2009 13:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Svoe2fayYKaF for ; Tue, 16 Jun 2009 13:12:56 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8521F3A6BF0 for ; Tue, 16 Jun 2009 13:12:56 -0700 (PDT) Received: from [192.168.2.2] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n5GK488Y002299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Jun 2009 15:04:10 -0500 Message-ID: <4A37FAB3.2010600@softarmor.com> Date: Tue, 16 Jun 2009 15:04:03 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Paul Kyzivat References: <4A374056.6050001@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1E83E210@zrc2hxm0.corp.nortel.com> <4A37CD86.7080505@softarmor.com> <4A37D3C7.4050705@cisco.com> In-Reply-To: <4A37D3C7.4050705@cisco.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Another approach to preservation of targeting information on a proxy-rewrite of request URI (Request URI Replacement) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 20:12:57 -0000 Paul Kyzivat wrote: > While I like the approach, I think you are over-promising. > It still *does* require standardization: > - the rur parameter would need to be standardized > - that would include when it should be used, and what it > means if its found in a request you receive. As I said, that's arguable; there are presentable reasons for and against. > And then I suppose people would want different parameters to express > nuances about why the rur url is there. Locally-relevant nuances, I believe, are only locally relevant. I don't see a strong argument for standardized nuance. > > And it would run up against implementations that can't handle long > R-URIs. (I don't have much sympathy for them, but they continue to exist.) One could trivially express it as a header field that is not formatted as part of the r-URI. > Aside from syntax, this is basically just a subset of H-I. But it can > only encode one path through the tree - 1, 1.1, 1.1.1, ... (Or course > that is usually the path you care about.) Further, that's the only subset required to convey any request-URI parameters that are relevant to the request as received by the UAS. It allows for UAC-initiated parameters, as well as the addition or alteration of parameters by middleboxes. However, it does lack message integrity, so middleboxes could muddle the parameters. Note that this is required for a certain range of applications (e2m, anonymizers, etc.), so it isn't necessarily a bad thing. In other words, it completely satisfies the "What are the request-URI parameters" question that was our original requirement for the work. While I concede that H-I is useful for debugging, it is massive overkill for parameter passing. Think of it as grilling a chicken using a plasma torch. -- Dean From christer.holmberg@ericsson.com Tue Jun 16 13:13:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0ECE3A6B2F for ; Tue, 16 Jun 2009 13:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.742 X-Spam-Level: X-Spam-Status: No, score=-5.742 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM1-d2L0Fr36 for ; Tue, 16 Jun 2009 13:13:25 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 481E03A6BA4 for ; Tue, 16 Jun 2009 13:13:24 -0700 (PDT) X-AuditID: c1b4fb3c-b7b0bae00000673a-a5-4a37fcb4cac3 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 95.B9.26426.4BCF73A4; Tue, 16 Jun 2009 22:12:36 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 22:12:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 22:12:35 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88E547@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAFn+ocAAVBjIQAABMeEAAACJowAAAUkGwAAHQjbAAAGGn0AACfPhgAAB/SzA= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com><1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>! ! ! ! ! ! ! <4A36AC 9C. 3060509@ gmail.com><1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E3A8@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E547@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Francois Audet" , "Mary Barnes" , "DRAGE, Keith (Keith)" , "Hans Erik van Elburg" , "Shida Schubert" X-OriginalArrivalTime: 16 Jun 2009 20:12:36.0391 (UTC) FILETIME=[CA69FB70:01C9EEBE] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 20:13:25 -0000 =20 >We can use synonyms if alias is too confusing.=20 We can use both, when appropriate :) >Or like Mary says, we can just define alias for the purpose of this document. I don't think we should do that. The 3GPP definition of "alias" is useful for the "ic" tag, I believe. Regards, Christer > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Tuesday, June 16, 2009 12:03 > To: DRAGE, Keith (Keith); Audet, Francois (SC100:3055); Christer=20 > Holmberg; Hans Erik van Elburg; Shida Schubert > Cc: sipcore@ietf.org > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Keith, >=20 > The term "alias" is not used in RFC 3325. It is used once in RFC 3324=20 > and I can't see that the proposed definition is confusing or=20 > conflicting as it is used in a fairly general sense. The term alias is > used once in GRUU: > "In cases where the UA uses a tel URI (as > defiend in [11]) to populate the From header field, the UA=20 > typically > has a SIP AOR that is treated as an alias for the tel URI." > And, the reference [11] does not use the term alias.=20 >=20 > Identity (RFC 4474) does use the term alias (once): > "It must be possible for a user to have multiple AoRs (i.e., > accounts or aliases) that it is authorized to use within a > domain..." >=20 > The most prolific user of the term alias is connection-reuse, where=20 > the term is defined, but that context is entirely different than what=20 > we are talking about here, so I don't see a problem. >=20 > And, I don't see any more suspects of concern when I google:=20 > draft-ietf-sip alias I found one enum document that talks about=20 > aliasing with DNS. Digging down to the 3rd page of hits, Hannes does=20 > use it in one of his docs about SPIT, but again the usage is=20 > consistent with the usage in Identity. > And, if you dig down to the fourth page, you can find an interesting=20 > patent that uses the term. One thing I have found with google is that=20 > you do get different results with different browsers - I used IE. >=20 > So, I don't see the concern, since the most explicit usage in Identity > is exactly what I thought we were talking about. > Once we finally agree these terms, we are proposing to write an update > to section 16.5 in RFC 3261 since the plan is to define precise terms=20 > for the mechanisms by which the targets are determined. >=20 > Regards, > Mary From AUDET@nortel.com Tue Jun 16 13:16:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D6683A6BF0 for ; Tue, 16 Jun 2009 13:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enDDyi4beHdc for ; Tue, 16 Jun 2009 13:16:43 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E22793A6B11 for ; Tue, 16 Jun 2009 13:16:42 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5GKD2a06552; Tue, 16 Jun 2009 20:13:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 15:13:23 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E88E5D9@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri thread-index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAFn+ocAAVBjIQAABMeEAAACJowAAAUkGwAAHQjbAAAGGn0AACfPhgAAB/SzAAACy4cA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com><1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>! ! ! ! ! ! ! ! ! <4A36 AC9C. 306050 9@gmail.com><1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E3A8@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E547@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Christer Holmberg" , "Mary Barnes" , "DRAGE, Keith (Keith)" , "Hans Erik van Elburg" , "Shida Schubert" Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 20:16:48 -0000 Ok, I agree.=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Tuesday, June 16, 2009 13:13 > To: Audet, Francois (SC100:3055); Barnes, Mary (RICH2:AR00);=20 > DRAGE, Keith (Keith); Hans Erik van Elburg; Shida Schubert > Cc: sipcore@ietf.org > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 > =20 >=20 > >We can use synonyms if alias is too confusing.=20 >=20 > We can use both, when appropriate :) >=20 > >Or like Mary says, we can just define alias for the purpose of this > document. >=20 > I don't think we should do that. The 3GPP definition of=20 > "alias" is useful for the "ic" tag, I believe. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > > -----Original Message----- > > From: Barnes, Mary (RICH2:AR00) > > Sent: Tuesday, June 16, 2009 12:03 > > To: DRAGE, Keith (Keith); Audet, Francois (SC100:3055); Christer=20 > > Holmberg; Hans Erik van Elburg; Shida Schubert > > Cc: sipcore@ietf.org > > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri > >=20 > > Keith, > >=20 > > The term "alias" is not used in RFC 3325. It is used once=20 > in RFC 3324=20 > > and I can't see that the proposed definition is confusing or=20 > > conflicting as it is used in a fairly general sense. The=20 > term alias is >=20 > > used once in GRUU: > > "In cases where the UA uses a tel URI (as > > defiend in [11]) to populate the From header field, the UA=20 > > typically > > has a SIP AOR that is treated as an alias for the tel URI." > > And, the reference [11] does not use the term alias.=20 > >=20 > > Identity (RFC 4474) does use the term alias (once): > > "It must be possible for a user to have multiple AoRs (i.e., > > accounts or aliases) that it is authorized to use within a > > domain..." > >=20 > > The most prolific user of the term alias is connection-reuse, where=20 > > the term is defined, but that context is entirely different=20 > than what=20 > > we are talking about here, so I don't see a problem. > >=20 > > And, I don't see any more suspects of concern when I google:=20 > > draft-ietf-sip alias I found one enum document that talks about=20 > > aliasing with DNS. Digging down to the 3rd page of hits,=20 > Hannes does=20 > > use it in one of his docs about SPIT, but again the usage is=20 > > consistent with the usage in Identity. > > And, if you dig down to the fourth page, you can find an=20 > interesting=20 > > patent that uses the term. One thing I have found with=20 > google is that=20 > > you do get different results with different browsers - I used IE. > >=20 > > So, I don't see the concern, since the most explicit usage=20 > in Identity >=20 > > is exactly what I thought we were talking about. > > Once we finally agree these terms, we are proposing to=20 > write an update >=20 > > to section 16.5 in RFC 3261 since the plan is to define=20 > precise terms=20 > > for the mechanisms by which the targets are determined. > >=20 > > Regards, > > Mary >=20 From pkyzivat@cisco.com Tue Jun 16 13:23:43 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390E13A6B2F for ; Tue, 16 Jun 2009 13:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOOUcGETd2bR for ; Tue, 16 Jun 2009 13:23:42 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E5FC23A6A03 for ; Tue, 16 Jun 2009 13:23:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,231,1243814400"; d="scan'208";a="47547455" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 Jun 2009 20:20:35 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n5GKKZpe009328; Tue, 16 Jun 2009 16:20:35 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5GKKZB2003929; Tue, 16 Jun 2009 20:20:35 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 16:20:35 -0400 Received: from [161.44.182.188] ([161.44.182.188]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 16:20:35 -0400 Message-ID: <4A37FE92.9080505@cisco.com> Date: Tue, 16 Jun 2009 16:20:34 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com>! ! ! ! ! ! ! <4A36AC 9C. 3060509@ gmail.com><1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E3A8@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E547@zrc2hxm0.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2009 20:20:35.0382 (UTC) FILETIME=[E7EA3560:01C9EEBF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2986; t=1245183635; x=1246047635; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20draft-barnes-sipcore-rfc424 4bis=20and=20target-uri |Sender:=20 |To:=20Christer=20Holmberg=20; bh=pY3IrTnMim9adDBL0uW1NUu2y4otonwy439z3V5GVWA=; b=T87/5tFTlengoftxaEdDrCFj0dQeb7WEdN3/CqL/9IlGdT4TwL6lzpf8tC r4XGFYBdwGL2Trx0vDIpM8DEmwcTbmvtBQF/yO/g9s6F+troyourIA+T1cDe Alva4f7kg5; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 20:23:43 -0000 A problem here is that "synonym" is the appropriate term for what 3gpp is calling "alias". If we we adopt the 3gpp usage of alias, then what to you want to use "synonym" for? Alias has the connotation that it is just a substitute for the "real" name. Thanks, Paul Christer Holmberg wrote: > > >> We can use synonyms if alias is too confusing. > > We can use both, when appropriate :) > >> Or like Mary says, we can just define alias for the purpose of this > document. > > I don't think we should do that. The 3GPP definition of "alias" is > useful for the "ic" tag, I believe. > > Regards, > > Christer > > > >> -----Original Message----- >> From: Barnes, Mary (RICH2:AR00) >> Sent: Tuesday, June 16, 2009 12:03 >> To: DRAGE, Keith (Keith); Audet, Francois (SC100:3055); Christer >> Holmberg; Hans Erik van Elburg; Shida Schubert >> Cc: sipcore@ietf.org >> Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >> >> Keith, >> >> The term "alias" is not used in RFC 3325. It is used once in RFC 3324 >> and I can't see that the proposed definition is confusing or >> conflicting as it is used in a fairly general sense. The term alias is > >> used once in GRUU: >> "In cases where the UA uses a tel URI (as >> defiend in [11]) to populate the From header field, the UA >> typically >> has a SIP AOR that is treated as an alias for the tel URI." >> And, the reference [11] does not use the term alias. >> >> Identity (RFC 4474) does use the term alias (once): >> "It must be possible for a user to have multiple AoRs (i.e., >> accounts or aliases) that it is authorized to use within a >> domain..." >> >> The most prolific user of the term alias is connection-reuse, where >> the term is defined, but that context is entirely different than what >> we are talking about here, so I don't see a problem. >> >> And, I don't see any more suspects of concern when I google: >> draft-ietf-sip alias I found one enum document that talks about >> aliasing with DNS. Digging down to the 3rd page of hits, Hannes does >> use it in one of his docs about SPIT, but again the usage is >> consistent with the usage in Identity. >> And, if you dig down to the fourth page, you can find an interesting >> patent that uses the term. One thing I have found with google is that >> you do get different results with different browsers - I used IE. >> >> So, I don't see the concern, since the most explicit usage in Identity > >> is exactly what I thought we were talking about. >> Once we finally agree these terms, we are proposing to write an update > >> to section 16.5 in RFC 3261 since the plan is to define precise terms >> for the mechanisms by which the targets are determined. >> >> Regards, >> Mary > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Tue Jun 16 13:31:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D10C3A6B11 for ; Tue, 16 Jun 2009 13:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.757 X-Spam-Level: X-Spam-Status: No, score=-5.757 tagged_above=-999 required=5 tests=[AWL=0.492, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8o6eAt8L+xu for ; Tue, 16 Jun 2009 13:31:07 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 9C83B3A6A03 for ; Tue, 16 Jun 2009 13:31:06 -0700 (PDT) X-AuditID: c1b4fb3c-b7b0bae00000673a-3f-4a3800b39f95 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 7A.0A.26426.3B0083A4; Tue, 16 Jun 2009 22:29:40 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 22:29:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 22:29:39 +0200 Message-ID: In-Reply-To: <4A37FAB3.2010600@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Another approach to preservation of targeting information on a proxy-rewrite of request URI (Request URI Replacement) Thread-Index: AcnuvuALoY+G+FsMT5eqaHCWWpxUEAAAPttw References: <4A374056.6050001@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1E83E210@zrc2hxm0.corp.nortel.com><4A37CD86.7080505@softarmor.com> <4A37D3C7.4050705@cisco.com> <4A37FAB3.2010600@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" , "Paul Kyzivat" X-OriginalArrivalTime: 16 Jun 2009 20:29:39.0725 (UTC) FILETIME=[2C5E5BD0:01C9EEC1] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] Another approach to preservation of targeting information on a proxy-rewrite of request URI (Request URI Replacement) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 20:31:08 -0000 Dean, Isn't your idea more or less what the Target header proposal was all about?=20 Again, we had a long discussion on Target header vs ua-loose-route, and at some point the people behind the drafts agreed on a HI based approach. That approach was presented to the WG, which agreed to work on that.=20 So, until the WG decides to re-evaluate that decission (you are free to propose that), I think we should stick to it. Regards, Christer -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis Sent: Tuesday, June 16, 2009 11:04 PM To: Paul Kyzivat Cc: sipcore@ietf.org Subject: Re: [sipcore] Another approach to preservation of targeting information on a proxy-rewrite of request URI (Request URI Replacement) Paul Kyzivat wrote: > While I like the approach, I think you are over-promising. > It still *does* require standardization: > - the rur parameter would need to be standardized > - that would include when it should be used, and what it > means if its found in a request you receive. As I said, that's arguable; there are presentable reasons for and against. > And then I suppose people would want different parameters to express=20 > nuances about why the rur url is there. Locally-relevant nuances, I believe, are only locally relevant. I don't see a strong argument for standardized nuance. >=20 > And it would run up against implementations that can't handle long=20 > R-URIs. (I don't have much sympathy for them, but they continue to=20 > exist.) One could trivially express it as a header field that is not formatted as part of the r-URI. > Aside from syntax, this is basically just a subset of H-I. But it can=20 > only encode one path through the tree - 1, 1.1, 1.1.1, ... (Or course=20 > that is usually the path you care about.) Further, that's the only subset required to convey any request-URI parameters that are relevant to the request as received by the UAS. It allows for UAC-initiated parameters, as well as the addition or alteration of parameters by middleboxes. However, it does lack message integrity, so middleboxes could muddle the parameters. Note that this is required for a certain range of applications (e2m, anonymizers, etc.), so it isn't necessarily a bad thing. In other words, it completely satisfies the "What are the request-URI parameters" question that was our original requirement for the work. While I concede that H-I is useful for debugging, it is massive overkill for parameter passing. Think of it as grilling a chicken using a plasma torch. -- Dean _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From AUDET@nortel.com Tue Jun 16 13:31:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 846F23A6B47 for ; Tue, 16 Jun 2009 13:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.37 X-Spam-Level: X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHuDHT+yO4iK for ; Tue, 16 Jun 2009 13:31:27 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 6A6AF3A6A03 for ; Tue, 16 Jun 2009 13:31:27 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5GJuCc27042; Tue, 16 Jun 2009 19:56:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 14:55:27 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E88E547@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88E3A8@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis and target-uri thread-index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAFn+ocAAVBjIQAABMeEAAACJowAAAUkGwAAHQjbAAAGGn0AACfPhg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com><1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>! ! ! ! ! ! ! <4A36AC9C . 3060509@gm ail.com><1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E3A8@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Mary Barnes" , "DRAGE, Keith (Keith)" , "Christer Holmberg" , "Hans Erik van Elburg" , "Shida Schubert" Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 20:31:28 -0000 We can use synonyms if alias is too confusing.=20 Or like Mary says, we can just define alias for the purpose of this document. > -----Original Message----- > From: Barnes, Mary (RICH2:AR00)=20 > Sent: Tuesday, June 16, 2009 12:03 > To: DRAGE, Keith (Keith); Audet, Francois (SC100:3055);=20 > Christer Holmberg; Hans Erik van Elburg; Shida Schubert > Cc: sipcore@ietf.org > Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Keith,=20 >=20 > The term "alias" is not used in RFC 3325. It is used once in=20 > RFC 3324 and I can't see that the proposed definition is=20 > confusing or conflicting as it is used in a fairly general=20 > sense. The term alias is used once in GRUU: > "In cases where the UA uses a tel URI (as > defiend in [11]) to populate the From header field, the UA=20 > typically > has a SIP AOR that is treated as an alias for the tel URI." > And, the reference [11] does not use the term alias.=20 >=20 > Identity (RFC 4474) does use the term alias (once): > "It must be possible for a user to have multiple AoRs (i.e., > accounts or aliases) that it is authorized to use within a > domain..." >=20 > The most prolific user of the term alias is connection-reuse,=20 > where the term is defined, but that context is entirely=20 > different than what we are talking about here, so I don't see=20 > a problem.=20 >=20 > And, I don't see any more suspects of concern when I google:=20 > draft-ietf-sip alias I found one enum document that talks=20 > about aliasing with DNS. Digging down to the 3rd page of=20 > hits, Hannes does use it in one of his docs about SPIT, but=20 > again the usage is consistent with the usage in Identity. =20 > And, if you dig down to the fourth page, you can find an=20 > interesting patent that uses the term. One thing I have found=20 > with google is that you do get different results with=20 > different browsers - I used IE. >=20 > So, I don't see the concern, since the most explicit usage in=20 > Identity is exactly what I thought we were talking about. =20 > Once we finally agree these terms, we are proposing to write=20 > an update to section 16.5 in RFC 3261 since the plan is to=20 > define precise terms for the mechanisms by which the targets=20 > are determined.=20 >=20 > Regards, > Mary From christer.holmberg@ericsson.com Tue Jun 16 13:33:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13B163A6A49 for ; Tue, 16 Jun 2009 13:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.771 X-Spam-Level: X-Spam-Status: No, score=-5.771 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qX9YDJFScaex for ; Tue, 16 Jun 2009 13:33:26 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id AC75B3A6C01 for ; Tue, 16 Jun 2009 13:33:25 -0700 (PDT) X-AuditID: c1b4fb3c-b7b0bae00000673a-2e-4a38017c7200 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id B0.2A.26426.C71083A4; Tue, 16 Jun 2009 22:33:00 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 22:33:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 22:32:59 +0200 Message-ID: In-Reply-To: <4A37FE92.9080505@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: Acnuv+oRRWJo8o30Rk2RCRJvNKDhKwAAVFXg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com>! ! ! ! ! ! ! <4A36AC 9C. 3060509@ gmail.com><1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E3A8@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E547@zrc2hxm0.corp.nortel.com> <4A37FE92.9080505@cisc o.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 16 Jun 2009 20:33:00.0414 (UTC) FILETIME=[A3FD11E0:01C9EEC1] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 20:33:27 -0000 >A problem here is that "synonym" is the appropriate term for what 3gpp is calling "alias". If we we adopt the 3gpp usage of alias, then what to you want to use "synonym" for? We would use "synonym" when an AOR is replaced with an AOR pointing to the same user, but the AOR is NOT an alias (per 3GPP definition). >Alias has the connotation that it is just a substitute for the "real" name. Alias is whatver we define it to be - and that is why I think it has to be very clear what we mean. Regards, Christer Christer Holmberg wrote: > =20 >=20 >> We can use synonyms if alias is too confusing.=20 >=20 > We can use both, when appropriate :) >=20 >> Or like Mary says, we can just define alias for the purpose of this > document. >=20 > I don't think we should do that. The 3GPP definition of "alias" is=20 > useful for the "ic" tag, I believe. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >> -----Original Message----- >> From: Barnes, Mary (RICH2:AR00) >> Sent: Tuesday, June 16, 2009 12:03 >> To: DRAGE, Keith (Keith); Audet, Francois (SC100:3055); Christer=20 >> Holmberg; Hans Erik van Elburg; Shida Schubert >> Cc: sipcore@ietf.org >> Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >> >> Keith, >> >> The term "alias" is not used in RFC 3325. It is used once in RFC 3324 >> and I can't see that the proposed definition is confusing or=20 >> conflicting as it is used in a fairly general sense. The term alias=20 >> is >=20 >> used once in GRUU: >> "In cases where the UA uses a tel URI (as >> defiend in [11]) to populate the From header field, the UA=20 >> typically >> has a SIP AOR that is treated as an alias for the tel URI." >> And, the reference [11] does not use the term alias.=20 >> >> Identity (RFC 4474) does use the term alias (once): >> "It must be possible for a user to have multiple AoRs (i.e., >> accounts or aliases) that it is authorized to use within a >> domain..." >> >> The most prolific user of the term alias is connection-reuse, where=20 >> the term is defined, but that context is entirely different than what >> we are talking about here, so I don't see a problem. >> >> And, I don't see any more suspects of concern when I google:=20 >> draft-ietf-sip alias I found one enum document that talks about=20 >> aliasing with DNS. Digging down to the 3rd page of hits, Hannes does=20 >> use it in one of his docs about SPIT, but again the usage is=20 >> consistent with the usage in Identity. >> And, if you dig down to the fourth page, you can find an interesting=20 >> patent that uses the term. One thing I have found with google is that >> you do get different results with different browsers - I used IE. >> >> So, I don't see the concern, since the most explicit usage in=20 >> Identity >=20 >> is exactly what I thought we were talking about. >> Once we finally agree these terms, we are proposing to write an=20 >> update >=20 >> to section 16.5 in RFC 3261 since the plan is to define precise terms >> for the mechanisms by which the targets are determined. >> >> Regards, >> Mary > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From pkyzivat@cisco.com Tue Jun 16 13:54:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F15B3A6D8C for ; Tue, 16 Jun 2009 13:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.553 X-Spam-Level: X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cte7oZ6egwTk for ; Tue, 16 Jun 2009 13:54:11 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id EB4FD3A6C41 for ; Tue, 16 Jun 2009 13:54:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,231,1243814400"; d="scan'208";a="47600450" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Jun 2009 20:54:00 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5GKs0mb012123; Tue, 16 Jun 2009 16:54:00 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n5GKs0f9004978; Tue, 16 Jun 2009 20:54:00 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 16:53:59 -0400 Received: from [161.44.182.188] ([161.44.182.188]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 16:53:58 -0400 Message-ID: <4A380666.6050706@cisco.com> Date: Tue, 16 Jun 2009 16:53:58 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><4A36AC 9C. 3060509@ gmail.com><1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E3A8@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E547@zrc2hxm0.corp.nortel.com> <4A37FE92.9080505@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2009 20:53:59.0028 (UTC) FILETIME=[922E5340:01C9EEC4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3739; t=1245185640; x=1246049640; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20draft-barnes-sipcore-rfc424 4bis=20and=20target-uri |Sender:=20 |To:=20Christer=20Holmberg=20; bh=8zH6hn6fvvmrSnK7srMARjyu+WbG1mlM0nSylQc0QfE=; b=Jwdiz6vN+oULE2cQM9kHfBHUFKHRxheqgCxWr3sld0kwa6E4B2KuwG7/AF E2YiSbOZab4PwN/a0PQtv816XSDeDqw+P5JoxKNaUnD2fn2f55CgkWMId1rx APIgA0M53B; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 20:54:12 -0000 Christer Holmberg wrote: >> A problem here is that "synonym" is the appropriate term for what 3gpp > is calling "alias". If we we adopt the 3gpp usage of alias, then what to > you want to use "synonym" for? > > We would use "synonym" when an AOR is replaced with an AOR pointing to > the same user, but the AOR is NOT an alias (per 3GPP definition). > >> Alias has the connotation that it is just a substitute for the "real" > name. > > Alias is whatver we define it to be - and that is why I think it has to > be very clear what we mean. Yes, we can make the word mean whatever we want. But if we make our word differ greatly from standard English usage then we are going to confuse people greatly. If we use both "synonym" and "alias", and use them in such a way that the distinction between them is opposite of the difference between them in English usage, then we are really asking for trouble. Thanks, Paul > Christer Holmberg wrote: >> >> >>> We can use synonyms if alias is too confusing. >> We can use both, when appropriate :) >> >>> Or like Mary says, we can just define alias for the purpose of this >> document. >> >> I don't think we should do that. The 3GPP definition of "alias" is >> useful for the "ic" tag, I believe. >> >> Regards, >> >> Christer >> >> >> >>> -----Original Message----- >>> From: Barnes, Mary (RICH2:AR00) >>> Sent: Tuesday, June 16, 2009 12:03 >>> To: DRAGE, Keith (Keith); Audet, Francois (SC100:3055); Christer >>> Holmberg; Hans Erik van Elburg; Shida Schubert >>> Cc: sipcore@ietf.org >>> Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >>> >>> Keith, >>> >>> The term "alias" is not used in RFC 3325. It is used once in RFC 3324 > >>> and I can't see that the proposed definition is confusing or >>> conflicting as it is used in a fairly general sense. The term alias >>> is >>> used once in GRUU: >>> "In cases where the UA uses a tel URI (as >>> defiend in [11]) to populate the From header field, the UA >>> typically >>> has a SIP AOR that is treated as an alias for the tel URI." >>> And, the reference [11] does not use the term alias. >>> >>> Identity (RFC 4474) does use the term alias (once): >>> "It must be possible for a user to have multiple AoRs (i.e., >>> accounts or aliases) that it is authorized to use within a >>> domain..." >>> >>> The most prolific user of the term alias is connection-reuse, where >>> the term is defined, but that context is entirely different than what > >>> we are talking about here, so I don't see a problem. >>> >>> And, I don't see any more suspects of concern when I google: >>> draft-ietf-sip alias I found one enum document that talks about >>> aliasing with DNS. Digging down to the 3rd page of hits, Hannes does >>> use it in one of his docs about SPIT, but again the usage is >>> consistent with the usage in Identity. >>> And, if you dig down to the fourth page, you can find an interesting >>> patent that uses the term. One thing I have found with google is that > >>> you do get different results with different browsers - I used IE. >>> >>> So, I don't see the concern, since the most explicit usage in >>> Identity >>> is exactly what I thought we were talking about. >>> Once we finally agree these terms, we are proposing to write an >>> update >>> to section 16.5 in RFC 3261 since the plan is to define precise terms > >>> for the mechanisms by which the targets are determined. >>> >>> Regards, >>> Mary >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From ietf.hanserik@gmail.com Tue Jun 16 14:03:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEF8D3A6BF0 for ; Tue, 16 Jun 2009 14:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1z3eyaX9b-5 for ; Tue, 16 Jun 2009 14:03:54 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 59A213A6C41 for ; Tue, 16 Jun 2009 14:03:37 -0700 (PDT) Received: by ewy6 with SMTP id 6so6384016ewy.37 for ; Tue, 16 Jun 2009 14:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=epb5ozUOmmcOoWN2yNPmKbdVbT8Jr887jGErm007wy4=; b=kCnoueaKpwShdbH6g6a9wtkKyChO4WuoxSoCsIYMbKgxpf/vPHMbAdmtsTxeOwICUs BSc+yWrF2y+BNEQraaJQRvlsTMu3XUxJCh16Lsf1MzS7Ki84fnd+tby37ufVbrHe81iG xgyVrRAc9HEUhX8ihVdWRnChCRTjmYYHQ/JIU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=EbvhxHWT3UCqVZq7+U/4bAJWnHkZkrs5+Y3WeU4jDXroUqV+HlgdrJnFChiemS7/Qu tMr5h8GZ9KmjlSEwvJf3Kp4PfI9z/KpOH/+aZ4c5xt8YOw50ejNWMlChNxU/yBqLy9En awvvs5iotSiI9UvVaCJ5hvhIsy4zZ8Pzz5SgE= Received: by 10.210.144.8 with SMTP id r8mr1745716ebd.63.1245185855789; Tue, 16 Jun 2009 13:57:35 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 24sm156274eyx.53.2009.06.16.13.57.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Jun 2009 13:57:35 -0700 (PDT) Message-ID: <4A38073E.7010003@gmail.com> Date: Tue, 16 Jun 2009 22:57:34 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Paul Kyzivat References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E3A8@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E547@zrc2hxm0.corp.nortel.com> <4A37FE92.9080505@cisco.com> <4A380666.6050706@cisco.com> In-Reply-To: <4A380666.6050706@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 21:03:55 -0000 A solution would be to not use the term at all in the definitions, but just describe what we mean. /Hans Erik Paul Kyzivat wrote: > > > Christer Holmberg wrote: >>> A problem here is that "synonym" is the appropriate term for what 3gpp >> is calling "alias". If we we adopt the 3gpp usage of alias, then what to >> you want to use "synonym" for? >> >> We would use "synonym" when an AOR is replaced with an AOR pointing to >> the same user, but the AOR is NOT an alias (per 3GPP definition). >> >>> Alias has the connotation that it is just a substitute for the "real" >> name. >> >> Alias is whatver we define it to be - and that is why I think it has to >> be very clear what we mean. > > Yes, we can make the word mean whatever we want. > But if we make our word differ greatly from standard English usage > then we are going to confuse people greatly. > > If we use both "synonym" and "alias", and use them in such a way that > the distinction between them is opposite of the difference between > them in English usage, then we are really asking for trouble. > > Thanks, > Paul > >> Christer Holmberg wrote: >>> >>> >>>> We can use synonyms if alias is too confusing. >>> We can use both, when appropriate :) >>> >>>> Or like Mary says, we can just define alias for the purpose of this >>> document. >>> >>> I don't think we should do that. The 3GPP definition of "alias" is >>> useful for the "ic" tag, I believe. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>>> -----Original Message----- >>>> From: Barnes, Mary (RICH2:AR00) >>>> Sent: Tuesday, June 16, 2009 12:03 >>>> To: DRAGE, Keith (Keith); Audet, Francois (SC100:3055); Christer >>>> Holmberg; Hans Erik van Elburg; Shida Schubert >>>> Cc: sipcore@ietf.org >>>> Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >>>> >>>> Keith, >>>> >>>> The term "alias" is not used in RFC 3325. It is used once in RFC 3324 >> >>>> and I can't see that the proposed definition is confusing or >>>> conflicting as it is used in a fairly general sense. The term alias is >>>> used once in GRUU: >>>> "In cases where the UA uses a tel URI (as >>>> defiend in [11]) to populate the From header field, the UA >>>> typically >>>> has a SIP AOR that is treated as an alias for the tel URI." >>>> And, the reference [11] does not use the term alias. >>>> Identity (RFC 4474) does use the term alias (once): >>>> "It must be possible for a user to have multiple AoRs (i.e., >>>> accounts or aliases) that it is authorized to use within a >>>> domain..." >>>> >>>> The most prolific user of the term alias is connection-reuse, where >>>> the term is defined, but that context is entirely different than what >> >>>> we are talking about here, so I don't see a problem. >>>> >>>> And, I don't see any more suspects of concern when I google: >>>> draft-ietf-sip alias I found one enum document that talks about >>>> aliasing with DNS. Digging down to the 3rd page of hits, Hannes >>>> does use it in one of his docs about SPIT, but again the usage is >>>> consistent with the usage in Identity. >>>> And, if you dig down to the fourth page, you can find an >>>> interesting patent that uses the term. One thing I have found with >>>> google is that >> >>>> you do get different results with different browsers - I used IE. >>>> >>>> So, I don't see the concern, since the most explicit usage in Identity >>>> is exactly what I thought we were talking about. >>>> Once we finally agree these terms, we are proposing to write an update >>>> to section 16.5 in RFC 3261 since the plan is to define precise terms >> >>>> for the mechanisms by which the targets are determined. >>>> >>>> Regards, >>>> Mary >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> From christer.holmberg@ericsson.com Tue Jun 16 14:04:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 466703A6B78 for ; Tue, 16 Jun 2009 14:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.784 X-Spam-Level: X-Spam-Status: No, score=-5.784 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3nOEdT7MoRW for ; Tue, 16 Jun 2009 14:04:29 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D55383A697E for ; Tue, 16 Jun 2009 14:04:28 -0700 (PDT) X-AuditID: c1b4fb3c-b7b0bae00000673a-fe-4a3808b96b1a Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 76.FB.26426.9B8083A4; Tue, 16 Jun 2009 23:03:53 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 23:03:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 23:03:46 +0200 Message-ID: In-Reply-To: <4A380666.6050706@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: AcnuxJSx9GK0Qr2RRru+Z/hw0GiSXQAAPXQw References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><4A36AC 9C. 3060509@ gmail.com><1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E3A8@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E547@zrc2hxm0.corp.nortel.com> <4A37FE92.9080505@cisco.com> <4A380 666.6050 706@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 16 Jun 2009 21:03:46.0253 (UTC) FILETIME=[F031BFD0:01C9EEC5] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 21:04:30 -0000 Hi,=20 >>>A problem here is that "synonym" is the appropriate term for what 3gpp >>>is calling "alias". If we we adopt the 3gpp usage of alias, then what to you want to use "synonym" for? >>=20 >>We would use "synonym" when an AOR is replaced with an AOR pointing to >>the same user, but the AOR is NOT an alias (per 3GPP definition). >>=20 >>Alias has the connotation that it is just a substitute for the "real" name. >>=20 >>Alias is whatver we define it to be - and that is why I think it has=20 >>to be very clear what we mean. > >Yes, we can make the word mean whatever we want. >But if we make our word differ greatly from standard English usage then we are going to confuse people greatly. > >If we use both "synonym" and "alias", and use them in such a way that the distinction between them is opposite of the difference between them in English usage, then we are really asking for trouble. We will confuse people even more if we use different definitions in different SIP related specifications. And, if 3GPP at some point would adopt 4244bis it would cause a mess, since there would be conflicting definitions. Regards. Christer > Christer Holmberg wrote: >> =20 >> >>> We can use synonyms if alias is too confusing.=20 >> We can use both, when appropriate :) >> >>> Or like Mary says, we can just define alias for the purpose of this >> document. >> >> I don't think we should do that. The 3GPP definition of "alias" is=20 >> useful for the "ic" tag, I believe. >> >> Regards, >> >> Christer >> >> >> >>> -----Original Message----- >>> From: Barnes, Mary (RICH2:AR00) >>> Sent: Tuesday, June 16, 2009 12:03 >>> To: DRAGE, Keith (Keith); Audet, Francois (SC100:3055); Christer=20 >>> Holmberg; Hans Erik van Elburg; Shida Schubert >>> Cc: sipcore@ietf.org >>> Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >>> >>> Keith, >>> >>> The term "alias" is not used in RFC 3325. It is used once in RFC=20 >>> 3324 >=20 >>> and I can't see that the proposed definition is confusing or=20 >>> conflicting as it is used in a fairly general sense. The term alias=20 >>> is used once in GRUU: >>> "In cases where the UA uses a tel URI (as >>> defiend in [11]) to populate the From header field, the UA=20 >>> typically >>> has a SIP AOR that is treated as an alias for the tel URI." >>> And, the reference [11] does not use the term alias.=20 >>> >>> Identity (RFC 4474) does use the term alias (once): >>> "It must be possible for a user to have multiple AoRs (i.e., >>> accounts or aliases) that it is authorized to use within a >>> domain..." >>> >>> The most prolific user of the term alias is connection-reuse, where=20 >>> the term is defined, but that context is entirely different than=20 >>> what >=20 >>> we are talking about here, so I don't see a problem. >>> >>> And, I don't see any more suspects of concern when I google:=20 >>> draft-ietf-sip alias I found one enum document that talks about=20 >>> aliasing with DNS. Digging down to the 3rd page of hits, Hannes does >>> use it in one of his docs about SPIT, but again the usage is=20 >>> consistent with the usage in Identity. >>> And, if you dig down to the fourth page, you can find an interesting >>> patent that uses the term. One thing I have found with google is=20 >>> that >=20 >>> you do get different results with different browsers - I used IE. >>> >>> So, I don't see the concern, since the most explicit usage in=20 >>> Identity is exactly what I thought we were talking about. >>> Once we finally agree these terms, we are proposing to write an=20 >>> update to section 16.5 in RFC 3261 since the plan is to define=20 >>> precise terms >=20 >>> for the mechanisms by which the targets are determined. >>> >>> Regards, >>> Mary >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >=20 From christer.holmberg@ericsson.com Tue Jun 16 14:09:05 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5868C3A6DBD for ; Tue, 16 Jun 2009 14:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.797 X-Spam-Level: X-Spam-Status: No, score=-5.797 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8UcT5UANYux for ; Tue, 16 Jun 2009 14:09:04 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8DE5D3A6D6C for ; Tue, 16 Jun 2009 14:08:35 -0700 (PDT) X-AuditID: c1b4fb3e-b7b1dae000006c99-42-4a3809a9189e Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id D8.E7.27801.9A9083A4; Tue, 16 Jun 2009 23:07:53 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jun 2009 23:07:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 23:07:51 +0200 Message-ID: In-Reply-To: <4A38073E.7010003@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: AcnuxRO55RMbj4ZpScmloXoJXeDZbAAAQRlA References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E3A8@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E547@zrc2hxm0.corp.nortel.com> <4A37FE92.9080505@cisco.com> <4A380666.6050706@cisco.com> <4A38073 E.701000 3@gmail.com> From: "Christer Holmberg" To: "Hans Erik van Elburg" , "Paul Kyzivat" X-OriginalArrivalTime: 16 Jun 2009 21:07:51.0865 (UTC) FILETIME=[82972A90:01C9EEC6] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 21:09:05 -0000 Yes. And, the small changes modifications that I propsed to a couple of the tags earlier (and which Francois seemede to be fine with) did not contain the work alias or synonym. The "ic" definition doesn't mention "alias", and my proposed change to "rt" doesn't mention "alias". Regards, Christer -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Tuesday, June 16, 2009 11:58 PM To: Paul Kyzivat Cc: Christer Holmberg; Francois Audet; Mary Barnes; DRAGE, Keith (Keith); Shida Schubert; sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri A solution would be to not use the term at all in the definitions, but just describe what we mean. /Hans Erik Paul Kyzivat wrote: > > > Christer Holmberg wrote: >>> A problem here is that "synonym" is the appropriate term for what=20 >>> 3gpp >> is calling "alias". If we we adopt the 3gpp usage of alias, then what >> to you want to use "synonym" for? >> >> We would use "synonym" when an AOR is replaced with an AOR pointing=20 >> to the same user, but the AOR is NOT an alias (per 3GPP definition). >> >>> Alias has the connotation that it is just a substitute for the "real" >> name. >> >> Alias is whatver we define it to be - and that is why I think it has=20 >> to be very clear what we mean. > > Yes, we can make the word mean whatever we want. > But if we make our word differ greatly from standard English usage=20 > then we are going to confuse people greatly. > > If we use both "synonym" and "alias", and use them in such a way that=20 > the distinction between them is opposite of the difference between=20 > them in English usage, then we are really asking for trouble. > > Thanks, > Paul > >> Christer Holmberg wrote: >>> =20 >>> >>>> We can use synonyms if alias is too confusing.=20 >>> We can use both, when appropriate :) >>> >>>> Or like Mary says, we can just define alias for the purpose of this >>> document. >>> >>> I don't think we should do that. The 3GPP definition of "alias" is=20 >>> useful for the "ic" tag, I believe. >>> >>> Regards, >>> >>> Christer >>> >>> >>> >>>> -----Original Message----- >>>> From: Barnes, Mary (RICH2:AR00) >>>> Sent: Tuesday, June 16, 2009 12:03 >>>> To: DRAGE, Keith (Keith); Audet, Francois (SC100:3055); Christer=20 >>>> Holmberg; Hans Erik van Elburg; Shida Schubert >>>> Cc: sipcore@ietf.org >>>> Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri >>>> >>>> Keith, >>>> >>>> The term "alias" is not used in RFC 3325. It is used once in RFC=20 >>>> 3324 >> >>>> and I can't see that the proposed definition is confusing or=20 >>>> conflicting as it is used in a fairly general sense. The term alias >>>> is used once in GRUU: >>>> "In cases where the UA uses a tel URI (as >>>> defiend in [11]) to populate the From header field, the UA=20 >>>> typically >>>> has a SIP AOR that is treated as an alias for the tel URI." >>>> And, the reference [11] does not use the term alias. >>>> Identity (RFC 4474) does use the term alias (once): >>>> "It must be possible for a user to have multiple AoRs (i.e., >>>> accounts or aliases) that it is authorized to use within a >>>> domain..." >>>> >>>> The most prolific user of the term alias is connection-reuse, where >>>> the term is defined, but that context is entirely different than=20 >>>> what >> >>>> we are talking about here, so I don't see a problem. >>>> >>>> And, I don't see any more suspects of concern when I google:=20 >>>> draft-ietf-sip alias I found one enum document that talks about=20 >>>> aliasing with DNS. Digging down to the 3rd page of hits, Hannes=20 >>>> does use it in one of his docs about SPIT, but again the usage is=20 >>>> consistent with the usage in Identity. >>>> And, if you dig down to the fourth page, you can find an=20 >>>> interesting patent that uses the term. One thing I have found with=20 >>>> google is that >> >>>> you do get different results with different browsers - I used IE. >>>> >>>> So, I don't see the concern, since the most explicit usage in=20 >>>> Identity is exactly what I thought we were talking about. >>>> Once we finally agree these terms, we are proposing to write an=20 >>>> update to section 16.5 in RFC 3261 since the plan is to define=20 >>>> precise terms >> >>>> for the mechanisms by which the targets are determined. >>>> >>>> Regards, >>>> Mary >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> From mary.barnes@nortel.com Tue Jun 16 15:51:00 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F311028C1DB for ; Tue, 16 Jun 2009 15:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.35 X-Spam-Level: X-Spam-Status: No, score=-6.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFBvOfyNU+xd for ; Tue, 16 Jun 2009 15:50:59 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id EDC4D3A693E for ; Tue, 16 Jun 2009 15:50:58 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5GMp3c11369; Tue, 16 Jun 2009 22:51:03 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 17:53:22 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E88E9BE@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri thread-index: Acnuqgr8BIccQ0FqSea0C7Cz99PV5AAAHzKwAAqfe5A= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! <4 A36AC9C.3060 509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> <4A37D9E1.1040001@cisco.com> From: "Mary Barnes" To: "Christer Holmberg" , "Paul Kyzivat" , "Francois Audet" Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 22:51:00 -0000 So, if we keep the current narrow scope for alias in 4244bis, then I think we need something else for things that are configured, but not necessarily AORs or aliases. In which case, can we not use the "mapped" that is defined in 4244bis? =20 Mary.=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Tuesday, June 16, 2009 12:52 PM To: Paul Kyzivat; Audet, Francois (SC100:3055) Cc: Hans Erik van Elburg; Barnes, Mary (RICH2:AR00); Shida Schubert; sipcore@ietf.org Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >> But, I think there is a small missunderstading for the AOR-to-AOR=20 >> cases. >> >> We don't think you need to know whether the new AOR is an alias or=20 >> not. You need to know whether the new AOR belongs to the same user or >> not. >=20 > To me, that is the definition of an alias. > >I have to differ here. > >I may own a bunch of AORs. Some of them may be aliases, others may not be. For instance: > >- sip:pkyzivat@example.net and paul.kyzivat@example.net > might be aliases. > >- sip:pkyzivat.ietf@example.net and sip:pkyzivat.junk@example.net > may be designed to bucket specific kinds of traffic, and so > not be aliases. That is why I like the 3GPP definition of alias, which 4244bis currently also uses. But, again, based on that definition a freephone number does not have to be an alias: the 1-800 number is not necessarily registered for the called user. Regards, Christer From christer.holmberg@ericsson.com Tue Jun 16 21:53:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45A243A6996 for ; Tue, 16 Jun 2009 21:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.809 X-Spam-Level: X-Spam-Status: No, score=-5.809 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeVrbWODdEGi for ; Tue, 16 Jun 2009 21:53:45 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 49BBB3A683A for ; Tue, 16 Jun 2009 21:53:44 -0700 (PDT) X-AuditID: c1b4fb3e-b7b1dae000006c99-19-4a3876e10f62 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 17.88.27801.1E6783A4; Wed, 17 Jun 2009 06:53:54 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jun 2009 06:53:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 06:53:52 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88E9BE@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: Acnuqgr8BIccQ0FqSea0C7Cz99PV5AAAHzKwAAqfe5AADHFwYA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! <4 A36AC9C.3060 509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> <4A37D9E1.1040001@cisco.com> <1ECE0EB50388174790F9694F77522CCF1E88E9BE@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Mary Barnes" , "Paul Kyzivat" , "Francois Audet" X-OriginalArrivalTime: 17 Jun 2009 04:53:53.0686 (UTC) FILETIME=[9D227360:01C9EF07] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 04:53:49 -0000 Hi,=20 >So, if we keep the current narrow scope for alias in 4244bis, then I think we need something else for things that are=20 >configured, but not necessarily AORs or aliases. In which case, can we not use the "mapped" that is defined in 4244bis? =20 Again, then we are back at the situation where we are not able to distinguish between the case when the AOR does represent the same user, and when it doesn't. I think Francois's current proposal for mapped (mp), where the user IS changed, is good: "mp : The request-URI is changed to a new URI that represent another user." "rt" works fine for the case where the user isn't changed, if we do the small editorial changes I proposed to Francois earlier (and which he seemed to be ok with). And, as Hans Erik said, maybe we don't need to talk about aliases etc in the fist place, in which case we don't need to worry about what it means :) Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, June 16, 2009 12:52 PM > To: Paul Kyzivat; Audet, Francois (SC100:3055) > Cc: Hans Erik van Elburg; Barnes, Mary (RICH2:AR00); Shida=20 > Schubert; sipcore@ietf.org > Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >=20 >=20 >=20 > >> But, I think there is a small missunderstading for the AOR-to-AOR=20 > >> cases. > >> > >> We don't think you need to know whether the new AOR is an alias or=20 > >> not. You need to know whether the new AOR belongs to the=20 > same user or >=20 > >> not. > >=20 > > To me, that is the definition of an alias. > > > >I have to differ here. > > > >I may own a bunch of AORs. Some of them may be aliases,=20 > others may not > be. For instance: > > > >- sip:pkyzivat@example.net and paul.kyzivat@example.net > > might be aliases. > > > >- sip:pkyzivat.ietf@example.net and sip:pkyzivat.junk@example.net > > may be designed to bucket specific kinds of traffic, and so > > not be aliases. >=20 > That is why I like the 3GPP definition of alias, which=20 > 4244bis currently > also uses. >=20 > But, again, based on that definition a freephone number does=20 > not have to > be an alias: the 1-800 number is not necessarily registered for the > called user. >=20 > Regards, >=20 > Christer >=20 From AUDET@nortel.com Tue Jun 16 22:02:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F3273A6996 for ; Tue, 16 Jun 2009 22:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.335 X-Spam-Level: X-Spam-Status: No, score=-5.335 tagged_above=-999 required=5 tests=[AWL=-0.803, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNySZrBYMwn9 for ; Tue, 16 Jun 2009 22:02:41 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 310413A68ED for ; Tue, 16 Jun 2009 22:02:41 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5H51MH02424; Wed, 17 Jun 2009 05:01:23 GMT Received: from 47.103.119.44 ([47.103.119.44]) by zrc2hxm0.corp.nortel.com ([47.103.119.44]) with Microsoft Exchange Server HTTP-DAV ; Wed, 17 Jun 2009 05:01:47 +0000 References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> ! ! ! ! <4 A36AC9C.3060 509@gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> <4A37D9E1.1040001@cisco.com> <1ECE0EB50388174790F9694F77522CCF1E88E9BE@zrc2hxm0.corp.nortel.com> Message-ID: <74AD34C2-513D-4EC0-B8EF-A9E87B3C6DFE@nortel.com> From: "Francois Audet" To: "Christer Holmberg" In-Reply-To: Content-Type: text/plain; format=flowed; delsp=yes; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri thread-index: AcnvCLew4lTFX6V5QqWCSl0+p8Rxjw== MIME-Version: 1.0 (iPod Mail 5H11a) Date: Tue, 16 Jun 2009 22:01:49 -0700 Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 05:02:42 -0000 lemme look into it tomorrow. Kinda getting late. On Jun 16, 2009, at 21:53, "Christer Holmberg" wrote: > > Hi, > >> So, if we keep the current narrow scope for alias in 4244bis, then I > think we need something else for things that are >> configured, but not necessarily AORs or aliases. In which case, can >> we > not use the "mapped" that is defined in 4244bis? > > Again, then we are back at the situation where we are not able to > distinguish between the case when the AOR does represent the same > user, > and when it doesn't. > > I think Francois's current proposal for mapped (mp), where the user IS > changed, is good: > > "mp : The request-URI is changed to a new URI that represent > another user." > > "rt" works fine for the case where the user isn't changed, if we do > the > small editorial changes I proposed to Francois earlier (and which he > seemed to be ok with). > > And, as Hans Erik said, maybe we don't need to talk about aliases > etc in > the fist place, in which case we don't need to worry about what it > means > :) > > Regards, > > Christer > > > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Tuesday, June 16, 2009 12:52 PM >> To: Paul Kyzivat; Audet, Francois (SC100:3055) >> Cc: Hans Erik van Elburg; Barnes, Mary (RICH2:AR00); Shida >> Schubert; sipcore@ietf.org >> Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >> >> >> >>>> But, I think there is a small missunderstading for the AOR-to-AOR >>>> cases. >>>> >>>> We don't think you need to know whether the new AOR is an alias or >>>> not. You need to know whether the new AOR belongs to the >> same user or >> >>>> not. >>> >>> To me, that is the definition of an alias. >>> >>> I have to differ here. >>> >>> I may own a bunch of AORs. Some of them may be aliases, >> others may not >> be. For instance: >>> >>> - sip:pkyzivat@example.net and paul.kyzivat@example.net >>> might be aliases. >>> >>> - sip:pkyzivat.ietf@example.net and sip:pkyzivat.junk@example.net >>> may be designed to bucket specific kinds of traffic, and so >>> not be aliases. >> >> That is why I like the 3GPP definition of alias, which >> 4244bis currently >> also uses. >> >> But, again, based on that definition a freephone number does >> not have to >> be an alias: the 1-800 number is not necessarily registered for the >> called user. >> >> Regards, >> >> Christer >> From R.Jesske@telekom.de Tue Jun 16 23:00:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 850173A6C16 for ; Tue, 16 Jun 2009 23:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfqXc7XpepMM for ; Tue, 16 Jun 2009 23:00:39 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id B05843A680D for ; Tue, 16 Jun 2009 23:00:38 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 17 Jun 2009 08:00:29 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2009 08:00:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 08:00:38 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD40482809F@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E88E0FE@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAEsEiwAAY2eFwABpznoA= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>!! ! ! <4 A36A C9C.306 0509@ gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404827ACF@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1E88E0FE@zrc2hxm0.corp.nortel.com> From: To: , , , , X-OriginalArrivalTime: 17 Jun 2009 06:00:29.0693 (UTC) FILETIME=[EAF0BAD0:01C9EF10] Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 06:00:40 -0000 I have slide concerns with that approach. Some network operators does = not like to present all the way of messages. Even if the entry is anonymous the amount of entries will show the = network structure which could also raise security concerns. BR, Roland=20 -----Urspr=FCngliche Nachricht----- Von: Francois Audet [mailto:audet@nortel.com]=20 Gesendet: Dienstag, 16. Juni 2009 19:22 An: Jesske, Roland; christer.holmberg@ericsson.com; = ietf.hanserik@gmail.com; Mary Barnes; shida@agnada.com Cc: sipcore@ietf.org Betreff: RE: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri In the new draft, the entries are always there and never removed. It = makes HI much more reliable. If entries need to be anonymous, they are anonymized but the entry is = still there.=20 > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 > Sent: Monday, June 15, 2009 22:38 > To: Audet, Francois (SC100:3055);=20 > christer.holmberg@ericsson.com; ietf.hanserik@gmail.com;=20 > Barnes, Mary (RICH2:AR00); shida@agnada.com > Cc: sipcore@ietf.org > Subject: AW: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Such values looks good and gives more guideline why the entry=20 > was included. > My question would be if there is a different network=20 > behaviour foreseen for the History mechanism. > Perhaps some of the networks needs the history only to=20 > indicate where the URI were mapped ("mp") and others would=20 > really track the whole history of each SIP proxy. > Or is it only seen either to support history full or not. >=20 > BR, >=20 > Roland =20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Francois Audet > Gesendet: Dienstag, 16. Juni 2009 03:44 > An: Christer Holmberg; Hans Erik van Elburg; Mary Barnes;=20 > Shida Schubert > Cc: sipcore@ietf.org > Betreff: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >=20 > All right guys, >=20 > I've been thinking about this. >=20 > It seems to me that what we want to capture is: > 1) If the target is an AOR, a contact, or a routing URI=20 > (maddr, noop intra-domain, or noop > forward to next domain, or strict routing). > 2) In the case that the target is an AOR, then if that AOR is=20 > known to be an alias for the previous > one, or if it is mapped to another AOR. >=20 > It seems to me that a Proxy should mark a Previous entry in=20 > H-I with aor if it determines that it owns this AOR. Just as=20 > Hans's current target-uri draft. >=20 > Now, for the mapped vs routed (versus reg-contact, etc.),=20 > instead of marking the Previous entry, we should mark the=20 > OUTGOING (i.e., New) entry instead. This would make the procedures of > 7.2.1 & 7.2.2 of target-URI draft clearer. >=20 > Specifically, the logic would be: >=20 > When proxy receives an incoming request with H-I, it adds an=20 > ;aor tag to that incoming entry if it determines that it is=20 > responsible for the AOR and.=20 >=20 > Also, if there was no Hi-entry at all (i.e., it came from a=20 > UAC), and the Proxy creates then two entries, the first one=20 > in this case would also have the ;aor tag associated to it. >=20 > For the Outgoing entry, I would see the following tags: >=20 > rc : The entry is an explicit registered contact=20 > (i.e., it was provided in a REGISTER message) >=20 > ic : The entry is an implicit registered contact=20 > (i.e., it's exactly as a registered contact, > but was not discovered using SIP Registration:=20 > it could have been manually configured > or done with a proprietary mechanism). >=20 > (TBD: we could debate if we need both rc and=20 > irc, but I think we do). >=20 > mp : The request-URI is changed to a new URI that=20 > represent another user. >=20 > rt : The entry is "routed", i.e., it is either a=20 > no-opt like a proxy forwarding within > a domain, predetermined by a maddr in the=20 > Request-URI, or when proxy is NOT responsible > for domain, or the address is an alias for the=20 > incoming URI. >=20 > So, to give an example.=20 >=20 > Say Alice calls Bob. Bob is forwarded to freephone. Freephone=20 > routes to Carol.=20 >=20 > The History-info at Carol would look like this: >=20 > Alice -> example.com > Nothing because UAC typically doesn't send H-I (otherwise, it=20 > would be as per Index 1 in next entry, but without the AOR. >=20 > example.com -> freephone@example.net > History-Info: ;index=3D1;aor > History-Info: ;index=3D1.1;mp >=20 > example.net -> carol@example.net > History-Info: ;index=3D1;aor =20 > History-Info: ;index=3D1.1;mp;aor =20 > <- aor is added > History-Info: ;index=3D1.1.1;rt;aor }=20 > Two entries are > History-Info: ;index=3D1.1.1.1;rc }=20 > added at same time >=20 > Also, I don't think we need to define an equivalent to the=20 > "reg-uri-alias" anymore. > If Freephone was configured to go to +14085551212 instead of=20 > the registered Contact (assuming +14085551212 was an Alias=20 > AOR for carol@example.net), the last H-I entries would look=20 > like this instead: >=20 > example.net -> carol@example.net > History-Info: ;index=3D1;aor =20 > History-Info:=20 > ;index=3D1.1;mp;aor <-=20 > aor is added > History-Info: ;index=3D1.1.1;rt;aor =20 > <- aor is added > History-Info: ;index=3D1.1.1.1;rt;aor =20 > } Two entries are > History-Info: ;index=3D1.1.1.1.1;rc =20 > } added at same time > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From R.Jesske@telekom.de Tue Jun 16 23:21:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83F0F3A6DDA for ; Tue, 16 Jun 2009 23:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_20=-0.74, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7+Y-79POua8 for ; Tue, 16 Jun 2009 23:21:56 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id DBA3C3A67F3 for ; Tue, 16 Jun 2009 23:21:55 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 17 Jun 2009 08:19:08 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2009 08:19:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EF13.85BA6014" Date: Wed, 17 Jun 2009 08:19:17 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD4048280C5@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis hi-target backward compatibility Thread-Index: AcnvE4qiHqhqwuOSRCy0RfDddNC8Cw== From: To: , , , , X-OriginalArrivalTime: 17 Jun 2009 06:19:08.0795 (UTC) FILETIME=[85FA24B0:01C9EF13] Cc: sipcore@ietf.org Subject: [sipcore] draft-barnes-sipcore-rfc4244bis hi-target backward compatibility X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 06:21:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EF13.85BA6014 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I saw that the hi-target is a mandatory parameter now. How a can now assure backward compatibility to the "old" History header. = Due to the fact that the old one is already implemented within some = networks? BR, Roland Deutsche Telekom Netzproduktion GmbH=20 Zentrum Technik Einf=FChrung=20 Roland Jesske=20 Gateways, Protokolle, Konvergenz, TE32-1 Heinrich-Hertz-Str. 3-7, 64295 Darmstadt,=20 Postfach, 64307 Darmstadt (Postanschrift)=20 +496151 628 2766 (Tel) +491718618445 (Mobile)=20 E-Mail: r.jesske@telekom.de=20 http://www.telekom.de =20 Registerrechtliche Unternehmensangaben:=20 Deutsche Telekom Netzproduktion GmbH=20 Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)=20 Gesch=E4ftsf=FChrung: Friedrich Fu=DF (Vorsitzender), Albert Matheis, = Klaus Peren=20 Handelsregister: Amtsgericht Bonn HRB 14190=20 Sitz der Gesellschaft: Bonn=20 USt-IdNr.: DE 814645262 ------_=_NextPart_001_01C9EF13.85BA6014 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [sipcore] draft-barnes-sipcore-rfc4244bis hi-target backward = compatibility

Dear all,
I saw that the hi-target is a = mandatory parameter now.
How a can now assure backward = compatibility to the "old" History header. Due to the fact = that the old one is already implemented within some networks?

BR,

Roland

Deutsche Telekom = Netzproduktion GmbH
Zentrum Technik Einf=FChrung
Roland Jesske
Gateways, Protokolle, Konvergenz, = TE32-1
Heinrich-Hertz-Str. 3-7, 64295 = Darmstadt,
Postfach, 64307 Darmstadt = (Postanschrift)
+496151 628 2766 (Tel)
+491718618445 (Mobile)
E-Mail: r.jesske@telekom.de=20
http://www.telekom.de=20



Registerrechtliche = Unternehmensangaben:=20
Deutsche Telekom Netzproduktion = GmbH
Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)
Gesch=E4ftsf=FChrung: Friedrich Fu=DF (Vorsitzender), Albert Matheis, = Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE 814645262


------_=_NextPart_001_01C9EF13.85BA6014-- From R.Jesske@telekom.de Tue Jun 16 23:34:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C133B28C17B for ; Tue, 16 Jun 2009 23:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=-2.400, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_LOAN=2.3, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DY9nwR1Dm-MN for ; Tue, 16 Jun 2009 23:34:28 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 7B83728C179 for ; Tue, 16 Jun 2009 23:34:26 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 17 Jun 2009 08:34:22 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2009 08:34:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 08:34:31 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD4048280DC@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYAAADaOvAAAEZYIAAAZd2gAAEEtLAAASSLAAAQUjFAAAQ6qeAABxuA8AAqMxcA References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com><1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>!<1ECE0EB50388174790F9694F77522CCF1E83DBEB@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA0375EC26@gaalpa1msgusr7e.ugd.att.com> <9886E5FCA6D76549A3011068483A4BD404827AB8@S4DE8PSAAQB.mitte.t-com.de> <9ECCF01B52E7AB408A7EB853526421412F59C6@ftrdmel0.rd.francetelecom.fr> From: To: , , , , , X-OriginalArrivalTime: 17 Jun 2009 06:34:22.0092 (UTC) FILETIME=[A65834C0:01C9EF15] Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 06:34:29 -0000 Is it really a complete separate discussion? In defining a parameter that is a hint that the uri was changed due to = some "magic" in a server, why not to point to some existing mechanism = and use it. Either we could mention that a drafts exisists that has the possibility = of "cause parameters" and some extensions are needed to express also = other services than CDIV. And define a additional draft for this values. Or add a section with some additional cause parameters. BR, Roland -----Urspr=FCngliche Nachricht----- Von: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Gesendet: Dienstag, 16. Juni 2009 12:31 An: bruno.chatras@orange-ftgroup.com; Jesske, Roland; mdolly@att.com; = mary.barnes@nortel.com; audet@nortel.com; sipcore@ietf.org Betreff: RE: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi, >I would go even further. There are cases where it is useful=20 >to keep track of the services invoked during the=20 >establishment of a session, irrespective of whether these=20 >services have modified the R-URI or not. To achieve this, an=20 >application server providing service X would insert an entry=20 >in the History-Info header field with hi-target=3Dnoop, an=20 >unmodified R-URI and an extended cause-param set to a value=20 >representing service "X". I think that should be a completely separate discussion. It is an interesting topic, but I think you would need to start it in = DISPATCH or BLISS, because I think it is far beyond the scope of both = 4244bis and target delivery :) Regards, Christer > -----Message d'origine----- > De : sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] De la part de=20 > R.Jesske@telekom.de Envoy=E9 : mardi 16 juin 2009 07:02 =C0 :=20 > mdolly@att.com; mary.barnes@nortel.com;=20 > christer.holmberg@ericsson.com; audet@nortel.com;=20 > sipcore@ietf.org Objet : Re: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hi, > Why not to adopt the cause-parameter principle of RFC 4458=20 > and extend it for other service approaches. > The have a general cause-param for services other then call=20 > diversion and to have explicit cause parameters for free=20 > phone, "IN-services", calling card ect. > Such indications where asked a couples of times from other=20 > service providers. >=20 > BR, >=20 > Roland=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] Im Auftrag von DOLLY,=20 > MARTIN C, ATTLABS > Gesendet: Montag, 15. Juni 2009 23:10 > An: Mary Barnes; Christer Holmberg; Francois Audet; sipcore@ietf.org > Betreff: Re: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > no >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 4:38 PM > To: Christer Holmberg; Francois Audet; DOLLY, MARTIN C,=20 > ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But, the freephone service can be implemented also with a=20 > reg-uri or reg-uri-alias - NOW if a specific service treats=20 > them the same, no big deal. The UAS then looks for any of a=20 > set of tags to grab the appropriate hi-entry.=20 >=20 > Mary. >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 3:14 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055);=20 > DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi,=20 >=20 > >But, still with this approach, I do not think you can get=20 > away with not > looking for multiple tags with the way you envision doing=20 > your services. >=20 > Maybe not - that depends on the service. But, then it will at least be > possible to figure out what has happended. >=20 > >I think there are others that will implement services on the UAS that > will not need the differentiation that you do - i.e, they=20 > care about the > difference between "reg-uri" and "reg-uri-alias". >=20 > My differentiation is based on my understanding of the=20 > requirements that > we have. >=20 > If you think we need to differentiate between req-uri and=20 > req-uri-alias, > then we should agree on such requirement. Let's not mix it with the > freephone requirement. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Monday, June 15, 2009 2:53 PM > To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY,=20 > MARTIN C, > ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Christer,=20 >=20 > On your last point, the objective here was to make use of History-Info > WITHOUT changing any core SIP functionality - it's a whole different > ballgame if we want to do the latter IMHO. However, here's the snippet > from the end of the response I just sent to Martin (summarizing the > current set of tags), which you may not read: >=20 > " So, we're debating here the differences between the "aor,mapped" and > "aor,routed" vs "predetermined", "reg-uri" and=20 > "reg-uri-alias". I think > that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed". > And, I think one could consider the "aor,mapped" as=20 > predetermined. But, > again 4244bis tags the entries entirely based on what SIP does and if > the 800 number translations (or whatever services) are setup=20 > differently > in different proxies, then you can't determine if the=20 > "aor,routed" cases > might be "reg-uri-alias" or "reg-uri". Although, I am personally > confused as to whether an 800 number would always be "aor, mapped" or > "aor, routed" - i.e., I just don't see this being deterministic and I > think that if a service can reach a UAS through different SIP > retargeting mechanisms, then the UAS needs to be aware.=20 >=20 > Also, as I'm going through this, I think we need 3 more tags=20 > if we want > the proxy to do the tagging - i.e., I think we need to add=20 > "-aor" to the > "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that the > proxy will mark in this manner. " >=20 >=20 > Mary.=20 > P.S. Also, I do not think it's a burden to put logic in the UAS - that > was the original intent for SIP - services in the endpoints - SIP is > just the signalling to carry the relevant information. But, I can see > that since the sort of service you mention that does not have=20 > a standard > SIP URI (i.e., user@domain) introduces something that isn't=20 > accomodated > in the basic SIP model, so we may need to add additional logic to the > proxies (I don't like it though).=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 2:34 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi,=20 >=20 > >Correct. But, what I am suggesting is that you distinguish it at the > UAS > >- I'm assuming that the target Request-URI that arrives at the UAS is > something that identifies a client that handles 800 numbers. That > client could be configured such that it knows to look for the=20 > >original 800 number in the mapped URIs or in the reg-alias-URIs or > both.=20 >=20 > 800 numbers is just one example.=20 >=20 > Why should the UAS have to be configured with this information??? I > think that is very limiting and unpractical. >=20 > >Again, if you're making these 800 numbers special and=20 > allowing proxies > to change them in multiple ways (i.e., non-deterministic), then if you > want them tagged special, then you need special logic in the=20 > >proxies to do this. >=20 > The logic is that the AOR is replaced with another AOR, which=20 > belongs to > the same user.=20 >=20 > It's not only for 800 numbers - they are just an example=20 > where it would > be useful. >=20 > And, the proxy is configured to do this - it doesn't do it because it > "thinks" it has to do it :) >=20 > >That doesn't make sense to me, although you could do it that way in a > closed network, in which case you can make sure to always tag them as > whatever you think they should be - so we could define an=20 > >additional value for the tag. But, this is what I don't=20 > think is right > in terms of normal SIP request routing and forwarding, which=20 > is what the > current 4244bis tags have been defined to represent.=20 >=20 > I really don't understand wht this "normal SIP request routing and > forwarding" is all about. Normal SIP request routing and=20 > forwarding has > issues, which were presented in the ua-loose-route draft - and that is > why we are now working on a solution to solve those issues. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 1:23 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi Mary, >=20 > Proxies will tag entries based on the functionality they perform. >=20 > Let's leave req-uri-alias for the moment. >=20 > As I said earlier, one of the issues we have with 4244bis, is that > "mapped" seems to be used BOTH for diversion and when an AOR=20 > is replaced > with another AOR pointing to the same user - e.g. freephone. So, it is > not possible to distinguish between diversion and freephone. >=20 > We think one MUST be able to make that distinguishment,=20 > because you may > have cases where both diversion and service number translation (e.g. > freephone) occurs, and the UAS needs to know which is which. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > =20 >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 9:13 PM > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > It seems to me that the gist of this discussion has been based on the > expectation that independent of how the 800 number is configured, > registered or whatever at a proxy, that there is an expectation of > deterministic behavior in terms of how it's tagged. So, if=20 > 800 numbers > are special and they can end up tagged as either reg-uri-alias or as > mapped, then perhaps the service has to know that it needs to look for > either of those. ISTM that if there is a reason to preserve=20 > that it's an > 800 number (i.e., and not format as a service specific uri),=20 > the service > at the UAS knows that it's special, thus it would need to check the > request-URIs associated with both reg-uri-alias and mapped hi-entries. > I can't see how we can make it work any other way without being > prescriptive of how proxy's MUST tag these entries, which is=20 > not a good > idea IMHO. However, I think these numbers are either special cases at > proxies or something that services know about.=20 >=20 > Mary.=20 >=20 > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 12:47 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary > (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Yes, we need to sort out what to do for that.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, June 15, 2009 10:17 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 > >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, June 15, 2009 6:50 PM > > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > > sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > then reg-uri-alias.=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Saturday, June 13, 2009 01:22 > > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C,=20 > ATTLABS; Barnes,=20 > > > Mary (RICH2:AR00); sipcore@ietf.org > > > Subject: RE: [sipcore] FW: I-D > > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > >=20 > > >=20 > > > Hi, > > >=20 > > > >1) RFC 4244bis > > > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > > Request-URI and it replacing it with a Contact, it will put > > a reg-uri > > > flag (if the Request-URI was the AOR used for=20 > registration), or reg- > > > >uri-alias (if the Request-URI was an alias for the AOR used in > > > registration). > > >=20 > > > And if the Request-URI was a "synonym" for the AOR? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Wed Jun 17 00:14:47 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A26A3A6988 for ; Wed, 17 Jun 2009 00:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.819 X-Spam-Level: X-Spam-Status: No, score=-5.819 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgQvLJ+q2Dgp for ; Wed, 17 Jun 2009 00:14:46 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E08D43A67AD for ; Wed, 17 Jun 2009 00:14:44 -0700 (PDT) X-AuditID: c1b4fb3e-b7b1dae000006c99-68-4a3897de6736 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 7C.97.27801.ED7983A4; Wed, 17 Jun 2009 09:14:39 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jun 2009 09:12:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EF1A.F1FB7DB2" Date: Wed, 17 Jun 2009 09:12:16 +0200 Message-ID: In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4048280C5@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis hi-target backward compatibility Thread-Index: AcnvE4qiHqhqwuOSRCy0RfDddNC8CwABzi8w References: <9886E5FCA6D76549A3011068483A4BD4048280C5@S4DE8PSAAQB.mitte.t-com.de> From: "Christer Holmberg" To: , , , , X-OriginalArrivalTime: 17 Jun 2009 07:12:16.0989 (UTC) FILETIME=[F249F0D0:01C9EF1A] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis hi-target backward compatibility X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 07:14:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EF1A.F1FB7DB2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Roland, =20 I think the meaning is that new, 4244bis compliant entities, would = insert hi-target. But, I agree with you that things must be backward = compatible, so a missing parameter must not be seen as an error. =20 Regards, =20 Christer ________________________________ From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: 17. kes=E4kuuta 2009 9:19 To: audet@nortel.com; Christer Holmberg; ietf.hanserik@gmail.com; = mary.barnes@nortel.com; shida@agnada.com Cc: sipcore@ietf.org Subject: [sipcore] draft-barnes-sipcore-rfc4244bis hi-target backward = compatibility =09 =09 Dear all,=20 I saw that the hi-target is a mandatory parameter now.=20 How a can now assure backward compatibility to the "old" History = header. Due to the fact that the old one is already implemented within = some networks? BR,=20 =09 Roland=20 Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Roland Jesske Gateways, Protokolle, Konvergenz, TE32-1 Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Postfach, 64307 Darmstadt (Postanschrift) +496151 628 2766 (Tel) +491718618445 (Mobile) E-Mail: r.jesske@telekom.de =20 http://www.telekom.de =20 Registerrechtliche Unternehmensangaben:=20 Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Friedrich Fu=DF (Vorsitzender), Albert Matheis, = Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262=20 ------_=_NextPart_001_01C9EF1A.F1FB7DB2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [sipcore] draft-barnes-sipcore-rfc4244bis hi-target = backward compatibility
Hi Roland,
 
I think the meaning is that new, 4244bis = compliant=20 entities, would insert hi-target. But, I agree with you that things must = be=20 backward compatible, so a missing parameter must not be seen as an=20 error.
 
Regards,
 
Christer

From: R.Jesske@telekom.de=20 [mailto:R.Jesske@telekom.de]
Sent: 17. kes=E4kuuta 2009=20 9:19
To: audet@nortel.com; Christer Holmberg;=20 ietf.hanserik@gmail.com; mary.barnes@nortel.com;=20 shida@agnada.com
Cc: sipcore@ietf.org
Subject: = [sipcore]=20 draft-barnes-sipcore-rfc4244bis hi-target backward=20 compatibility

Dear all,
I saw=20 that the hi-target is a mandatory parameter now.
How a can now assure backward compatibility to the "old" = History=20 header. Due to the fact that the old one is already implemented within = some=20 networks?

BR,

Roland

Deutsche Telekom = Netzproduktion=20 GmbH
Zentrum Technik Einf=FChrung
Roland=20 Jesske
Gateways, Protokolle, Konvergenz, TE32-1
Heinrich-Hertz-Str. 3-7, 64295 Darmstadt,
Postfach, 64307 Darmstadt (Postanschrift)
+496151 628 2766=20 (Tel)
+491718618445 = (Mobile)
E-Mail: r.jesske@telekom.de=20
http://www.telekom.de



Registerrechtliche=20 Unternehmensangaben: =
Deutsche Telekom Netzproduktion = GmbH
Aufsichtsrat:=20 Timotheus H=F6ttges (Vorsitzender)
Gesch=E4ftsf=FChrung: Friedrich = Fu=DF=20 (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: = Amtsgericht=20 Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE=20 814645262


------_=_NextPart_001_01C9EF1A.F1FB7DB2-- From christer.holmberg@ericsson.com Wed Jun 17 00:24:18 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D4F3A6A6D for ; Wed, 17 Jun 2009 00:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=-1.982, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_LOAN=2.3, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7AosFTfBFwb for ; Wed, 17 Jun 2009 00:24:16 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E04D23A6A2C for ; Wed, 17 Jun 2009 00:24:15 -0700 (PDT) X-AuditID: c1b4fb3e-b7b1dae000006c99-0c-4a389a19e48a Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id CD.E8.27801.91A983A4; Wed, 17 Jun 2009 09:24:10 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 Jun 2009 09:24:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 09:24:08 +0200 Message-ID: In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4048280DC@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYAAADaOvAAAEZYIAAAZd2gAAEEtLAAASSLAAAQUjFAAAQ6qeAABxuA8AAqMxcAAAGOHUA= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com><1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>!<1ECE0EB50388174790F9694F77522CCF1E83DBEB@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA0375EC26@gaalpa1msgusr7e.ugd.att.com> <9886E5FCA6D76549A3011068483A4BD404827AB8@S4DE8PSAAQB.mitte.t-com.de> <9ECCF01B52E7AB408A7EB853526421412F59C6@ftrdmel0.rd.francetelecom.fr> <9886E5FCA6D76549A3011068483A4BD4048280DC@S4DE8PSAAQB.mitte.t-com.de> From: "Christer Holmberg" To: , , , , , X-OriginalArrivalTime: 17 Jun 2009 07:24:09.0572 (UTC) FILETIME=[9B057A40:01C9EF1C] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 07:24:18 -0000 Hi,=20 >Is it really a complete separate discussion? It is a separate requirement. =20 >In defining a parameter that is a hint that the uri was=20 >changed due to some "magic" in a server, why not to point to=20 >some existing mechanism and use it. > >Either we could mention that a drafts exisists that has the=20 >possibility of "cause parameters" and some extensions are=20 >needed to express also other services than CDIV. And define a=20 >additional draft for this values. We are working on a solution to in a generic way indicate WHAT has = happened. I believe you are talking about WHY it happended. Again, I think it is an interesting topic, and maybe something we should = look at, but I think we should keep it separated. Regards, Christer > -----Urspr=FCngliche Nachricht----- > Von: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Gesendet: Dienstag, 16. Juni 2009 12:31 > An: bruno.chatras@orange-ftgroup.com; Jesske, Roland;=20 > mdolly@att.com; mary.barnes@nortel.com; audet@nortel.com;=20 > sipcore@ietf.org > Betreff: RE: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi, >=20 > >I would go even further. There are cases where it is useful=20 > >to keep track of the services invoked during the=20 > >establishment of a session, irrespective of whether these=20 > >services have modified the R-URI or not. To achieve this, an=20 > >application server providing service X would insert an entry=20 > >in the History-Info header field with hi-target=3Dnoop, an=20 > >unmodified R-URI and an extended cause-param set to a value=20 > >representing service "X". >=20 > I think that should be a completely separate discussion. >=20 > It is an interesting topic, but I think you would need to=20 > start it in DISPATCH or BLISS, because I think it is far=20 > beyond the scope of both 4244bis and target delivery :) >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > > -----Message d'origine----- > > De : sipcore-bounces@ietf.org=20 > > [mailto:sipcore-bounces@ietf.org] De la part de=20 > > R.Jesske@telekom.de Envoy=E9 : mardi 16 juin 2009 07:02 =C0 :=20 > > mdolly@att.com; mary.barnes@nortel.com;=20 > > christer.holmberg@ericsson.com; audet@nortel.com;=20 > > sipcore@ietf.org Objet : Re: [sipcore] FW: I-D=20 > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > Hi, > > Why not to adopt the cause-parameter principle of RFC 4458=20 > > and extend it for other service approaches. > > The have a general cause-param for services other then call=20 > > diversion and to have explicit cause parameters for free=20 > > phone, "IN-services", calling card ect. > > Such indications where asked a couples of times from other=20 > > service providers. > >=20 > > BR, > >=20 > > Roland=20 > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: sipcore-bounces@ietf.org=20 > > [mailto:sipcore-bounces@ietf.org] Im Auftrag von DOLLY,=20 > > MARTIN C, ATTLABS > > Gesendet: Montag, 15. Juni 2009 23:10 > > An: Mary Barnes; Christer Holmberg; Francois Audet; sipcore@ietf.org > > Betreff: Re: [sipcore] FW: I-D=20 > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > no > >=20 > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: Monday, June 15, 2009 4:38 PM > > To: Christer Holmberg; Francois Audet; DOLLY, MARTIN C,=20 > > ATTLABS; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > But, the freephone service can be implemented also with a=20 > > reg-uri or reg-uri-alias - NOW if a specific service treats=20 > > them the same, no big deal. The UAS then looks for any of a=20 > > set of tags to grab the appropriate hi-entry.=20 > >=20 > > Mary. > >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, June 15, 2009 3:14 PM > > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055);=20 > > DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi,=20 > >=20 > > >But, still with this approach, I do not think you can get=20 > > away with not > > looking for multiple tags with the way you envision doing=20 > > your services. > >=20 > > Maybe not - that depends on the service. But, then it will=20 > at least be > > possible to figure out what has happended. > >=20 > > >I think there are others that will implement services on=20 > the UAS that > > will not need the differentiation that you do - i.e, they=20 > > care about the > > difference between "reg-uri" and "reg-uri-alias". > >=20 > > My differentiation is based on my understanding of the=20 > > requirements that > > we have. > >=20 > > If you think we need to differentiate between req-uri and=20 > > req-uri-alias, > > then we should agree on such requirement. Let's not mix it with the > > freephone requirement. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Barnes, Mary (RICH2:AR00) > > Sent: Monday, June 15, 2009 2:53 PM > > To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY,=20 > > MARTIN C, > > ATTLABS; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > Christer,=20 > >=20 > > On your last point, the objective here was to make use of=20 > History-Info > > WITHOUT changing any core SIP functionality - it's a whole different > > ballgame if we want to do the latter IMHO. However, here's=20 > the snippet > > from the end of the response I just sent to Martin (summarizing the > > current set of tags), which you may not read: > >=20 > > " So, we're debating here the differences between the=20 > "aor,mapped" and > > "aor,routed" vs "predetermined", "reg-uri" and=20 > > "reg-uri-alias". I think > > that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed". > > And, I think one could consider the "aor,mapped" as=20 > > predetermined. But, > > again 4244bis tags the entries entirely based on what SIP=20 > does and if > > the 800 number translations (or whatever services) are setup=20 > > differently > > in different proxies, then you can't determine if the=20 > > "aor,routed" cases > > might be "reg-uri-alias" or "reg-uri". Although, I am personally > > confused as to whether an 800 number would always be "aor,=20 > mapped" or > > "aor, routed" - i.e., I just don't see this being=20 > deterministic and I > > think that if a service can reach a UAS through different SIP > > retargeting mechanisms, then the UAS needs to be aware.=20 > >=20 > > Also, as I'm going through this, I think we need 3 more tags=20 > > if we want > > the proxy to do the tagging - i.e., I think we need to add=20 > > "-aor" to the > > "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that the > > proxy will mark in this manner. " > >=20 > >=20 > > Mary.=20 > > P.S. Also, I do not think it's a burden to put logic in the=20 > UAS - that > > was the original intent for SIP - services in the endpoints - SIP is > > just the signalling to carry the relevant information. But,=20 > I can see > > that since the sort of service you mention that does not have=20 > > a standard > > SIP URI (i.e., user@domain) introduces something that isn't=20 > > accomodated > > in the basic SIP model, so we may need to add additional=20 > logic to the > > proxies (I don't like it though).=20 > >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, June 15, 2009 2:34 PM > > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > > MARTIN C, ATTLABS; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi,=20 > >=20 > > >Correct. But, what I am suggesting is that you distinguish=20 > it at the > > UAS > > >- I'm assuming that the target Request-URI that arrives at=20 > the UAS is > > something that identifies a client that handles 800 numbers. That > > client could be configured such that it knows to look for the=20 > > >original 800 number in the mapped URIs or in the reg-alias-URIs or > > both.=20 > >=20 > > 800 numbers is just one example.=20 > >=20 > > Why should the UAS have to be configured with this information??? I > > think that is very limiting and unpractical. > >=20 > > >Again, if you're making these 800 numbers special and=20 > > allowing proxies > > to change them in multiple ways (i.e., non-deterministic),=20 > then if you > > want them tagged special, then you need special logic in the=20 > > >proxies to do this. > >=20 > > The logic is that the AOR is replaced with another AOR, which=20 > > belongs to > > the same user.=20 > >=20 > > It's not only for 800 numbers - they are just an example=20 > > where it would > > be useful. > >=20 > > And, the proxy is configured to do this - it doesn't do it=20 > because it > > "thinks" it has to do it :) > >=20 > > >That doesn't make sense to me, although you could do it=20 > that way in a > > closed network, in which case you can make sure to always=20 > tag them as > > whatever you think they should be - so we could define an=20 > > >additional value for the tag. But, this is what I don't=20 > > think is right > > in terms of normal SIP request routing and forwarding, which=20 > > is what the > > current 4244bis tags have been defined to represent.=20 > >=20 > > I really don't understand wht this "normal SIP request routing and > > forwarding" is all about. Normal SIP request routing and=20 > > forwarding has > > issues, which were presented in the ua-loose-route draft -=20 > and that is > > why we are now working on a solution to solve those issues. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, June 15, 2009 1:23 PM > > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > > MARTIN C, ATTLABS; sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > Hi Mary, > >=20 > > Proxies will tag entries based on the functionality they perform. > >=20 > > Let's leave req-uri-alias for the moment. > >=20 > > As I said earlier, one of the issues we have with 4244bis, is that > > "mapped" seems to be used BOTH for diversion and when an AOR=20 > > is replaced > > with another AOR pointing to the same user - e.g.=20 > freephone. So, it is > > not possible to distinguish between diversion and freephone. > >=20 > > We think one MUST be able to make that distinguishment,=20 > > because you may > > have cases where both diversion and service number translation (e.g. > > freephone) occurs, and the UAS needs to know which is which. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > > =20 > >=20 > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: Monday, June 15, 2009 9:13 PM > > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; > > sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > It seems to me that the gist of this discussion has been=20 > based on the > > expectation that independent of how the 800 number is configured, > > registered or whatever at a proxy, that there is an expectation of > > deterministic behavior in terms of how it's tagged. So, if=20 > > 800 numbers > > are special and they can end up tagged as either reg-uri-alias or as > > mapped, then perhaps the service has to know that it needs=20 > to look for > > either of those. ISTM that if there is a reason to preserve=20 > > that it's an > > 800 number (i.e., and not format as a service specific uri),=20 > > the service > > at the UAS knows that it's special, thus it would need to check the > > request-URIs associated with both reg-uri-alias and mapped=20 > hi-entries. > > I can't see how we can make it work any other way without being > > prescriptive of how proxy's MUST tag these entries, which is=20 > > not a good > > idea IMHO. However, I think these numbers are either=20 > special cases at > > proxies or something that services know about.=20 > >=20 > > Mary.=20 > >=20 > > -----Original Message----- > > From: Audet, Francois (SC100:3055) > > Sent: Monday, June 15, 2009 12:47 PM > > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary > > (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > Yes, we need to sort out what to do for that.=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Monday, June 15, 2009 10:17 > > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C,=20 > ATTLABS; Barnes,=20 > > > Mary (RICH2:AR00); sipcore@ietf.org > > > Subject: RE: [sipcore] FW: I-D > > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > >=20 > > >=20 > > > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 > > >=20 > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: Monday, June 15, 2009 6:50 PM > > > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > > > sipcore@ietf.org > > > Subject: RE: [sipcore] FW: I-D > > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > >=20 > > > then reg-uri-alias.=20 > > >=20 > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > > Sent: Saturday, June 13, 2009 01:22 > > > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C,=20 > > ATTLABS; Barnes,=20 > > > > Mary (RICH2:AR00); sipcore@ietf.org > > > > Subject: RE: [sipcore] FW: I-D > > > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > > >=20 > > > >=20 > > > > Hi, > > > >=20 > > > > >1) RFC 4244bis > > > > > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > > > Request-URI and it replacing it with a Contact, it will put > > > a reg-uri > > > > flag (if the Request-URI was the AOR used for=20 > > registration), or reg- > > > > >uri-alias (if the Request-URI was an alias for the AOR used in > > > > registration). > > > >=20 > > > > And if the Request-URI was a "synonym" for the AOR? > > > >=20 > > > > Regards, > > > >=20 > > > > Christer > > > >=20 > > > >=20 > > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 >=20 From ietf.hanserik@gmail.com Wed Jun 17 01:26:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298E328C137 for ; Wed, 17 Jun 2009 01:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suUDu6eWBO4Q for ; Wed, 17 Jun 2009 01:26:37 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 9DEA128C0E2 for ; Wed, 17 Jun 2009 01:26:36 -0700 (PDT) Received: by ewy6 with SMTP id 6so251977ewy.37 for ; Wed, 17 Jun 2009 01:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6z+fDO5v4cuYlB6rywu7Caudm0oCOqovwDc+JVk54NM=; b=JbOlgMs1gv6ob3OLLI/kG0+9MTdDvCrCAjrwHeRpl3L9yElfhtQgoEymOtpQZXJip7 s0eqM4gSRRnH2Fl5jLt6W+M7ZXQghwNOO+u2QiFiT79pV6WByZYKMcvUW5f7Y1R6et2u xMQX7kKOxZfKoyf616iERx186cSr4Y6adIheE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Xa1AxGj3c/VpFvKOhEtD4KM5fbMud2FoIi2Wg9NZTlUxWSAX+W5idKIsyjXAjsnEHx vvD4AAKk2BFaPcYEMhZGBf9R/eyPOP38voXOxiFHAfeWuKt4cBRkwU+MO3ItP2mBrgX1 PFx63ngeU6+m8+3SADt1DjweitqRbxieUGVgw= MIME-Version: 1.0 Received: by 10.216.26.80 with SMTP id b58mr3102326wea.35.1245227203458; Wed, 17 Jun 2009 01:26:43 -0700 (PDT) In-Reply-To: <9886E5FCA6D76549A3011068483A4BD40482809F@S4DE8PSAAQB.mitte.t-com.de> References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404827ACF@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1E88E0FE@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD40482809F@S4DE8PSAAQB.mitte.t-com.de> Date: Wed, 17 Jun 2009 10:26:43 +0200 Message-ID: <9ae56b1e0906170126x25f12db9ua03b4d3b2cfb32bb@mail.gmail.com> From: Hans Erik van Elburg To: R.Jesske@telekom.de Content-Type: multipart/alternative; boundary=001485f423dc20785a046c870dea Cc: sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 08:26:39 -0000 --001485f423dc20785a046c870dea Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roland, For that you would use IBCF or SBC topology hiding functionality on the boundary of you're network. This is not an issue for the 4424bis, if it where it would be an issue with 4424 too. BR, /Hans Erik van Elburg On Wed, Jun 17, 2009 at 8:00 AM, wrote: > I have slide concerns with that approach. Some network operators does not > like to present all the way of messages. > Even if the entry is anonymous the amount of entries will show the networ= k > structure which could also raise security concerns. > > BR, Roland > > -----Urspr=FCngliche Nachricht----- > Von: Francois Audet [mailto:audet@nortel.com] > Gesendet: Dienstag, 16. Juni 2009 19:22 > An: Jesske, Roland; christer.holmberg@ericsson.com; > ietf.hanserik@gmail.com; Mary Barnes; shida@agnada.com > Cc: sipcore@ietf.org > Betreff: RE: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri > > In the new draft, the entries are always there and never removed. It make= s > HI much more reliable. > > If entries need to be anonymous, they are anonymized but the entry is sti= ll > there. > > > -----Original Message----- > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > > Sent: Monday, June 15, 2009 22:38 > > To: Audet, Francois (SC100:3055); > > christer.holmberg@ericsson.com; ietf.hanserik@gmail.com; > > Barnes, Mary (RICH2:AR00); shida@agnada.com > > Cc: sipcore@ietf.org > > Subject: AW: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri > > > > Such values looks good and gives more guideline why the entry > > was included. > > My question would be if there is a different network > > behaviour foreseen for the History mechanism. > > Perhaps some of the networks needs the history only to > > indicate where the URI were mapped ("mp") and others would > > really track the whole history of each SIP proxy. > > Or is it only seen either to support history full or not. > > > > BR, > > > > Roland > > > > -----Urspr=FCngliche Nachricht----- > > Von: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Francois Audet > > Gesendet: Dienstag, 16. Juni 2009 03:44 > > An: Christer Holmberg; Hans Erik van Elburg; Mary Barnes; > > Shida Schubert > > Cc: sipcore@ietf.org > > Betreff: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri > > > > All right guys, > > > > I've been thinking about this. > > > > It seems to me that what we want to capture is: > > 1) If the target is an AOR, a contact, or a routing URI > > (maddr, noop intra-domain, or noop > > forward to next domain, or strict routing). > > 2) In the case that the target is an AOR, then if that AOR is > > known to be an alias for the previous > > one, or if it is mapped to another AOR. > > > > It seems to me that a Proxy should mark a Previous entry in > > H-I with aor if it determines that it owns this AOR. Just as > > Hans's current target-uri draft. > > > > Now, for the mapped vs routed (versus reg-contact, etc.), > > instead of marking the Previous entry, we should mark the > > OUTGOING (i.e., New) entry instead. This would make the procedures of > > 7.2.1 & 7.2.2 of target-URI draft clearer. > > > > Specifically, the logic would be: > > > > When proxy receives an incoming request with H-I, it adds an > > ;aor tag to that incoming entry if it determines that it is > > responsible for the AOR and. > > > > Also, if there was no Hi-entry at all (i.e., it came from a > > UAC), and the Proxy creates then two entries, the first one > > in this case would also have the ;aor tag associated to it. > > > > For the Outgoing entry, I would see the following tags: > > > > rc : The entry is an explicit registered contact > > (i.e., it was provided in a REGISTER message) > > > > ic : The entry is an implicit registered contact > > (i.e., it's exactly as a registered contact, > > but was not discovered using SIP Registration: > > it could have been manually configured > > or done with a proprietary mechanism). > > > > (TBD: we could debate if we need both rc and > > irc, but I think we do). > > > > mp : The request-URI is changed to a new URI that > > represent another user. > > > > rt : The entry is "routed", i.e., it is either a > > no-opt like a proxy forwarding within > > a domain, predetermined by a maddr in the > > Request-URI, or when proxy is NOT responsible > > for domain, or the address is an alias for the > > incoming URI. > > > > So, to give an example. > > > > Say Alice calls Bob. Bob is forwarded to freephone. Freephone > > routes to Carol. > > > > The History-info at Carol would look like this: > > > > Alice -> example.com > > Nothing because UAC typically doesn't send H-I (otherwise, it > > would be as per Index 1 in next entry, but without the AOR. > > > > example.com -> freephone@example.net > > History-Info: >;index=3D1;a= or > > History-Info: > >;index=3D1.1;mp > > > > example.net -> carol@example.net > > History-Info: >;index=3D1;a= or > > History-Info: > >;index=3D1.1;mp;aor > > <- aor is added > > History-Info: >;index= =3D1.1.1;rt;aor > } > > Two entries are > > History-Info: >;index=3D1.1= .1.1;rc > } > > added at same time > > > > Also, I don't think we need to define an equivalent to the > > "reg-uri-alias" anymore. > > If Freephone was configured to go to +14085551212 instead of > > the registered Contact (assuming +14085551212 was an Alias > > AOR for carol@example.net), the last H-I entries would look > > like this instead: > > > > example.net -> carol@example.net > > History-Info: >;index=3D1;a= or > > History-Info: > > ;user= =3Dphone>;index=3D1.1;mp;aor > <- > > aor is added > > History-Info: > >;index=3D1.1.1;rt;aor > > <- aor is added > > History-Info: > >;index=3D1.1.1.1;rt;aor > > } Two entries are > > History-Info: > >;index=3D1.1.1.1.1;rc > > } added at same time > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > --001485f423dc20785a046c870dea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roland,

For that you would use IBCF or SBC topology hiding functi= onality on the boundary of you're network. This is not an issue for the= 4424bis, if it where it would be an issue with 4424 too.

BR,
/Hans Erik van Elburg


On Wed, Jun 17, 2009 at 8:00 AM, <R.Jesske@telekom.de<= /a>> wrote:
I have slide concerns with that approach. Some network operators does not l= ike to present all the way of messages.
Even if the entry is anonymous the amount of entries will show the network = structure which could also raise security concerns.

BR, Roland

-----Urspr=FCngliche Nachricht-----
Von: Francois Audet [mailto:audet@norte= l.com]
Gesendet: Dienstag, 16. Juni 2009 19:22
An: Jesske, Roland; chris= ter.holmberg@ericsson.com; i= etf.hanserik@gmail.com; Mary Barnes; shida@agnada.com
Cc: sipcore@ietf.org
Betreff: RE: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri

In the new draft, the entries are always there and never removed. It makes<= br> HI much more reliable.

If entries need to be anonymous, they are anonymized but the entry is still= there.

> -----Original Message-----
> From: R.Jesske@telekom.de [= mailto:R.Jesske@telekom.de]
> Sent: Monday, June 15, 2009 22:38
> To: Audet, Francois (SC100:3055);
> christer.holmberg@er= icsson.com; ietf.hanserik@gm= ail.com;
> Barnes, Mary (RICH2:AR00); shida@a= gnada.com
> Cc: sipcore@ietf.org
> Subject: AW: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri<= br> >
> Such values looks good and gives more guideline why the entry
> was included.
> My question would be if there is a different network
> behaviour foreseen for the History mechanism.
> Perhaps some of the networks needs the history only to
> indicate where the URI were mapped ("mp") and others would > really track the whole history of each SIP proxy.
> Or is it only seen either to support history full =A0or not.
>
> BR,
>
> Roland
>
> -----Urspr=FCngliche Nachricht-----
> Von: sipcore-bounces@ietf.= org
> [mailto:sipcore-bounces@ie= tf.org] Im Auftrag von Francois Audet
> Gesendet: Dienstag, 16. Juni 2009 03:44
> An: Christer Holmberg; Hans Erik van Elburg; Mary Barnes;
> Shida Schubert
> Cc: sipcore@ietf.org
> Betreff: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri
>
> All right guys,
>
> I've been thinking about this.
>
> It seems to me that what we want to capture is:
> 1) If the target is an AOR, a contact, or a routing URI
> (maddr, noop intra-domain, or noop
> =A0 =A0forward to next domain, or strict routing).
> 2) In the case that the target is an AOR, then if that AOR is
> known to be an alias for the previous
> =A0 =A0one, or if it is mapped to another AOR.
>
> It seems to me that a Proxy should mark a Previous entry in
> H-I with aor if it determines that it owns this AOR. Just as
> Hans's current target-uri draft.
>
> Now, for the mapped vs routed (versus reg-contact, etc.),
> instead of marking the Previous entry, we should mark the
> OUTGOING (i.e., New) entry instead. This would make the procedures of<= br> > 7.2.1 & 7.2.2 of target-URI draft clearer.
>
> Specifically, the logic would be:
>
> When proxy receives an incoming request with H-I, it adds an
> ;aor tag to that incoming entry if it determines that it is
> responsible for the AOR and.
>
> Also, if there was no Hi-entry at all (i.e., it came from a
> UAC), and the Proxy creates then two entries, the first one
> in this case would also have the ;aor tag associated to it.
>
> For the Outgoing entry, I would see the following tags:
>
> rc =A0 =A0: =A0 =A0 =A0 The entry is an explicit registered contact > (i.e., it was provided in a REGISTER message)
>
> ic =A0 =A0: =A0 =A0 =A0 The entry is an implicit registered contact > (i.e., it's exactly as a registered contact,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 but was not discovered using SIP Registrat= ion:
> it could have been manually configured
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 or done with a proprietary mechanism).
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 (TBD: we could debate if we need both rc a= nd
> irc, but I think we do).
>
> mp =A0 =A0: =A0 =A0 =A0 The request-URI is changed to a new URI that > represent another user.
>
> rt =A0 =A0: =A0 =A0 =A0 The entry is "routed", i.e., it is e= ither a
> no-opt like a proxy forwarding within
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 a domain, predetermined by a maddr in the<= br> > Request-URI, or when proxy is NOT responsible
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 for domain, or the address is an alias for= the
> incoming URI.
>
> So, to give an example.
>
> Say Alice calls Bob. Bob is forwarded to freephone. Freephone
> routes to Carol.
>
> The History-info at Carol would look like this:
>
> Alice -> example.c= om
> Nothing because UAC typically doesn't send H-I (otherwise, it
> would be as per Index 1 in next entry, but without the AOR.
>
> example.com ->= freephone@example.net
> History-Info: <sip:bob@exa= mple.com>;index=3D1;aor
> History-Info: <sip:f= reephone@example.net>;index=3D1.1;mp
>
> example.net ->= carol@example.net
> History-Info: <sip:bob@exa= mple.com>;index=3D1;aor
> History-Info: <sip:f= reephone@example.net>;index=3D1.1;mp;aor
> <- aor is added
> History-Info: <sip:carol= @example.net>;index=3D1.1.1;rt;aor =A0 =A0}
> =A0Two entries are
> History-Info: <sip:carol@1= 92.0.2.4>;index=3D1.1.1.1;rc =A0 =A0 =A0 =A0}
> =A0added at same time
>
> Also, I don't think we need to define an equivalent to the
> "reg-uri-alias" anymore.
> If Freephone was configured to go to +14085551212 instead of
> the registered Contact (assuming +14085551212 was an Alias
> AOR for carol@example.net), t= he last H-I entries would look
> like this instead:
>
> example.net ->= carol@example.net
> History-Info: <sip:bob@exa= mple.com>;index=3D1;aor
> History-Info:
> <sip:+140855512= 12@example.net;user=3Dphone>;index=3D1.1;mp;aor <-
> aor is added
> History-Info: <sip:f= reephone@example.net>;index=3D1.1.1;rt;aor
> <- aor is added
> History-Info: <sip:carol= @example.net>;index=3D1.1.1.1;rt;aor
> } =A0Two entries are
> History-Info: <sip:carol@1= 92.0.2.4>;index=3D1.1.1.1.1;rc
> } =A0added at same time
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>

--001485f423dc20785a046c870dea-- From john.elwell@siemens-enterprise.com Wed Jun 17 03:14:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8482E3A6809 for ; Wed, 17 Jun 2009 03:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svdyv6YovQL9 for ; Wed, 17 Jun 2009 03:14:31 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 0956D3A69CE for ; Wed, 17 Jun 2009 03:14:31 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KLD0036YOEJ2P@siemenscomms.co.uk> for sipcore@ietf.org; Wed, 17 Jun 2009 11:13:31 +0100 (BST) Date: Wed, 17 Jun 2009 11:13:32 +0100 From: "Elwell, John" In-reply-to: <4A3227D2.4020808@ericsson.com> To: Gonzalo Camarillo , SIPCORE Message-id: <0D5F89FAC29E2C41B98A6A762007F5D002063E84@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] Milestone to revise RFC 3265 Thread-Index: AcnrRQcGTO4lyl0RQ6eEVbQP4J3whAD7zFVg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A3227D2.4020808@ericsson.com> Subject: Re: [sipcore] Milestone to revise RFC 3265 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 10:14:32 -0000 Yes to both. John=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: 12 June 2009 11:03 > To: SIPCORE > Subject: [sipcore] Milestone to revise RFC 3265 >=20 > Folks, >=20 > since the publication of RFC 3265, we have gotten significant=20 > experience=20 > deploying SIP-based notification systems. It has been=20 > proposed to revise=20 > RFC 3265 based on that experience. We have two questions for the WG: >=20 > 1) should we add a milestone to our charter to revise RFC 3265? >=20 > 2) if we add such a milestone, should we take the following=20 > draft as the=20 > initial WG item for the milestone? >=20 > http://tools.ietf.org/html/draft-roach-sipcore-rfc3265bis-00 >=20 > Thanks, >=20 > Gonzalo > SIPCORE co-chair > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From mdolly@att.com Wed Jun 17 03:19:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 645983A6809 for ; Wed, 17 Jun 2009 03:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.72 X-Spam-Level: X-Spam-Status: No, score=-105.72 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SORTED_RECIPS=1.125, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkPucEByTDtt for ; Wed, 17 Jun 2009 03:19:10 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.242.3]) by core3.amsl.com (Postfix) with ESMTP id 76A643A6968 for ; Wed, 17 Jun 2009 03:19:03 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-2.tower-121.messagelabs.com!1245233858!23678182!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 21343 invoked from network); 17 Jun 2009 10:17:39 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-2.tower-121.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Jun 2009 10:17:39 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5HAHcP1018518; Wed, 17 Jun 2009 06:17:38 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n5HAHYK7018492; Wed, 17 Jun 2009 06:17:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 17 Jun 2009 06:17:33 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD481E@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAEsEiwAAY2eFwABpznoAACQ/pUw== From: "DOLLY, MARTIN C, ATTLABS" To: , , , , , Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 10:19:11 -0000 SSBhZ3JlZSB3aXRoIFJvbGFuZA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9t OiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgPHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZz4NClRv OiBhdWRldEBub3J0ZWwuY29tIDxhdWRldEBub3J0ZWwuY29tPjsgY2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+OyBpZXRmLmhhbnNl cmlrQGdtYWlsLmNvbSA8aWV0Zi5oYW5zZXJpa0BnbWFpbC5jb20+OyBtYXJ5LmJhcm5lc0Bub3J0 ZWwuY29tIDxtYXJ5LmJhcm5lc0Bub3J0ZWwuY29tPjsgc2hpZGFAYWduYWRhLmNvbSA8c2hpZGFA YWduYWRhLmNvbT4NCkNjOiBzaXBjb3JlQGlldGYub3JnIDxzaXBjb3JlQGlldGYub3JnPg0KU2Vu dDogV2VkIEp1biAxNyAwMjowMDozOCAyMDA5DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIGRyYWZ0 LWJhcm5lcy1zaXBjb3JlLXJmYzQyNDRiaXMgYW5kIHRhcmdldC11cmkNCg0KSSBoYXZlIHNsaWRl IGNvbmNlcm5zIHdpdGggdGhhdCBhcHByb2FjaC4gU29tZSBuZXR3b3JrIG9wZXJhdG9ycyBkb2Vz IG5vdCBsaWtlIHRvIHByZXNlbnQgYWxsIHRoZSB3YXkgb2YgbWVzc2FnZXMuDQpFdmVuIGlmIHRo ZSBlbnRyeSBpcyBhbm9ueW1vdXMgdGhlIGFtb3VudCBvZiBlbnRyaWVzIHdpbGwgc2hvdyB0aGUg bmV0d29yayBzdHJ1Y3R1cmUgd2hpY2ggY291bGQgYWxzbyByYWlzZSBzZWN1cml0eSBjb25jZXJu cy4NCg0KQlIsIFJvbGFuZCANCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0K Vm9uOiBGcmFuY29pcyBBdWRldCBbbWFpbHRvOmF1ZGV0QG5vcnRlbC5jb21dIA0KR2VzZW5kZXQ6 IERpZW5zdGFnLCAxNi4gSnVuaSAyMDA5IDE5OjIyDQpBbjogSmVzc2tlLCBSb2xhbmQ7IGNocmlz dGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTsgaWV0Zi5oYW5zZXJpa0BnbWFpbC5jb207IE1hcnkg QmFybmVzOyBzaGlkYUBhZ25hZGEuY29tDQpDYzogc2lwY29yZUBpZXRmLm9yZw0KQmV0cmVmZjog UkU6IFtzaXBjb3JlXSBkcmFmdC1iYXJuZXMtc2lwY29yZS1yZmM0MjQ0YmlzIGFuZCB0YXJnZXQt dXJpDQoNCkluIHRoZSBuZXcgZHJhZnQsIHRoZSBlbnRyaWVzIGFyZSBhbHdheXMgdGhlcmUgYW5k IG5ldmVyIHJlbW92ZWQuIEl0IG1ha2VzDQpISSBtdWNoIG1vcmUgcmVsaWFibGUuDQoNCklmIGVu dHJpZXMgbmVlZCB0byBiZSBhbm9ueW1vdXMsIHRoZXkgYXJlIGFub255bWl6ZWQgYnV0IHRoZSBl bnRyeSBpcyBzdGlsbCB0aGVyZS4gDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogUi5KZXNza2VAdGVsZWtvbS5kZSBbbWFpbHRvOlIuSmVzc2tlQHRlbGVrb20uZGVdIA0K PiBTZW50OiBNb25kYXksIEp1bmUgMTUsIDIwMDkgMjI6MzgNCj4gVG86IEF1ZGV0LCBGcmFuY29p cyAoU0MxMDA6MzA1NSk7IA0KPiBjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb207IGlldGYu aGFuc2VyaWtAZ21haWwuY29tOyANCj4gQmFybmVzLCBNYXJ5IChSSUNIMjpBUjAwKTsgc2hpZGFA YWduYWRhLmNvbQ0KPiBDYzogc2lwY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBBVzogW3NpcGNv cmVdIGRyYWZ0LWJhcm5lcy1zaXBjb3JlLXJmYzQyNDRiaXMgYW5kIHRhcmdldC11cmkNCj4gDQo+ IFN1Y2ggdmFsdWVzIGxvb2tzIGdvb2QgYW5kIGdpdmVzIG1vcmUgZ3VpZGVsaW5lIHdoeSB0aGUg ZW50cnkgDQo+IHdhcyBpbmNsdWRlZC4NCj4gTXkgcXVlc3Rpb24gd291bGQgYmUgaWYgdGhlcmUg aXMgYSBkaWZmZXJlbnQgbmV0d29yayANCj4gYmVoYXZpb3VyIGZvcmVzZWVuIGZvciB0aGUgSGlz dG9yeSBtZWNoYW5pc20uDQo+IFBlcmhhcHMgc29tZSBvZiB0aGUgbmV0d29ya3MgbmVlZHMgdGhl IGhpc3Rvcnkgb25seSB0byANCj4gaW5kaWNhdGUgd2hlcmUgdGhlIFVSSSB3ZXJlIG1hcHBlZCAo Im1wIikgYW5kIG90aGVycyB3b3VsZCANCj4gcmVhbGx5IHRyYWNrIHRoZSB3aG9sZSBoaXN0b3J5 IG9mIGVhY2ggU0lQIHByb3h5Lg0KPiBPciBpcyBpdCBvbmx5IHNlZW4gZWl0aGVyIHRvIHN1cHBv cnQgaGlzdG9yeSBmdWxsICBvciBub3QuDQo+IA0KPiBCUiwNCj4gDQo+IFJvbGFuZCAgDQo+IA0K PiAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQo+IFZvbjogc2lwY29yZS1ib3Vu Y2VzQGlldGYub3JnIA0KPiBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVm dHJhZyB2b24gRnJhbmNvaXMgQXVkZXQNCj4gR2VzZW5kZXQ6IERpZW5zdGFnLCAxNi4gSnVuaSAy MDA5IDAzOjQ0DQo+IEFuOiBDaHJpc3RlciBIb2xtYmVyZzsgSGFucyBFcmlrIHZhbiBFbGJ1cmc7 IE1hcnkgQmFybmVzOyANCj4gU2hpZGEgU2NodWJlcnQNCj4gQ2M6IHNpcGNvcmVAaWV0Zi5vcmcN Cj4gQmV0cmVmZjogW3NpcGNvcmVdIGRyYWZ0LWJhcm5lcy1zaXBjb3JlLXJmYzQyNDRiaXMgYW5k IHRhcmdldC11cmkNCj4gDQo+IEFsbCByaWdodCBndXlzLA0KPiANCj4gSSd2ZSBiZWVuIHRoaW5r aW5nIGFib3V0IHRoaXMuDQo+IA0KPiBJdCBzZWVtcyB0byBtZSB0aGF0IHdoYXQgd2Ugd2FudCB0 byBjYXB0dXJlIGlzOg0KPiAxKSBJZiB0aGUgdGFyZ2V0IGlzIGFuIEFPUiwgYSBjb250YWN0LCBv ciBhIHJvdXRpbmcgVVJJIA0KPiAobWFkZHIsIG5vb3AgaW50cmEtZG9tYWluLCBvciBub29wDQo+ ICAgIGZvcndhcmQgdG8gbmV4dCBkb21haW4sIG9yIHN0cmljdCByb3V0aW5nKS4NCj4gMikgSW4g dGhlIGNhc2UgdGhhdCB0aGUgdGFyZ2V0IGlzIGFuIEFPUiwgdGhlbiBpZiB0aGF0IEFPUiBpcyAN Cj4ga25vd24gdG8gYmUgYW4gYWxpYXMgZm9yIHRoZSBwcmV2aW91cw0KPiAgICBvbmUsIG9yIGlm IGl0IGlzIG1hcHBlZCB0byBhbm90aGVyIEFPUi4NCj4gDQo+IEl0IHNlZW1zIHRvIG1lIHRoYXQg YSBQcm94eSBzaG91bGQgbWFyayBhIFByZXZpb3VzIGVudHJ5IGluIA0KPiBILUkgd2l0aCBhb3Ig aWYgaXQgZGV0ZXJtaW5lcyB0aGF0IGl0IG93bnMgdGhpcyBBT1IuIEp1c3QgYXMgDQo+IEhhbnMn cyBjdXJyZW50IHRhcmdldC11cmkgZHJhZnQuDQo+IA0KPiBOb3csIGZvciB0aGUgbWFwcGVkIHZz IHJvdXRlZCAodmVyc3VzIHJlZy1jb250YWN0LCBldGMuKSwgDQo+IGluc3RlYWQgb2YgbWFya2lu ZyB0aGUgUHJldmlvdXMgZW50cnksIHdlIHNob3VsZCBtYXJrIHRoZSANCj4gT1VUR09JTkcgKGku ZS4sIE5ldykgZW50cnkgaW5zdGVhZC4gVGhpcyB3b3VsZCBtYWtlIHRoZSBwcm9jZWR1cmVzIG9m DQo+IDcuMi4xICYgNy4yLjIgb2YgdGFyZ2V0LVVSSSBkcmFmdCBjbGVhcmVyLg0KPiANCj4gU3Bl Y2lmaWNhbGx5LCB0aGUgbG9naWMgd291bGQgYmU6DQo+IA0KPiBXaGVuIHByb3h5IHJlY2VpdmVz IGFuIGluY29taW5nIHJlcXVlc3Qgd2l0aCBILUksIGl0IGFkZHMgYW4gDQo+IDthb3IgdGFnIHRv IHRoYXQgaW5jb21pbmcgZW50cnkgaWYgaXQgZGV0ZXJtaW5lcyB0aGF0IGl0IGlzIA0KPiByZXNw b25zaWJsZSBmb3IgdGhlIEFPUiBhbmQuIA0KPiANCj4gQWxzbywgaWYgdGhlcmUgd2FzIG5vIEhp LWVudHJ5IGF0IGFsbCAoaS5lLiwgaXQgY2FtZSBmcm9tIGEgDQo+IFVBQyksIGFuZCB0aGUgUHJv eHkgY3JlYXRlcyB0aGVuIHR3byBlbnRyaWVzLCB0aGUgZmlyc3Qgb25lIA0KPiBpbiB0aGlzIGNh c2Ugd291bGQgYWxzbyBoYXZlIHRoZSA7YW9yIHRhZyBhc3NvY2lhdGVkIHRvIGl0Lg0KPiANCj4g Rm9yIHRoZSBPdXRnb2luZyBlbnRyeSwgSSB3b3VsZCBzZWUgdGhlIGZvbGxvd2luZyB0YWdzOg0K PiANCj4gcmMJOglUaGUgZW50cnkgaXMgYW4gZXhwbGljaXQgcmVnaXN0ZXJlZCBjb250YWN0IA0K PiAoaS5lLiwgaXQgd2FzIHByb3ZpZGVkIGluIGEgUkVHSVNURVIgbWVzc2FnZSkNCj4gDQo+IGlj CToJVGhlIGVudHJ5IGlzIGFuIGltcGxpY2l0IHJlZ2lzdGVyZWQgY29udGFjdCANCj4gKGkuZS4s IGl0J3MgZXhhY3RseSBhcyBhIHJlZ2lzdGVyZWQgY29udGFjdCwNCj4gCQlidXQgd2FzIG5vdCBk aXNjb3ZlcmVkIHVzaW5nIFNJUCBSZWdpc3RyYXRpb246IA0KPiBpdCBjb3VsZCBoYXZlIGJlZW4g bWFudWFsbHkgY29uZmlndXJlZA0KPiAJCW9yIGRvbmUgd2l0aCBhIHByb3ByaWV0YXJ5IG1lY2hh bmlzbSkuDQo+IA0KPiAJCShUQkQ6IHdlIGNvdWxkIGRlYmF0ZSBpZiB3ZSBuZWVkIGJvdGggcmMg YW5kIA0KPiBpcmMsIGJ1dCBJIHRoaW5rIHdlIGRvKS4NCj4gDQo+IG1wCToJVGhlIHJlcXVlc3Qt VVJJIGlzIGNoYW5nZWQgdG8gYSBuZXcgVVJJIHRoYXQgDQo+IHJlcHJlc2VudCBhbm90aGVyIHVz ZXIuDQo+IA0KPiBydAk6CVRoZSBlbnRyeSBpcyAicm91dGVkIiwgaS5lLiwgaXQgaXMgZWl0aGVy IGEgDQo+IG5vLW9wdCBsaWtlIGEgcHJveHkgZm9yd2FyZGluZyB3aXRoaW4NCj4gCQlhIGRvbWFp biwgcHJlZGV0ZXJtaW5lZCBieSBhIG1hZGRyIGluIHRoZSANCj4gUmVxdWVzdC1VUkksIG9yIHdo ZW4gcHJveHkgaXMgTk9UIHJlc3BvbnNpYmxlDQo+IAkJZm9yIGRvbWFpbiwgb3IgdGhlIGFkZHJl c3MgaXMgYW4gYWxpYXMgZm9yIHRoZSANCj4gaW5jb21pbmcgVVJJLg0KPiANCj4gU28sIHRvIGdp dmUgYW4gZXhhbXBsZS4gDQo+IA0KPiBTYXkgQWxpY2UgY2FsbHMgQm9iLiBCb2IgaXMgZm9yd2Fy ZGVkIHRvIGZyZWVwaG9uZS4gRnJlZXBob25lIA0KPiByb3V0ZXMgdG8gQ2Fyb2wuIA0KPiANCj4g VGhlIEhpc3RvcnktaW5mbyBhdCBDYXJvbCB3b3VsZCBsb29rIGxpa2UgdGhpczoNCj4gDQo+IEFs aWNlIC0+IGV4YW1wbGUuY29tDQo+IE5vdGhpbmcgYmVjYXVzZSBVQUMgdHlwaWNhbGx5IGRvZXNu J3Qgc2VuZCBILUkgKG90aGVyd2lzZSwgaXQgDQo+IHdvdWxkIGJlIGFzIHBlciBJbmRleCAxIGlu IG5leHQgZW50cnksIGJ1dCB3aXRob3V0IHRoZSBBT1IuDQo+IA0KPiBleGFtcGxlLmNvbSAtPiBm cmVlcGhvbmVAZXhhbXBsZS5uZXQNCj4gSGlzdG9yeS1JbmZvOiA8c2lwOmJvYkBleGFtcGxlLmNv bT47aW5kZXg9MTthb3INCj4gSGlzdG9yeS1JbmZvOiA8c2lwOmZyZWVwaG9uZUBleGFtcGxlLm5l dD47aW5kZXg9MS4xO21wDQo+IA0KPiBleGFtcGxlLm5ldCAtPiBjYXJvbEBleGFtcGxlLm5ldA0K PiBIaXN0b3J5LUluZm86IDxzaXA6Ym9iQGV4YW1wbGUuY29tPjtpbmRleD0xO2FvciAgICAgICAg ICAgDQo+IEhpc3RvcnktSW5mbzogPHNpcDpmcmVlcGhvbmVAZXhhbXBsZS5uZXQ+O2luZGV4PTEu MTttcDthb3IgIA0KPiA8LSBhb3IgaXMgYWRkZWQNCj4gSGlzdG9yeS1JbmZvOiA8c2lwOmNhcm9s QGV4YW1wbGUubmV0PjtpbmRleD0xLjEuMTtydDthb3IgICAgfSANCj4gIFR3byBlbnRyaWVzIGFy ZQ0KPiBIaXN0b3J5LUluZm86IDxzaXA6Y2Fyb2xAMTkyLjAuMi40PjtpbmRleD0xLjEuMS4xO3Jj ICAgICAgICB9IA0KPiAgYWRkZWQgYXQgc2FtZSB0aW1lDQo+IA0KPiBBbHNvLCBJIGRvbid0IHRo aW5rIHdlIG5lZWQgdG8gZGVmaW5lIGFuIGVxdWl2YWxlbnQgdG8gdGhlIA0KPiAicmVnLXVyaS1h bGlhcyIgYW55bW9yZS4NCj4gSWYgRnJlZXBob25lIHdhcyBjb25maWd1cmVkIHRvIGdvIHRvICsx NDA4NTU1MTIxMiBpbnN0ZWFkIG9mIA0KPiB0aGUgcmVnaXN0ZXJlZCBDb250YWN0IChhc3N1bWlu ZyArMTQwODU1NTEyMTIgd2FzIGFuIEFsaWFzIA0KPiBBT1IgZm9yIGNhcm9sQGV4YW1wbGUubmV0 KSwgdGhlIGxhc3QgSC1JIGVudHJpZXMgd291bGQgbG9vayANCj4gbGlrZSB0aGlzIGluc3RlYWQ6 DQo+IA0KPiBleGFtcGxlLm5ldCAtPiBjYXJvbEBleGFtcGxlLm5ldA0KPiBIaXN0b3J5LUluZm86 IDxzaXA6Ym9iQGV4YW1wbGUuY29tPjtpbmRleD0xO2FvciAgICAgDQo+IEhpc3RvcnktSW5mbzog DQo+IDxzaXA6KzE0MDg1NTUxMjEyQGV4YW1wbGUubmV0O3VzZXI9cGhvbmU+O2luZGV4PTEuMTtt cDthb3IgPC0gDQo+IGFvciBpcyBhZGRlZA0KPiBIaXN0b3J5LUluZm86IDxzaXA6ZnJlZXBob25l QGV4YW1wbGUubmV0PjtpbmRleD0xLjEuMTtydDthb3IgIA0KPiA8LSBhb3IgaXMgYWRkZWQNCj4g SGlzdG9yeS1JbmZvOiA8c2lwOmNhcm9sQGV4YW1wbGUubmV0PjtpbmRleD0xLjEuMS4xO3J0O2Fv ciAgICANCj4gfSAgVHdvIGVudHJpZXMgYXJlDQo+IEhpc3RvcnktSW5mbzogPHNpcDpjYXJvbEAx OTIuMC4yLjQ+O2luZGV4PTEuMS4xLjEuMTtyYyAgICAgICAgDQo+IH0gIGFkZGVkIGF0IHNhbWUg dGltZQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiANCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lw Y29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBj b3JlDQo= From mary.barnes@nortel.com Wed Jun 17 08:03:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06F2328C29F for ; Wed, 17 Jun 2009 08:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.958 X-Spam-Level: X-Spam-Status: No, score=-3.958 tagged_above=-999 required=5 tests=[AWL=-2.159, BAYES_00=-2.599, MANGLED_LOAN=2.3, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDios0Xx7nB4 for ; Wed, 17 Jun 2009 08:03:51 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id F2FEB28C29D for ; Wed, 17 Jun 2009 08:03:46 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5HF1uH00980; Wed, 17 Jun 2009 15:01:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 10:05:43 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E8D4A32@zrc2hxm0.corp.nortel.com> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4048280DC@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt thread-index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYAAADaOvAAAEZYIAAAZd2gAAEEtLAAASSLAAAQUjFAAAQ6qeAABxuA8AAqMxcAABHp8TA= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com><1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>!<1ECE0EB50388174790F9694F77522CCF1E83DBEB@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA0375EC26@gaalpa1msgusr7e.ugd.att.com> <9886E5FCA6D76549A3011068483A4BD404827AB8@S4DE8PSAAQB.mitte.t-com.de> <9ECCF01B52E7AB408A7EB853526421412F59C6@ftrdmel0.rd.francetelecom.fr> <9886E5FCA6D76549A3011068483A4BD4048280DC@S4DE8PSAAQB.mitte.t-com.de> From: "Mary Barnes" To: , , , , "Francois Audet" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 15:03:53 -0000 Roland, If you need additional "cause" parameters, then we really should = consider extensions to the Reason header in RFC 3326. =20 Mary. -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: Wednesday, June 17, 2009 1:35 AM To: christer.holmberg@ericsson.com; bruno.chatras@orange-ftgroup.com; = mdolly@att.com; Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); = sipcore@ietf.org Subject: AW: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Is it really a complete separate discussion? In defining a parameter that is a hint that the uri was changed due to = some "magic" in a server, why not to point to some existing mechanism = and use it. Either we could mention that a drafts exisists that has the possibility = of "cause parameters" and some extensions are needed to express also = other services than CDIV. And define a additional draft for this values. Or add a section with some additional cause parameters. BR, Roland -----Urspr=FCngliche Nachricht----- Von: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Gesendet: Dienstag, 16. Juni 2009 12:31 An: bruno.chatras@orange-ftgroup.com; Jesske, Roland; mdolly@att.com; = mary.barnes@nortel.com; audet@nortel.com; sipcore@ietf.org Betreff: RE: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi, >I would go even further. There are cases where it is useful=20 >to keep track of the services invoked during the=20 >establishment of a session, irrespective of whether these=20 >services have modified the R-URI or not. To achieve this, an=20 >application server providing service X would insert an entry=20 >in the History-Info header field with hi-target=3Dnoop, an=20 >unmodified R-URI and an extended cause-param set to a value=20 >representing service "X". I think that should be a completely separate discussion. It is an interesting topic, but I think you would need to start it in = DISPATCH or BLISS, because I think it is far beyond the scope of both = 4244bis and target delivery :) Regards, Christer > -----Message d'origine----- > De : sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] De la part de=20 > R.Jesske@telekom.de Envoy=E9 : mardi 16 juin 2009 07:02 =C0 :=20 > mdolly@att.com; mary.barnes@nortel.com;=20 > christer.holmberg@ericsson.com; audet@nortel.com;=20 > sipcore@ietf.org Objet : Re: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hi, > Why not to adopt the cause-parameter principle of RFC 4458=20 > and extend it for other service approaches. > The have a general cause-param for services other then call=20 > diversion and to have explicit cause parameters for free=20 > phone, "IN-services", calling card ect. > Such indications where asked a couples of times from other=20 > service providers. >=20 > BR, >=20 > Roland=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] Im Auftrag von DOLLY,=20 > MARTIN C, ATTLABS > Gesendet: Montag, 15. Juni 2009 23:10 > An: Mary Barnes; Christer Holmberg; Francois Audet; sipcore@ietf.org > Betreff: Re: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > no >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 4:38 PM > To: Christer Holmberg; Francois Audet; DOLLY, MARTIN C,=20 > ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But, the freephone service can be implemented also with a=20 > reg-uri or reg-uri-alias - NOW if a specific service treats=20 > them the same, no big deal. The UAS then looks for any of a=20 > set of tags to grab the appropriate hi-entry.=20 >=20 > Mary. >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 3:14 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055);=20 > DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi,=20 >=20 > >But, still with this approach, I do not think you can get=20 > away with not > looking for multiple tags with the way you envision doing=20 > your services. >=20 > Maybe not - that depends on the service. But, then it will at least be > possible to figure out what has happended. >=20 > >I think there are others that will implement services on the UAS that > will not need the differentiation that you do - i.e, they=20 > care about the > difference between "reg-uri" and "reg-uri-alias". >=20 > My differentiation is based on my understanding of the=20 > requirements that > we have. >=20 > If you think we need to differentiate between req-uri and=20 > req-uri-alias, > then we should agree on such requirement. Let's not mix it with the > freephone requirement. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Monday, June 15, 2009 2:53 PM > To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY,=20 > MARTIN C, > ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Christer,=20 >=20 > On your last point, the objective here was to make use of History-Info > WITHOUT changing any core SIP functionality - it's a whole different > ballgame if we want to do the latter IMHO. However, here's the snippet > from the end of the response I just sent to Martin (summarizing the > current set of tags), which you may not read: >=20 > " So, we're debating here the differences between the "aor,mapped" and > "aor,routed" vs "predetermined", "reg-uri" and=20 > "reg-uri-alias". I think > that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed". > And, I think one could consider the "aor,mapped" as=20 > predetermined. But, > again 4244bis tags the entries entirely based on what SIP does and if > the 800 number translations (or whatever services) are setup=20 > differently > in different proxies, then you can't determine if the=20 > "aor,routed" cases > might be "reg-uri-alias" or "reg-uri". Although, I am personally > confused as to whether an 800 number would always be "aor, mapped" or > "aor, routed" - i.e., I just don't see this being deterministic and I > think that if a service can reach a UAS through different SIP > retargeting mechanisms, then the UAS needs to be aware.=20 >=20 > Also, as I'm going through this, I think we need 3 more tags=20 > if we want > the proxy to do the tagging - i.e., I think we need to add=20 > "-aor" to the > "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that the > proxy will mark in this manner. " >=20 >=20 > Mary.=20 > P.S. Also, I do not think it's a burden to put logic in the UAS - that > was the original intent for SIP - services in the endpoints - SIP is > just the signalling to carry the relevant information. But, I can see > that since the sort of service you mention that does not have=20 > a standard > SIP URI (i.e., user@domain) introduces something that isn't=20 > accomodated > in the basic SIP model, so we may need to add additional logic to the > proxies (I don't like it though).=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 2:34 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi,=20 >=20 > >Correct. But, what I am suggesting is that you distinguish it at the > UAS > >- I'm assuming that the target Request-URI that arrives at the UAS is > something that identifies a client that handles 800 numbers. That > client could be configured such that it knows to look for the=20 > >original 800 number in the mapped URIs or in the reg-alias-URIs or > both.=20 >=20 > 800 numbers is just one example.=20 >=20 > Why should the UAS have to be configured with this information??? I > think that is very limiting and unpractical. >=20 > >Again, if you're making these 800 numbers special and=20 > allowing proxies > to change them in multiple ways (i.e., non-deterministic), then if you > want them tagged special, then you need special logic in the=20 > >proxies to do this. >=20 > The logic is that the AOR is replaced with another AOR, which=20 > belongs to > the same user.=20 >=20 > It's not only for 800 numbers - they are just an example=20 > where it would > be useful. >=20 > And, the proxy is configured to do this - it doesn't do it because it > "thinks" it has to do it :) >=20 > >That doesn't make sense to me, although you could do it that way in a > closed network, in which case you can make sure to always tag them as > whatever you think they should be - so we could define an=20 > >additional value for the tag. But, this is what I don't=20 > think is right > in terms of normal SIP request routing and forwarding, which=20 > is what the > current 4244bis tags have been defined to represent.=20 >=20 > I really don't understand wht this "normal SIP request routing and > forwarding" is all about. Normal SIP request routing and=20 > forwarding has > issues, which were presented in the ua-loose-route draft - and that is > why we are now working on a solution to solve those issues. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 1:23 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi Mary, >=20 > Proxies will tag entries based on the functionality they perform. >=20 > Let's leave req-uri-alias for the moment. >=20 > As I said earlier, one of the issues we have with 4244bis, is that > "mapped" seems to be used BOTH for diversion and when an AOR=20 > is replaced > with another AOR pointing to the same user - e.g. freephone. So, it is > not possible to distinguish between diversion and freephone. >=20 > We think one MUST be able to make that distinguishment,=20 > because you may > have cases where both diversion and service number translation (e.g. > freephone) occurs, and the UAS needs to know which is which. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > =20 >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 9:13 PM > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > It seems to me that the gist of this discussion has been based on the > expectation that independent of how the 800 number is configured, > registered or whatever at a proxy, that there is an expectation of > deterministic behavior in terms of how it's tagged. So, if=20 > 800 numbers > are special and they can end up tagged as either reg-uri-alias or as > mapped, then perhaps the service has to know that it needs to look for > either of those. ISTM that if there is a reason to preserve=20 > that it's an > 800 number (i.e., and not format as a service specific uri),=20 > the service > at the UAS knows that it's special, thus it would need to check the > request-URIs associated with both reg-uri-alias and mapped hi-entries. > I can't see how we can make it work any other way without being > prescriptive of how proxy's MUST tag these entries, which is=20 > not a good > idea IMHO. However, I think these numbers are either special cases at > proxies or something that services know about.=20 >=20 > Mary.=20 >=20 > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 12:47 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary > (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Yes, we need to sort out what to do for that.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, June 15, 2009 10:17 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 > >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, June 15, 2009 6:50 PM > > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > > sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > then reg-uri-alias.=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Saturday, June 13, 2009 01:22 > > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C,=20 > ATTLABS; Barnes,=20 > > > Mary (RICH2:AR00); sipcore@ietf.org > > > Subject: RE: [sipcore] FW: I-D > > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > >=20 > > >=20 > > > Hi, > > >=20 > > > >1) RFC 4244bis > > > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > > Request-URI and it replacing it with a Contact, it will put > > a reg-uri > > > flag (if the Request-URI was the AOR used for=20 > registration), or reg- > > > >uri-alias (if the Request-URI was an alias for the AOR used in > > > registration). > > >=20 > > > And if the Request-URI was a "synonym" for the AOR? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From mary.barnes@nortel.com Wed Jun 17 08:08:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 148DF28C289 for ; Wed, 17 Jun 2009 08:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.323 X-Spam-Level: X-Spam-Status: No, score=-6.323 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSOZaI3+8+Op for ; Wed, 17 Jun 2009 08:08:25 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id A85AE28C248 for ; Wed, 17 Jun 2009 08:08:25 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5HF6sH01984; Wed, 17 Jun 2009 15:06:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 10:10:16 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E8D4A5D@zrc2hxm0.corp.nortel.com> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD40482809F@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri thread-index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAEsEiwAAY2eFwABpznoAAEyhgAA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>!! ! ! ! ! <4A36A C9C.3 060509@ gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404827ACF@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1E88E0FE@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD40482809F@S4DE8PSAAQB.mitte.t-com.de> From: "Mary Barnes" To: , "Francois Audet" , , , Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 15:08:27 -0000 Roland, There is still room in the document for the the functionality you = mention in section 3.2: Thus, local policy MAY also be used to determine whether to include = the History-Info header at all, whether to capture a specific Request-URI in the header as is, whether it be included only in the Request as it is retargeted within a specific domain, or whether it is anonymized when being retargeted outside a specific domain (PRIV-req-3). The latter two cases can be accomplished with a new priv-value, history, added to the Privacy header [RFC3323]. The details as to the use of the new priv-value with the Privacy header are provided in section Section 4. Mary.=20 -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: Wednesday, June 17, 2009 1:01 AM To: Audet, Francois (SC100:3055); christer.holmberg@ericsson.com; = ietf.hanserik@gmail.com; Barnes, Mary (RICH2:AR00); shida@agnada.com Cc: sipcore@ietf.org Subject: AW: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri I have slide concerns with that approach. Some network operators does = not like to present all the way of messages. Even if the entry is anonymous the amount of entries will show the = network structure which could also raise security concerns. BR, Roland=20 -----Urspr=FCngliche Nachricht----- Von: Francois Audet [mailto:audet@nortel.com] Gesendet: Dienstag, 16. Juni 2009 19:22 An: Jesske, Roland; christer.holmberg@ericsson.com; = ietf.hanserik@gmail.com; Mary Barnes; shida@agnada.com Cc: sipcore@ietf.org Betreff: RE: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri In the new draft, the entries are always there and never removed. It = makes HI much more reliable. If entries need to be anonymous, they are anonymized but the entry is = still there.=20 > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: Monday, June 15, 2009 22:38 > To: Audet, Francois (SC100:3055); > christer.holmberg@ericsson.com; ietf.hanserik@gmail.com; Barnes, Mary=20 > (RICH2:AR00); shida@agnada.com > Cc: sipcore@ietf.org > Subject: AW: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Such values looks good and gives more guideline why the entry was=20 > included. > My question would be if there is a different network behaviour=20 > foreseen for the History mechanism. > Perhaps some of the networks needs the history only to indicate where=20 > the URI were mapped ("mp") and others would really track the whole=20 > history of each SIP proxy. > Or is it only seen either to support history full or not. >=20 > BR, >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Francois Audet > Gesendet: Dienstag, 16. Juni 2009 03:44 > An: Christer Holmberg; Hans Erik van Elburg; Mary Barnes; Shida=20 > Schubert > Cc: sipcore@ietf.org > Betreff: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >=20 > All right guys, >=20 > I've been thinking about this. >=20 > It seems to me that what we want to capture is: > 1) If the target is an AOR, a contact, or a routing URI (maddr, noop=20 > intra-domain, or noop > forward to next domain, or strict routing). > 2) In the case that the target is an AOR, then if that AOR is known to = > be an alias for the previous > one, or if it is mapped to another AOR. >=20 > It seems to me that a Proxy should mark a Previous entry in H-I with=20 > aor if it determines that it owns this AOR. Just as Hans's current=20 > target-uri draft. >=20 > Now, for the mapped vs routed (versus reg-contact, etc.), instead of=20 > marking the Previous entry, we should mark the OUTGOING (i.e., New)=20 > entry instead. This would make the procedures of > 7.2.1 & 7.2.2 of target-URI draft clearer. >=20 > Specifically, the logic would be: >=20 > When proxy receives an incoming request with H-I, it adds an ;aor tag=20 > to that incoming entry if it determines that it is responsible for the = > AOR and. >=20 > Also, if there was no Hi-entry at all (i.e., it came from a UAC), and=20 > the Proxy creates then two entries, the first one in this case would=20 > also have the ;aor tag associated to it. >=20 > For the Outgoing entry, I would see the following tags: >=20 > rc : The entry is an explicit registered contact=20 > (i.e., it was provided in a REGISTER message) >=20 > ic : The entry is an implicit registered contact=20 > (i.e., it's exactly as a registered contact, > but was not discovered using SIP Registration:=20 > it could have been manually configured > or done with a proprietary mechanism). >=20 > (TBD: we could debate if we need both rc and irc, but I think we=20 > do). >=20 > mp : The request-URI is changed to a new URI that=20 > represent another user. >=20 > rt : The entry is "routed", i.e., it is either a=20 > no-opt like a proxy forwarding within > a domain, predetermined by a maddr in the Request-URI, or when proxy = > is NOT responsible > for domain, or the address is an alias for the incoming URI. >=20 > So, to give an example.=20 >=20 > Say Alice calls Bob. Bob is forwarded to freephone. Freephone routes=20 > to Carol. >=20 > The History-info at Carol would look like this: >=20 > Alice -> example.com > Nothing because UAC typically doesn't send H-I (otherwise, it would be = > as per Index 1 in next entry, but without the AOR. >=20 > example.com -> freephone@example.net > History-Info: ;index=3D1;aor > History-Info: ;index=3D1.1;mp >=20 > example.net -> carol@example.net > History-Info: ;index=3D1;aor =20 > History-Info: ;index=3D1.1;mp;aor > <- aor is added > History-Info: ;index=3D1.1.1;rt;aor }=20 > Two entries are > History-Info: ;index=3D1.1.1.1;rc }=20 > added at same time >=20 > Also, I don't think we need to define an equivalent to the=20 > "reg-uri-alias" anymore. > If Freephone was configured to go to +14085551212 instead of the=20 > registered Contact (assuming +14085551212 was an Alias AOR for=20 > carol@example.net), the last H-I entries would look like this instead: >=20 > example.net -> carol@example.net > History-Info: ;index=3D1;aor =20 > History-Info:=20 > ;index=3D1.1;mp;aor <- aor = is=20 > added > History-Info: ;index=3D1.1.1;rt;aor > <- aor is added > History-Info: ;index=3D1.1.1.1;rt;aor =20 > } Two entries are > History-Info: ;index=3D1.1.1.1.1;rc =20 > } added at same time > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From AUDET@nortel.com Wed Jun 17 08:50:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE82A28B56A for ; Wed, 17 Jun 2009 08:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfxhEXw9Y8Cj for ; Wed, 17 Jun 2009 08:50:24 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 5BE6428C278 for ; Wed, 17 Jun 2009 08:50:24 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5HFn4H09619; Wed, 17 Jun 2009 15:49:04 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EF63.52DAB8F4" Date: Wed, 17 Jun 2009 10:50:21 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E8D4BE7@zrc2hxm0.corp.nortel.com> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4048280C5@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis hi-target backward compatibility thread-index: AcnvE4qiHqhqwuOSRCy0RfDddNC8CwAT6aDA References: <9886E5FCA6D76549A3011068483A4BD4048280C5@S4DE8PSAAQB.mitte.t-com.de> From: "Francois Audet" To: , , , "Mary Barnes" , Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis hi-target backward compatibility X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 15:50:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EF63.52DAB8F4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All the HI entries will be marked in the new mechanism. =20 The old ones won't. =20 So entities that inspect them will be able to distinguish between them. ________________________________ From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: Tuesday, June 16, 2009 23:19 To: Audet, Francois (SC100:3055); christer.holmberg@ericsson.com; = ietf.hanserik@gmail.com; Barnes, Mary (RICH2:AR00); shida@agnada.com Cc: sipcore@ietf.org Subject: [sipcore] draft-barnes-sipcore-rfc4244bis hi-target backward = compatibility =09 =09 Dear all,=20 I saw that the hi-target is a mandatory parameter now.=20 How a can now assure backward compatibility to the "old" History = header. Due to the fact that the old one is already implemented within = some networks? BR,=20 =09 Roland=20 Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Roland Jesske Gateways, Protokolle, Konvergenz, TE32-1 Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Postfach, 64307 Darmstadt (Postanschrift) +496151 628 2766 (Tel) +491718618445 (Mobile) E-Mail: r.jesske@telekom.de =20 http://www.telekom.de =20 Registerrechtliche Unternehmensangaben:=20 Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Friedrich Fu=DF (Vorsitzender), Albert Matheis, = Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262=20 ------_=_NextPart_001_01C9EF63.52DAB8F4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [sipcore] draft-barnes-sipcore-rfc4244bis hi-target = backward compatibility
All=20 the HI entries will be marked in the new mechanism.
 
The=20 old ones won't.
 
So=20 entities that inspect them will be able to distinguish between=20 them.

From: R.Jesske@telekom.de=20 [mailto:R.Jesske@telekom.de]
Sent: Tuesday, June 16, 2009=20 23:19
To: Audet, Francois (SC100:3055);=20 christer.holmberg@ericsson.com; ietf.hanserik@gmail.com; Barnes, Mary=20 (RICH2:AR00); shida@agnada.com
Cc:=20 sipcore@ietf.org
Subject: [sipcore] = draft-barnes-sipcore-rfc4244bis=20 hi-target backward compatibility

Dear all,
I saw=20 that the hi-target is a mandatory parameter now.
How a can now assure backward compatibility to the "old" = History=20 header. Due to the fact that the old one is already implemented within = some=20 networks?

BR,

Roland

Deutsche Telekom = Netzproduktion=20 GmbH
Zentrum Technik Einf=FChrung
Roland=20 Jesske
Gateways, Protokolle, Konvergenz, TE32-1
Heinrich-Hertz-Str. 3-7, 64295 Darmstadt,
Postfach, 64307 Darmstadt (Postanschrift)
+496151 628 2766=20 (Tel)
+491718618445 = (Mobile)
E-Mail: r.jesske@telekom.de=20
http://www.telekom.de



Registerrechtliche=20 Unternehmensangaben: =
Deutsche Telekom Netzproduktion = GmbH
Aufsichtsrat:=20 Timotheus H=F6ttges (Vorsitzender)
Gesch=E4ftsf=FChrung: Friedrich = Fu=DF=20 (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: = Amtsgericht=20 Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE=20 814645262


------_=_NextPart_001_01C9EF63.52DAB8F4-- From AUDET@nortel.com Wed Jun 17 08:51:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1FD3A6BED for ; Wed, 17 Jun 2009 08:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.345 X-Spam-Level: X-Spam-Status: No, score=-6.345 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEnCzZr7oBAf for ; Wed, 17 Jun 2009 08:51:48 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E6C8528C2B2 for ; Wed, 17 Jun 2009 08:51:41 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5HFoNH09818; Wed, 17 Jun 2009 15:50:24 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EF63.78F6CF8C" Date: Wed, 17 Jun 2009 10:51:26 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E8D4BF5@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis hi-target backward compatibility thread-index: AcnvE4qiHqhqwuOSRCy0RfDddNC8CwABzi8wABIqVlA= References: <9886E5FCA6D76549A3011068483A4BD4048280C5@S4DE8PSAAQB.mitte.t-com.de> From: "Francois Audet" To: "Christer Holmberg" , , , "Mary Barnes" , Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis hi-target backward compatibility X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 15:51:49 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EF63.78F6CF8C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Correct.=20 =20 I think we should add a section on backward compatibility. ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Wednesday, June 17, 2009 00:12 To: R.Jesske@telekom.de; Audet, Francois (SC100:3055); = ietf.hanserik@gmail.com; Barnes, Mary (RICH2:AR00); shida@agnada.com Cc: sipcore@ietf.org Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis hi-target = backward compatibility =09 =09 Hi Roland, =20 I think the meaning is that new, 4244bis compliant entities, would = insert hi-target. But, I agree with you that things must be backward = compatible, so a missing parameter must not be seen as an error. =20 Regards, =20 Christer ________________________________ From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: 17. kes=E4kuuta 2009 9:19 To: audet@nortel.com; Christer Holmberg; ietf.hanserik@gmail.com; = mary.barnes@nortel.com; shida@agnada.com Cc: sipcore@ietf.org Subject: [sipcore] draft-barnes-sipcore-rfc4244bis hi-target backward = compatibility =09 =09 Dear all,=20 I saw that the hi-target is a mandatory parameter now.=20 How a can now assure backward compatibility to the "old" History = header. Due to the fact that the old one is already implemented within = some networks? BR,=20 =09 Roland=20 Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Roland Jesske Gateways, Protokolle, Konvergenz, TE32-1 Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Postfach, 64307 Darmstadt (Postanschrift) +496151 628 2766 (Tel) +491718618445 (Mobile) E-Mail: r.jesske@telekom.de =20 http://www.telekom.de =20 Registerrechtliche Unternehmensangaben:=20 Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Friedrich Fu=DF (Vorsitzender), Albert Matheis, = Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262=20 ------_=_NextPart_001_01C9EF63.78F6CF8C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [sipcore] draft-barnes-sipcore-rfc4244bis hi-target = backward compatibility
Correct.
 
I=20 think we should add a section on backward = compatibility.

From: Christer Holmberg=20 [mailto:christer.holmberg@ericsson.com]
Sent: Wednesday, = June 17,=20 2009 00:12
To: R.Jesske@telekom.de; Audet, Francois = (SC100:3055);=20 ietf.hanserik@gmail.com; Barnes, Mary (RICH2:AR00);=20 shida@agnada.com
Cc: sipcore@ietf.org
Subject: RE: = [sipcore] draft-barnes-sipcore-rfc4244bis hi-target backward=20 compatibility

Hi Roland,
 
I think the meaning is that new, 4244bis = compliant=20 entities, would insert hi-target. But, I agree with you that things = must be=20 backward compatible, so a missing parameter must not be seen as an=20 error.
 
Regards,
 
Christer

From: R.Jesske@telekom.de=20 [mailto:R.Jesske@telekom.de]
Sent: 17. kes=E4kuuta 2009=20 9:19
To: audet@nortel.com; Christer Holmberg;=20 ietf.hanserik@gmail.com; mary.barnes@nortel.com;=20 shida@agnada.com
Cc: sipcore@ietf.org
Subject: = [sipcore]=20 draft-barnes-sipcore-rfc4244bis hi-target backward=20 compatibility

Dear all,
I=20 saw that the hi-target is a mandatory parameter now. =
How a can now assure backward compatibility to = the "old"=20 History header. Due to the fact that the old one is already = implemented=20 within some networks?

BR,

Roland

Deutsche Telekom = Netzproduktion=20 GmbH
Zentrum Technik Einf=FChrung
Roland=20 Jesske
Gateways, Protokolle, Konvergenz, TE32-1
Heinrich-Hertz-Str. 3-7, 64295 Darmstadt,
Postfach, 64307 Darmstadt (Postanschrift)
+496151 628 2766=20 (Tel)
+491718618445 = (Mobile)
E-Mail: r.jesske@telekom.de=20
http://www.telekom.de



Registerrechtliche=20 Unternehmensangaben: =
Deutsche Telekom Netzproduktion = GmbH
Aufsichtsrat:=20 Timotheus H=F6ttges (Vorsitzender)
Gesch=E4ftsf=FChrung: = Friedrich Fu=DF=20 (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: = Amtsgericht=20 Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE=20 814645262


------_=_NextPart_001_01C9EF63.78F6CF8C-- From AUDET@nortel.com Wed Jun 17 08:51:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 703D33A6AE5 for ; Wed, 17 Jun 2009 08:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.355 X-Spam-Level: X-Spam-Status: No, score=-6.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKrXx3DbwbVh for ; Wed, 17 Jun 2009 08:51:49 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id D91103A6A97 for ; Wed, 17 Jun 2009 08:51:44 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5HFpmY20529; Wed, 17 Jun 2009 15:51:48 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 10:51:46 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E8D4BFC@zrc2hxm0.corp.nortel.com> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD40482809F@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri thread-index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAEsEiwAAY2eFwABpznoAAFJZoQA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>!! ! ! ! ! <4A36A C9C.3 060509@ gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404827ACF@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1E88E0FE@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD40482809F@S4DE8PSAAQB.mitte.t-com.de> From: "Francois Audet" To: , , , "Mary Barnes" , Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 15:51:50 -0000 This is no different than Via headers. If the network decides to "remove" headers, then it's free to do it. The consequences however are worst for History-Info than for Via because then you can break services. This was even described in "old" 4244. > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 > Sent: Tuesday, June 16, 2009 23:01 > To: Audet, Francois (SC100:3055);=20 > christer.holmberg@ericsson.com; ietf.hanserik@gmail.com;=20 > Barnes, Mary (RICH2:AR00); shida@agnada.com > Cc: sipcore@ietf.org > Subject: AW: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >=20 > I have slide concerns with that approach. Some network=20 > operators does not like to present all the way of messages. > Even if the entry is anonymous the amount of entries will=20 > show the network structure which could also raise security concerns. >=20 > BR, Roland=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Francois Audet [mailto:audet@nortel.com] > Gesendet: Dienstag, 16. Juni 2009 19:22 > An: Jesske, Roland; christer.holmberg@ericsson.com;=20 > ietf.hanserik@gmail.com; Mary Barnes; shida@agnada.com > Cc: sipcore@ietf.org > Betreff: RE: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >=20 > In the new draft, the entries are always there and never=20 > removed. It makes HI much more reliable. >=20 > If entries need to be anonymous, they are anonymized but the=20 > entry is still there.=20 >=20 > > -----Original Message----- > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > > Sent: Monday, June 15, 2009 22:38 > > To: Audet, Francois (SC100:3055); > > christer.holmberg@ericsson.com; ietf.hanserik@gmail.com;=20 > Barnes, Mary=20 > > (RICH2:AR00); shida@agnada.com > > Cc: sipcore@ietf.org > > Subject: AW: [sipcore] draft-barnes-sipcore-rfc4244bis and=20 > target-uri > >=20 > > Such values looks good and gives more guideline why the entry was=20 > > included. > > My question would be if there is a different network behaviour=20 > > foreseen for the History mechanism. > > Perhaps some of the networks needs the history only to=20 > indicate where=20 > > the URI were mapped ("mp") and others would really track the whole=20 > > history of each SIP proxy. > > Or is it only seen either to support history full or not. > >=20 > > BR, > >=20 > > Roland > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Francois Audet > > Gesendet: Dienstag, 16. Juni 2009 03:44 > > An: Christer Holmberg; Hans Erik van Elburg; Mary Barnes; Shida=20 > > Schubert > > Cc: sipcore@ietf.org > > Betreff: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri > >=20 > > All right guys, > >=20 > > I've been thinking about this. > >=20 > > It seems to me that what we want to capture is: > > 1) If the target is an AOR, a contact, or a routing URI=20 > (maddr, noop=20 > > intra-domain, or noop > > forward to next domain, or strict routing). > > 2) In the case that the target is an AOR, then if that AOR=20 > is known to=20 > > be an alias for the previous > > one, or if it is mapped to another AOR. > >=20 > > It seems to me that a Proxy should mark a Previous entry in=20 > H-I with=20 > > aor if it determines that it owns this AOR. Just as Hans's current=20 > > target-uri draft. > >=20 > > Now, for the mapped vs routed (versus reg-contact, etc.),=20 > instead of=20 > > marking the Previous entry, we should mark the OUTGOING (i.e., New)=20 > > entry instead. This would make the procedures of > > 7.2.1 & 7.2.2 of target-URI draft clearer. > >=20 > > Specifically, the logic would be: > >=20 > > When proxy receives an incoming request with H-I, it adds=20 > an ;aor tag=20 > > to that incoming entry if it determines that it is=20 > responsible for the=20 > > AOR and. > >=20 > > Also, if there was no Hi-entry at all (i.e., it came from a=20 > UAC), and=20 > > the Proxy creates then two entries, the first one in this=20 > case would=20 > > also have the ;aor tag associated to it. > >=20 > > For the Outgoing entry, I would see the following tags: > >=20 > > rc : The entry is an explicit registered contact=20 > > (i.e., it was provided in a REGISTER message) > >=20 > > ic : The entry is an implicit registered contact=20 > > (i.e., it's exactly as a registered contact, > > but was not discovered using SIP Registration:=20 > > it could have been manually configured > > or done with a proprietary mechanism). > >=20 > > (TBD: we could debate if we need both rc and=20 > irc, but I think we=20 > > do). > >=20 > > mp : The request-URI is changed to a new URI that=20 > > represent another user. > >=20 > > rt : The entry is "routed", i.e., it is either a=20 > > no-opt like a proxy forwarding within > > a domain, predetermined by a maddr in the=20 > Request-URI, or when proxy=20 > > is NOT responsible > > for domain, or the address is an alias for the=20 > incoming URI. > >=20 > > So, to give an example.=20 > >=20 > > Say Alice calls Bob. Bob is forwarded to freephone.=20 > Freephone routes=20 > > to Carol. > >=20 > > The History-info at Carol would look like this: > >=20 > > Alice -> example.com > > Nothing because UAC typically doesn't send H-I (otherwise,=20 > it would be=20 > > as per Index 1 in next entry, but without the AOR. > >=20 > > example.com -> freephone@example.net > > History-Info: ;index=3D1;aor > > History-Info: ;index=3D1.1;mp > >=20 > > example.net -> carol@example.net > > History-Info: ;index=3D1;aor =20 > > History-Info: ;index=3D1.1;mp;aor > > <- aor is added > > History-Info: ;index=3D1.1.1;rt;aor }=20 > > Two entries are > > History-Info: ;index=3D1.1.1.1;rc }=20 > > added at same time > >=20 > > Also, I don't think we need to define an equivalent to the=20 > > "reg-uri-alias" anymore. > > If Freephone was configured to go to +14085551212 instead of the=20 > > registered Contact (assuming +14085551212 was an Alias AOR for=20 > > carol@example.net), the last H-I entries would look like=20 > this instead: > >=20 > > example.net -> carol@example.net > > History-Info: ;index=3D1;aor =20 > > History-Info:=20 > > ;index=3D1.1;mp;aor=20 > <- aor is=20 > > added > > History-Info: ;index=3D1.1.1;rt;aor > > <- aor is added > > History-Info: ;index=3D1.1.1.1;rt;aor =20 > > } Two entries are > > History-Info: ;index=3D1.1.1.1.1;rc =20 > > } added at same time > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 >=20 From mary.barnes@nortel.com Wed Jun 17 08:58:23 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4AD13A6E4E for ; Wed, 17 Jun 2009 08:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.327 X-Spam-Level: X-Spam-Status: No, score=-6.327 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5huLvLEPUyD for ; Wed, 17 Jun 2009 08:58:22 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 6B8293A6C3C for ; Wed, 17 Jun 2009 08:58:22 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5HFwRY22326; Wed, 17 Jun 2009 15:58:27 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EF64.3951C8B8" Date: Wed, 17 Jun 2009 10:59:20 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E8D4C3C@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E8D4BF5@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis hi-target backward compatibility thread-index: AcnvE4qiHqhqwuOSRCy0RfDddNC8CwABzi8wABIqVlAAAEL5gA== References: <9886E5FCA6D76549A3011068483A4BD4048280C5@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1E8D4BF5@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Francois Audet" , "Christer Holmberg" , , , Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis hi-target backward compatibility X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 15:58:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EF64.3951C8B8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, we already need to add a section on the differences between 4244 = and 4244bis, so we can include this as part of that section.=20 =20 Mary. ________________________________ From: Audet, Francois (SC100:3055)=20 Sent: Wednesday, June 17, 2009 10:51 AM To: Christer Holmberg; R.Jesske@telekom.de; ietf.hanserik@gmail.com; = Barnes, Mary (RICH2:AR00); shida@agnada.com Cc: sipcore@ietf.org Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis hi-target = backward compatibility Correct.=20 =20 I think we should add a section on backward compatibility. ________________________________ From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Wednesday, June 17, 2009 00:12 To: R.Jesske@telekom.de; Audet, Francois (SC100:3055); = ietf.hanserik@gmail.com; Barnes, Mary (RICH2:AR00); shida@agnada.com Cc: sipcore@ietf.org Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis hi-target = backward compatibility =09 =09 Hi Roland, =20 I think the meaning is that new, 4244bis compliant entities, would = insert hi-target. But, I agree with you that things must be backward = compatible, so a missing parameter must not be seen as an error. =20 Regards, =20 Christer ________________________________ From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: 17. kes=E4kuuta 2009 9:19 To: audet@nortel.com; Christer Holmberg; ietf.hanserik@gmail.com; = mary.barnes@nortel.com; shida@agnada.com Cc: sipcore@ietf.org Subject: [sipcore] draft-barnes-sipcore-rfc4244bis hi-target backward = compatibility =09 =09 Dear all,=20 I saw that the hi-target is a mandatory parameter now.=20 How a can now assure backward compatibility to the "old" History = header. Due to the fact that the old one is already implemented within = some networks? BR,=20 =09 Roland=20 Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Roland Jesske Gateways, Protokolle, Konvergenz, TE32-1 Heinrich-Hertz-Str. 3-7, 64295 Darmstadt, Postfach, 64307 Darmstadt (Postanschrift) +496151 628 2766 (Tel) +491718618445 (Mobile) E-Mail: r.jesske@telekom.de =20 http://www.telekom.de =20 Registerrechtliche Unternehmensangaben:=20 Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Friedrich Fu=DF (Vorsitzender), Albert Matheis, = Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262=20 ------_=_NextPart_001_01C9EF64.3951C8B8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [sipcore] draft-barnes-sipcore-rfc4244bis hi-target = backward compatibility
Yes,=20 we already need to add a section on the differences between 4244 and = 4244bis, so=20 we can include this as part of that section.
 
Mary.

From: Audet, Francois (SC100:3055)=20
Sent: Wednesday, June 17, 2009 10:51 AM
To: = Christer=20 Holmberg; R.Jesske@telekom.de; ietf.hanserik@gmail.com; Barnes, Mary=20 (RICH2:AR00); shida@agnada.com
Cc: = sipcore@ietf.org
Subject:=20 RE: [sipcore] draft-barnes-sipcore-rfc4244bis hi-target backward=20 compatibility

Correct.
 
I=20 think we should add a section on backward = compatibility.

From: Christer Holmberg=20 [mailto:christer.holmberg@ericsson.com]
Sent: Wednesday, = June 17,=20 2009 00:12
To: R.Jesske@telekom.de; Audet, Francois = (SC100:3055);=20 ietf.hanserik@gmail.com; Barnes, Mary (RICH2:AR00);=20 shida@agnada.com
Cc: sipcore@ietf.org
Subject: RE: = [sipcore] draft-barnes-sipcore-rfc4244bis hi-target backward=20 compatibility

Hi Roland,
 
I think the meaning is that new, 4244bis = compliant=20 entities, would insert hi-target. But, I agree with you that things = must be=20 backward compatible, so a missing parameter must not be seen as an=20 error.
 
Regards,
 
Christer

From: R.Jesske@telekom.de=20 [mailto:R.Jesske@telekom.de]
Sent: 17. kes=E4kuuta 2009=20 9:19
To: audet@nortel.com; Christer Holmberg;=20 ietf.hanserik@gmail.com; mary.barnes@nortel.com;=20 shida@agnada.com
Cc: sipcore@ietf.org
Subject: = [sipcore]=20 draft-barnes-sipcore-rfc4244bis hi-target backward=20 compatibility

Dear all,
I=20 saw that the hi-target is a mandatory parameter now. =
How a can now assure backward compatibility to = the "old"=20 History header. Due to the fact that the old one is already = implemented=20 within some networks?

BR,

Roland

Deutsche Telekom = Netzproduktion=20 GmbH
Zentrum Technik Einf=FChrung
Roland=20 Jesske
Gateways, Protokolle, Konvergenz, TE32-1
Heinrich-Hertz-Str. 3-7, 64295 Darmstadt,
Postfach, 64307 Darmstadt (Postanschrift)
+496151 628 2766=20 (Tel)
+491718618445 = (Mobile)
E-Mail: r.jesske@telekom.de=20
http://www.telekom.de



Registerrechtliche=20 Unternehmensangaben: =
Deutsche Telekom Netzproduktion = GmbH
Aufsichtsrat:=20 Timotheus H=F6ttges (Vorsitzender)
Gesch=E4ftsf=FChrung: = Friedrich Fu=DF=20 (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: = Amtsgericht=20 Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE=20 814645262


------_=_NextPart_001_01C9EF64.3951C8B8-- From R.Jesske@telekom.de Thu Jun 18 03:15:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE35228C0F5 for ; Thu, 18 Jun 2009 03:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_LOAN=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCrVSSbaKPqv for ; Thu, 18 Jun 2009 03:15:18 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 2E9A63A68CF for ; Thu, 18 Jun 2009 03:15:17 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 18 Jun 2009 12:15:18 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Jun 2009 12:15:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jun 2009 12:15:39 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD4048288A5@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E8D4A5D@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: Acnt9nhjVyPJvow2Sfq6DWylBeC0jwAAFiegAABiZFAAEsEiwAAY2eFwABpznoAAEyhgAAAoHQkw References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com> <1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>!! ! ! ! ! <4A36A C9C .3060509@ gmail.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD404827ACF@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1E88E0FE@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD40482809F@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1E8D4A5D@zrc2hxm0.corp.nortel.com> From: To: , , , , X-OriginalArrivalTime: 18 Jun 2009 10:15:18.0271 (UTC) FILETIME=[AE0E58F0:01C9EFFD] Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 10:15:20 -0000 OK agreed, Thanks for clarification.=20 Roland -----Urspr=FCngliche Nachricht----- Von: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Gesendet: Mittwoch, 17. Juni 2009 17:10 An: Jesske, Roland; Francois Audet; christer.holmberg@ericsson.com; = ietf.hanserik@gmail.com; shida@agnada.com Cc: sipcore@ietf.org Betreff: RE: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Roland, There is still room in the document for the the functionality you = mention in section 3.2: Thus, local policy MAY also be used to determine whether to include = the History-Info header at all, whether to capture a specific Request-URI in the header as is, whether it be included only in the Request as it is retargeted within a specific domain, or whether it is anonymized when being retargeted outside a specific domain (PRIV-req-3). The latter two cases can be accomplished with a new priv-value, history, added to the Privacy header [RFC3323]. The details as to the use of the new priv-value with the Privacy header are provided in section Section 4. Mary.=20 -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: Wednesday, June 17, 2009 1:01 AM To: Audet, Francois (SC100:3055); christer.holmberg@ericsson.com; = ietf.hanserik@gmail.com; Barnes, Mary (RICH2:AR00); shida@agnada.com Cc: sipcore@ietf.org Subject: AW: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri I have slide concerns with that approach. Some network operators does = not like to present all the way of messages. Even if the entry is anonymous the amount of entries will show the = network structure which could also raise security concerns. BR, Roland=20 -----Urspr=FCngliche Nachricht----- Von: Francois Audet [mailto:audet@nortel.com] Gesendet: Dienstag, 16. Juni 2009 19:22 An: Jesske, Roland; christer.holmberg@ericsson.com; = ietf.hanserik@gmail.com; Mary Barnes; shida@agnada.com Cc: sipcore@ietf.org Betreff: RE: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri In the new draft, the entries are always there and never removed. It = makes HI much more reliable. If entries need to be anonymous, they are anonymized but the entry is = still there.=20 > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: Monday, June 15, 2009 22:38 > To: Audet, Francois (SC100:3055); > christer.holmberg@ericsson.com; ietf.hanserik@gmail.com; Barnes, Mary=20 > (RICH2:AR00); shida@agnada.com > Cc: sipcore@ietf.org > Subject: AW: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >=20 > Such values looks good and gives more guideline why the entry was=20 > included. > My question would be if there is a different network behaviour=20 > foreseen for the History mechanism. > Perhaps some of the networks needs the history only to indicate where=20 > the URI were mapped ("mp") and others would really track the whole=20 > history of each SIP proxy. > Or is it only seen either to support history full or not. >=20 > BR, >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Francois Audet > Gesendet: Dienstag, 16. Juni 2009 03:44 > An: Christer Holmberg; Hans Erik van Elburg; Mary Barnes; Shida=20 > Schubert > Cc: sipcore@ietf.org > Betreff: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >=20 > All right guys, >=20 > I've been thinking about this. >=20 > It seems to me that what we want to capture is: > 1) If the target is an AOR, a contact, or a routing URI (maddr, noop=20 > intra-domain, or noop > forward to next domain, or strict routing). > 2) In the case that the target is an AOR, then if that AOR is known to = > be an alias for the previous > one, or if it is mapped to another AOR. >=20 > It seems to me that a Proxy should mark a Previous entry in H-I with=20 > aor if it determines that it owns this AOR. Just as Hans's current=20 > target-uri draft. >=20 > Now, for the mapped vs routed (versus reg-contact, etc.), instead of=20 > marking the Previous entry, we should mark the OUTGOING (i.e., New)=20 > entry instead. This would make the procedures of > 7.2.1 & 7.2.2 of target-URI draft clearer. >=20 > Specifically, the logic would be: >=20 > When proxy receives an incoming request with H-I, it adds an ;aor tag=20 > to that incoming entry if it determines that it is responsible for the = > AOR and. >=20 > Also, if there was no Hi-entry at all (i.e., it came from a UAC), and=20 > the Proxy creates then two entries, the first one in this case would=20 > also have the ;aor tag associated to it. >=20 > For the Outgoing entry, I would see the following tags: >=20 > rc : The entry is an explicit registered contact=20 > (i.e., it was provided in a REGISTER message) >=20 > ic : The entry is an implicit registered contact=20 > (i.e., it's exactly as a registered contact, > but was not discovered using SIP Registration:=20 > it could have been manually configured > or done with a proprietary mechanism). >=20 > (TBD: we could debate if we need both rc and irc, but I think we=20 > do). >=20 > mp : The request-URI is changed to a new URI that=20 > represent another user. >=20 > rt : The entry is "routed", i.e., it is either a=20 > no-opt like a proxy forwarding within > a domain, predetermined by a maddr in the Request-URI, or when proxy = > is NOT responsible > for domain, or the address is an alias for the incoming URI. >=20 > So, to give an example.=20 >=20 > Say Alice calls Bob. Bob is forwarded to freephone. Freephone routes=20 > to Carol. >=20 > The History-info at Carol would look like this: >=20 > Alice -> example.com > Nothing because UAC typically doesn't send H-I (otherwise, it would be = > as per Index 1 in next entry, but without the AOR. >=20 > example.com -> freephone@example.net > History-Info: ;index=3D1;aor > History-Info: ;index=3D1.1;mp >=20 > example.net -> carol@example.net > History-Info: ;index=3D1;aor =20 > History-Info: ;index=3D1.1;mp;aor > <- aor is added > History-Info: ;index=3D1.1.1;rt;aor }=20 > Two entries are > History-Info: ;index=3D1.1.1.1;rc }=20 > added at same time >=20 > Also, I don't think we need to define an equivalent to the=20 > "reg-uri-alias" anymore. > If Freephone was configured to go to +14085551212 instead of the=20 > registered Contact (assuming +14085551212 was an Alias AOR for=20 > carol@example.net), the last H-I entries would look like this instead: >=20 > example.net -> carol@example.net > History-Info: ;index=3D1;aor =20 > History-Info:=20 > ;index=3D1.1;mp;aor <- aor = is=20 > added > History-Info: ;index=3D1.1.1;rt;aor > <- aor is added > History-Info: ;index=3D1.1.1.1;rt;aor =20 > } Two entries are > History-Info: ;index=3D1.1.1.1.1;rc =20 > } added at same time > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From R.Jesske@telekom.de Thu Jun 18 03:46:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2557A28C112 for ; Thu, 18 Jun 2009 03:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.334 X-Spam-Level: X-Spam-Status: No, score=0.334 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_LOAN=2.3, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0H90d9vrWPUq for ; Thu, 18 Jun 2009 03:46:07 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 80E603A698D for ; Thu, 18 Jun 2009 03:46:06 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 18 Jun 2009 12:46:12 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Jun 2009 12:46:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jun 2009 12:46:33 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD4048288E0@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1E8D4A32@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYAAADaOvAAAEZYIAAAZd2gAAEEtLAAASSLAAAQUjFAAAQ6qeAABxuA8AAqMxcAABHp8TAAKFRPgA== References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com><1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>!<1ECE0EB50388174790F9694F77522CCF1E83DBEB@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA0375EC26@gaalpa1msgusr7e.ugd.att.com> <9886E5FCA6D76549A3011068483A4BD404827AB8@S4DE8PSAAQB.mitte.t-com.de> <9ECCF01B52E7AB408A7EB853526421412F59C6@ftrdmel0.rd.francetelecom.fr> <9886E5FCA6D76549A3011068483A4BD4048280DC@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1E8D4A32@zrc2hxm0.corp.nortel.com> From: To: , , , , , X-OriginalArrivalTime: 18 Jun 2009 10:46:12.0103 (UTC) FILETIME=[FF06A970:01C9F001] Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 10:46:09 -0000 Mary, Question is how to distinguish. >From my understanding the Reason will only be included if a Service is = based upon a received Response. E.g Call Forwarding on Busy. So If you = would like to reach a UA and the UA is busy and send back a 486 then a = SIP AS would forward the call to an other UA so within the history INFO = the Reason 486 will be included. But if you forward based on provisioning within the AS then you will not = include a Reason but you can include a cause param with a value 302. Or you can forward the call based on a Response 302 (after 180 Ringing) = and add a cause 487 Parameter for Call deflection during alerting. So the REASON shows the SIP network response and the cause shows the = service behaviour of a specific application (in RFC 4458 the only = service putting a cause param into History is Call Diversion). So I see such cause param more under service apsects like a Free phone = call. BR Roland -----Urspr=FCngliche Nachricht----- Von: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Gesendet: Mittwoch, 17. Juni 2009 17:06 An: Jesske, Roland; christer.holmberg@ericsson.com; = bruno.chatras@orange-ftgroup.com; mdolly@att.com; Francois Audet; = sipcore@ietf.org Betreff: RE: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Roland, If you need additional "cause" parameters, then we really should = consider extensions to the Reason header in RFC 3326. =20 Mary. -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: Wednesday, June 17, 2009 1:35 AM To: christer.holmberg@ericsson.com; bruno.chatras@orange-ftgroup.com; = mdolly@att.com; Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); = sipcore@ietf.org Subject: AW: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Is it really a complete separate discussion? In defining a parameter that is a hint that the uri was changed due to = some "magic" in a server, why not to point to some existing mechanism = and use it. Either we could mention that a drafts exisists that has the possibility = of "cause parameters" and some extensions are needed to express also = other services than CDIV. And define a additional draft for this values. Or add a section with some additional cause parameters. BR, Roland -----Urspr=FCngliche Nachricht----- Von: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Gesendet: Dienstag, 16. Juni 2009 12:31 An: bruno.chatras@orange-ftgroup.com; Jesske, Roland; mdolly@att.com; = mary.barnes@nortel.com; audet@nortel.com; sipcore@ietf.org Betreff: RE: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi, >I would go even further. There are cases where it is useful=20 >to keep track of the services invoked during the=20 >establishment of a session, irrespective of whether these=20 >services have modified the R-URI or not. To achieve this, an=20 >application server providing service X would insert an entry=20 >in the History-Info header field with hi-target=3Dnoop, an=20 >unmodified R-URI and an extended cause-param set to a value=20 >representing service "X". I think that should be a completely separate discussion. It is an interesting topic, but I think you would need to start it in = DISPATCH or BLISS, because I think it is far beyond the scope of both = 4244bis and target delivery :) Regards, Christer > -----Message d'origine----- > De : sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] De la part de=20 > R.Jesske@telekom.de Envoy=E9 : mardi 16 juin 2009 07:02 =C0 :=20 > mdolly@att.com; mary.barnes@nortel.com;=20 > christer.holmberg@ericsson.com; audet@nortel.com;=20 > sipcore@ietf.org Objet : Re: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hi, > Why not to adopt the cause-parameter principle of RFC 4458=20 > and extend it for other service approaches. > The have a general cause-param for services other then call=20 > diversion and to have explicit cause parameters for free=20 > phone, "IN-services", calling card ect. > Such indications where asked a couples of times from other=20 > service providers. >=20 > BR, >=20 > Roland=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] Im Auftrag von DOLLY,=20 > MARTIN C, ATTLABS > Gesendet: Montag, 15. Juni 2009 23:10 > An: Mary Barnes; Christer Holmberg; Francois Audet; sipcore@ietf.org > Betreff: Re: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > no >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 4:38 PM > To: Christer Holmberg; Francois Audet; DOLLY, MARTIN C,=20 > ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But, the freephone service can be implemented also with a=20 > reg-uri or reg-uri-alias - NOW if a specific service treats=20 > them the same, no big deal. The UAS then looks for any of a=20 > set of tags to grab the appropriate hi-entry.=20 >=20 > Mary. >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 3:14 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055);=20 > DOLLY, MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi,=20 >=20 > >But, still with this approach, I do not think you can get=20 > away with not > looking for multiple tags with the way you envision doing=20 > your services. >=20 > Maybe not - that depends on the service. But, then it will at least be > possible to figure out what has happended. >=20 > >I think there are others that will implement services on the UAS that > will not need the differentiation that you do - i.e, they=20 > care about the > difference between "reg-uri" and "reg-uri-alias". >=20 > My differentiation is based on my understanding of the=20 > requirements that > we have. >=20 > If you think we need to differentiate between req-uri and=20 > req-uri-alias, > then we should agree on such requirement. Let's not mix it with the > freephone requirement. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Monday, June 15, 2009 2:53 PM > To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY,=20 > MARTIN C, > ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Christer,=20 >=20 > On your last point, the objective here was to make use of History-Info > WITHOUT changing any core SIP functionality - it's a whole different > ballgame if we want to do the latter IMHO. However, here's the snippet > from the end of the response I just sent to Martin (summarizing the > current set of tags), which you may not read: >=20 > " So, we're debating here the differences between the "aor,mapped" and > "aor,routed" vs "predetermined", "reg-uri" and=20 > "reg-uri-alias". I think > that "reg-uri-alias" and "reg-uri" are equivalent to "aor, routed". > And, I think one could consider the "aor,mapped" as=20 > predetermined. But, > again 4244bis tags the entries entirely based on what SIP does and if > the 800 number translations (or whatever services) are setup=20 > differently > in different proxies, then you can't determine if the=20 > "aor,routed" cases > might be "reg-uri-alias" or "reg-uri". Although, I am personally > confused as to whether an 800 number would always be "aor, mapped" or > "aor, routed" - i.e., I just don't see this being deterministic and I > think that if a service can reach a UAS through different SIP > retargeting mechanisms, then the UAS needs to be aware.=20 >=20 > Also, as I'm going through this, I think we need 3 more tags=20 > if we want > the proxy to do the tagging - i.e., I think we need to add=20 > "-aor" to the > "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that the > proxy will mark in this manner. " >=20 >=20 > Mary.=20 > P.S. Also, I do not think it's a burden to put logic in the UAS - that > was the original intent for SIP - services in the endpoints - SIP is > just the signalling to carry the relevant information. But, I can see > that since the sort of service you mention that does not have=20 > a standard > SIP URI (i.e., user@domain) introduces something that isn't=20 > accomodated > in the basic SIP model, so we may need to add additional logic to the > proxies (I don't like it though).=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 2:34 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi,=20 >=20 > >Correct. But, what I am suggesting is that you distinguish it at the > UAS > >- I'm assuming that the target Request-URI that arrives at the UAS is > something that identifies a client that handles 800 numbers. That > client could be configured such that it knows to look for the=20 > >original 800 number in the mapped URIs or in the reg-alias-URIs or > both.=20 >=20 > 800 numbers is just one example.=20 >=20 > Why should the UAS have to be configured with this information??? I > think that is very limiting and unpractical. >=20 > >Again, if you're making these 800 numbers special and=20 > allowing proxies > to change them in multiple ways (i.e., non-deterministic), then if you > want them tagged special, then you need special logic in the=20 > >proxies to do this. >=20 > The logic is that the AOR is replaced with another AOR, which=20 > belongs to > the same user.=20 >=20 > It's not only for 800 numbers - they are just an example=20 > where it would > be useful. >=20 > And, the proxy is configured to do this - it doesn't do it because it > "thinks" it has to do it :) >=20 > >That doesn't make sense to me, although you could do it that way in a > closed network, in which case you can make sure to always tag them as > whatever you think they should be - so we could define an=20 > >additional value for the tag. But, this is what I don't=20 > think is right > in terms of normal SIP request routing and forwarding, which=20 > is what the > current 4244bis tags have been defined to represent.=20 >=20 > I really don't understand wht this "normal SIP request routing and > forwarding" is all about. Normal SIP request routing and=20 > forwarding has > issues, which were presented in the ua-loose-route draft - and that is > why we are now working on a solution to solve those issues. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 1:23 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi Mary, >=20 > Proxies will tag entries based on the functionality they perform. >=20 > Let's leave req-uri-alias for the moment. >=20 > As I said earlier, one of the issues we have with 4244bis, is that > "mapped" seems to be used BOTH for diversion and when an AOR=20 > is replaced > with another AOR pointing to the same user - e.g. freephone. So, it is > not possible to distinguish between diversion and freephone. >=20 > We think one MUST be able to make that distinguishment,=20 > because you may > have cases where both diversion and service number translation (e.g. > freephone) occurs, and the UAS needs to know which is which. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > =20 >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 9:13 PM > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > It seems to me that the gist of this discussion has been based on the > expectation that independent of how the 800 number is configured, > registered or whatever at a proxy, that there is an expectation of > deterministic behavior in terms of how it's tagged. So, if=20 > 800 numbers > are special and they can end up tagged as either reg-uri-alias or as > mapped, then perhaps the service has to know that it needs to look for > either of those. ISTM that if there is a reason to preserve=20 > that it's an > 800 number (i.e., and not format as a service specific uri),=20 > the service > at the UAS knows that it's special, thus it would need to check the > request-URIs associated with both reg-uri-alias and mapped hi-entries. > I can't see how we can make it work any other way without being > prescriptive of how proxy's MUST tag these entries, which is=20 > not a good > idea IMHO. However, I think these numbers are either special cases at > proxies or something that services know about.=20 >=20 > Mary.=20 >=20 > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 12:47 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary > (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Yes, we need to sort out what to do for that.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, June 15, 2009 10:17 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 > >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, June 15, 2009 6:50 PM > > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > > sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > then reg-uri-alias.=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Saturday, June 13, 2009 01:22 > > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C,=20 > ATTLABS; Barnes,=20 > > > Mary (RICH2:AR00); sipcore@ietf.org > > > Subject: RE: [sipcore] FW: I-D > > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > >=20 > > >=20 > > > Hi, > > >=20 > > > >1) RFC 4244bis > > > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > > Request-URI and it replacing it with a Contact, it will put > > a reg-uri > > > flag (if the Request-URI was the AOR used for=20 > registration), or reg- > > > >uri-alias (if the Request-URI was an alias for the AOR used in > > > registration). > > >=20 > > > And if the Request-URI was a "synonym" for the AOR? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From bruno.chatras@orange-ftgroup.com Thu Jun 18 06:08:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33CA33A672F for ; Thu, 18 Jun 2009 06:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.551 X-Spam-Level: ** X-Spam-Status: No, score=2.551 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_LOAN=2.3, MANGLED_REGALS=2.5] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtH6vtnaFh0H for ; Thu, 18 Jun 2009 06:08:25 -0700 (PDT) Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id ABC6F3A6CBF for ; Thu, 18 Jun 2009 06:08:24 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Jun 2009 15:07:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jun 2009 15:07:39 +0200 Message-ID: <9ECCF01B52E7AB408A7EB853526421413251E3@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4048288E0@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Thread-Index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYAAADaOvAAAEZYIAAAZd2gAAEEtLAAASSLAAAQUjFAAAQ6qeAABxuA8AAqMxcAABHp8TAAKFRPgAADgUdg References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com><1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>!<1ECE0EB50388174790F9694F77522CCF1E83DBEB@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA0375EC26@gaalpa1msgusr7e.ugd.att.com> <9886E5FCA6D76549A3011068483A4BD404827AB8@S4DE8PSAAQB.mitte.t-com.de> <9ECCF01B52E7AB408A7EB853526421412F59C6@ftrdmel0.rd.francetelecom.fr> <9886E5FCA6D76549A3011068483A4BD4048280DC@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1E8D4A32@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4048288E0@S4DE8PSAAQB.mitte.t-com.de> From: To: , , , , , X-OriginalArrivalTime: 18 Jun 2009 13:07:38.0845 (UTC) FILETIME=[C184B8D0:01C9F015] Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 13:08:27 -0000 Roland, Mary, According to rfc4244bis the History-Info header "is added to a Request = when a new request is created by a UAC or forwarded by a Proxy, or when = the target of a request is changed". I believe a couple of minor = modifications would be required in 4.3.3.1.2. to enable adding a Reason = parameter in case a Request is retargeted or is just forwarded (target = unchanged) for a reason other than receipt of a SIP response. Clause 4.3.3.1.2 already includes the following text: "For retargets as = a result of timeouts or internal events, a Reason MAY be associated with = the hi-targeted-to-uri that has been retargeted." So it seems that Reason is not only associated to SIP Responses. However = it is unclear to me how the Reason parameter is valued in case of = internal events, especially the "protocol" field? A clarification would = help. Then we can think about extending the Reason header with new = values associated to internal events representing either standard or = non-standard services. Furthermore, if the Reason header can indeed be used for cases other = than receipt of a SIP response, I believe we should add "or when a = request is forwarded by a proxy" immediately after "internal events," = and remove "that has been retargeted" at the end of the sentence. This = would take care of the case where the Request is just forwarded. BC =09 -----Message d'origine----- De : R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Envoy=E9 : jeudi 18 juin 2009 12:47 =C0 : mary.barnes@nortel.com; christer.holmberg@ericsson.com; CHATRAS = Bruno RD-CORE-ISS; mdolly@att.com; audet@nortel.com; sipcore@ietf.org Objet : AW: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Mary, Question is how to distinguish. >From my understanding the Reason will only be included if a Service is = based upon a received Response. E.g Call Forwarding on Busy. So If you = would like to reach a UA and the UA is busy and send back a 486 then a = SIP AS would forward the call to an other UA so within the history INFO = the Reason 486 will be included. But if you forward based on provisioning within the AS then you will not = include a Reason but you can include a cause param with a value 302. Or you can forward the call based on a Response 302 (after 180 Ringing) = and add a cause 487 Parameter for Call deflection during alerting. So the REASON shows the SIP network response and the cause shows the = service behaviour of a specific application (in RFC 4458 the only = service putting a cause param into History is Call Diversion). So I see such cause param more under service apsects like a Free phone = call. BR Roland -----Urspr=FCngliche Nachricht----- Von: Mary Barnes [mailto:mary.barnes@nortel.com] Gesendet: Mittwoch, 17. Juni 2009 17:06 An: Jesske, Roland; christer.holmberg@ericsson.com; = bruno.chatras@orange-ftgroup.com; mdolly@att.com; Francois Audet; = sipcore@ietf.org Betreff: RE: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Roland, If you need additional "cause" parameters, then we really should = consider extensions to the Reason header in RFC 3326. =20 Mary. -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] Sent: Wednesday, June 17, 2009 1:35 AM To: christer.holmberg@ericsson.com; bruno.chatras@orange-ftgroup.com; = mdolly@att.com; Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); = sipcore@ietf.org Subject: AW: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Is it really a complete separate discussion? In defining a parameter that is a hint that the uri was changed due to = some "magic" in a server, why not to point to some existing mechanism = and use it. Either we could mention that a drafts exisists that has the possibility = of "cause parameters" and some extensions are needed to express also = other services than CDIV. And define a additional draft for this values. Or add a section with some additional cause parameters. BR, Roland -----Urspr=FCngliche Nachricht----- Von: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Gesendet: Dienstag, 16. Juni 2009 12:31 An: bruno.chatras@orange-ftgroup.com; Jesske, Roland; mdolly@att.com; = mary.barnes@nortel.com; audet@nortel.com; sipcore@ietf.org Betreff: RE: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi, >I would go even further. There are cases where it is useful to keep=20 >track of the services invoked during the establishment of a session,=20 >irrespective of whether these services have modified the R-URI or not.=20 >To achieve this, an application server providing service X would insert = >an entry in the History-Info header field with hi-target=3Dnoop, an=20 >unmodified R-URI and an extended cause-param set to a value=20 >representing service "X". I think that should be a completely separate discussion. It is an interesting topic, but I think you would need to start it in = DISPATCH or BLISS, because I think it is far beyond the scope of both = 4244bis and target delivery :) Regards, Christer > -----Message d'origine----- > De : sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] De la part de R.Jesske@telekom.de=20 > Envoy=E9 : mardi 16 juin 2009 07:02 =C0 : > mdolly@att.com; mary.barnes@nortel.com;=20 > christer.holmberg@ericsson.com; audet@nortel.com; sipcore@ietf.org=20 > Objet : Re: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hi, > Why not to adopt the cause-parameter principle of RFC 4458 and extend=20 > it for other service approaches. > The have a general cause-param for services other then call diversion=20 > and to have explicit cause parameters for free phone, "IN-services",=20 > calling card ect. > Such indications where asked a couples of times from other service=20 > providers. >=20 > BR, >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] Im Auftrag von DOLLY, MARTIN C,=20 > ATTLABS > Gesendet: Montag, 15. Juni 2009 23:10 > An: Mary Barnes; Christer Holmberg; Francois Audet; sipcore@ietf.org > Betreff: Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > no >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 4:38 PM > To: Christer Holmberg; Francois Audet; DOLLY, MARTIN C, ATTLABS;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But, the freephone service can be implemented also with a reg-uri or=20 > reg-uri-alias - NOW if a specific service treats them the same, no big = > deal. The UAS then looks for any of a set of tags to grab the=20 > appropriate hi-entry. >=20 > Mary. >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 3:14 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,=20 > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi, >=20 > >But, still with this approach, I do not think you can get > away with not > looking for multiple tags with the way you envision doing your=20 > services. >=20 > Maybe not - that depends on the service. But, then it will at least be = > possible to figure out what has happended. >=20 > >I think there are others that will implement services on the UAS that > will not need the differentiation that you do - i.e, they care about=20 > the difference between "reg-uri" and "reg-uri-alias". >=20 > My differentiation is based on my understanding of the requirements=20 > that we have. >=20 > If you think we need to differentiate between req-uri and=20 > req-uri-alias, then we should agree on such requirement. Let's not mix = > it with the freephone requirement. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Monday, June 15, 2009 2:53 PM > To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN=20 > C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Christer, >=20 > On your last point, the objective here was to make use of History-Info = > WITHOUT changing any core SIP functionality - it's a whole different=20 > ballgame if we want to do the latter IMHO. However, here's the snippet = > from the end of the response I just sent to Martin (summarizing the=20 > current set of tags), which you may not read: >=20 > " So, we're debating here the differences between the "aor,mapped" and = > "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I=20 > think that "reg-uri-alias" and "reg-uri" are equivalent to "aor,=20 > routed". > And, I think one could consider the "aor,mapped" as predetermined.=20 > But, again 4244bis tags the entries entirely based on what SIP does=20 > and if the 800 number translations (or whatever services) are setup=20 > differently in different proxies, then you can't determine if the=20 > "aor,routed" cases might be "reg-uri-alias" or "reg-uri". Although, I = > am personally confused as to whether an 800 number would always be=20 > "aor, mapped" or "aor, routed" - i.e., I just don't see this being=20 > deterministic and I think that if a service can reach a UAS through=20 > different SIP retargeting mechanisms, then the UAS needs to be aware. >=20 > Also, as I'm going through this, I think we need 3 more tags if we=20 > want the proxy to do the tagging - i.e., I think we need to add "-aor" = > to the "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that = > the proxy will mark in this manner. " >=20 >=20 > Mary.=20 > P.S. Also, I do not think it's a burden to put logic in the UAS - that > was the original intent for SIP - services in the endpoints - SIP is > just the signalling to carry the relevant information. But, I can see > that since the sort of service you mention that does not have=20 > a standard > SIP URI (i.e., user@domain) introduces something that isn't=20 > accomodated > in the basic SIP model, so we may need to add additional logic to the > proxies (I don't like it though).=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 2:34 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi,=20 >=20 > >Correct. But, what I am suggesting is that you distinguish it at the > UAS > >- I'm assuming that the target Request-URI that arrives at the UAS is > something that identifies a client that handles 800 numbers. That > client could be configured such that it knows to look for the=20 > >original 800 number in the mapped URIs or in the reg-alias-URIs or > both.=20 >=20 > 800 numbers is just one example.=20 >=20 > Why should the UAS have to be configured with this information??? I > think that is very limiting and unpractical. >=20 > >Again, if you're making these 800 numbers special and=20 > allowing proxies > to change them in multiple ways (i.e., non-deterministic), then if you > want them tagged special, then you need special logic in the=20 > >proxies to do this. >=20 > The logic is that the AOR is replaced with another AOR, which=20 > belongs to > the same user.=20 >=20 > It's not only for 800 numbers - they are just an example=20 > where it would > be useful. >=20 > And, the proxy is configured to do this - it doesn't do it because it > "thinks" it has to do it :) >=20 > >That doesn't make sense to me, although you could do it that way in a > closed network, in which case you can make sure to always tag them as > whatever you think they should be - so we could define an=20 > >additional value for the tag. But, this is what I don't=20 > think is right > in terms of normal SIP request routing and forwarding, which=20 > is what the > current 4244bis tags have been defined to represent.=20 >=20 > I really don't understand wht this "normal SIP request routing and > forwarding" is all about. Normal SIP request routing and=20 > forwarding has > issues, which were presented in the ua-loose-route draft - and that is > why we are now working on a solution to solve those issues. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 1:23 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi Mary, >=20 > Proxies will tag entries based on the functionality they perform. >=20 > Let's leave req-uri-alias for the moment. >=20 > As I said earlier, one of the issues we have with 4244bis, is that > "mapped" seems to be used BOTH for diversion and when an AOR=20 > is replaced > with another AOR pointing to the same user - e.g. freephone. So, it is > not possible to distinguish between diversion and freephone. >=20 > We think one MUST be able to make that distinguishment,=20 > because you may > have cases where both diversion and service number translation (e.g. > freephone) occurs, and the UAS needs to know which is which. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > =20 >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 9:13 PM > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > It seems to me that the gist of this discussion has been based on the > expectation that independent of how the 800 number is configured, > registered or whatever at a proxy, that there is an expectation of > deterministic behavior in terms of how it's tagged. So, if=20 > 800 numbers > are special and they can end up tagged as either reg-uri-alias or as > mapped, then perhaps the service has to know that it needs to look for > either of those. ISTM that if there is a reason to preserve=20 > that it's an > 800 number (i.e., and not format as a service specific uri),=20 > the service > at the UAS knows that it's special, thus it would need to check the > request-URIs associated with both reg-uri-alias and mapped hi-entries. > I can't see how we can make it work any other way without being > prescriptive of how proxy's MUST tag these entries, which is=20 > not a good > idea IMHO. However, I think these numbers are either special cases at > proxies or something that services know about.=20 >=20 > Mary.=20 >=20 > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 12:47 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary > (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Yes, we need to sort out what to do for that.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, June 15, 2009 10:17 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 > >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, June 15, 2009 6:50 PM > > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > > sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > then reg-uri-alias.=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Saturday, June 13, 2009 01:22 > > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C,=20 > ATTLABS; Barnes,=20 > > > Mary (RICH2:AR00); sipcore@ietf.org > > > Subject: RE: [sipcore] FW: I-D > > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > >=20 > > >=20 > > > Hi, > > >=20 > > > >1) RFC 4244bis > > > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > > Request-URI and it replacing it with a Contact, it will put > > a reg-uri > > > flag (if the Request-URI was the AOR used for=20 > registration), or reg- > > > >uri-alias (if the Request-URI was an alias for the AOR used in > > > registration). > > >=20 > > > And if the Request-URI was a "synonym" for the AOR? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From john.elwell@siemens-enterprise.com Thu Jun 18 08:24:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC4FE28C325 for ; Thu, 18 Jun 2009 08:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wX9mdSw1u4T for ; Thu, 18 Jun 2009 08:24:52 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 28E9B28C159 for ; Thu, 18 Jun 2009 08:24:52 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KLF00G15XHNIY@siemenscomms.co.uk> for sipcore@ietf.org; Thu, 18 Jun 2009 16:25:01 +0100 (BST) Date: Thu, 18 Jun 2009 16:24:57 +0100 From: "Elwell, John" In-reply-to: <4A380666.6050706@cisco.com> To: Paul Kyzivat , Christer Holmberg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0020A7AAF@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: AcnuxOYeMPSFoWtzTLiu4FA382ve+wBY4v5A Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E3A8@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E547@zrc2hxm0.corp.nortel.com> <4A37FE92.9080505@cisco.com> Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 15:24:53 -0000 =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 16 June 2009 21:54 > To: Christer Holmberg > Cc: sipcore@ietf.org; Shida Schubert > Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri >=20 >=20 >=20 > Christer Holmberg wrote: > >> A problem here is that "synonym" is the appropriate term=20 > for what 3gpp > > is calling "alias". If we we adopt the 3gpp usage of alias,=20 > then what to > > you want to use "synonym" for? > >=20 > > We would use "synonym" when an AOR is replaced with an AOR=20 > pointing to > > the same user, but the AOR is NOT an alias (per 3GPP definition). > >=20 > >> Alias has the connotation that it is just a substitute for=20 > the "real" > > name. > >=20 > > Alias is whatver we define it to be - and that is why I=20 > think it has to > > be very clear what we mean. >=20 > Yes, we can make the word mean whatever we want. > But if we make our word differ greatly from standard English=20 > usage then=20 > we are going to confuse people greatly. >=20 > If we use both "synonym" and "alias", and use them in such a way that=20 > the distinction between them is opposite of the difference=20 > between them=20 > in English usage, then we are really asking for trouble. [JRE] Can somebody explain again the circumstances in which we would use "synonym" or "alias". I thought there was some mention in the context of operations like resolving a call center URI to a specific user URI. In such cases I don't think either "synonym" or "alias" is an intuitive term. The call center URI and the resolved-to user URI identify different objects. John >=20 > Thanks, > Paul >=20 > > Christer Holmberg wrote: > >> =20 > >> > >>> We can use synonyms if alias is too confusing.=20 > >> We can use both, when appropriate :) > >> > >>> Or like Mary says, we can just define alias for the=20 > purpose of this > >> document. > >> > >> I don't think we should do that. The 3GPP definition of "alias" is=20 > >> useful for the "ic" tag, I believe. > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >>> -----Original Message----- > >>> From: Barnes, Mary (RICH2:AR00) > >>> Sent: Tuesday, June 16, 2009 12:03 > >>> To: DRAGE, Keith (Keith); Audet, Francois (SC100:3055); Christer=20 > >>> Holmberg; Hans Erik van Elburg; Shida Schubert > >>> Cc: sipcore@ietf.org > >>> Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri > >>> > >>> Keith, > >>> > >>> The term "alias" is not used in RFC 3325. It is used once=20 > in RFC 3324 > >=20 > >>> and I can't see that the proposed definition is confusing or=20 > >>> conflicting as it is used in a fairly general sense. The=20 > term alias=20 > >>> is > >>> used once in GRUU: > >>> "In cases where the UA uses a tel URI (as > >>> defiend in [11]) to populate the From header field, the UA=20 > >>> typically > >>> has a SIP AOR that is treated as an alias for the tel URI." > >>> And, the reference [11] does not use the term alias.=20 > >>> > >>> Identity (RFC 4474) does use the term alias (once): > >>> "It must be possible for a user to have multiple AoRs (i.e., > >>> accounts or aliases) that it is authorized to use within a > >>> domain..." > >>> > >>> The most prolific user of the term alias is=20 > connection-reuse, where=20 > >>> the term is defined, but that context is entirely=20 > different than what > >=20 > >>> we are talking about here, so I don't see a problem. > >>> > >>> And, I don't see any more suspects of concern when I google:=20 > >>> draft-ietf-sip alias I found one enum document that talks about=20 > >>> aliasing with DNS. Digging down to the 3rd page of hits,=20 > Hannes does=20 > >>> use it in one of his docs about SPIT, but again the usage is=20 > >>> consistent with the usage in Identity. > >>> And, if you dig down to the fourth page, you can find an=20 > interesting=20 > >>> patent that uses the term. One thing I have found with=20 > google is that > >=20 > >>> you do get different results with different browsers - I used IE. > >>> > >>> So, I don't see the concern, since the most explicit usage in=20 > >>> Identity > >>> is exactly what I thought we were talking about. > >>> Once we finally agree these terms, we are proposing to write an=20 > >>> update > >>> to section 16.5 in RFC 3261 since the plan is to define=20 > precise terms > >=20 > >>> for the mechanisms by which the targets are determined. > >>> > >>> Regards, > >>> Mary > >> _______________________________________________ > >> 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 >=20 From mary.barnes@nortel.com Thu Jun 18 09:46:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 002E528C38E for ; Thu, 18 Jun 2009 09:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.937 X-Spam-Level: X-Spam-Status: No, score=-3.937 tagged_above=-999 required=5 tests=[AWL=-2.138, BAYES_00=-2.599, MANGLED_LOAN=2.3, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHE9nMhetLGA for ; Thu, 18 Jun 2009 09:46:23 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 23A6528C162 for ; Thu, 18 Jun 2009 09:46:23 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5IGj1S11234; Thu, 18 Jun 2009 16:45:01 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jun 2009 11:48:28 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E923387@zrc2hxm0.corp.nortel.com> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4048288E0@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt thread-index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYAAADaOvAAAEZYIAAAZd2gAAEEtLAAASSLAAAQUjFAAAQ6qeAABxuA8AAqMxcAABHp8TAAKFRPgAANjn2w References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com><1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>!<1ECE0EB50388174790F9694F77522CCF1E83DBEB@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA0375EC26@gaalpa1msgusr7e.ugd.att.com> <9886E5FCA6D76549A3011068483A4BD404827AB8@S4DE8PSAAQB.mitte.t-com.de> <9ECCF01B52E7AB408A7EB853526421412F59C6@ftrdmel0.rd.francetelecom.fr> <9886E5FCA6D76549A3011068483A4BD4048280DC@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1E8D4A32@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4048288E0@S4DE8PSAAQB.mitte.t-com.de> From: "Mary Barnes" To: , , , , "Francois Audet" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 16:46:25 -0000 Roland, For some of the services you have in mind, the new tags being added to = the hi-entries should facilitate those services, in particular in a pure = SIP model. Also, consider that you can add multiple reason headers.=20 Regards, Mary.=20 -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: Thursday, June 18, 2009 5:47 AM To: Barnes, Mary (RICH2:AR00); christer.holmberg@ericsson.com; = bruno.chatras@orange-ftgroup.com; mdolly@att.com; Audet, Francois = (SC100:3055); sipcore@ietf.org Subject: AW: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Mary, Question is how to distinguish. >From my understanding the Reason will only be included if a Service is = based upon a received Response. E.g Call Forwarding on Busy. So If you = would like to reach a UA and the UA is busy and send back a 486 then a = SIP AS would forward the call to an other UA so within the history INFO = the Reason 486 will be included. But if you forward based on provisioning within the AS then you will not = include a Reason but you can include a cause param with a value 302. Or you can forward the call based on a Response 302 (after 180 Ringing) = and add a cause 487 Parameter for Call deflection during alerting. So the REASON shows the SIP network response and the cause shows the = service behaviour of a specific application (in RFC 4458 the only = service putting a cause param into History is Call Diversion). So I see such cause param more under service apsects like a Free phone = call. BR Roland -----Urspr=FCngliche Nachricht----- Von: Mary Barnes [mailto:mary.barnes@nortel.com] Gesendet: Mittwoch, 17. Juni 2009 17:06 An: Jesske, Roland; christer.holmberg@ericsson.com; = bruno.chatras@orange-ftgroup.com; mdolly@att.com; Francois Audet; = sipcore@ietf.org Betreff: RE: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Roland, If you need additional "cause" parameters, then we really should = consider extensions to the Reason header in RFC 3326. =20 Mary. -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] Sent: Wednesday, June 17, 2009 1:35 AM To: christer.holmberg@ericsson.com; bruno.chatras@orange-ftgroup.com; = mdolly@att.com; Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); = sipcore@ietf.org Subject: AW: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Is it really a complete separate discussion? In defining a parameter that is a hint that the uri was changed due to = some "magic" in a server, why not to point to some existing mechanism = and use it. Either we could mention that a drafts exisists that has the possibility = of "cause parameters" and some extensions are needed to express also = other services than CDIV. And define a additional draft for this values. Or add a section with some additional cause parameters. BR, Roland -----Urspr=FCngliche Nachricht----- Von: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Gesendet: Dienstag, 16. Juni 2009 12:31 An: bruno.chatras@orange-ftgroup.com; Jesske, Roland; mdolly@att.com; = mary.barnes@nortel.com; audet@nortel.com; sipcore@ietf.org Betreff: RE: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi, >I would go even further. There are cases where it is useful to keep=20 >track of the services invoked during the establishment of a session,=20 >irrespective of whether these services have modified the R-URI or not.=20 >To achieve this, an application server providing service X would insert = >an entry in the History-Info header field with hi-target=3Dnoop, an=20 >unmodified R-URI and an extended cause-param set to a value=20 >representing service "X". I think that should be a completely separate discussion. It is an interesting topic, but I think you would need to start it in = DISPATCH or BLISS, because I think it is far beyond the scope of both = 4244bis and target delivery :) Regards, Christer > -----Message d'origine----- > De : sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] De la part de R.Jesske@telekom.de=20 > Envoy=E9 : mardi 16 juin 2009 07:02 =C0 : > mdolly@att.com; mary.barnes@nortel.com;=20 > christer.holmberg@ericsson.com; audet@nortel.com; sipcore@ietf.org=20 > Objet : Re: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hi, > Why not to adopt the cause-parameter principle of RFC 4458 and extend=20 > it for other service approaches. > The have a general cause-param for services other then call diversion=20 > and to have explicit cause parameters for free phone, "IN-services",=20 > calling card ect. > Such indications where asked a couples of times from other service=20 > providers. >=20 > BR, >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] Im Auftrag von DOLLY, MARTIN C,=20 > ATTLABS > Gesendet: Montag, 15. Juni 2009 23:10 > An: Mary Barnes; Christer Holmberg; Francois Audet; sipcore@ietf.org > Betreff: Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > no >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 4:38 PM > To: Christer Holmberg; Francois Audet; DOLLY, MARTIN C, ATTLABS;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But, the freephone service can be implemented also with a reg-uri or=20 > reg-uri-alias - NOW if a specific service treats them the same, no big = > deal. The UAS then looks for any of a set of tags to grab the=20 > appropriate hi-entry. >=20 > Mary. >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 3:14 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,=20 > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi, >=20 > >But, still with this approach, I do not think you can get > away with not > looking for multiple tags with the way you envision doing your=20 > services. >=20 > Maybe not - that depends on the service. But, then it will at least be = > possible to figure out what has happended. >=20 > >I think there are others that will implement services on the UAS that > will not need the differentiation that you do - i.e, they care about=20 > the difference between "reg-uri" and "reg-uri-alias". >=20 > My differentiation is based on my understanding of the requirements=20 > that we have. >=20 > If you think we need to differentiate between req-uri and=20 > req-uri-alias, then we should agree on such requirement. Let's not mix = > it with the freephone requirement. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Monday, June 15, 2009 2:53 PM > To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN=20 > C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Christer, >=20 > On your last point, the objective here was to make use of History-Info = > WITHOUT changing any core SIP functionality - it's a whole different=20 > ballgame if we want to do the latter IMHO. However, here's the snippet = > from the end of the response I just sent to Martin (summarizing the=20 > current set of tags), which you may not read: >=20 > " So, we're debating here the differences between the "aor,mapped" and = > "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I=20 > think that "reg-uri-alias" and "reg-uri" are equivalent to "aor,=20 > routed". > And, I think one could consider the "aor,mapped" as predetermined.=20 > But, again 4244bis tags the entries entirely based on what SIP does=20 > and if the 800 number translations (or whatever services) are setup=20 > differently in different proxies, then you can't determine if the=20 > "aor,routed" cases might be "reg-uri-alias" or "reg-uri". Although, I = > am personally confused as to whether an 800 number would always be=20 > "aor, mapped" or "aor, routed" - i.e., I just don't see this being=20 > deterministic and I think that if a service can reach a UAS through=20 > different SIP retargeting mechanisms, then the UAS needs to be aware. >=20 > Also, as I'm going through this, I think we need 3 more tags if we=20 > want the proxy to do the tagging - i.e., I think we need to add "-aor" = > to the "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that = > the proxy will mark in this manner. " >=20 >=20 > Mary.=20 > P.S. Also, I do not think it's a burden to put logic in the UAS - that > was the original intent for SIP - services in the endpoints - SIP is > just the signalling to carry the relevant information. But, I can see > that since the sort of service you mention that does not have=20 > a standard > SIP URI (i.e., user@domain) introduces something that isn't=20 > accomodated > in the basic SIP model, so we may need to add additional logic to the > proxies (I don't like it though).=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 2:34 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi,=20 >=20 > >Correct. But, what I am suggesting is that you distinguish it at the > UAS > >- I'm assuming that the target Request-URI that arrives at the UAS is > something that identifies a client that handles 800 numbers. That > client could be configured such that it knows to look for the=20 > >original 800 number in the mapped URIs or in the reg-alias-URIs or > both.=20 >=20 > 800 numbers is just one example.=20 >=20 > Why should the UAS have to be configured with this information??? I > think that is very limiting and unpractical. >=20 > >Again, if you're making these 800 numbers special and=20 > allowing proxies > to change them in multiple ways (i.e., non-deterministic), then if you > want them tagged special, then you need special logic in the=20 > >proxies to do this. >=20 > The logic is that the AOR is replaced with another AOR, which=20 > belongs to > the same user.=20 >=20 > It's not only for 800 numbers - they are just an example=20 > where it would > be useful. >=20 > And, the proxy is configured to do this - it doesn't do it because it > "thinks" it has to do it :) >=20 > >That doesn't make sense to me, although you could do it that way in a > closed network, in which case you can make sure to always tag them as > whatever you think they should be - so we could define an=20 > >additional value for the tag. But, this is what I don't=20 > think is right > in terms of normal SIP request routing and forwarding, which=20 > is what the > current 4244bis tags have been defined to represent.=20 >=20 > I really don't understand wht this "normal SIP request routing and > forwarding" is all about. Normal SIP request routing and=20 > forwarding has > issues, which were presented in the ua-loose-route draft - and that is > why we are now working on a solution to solve those issues. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 1:23 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY, > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi Mary, >=20 > Proxies will tag entries based on the functionality they perform. >=20 > Let's leave req-uri-alias for the moment. >=20 > As I said earlier, one of the issues we have with 4244bis, is that > "mapped" seems to be used BOTH for diversion and when an AOR=20 > is replaced > with another AOR pointing to the same user - e.g. freephone. So, it is > not possible to distinguish between diversion and freephone. >=20 > We think one MUST be able to make that distinguishment,=20 > because you may > have cases where both diversion and service number translation (e.g. > freephone) occurs, and the UAS needs to know which is which. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > =20 >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 9:13 PM > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS; > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > It seems to me that the gist of this discussion has been based on the > expectation that independent of how the 800 number is configured, > registered or whatever at a proxy, that there is an expectation of > deterministic behavior in terms of how it's tagged. So, if=20 > 800 numbers > are special and they can end up tagged as either reg-uri-alias or as > mapped, then perhaps the service has to know that it needs to look for > either of those. ISTM that if there is a reason to preserve=20 > that it's an > 800 number (i.e., and not format as a service specific uri),=20 > the service > at the UAS knows that it's special, thus it would need to check the > request-URIs associated with both reg-uri-alias and mapped hi-entries. > I can't see how we can make it work any other way without being > prescriptive of how proxy's MUST tag these entries, which is=20 > not a good > idea IMHO. However, I think these numbers are either special cases at > proxies or something that services know about.=20 >=20 > Mary.=20 >=20 > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 12:47 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary > (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Yes, we need to sort out what to do for that.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, June 15, 2009 10:17 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 > >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, June 15, 2009 6:50 PM > > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > > sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > then reg-uri-alias.=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Saturday, June 13, 2009 01:22 > > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C,=20 > ATTLABS; Barnes,=20 > > > Mary (RICH2:AR00); sipcore@ietf.org > > > Subject: RE: [sipcore] FW: I-D > > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > >=20 > > >=20 > > > Hi, > > >=20 > > > >1) RFC 4244bis > > > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > > Request-URI and it replacing it with a Contact, it will put > > a reg-uri > > > flag (if the Request-URI was the AOR used for=20 > registration), or reg- > > > >uri-alias (if the Request-URI was an alias for the AOR used in > > > registration). > > >=20 > > > And if the Request-URI was a "synonym" for the AOR? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From mary.barnes@nortel.com Thu Jun 18 10:04:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5700B28C38F for ; Thu, 18 Jun 2009 10:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.907 X-Spam-Level: X-Spam-Status: No, score=-3.907 tagged_above=-999 required=5 tests=[AWL=-2.108, BAYES_00=-2.599, MANGLED_LOAN=2.3, MANGLED_REGALS=2.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wtnbp1ehGT9 for ; Thu, 18 Jun 2009 10:04:09 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id A608A28C324 for ; Thu, 18 Jun 2009 10:03:50 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5IH2VS14377; Thu, 18 Jun 2009 17:02:31 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jun 2009 12:05:30 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E92340A@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ECCF01B52E7AB408A7EB853526421413251E3@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt thread-index: AcnqvH1VHAB1UfkCS5+f7Wz0Z+IMGAAAGy9wAAVYedAAAFgRsAAAPDLwAC1esSAAHXMG4AB0RVVgAAL/qIAAARDIwAAAn6VQAABNexAAASepMAABVKYAAADaOvAAAEZYIAAAZd2gAAEEtLAAASSLAAAQUjFAAAQ6qeAABxuA8AAqMxcAABHp8TAAKFRPgAADgUdgAAqvI5A= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA036D0C66@gaalpa1msgusr7e.ugd.att.com><1ECE0EB50388174790F9694F77522CCF1E7D8301@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D361@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D6D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D791@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83D8D7@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1E83DACF@zrc2hxm0.corp.nortel.com>!<1ECE0EB50388174790F9694F77522CCF1E83DBEB@zrc2hxm0.corp.nortel.com><14C85D6CCBE92743AF33663BF5D24EBA0375EC26@gaalpa1msgusr7e.ugd.att.com> <9886E5FCA6D76549A3011068483A4BD404827AB8@S4DE8PSAAQB.mitte.t-com.de> <9ECCF01B52E7AB408A7EB853526421412F59C6@ftrdmel0.rd.francetelecom.fr> <9886E5FCA6D76549A3011068483A4BD4048280DC@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1E8D4A32@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4048288E0@S4DE8PSAAQB.mitte.t-com.de> <9ECCF01B52E7AB408A7EB853526421413251E3@ftrdmel0.rd.francetelecom.fr> From: "Mary Barnes" To: , , , , "Francois Audet" , Subject: Re: [sipcore] FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 17:04:11 -0000 Bruno, We can look at this once we get the next version of the document out - I = think the changes you suggest are okay. However, per my response to = Roland, I'm not certain you'll need to add more Reasons (causes) with = the new tags - you should be able to derive some of the information that = would give you the equivalent of a cause. Your application could convert = that to a cause if appropriate.=20 Mary.=20 -----Original Message----- From: bruno.chatras@orange-ftgroup.com = [mailto:bruno.chatras@orange-ftgroup.com]=20 Sent: Thursday, June 18, 2009 8:08 AM To: R.Jesske@telekom.de; Barnes, Mary (RICH2:AR00); = christer.holmberg@ericsson.com; mdolly@att.com; Audet, Francois = (SC100:3055); sipcore@ietf.org Subject: RE: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Roland, Mary, According to rfc4244bis the History-Info header "is added to a Request = when a new request is created by a UAC or forwarded by a Proxy, or when = the target of a request is changed". I believe a couple of minor = modifications would be required in 4.3.3.1.2. to enable adding a Reason = parameter in case a Request is retargeted or is just forwarded (target = unchanged) for a reason other than receipt of a SIP response. Clause 4.3.3.1.2 already includes the following text: "For retargets as = a result of timeouts or internal events, a Reason MAY be associated with = the hi-targeted-to-uri that has been retargeted." So it seems that Reason is not only associated to SIP Responses. However = it is unclear to me how the Reason parameter is valued in case of = internal events, especially the "protocol" field? A clarification would = help. Then we can think about extending the Reason header with new = values associated to internal events representing either standard or = non-standard services. Furthermore, if the Reason header can indeed be used for cases other = than receipt of a SIP response, I believe we should add "or when a = request is forwarded by a proxy" immediately after "internal events," = and remove "that has been retargeted" at the end of the sentence. This = would take care of the case where the Request is just forwarded. BC =09 -----Message d'origine----- De : R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] Envoy=E9 : jeudi = 18 juin 2009 12:47 =C0 : mary.barnes@nortel.com; = christer.holmberg@ericsson.com; CHATRAS Bruno RD-CORE-ISS; = mdolly@att.com; audet@nortel.com; sipcore@ietf.org Objet : AW: [sipcore] = FW: I-D Action:draft-barnes-sipcore-rfc4244bis-01.txt Mary, Question is how to distinguish. >From my understanding the Reason will only be included if a Service is = based upon a received Response. E.g Call Forwarding on Busy. So If you = would like to reach a UA and the UA is busy and send back a 486 then a = SIP AS would forward the call to an other UA so within the history INFO = the Reason 486 will be included. But if you forward based on provisioning within the AS then you will not = include a Reason but you can include a cause param with a value 302. Or you can forward the call based on a Response 302 (after 180 Ringing) = and add a cause 487 Parameter for Call deflection during alerting. So the REASON shows the SIP network response and the cause shows the = service behaviour of a specific application (in RFC 4458 the only = service putting a cause param into History is Call Diversion). So I see such cause param more under service apsects like a Free phone = call. BR Roland -----Urspr=FCngliche Nachricht----- Von: Mary Barnes [mailto:mary.barnes@nortel.com] Gesendet: Mittwoch, 17. Juni 2009 17:06 An: Jesske, Roland; christer.holmberg@ericsson.com; = bruno.chatras@orange-ftgroup.com; mdolly@att.com; Francois Audet; = sipcore@ietf.org Betreff: RE: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Roland, If you need additional "cause" parameters, then we really should = consider extensions to the Reason header in RFC 3326. =20 Mary. -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] Sent: Wednesday, June 17, 2009 1:35 AM To: christer.holmberg@ericsson.com; bruno.chatras@orange-ftgroup.com; = mdolly@att.com; Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); = sipcore@ietf.org Subject: AW: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Is it really a complete separate discussion? In defining a parameter that is a hint that the uri was changed due to = some "magic" in a server, why not to point to some existing mechanism = and use it. Either we could mention that a drafts exisists that has the possibility = of "cause parameters" and some extensions are needed to express also = other services than CDIV. And define a additional draft for this values. Or add a section with some additional cause parameters. BR, Roland -----Urspr=FCngliche Nachricht----- Von: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Gesendet: Dienstag, 16. Juni 2009 12:31 An: bruno.chatras@orange-ftgroup.com; Jesske, Roland; mdolly@att.com; = mary.barnes@nortel.com; audet@nortel.com; sipcore@ietf.org Betreff: RE: [sipcore] FW: I-D = Action:draft-barnes-sipcore-rfc4244bis-01.txt Hi, >I would go even further. There are cases where it is useful to keep=20 >track of the services invoked during the establishment of a session,=20 >irrespective of whether these services have modified the R-URI or not. >To achieve this, an application server providing service X would insert = >an entry in the History-Info header field with hi-target=3Dnoop, an=20 >unmodified R-URI and an extended cause-param set to a value=20 >representing service "X". I think that should be a completely separate discussion. It is an interesting topic, but I think you would need to start it in = DISPATCH or BLISS, because I think it is far beyond the scope of both = 4244bis and target delivery :) Regards, Christer > -----Message d'origine----- > De : sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] De la part de R.Jesske@telekom.de=20 > Envoy=E9 : mardi 16 juin 2009 07:02 =C0 : > mdolly@att.com; mary.barnes@nortel.com;=20 > christer.holmberg@ericsson.com; audet@nortel.com; sipcore@ietf.org=20 > Objet : Re: [sipcore] FW: I-D=20 > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Hi, > Why not to adopt the cause-parameter principle of RFC 4458 and extend=20 > it for other service approaches. > The have a general cause-param for services other then call diversion=20 > and to have explicit cause parameters for free phone, "IN-services",=20 > calling card ect. > Such indications where asked a couples of times from other service=20 > providers. >=20 > BR, >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] Im Auftrag von DOLLY, MARTIN C,=20 > ATTLABS > Gesendet: Montag, 15. Juni 2009 23:10 > An: Mary Barnes; Christer Holmberg; Francois Audet; sipcore@ietf.org > Betreff: Re: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > no >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 4:38 PM > To: Christer Holmberg; Francois Audet; DOLLY, MARTIN C, ATTLABS;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > But, the freephone service can be implemented also with a reg-uri or=20 > reg-uri-alias - NOW if a specific service treats them the same, no big = > deal. The UAS then looks for any of a set of tags to grab the=20 > appropriate hi-entry. >=20 > Mary. >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 3:14 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,=20 > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi, >=20 > >But, still with this approach, I do not think you can get > away with not > looking for multiple tags with the way you envision doing your=20 > services. >=20 > Maybe not - that depends on the service. But, then it will at least be = > possible to figure out what has happended. >=20 > >I think there are others that will implement services on the UAS that > will not need the differentiation that you do - i.e, they care about=20 > the difference between "reg-uri" and "reg-uri-alias". >=20 > My differentiation is based on my understanding of the requirements=20 > that we have. >=20 > If you think we need to differentiate between req-uri and=20 > req-uri-alias, then we should agree on such requirement. Let's not mix = > it with the freephone requirement. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Monday, June 15, 2009 2:53 PM > To: 'Christer Holmberg'; Audet, Francois (SC100:3055); DOLLY, MARTIN=20 > C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Christer, >=20 > On your last point, the objective here was to make use of History-Info = > WITHOUT changing any core SIP functionality - it's a whole different=20 > ballgame if we want to do the latter IMHO. However, here's the snippet = > from the end of the response I just sent to Martin (summarizing the=20 > current set of tags), which you may not read: >=20 > " So, we're debating here the differences between the "aor,mapped" and = > "aor,routed" vs "predetermined", "reg-uri" and "reg-uri-alias". I=20 > think that "reg-uri-alias" and "reg-uri" are equivalent to "aor,=20 > routed". > And, I think one could consider the "aor,mapped" as predetermined.=20 > But, again 4244bis tags the entries entirely based on what SIP does=20 > and if the 800 number translations (or whatever services) are setup=20 > differently in different proxies, then you can't determine if the=20 > "aor,routed" cases might be "reg-uri-alias" or "reg-uri". Although, I = > am personally confused as to whether an 800 number would always be=20 > "aor, mapped" or "aor, routed" - i.e., I just don't see this being=20 > deterministic and I think that if a service can reach a UAS through=20 > different SIP retargeting mechanisms, then the UAS needs to be aware. >=20 > Also, as I'm going through this, I think we need 3 more tags if we=20 > want the proxy to do the tagging - i.e., I think we need to add "-aor" > to the "predetermined", "reg-uri" and "reg-uri-alias" IF we agree that = > the proxy will mark in this manner. " >=20 >=20 > Mary.=20 > P.S. Also, I do not think it's a burden to put logic in the UAS - that = > was the original intent for SIP - services in the endpoints - SIP is=20 > just the signalling to carry the relevant information. But, I can see=20 > that since the sort of service you mention that does not have a=20 > standard SIP URI (i.e., user@domain) introduces something that isn't=20 > accomodated in the basic SIP model, so we may need to add additional=20 > logic to the proxies (I don't like it though). >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 2:34 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,=20 > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi, >=20 > >Correct. But, what I am suggesting is that you distinguish it at the > UAS > >- I'm assuming that the target Request-URI that arrives at the UAS is > something that identifies a client that handles 800 numbers. That=20 > client could be configured such that it knows to look for the > >original 800 number in the mapped URIs or in the reg-alias-URIs or > both.=20 >=20 > 800 numbers is just one example.=20 >=20 > Why should the UAS have to be configured with this information??? I=20 > think that is very limiting and unpractical. >=20 > >Again, if you're making these 800 numbers special and > allowing proxies > to change them in multiple ways (i.e., non-deterministic), then if you = > want them tagged special, then you need special logic in the > >proxies to do this. >=20 > The logic is that the AOR is replaced with another AOR, which belongs=20 > to the same user. >=20 > It's not only for 800 numbers - they are just an example where it=20 > would be useful. >=20 > And, the proxy is configured to do this - it doesn't do it because it = > "thinks" it has to do it :) >=20 > >That doesn't make sense to me, although you could do it that way in a > closed network, in which case you can make sure to always tag them as=20 > whatever you think they should be - so we could define an > >additional value for the tag. But, this is what I don't > think is right > in terms of normal SIP request routing and forwarding, which is what=20 > the current 4244bis tags have been defined to represent. >=20 > I really don't understand wht this "normal SIP request routing and=20 > forwarding" is all about. Normal SIP request routing and forwarding=20 > has issues, which were presented in the ua-loose-route draft - and=20 > that is why we are now working on a solution to solve those issues. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, June 15, 2009 1:23 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); DOLLY,=20 > MARTIN C, ATTLABS; sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 >=20 > Hi Mary, >=20 > Proxies will tag entries based on the functionality they perform. >=20 > Let's leave req-uri-alias for the moment. >=20 > As I said earlier, one of the issues we have with 4244bis, is that=20 > "mapped" seems to be used BOTH for diversion and when an AOR is=20 > replaced with another AOR pointing to the same user - e.g. freephone.=20 > So, it is not possible to distinguish between diversion and freephone. >=20 > We think one MUST be able to make that distinguishment, because you=20 > may have cases where both diversion and service number translation=20 > (e.g. > freephone) occurs, and the UAS needs to know which is which. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 > =20 >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Monday, June 15, 2009 9:13 PM > To: Francois Audet; Christer Holmberg; DOLLY, MARTIN C, ATTLABS;=20 > sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > It seems to me that the gist of this discussion has been based on the=20 > expectation that independent of how the 800 number is configured,=20 > registered or whatever at a proxy, that there is an expectation of=20 > deterministic behavior in terms of how it's tagged. So, if 800=20 > numbers are special and they can end up tagged as either reg-uri-alias = > or as mapped, then perhaps the service has to know that it needs to=20 > look for either of those. ISTM that if there is a reason to preserve=20 > that it's an 800 number (i.e., and not format as a service specific=20 > uri), the service at the UAS knows that it's special, thus it would=20 > need to check the request-URIs associated with both reg-uri-alias and=20 > mapped hi-entries. > I can't see how we can make it work any other way without being=20 > prescriptive of how proxy's MUST tag these entries, which is not a=20 > good idea IMHO. However, I think these numbers are either special=20 > cases at proxies or something that services know about. >=20 > Mary.=20 >=20 > -----Original Message----- > From: Audet, Francois (SC100:3055) > Sent: Monday, June 15, 2009 12:47 PM > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Barnes, Mary=20 > (RICH2:AR00); sipcore@ietf.org > Subject: RE: [sipcore] FW: I-D > Action:draft-barnes-sipcore-rfc4244bis-01.txt >=20 > Yes, we need to sort out what to do for that.=20 >=20 > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Monday, June 15, 2009 10:17 > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, ATTLABS; Barnes,=20 > > Mary (RICH2:AR00); sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > >=20 > > But if it is NOT an alias (=3Dimplicitly/explicitly registered)?=20 > >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, June 15, 2009 6:50 PM > > To: Christer Holmberg; DOLLY, MARTIN C, ATTLABS; Mary Barnes;=20 > > sipcore@ietf.org > > Subject: RE: [sipcore] FW: I-D > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > >=20 > > then reg-uri-alias.=20 > >=20 > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Saturday, June 13, 2009 01:22 > > > To: Audet, Francois (SC100:3055); DOLLY, MARTIN C, > ATTLABS; Barnes, > > > Mary (RICH2:AR00); sipcore@ietf.org > > > Subject: RE: [sipcore] FW: I-D > > > Action:draft-barnes-sipcore-rfc4244bis-01.txt > > >=20 > > >=20 > > > Hi, > > >=20 > > > >1) RFC 4244bis > > > > > > > >In RFC 4244bis, if the domain is responsible for the URI in the > > > Request-URI and it replacing it with a Contact, it will put > > a reg-uri > > > flag (if the Request-URI was the AOR used for > registration), or reg- > > > >uri-alias (if the Request-URI was an alias for the AOR used in > > > registration). > > >=20 > > > And if the Request-URI was a "synonym" for the AOR? > > >=20 > > > Regards, > > >=20 > > > Christer > > >=20 > > >=20 > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Fri Jun 19 05:19:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30B513A69F9 for ; Fri, 19 Jun 2009 05:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.782 X-Spam-Level: X-Spam-Status: No, score=-5.782 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OggpK-bExWkE for ; Fri, 19 Jun 2009 05:19:32 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 85D093A67F2 for ; Fri, 19 Jun 2009 05:19:31 -0700 (PDT) X-AuditID: c1b4fb3c-b7b0bae00000673a-5c-4a3b825383c7 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 5E.64.26426.3528B3A4; Fri, 19 Jun 2009 14:19:31 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 Jun 2009 14:17:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Jun 2009 14:17:41 +0200 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0020A7AAF@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri Thread-Index: AcnuxOYeMPSFoWtzTLiu4FA382ve+wBY4v5AACvK01A= References: <1ECE0EB50388174790F9694F77522CCF1E787418@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E83DFA5@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E0F1@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E146@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E178@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E3A8@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E88E547@zrc2hxm0.corp.nortel.com> <4A37FE92.9080505@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5 D0020A7A AF@GBNTHT12009MSX.gb002.siemens.net> From: "Christer Holmberg" To: "Elwell, John" , "Paul Kyzivat" X-OriginalArrivalTime: 19 Jun 2009 12:17:42.0348 (UTC) FILETIME=[F1E150C0:01C9F0D7] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis and target-uri X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 12:19:33 -0000 Hi John,=20 >>If we use both "synonym" and "alias", and use them in such a way that=20 >>the distinction between them is opposite of the difference between=20 >>them in English usage, then we are really asking for trouble. >[JRE] Can somebody explain again the circumstances in which we would use "synonym" or "alias". I thought there was some mention in the context of operations like resolving a call center URI to a specific=20 >user URI. In such cases I don't think either "synonym" or "alias" is an intuitive term. The call center URI and the resolved-to user URI identify different objects. I think we have agreed not to use "alias" and "synonym" wording, in order to avoid confusion. Regards, Christer > > Christer Holmberg wrote: > >> =20 > >> > >>> We can use synonyms if alias is too confusing.=20 > >> We can use both, when appropriate :) > >> > >>> Or like Mary says, we can just define alias for the > purpose of this > >> document. > >> > >> I don't think we should do that. The 3GPP definition of "alias" is=20 > >> useful for the "ic" tag, I believe. > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >>> -----Original Message----- > >>> From: Barnes, Mary (RICH2:AR00) > >>> Sent: Tuesday, June 16, 2009 12:03 > >>> To: DRAGE, Keith (Keith); Audet, Francois (SC100:3055); Christer=20 > >>> Holmberg; Hans Erik van Elburg; Shida Schubert > >>> Cc: sipcore@ietf.org > >>> Subject: RE: draft-barnes-sipcore-rfc4244bis and target-uri > >>> > >>> Keith, > >>> > >>> The term "alias" is not used in RFC 3325. It is used once > in RFC 3324 > >=20 > >>> and I can't see that the proposed definition is confusing or=20 > >>> conflicting as it is used in a fairly general sense. The > term alias > >>> is > >>> used once in GRUU: > >>> "In cases where the UA uses a tel URI (as > >>> defiend in [11]) to populate the From header field, the UA=20 > >>> typically > >>> has a SIP AOR that is treated as an alias for the tel URI." > >>> And, the reference [11] does not use the term alias.=20 > >>> > >>> Identity (RFC 4474) does use the term alias (once): > >>> "It must be possible for a user to have multiple AoRs (i.e., > >>> accounts or aliases) that it is authorized to use within a > >>> domain..." > >>> > >>> The most prolific user of the term alias is > connection-reuse, where > >>> the term is defined, but that context is entirely > different than what > >=20 > >>> we are talking about here, so I don't see a problem. > >>> > >>> And, I don't see any more suspects of concern when I google:=20 > >>> draft-ietf-sip alias I found one enum document that talks about=20 > >>> aliasing with DNS. Digging down to the 3rd page of hits, > Hannes does > >>> use it in one of his docs about SPIT, but again the usage is=20 > >>> consistent with the usage in Identity. > >>> And, if you dig down to the fourth page, you can find an > interesting > >>> patent that uses the term. One thing I have found with > google is that > >=20 > >>> you do get different results with different browsers - I used IE. > >>> > >>> So, I don't see the concern, since the most explicit usage in=20 > >>> Identity is exactly what I thought we were talking about. > >>> Once we finally agree these terms, we are proposing to write an=20 > >>> update to section 16.5 in RFC 3261 since the plan is to define > precise terms > >=20 > >>> for the mechanisms by which the targets are determined. > >>> > >>> Regards, > >>> Mary > >> _______________________________________________ > >> 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 >=20 From drage@alcatel-lucent.com Fri Jun 19 09:37:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F34F3A69BB for ; Fri, 19 Jun 2009 09:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1kj3BhnkTU5 for ; Fri, 19 Jun 2009 09:37:27 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 310CD3A699C for ; Fri, 19 Jun 2009 09:37:27 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n5JGbcDX002463 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 Jun 2009 18:37:38 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 19 Jun 2009 18:37:38 +0200 From: "DRAGE, Keith (Keith)" To: Dean Willis , Gonzalo Camarillo Date: Fri, 19 Jun 2009 18:37:37 +0200 Thread-Topic: [sipcore] Milestone to revise RFC 3265 Thread-Index: AcnsV5Og/VE/0TXhQ2+B8DSAROT3QgEo0MCw Message-ID: References: <4A3227D2.4020808@ericsson.com> <4A33F477.3030901@softarmor.com> In-Reply-To: <4A33F477.3030901@softarmor.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.57 on 155.132.188.80 Cc: SIPCORE Subject: Re: [sipcore] Milestone to revise RFC 3265 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 16:37:28 -0000 At the moment I have to answer NO to this consensus call for two reasons: 1) Nothing in the proposal addresses the issue of why we are revising the R= FC. Annex C of the initial draft contains a list of bugfixes that are addre= ssed in the -00 version, but nothing in the request indicates whether that = is the sole purpose of this revision, or whether other substantial changes,= and more specifically enhancements can suddenly land on the WGs work progr= amme once the work is adopted. So I would like to see statements that indic= ate the revision is to address issue problems with the existing RFC within = the existing scope of operation, and if there are any enhancements intended= then these are listed now and we obtain consensus on them. 2) Nothing in the proposal addresses compatibility with the existing RFC. D= ean is saying yes because he wants SIP 3.0. That is by definition incompati= ble with SIP 2.0 (the compatibility mechanism in this case is that if a res= ponse fails to appear for a 3.0 request the sender has to drop back to 2.0 = operation). I am certainly not prepared to endorse a revision at this stage= to produce a SIP 3.0 version of RFC 3265, and moreover, I require that whe= re possible, the changes made are made in a fashion that maintains compatib= ility with implementations to the existing RFC 3265 (barring stuff that is = completely broken of course). I would note that I do not have a problem with a revision addressing issues= currently listed in Annex C, so if we can revise the call to address my tw= o point, I will be able to revise my answer to yes. regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis > Sent: Saturday, June 13, 2009 7:48 PM > To: Gonzalo Camarillo > Cc: SIPCORE > Subject: Re: [sipcore] Milestone to revise RFC 3265 >=20 > Gonzalo Camarillo wrote: > > Folks, > >=20 > > since the publication of RFC 3265, we have gotten significant=20 > > experience deploying SIP-based notification systems. It has been=20 > > proposed to revise RFC 3265 based on that experience. We=20 > have two questions for the WG: > >=20 > > 1) should we add a milestone to our charter to revise RFC 3265? > >=20 > > 2) if we add such a milestone, should we take the following=20 > draft as=20 > > the initial WG item for the milestone? > >=20 > > http://tools.ietf.org/html/draft-roach-sipcore-rfc3265bis-00 > >=20 >=20 > I believe that RFC 3265 should be revised, and that SIPCORE=20 > is the right place to do it. Of course, I feel the same about=20 > 3261, 3262, 3263... >=20 > Adam's draft seems like a very good start. >=20 > -- > Dean > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From gonzalo.camarillo@ericsson.com Sun Jun 21 10:58:20 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21D553A6D5D for ; Sun, 21 Jun 2009 10:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kg1rLMTApfh8 for ; Sun, 21 Jun 2009 10:58:19 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EC8073A69C9 for ; Sun, 21 Jun 2009 10:58:18 -0700 (PDT) X-AuditID: c1b4fb3e-b7b88ae0000022f5-a8-4a3e74c7acc3 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id C0.57.08949.7C47E3A4; Sun, 21 Jun 2009 19:58:32 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 21 Jun 2009 19:58:31 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 21 Jun 2009 19:58:30 +0200 Received: from [131.160.126.167] (rvi2-126-167.lmf.ericsson.se [131.160.126.167]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0CBA3246A; Sun, 21 Jun 2009 20:58:31 +0300 (EEST) Message-ID: <4A3E74C7.9050403@ericsson.com> Date: Sun, 21 Jun 2009 20:58:31 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2009 17:58:31.0067 (UTC) FILETIME=[E317B6B0:01C9F299] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Call for consensus: location conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 17:58:20 -0000 Folks, we have the following milestone in our charter: Aug 2009 - Location Conveyance with SIP to IESG (PS) Does anybody object to adopting the following draft as the SIPCORE WG item for that milestone? http://tools.ietf.org/id/draft-ietf-sip-location-conveyance-13.txt This draft was WGLCed in the SIP WG some time ago. The draft received a few comments that will need to be addressed before we can move this draft forward. Cheers, Gonzalo SIPCORE co-chair From dean.willis@softarmor.com Mon Jun 22 10:58:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9902E3A6C85 for ; Mon, 22 Jun 2009 10:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pR5T2oBRTcp for ; Mon, 22 Jun 2009 10:58:58 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id DC56328C252 for ; Mon, 22 Jun 2009 10:58:57 -0700 (PDT) Received: from [192.168.2.102] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n5MHx9P3026604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jun 2009 12:59:10 -0500 Message-ID: <4A3FC668.4040405@softarmor.com> Date: Mon, 22 Jun 2009 12:59:04 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A3E74C7.9050403@ericsson.com> In-Reply-To: <4A3E74C7.9050403@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Call for consensus: location conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 17:58:58 -0000 Gonzalo Camarillo wrote: > Folks, > > we have the following milestone in our charter: > > Aug 2009 - Location Conveyance with SIP to IESG (PS) > > Does anybody object to adopting the following draft as the SIPCORE WG > item for that milestone? > > http://tools.ietf.org/id/draft-ietf-sip-location-conveyance-13.txt I object to the milestone. This isn't maintenance on the core SIP protocol. It ought to be in some other working group. But if we're going to insist on doing it here, you might as well start with that document. -- Dean From jmpolk@cisco.com Mon Jun 22 12:08:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44E543A6AF8 for ; Mon, 22 Jun 2009 12:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.033 X-Spam-Level: X-Spam-Status: No, score=-6.033 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evd1ya53ZHmm for ; Mon, 22 Jun 2009 12:08:08 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 475963A6801 for ; Mon, 22 Jun 2009 12:08:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,270,1243814400"; d="scan'208";a="329510815" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 22 Jun 2009 19:08:24 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5MJ8Oro017720; Mon, 22 Jun 2009 12:08:24 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n5MJ8N6m027001; Mon, 22 Jun 2009 19:08:23 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Jun 2009 12:08:23 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.6.63]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Jun 2009 12:08:23 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 22 Jun 2009 14:08:21 -0500 To: Dean Willis , Gonzalo Camarillo From: "James M. Polk" In-Reply-To: <4A3FC668.4040405@softarmor.com> References: <4A3E74C7.9050403@ericsson.com> <4A3FC668.4040405@softarmor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 22 Jun 2009 19:08:23.0363 (UTC) FILETIME=[D04F1130:01C9F36C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2331; t=1245697704; x=1246561704; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[sipcore]=20Call=20for=20consensus=3A=2 0location=20conveyance |Sender:=20; bh=Kf3rfjVVnWvm5XqEQ4r9LJwqEWvWEO7t5HxfjOWOXK0=; b=cKdTVBacZ/S9OB92pZtWvOcMw1eytA8UrclKzW9C38VLuYdamK6KehmIdD XYq9WLsSEXtB1v2Q7c7Lk9HuXBHA2ufRjqeUoUE62MUUz8vTMt968TzXmEbH V3sJm0OglZS94XQxPC0qLSZ9A9DEFnntn8aujnY+XlZJFDNXNDOqk=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Call for consensus: location conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 19:08:09 -0000 At 12:59 PM 6/22/2009, Dean Willis wrote: >Gonzalo Camarillo wrote: >>Folks, >>we have the following milestone in our charter: >>Aug 2009 - Location Conveyance with SIP to IESG (PS) >>Does anybody object to adopting the following draft as the SIPCORE >>WG item for that milestone? >>http://tools.ietf.org/id/draft-ietf-sip-location-conveyance-13.txt > >I object to the milestone. This isn't maintenance on the core SIP protocol. neither is any of these: >To: draft-ietf-sip-199@tools.ietf.org, > draft-ietf-sip-location-conveyance@tools.ietf.org, > draft-ietf-sip-sec-flows@tools.ietf.org, > draft-ietf-sipping-presence-scaling-requirements@tools.ietf.org, > draft-ietf-sip-info-events@tools.ietf.org, > draft-ietf-sipcore-subnot-etags@tools.ietf.org yet they are also in the SIPCORE WG - as legacy items that are supposed to be really close to getting done. I believe once these are done, nothing else is to go into SIPCORE other than SIP maintenance stuff (like 3265bis). >It ought to be in some other working group. What WG do any of the above 6 IDs go into? I'd argue that only Conveyance has a prayer of another WG, but that WG isn't up on all the SIP specific stuff (what's allowed in SIP headers or option tags or rules for insertion of information by intermediaries). This ID does nothing to the PIDF-LO, that Geopriv does know about, that this ID specifies how to carry. I'd say nearly everyone that attends SIPCORE comes from SIP, therefore they have the (very long) history of this ID in mind. I believe this -00 version is ready for the next and last WGLC, and nits can be fixed coming out of that review before this goes to the IESG. The -00 is significantly easier to read, as that is the primary change from the SIP-13 version. I completely rewrote the Intro and Overview sections, cutting the Intro to 4 paragraphs. I added a few message flow figures to the Overview to aid that explanation. >But if we're going to insist on doing it here, you might as well >start with that document. boy, that's a reluctant endorsement... thanks! James >-- >Dean >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From gonzalo.camarillo@ericsson.com Mon Jun 22 13:15:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1C043A6C1F for ; Mon, 22 Jun 2009 13:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fkuCfyoaYYx for ; Mon, 22 Jun 2009 13:15:06 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id EE5803A6C3C for ; Mon, 22 Jun 2009 13:14:20 -0700 (PDT) X-AuditID: c1b4fb3e-b7b99ae0000070a2-29-4a3fe61fca6e Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 9C.B5.28834.F16EF3A4; Mon, 22 Jun 2009 22:14:23 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jun 2009 22:14:21 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Jun 2009 22:14:20 +0200 Received: from [131.160.126.167] (rvi2-126-167.lmf.ericsson.se [131.160.126.167]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 10AEA244E; Mon, 22 Jun 2009 23:14:20 +0300 (EEST) Message-ID: <4A3FE61C.7040304@ericsson.com> Date: Mon, 22 Jun 2009 23:14:20 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dean Willis References: <4A3E74C7.9050403@ericsson.com> <4A3FC668.4040405@softarmor.com> In-Reply-To: <4A3FC668.4040405@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2009 20:14:20.0641 (UTC) FILETIME=[0707C510:01C9F376] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Call for consensus: location conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 20:15:06 -0000 Hi Dean, inline: Dean Willis wrote: > Gonzalo Camarillo wrote: >> Folks, >> >> we have the following milestone in our charter: >> >> Aug 2009 - Location Conveyance with SIP to IESG (PS) >> >> Does anybody object to adopting the following draft as the SIPCORE WG >> item for that milestone? >> >> http://tools.ietf.org/id/draft-ietf-sip-location-conveyance-13.txt > > I object to the milestone. This isn't maintenance on the core SIP > protocol. It ought to be in some other working group. we agreed on the milestones for the WG a long time ago. Here we are talking about adopting a particular draft for an already existing milestone. > But if we're going to insist on doing it here, you might as well start > with that document. yes, this is an answer to the question we were asking above. We had already announced (see link below) that we intended to use this draft for that milestone. We just wanted to confirm that people were OK with using that document. http://www.ietf.org/mail-archive/web/sipcore/current/msg00004.html Thanks, Gonzalo From dean.willis@softarmor.com Mon Jun 22 13:20:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC4793A6B89 for ; Mon, 22 Jun 2009 13:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXWR-IqtYt33 for ; Mon, 22 Jun 2009 13:20:54 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E11E23A67C0 for ; Mon, 22 Jun 2009 13:20:53 -0700 (PDT) Received: from [192.168.2.102] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n5MKL61P028176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Jun 2009 15:21:08 -0500 Message-ID: <4A3FE7AD.4040901@softarmor.com> Date: Mon, 22 Jun 2009 15:21:01 -0500 From: Dean Willis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "James M. Polk" References: <4A3E74C7.9050403@ericsson.com> <4A3FC668.4040405@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Call for consensus: location conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 20:20:54 -0000 James M. Polk wrote: > At 12:59 PM 6/22/2009, Dean Willis wrote: >> I object to the milestone. This isn't maintenance on the core SIP >> protocol. > > > neither is any of these: > >> To: draft-ietf-sip-199@tools.ietf.org, >> draft-ietf-sip-location-conveyance@tools.ietf.org, >> draft-ietf-sip-sec-flows@tools.ietf.org, >> draft-ietf-sipping-presence-scaling-requirements@tools.ietf.org, >> draft-ietf-sip-info-events@tools.ietf.org, >> draft-ietf-sipcore-subnot-etags@tools.ietf.org > > > yet they are also in the SIPCORE WG - as legacy items that are supposed > to be really close to getting done. I believe once these are done, > nothing else is to go into SIPCORE other than SIP maintenance stuff > (like 3265bis). Yep. That's the plan. I just don't like it very much. As a self appointed grouchy old man, it's my privilege to whine about it between flea-scratching sessions, and the fleas have been vicious this year so I'm way behind on my whining. I hope to do some catching-up this week. -- Dean From gonzalo.camarillo@ericsson.com Tue Jun 23 00:33:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8EEA3A6E41 for ; Tue, 23 Jun 2009 00:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ji88EM7FsgJW for ; Tue, 23 Jun 2009 00:33:22 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 924C23A6922 for ; Tue, 23 Jun 2009 00:33:21 -0700 (PDT) X-AuditID: c1b4fb3c-b7b0bae00000673a-ef-4a408540a958 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id DA.9B.26426.045804A4; Tue, 23 Jun 2009 09:33:20 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 09:33:21 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 09:33:21 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8D9D3246A for ; Tue, 23 Jun 2009 10:33:19 +0300 (EEST) Message-ID: <4A40853F.8010102@ericsson.com> Date: Tue, 23 Jun 2009 10:33:19 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: SIPCORE References: <4A3227D2.4020808@ericsson.com> In-Reply-To: <4A3227D2.4020808@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jun 2009 07:33:21.0358 (UTC) FILETIME=[E263D6E0:01C9F3D4] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Milestone to revise RFC 3265: Conclusion X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 07:33:23 -0000 Hi, based on all the responses received, there is agreement that the WG should work on revising RFC 3265 and that this draft is a good starting point for that. Therefore, I will ask our ADs to add a milestone to revise RFC 3265 and the author of the draft to submit it as a SIPCORE WG item. Keith brought up two good questions about the scope of this effort that we need to resolve (while he agrees on a limited-scope update that would preserve backwards compatibility, he would object to a wider scope). The first discussions on this topic need to deal with those questions in order to reach an agreement on the actual scope of this effort. Thanks, Gonzalo SIPCORE cochair Gonzalo Camarillo wrote: > Folks, > > since the publication of RFC 3265, we have gotten significant experience > deploying SIP-based notification systems. It has been proposed to revise > RFC 3265 based on that experience. We have two questions for the WG: > > 1) should we add a milestone to our charter to revise RFC 3265? > > 2) if we add such a milestone, should we take the following draft as the > initial WG item for the milestone? > > http://tools.ietf.org/html/draft-roach-sipcore-rfc3265bis-00 > > Thanks, > > Gonzalo > SIPCORE co-chair > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From root@core3.amsl.com Tue Jun 23 10:00:01 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E4E3D28C3DF; Tue, 23 Jun 2009 10:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090623170001.E4E3D28C3DF@core3.amsl.com> Date: Tue, 23 Jun 2009 10:00:01 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D ACTION:draft-ietf-sipcore-location-conveyance-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 17:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Location Conveyance for the Session Initiation Protocol Author(s) : J. Polk, B. Rosen Filename : draft-ietf-sipcore-location-conveyance-00.txt Pages : 45 Date : 2009-6-18 This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension covers end to end conveyance as well as location-based routing, where SIP servers make routing decisions based on the location of the user agent clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-location-conveyance-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-6-23095733.I-D@ietf.org> --NextPart-- From ian.elz@ericsson.com Wed Jun 24 01:14:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D26BF3A6D48 for ; Wed, 24 Jun 2009 01:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXYNYwimjo8F for ; Wed, 24 Jun 2009 01:14:10 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 988B028C424 for ; Wed, 24 Jun 2009 01:14:01 -0700 (PDT) X-AuditID: c1b4fb3c-b7ba8ae0000072d6-50-4a41dc4ec541 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 62.E6.29398.E4CD14A4; Wed, 24 Jun 2009 09:57:02 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jun 2009 09:56:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jun 2009 09:57:21 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 4244bis and privacy Thread-Index: Acn0Lcc7X7sq6TfYRnWN9a4W8C0fHQAARIBQAADAA2AAGracUA== References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com> From: "Ian Elz" To: "Mary Barnes" X-OriginalArrivalTime: 24 Jun 2009 07:56:58.0711 (UTC) FILETIME=[599C7E70:01C9F4A1] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 08:14:11 -0000 Mary, [I have added the list to this thread for wider comment.] In the previous discussions I commented that in RFC4424 that a Privacy header with value "history" effectively makes all H-I entries private with the result that the H-I entries may be removed. There has now been a comprehensive discussion on indication of the initial 'target' to the final recipient for call handling purposes. The main use case related to a freephone example where the answering location may be a call centre where the original freephone number may be required for correct call handling. If you now consider the following example (modified from Francois' text in the latest draft - excuse any errors that I may have inserted) INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx Privacy: history History-Info: ;index=3D1;rt;aor = (1) History-Info: ;index=3D1.1;mp;aor (2) History-Info: ;index=3D1.1.1;rc (3) In this case due to the Privacy header all of the H-I entries are considered private and the +18001234567 will not be delivered to the final destination with the result that call handling may not be correct. The Privacy header may have been inserted by any of the nodes which routed the message and inserted a H-I entry. If however the H-I was allowed to include a header parameter of "?Privacy=3Dnone" in the H-I entry and that an explicit H-I entry = privacy value would be considered to have precedence over a Privacy header with a value of "history" then the mapping of the +18001234567 could be explicitly specified as not private and may be passed on. Thus when the mapping from sip:+18001234567@example.com to sip:bob@biloxi.example.com when H-I entry (2) above is included could also insert the Privacy header parameter in H-I entry (1). Thus the message would appear as follows: INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx Privacy: history History-Info: ;index=3D= 1;rt;ao r History-Info: ;index=3D1.1;mp;aor History-Info: ;index=3D1.1.1;rc This would result in all the H-I entries except (1) being considered private with the result that the =3D1800... Number is passed for call handling purposes. This change is backward compatible with the existing implementation as any node using the existing functionality as defined in RFC4244 will continue to be supported. The alternative is to remove the ability to include the value "history" in the Privacy header and only allow this value in the Privacy header parameter. This alternative is not backward compatible. Without this change a single node in the message path which includes a header "Privacy: history" will prevent delivery of the aor and thus prevent proper call handling. Ian Elz -----Original Message----- From: Christer Holmberg=20 Sent: 23 June 2009 19:40 To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida Schubert Cc: Ian Elz Subject: RE: 4244bis and privacy =20 Hi, I include Ian, so he can comment to your resposne himself. Regards, Christer -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Tuesday, June 23, 2009 9:40 PM To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida Schubert Subject: RE: 4244bis and privacy Here was the thread of response and the last comment was from Ian that he would consider the response: http://www.ietf.org/mail-archive/web/sip/current/msg26948.html And, there was not agreement on the "none" but rather to qualify the SHOULD NOT forward. However, in the sipcore-4244bis-00, rather than changing the text such that the headers SHOULD be removed, we recommend that they be anonymized (in section 4.3.3.3.1). That is entirely consistent with RFC 3324 and thus we have removed the recommendations to remove the headers entirely. However, that changed never got done in section 3.2, so we would need to change this: "Thus, the History- Info header SHOULD NOT be included in Requests where the requestor has indicated a priv-value of Session- or Header-level privacy." But, I'm really beginning to be of the mindset that we should just remove all the subsections of section 3 (i.e., leave the text in the upper level section), so we don't have to keep worrying about consistency. So, lets either fixt the text in 3.2 or remove altogether and then I think we are really at the point of needing to submit this version so folks that actually have an interest in it can review the updated document.=20 Mary.=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, June 23, 2009 1:10 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik van Elburg; Shida Schubert Subject: 4244bis and privacy Hi, Below is a comment/proposal which one of my collegues (Ian Elz) gave on the list a while ago, when the first version of 4244bis was submitted, but was not incorporated. Do you think it would be useful? ------- While the HI approach to target may solve the problem of being able to deliver the target URI to the final destination there is no guarantee that it will actually be delivered. The problem arises with how Privacy is defined for HI. 4424 defines a new Privacy value "history" which may be placed in either the Privacy header or as a header parameter to the HI entry. If one node uses the former option "Privacy: history" then this will make all headers private and will result in all HI entries being removed or made anonymous when the message containing the HI is delivered to the user. There is a simple solution to this and that is to also allow the use of the "none" Privacy value as a header parameter in the HI entry. This would explicitly state that no privacy is required to the HI entry and this would override a "history" value in the Privacy header. I pointed this out to Mary when the 4424bis draft was first published but the change has not been made in the latest draft. The change is backward compatible and would not cause an issue with any existing implementations. ------ Regards, Christer From gonzalo.camarillo@ericsson.com Wed Jun 24 04:31:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B1063A6F75 for ; Wed, 24 Jun 2009 04:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8x5M1V8c25Z for ; Wed, 24 Jun 2009 04:31:56 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 237263A6BFA for ; Wed, 24 Jun 2009 04:31:55 -0700 (PDT) X-AuditID: c1b4fb3c-b7bdcae0000052f9-c5-4a420eb409c8 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id D3.E8.21241.4BE024A4; Wed, 24 Jun 2009 13:32:04 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jun 2009 13:32:03 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jun 2009 13:32:03 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id DBEBA244E; Wed, 24 Jun 2009 14:32:03 +0300 (EEST) Message-ID: <4A420EB3.6020308@ericsson.com> Date: Wed, 24 Jun 2009 14:32:03 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: sipcore@ietf.org References: <20090504221501.62CC83A6C6D@core3.amsl.com> <4A15D085.9070704@nostrum.com> In-Reply-To: <4A15D085.9070704@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jun 2009 11:32:03.0852 (UTC) FILETIME=[65ACBCC0:01C9F4BF] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-sec-flows-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 11:31:57 -0000 Folks, we would like to encourage people once more to have a look at this draft and send their comments to the list. Thanks, Gonzalo SIPCORE co-chair Adam Roach wrote: > [as chair] > > I'd like to thank Brian for taking over editorship of this document, > which has been mostly complete (pending some syntax issues) for several > years now. Keeping in mind that this document is an adopted SIPCORE > working group item, I would encourage everyone to read over it, and > provide comments to the list. Even a quick note saying something like "I > read through this, understood it, and think the examples are correct" is > useful. > > Of course, something like "I untarred the examples and independently > verified them with my own implementation" would be spectacular. > > /a > > > Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Session Initiation Protocol Core >> Working Group of the IETF. >> >> >> Title : Example call flows using Session Initiation >> Protocol (SIP) security mechanisms >> Author(s) : C. Jennings, et al. >> Filename : draft-ietf-sipcore-sec-flows-00.txt >> Pages : 59 >> Date : 2009-05-04 >> >> This document shows example call flows demonstrating the use of >> Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail >> Extensions (S/MIME) in Session Initiation Protocol (SIP). It also >> provides information that helps implementers build interoperable SIP >> software. To help facilitate interoperability testing, it includes >> certificates used in the example call flows and processes to create >> certificates for testing. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-sec-flows-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 mary.barnes@nortel.com Wed Jun 24 07:47:07 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD5823A6F73 for ; Wed, 24 Jun 2009 07:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.294 X-Spam-Level: X-Spam-Status: No, score=-6.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85I2LkiK+e4G for ; Wed, 24 Jun 2009 07:47:06 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E11483A6CAC for ; Wed, 24 Jun 2009 07:47:05 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5OEjfI23778; Wed, 24 Jun 2009 14:45:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jun 2009 09:47:56 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 4244bis and privacy thread-index: Acn0Lcc7X7sq6TfYRnWN9a4W8C0fHQAARIBQAADAA2AAGracUAAO1MaQ References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Ian Elz" Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 14:47:07 -0000 Hi Ian, I do not believe we should do the "override" behavior as I think that violates RFC 3323, as the "history" is really a subset of the cases whereby a UAC or proxy would add "session" or "header" to the request. And, the latter two cases have the same (undesireable) result. I agree this impacts your services, but we can't mandate that proxies provide information that might violate their local policies and indeed a proxy's local policies can result in the information being anonymized (or removed if they can't anonymize) even in the "none" case.=20 I do believe it's reasonable that we strongly recommend that the request level (versus specific hi-entries) not be used and if it is used, the consequence is that some services will not have the information they need - this was the gist of my previous response (to which I did not get any additional feedback). Now, we could add some text that the "none" case SHOULD be used (e.g., added by first hop proxy) if it is desired that the information not be subject to privacy restrictions. I do not think it is then particularly useful to add logic around the proxy then being able to tag the entries within their domain as subject to privacy. I think that conflicts with the intent of the request level "none". However, as I mention above, per the current text, a proxy can (based on local policy) remove entries - so a proxy can capture hi within their domain and not forward any of that information to the next hop in another domain - you already have that functionality. But, I think this introduces the general problem that you might be impacting other services further down the line, which I thought was the problem you were wanting to solve - not specifically your example service but, for example, in the case that someone is debugging and they want the entire history, so depending upon the service, this is also undesirable behavior. =20 Regards, Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com]=20 Sent: Wednesday, June 24, 2009 2:57 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Audet, Francois (SC100:3055) Subject: RE: 4244bis and privacy Mary, [I have added the list to this thread for wider comment.] In the previous discussions I commented that in RFC4424 that a Privacy header with value "history" effectively makes all H-I entries private with the result that the H-I entries may be removed. There has now been a comprehensive discussion on indication of the initial 'target' to the final recipient for call handling purposes. The main use case related to a freephone example where the answering location may be a call centre where the original freephone number may be required for correct call handling. If you now consider the following example (modified from Francois' text in the latest draft - excuse any errors that I may have inserted) INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx Privacy: history History-Info: ;index=3D1;rt;aor = (1) History-Info: ;index=3D1.1;mp;aor (2) History-Info: ;index=3D1.1.1;rc (3) In this case due to the Privacy header all of the H-I entries are considered private and the +18001234567 will not be delivered to the final destination with the result that call handling may not be correct. The Privacy header may have been inserted by any of the nodes which routed the message and inserted a H-I entry. If however the H-I was allowed to include a header parameter of "?Privacy=3Dnone" in the H-I entry and that an explicit H-I entry = privacy value would be considered to have precedence over a Privacy header with a value of "history" then the mapping of the +18001234567 could be explicitly specified as not private and may be passed on. Thus when the mapping from sip:+18001234567@example.com to sip:bob@biloxi.example.com when H-I entry (2) above is included could also insert the Privacy header parameter in H-I entry (1). Thus the message would appear as follows: INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx Privacy: history History-Info: ;index=3D= 1;rt;ao r History-Info: ;index=3D1.1;mp;aor History-Info: ;index=3D1.1.1;rc This would result in all the H-I entries except (1) being considered private with the result that the =3D1800... Number is passed for call handling purposes. This change is backward compatible with the existing implementation as any node using the existing functionality as defined in RFC4244 will continue to be supported. The alternative is to remove the ability to include the value "history" in the Privacy header and only allow this value in the Privacy header parameter. This alternative is not backward compatible. Without this change a single node in the message path which includes a header "Privacy: history" will prevent delivery of the aor and thus prevent proper call handling. Ian Elz -----Original Message----- From: Christer Holmberg Sent: 23 June 2009 19:40 To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida Schubert Cc: Ian Elz Subject: RE: 4244bis and privacy =20 Hi, I include Ian, so he can comment to your resposne himself. Regards, Christer -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Tuesday, June 23, 2009 9:40 PM To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida Schubert Subject: RE: 4244bis and privacy Here was the thread of response and the last comment was from Ian that he would consider the response: http://www.ietf.org/mail-archive/web/sip/current/msg26948.html And, there was not agreement on the "none" but rather to qualify the SHOULD NOT forward. However, in the sipcore-4244bis-00, rather than changing the text such that the headers SHOULD be removed, we recommend that they be anonymized (in section 4.3.3.3.1). That is entirely consistent with RFC 3324 and thus we have removed the recommendations to remove the headers entirely. However, that changed never got done in section 3.2, so we would need to change this: "Thus, the History- Info header SHOULD NOT be included in Requests where the requestor has indicated a priv-value of Session- or Header-level privacy." But, I'm really beginning to be of the mindset that we should just remove all the subsections of section 3 (i.e., leave the text in the upper level section), so we don't have to keep worrying about consistency. So, lets either fixt the text in 3.2 or remove altogether and then I think we are really at the point of needing to submit this version so folks that actually have an interest in it can review the updated document.=20 Mary.=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, June 23, 2009 1:10 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik van Elburg; Shida Schubert Subject: 4244bis and privacy Hi, Below is a comment/proposal which one of my collegues (Ian Elz) gave on the list a while ago, when the first version of 4244bis was submitted, but was not incorporated. Do you think it would be useful? ------- While the HI approach to target may solve the problem of being able to deliver the target URI to the final destination there is no guarantee that it will actually be delivered. The problem arises with how Privacy is defined for HI. 4424 defines a new Privacy value "history" which may be placed in either the Privacy header or as a header parameter to the HI entry. If one node uses the former option "Privacy: history" then this will make all headers private and will result in all HI entries being removed or made anonymous when the message containing the HI is delivered to the user. There is a simple solution to this and that is to also allow the use of the "none" Privacy value as a header parameter in the HI entry. This would explicitly state that no privacy is required to the HI entry and this would override a "history" value in the Privacy header. I pointed this out to Mary when the 4424bis draft was first published but the change has not been made in the latest draft. The change is backward compatible and would not cause an issue with any existing implementations. ------ Regards, Christer From mary.barnes@nortel.com Wed Jun 24 09:25:36 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60C023A6CD9 for ; Wed, 24 Jun 2009 09:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNYR5vYa28nm for ; Wed, 24 Jun 2009 09:25:34 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 3670A3A6813 for ; Wed, 24 Jun 2009 09:25:33 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5OGOgG01175; Wed, 24 Jun 2009 16:24:42 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jun 2009 11:26:41 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 4244bis and privacy thread-index: Acn0Lcc7X7sq6TfYRnWN9a4W8C0fHQAARIBQAADAA2AAGracUAAO1MaQAAH7tqAAAL/rAA== References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Ian Elz" Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 16:25:36 -0000 Hi Ian, Responses inline below [MB]. Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com]=20 Sent: Wednesday, June 24, 2009 10:37 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Audet, Francois (SC100:3055) Subject: RE: 4244bis and privacy Mary, I was not proposing that we change the handling of H-I which is based upon local policy. If that causes an issue for a network operator then they can modify their local policy accordingly or arrange with the proxy vendor to modify their equipment to be more flexible with regards to policy. Can you clarify for me: If you have a Privacy header with either "session" or "header" doe this impact the H-I entries or will only a value of "history" impact the H-I entries? [MB] Yes, both "session" and "header" level privacy, consistent with RFC 3323, mandate that entries be anonymized or dropped, with the latter being the recommendation for "session" level privacy. RFC 4244 mandated that they be dropped and 4244bis recommends they be anonymized. The original intent for the value of "history" was for the tagging of the individual entries, but you end up getting the header level functionality as well. [/MB]=20 If you have a Privacy header with a value of "none" and a H-I entry with Privacy header parameter with value "history" what is the privacy of the individual H-I entry? [MB] We did not explicitly address the "none" in RFC 4244, but the general statement is the privacy headers at the request level override any at the hi-entry level. [/MB] >From reading RFC4244 a Privacy header with value "history" will effectively make all H-I entries private and there is currently no option to include a H-I Privacy header parameter with value "none". [MB] Correct, per my comment above. [/MB] H-I at present allows the inclusion of Privacy header parameters to explicitly express privacy for an individual H-I entry but a single node which includes a header "Privacy: history" makes all H-I entries private even if this is not the requirements for the specific URI. [MB] Correct, but the only node that should add the header is a node which is responsible for the domain associated with the Request URI in the incoming request or is authorized to do so. [/MB] I will admit that having worked in a telephony environment for a long time I am used to having privacy of identities set on a per number basis and the relative inflexibility of the IETF Privacy header is relatively restrictive as to specifying which identities may be presented and which not. [MB] Yes, this is an entirely different paradigm. I developed telephony s/w for over a decade and this is entirely different - it provides a lot more flexibility, which makes things far, far less deterministic than what you have in telephony switches where your routing and translations are configured for the most part, with just a few capabilities for controlling the privacy and it's a closed network. =20 With RFC4244/4244bis, there MUST be a mechanism at the UAS or end application that can handle a request that doesn't have the appropriate information either because nodes didn't support History-Info or some random node in the network applied privacy (which I think is highly unlikely) - this is normative per section 5 of RFC 4244. So, the worst case scenario I see for this 800 service (which will get to the right UAS but without the exact 800 number that was dialed) is that it goes to a default ACD group/customer service agent, etc. who then needs to gather the appropriate information and in my experience this is often an IVR system these days. So, the service is not broken when privacy is applied in an undesireable manner, it's just not optimal. This is something that should be addressed in the target-uri draft which has all the details of how specific services use History-Info. One other thing to consider is that most networks that are emulating telephony type features use B2BUAs, which follow the UAS/UAC rules for the header rather than the proxy rules, noting that the UAC can set the Privacy header to whatever value it sees as appropriate for the request. [/MB] Regards=20 Ian -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: 24 June 2009 15:48 To: Ian Elz Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Francois Audet Subject: RE: 4244bis and privacy Hi Ian, I do not believe we should do the "override" behavior as I think that violates RFC 3323, as the "history" is really a subset of the cases whereby a UAC or proxy would add "session" or "header" to the request. And, the latter two cases have the same (undesireable) result. I agree this impacts your services, but we can't mandate that proxies provide information that might violate their local policies and indeed a proxy's local policies can result in the information being anonymized (or removed if they can't anonymize) even in the "none" case.=20 I do believe it's reasonable that we strongly recommend that the request level (versus specific hi-entries) not be used and if it is used, the consequence is that some services will not have the information they need - this was the gist of my previous response (to which I did not get any additional feedback). Now, we could add some text that the "none" case SHOULD be used (e.g., added by first hop proxy) if it is desired that the information not be subject to privacy restrictions. I do not think it is then particularly useful to add logic around the proxy then being able to tag the entries within their domain as subject to privacy. I think that conflicts with the intent of the request level "none". However, as I mention above, per the current text, a proxy can (based on local policy) remove entries - so a proxy can capture hi within their domain and not forward any of that information to the next hop in another domain - you already have that functionality. But, I think this introduces the general problem that you might be impacting other services further down the line, which I thought was the problem you were wanting to solve - not specifically your example service but, for example, in the case that someone is debugging and they want the entire history, so depending upon the service, this is also undesirable behavior. =20 Regards, Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Wednesday, June 24, 2009 2:57 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Audet, Francois (SC100:3055) Subject: RE: 4244bis and privacy Mary, [I have added the list to this thread for wider comment.] In the previous discussions I commented that in RFC4424 that a Privacy header with value "history" effectively makes all H-I entries private with the result that the H-I entries may be removed. There has now been a comprehensive discussion on indication of the initial 'target' to the final recipient for call handling purposes. The main use case related to a freephone example where the answering location may be a call centre where the original freephone number may be required for correct call handling. If you now consider the following example (modified from Francois' text in the latest draft - excuse any errors that I may have inserted) INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx Privacy: history History-Info: ;index=3D1;rt;aor = (1) History-Info: ;index=3D1.1;mp;aor (2) History-Info: ;index=3D1.1.1;rc (3) In this case due to the Privacy header all of the H-I entries are considered private and the +18001234567 will not be delivered to the final destination with the result that call handling may not be correct. The Privacy header may have been inserted by any of the nodes which routed the message and inserted a H-I entry. If however the H-I was allowed to include a header parameter of "?Privacy=3Dnone" in the H-I entry and that an explicit H-I entry = privacy value would be considered to have precedence over a Privacy header with a value of "history" then the mapping of the +18001234567 could be explicitly specified as not private and may be passed on. Thus when the mapping from sip:+18001234567@example.com to sip:bob@biloxi.example.com when H-I entry (2) above is included could also insert the Privacy header parameter in H-I entry (1). Thus the message would appear as follows: INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx Privacy: history History-Info: ;index=3D= 1;rt;ao r History-Info: ;index=3D1.1;mp;aor History-Info: ;index=3D1.1.1;rc This would result in all the H-I entries except (1) being considered private with the result that the =3D1800... Number is passed for call handling purposes. This change is backward compatible with the existing implementation as any node using the existing functionality as defined in RFC4244 will continue to be supported. The alternative is to remove the ability to include the value "history" in the Privacy header and only allow this value in the Privacy header parameter. This alternative is not backward compatible. Without this change a single node in the message path which includes a header "Privacy: history" will prevent delivery of the aor and thus prevent proper call handling. Ian Elz -----Original Message----- From: Christer Holmberg Sent: 23 June 2009 19:40 To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida Schubert Cc: Ian Elz Subject: RE: 4244bis and privacy =20 Hi, I include Ian, so he can comment to your resposne himself. Regards, Christer -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Tuesday, June 23, 2009 9:40 PM To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida Schubert Subject: RE: 4244bis and privacy Here was the thread of response and the last comment was from Ian that he would consider the response: http://www.ietf.org/mail-archive/web/sip/current/msg26948.html And, there was not agreement on the "none" but rather to qualify the SHOULD NOT forward. However, in the sipcore-4244bis-00, rather than changing the text such that the headers SHOULD be removed, we recommend that they be anonymized (in section 4.3.3.3.1). That is entirely consistent with RFC 3324 and thus we have removed the recommendations to remove the headers entirely. However, that changed never got done in section 3.2, so we would need to change this: "Thus, the History- Info header SHOULD NOT be included in Requests where the requestor has indicated a priv-value of Session- or Header-level privacy." But, I'm really beginning to be of the mindset that we should just remove all the subsections of section 3 (i.e., leave the text in the upper level section), so we don't have to keep worrying about consistency. So, lets either fixt the text in 3.2 or remove altogether and then I think we are really at the point of needing to submit this version so folks that actually have an interest in it can review the updated document.=20 Mary.=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, June 23, 2009 1:10 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik van Elburg; Shida Schubert Subject: 4244bis and privacy Hi, Below is a comment/proposal which one of my collegues (Ian Elz) gave on the list a while ago, when the first version of 4244bis was submitted, but was not incorporated. Do you think it would be useful? ------- While the HI approach to target may solve the problem of being able to deliver the target URI to the final destination there is no guarantee that it will actually be delivered. The problem arises with how Privacy is defined for HI. 4424 defines a new Privacy value "history" which may be placed in either the Privacy header or as a header parameter to the HI entry. If one node uses the former option "Privacy: history" then this will make all headers private and will result in all HI entries being removed or made anonymous when the message containing the HI is delivered to the user. There is a simple solution to this and that is to also allow the use of the "none" Privacy value as a header parameter in the HI entry. This would explicitly state that no privacy is required to the HI entry and this would override a "history" value in the Privacy header. I pointed this out to Mary when the 4424bis draft was first published but the change has not been made in the latest draft. The change is backward compatible and would not cause an issue with any existing implementations. ------ Regards, Christer From jmpolk@cisco.com Wed Jun 24 11:56:40 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D78B328C4CC for ; Wed, 24 Jun 2009 11:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.117 X-Spam-Level: X-Spam-Status: No, score=-6.117 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZh9lM-8eIbW for ; Wed, 24 Jun 2009 11:56:39 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id CFA2C28C4F4 for ; Wed, 24 Jun 2009 11:56:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,284,1243814400"; d="scan'208";a="331073782" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 24 Jun 2009 18:56:29 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5OIuTMR002338 for ; Wed, 24 Jun 2009 11:56:29 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5OIuTVo004821 for ; Wed, 24 Jun 2009 18:56:29 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2009 11:56:29 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.0.154]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2009 11:56:29 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 24 Jun 2009 13:56:27 -0500 To: sipcore@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 24 Jun 2009 18:56:29.0175 (UTC) FILETIME=[7B722070:01C9F4FD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2835; t=1245869789; x=1246733789; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20SIPCORE=20Location=20Conveyance=20-00=20submitt ed |Sender:=20; bh=I2DHaowjG1TaYHd/GSPyzBtwZBPbw4BL4UYWo/xtst4=; b=hC8yUJDN+jJiWuJGO/uUf6kQilg9Qq/U2qiDIbcNZFo6F1wVqby1nA7yyn CB63MPWw9+kgcKG03gZEcwlr2B0MMMF70bVKyntphuKJFyV2J/LMS3D7zhBt gv+HAx/PqL; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [sipcore] SIPCORE Location Conveyance -00 submitted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 18:56:40 -0000 SIPCORE WG I have just submitted draft-ietf-sipcore-location-conveyance-00.txt here http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-00.txt This is the subsequent version from SIP Location Conveyance -13. Here's what's changed in SIPCORE-00 compared to the SIP-13 version: - Understanding that readability was a main concern - I reduced the Intro section to 4 paragraphs (less than half of what was in -13) - simplified the Overview section, added a couple of flow figures to show how location is transmitted within a SIP request in a message body, and as a URI reference similar to content indirection. - moved some of the Intro text to the Overview section, but cut out a lot of what was in the Overview section that is explained later in the draft. - Removed all the UA-1 vs UA-2 stuff, and replaced it with Alice and Bob references, making this easier to read. - I reduced the terminology section, and what was left that was already defined in another RFC, is now the same text from that RFC (which is also referenced each time). - I toned down the 2119 text for servers inserting location into a request from SHOULD NOT to not RECOMMENDED, based on WG comment. - I added RFC5491 (PIDF-LO Usage) and RFC 4483 (SIP Content Indirection) as references. - I removed text saying future error codes can be specified in each category, as that seems to confuse some about the meaning of this. But added text saying more granular error codes that have the same action by a UA can be created. - I'm not an S/MIME expert, and was told (a long time ago) it can be used just for signing, and not encrypting. Two from this WG seemed to adamantly disagree with this, so I removed that text about signing only. - Clarified a point that is allowed in PIDF-LO, and that SIP shouldn't attempt to overcome this - that if Bob sends Alice his location, and sets his to "yes"; within the time (in which the location is still valid), if Bob transfers Alice to Carol, that PIDF-LO privacy rules implicitly allow Alice to tell Carol where Bob is. This came up in another forum, and is a current byproduct of the policy rules within the PIDF-LO and this document cannot overcome those. A benefit to this policy is that if Alice calls for emergency help, and somehow is routed to the wrong PSAP (emergency call center), PSAP-1 can transfer Alice's location to PSAP-2 (i.e., the correct PSAP serving Alice's area). Therefore, this PIDF-LO policy is not necessarily a hole. BTW - the default value of has always been to "no". - I removed the term sighter from the doc (a legacy term within Geopriv), and replaced it with locator. Comments are welcome James From ian.elz@ericsson.com Wed Jun 24 12:24:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 757BD3A6CCE for ; Wed, 24 Jun 2009 12:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooGEABQvYSFr for ; Wed, 24 Jun 2009 12:24:40 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A33DE28C4FE for ; Wed, 24 Jun 2009 12:24:07 -0700 (PDT) X-AuditID: c1b4fb3c-b7bdcae0000052f9-43-4a424801387b Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 97.14.21241.108424A4; Wed, 24 Jun 2009 17:36:33 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jun 2009 17:36:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jun 2009 17:36:54 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 4244bis and privacy Thread-Index: Acn0Lcc7X7sq6TfYRnWN9a4W8C0fHQAARIBQAADAA2AAGracUAAO1MaQAAH7tqA= References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com> From: "Ian Elz" To: "Mary Barnes" X-OriginalArrivalTime: 24 Jun 2009 15:36:33.0242 (UTC) FILETIME=[8D5003A0:01C9F4E1] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 19:24:42 -0000 Mary, I was not proposing that we change the handling of H-I which is based upon local policy. If that causes an issue for a network operator then they can modify their local policy accordingly or arrange with the proxy vendor to modify their equipment to be more flexible with regards to policy. Can you clarify for me: If you have a Privacy header with either "session" or "header" doe this impact the H-I entries or will only a value of "history" impact the H-I entries? If you have a Privacy header with a value of "none" and a H-I entry with Privacy header parameter with value "history" what is the privacy of the individual H-I entry? >From reading RFC4244 a Privacy header with value "history" will effectively make all H-I entries private and there is currently no option to include a H-I Privacy header parameter with value "none". H-I at present allows the inclusion of Privacy header parameters to explicitly express privacy for an individual H-I entry but a single node which includes a header "Privacy: history" makes all H-I entries private even if this is not the requirements for the specific URI. I will admit that having worked in a telephony environment for a long time I am used to having privacy of identities set on a per number basis and the relative inflexibility of the IETF Privacy header is relatively restrictive as to specifying which identities may be presented and which not. Regards=20 Ian -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: 24 June 2009 15:48 To: Ian Elz Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Francois Audet Subject: RE: 4244bis and privacy Hi Ian, I do not believe we should do the "override" behavior as I think that violates RFC 3323, as the "history" is really a subset of the cases whereby a UAC or proxy would add "session" or "header" to the request. And, the latter two cases have the same (undesireable) result. I agree this impacts your services, but we can't mandate that proxies provide information that might violate their local policies and indeed a proxy's local policies can result in the information being anonymized (or removed if they can't anonymize) even in the "none" case.=20 I do believe it's reasonable that we strongly recommend that the request level (versus specific hi-entries) not be used and if it is used, the consequence is that some services will not have the information they need - this was the gist of my previous response (to which I did not get any additional feedback). Now, we could add some text that the "none" case SHOULD be used (e.g., added by first hop proxy) if it is desired that the information not be subject to privacy restrictions. I do not think it is then particularly useful to add logic around the proxy then being able to tag the entries within their domain as subject to privacy. I think that conflicts with the intent of the request level "none". However, as I mention above, per the current text, a proxy can (based on local policy) remove entries - so a proxy can capture hi within their domain and not forward any of that information to the next hop in another domain - you already have that functionality. But, I think this introduces the general problem that you might be impacting other services further down the line, which I thought was the problem you were wanting to solve - not specifically your example service but, for example, in the case that someone is debugging and they want the entire history, so depending upon the service, this is also undesirable behavior. =20 Regards, Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Wednesday, June 24, 2009 2:57 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Audet, Francois (SC100:3055) Subject: RE: 4244bis and privacy Mary, [I have added the list to this thread for wider comment.] In the previous discussions I commented that in RFC4424 that a Privacy header with value "history" effectively makes all H-I entries private with the result that the H-I entries may be removed. There has now been a comprehensive discussion on indication of the initial 'target' to the final recipient for call handling purposes. The main use case related to a freephone example where the answering location may be a call centre where the original freephone number may be required for correct call handling. If you now consider the following example (modified from Francois' text in the latest draft - excuse any errors that I may have inserted) INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx Privacy: history History-Info: ;index=3D1;rt;aor = (1) History-Info: ;index=3D1.1;mp;aor (2) History-Info: ;index=3D1.1.1;rc (3) In this case due to the Privacy header all of the H-I entries are considered private and the +18001234567 will not be delivered to the final destination with the result that call handling may not be correct. The Privacy header may have been inserted by any of the nodes which routed the message and inserted a H-I entry. If however the H-I was allowed to include a header parameter of "?Privacy=3Dnone" in the H-I entry and that an explicit H-I entry = privacy value would be considered to have precedence over a Privacy header with a value of "history" then the mapping of the +18001234567 could be explicitly specified as not private and may be passed on. Thus when the mapping from sip:+18001234567@example.com to sip:bob@biloxi.example.com when H-I entry (2) above is included could also insert the Privacy header parameter in H-I entry (1). Thus the message would appear as follows: INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx Privacy: history History-Info: ;index=3D= 1;rt;ao r History-Info: ;index=3D1.1;mp;aor History-Info: ;index=3D1.1.1;rc This would result in all the H-I entries except (1) being considered private with the result that the =3D1800... Number is passed for call handling purposes. This change is backward compatible with the existing implementation as any node using the existing functionality as defined in RFC4244 will continue to be supported. The alternative is to remove the ability to include the value "history" in the Privacy header and only allow this value in the Privacy header parameter. This alternative is not backward compatible. Without this change a single node in the message path which includes a header "Privacy: history" will prevent delivery of the aor and thus prevent proper call handling. Ian Elz -----Original Message----- From: Christer Holmberg Sent: 23 June 2009 19:40 To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida Schubert Cc: Ian Elz Subject: RE: 4244bis and privacy =20 Hi, I include Ian, so he can comment to your resposne himself. Regards, Christer -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Tuesday, June 23, 2009 9:40 PM To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida Schubert Subject: RE: 4244bis and privacy Here was the thread of response and the last comment was from Ian that he would consider the response: http://www.ietf.org/mail-archive/web/sip/current/msg26948.html And, there was not agreement on the "none" but rather to qualify the SHOULD NOT forward. However, in the sipcore-4244bis-00, rather than changing the text such that the headers SHOULD be removed, we recommend that they be anonymized (in section 4.3.3.3.1). That is entirely consistent with RFC 3324 and thus we have removed the recommendations to remove the headers entirely. However, that changed never got done in section 3.2, so we would need to change this: "Thus, the History- Info header SHOULD NOT be included in Requests where the requestor has indicated a priv-value of Session- or Header-level privacy." But, I'm really beginning to be of the mindset that we should just remove all the subsections of section 3 (i.e., leave the text in the upper level section), so we don't have to keep worrying about consistency. So, lets either fixt the text in 3.2 or remove altogether and then I think we are really at the point of needing to submit this version so folks that actually have an interest in it can review the updated document.=20 Mary.=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, June 23, 2009 1:10 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik van Elburg; Shida Schubert Subject: 4244bis and privacy Hi, Below is a comment/proposal which one of my collegues (Ian Elz) gave on the list a while ago, when the first version of 4244bis was submitted, but was not incorporated. Do you think it would be useful? ------- While the HI approach to target may solve the problem of being able to deliver the target URI to the final destination there is no guarantee that it will actually be delivered. The problem arises with how Privacy is defined for HI. 4424 defines a new Privacy value "history" which may be placed in either the Privacy header or as a header parameter to the HI entry. If one node uses the former option "Privacy: history" then this will make all headers private and will result in all HI entries being removed or made anonymous when the message containing the HI is delivered to the user. There is a simple solution to this and that is to also allow the use of the "none" Privacy value as a header parameter in the HI entry. This would explicitly state that no privacy is required to the HI entry and this would override a "history" value in the Privacy header. I pointed this out to Mary when the 4424bis draft was first published but the change has not been made in the latest draft. The change is backward compatible and would not cause an issue with any existing implementations. ------ Regards, Christer From dworley@nortel.com Wed Jun 24 13:51:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A94C3A6C08 for ; Wed, 24 Jun 2009 13:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.666 X-Spam-Level: X-Spam-Status: No, score=-7.666 tagged_above=-999 required=5 tests=[AWL=0.933, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PQ06iXv1Lsv for ; Wed, 24 Jun 2009 13:51:47 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2C91C28C0FA for ; Wed, 24 Jun 2009 13:51:47 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5OKpbG22832 for ; Wed, 24 Jun 2009 20:51:38 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2009 16:51:26 -0400 From: "Dale Worley" To: SIPCORE Content-Type: text/plain Organization: Nortel Networks Date: Wed, 24 Jun 2009 16:51:25 -0400 Message-Id: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jun 2009 20:51:26.0507 (UTC) FILETIME=[8A9377B0:01C9F50D] Subject: [sipcore] draft-kaplan-sip-session-id-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 20:51:48 -0000 Looking at draft-kaplan-sip-session-id-02, the shorter the Session-Id header is, the fewer complaints people will have about using it in practice. A couple of things could be done to shorten it: - assign a single-letter abbreviation for the name - use base64 rather than hex encoding Base64 encoding reduces the header value to 22 characters from 32. Dale From dworley@nortel.com Wed Jun 24 14:18:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A523A6D67 for ; Wed, 24 Jun 2009 14:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.724 X-Spam-Level: X-Spam-Status: No, score=-6.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c07On7FvfmP2 for ; Wed, 24 Jun 2009 14:18:30 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 173463A6CF8 for ; Wed, 24 Jun 2009 14:18:29 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5OLH6028462 for ; Wed, 24 Jun 2009 21:17:06 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2009 17:18:33 -0400 From: "Dale Worley" To: SIPCORE Content-Type: text/plain Organization: Nortel Networks Date: Wed, 24 Jun 2009 17:18:32 -0400 Message-Id: <1245878312.3748.84.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jun 2009 21:18:33.0565 (UTC) FILETIME=[5460D0D0:01C9F511] Subject: [sipcore] draft-kaplan-sip-secure-call-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 21:18:31 -0000 The difficulty with draft-kaplan-sip-secure-call-id-00 is that it provides no mechanism for a B2BUA or other device to switch from Call-Id-obscuring to Call-Id-preserving behavior, even when the SIP elements involved are trying to cooperate. For example, suppose I'm a SIP network provider with Acme Packet SBCs at the boundary of my network. Currently, the SBCs obscure Call-Ids for reasons of commercial secrecy. If I replace some or all of the UAs in the network with ones that generate Call-Ids according to the draft, nothing happens -- there's no way for the SBCs to detect that the Call-IDs conform to the draft, and change their behavior. My only option is to update *all* the UAs, then reconfigure the SBCs to not obscure Call-Ids. This is probably unworkable even in enterprise PBX systems, much less walled-garden service provider networks -- and yet we want the mechanism to work in open and nearly-open SIP networks. What the draft needs is not the current "negative criterion" that enables B2BUAs to detect Call-Ids that definitely do not conform to the draft, but a "positive criterion" that enables B2BUAs to detect Call-Ids that *do* conform to the draft. We did this sort of thing before, with the "magic cookie" z9hG4bK in the branch value to distinguish RFC 3261 from RFC 2453 messages. So let us define the "new" Call-Id format to be: callid = "+)puK>" 22*( %x41-5A ; "A"-"Z" / %x61-7A ; "a"-"z" / %x30-39 ; "0"-"9" / "_" / "." / "!" ) That provides 132 bits of randomness in 28 characters, and most likely a string of that format has never existed in the history of the world. So when a B2BUA sees a Call-Id of that format, it can trust that the value was generated properly and can avoid changing it. Dale From Martin.Thomson@andrew.com Wed Jun 24 16:24:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390F028B23E for ; Wed, 24 Jun 2009 16:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sy883Z34lO8 for ; Wed, 24 Jun 2009 16:24:11 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 6483C3A6A8D for ; Wed, 24 Jun 2009 16:23:40 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_06_24_18_28_13 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 24 Jun 2009 18:28:13 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2009 18:06:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 24 Jun 2009 18:06:18 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] SIPCORE Location Conveyance -00 submitted Thread-Index: Acn0/ZH6qnUjyeGYRa2ktmHxEDpf7wAICp5A References: From: "Thomson, Martin" To: "James M. Polk" , X-OriginalArrivalTime: 24 Jun 2009 23:06:21.0136 (UTC) FILETIME=[6359D500:01C9F520] Subject: Re: [sipcore] SIPCORE Location Conveyance -00 submitted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 23:24:12 -0000 SGkgSmFtZXMsDQoNCkknbGwgcHJlZmFjZSB0aGlzIGVtYWlsIHdpdGggdGhlIHVzdWFsIG5vdGUg dGhhdCBpdCdzIHNob2NraW5nIGhvdyBvbGQgdGhpcyBkb2N1bWVudCBpcy4gIFRoaXMgaXMgYW4g aW1wb3J0YW50IGRvY3VtZW50IGZyb20gbXkgcGVyc3BlY3RpdmUsIGFuZCBpdCBuZWVkcyB0byBi ZSBwdWJsaXNoZWQuDQoNCllvdXIgcmV3cml0dGVuIGludHJvIGlzIGEgZ3JlYXQgaW1wcm92ZW1l bnQuICBJIGRpZG4ndCByZWFkIGluIGRldGFpbCBiZXlvbmQgdGhpcywgYnV0IGl0J3MgY2VydGFp bmx5IG11Y2ggY2xlYXJlci4NCg0KSSBub3RlIHRoYXQgdGhlIGV4YW1wbGUgUElERi1MTyBkb2N1 bWVudHMgc3RpbGwgY29udGFpbiBlcnJvcnMuICBSZWZlciB0byA1NDkxIG9yIG9uZSBvZiBteSBw cmV2aW91cyByZXZpZXdzIGZvciBkZXRhaWxzLg0KDQpUaGUgb25lIG1ham9yIGZsYXcgdGhhdCBJ IGhpZ2hsaWdodGVkIGluIG15IFdHTEMgY29tbWVudHMgdG8gdGhlIGZvcm1lciBTSVAgV0cgcmVt YWlucy4gIFRoZSBkb2N1bWVudCBkb2VzIG5vdCBlc3RhYmxpc2ggc3RyaWN0IHNlbWFudGljcyBm b3IgdGhlIGxvY2F0aW9uIGl0IGNvbnZleXMuICBJcyB0aGUgbG9jYXRpb24gaW5mb3JtYXRpb24g aW5kaWNhdGVkIGluIGEgR2VvbG9jYXRpb24gaGVhZGVyIGJlbG9uZyB0byB0aGUgZW50aXR5IGlk ZW50aWZpZWQgaW4gdGhlIEZyb20gaGVhZGVyPyAgT3IgaXMgaXQgdGhlIFVBQyB0aGF0IHNlbmRz IHRoZSByZXF1ZXN0PyAgV2hpbGUgdGhpcyBtaWdodCBzZWVtIGludHVpdGl2ZSwgaXQncyBub3Qu ICBUbyBjb21wbGljYXRlIHRoaW5ncywgdGhlIFBJREYtTE8gY2FuIGNvbnRhaW4gYWx0ZXJuYXRp dmUgaWRlbnRpZmljYXRpb24gaW5mb3JtYXRpb24sIHRoZXJlIGlzIGEgcG90ZW50aWFsIGZvciBj b25mdXNpb24gb3IgY29uZmxpY3QuDQoNClRoaXMgZG9jdW1lbnQgbmVlZHMgdG8gYmUgcmVhbGx5 IGNsZWFyIGFib3V0IHdobyB0aGUgbG9jYXRpb24gYmVsb25ncyB0byB3aXRoaW4gdGhlIGNvbnRl eHQgb2YgdGhlIGV4Y2hhbmdlLg0KDQotLU1hcnRpbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNpcGNvcmUt Ym91bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIEphbWVzIE0uIFBvbGsNCj4gU2VudDog VGh1cnNkYXksIDI1IEp1bmUgMjAwOSA0OjU2IEFNDQo+IFRvOiBzaXBjb3JlQGlldGYub3JnDQo+ IFN1YmplY3Q6IFtzaXBjb3JlXSBTSVBDT1JFIExvY2F0aW9uIENvbnZleWFuY2UgLTAwIHN1Ym1p dHRlZA0KPiANCj4gU0lQQ09SRSBXRw0KPiANCj4gSSBoYXZlIGp1c3Qgc3VibWl0dGVkIGRyYWZ0 LWlldGYtc2lwY29yZS1sb2NhdGlvbi1jb252ZXlhbmNlLTAwLnR4dA0KPiBoZXJlDQo+IGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtc2lwY29yZS1sb2NhdGlv bi0NCj4gY29udmV5YW5jZS0wMC50eHQNCj4gDQo+IFRoaXMgaXMgdGhlIHN1YnNlcXVlbnQgdmVy c2lvbiBmcm9tIFNJUCBMb2NhdGlvbiBDb252ZXlhbmNlIC0xMy4NCj4gDQo+IEhlcmUncyB3aGF0 J3MgY2hhbmdlZCBpbiBTSVBDT1JFLTAwIGNvbXBhcmVkIHRvIHRoZSBTSVAtMTMgdmVyc2lvbjoN Cj4gDQo+IC0gVW5kZXJzdGFuZGluZyB0aGF0IHJlYWRhYmlsaXR5IHdhcyBhIG1haW4gY29uY2Vy biAtIEkgcmVkdWNlZCB0aGUNCj4gSW50cm8gc2VjdGlvbiB0byA0IHBhcmFncmFwaHMgKGxlc3Mg dGhhbiBoYWxmIG9mIHdoYXQgd2FzIGluIC0xMykNCj4gDQo+IC0gc2ltcGxpZmllZCB0aGUgT3Zl cnZpZXcgc2VjdGlvbiwgYWRkZWQgYSBjb3VwbGUgb2YgZmxvdyBmaWd1cmVzIHRvDQo+IHNob3cg aG93IGxvY2F0aW9uIGlzIHRyYW5zbWl0dGVkIHdpdGhpbiBhIFNJUCByZXF1ZXN0IGluIGEgbWVz c2FnZQ0KPiBib2R5LCBhbmQgYXMgYSBVUkkgcmVmZXJlbmNlIHNpbWlsYXIgdG8gY29udGVudCBp bmRpcmVjdGlvbi4NCj4gDQo+IC0gbW92ZWQgc29tZSBvZiB0aGUgSW50cm8gdGV4dCB0byB0aGUg T3ZlcnZpZXcgc2VjdGlvbiwgYnV0IGN1dCBvdXQgYQ0KPiBsb3Qgb2Ygd2hhdCB3YXMgaW4gdGhl IE92ZXJ2aWV3IHNlY3Rpb24gdGhhdCBpcyBleHBsYWluZWQgbGF0ZXIgaW4gdGhlDQo+IGRyYWZ0 Lg0KPiANCj4gLSBSZW1vdmVkIGFsbCB0aGUgVUEtMSB2cyBVQS0yIHN0dWZmLCBhbmQgcmVwbGFj ZWQgaXQgd2l0aCBBbGljZSBhbmQNCj4gQm9iIHJlZmVyZW5jZXMsIG1ha2luZyB0aGlzIGVhc2ll ciB0byByZWFkLg0KPiANCj4gLSBJIHJlZHVjZWQgdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24sIGFu ZCB3aGF0IHdhcyBsZWZ0IHRoYXQgd2FzDQo+IGFscmVhZHkgZGVmaW5lZCBpbiBhbm90aGVyIFJG QywgaXMgbm93IHRoZSBzYW1lIHRleHQgZnJvbSB0aGF0IFJGQw0KPiAod2hpY2ggaXMgYWxzbyBy ZWZlcmVuY2VkIGVhY2ggdGltZSkuDQo+IA0KPiAtIEkgdG9uZWQgZG93biB0aGUgMjExOSB0ZXh0 IGZvciBzZXJ2ZXJzIGluc2VydGluZyBsb2NhdGlvbiBpbnRvIGENCj4gcmVxdWVzdCBmcm9tIFNI T1VMRCBOT1QgdG8gbm90IFJFQ09NTUVOREVELCBiYXNlZCBvbiBXRyBjb21tZW50Lg0KPiANCj4g LSBJIGFkZGVkIFJGQzU0OTEgKFBJREYtTE8gVXNhZ2UpIGFuZCBSRkMgNDQ4MyAoU0lQIENvbnRl bnQNCj4gSW5kaXJlY3Rpb24pIGFzIHJlZmVyZW5jZXMuDQo+IA0KPiAtIEkgcmVtb3ZlZCB0ZXh0 IHNheWluZyBmdXR1cmUgZXJyb3IgY29kZXMgY2FuIGJlIHNwZWNpZmllZCBpbiBlYWNoDQo+IGNh dGVnb3J5LCBhcyB0aGF0IHNlZW1zIHRvIGNvbmZ1c2Ugc29tZSBhYm91dCB0aGUgbWVhbmluZyBv ZiB0aGlzLg0KPiBCdXQgYWRkZWQgdGV4dCBzYXlpbmcgbW9yZSBncmFudWxhciBlcnJvciBjb2Rl cyB0aGF0IGhhdmUgdGhlIHNhbWUNCj4gYWN0aW9uIGJ5IGEgVUEgY2FuIGJlIGNyZWF0ZWQuDQo+ IA0KPiAtIEknbSBub3QgYW4gUy9NSU1FIGV4cGVydCwgYW5kIHdhcyB0b2xkIChhIGxvbmcgdGlt ZSBhZ28pIGl0IGNhbiBiZQ0KPiB1c2VkIGp1c3QgZm9yIHNpZ25pbmcsIGFuZCBub3QgZW5jcnlw dGluZy4gIFR3byBmcm9tIHRoaXMgV0cgc2VlbWVkDQo+IHRvIGFkYW1hbnRseSBkaXNhZ3JlZSB3 aXRoIHRoaXMsIHNvIEkgcmVtb3ZlZCB0aGF0IHRleHQgYWJvdXQgc2lnbmluZw0KPiBvbmx5Lg0K PiANCj4gLSBDbGFyaWZpZWQgYSBwb2ludCB0aGF0IGlzIGFsbG93ZWQgaW4gUElERi1MTywgYW5k IHRoYXQgU0lQDQo+IHNob3VsZG4ndCBhdHRlbXB0IHRvIG92ZXJjb21lIHRoaXMgLSB0aGF0IGlm IEJvYiBzZW5kcyBBbGljZSBoaXMNCj4gbG9jYXRpb24sIGFuZCBzZXRzIGhpcyA8cmV0cmFuc21p c3Npb24tYWxsb3dlZD4gdG8gInllcyI7IHdpdGhpbiB0aGUNCj4gPHJldGVudGlvbi1leHBpcnk+ IHRpbWUgKGluIHdoaWNoIHRoZSBsb2NhdGlvbiBpcyBzdGlsbCB2YWxpZCksIGlmDQo+IEJvYiB0 cmFuc2ZlcnMgQWxpY2UgdG8gQ2Fyb2wsIHRoYXQgUElERi1MTyBwcml2YWN5IHJ1bGVzIGltcGxp Y2l0bHkNCj4gYWxsb3cgQWxpY2UgdG8gdGVsbCBDYXJvbCB3aGVyZSBCb2IgaXMuIFRoaXMgY2Ft ZSB1cCBpbiBhbm90aGVyDQo+IGZvcnVtLCBhbmQgaXMgYSBjdXJyZW50IGJ5cHJvZHVjdCBvZiB0 aGUgcG9saWN5IHJ1bGVzIHdpdGhpbiB0aGUNCj4gUElERi1MTyBhbmQgdGhpcyBkb2N1bWVudCBj YW5ub3Qgb3ZlcmNvbWUgdGhvc2UuDQo+IA0KPiBBIGJlbmVmaXQgdG8gdGhpcyBwb2xpY3kgaXMg dGhhdCBpZiBBbGljZSBjYWxscyBmb3IgZW1lcmdlbmN5IGhlbHAsDQo+IGFuZCBzb21laG93IGlz IHJvdXRlZCB0byB0aGUgd3JvbmcgUFNBUCAoZW1lcmdlbmN5IGNhbGwgY2VudGVyKSwNCj4gUFNB UC0xIGNhbiB0cmFuc2ZlciBBbGljZSdzIGxvY2F0aW9uIHRvIFBTQVAtMiAoaS5lLiwgdGhlIGNv cnJlY3QNCj4gUFNBUCBzZXJ2aW5nIEFsaWNlJ3MgYXJlYSkuIFRoZXJlZm9yZSwgdGhpcyBQSURG LUxPIHBvbGljeSBpcyBub3QNCj4gbmVjZXNzYXJpbHkgYSBob2xlLiAgQlRXIC0gdGhlIGRlZmF1 bHQgdmFsdWUgb2YNCj4gPHJldHJhbnNtaXNzaW9uLWFsbG93ZWQ+IGhhcyBhbHdheXMgYmVlbiB0 byAibm8iLg0KPiANCj4gLSBJIHJlbW92ZWQgdGhlIHRlcm0gc2lnaHRlciBmcm9tIHRoZSBkb2Mg KGEgbGVnYWN5IHRlcm0gd2l0aGluDQo+IEdlb3ByaXYpLCBhbmQgcmVwbGFjZWQgaXQgd2l0aCBs b2NhdG9yLg0KPiANCj4gQ29tbWVudHMgYXJlIHdlbGNvbWUNCj4gDQo+IEphbWVzDQo+IA0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lw Y29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lw aWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90 aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRl IHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHBy b2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd DQo= From jmpolk@cisco.com Wed Jun 24 17:02:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB3303A6D1E for ; Wed, 24 Jun 2009 17:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 253oauN4qs5M for ; Wed, 24 Jun 2009 17:02:58 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 9FCAC3A695E for ; Wed, 24 Jun 2009 17:02:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,285,1243814400"; d="scan'208";a="172756537" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 25 Jun 2009 00:03:10 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5P039Cv023407; Wed, 24 Jun 2009 17:03:09 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n5P0395s011522; Thu, 25 Jun 2009 00:03:09 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2009 17:03:09 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.0.154]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2009 17:03:08 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 24 Jun 2009 19:03:09 -0500 To: "Thomson, Martin" , From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 25 Jun 2009 00:03:08.0853 (UTC) FILETIME=[52822E50:01C9F528] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5659; t=1245888189; x=1246752189; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[sipcore]=20SIPCORE=20Location=20Convey ance=20-00=20submitted |Sender:=20; bh=h4Pm4Bkgadynr+4xjCbUnxv0nqUz4HsT/kM5uv3UD5s=; b=U0eEXXwQdJMg5RB4zLRLPnHNacHBytb/OjDyn8Y+EM9rOAl1LwVDmTVS7X PlsceswOBD0wQj/L17ICk48i4C/Q9YY1GauCnHcy+gKoFgdiI5nO6BLa9Qgd 0VCOW4FKZD; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [sipcore] SIPCORE Location Conveyance -00 submitted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 00:02:59 -0000 At 06:06 PM 6/24/2009, Thomson, Martin wrote: >Hi James, > >I'll preface this email with the usual note that it's shocking how >old this document is. This is an important document from my >perspective, and it needs to be published. > >Your rewritten intro is a great improvement. I didn't read in >detail beyond this, but it's certainly much clearer. > >I note that the example PIDF-LO documents still contain >errors. Refer to 5491 or one of my previous reviews for details. your previous emails have never had any details to know what you're talking about... just as this one doesn't. Since I cannot determine what you want changed, knowing I'm not a mind reader, the text remains as it is. >The one major flaw that I highlighted in my WGLC comments to the >former SIP WG remains. The document does not establish strict >semantics for the location it conveys. Is the location information >indicated in a Geolocation header belong to the entity identified in >the From header? Or is it the UAC that sends the request? While >this might seem intuitive, it's not. To complicate things, the >PIDF-LO can contain alternative identification information, there is >a potential for confusion or conflict. Please read the parts you say you didn't read this time to read the text that's been in the doc for quite some time now that discusses this. >This document needs to be really clear about who the location >belongs to within the context of the exchange. here's a hint: this is (and has always been) done in the PIDF-LO, this is not (and never has been) part of any of the SIP headers. >--Martin > > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > > Behalf Of James M. Polk > > Sent: Thursday, 25 June 2009 4:56 AM > > To: sipcore@ietf.org > > Subject: [sipcore] SIPCORE Location Conveyance -00 submitted > > > > SIPCORE WG > > > > I have just submitted draft-ietf-sipcore-location-conveyance-00.txt > > here > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location- > > conveyance-00.txt > > > > This is the subsequent version from SIP Location Conveyance -13. > > > > Here's what's changed in SIPCORE-00 compared to the SIP-13 version: > > > > - Understanding that readability was a main concern - I reduced the > > Intro section to 4 paragraphs (less than half of what was in -13) > > > > - simplified the Overview section, added a couple of flow figures to > > show how location is transmitted within a SIP request in a message > > body, and as a URI reference similar to content indirection. > > > > - moved some of the Intro text to the Overview section, but cut out a > > lot of what was in the Overview section that is explained later in the > > draft. > > > > - Removed all the UA-1 vs UA-2 stuff, and replaced it with Alice and > > Bob references, making this easier to read. > > > > - I reduced the terminology section, and what was left that was > > already defined in another RFC, is now the same text from that RFC > > (which is also referenced each time). > > > > - I toned down the 2119 text for servers inserting location into a > > request from SHOULD NOT to not RECOMMENDED, based on WG comment. > > > > - I added RFC5491 (PIDF-LO Usage) and RFC 4483 (SIP Content > > Indirection) as references. > > > > - I removed text saying future error codes can be specified in each > > category, as that seems to confuse some about the meaning of this. > > But added text saying more granular error codes that have the same > > action by a UA can be created. > > > > - I'm not an S/MIME expert, and was told (a long time ago) it can be > > used just for signing, and not encrypting. Two from this WG seemed > > to adamantly disagree with this, so I removed that text about signing > > only. > > > > - Clarified a point that is allowed in PIDF-LO, and that SIP > > shouldn't attempt to overcome this - that if Bob sends Alice his > > location, and sets his to "yes"; within the > > time (in which the location is still valid), if > > Bob transfers Alice to Carol, that PIDF-LO privacy rules implicitly > > allow Alice to tell Carol where Bob is. This came up in another > > forum, and is a current byproduct of the policy rules within the > > PIDF-LO and this document cannot overcome those. > > > > A benefit to this policy is that if Alice calls for emergency help, > > and somehow is routed to the wrong PSAP (emergency call center), > > PSAP-1 can transfer Alice's location to PSAP-2 (i.e., the correct > > PSAP serving Alice's area). Therefore, this PIDF-LO policy is not > > necessarily a hole. BTW - the default value of > > has always been to "no". > > > > - I removed the term sighter from the doc (a legacy term within > > Geopriv), and replaced it with locator. > > > > Comments are welcome > > > > James > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] From Martin.Thomson@andrew.com Wed Jun 24 17:33:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08C893A6928 for ; Wed, 24 Jun 2009 17:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcZyvPQBTlfv for ; Wed, 24 Jun 2009 17:33:25 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 00FD43A6D90 for ; Wed, 24 Jun 2009 17:33:24 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_06_24_19_55_34 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 24 Jun 2009 19:55:33 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Jun 2009 19:33:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 24 Jun 2009 19:33:39 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] SIPCORE Location Conveyance -00 submitted Thread-Index: Acn1KFQF3AAJ8SA5Ts6mKh7/ytHnagAAPuPg References: From: "Thomson, Martin" To: "James M. Polk" , X-OriginalArrivalTime: 25 Jun 2009 00:33:41.0079 (UTC) FILETIME=[9699AE70:01C9F52C] Subject: Re: [sipcore] SIPCORE Location Conveyance -00 submitted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 00:33:26 -0000 SW5saW5lLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEphbWVzIE0u IFBvbGsgW21haWx0bzpqbXBvbGtAY2lzY28uY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgMjUgSnVu ZSAyMDA5IDEwOjAzIEFNDQo+IFRvOiBUaG9tc29uLCBNYXJ0aW47IHNpcGNvcmVAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUkU6IFtzaXBjb3JlXSBTSVBDT1JFIExvY2F0aW9uIENvbnZleWFuY2UgLTAw IHN1Ym1pdHRlZA0KPiANCj4gQXQgMDY6MDYgUE0gNi8yNC8yMDA5LCBUaG9tc29uLCBNYXJ0aW4g d3JvdGU6DQo+ID5IaSBKYW1lcywNCj4gPg0KPiA+SSdsbCBwcmVmYWNlIHRoaXMgZW1haWwgd2l0 aCB0aGUgdXN1YWwgbm90ZSB0aGF0IGl0J3Mgc2hvY2tpbmcgaG93DQo+ID5vbGQgdGhpcyBkb2N1 bWVudCBpcy4gIFRoaXMgaXMgYW4gaW1wb3J0YW50IGRvY3VtZW50IGZyb20gbXkNCj4gPnBlcnNw ZWN0aXZlLCBhbmQgaXQgbmVlZHMgdG8gYmUgcHVibGlzaGVkLg0KPiA+DQo+ID5Zb3VyIHJld3Jp dHRlbiBpbnRybyBpcyBhIGdyZWF0IGltcHJvdmVtZW50LiAgSSBkaWRuJ3QgcmVhZCBpbg0KPiA+ ZGV0YWlsIGJleW9uZCB0aGlzLCBidXQgaXQncyBjZXJ0YWlubHkgbXVjaCBjbGVhcmVyLg0KPiA+ DQo+ID5JIG5vdGUgdGhhdCB0aGUgZXhhbXBsZSBQSURGLUxPIGRvY3VtZW50cyBzdGlsbCBjb250 YWluDQo+ID5lcnJvcnMuICBSZWZlciB0byA1NDkxIG9yIG9uZSBvZiBteSBwcmV2aW91cyByZXZp ZXdzIGZvciBkZXRhaWxzLg0KPiANCj4geW91ciBwcmV2aW91cyBlbWFpbHMgaGF2ZSBuZXZlciBo YWQgYW55IGRldGFpbHMgdG8ga25vdyB3aGF0IHlvdSdyZQ0KPiB0YWxraW5nIGFib3V0Li4uIGp1 c3QgYXMgdGhpcyBvbmUgZG9lc24ndC4gU2luY2UgSSBjYW5ub3QgZGV0ZXJtaW5lDQo+IHdoYXQg eW91IHdhbnQgY2hhbmdlZCwga25vd2luZyBJJ20gbm90IGEgbWluZCByZWFkZXIsIHRoZSB0ZXh0 DQo+IHJlbWFpbnMgYXMgaXQgaXMuDQoNCkkgZG9uJ3QgaGF2ZSB0aW1lIHJpZ2h0IG5vdyB0byBk ZXRhaWwgdGhlIG15cmlhZCB3YXlzLiAgRm9yIG5vdyBhbGwgSSBjYW4gZG8gaXMgc3VnZ2VzdCB0 aGF0IHlvdSB2YWxpZGF0ZSB0aGUgWE1MLiAgQmVmb3JlIHlvdSBkbyB0aG91Z2gsIGVuc3VyZSB0 aGF0IHlvdSByZW1vdmUgYWxsIGluc3RhbmNlcyBvZiBwcm9jZXNzQ29udGVudHM9ImxheCIgc28g dGhhdCB0aGUgdmFsaWRhdG9yIGRvZXNuJ3QgZGVjaWRlIHRvIHNraXAgdmFsaWRhdGlvbiBvbiBh bnl0aGluZy4NCg0KT2ZmaGFuZCwgSSBub3RlZCB0aGF0IHByb3ZpZGVkLWJ5IHVzYWdlIGlzIGlu Y29ycmVjdCAocmVtb3ZlIGl0KSwgeW91IG9taXR0ZWQgdGhlIG1hbmRhdG9yeSBkZXZpY2VJRCBl bGVtZW50IGZyb20gZGV2aWNlLCB0aW1lc3RhbXAgY29tZXMgYWZ0ZXIgc3RhdHVzLCByZXRyYW5z bWlzc2lvbi1hbGxvd2VkIGlzIG9mIHRoZSAneHM6Ym9vbGVhbicgdHlwZSB3aGljaCBtZWFucyBz L25vL2ZhbHNlLyAoY29udHJhcnkgdG8gd2hhdCBtaWdodCBiZSBpbmRpY2F0ZWQgaW4gUkZDNDEx OSkuDQoNCj4gPlRoZSBvbmUgbWFqb3IgZmxhdyB0aGF0IEkgaGlnaGxpZ2h0ZWQgaW4gbXkgV0dM QyBjb21tZW50cyB0byB0aGUNCj4gPmZvcm1lciBTSVAgV0cgcmVtYWlucy4gIFRoZSBkb2N1bWVu dCBkb2VzIG5vdCBlc3RhYmxpc2ggc3RyaWN0DQo+ID5zZW1hbnRpY3MgZm9yIHRoZSBsb2NhdGlv biBpdCBjb252ZXlzLiAgSXMgdGhlIGxvY2F0aW9uIGluZm9ybWF0aW9uDQo+ID5pbmRpY2F0ZWQg aW4gYSBHZW9sb2NhdGlvbiBoZWFkZXIgYmVsb25nIHRvIHRoZSBlbnRpdHkgaWRlbnRpZmllZCBp bg0KPiA+dGhlIEZyb20gaGVhZGVyPyAgT3IgaXMgaXQgdGhlIFVBQyB0aGF0IHNlbmRzIHRoZSBy ZXF1ZXN0PyAgV2hpbGUNCj4gPnRoaXMgbWlnaHQgc2VlbSBpbnR1aXRpdmUsIGl0J3Mgbm90LiAg VG8gY29tcGxpY2F0ZSB0aGluZ3MsIHRoZQ0KPiA+UElERi1MTyBjYW4gY29udGFpbiBhbHRlcm5h dGl2ZSBpZGVudGlmaWNhdGlvbiBpbmZvcm1hdGlvbiwgdGhlcmUgaXMNCj4gPmEgcG90ZW50aWFs IGZvciBjb25mdXNpb24gb3IgY29uZmxpY3QuDQo+IA0KPiBQbGVhc2UgcmVhZCB0aGUgcGFydHMg eW91IHNheSB5b3UgZGlkbid0IHJlYWQgdGhpcyB0aW1lIHRvIHJlYWQgdGhlDQo+IHRleHQgdGhh dCdzIGJlZW4gaW4gdGhlIGRvYyBmb3IgcXVpdGUgc29tZSB0aW1lIG5vdyB0aGF0IGRpc2N1c3Nl cw0KPiB0aGlzLg0KDQpJIGp1c3QgcmUtcmVhZCB0aGUgZmlyc3QgMTAgcGFnZXMsIHBsdXMgdGhl IGRlc2NyaXB0aW9ucyBvZiBVQUMgYW5kIFVBUyBiZWhhdmlvdXIgd2l0aG91dCBmaW5kaW5nIGFu eXRoaW5nIG90aGVyIHRoYW4gdmFndWUgaGludHMuICBJbiBhbGwgY2FzZXMgeW91IHRhbGsgYWJv dXQgInRhcmdldCIsICJUYXJnZXQiIG9yICJBbGljZSIgd2l0aG91dCBkZXNjcmliaW5nIGhvdyB0 aGF0IGlkZW50aXR5IGlzIGVzdGFibGlzaGVkIG9yIGxpbmtlZCB0byBhbnkgcHJvdG9jb2wgcGFy YW1ldGVycy4gIEknZCBleHBlY3QgdGhpcyB0byBiZSBtb3JlIGNsZWFybHkgZGVzY3JpYmVkIGJl Zm9yZSB5b3UgZ2V0IGludG8gdGhlIHByb3RvY29sIGRldGFpbHMuDQoNCkkgZGlkIGZpbmQgdGhp cyBoaWRkZW4gYXQgdGhlIGJvdHRvbSBvZiBTNC4xOg0KDQogICAgICAgIFRoZSA8ZG06ZGV2aWNl IGlkPg0KICAgICAgICBlbGVtZW50IFtSRkM1NDkxXSBpbiB0aGUgUElERi1MTyBYTUwgaW5kaWNh dGVzIHdob3NlIGxvY2F0aW9uDQogICAgICAgIGlzIGNvbnRhaW5lZCBpbiB0aGUgUElERi1MTy4N Cg0KVGhpcyBpcyBwb3RlbnRpYWxseSBvZiBubyB1c2U6ICBTSVAgcGVlcnMgZG8gbm90IG5lY2Vz c2FyaWx5IGhhdmUgdGhlIG5lY2Vzc2FyeSBjb250ZXh0IHRvIG1ha2Ugc2Vuc2Ugb2YgdGhlc2Ug aWRlbnRpZmllcnM7IGRldmljZUlEIGlzIG5vdCBtYW5kYXRvcnk7IGFuZCBmb3IgcHJpdmFjeSBy ZWFzb25zIEkgd291bGQgcmVjb21tZW5kIHRvIGFueW9uZSBpbXBsZW1lbnRpbmcgdGhpcyB0aGF0 IHRoZXkgZG8gbm90IHByb3ZpZGUgdGhpcyBpbmZvcm1hdGlvbi4NCg0KKFRoZSBjb3JyZWN0IHJl ZmVyZW5jZSBoZXJlIGlzIFJGQyA0NDc5IC0gcHJlc2VuY2UgZGF0YSBtb2RlbCwgd2hpY2ggZGVm aW5lcyB0aGlzIGZpZWxkOyBhbmQgSSBzdXNwZWN0IHRoYXQgeW91IG1lYW4gPGRldmljZUlEPi4u LjwvZGV2aWNlSUQ+LCBub3QgPGRldmljZSBpZD0ieHh4Ij4sIHdoaWNoIGhhcyBvdGhlciBzZW1h bnRpY3MuKQ0KDQo+ID5UaGlzIGRvY3VtZW50IG5lZWRzIHRvIGJlIHJlYWxseSBjbGVhciBhYm91 dCB3aG8gdGhlIGxvY2F0aW9uDQo+ID5iZWxvbmdzIHRvIHdpdGhpbiB0aGUgY29udGV4dCBvZiB0 aGUgZXhjaGFuZ2UuDQo+IA0KPiBoZXJlJ3MgYSBoaW50OiB0aGlzIGlzIChhbmQgaGFzIGFsd2F5 cyBiZWVuKSBkb25lIGluIHRoZSBQSURGLUxPLA0KPiB0aGlzIGlzIG5vdCAoYW5kIG5ldmVyIGhh cyBiZWVuKSBwYXJ0IG9mIGFueSBvZiB0aGUgU0lQIGhlYWRlcnMuDQoNCk5vdyB0aGlzIGlzIGEg cHJvYmxlbSBpbmRlZWQuICBUaGUgcG9zc2liaWxpdHkgdGhhdCB0aGUgUElERi1MTyBjb250YWlu cyBhbiB1bmxpbmtlZCBwc2V1ZG9ueW0gKGMuZi4gUkZDIDM2OTMpIGhhcyB0byBiZSBjb25zaWRl cmVkLiAgTm90ZSBhbHNvIHRoZSBhYm92ZSBwcm9ibGVtcy4NCg0KPiANCj4gPi0tTWFydGluDQo+ ID4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3Nh Z2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4g cHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9u LiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhv cml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJdDQo= From gonzalo.camarillo@ericsson.com Wed Jun 24 23:12:23 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A01D3A68A1 for ; Wed, 24 Jun 2009 23:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYahk55Rc9h3 for ; Wed, 24 Jun 2009 23:12:21 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D479B3A67A1 for ; Wed, 24 Jun 2009 23:12:20 -0700 (PDT) X-AuditID: c1b4fb3c-b7bdcae0000052f9-34-4a43115dc071 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 7B.C4.21241.D51134A4; Thu, 25 Jun 2009 07:55:41 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jun 2009 07:55:40 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jun 2009 07:55:40 +0200 Received: from [131.160.126.143] (rvi2-126-143.lmf.ericsson.se [131.160.126.143]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7CB34245E; Thu, 25 Jun 2009 08:55:40 +0300 (EEST) Message-ID: <4A43115C.7040902@ericsson.com> Date: Thu, 25 Jun 2009 08:55:40 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2009 05:55:40.0576 (UTC) FILETIME=[91EAFA00:01C9F559] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Input requested on how to proceed with the essential corrections to RFC 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 06:12:23 -0000 Folks, as you can see in our charter, we have the following milestone: Sep 2009 - Essential corrections to RFC 3261 (1st batch) to IESG (PS) The reason why the milestone talks about the "first batch" can be found in the following draft: http://tools.ietf.org/html/draft-drage-sip-essential-correction-03 The draft above talks about RFCs that are updated by tens of RFCs. The draft claims that having a lot of RFCs updating a given RFC would be confusing for implementers. At the time of writing the draft above, there was a belief that RFC 3261 was going to be an example of an RFC updated by tens of RFCs. The idea in the draft is that instead of issuing a number of RFCs updating the original one, the WG would put all those updates together into a batch and publish the batch as a single RFC. Analyzing the current situation, RFC 3261 has already been updated by the following RFCs: 3265, 3853, 4320, 4916, 5393 Additionally, there are a few drafts that will, if approved, update RFC 3261 as well: Draft already with the IESG: http://tools.ietf.org/html/draft-ietf-sip-body-handling-06 Draft that could be included in the essential corrections process when their contents are approved: http://tools.ietf.org/html/draft-ietf-sip-ipv6-abnf-fix-03 http://tools.ietf.org/html/draft-sparks-sip-invfix-03 http://tools.ietf.org/html/draft-camarillo-sipping-reinvite-00 It turns out that the total number of RFCs updating RFC 3261 has not grown as much as expected. The number of RFCs documenting essential corrections (a subset of all the RFCs updating RFC 3261) is also lower than expected. (From Section 3 of the essential corrections draft, an essential change is one where in the absence of the correction, it will not be possible to implement the specification contained in the original RFC in a manner to ensure interoperability or correct operation.) The general decision we have to make at this point, given the small number of drafts documenting essential corrections, is whether we want to document essential corrections in batches, per the essential corrections process, or in individual drafts, as it has been done in the past. The concrete decision we have to make is whether it makes sense to merge the following drafts in a batch, per the essential corrections process, or whether we advance these drafts independently. http://tools.ietf.org/html/draft-ietf-sip-ipv6-abnf-fix-03 http://tools.ietf.org/html/draft-sparks-sip-invfix-03 http://tools.ietf.org/html/draft-camarillo-sipping-reinvite-00 We would appreciate the feedback of the WG on this issue so that we can make progress updating RFC 3261. Thanks, Gonzalo SIPCORE co-chair From john.elwell@siemens-enterprise.com Thu Jun 25 00:31:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E6F528C0CE for ; Thu, 25 Jun 2009 00:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IVZL8cK3R6f for ; Thu, 25 Jun 2009 00:31:55 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 4E2E23A6AAC for ; Thu, 25 Jun 2009 00:31:54 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KLS00B8H9IWX9@siemenscomms.co.uk> for sipcore@ietf.org; Thu, 25 Jun 2009 08:16:08 +0100 (BST) Date: Thu, 25 Jun 2009 08:16:06 +0100 From: "Elwell, John" In-reply-to: <4A43115C.7040902@ericsson.com> To: Gonzalo Camarillo , SIPCORE Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0021058FB@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] Input requested on how to proceed with the essential corrections to RFC 3261 Thread-Index: Acn1XAHWEYY0noF2Roy/SmBJr/CRbgACF27g Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A43115C.7040902@ericsson.com> Subject: Re: [sipcore] Input requested on how to proceed with the essential corrections to RFC 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 07:31:56 -0000 Gonzalo, I would say advance them separately. By the way, I noticed the absence of sip-sips from the list of drafts updating RFC 3261. Arguably that could also be considered an "essential correction", but I certainly think it should remain in its own document. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: 25 June 2009 06:56 > To: SIPCORE > Subject: [sipcore] Input requested on how to proceed with the=20 > essential corrections to RFC 3261 >=20 > Folks, >=20 > as you can see in our charter, we have the following milestone: >=20 > Sep 2009 - Essential corrections to RFC 3261 (1st batch) to IESG (PS) >=20 > The reason why the milestone talks about the "first batch"=20 > can be found=20 > in the following draft: >=20 > http://tools.ietf.org/html/draft-drage-sip-essential-correction-03 >=20 > The draft above talks about RFCs that are updated by tens of=20 > RFCs. The=20 > draft claims that having a lot of RFCs updating a given RFC would be=20 > confusing for implementers. At the time of writing the draft above,=20 > there was a belief that RFC 3261 was going to be an example of an RFC=20 > updated by tens of RFCs. The idea in the draft is that instead of=20 > issuing a number of RFCs updating the original one, the WG=20 > would put all=20 > those updates together into a batch and publish the batch as=20 > a single RFC. >=20 > Analyzing the current situation, RFC 3261 has already been updated by=20 > the following RFCs: 3265, 3853, 4320, 4916, 5393 >=20 > Additionally, there are a few drafts that will, if approved,=20 > update RFC=20 > 3261 as well: >=20 > Draft already with the IESG: > http://tools.ietf.org/html/draft-ietf-sip-body-handling-06 >=20 > Draft that could be included in the essential corrections=20 > process when=20 > their contents are approved: > http://tools.ietf.org/html/draft-ietf-sip-ipv6-abnf-fix-03 > http://tools.ietf.org/html/draft-sparks-sip-invfix-03 > http://tools.ietf.org/html/draft-camarillo-sipping-reinvite-00 >=20 > It turns out that the total number of RFCs updating RFC 3261 has not=20 > grown as much as expected. The number of RFCs documenting essential=20 > corrections (a subset of all the RFCs updating RFC 3261) is=20 > also lower=20 > than expected. (From Section 3 of the essential corrections draft, an=20 > essential change is one where in the absence of the=20 > correction, it will=20 > not be possible to implement the specification contained in=20 > the original=20 > RFC in a manner to ensure interoperability or correct operation.) >=20 > The general decision we have to make at this point, given the small=20 > number of drafts documenting essential corrections, is=20 > whether we want=20 > to document essential corrections in batches, per the essential=20 > corrections process, or in individual drafts, as it has been=20 > done in the=20 > past. >=20 > The concrete decision we have to make is whether it makes=20 > sense to merge=20 > the following drafts in a batch, per the essential=20 > corrections process,=20 > or whether we advance these drafts independently. >=20 > http://tools.ietf.org/html/draft-ietf-sip-ipv6-abnf-fix-03 > http://tools.ietf.org/html/draft-sparks-sip-invfix-03 > http://tools.ietf.org/html/draft-camarillo-sipping-reinvite-00 >=20 > We would appreciate the feedback of the WG on this issue so=20 > that we can=20 > make progress updating RFC 3261. >=20 > Thanks, >=20 > Gonzalo > SIPCORE co-chair >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From gao.yang2@zte.com.cn Thu Jun 25 05:05:47 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BCF928C0FD; Thu, 25 Jun 2009 05:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L32dHanS0RCN; Thu, 25 Jun 2009 05:05:46 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 6B08C3A6A64; Thu, 25 Jun 2009 05:05:45 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111642206043021; Thu, 25 Jun 2009 19:18:54 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 59484.3458903452; Thu, 25 Jun 2009 19:09:56 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n5PBGHOe057268; Thu, 25 Jun 2009 19:16:17 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4A43115C.7040902@ericsson.com> To: Gonzalo Camarillo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 25 Jun 2009 19:15:30 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-06-25 19:16:05, Serialize complete at 2009-06-25 19:16:05 Content-Type: multipart/alternative; boundary="=_alternative 003DE0E9482575E0_=" X-MAIL: mse2.zte.com.cn n5PBGHOe057268 Cc: SIPCORE , sipping@ietf.org Subject: Re: [sipcore] Input requested on how to proceed with the essential corrections to RFC 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 12:05:47 -0000 This is a multipart message in MIME format. --=_alternative 003DE0E9482575E0_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 R29uemFsbywNCg0KV2UgaGF2ZSBhZ3JlZWQgb24gdGhlIGlzc3VlIG9mIGNvLWF1dGhvci4gQnV0 IGZyb20gdGhlIG1haWwsIHlvdSBqdXN0IA0KbWVudGlvbmVkICJkcmFmdC1jYW1hcmlsbG8tc2lw cGluZy1yZWludml0ZS0wMCIgYXMgY29ycmVjdGlvbiBvZiBSRkMzMjYxLg0KDQpJJ2QgbGlrZSB0 byBjb25maXJtOg0KDQp3aGV0aGVyIHlvdSB3YW50IG1ha2luZyB5b3VyIHR3byANCmRyYWZ0cygi ZHJhZnQtY2FtYXJpbGxvLXNpcHBpbmctcHJlY29ucy0wMCIgYW5kIA0KImRyYWZ0LWNhbWFyaWxs by1zaXBwaW5nLXJlaW52aXRlLTAwIikgYW5kIA0KbWluZSgiZHJhZnQtZ2FveWFuZy1zaXBwaW5n LXNlc3Npb24tc3RhdGUtY3JpdGVyaW9uLTAzIikgYXMgb25lIG9yIG1ha2luZyANCiJkcmFmdC1j YW1hcmlsbG8tc2lwcGluZy1wcmVjb25zLTAwIiBhbmQgDQoiZHJhZnQtZ2FveWFuZy1zaXBwaW5n LXNlc3Npb24tc3RhdGUtY3JpdGVyaW9uLTAzIiBhcyBvbmUsIA0KImRyYWZ0LWNhbWFyaWxsby1z aXBwaW5nLXJlaW52aXRlLTAwIiBzZXBhcmF0ZWx5Lg0KDQpJIHRoaW5rIG1ha2luZyB0aGVtIGEg d2hvbGUgaXMgYmV0dGVyIGZvciB0aGUgY29ycmVsYXRpb24gb2YgdGhlIHR3byANCnRvcGljcy4g SXQgaXMganVzdCBteSBzdWdnZXN0aW9uLCB5b3UgY2FuIGRlY2lkZSBpbmRlcGVuZGVudGx5Lg0K DQpUaGFua3MsDQoNCkdhby4NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N CiBaaXAgICAgOiAyMTAwMTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUy ODc3MjExDQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQoNCg0KDQpHb256YWxvIENhbWFyaWxsbyA8R29uemFsby5DYW1h cmlsbG9AZXJpY3Nzb24uY29tPiANCreivP7IyzogIHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZw0K MjAwOS0wNi0yNSAxMzo1NQ0KDQrK1bz+yMsNClNJUENPUkUgPHNpcGNvcmVAaWV0Zi5vcmc+DQqz rcvNDQoNCtb3zOINCltzaXBjb3JlXSBJbnB1dCByZXF1ZXN0ZWQgb24gaG93IHRvIHByb2NlZWQg d2l0aCB0aGUgZXNzZW50aWFsIGNvcnJlY3Rpb25zIA0KdG8gUkZDIDMyNjENCg0KDQoNCg0KDQoN CkZvbGtzLA0KDQphcyB5b3UgY2FuIHNlZSBpbiBvdXIgY2hhcnRlciwgd2UgaGF2ZSB0aGUgZm9s bG93aW5nIG1pbGVzdG9uZToNCg0KU2VwIDIwMDkgLSBFc3NlbnRpYWwgY29ycmVjdGlvbnMgdG8g UkZDIDMyNjEgKDFzdCBiYXRjaCkgdG8gSUVTRyAoUFMpDQoNClRoZSByZWFzb24gd2h5IHRoZSBt aWxlc3RvbmUgdGFsa3MgYWJvdXQgdGhlICJmaXJzdCBiYXRjaCIgY2FuIGJlIGZvdW5kIA0KaW4g dGhlIGZvbGxvd2luZyBkcmFmdDoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt ZHJhZ2Utc2lwLWVzc2VudGlhbC1jb3JyZWN0aW9uLTAzDQoNClRoZSBkcmFmdCBhYm92ZSB0YWxr cyBhYm91dCBSRkNzIHRoYXQgYXJlIHVwZGF0ZWQgYnkgdGVucyBvZiBSRkNzLiBUaGUgDQpkcmFm dCBjbGFpbXMgdGhhdCBoYXZpbmcgYSBsb3Qgb2YgUkZDcyB1cGRhdGluZyBhIGdpdmVuIFJGQyB3 b3VsZCBiZSANCmNvbmZ1c2luZyBmb3IgaW1wbGVtZW50ZXJzLiBBdCB0aGUgdGltZSBvZiB3cml0 aW5nIHRoZSBkcmFmdCBhYm92ZSwgDQp0aGVyZSB3YXMgYSBiZWxpZWYgdGhhdCBSRkMgMzI2MSB3 YXMgZ29pbmcgdG8gYmUgYW4gZXhhbXBsZSBvZiBhbiBSRkMgDQp1cGRhdGVkIGJ5IHRlbnMgb2Yg UkZDcy4gVGhlIGlkZWEgaW4gdGhlIGRyYWZ0IGlzIHRoYXQgaW5zdGVhZCBvZiANCmlzc3Vpbmcg YSBudW1iZXIgb2YgUkZDcyB1cGRhdGluZyB0aGUgb3JpZ2luYWwgb25lLCB0aGUgV0cgd291bGQg cHV0IGFsbCANCnRob3NlIHVwZGF0ZXMgdG9nZXRoZXIgaW50byBhIGJhdGNoIGFuZCBwdWJsaXNo IHRoZSBiYXRjaCBhcyBhIHNpbmdsZSBSRkMuDQoNCkFuYWx5emluZyB0aGUgY3VycmVudCBzaXR1 YXRpb24sIFJGQyAzMjYxIGhhcyBhbHJlYWR5IGJlZW4gdXBkYXRlZCBieSANCnRoZSBmb2xsb3dp bmcgUkZDczogMzI2NSwgMzg1MywgNDMyMCwgNDkxNiwgNTM5Mw0KDQpBZGRpdGlvbmFsbHksIHRo ZXJlIGFyZSBhIGZldyBkcmFmdHMgdGhhdCB3aWxsLCBpZiBhcHByb3ZlZCwgdXBkYXRlIFJGQyAN CjMyNjEgYXMgd2VsbDoNCg0KRHJhZnQgYWxyZWFkeSB3aXRoIHRoZSBJRVNHOg0KaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zaXAtYm9keS1oYW5kbGluZy0wNg0KDQpEcmFm dCB0aGF0IGNvdWxkIGJlIGluY2x1ZGVkIGluIHRoZSBlc3NlbnRpYWwgY29ycmVjdGlvbnMgcHJv Y2VzcyB3aGVuIA0KdGhlaXIgY29udGVudHMgYXJlIGFwcHJvdmVkOg0KaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zaXAtaXB2Ni1hYm5mLWZpeC0wMw0KaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtc3BhcmtzLXNpcC1pbnZmaXgtMDMNCmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWNhbWFyaWxsby1zaXBwaW5nLXJlaW52aXRlLTAwDQoNCkl0IHR1 cm5zIG91dCB0aGF0IHRoZSB0b3RhbCBudW1iZXIgb2YgUkZDcyB1cGRhdGluZyBSRkMgMzI2MSBo YXMgbm90IA0KZ3Jvd24gYXMgbXVjaCBhcyBleHBlY3RlZC4gVGhlIG51bWJlciBvZiBSRkNzIGRv Y3VtZW50aW5nIGVzc2VudGlhbCANCmNvcnJlY3Rpb25zIChhIHN1YnNldCBvZiBhbGwgdGhlIFJG Q3MgdXBkYXRpbmcgUkZDIDMyNjEpIGlzIGFsc28gbG93ZXIgDQp0aGFuIGV4cGVjdGVkLiAoRnJv bSBTZWN0aW9uIDMgb2YgdGhlIGVzc2VudGlhbCBjb3JyZWN0aW9ucyBkcmFmdCwgYW4gDQplc3Nl bnRpYWwgY2hhbmdlIGlzIG9uZSB3aGVyZSBpbiB0aGUgYWJzZW5jZSBvZiB0aGUgY29ycmVjdGlv biwgaXQgd2lsbCANCm5vdCBiZSBwb3NzaWJsZSB0byBpbXBsZW1lbnQgdGhlIHNwZWNpZmljYXRp b24gY29udGFpbmVkIGluIHRoZSBvcmlnaW5hbCANClJGQyBpbiBhIG1hbm5lciB0byBlbnN1cmUg aW50ZXJvcGVyYWJpbGl0eSBvciBjb3JyZWN0IG9wZXJhdGlvbi4pDQoNClRoZSBnZW5lcmFsIGRl Y2lzaW9uIHdlIGhhdmUgdG8gbWFrZSBhdCB0aGlzIHBvaW50LCBnaXZlbiB0aGUgc21hbGwgDQpu dW1iZXIgb2YgZHJhZnRzIGRvY3VtZW50aW5nIGVzc2VudGlhbCBjb3JyZWN0aW9ucywgaXMgd2hl dGhlciB3ZSB3YW50IA0KdG8gZG9jdW1lbnQgZXNzZW50aWFsIGNvcnJlY3Rpb25zIGluIGJhdGNo ZXMsIHBlciB0aGUgZXNzZW50aWFsIA0KY29ycmVjdGlvbnMgcHJvY2Vzcywgb3IgaW4gaW5kaXZp ZHVhbCBkcmFmdHMsIGFzIGl0IGhhcyBiZWVuIGRvbmUgaW4gdGhlIA0KcGFzdC4NCg0KVGhlIGNv bmNyZXRlIGRlY2lzaW9uIHdlIGhhdmUgdG8gbWFrZSBpcyB3aGV0aGVyIGl0IG1ha2VzIHNlbnNl IHRvIG1lcmdlIA0KdGhlIGZvbGxvd2luZyBkcmFmdHMgaW4gYSBiYXRjaCwgcGVyIHRoZSBlc3Nl bnRpYWwgY29ycmVjdGlvbnMgcHJvY2VzcywgDQpvciB3aGV0aGVyIHdlIGFkdmFuY2UgdGhlc2Ug ZHJhZnRzIGluZGVwZW5kZW50bHkuDQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtc2lwLWlwdjYtYWJuZi1maXgtMDMNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXNwYXJrcy1zaXAtaW52Zml4LTAzDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1jYW1hcmlsbG8tc2lwcGluZy1yZWludml0ZS0wMA0KDQpXZSB3b3VsZCBhcHByZWNpYXRlIHRo ZSBmZWVkYmFjayBvZiB0aGUgV0cgb24gdGhpcyBpc3N1ZSBzbyB0aGF0IHdlIGNhbiANCm1ha2Ug cHJvZ3Jlc3MgdXBkYXRpbmcgUkZDIDMyNjEuDQoNClRoYW5rcywNCg0KR29uemFsbw0KU0lQQ09S RSBjby1jaGFpcg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQoNCg0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3Jt YXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhp cyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFi b3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0 ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhl cnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29u ZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2Yg dGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9z ZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5l ZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 003DE0E9482575E0_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdvbnphbG8sPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XZSBoYXZlIGFncmVlZCBvbiB0 aGUgaXNzdWUgb2YgY28tYXV0aG9yLg0KQnV0IGZyb20gdGhlIG1haWwsIHlvdSBqdXN0IG1lbnRp b25lZCAmcXVvdDtkcmFmdC1jYW1hcmlsbG8tc2lwcGluZy1yZWludml0ZS0wMCZxdW90Ow0KYXMg Y29ycmVjdGlvbiBvZiBSRkMzMjYxLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+SSdkIGxpa2UgdG8gY29uZmlybTo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPndoZXRoZXIgeW91IHdhbnQgbWFraW5nIHlvdXIg dHdvIGRyYWZ0cygmcXVvdDtkcmFmdC1jYW1hcmlsbG8tc2lwcGluZy1wcmVjb25zLTAwJnF1b3Q7 DQphbmQgJnF1b3Q7ZHJhZnQtY2FtYXJpbGxvLXNpcHBpbmctcmVpbnZpdGUtMDAmcXVvdDspIGFu ZCBtaW5lKCZxdW90O2RyYWZ0LWdhb3lhbmctc2lwcGluZy1zZXNzaW9uLXN0YXRlLWNyaXRlcmlv bi0wMyZxdW90OykNCmFzIG9uZSA8Yj5vciA8L2I+bWFraW5nICZxdW90O2RyYWZ0LWNhbWFyaWxs by1zaXBwaW5nLXByZWNvbnMtMDAmcXVvdDsNCmFuZCAmcXVvdDtkcmFmdC1nYW95YW5nLXNpcHBp bmctc2Vzc2lvbi1zdGF0ZS1jcml0ZXJpb24tMDMmcXVvdDsgYXMgb25lLA0KJnF1b3Q7ZHJhZnQt Y2FtYXJpbGxvLXNpcHBpbmctcmVpbnZpdGUtMDAmcXVvdDsgc2VwYXJhdGVseS48L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgdGhpbmsgbWFraW5nIHRo ZW0gYSB3aG9sZSBpcyBiZXR0ZXINCmZvciB0aGUgY29ycmVsYXRpb24gb2YgdGhlIHR3byB0b3Bp Y3MuIEl0IGlzIGp1c3QgbXkgc3VnZ2VzdGlvbiwgeW91IGNhbg0KZGVjaWRlIGluZGVwZW5kZW50 bHkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFu a3MsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW8u PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEw MDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4 NiktMDI1LTUyODc3MjExPGJyPg0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0K PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+R29uemFsbyBDYW1hcmlsbG8gJmx0O0dv bnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7c2lwY29yZS1ib3VuY2VzQGll dGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDktMDYt MjUgMTM6NTU8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+U0lQQ09SRSAmbHQ7c2lwY29yZUBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxk aXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+ PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltzaXBjb3JlXSBJbnB1 dCByZXF1ZXN0ZWQgb24gaG93IHRvDQpwcm9jZWVkIHdpdGggdGhlIGVzc2VudGlhbCBjb3JyZWN0 aW9ucyB0byBSRkMgMzI2MTwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJy Pjxmb250IHNpemU9Mj48dHQ+Rm9sa3MsPGJyPg0KPGJyPg0KYXMgeW91IGNhbiBzZWUgaW4gb3Vy IGNoYXJ0ZXIsIHdlIGhhdmUgdGhlIGZvbGxvd2luZyBtaWxlc3RvbmU6PGJyPg0KPGJyPg0KU2Vw IDIwMDkgLSBFc3NlbnRpYWwgY29ycmVjdGlvbnMgdG8gUkZDIDMyNjEgKDFzdCBiYXRjaCkgdG8g SUVTRyAoUFMpPGJyPg0KPGJyPg0KVGhlIHJlYXNvbiB3aHkgdGhlIG1pbGVzdG9uZSB0YWxrcyBh Ym91dCB0aGUgJnF1b3Q7Zmlyc3QgYmF0Y2gmcXVvdDsgY2FuDQpiZSBmb3VuZCA8YnI+DQppbiB0 aGUgZm9sbG93aW5nIGRyYWZ0Ojxicj4NCjxicj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWRyYWdlLXNpcC1lc3NlbnRpYWwtY29ycmVjdGlvbi0wMzxicj4NCjxicj4NClRoZSBk cmFmdCBhYm92ZSB0YWxrcyBhYm91dCBSRkNzIHRoYXQgYXJlIHVwZGF0ZWQgYnkgdGVucyBvZiBS RkNzLiBUaGUNCjxicj4NCmRyYWZ0IGNsYWltcyB0aGF0IGhhdmluZyBhIGxvdCBvZiBSRkNzIHVw ZGF0aW5nIGEgZ2l2ZW4gUkZDIHdvdWxkIGJlIDxicj4NCmNvbmZ1c2luZyBmb3IgaW1wbGVtZW50 ZXJzLiBBdCB0aGUgdGltZSBvZiB3cml0aW5nIHRoZSBkcmFmdCBhYm92ZSwgPGJyPg0KdGhlcmUg d2FzIGEgYmVsaWVmIHRoYXQgUkZDIDMyNjEgd2FzIGdvaW5nIHRvIGJlIGFuIGV4YW1wbGUgb2Yg YW4gUkZDIDxicj4NCnVwZGF0ZWQgYnkgdGVucyBvZiBSRkNzLiBUaGUgaWRlYSBpbiB0aGUgZHJh ZnQgaXMgdGhhdCBpbnN0ZWFkIG9mIDxicj4NCmlzc3VpbmcgYSBudW1iZXIgb2YgUkZDcyB1cGRh dGluZyB0aGUgb3JpZ2luYWwgb25lLCB0aGUgV0cgd291bGQgcHV0IGFsbA0KPGJyPg0KdGhvc2Ug dXBkYXRlcyB0b2dldGhlciBpbnRvIGEgYmF0Y2ggYW5kIHB1Ymxpc2ggdGhlIGJhdGNoIGFzIGEg c2luZ2xlIFJGQy48YnI+DQo8YnI+DQpBbmFseXppbmcgdGhlIGN1cnJlbnQgc2l0dWF0aW9uLCBS RkMgMzI2MSBoYXMgYWxyZWFkeSBiZWVuIHVwZGF0ZWQgYnkgPGJyPg0KdGhlIGZvbGxvd2luZyBS RkNzOiAzMjY1LCAzODUzLCA0MzIwLCA0OTE2LCA1MzkzPGJyPg0KPGJyPg0KQWRkaXRpb25hbGx5 LCB0aGVyZSBhcmUgYSBmZXcgZHJhZnRzIHRoYXQgd2lsbCwgaWYgYXBwcm92ZWQsIHVwZGF0ZSBS RkMNCjxicj4NCjMyNjEgYXMgd2VsbDo8YnI+DQo8YnI+DQpEcmFmdCBhbHJlYWR5IHdpdGggdGhl IElFU0c6PGJyPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zaXAtYm9k eS1oYW5kbGluZy0wNjxicj4NCjxicj4NCkRyYWZ0IHRoYXQgY291bGQgYmUgaW5jbHVkZWQgaW4g dGhlIGVzc2VudGlhbCBjb3JyZWN0aW9ucyBwcm9jZXNzIHdoZW4NCjxicj4NCnRoZWlyIGNvbnRl bnRzIGFyZSBhcHByb3ZlZDo8YnI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXNpcC1pcHY2LWFibmYtZml4LTAzPGJyPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtc3BhcmtzLXNpcC1pbnZmaXgtMDM8YnI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1jYW1hcmlsbG8tc2lwcGluZy1yZWludml0ZS0wMDxicj4NCjxicj4NCkl0IHR1cm5z IG91dCB0aGF0IHRoZSB0b3RhbCBudW1iZXIgb2YgUkZDcyB1cGRhdGluZyBSRkMgMzI2MSBoYXMg bm90IDxicj4NCmdyb3duIGFzIG11Y2ggYXMgZXhwZWN0ZWQuIFRoZSBudW1iZXIgb2YgUkZDcyBk b2N1bWVudGluZyBlc3NlbnRpYWwgPGJyPg0KY29ycmVjdGlvbnMgKGEgc3Vic2V0IG9mIGFsbCB0 aGUgUkZDcyB1cGRhdGluZyBSRkMgMzI2MSkgaXMgYWxzbyBsb3dlcg0KPGJyPg0KdGhhbiBleHBl Y3RlZC4gKEZyb20gU2VjdGlvbiAzIG9mIHRoZSBlc3NlbnRpYWwgY29ycmVjdGlvbnMgZHJhZnQs IGFuIDxicj4NCmVzc2VudGlhbCBjaGFuZ2UgaXMgb25lIHdoZXJlIGluIHRoZSBhYnNlbmNlIG9m IHRoZSBjb3JyZWN0aW9uLCBpdCB3aWxsDQo8YnI+DQpub3QgYmUgcG9zc2libGUgdG8gaW1wbGVt ZW50IHRoZSBzcGVjaWZpY2F0aW9uIGNvbnRhaW5lZCBpbiB0aGUgb3JpZ2luYWwNCjxicj4NClJG QyBpbiBhIG1hbm5lciB0byBlbnN1cmUgaW50ZXJvcGVyYWJpbGl0eSBvciBjb3JyZWN0IG9wZXJh dGlvbi4pPGJyPg0KPGJyPg0KVGhlIGdlbmVyYWwgZGVjaXNpb24gd2UgaGF2ZSB0byBtYWtlIGF0 IHRoaXMgcG9pbnQsIGdpdmVuIHRoZSBzbWFsbCA8YnI+DQpudW1iZXIgb2YgZHJhZnRzIGRvY3Vt ZW50aW5nIGVzc2VudGlhbCBjb3JyZWN0aW9ucywgaXMgd2hldGhlciB3ZSB3YW50DQo8YnI+DQp0 byBkb2N1bWVudCBlc3NlbnRpYWwgY29ycmVjdGlvbnMgaW4gYmF0Y2hlcywgcGVyIHRoZSBlc3Nl bnRpYWwgPGJyPg0KY29ycmVjdGlvbnMgcHJvY2Vzcywgb3IgaW4gaW5kaXZpZHVhbCBkcmFmdHMs IGFzIGl0IGhhcyBiZWVuIGRvbmUgaW4gdGhlDQo8YnI+DQpwYXN0Ljxicj4NCjxicj4NClRoZSBj b25jcmV0ZSBkZWNpc2lvbiB3ZSBoYXZlIHRvIG1ha2UgaXMgd2hldGhlciBpdCBtYWtlcyBzZW5z ZSB0byBtZXJnZQ0KPGJyPg0KdGhlIGZvbGxvd2luZyBkcmFmdHMgaW4gYSBiYXRjaCwgcGVyIHRo ZSBlc3NlbnRpYWwgY29ycmVjdGlvbnMgcHJvY2VzcywNCjxicj4NCm9yIHdoZXRoZXIgd2UgYWR2 YW5jZSB0aGVzZSBkcmFmdHMgaW5kZXBlbmRlbnRseS48YnI+DQo8YnI+DQpodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNpcC1pcHY2LWFibmYtZml4LTAzPGJyPg0KaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc3BhcmtzLXNpcC1pbnZmaXgtMDM8YnI+DQpodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1hcmlsbG8tc2lwcGluZy1yZWludml0ZS0w MDxicj4NCjxicj4NCldlIHdvdWxkIGFwcHJlY2lhdGUgdGhlIGZlZWRiYWNrIG9mIHRoZSBXRyBv biB0aGlzIGlzc3VlIHNvIHRoYXQgd2UgY2FuDQo8YnI+DQptYWtlIHByb2dyZXNzIHVwZGF0aW5n IFJGQyAzMjYxLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQo8YnI+DQpHb256YWxvPGJyPg0KU0lQ Q09SRSBjby1jaGFpcjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0Kc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQpzaXBjb3JlQGll dGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3Jl PGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZv cm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0 aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5i c3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5i c3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZu YnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNw O2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNw O3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0 byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMm bmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwm bmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZu YnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQm bmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZu YnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNw O3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZl Jm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5i c3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5i c3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZu YnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29m Jm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdl Jm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5i c3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lz dGVtLg0KPC9wcmU+ --=_alternative 003DE0E9482575E0_=-- From ietf.hanserik@gmail.com Thu Jun 25 06:19:20 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD8C53A6B81 for ; Thu, 25 Jun 2009 06:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 682X1SqkAnBG for ; Thu, 25 Jun 2009 06:19:19 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 051EA28C151 for ; Thu, 25 Jun 2009 06:19:05 -0700 (PDT) Received: by ewy6 with SMTP id 6so2220086ewy.37 for ; Thu, 25 Jun 2009 06:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=leTTjnpkDN+EhTfVutR6xbKB+0quCWWqT7zeOQe0s0s=; b=MDgilp0hKfsF4B8uDcRD+/iJzQXlP9OTYAFTSSmDLuDfFfLlrKOZDq4EaquvamMBvP 4P8GDGYEY8eKXSBRZe8DZ67XNDbzhPd0LFercyn3MJMgiLIDxp1g7uBkcxei9F/X/c/i 3vqFEDdEGUKJeIeQZNHIQHj995eFs1pFQzOqo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QlVfBcDl5fg+la1Re1AY329vD1DuvyA6BB/Sf14Gtf2vrBB4xXzxlpIIuEIjKYQOx8 Zpgy8pjCIIrA2g+7oe6C+JZ0hIyffiKA4BQ+enFksi36fI1bIHE39UGZuqhIFEmXiE+L hufB18yZO9kklgS80LwtozsVbSO/jfx5ocs2g= MIME-Version: 1.0 Received: by 10.216.7.209 with SMTP id 59mr755952wep.213.1245935920523; Thu, 25 Jun 2009 06:18:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 25 Jun 2009 15:18:40 +0200 Message-ID: <9ae56b1e0906250618x328c3012t9cb634f654f17469@mail.gmail.com> From: Hans Erik van Elburg To: "James M. Polk" Content-Type: multipart/alternative; boundary=0016364c7d91f4a9f3046d2c0fef Cc: sipcore@ietf.org, "Thomson, Martin" Subject: Re: [sipcore] SIPCORE Location Conveyance -00 submitted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 13:19:20 -0000 --0016364c7d91f4a9f3046d2c0fef Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit So what IS the semantics of something like: Geolocation: wrote: > Inline, > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Thursday, 25 June 2009 10:03 AM > > To: Thomson, Martin; sipcore@ietf.org > > Subject: RE: [sipcore] SIPCORE Location Conveyance -00 submitted > > > > At 06:06 PM 6/24/2009, Thomson, Martin wrote: > > >Hi James, > > > > > >I'll preface this email with the usual note that it's shocking how > > >old this document is. This is an important document from my > > >perspective, and it needs to be published. > > > > > >Your rewritten intro is a great improvement. I didn't read in > > >detail beyond this, but it's certainly much clearer. > > > > > >I note that the example PIDF-LO documents still contain > > >errors. Refer to 5491 or one of my previous reviews for details. > > > > your previous emails have never had any details to know what you're > > talking about... just as this one doesn't. Since I cannot determine > > what you want changed, knowing I'm not a mind reader, the text > > remains as it is. > > I don't have time right now to detail the myriad ways. For now all I can > do is suggest that you validate the XML. Before you do though, ensure that > you remove all instances of processContents="lax" so that the validator > doesn't decide to skip validation on anything. > > Offhand, I noted that provided-by usage is incorrect (remove it), you > omitted the mandatory deviceID element from device, timestamp comes after > status, retransmission-allowed is of the 'xs:boolean' type which means > s/no/false/ (contrary to what might be indicated in RFC4119). > > > >The one major flaw that I highlighted in my WGLC comments to the > > >former SIP WG remains. The document does not establish strict > > >semantics for the location it conveys. Is the location information > > >indicated in a Geolocation header belong to the entity identified in > > >the From header? Or is it the UAC that sends the request? While > > >this might seem intuitive, it's not. To complicate things, the > > >PIDF-LO can contain alternative identification information, there is > > >a potential for confusion or conflict. > > > > Please read the parts you say you didn't read this time to read the > > text that's been in the doc for quite some time now that discusses > > this. > > I just re-read the first 10 pages, plus the descriptions of UAC and UAS > behaviour without finding anything other than vague hints. In all cases you > talk about "target", "Target" or "Alice" without describing how that > identity is established or linked to any protocol parameters. I'd expect > this to be more clearly described before you get into the protocol details. > > I did find this hidden at the bottom of S4.1: > > The > element [RFC5491] in the PIDF-LO XML indicates whose location > is contained in the PIDF-LO. > > This is potentially of no use: SIP peers do not necessarily have the > necessary context to make sense of these identifiers; deviceID is not > mandatory; and for privacy reasons I would recommend to anyone implementing > this that they do not provide this information. > > (The correct reference here is RFC 4479 - presence data model, which > defines this field; and I suspect that you mean ..., > not , which has other semantics.) > > > >This document needs to be really clear about who the location > > >belongs to within the context of the exchange. > > > > here's a hint: this is (and has always been) done in the PIDF-LO, > > this is not (and never has been) part of any of the SIP headers. > > Now this is a problem indeed. The possibility that the PIDF-LO contains an > unlinked pseudonym (c.f. RFC 3693) has to be considered. Note also the > above problems. > > > > > >--Martin > > > > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > > ------------------------------------------------------------------------------------------------ > [mf2] > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0016364c7d91f4a9f3046d2c0fef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So what IS the semantics of something like:
Geolocation: <= ;tel:+351912795300; inserted-by=3D"node1.example.com"

Does it express the = location of the sender?
Can it express the location of the receiver?
Can the meaning= depend on who inserted it?
Where does it say so?

<= /div>
Also the use of the word Target is extremely confusing in a SIP s= etting, even if you define it to mean something else then what it means nor= mally.

BR,
/Hans Erik van Elburg

On Thu, Jun 25, 2009 at 2:33 AM, Thomson, Ma= rtin <Mar= tin.Thomson@andrew.com> wrote:
Inline,

> -----Original Message-----
> From: James M. Polk [mailto:jmpolk= @cisco.com]
> Sent: Thursday, 25 June 2009 10:03 AM
> To: Thomson, Martin; sipcore@ietf.= org
> Subject: RE: [sipcore] SIPCORE Location Conveyance -00 submitted
>
> At 06:06 PM 6/24/2009, Thomson, Martin wrote:
> >Hi James,
> >
> >I'll preface this email with the usual note that it's shoc= king how
> >old this document is. =A0This is an important document from my
> >perspective, and it needs to be published.
> >
> >Your rewritten intro is a great improvement. =A0I didn't read = in
> >detail beyond this, but it's certainly much clearer.
> >
> >I note that the example PIDF-LO documents still contain
> >errors. =A0Refer to 5491 or one of my previous reviews for details= .
>
> your previous emails have never had any details to know what you'r= e
> talking about... just as this one doesn't. Since I cannot determin= e
> what you want changed, knowing I'm not a mind reader, the text
> remains as it is.

I don't have time right now to detail the myriad ways. =A0For now= all I can do is suggest that you validate the XML. =A0Before you do though= , ensure that you remove all instances of processContents=3D"lax"= so that the validator doesn't decide to skip validation on anything.
Offhand, I noted that provided-by usage is incorrect (remove it), you omitt= ed the mandatory deviceID element from device, timestamp comes after status= , retransmission-allowed is of the 'xs:boolean' type which means s/= no/false/ (contrary to what might be indicated in RFC4119).

> >The one major flaw that I highlighted in my WGLC comments to the > >former SIP WG remains. =A0The document does not establish strict > >semantics for the location it conveys. =A0Is the location informat= ion
> >indicated in a Geolocation header belong to the entity identified = in
> >the From header? =A0Or is it the UAC that sends the request? =A0Wh= ile
> >this might seem intuitive, it's not. =A0To complicate things, = the
> >PIDF-LO can contain alternative identification information, there = is
> >a potential for confusion or conflict.
>
> Please read the parts you say you didn't read this time to read th= e
> text that's been in the doc for quite some time now that discusses=
> this.

I just re-read the first 10 pages, plus the descriptions of UAC and U= AS behaviour without finding anything other than vague hints. =A0In all cas= es you talk about "target", "Target" or "Alice&quo= t; without describing how that identity is established or linked to any pro= tocol parameters. =A0I'd expect this to be more clearly described befor= e you get into the protocol details.

I did find this hidden at the bottom of S4.1:

=A0 =A0 =A0 =A0The <dm:device id>
=A0 =A0 =A0 =A0element [RFC5491] in the PIDF-LO XML indicates whose locati= on
=A0 =A0 =A0 =A0is contained in the PIDF-LO.

This is potentially of no use: =A0SIP peers do not necessarily have the nec= essary context to make sense of these identifiers; deviceID is not mandator= y; and for privacy reasons I would recommend to anyone implementing this th= at they do not provide this information.

(The correct reference here is RFC 4479 - presence data model, which define= s this field; and I suspect that you mean <deviceID>...</deviceID&= gt;, not <device id=3D"xxx">, which has other semantics.)

> >This document needs to be really clear about who the location
> >belongs to within the context of the exchange.
>
> here's a hint: this is (and has always been) done in the PIDF-LO,<= br> > this is not (and never has been) part of any of the SIP headers.

Now this is a problem indeed. =A0The possibility that the PIDF-LO con= tains an unlinked pseudonym (c.f. RFC 3693) has to be considered. =A0Note a= lso the above problems.

>
> >--Martin
> >

---------------------------------------------------------------------------= ---------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. =A0Any unauthorized use of
this email is prohibited.
---------------------------------------------------------------------------= ---------------------
[mf2]
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--0016364c7d91f4a9f3046d2c0fef-- From vkg@alcatel-lucent.com Thu Jun 25 07:22:02 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 414BC3A68C8 for ; Thu, 25 Jun 2009 07:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+hNOrVjhcUL for ; Thu, 25 Jun 2009 07:22:01 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 1B6653A682E for ; Thu, 25 Jun 2009 07:22:01 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n5PDw9qx025526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jun 2009 08:58:09 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n5PDw95V023043; Thu, 25 Jun 2009 08:58:09 -0500 (CDT) Message-ID: <4A438271.2030909@alcatel-lucent.com> Date: Thu, 25 Jun 2009 08:58:09 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A43115C.7040902@ericsson.com> In-Reply-To: <4A43115C.7040902@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: SIPCORE Subject: Re: [sipcore] Input requested on how to proceed with the essential corrections to RFC 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 14:22:02 -0000 Gonzalo Camarillo wrote: [...] > The concrete decision we have to make is whether it makes sense to merge > the following drafts in a batch, per the essential corrections process, > or whether we advance these drafts independently. > > http://tools.ietf.org/html/draft-ietf-sip-ipv6-abnf-fix-03 > http://tools.ietf.org/html/draft-sparks-sip-invfix-03 > http://tools.ietf.org/html/draft-camarillo-sipping-reinvite-00 > > We would appreciate the feedback of the WG on this issue so that we can > make progress updating RFC 3261. Gonzalo: I don't have a hard opinion one way or the other. That said, a quick analysis on the existing corpus of RFCs to see which RFC has been updated by the most number of RFCs reveals that rfc1035 has been updated by 20 RFCs (and rfc1035 is a standards track document), followed by rfc1034 (14 updates.) The next highest distribution bin from there clusters around 3-5 updates. So, if the past in the form of rfc1035 is any guide, then rfc3261 has a way to go, and we should be okay by having each individual document update rfc3261 independently. Or alternatively, you can advance the drafts that have been previously identified as part of the essential corrections process in a batch, but once that is done, revert back to the normal mode of operations -- each file updates the base RFC in its own manner. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From ian.elz@ericsson.com Thu Jun 25 08:33:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50AB93A6BE5 for ; Thu, 25 Jun 2009 08:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxxb9G0GQoLz for ; Thu, 25 Jun 2009 08:33:30 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A2E403A6B74 for ; Thu, 25 Jun 2009 08:33:29 -0700 (PDT) X-AuditID: c1b4fb3c-b7bdcae0000052f9-2f-4a4393cb0247 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 3F.78.21241.BC3934A4; Thu, 25 Jun 2009 17:12:11 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Jun 2009 17:12:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 17:12:43 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 4244bis and privacy Thread-Index: Acn0Lcc7X7sq6TfYRnWN9a4W8C0fHQAARIBQAADAA2AAGracUAAO1MaQAAH7tqAAAL/rAAAvtR7A References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> From: "Ian Elz" To: "Mary Barnes" X-OriginalArrivalTime: 25 Jun 2009 15:12:11.0142 (UTC) FILETIME=[503F0260:01C9F5A7] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 15:33:32 -0000 Mary, I am a little concerned about one answer that you gave: If you have a Privacy header with a value of "none" and a H-I entry with Privacy header parameter with value "history" what is the privacy of the individual H-I entry? [MB] We did not explicitly address the "none" in RFC 4244, but the general statement is the privacy headers at the request level override any at the hi-entry level. [/MB] =20 This means that if privacy is required for an individual H-I entry but the originating user included "Privacy:none" in the request then there is no option to include the real URI in the H-I entry. This occurs as RFC3323 states in section 4.3: "However, if the Privacy header value of 'none' is specified in a message, privacy services MUST NOT perform any privacy function and MUST NOT remove or modify the Privacy header." The only option for an intermediate node including a H-I entry where "Privacy:none" is specified and privacy for the H-I URI is required is to include an anonymous entry or not include the H-I entry. In your previous response you stated that we would violate RFC3323 if we specified additional behaviour for privacy explicitly stated with a URI -n the H-I entry. I don't believe that this is the case as RFC3323 only considered privacy in a two party scenario and did not consider third party identities being included in a message between two parties. H-I is not the only case where this occurs as the Referred-By header when included in the INVITE (or other request) which results from the REFER has the same issue. RFC4244 was the first time that there was a recognition that privacy for these individual third party identities may be required. To allow this explicit statement of privacy to be overridden by a generic statement which is applicable to a different user is counterintuitive. The original Privacy header is usually included by or on behalf of the originating user and should not be allowed to specify the privacy of the original called user, e.g. the 800 number, and prevent this identity being presented if this user does not have the same level of privacy. The real issue with the 800 scenario is as you have stated is that the answerer will not know the original called identity and will not be able to correctly handle the call. As more generic call centres are used which will answer calls on behalf of many different organizations using CTI and the original called identity to have to implement a generic system asking the caller who he originally called appear unprofessional, is inefficient and unproductive. We have an opportunity to allow presentation of specific identities and to solve this particular problem so we should take it. I hope that we can get some wider discussion on this issue so a more general consensus can be obtained. Regards Ian -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: 24 June 2009 17:27 To: Ian Elz Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Francois Audet Subject: RE: 4244bis and privacy Hi Ian, Responses inline below [MB]. Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Wednesday, June 24, 2009 10:37 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Audet, Francois (SC100:3055) Subject: RE: 4244bis and privacy Mary, I was not proposing that we change the handling of H-I which is based upon local policy. If that causes an issue for a network operator then they can modify their local policy accordingly or arrange with the proxy vendor to modify their equipment to be more flexible with regards to policy. Can you clarify for me: If you have a Privacy header with either "session" or "header" doe this impact the H-I entries or will only a value of "history" impact the H-I entries? [MB] Yes, both "session" and "header" level privacy, consistent with RFC 3323, mandate that entries be anonymized or dropped, with the latter being the recommendation for "session" level privacy. RFC 4244 mandated that they be dropped and 4244bis recommends they be anonymized. The original intent for the value of "history" was for the tagging of the individual entries, but you end up getting the header level functionality as well. [/MB]=20 If you have a Privacy header with a value of "none" and a H-I entry with Privacy header parameter with value "history" what is the privacy of the individual H-I entry? [MB] We did not explicitly address the "none" in RFC 4244, but the general statement is the privacy headers at the request level override any at the hi-entry level. [/MB] >From reading RFC4244 a Privacy header with value "history" will effectively make all H-I entries private and there is currently no option to include a H-I Privacy header parameter with value "none". [MB] Correct, per my comment above. [/MB] H-I at present allows the inclusion of Privacy header parameters to explicitly express privacy for an individual H-I entry but a single node which includes a header "Privacy: history" makes all H-I entries private even if this is not the requirements for the specific URI. [MB] Correct, but the only node that should add the header is a node which is responsible for the domain associated with the Request URI in the incoming request or is authorized to do so. [/MB] I will admit that having worked in a telephony environment for a long time I am used to having privacy of identities set on a per number basis and the relative inflexibility of the IETF Privacy header is relatively restrictive as to specifying which identities may be presented and which not. [MB] Yes, this is an entirely different paradigm. I developed telephony s/w for over a decade and this is entirely different - it provides a lot more flexibility, which makes things far, far less deterministic than what you have in telephony switches where your routing and translations are configured for the most part, with just a few capabilities for controlling the privacy and it's a closed network. =20 With RFC4244/4244bis, there MUST be a mechanism at the UAS or end application that can handle a request that doesn't have the appropriate information either because nodes didn't support History-Info or some random node in the network applied privacy (which I think is highly unlikely) - this is normative per section 5 of RFC 4244. So, the worst case scenario I see for this 800 service (which will get to the right UAS but without the exact 800 number that was dialed) is that it goes to a default ACD group/customer service agent, etc. who then needs to gather the appropriate information and in my experience this is often an IVR system these days. So, the service is not broken when privacy is applied in an undesireable manner, it's just not optimal. This is something that should be addressed in the target-uri draft which has all the details of how specific services use History-Info. One other thing to consider is that most networks that are emulating telephony type features use B2BUAs, which follow the UAS/UAC rules for the header rather than the proxy rules, noting that the UAC can set the Privacy header to whatever value it sees as appropriate for the request. [/MB] Regards=20 Ian -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: 24 June 2009 15:48 To: Ian Elz Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Francois Audet Subject: RE: 4244bis and privacy Hi Ian, I do not believe we should do the "override" behavior as I think that violates RFC 3323, as the "history" is really a subset of the cases whereby a UAC or proxy would add "session" or "header" to the request. And, the latter two cases have the same (undesireable) result. I agree this impacts your services, but we can't mandate that proxies provide information that might violate their local policies and indeed a proxy's local policies can result in the information being anonymized (or removed if they can't anonymize) even in the "none" case.=20 I do believe it's reasonable that we strongly recommend that the request level (versus specific hi-entries) not be used and if it is used, the consequence is that some services will not have the information they need - this was the gist of my previous response (to which I did not get any additional feedback). Now, we could add some text that the "none" case SHOULD be used (e.g., added by first hop proxy) if it is desired that the information not be subject to privacy restrictions. I do not think it is then particularly useful to add logic around the proxy then being able to tag the entries within their domain as subject to privacy. I think that conflicts with the intent of the request level "none". However, as I mention above, per the current text, a proxy can (based on local policy) remove entries - so a proxy can capture hi within their domain and not forward any of that information to the next hop in another domain - you already have that functionality. But, I think this introduces the general problem that you might be impacting other services further down the line, which I thought was the problem you were wanting to solve - not specifically your example service but, for example, in the case that someone is debugging and they want the entire history, so depending upon the service, this is also undesirable behavior. =20 Regards, Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Wednesday, June 24, 2009 2:57 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Audet, Francois (SC100:3055) Subject: RE: 4244bis and privacy Mary, [I have added the list to this thread for wider comment.] In the previous discussions I commented that in RFC4424 that a Privacy header with value "history" effectively makes all H-I entries private with the result that the H-I entries may be removed. There has now been a comprehensive discussion on indication of the initial 'target' to the final recipient for call handling purposes. The main use case related to a freephone example where the answering location may be a call centre where the original freephone number may be required for correct call handling. If you now consider the following example (modified from Francois' text in the latest draft - excuse any errors that I may have inserted) INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx Privacy: history History-Info: ;index=3D1;rt;aor = (1) History-Info: ;index=3D1.1;mp;aor (2) History-Info: ;index=3D1.1.1;rc (3) In this case due to the Privacy header all of the H-I entries are considered private and the +18001234567 will not be delivered to the final destination with the result that call handling may not be correct. The Privacy header may have been inserted by any of the nodes which routed the message and inserted a H-I entry. If however the H-I was allowed to include a header parameter of "?Privacy=3Dnone" in the H-I entry and that an explicit H-I entry = privacy value would be considered to have precedence over a Privacy header with a value of "history" then the mapping of the +18001234567 could be explicitly specified as not private and may be passed on. Thus when the mapping from sip:+18001234567@example.com to sip:bob@biloxi.example.com when H-I entry (2) above is included could also insert the Privacy header parameter in H-I entry (1). Thus the message would appear as follows: INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx Privacy: history History-Info: ;index=3D= 1;rt;ao r History-Info: ;index=3D1.1;mp;aor History-Info: ;index=3D1.1.1;rc This would result in all the H-I entries except (1) being considered private with the result that the =3D1800... Number is passed for call handling purposes. This change is backward compatible with the existing implementation as any node using the existing functionality as defined in RFC4244 will continue to be supported. The alternative is to remove the ability to include the value "history" in the Privacy header and only allow this value in the Privacy header parameter. This alternative is not backward compatible. Without this change a single node in the message path which includes a header "Privacy: history" will prevent delivery of the aor and thus prevent proper call handling. Ian Elz -----Original Message----- From: Christer Holmberg Sent: 23 June 2009 19:40 To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida Schubert Cc: Ian Elz Subject: RE: 4244bis and privacy =20 Hi, I include Ian, so he can comment to your resposne himself. Regards, Christer -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Tuesday, June 23, 2009 9:40 PM To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida Schubert Subject: RE: 4244bis and privacy Here was the thread of response and the last comment was from Ian that he would consider the response: http://www.ietf.org/mail-archive/web/sip/current/msg26948.html And, there was not agreement on the "none" but rather to qualify the SHOULD NOT forward. However, in the sipcore-4244bis-00, rather than changing the text such that the headers SHOULD be removed, we recommend that they be anonymized (in section 4.3.3.3.1). That is entirely consistent with RFC 3324 and thus we have removed the recommendations to remove the headers entirely. However, that changed never got done in section 3.2, so we would need to change this: "Thus, the History- Info header SHOULD NOT be included in Requests where the requestor has indicated a priv-value of Session- or Header-level privacy." But, I'm really beginning to be of the mindset that we should just remove all the subsections of section 3 (i.e., leave the text in the upper level section), so we don't have to keep worrying about consistency. So, lets either fixt the text in 3.2 or remove altogether and then I think we are really at the point of needing to submit this version so folks that actually have an interest in it can review the updated document.=20 Mary.=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, June 23, 2009 1:10 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik van Elburg; Shida Schubert Subject: 4244bis and privacy Hi, Below is a comment/proposal which one of my collegues (Ian Elz) gave on the list a while ago, when the first version of 4244bis was submitted, but was not incorporated. Do you think it would be useful? ------- While the HI approach to target may solve the problem of being able to deliver the target URI to the final destination there is no guarantee that it will actually be delivered. The problem arises with how Privacy is defined for HI. 4424 defines a new Privacy value "history" which may be placed in either the Privacy header or as a header parameter to the HI entry. If one node uses the former option "Privacy: history" then this will make all headers private and will result in all HI entries being removed or made anonymous when the message containing the HI is delivered to the user. There is a simple solution to this and that is to also allow the use of the "none" Privacy value as a header parameter in the HI entry. This would explicitly state that no privacy is required to the HI entry and this would override a "history" value in the Privacy header. I pointed this out to Mary when the 4424bis draft was first published but the change has not been made in the latest draft. The change is backward compatible and would not cause an issue with any existing implementations. ------ Regards, Christer From ietf.hanserik@gmail.com Thu Jun 25 08:49:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A527A3A687F for ; Thu, 25 Jun 2009 08:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HTML_MESSAGE=0.001, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1crtFHQuPoN4 for ; Thu, 25 Jun 2009 08:49:52 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id D212A3A6839 for ; Thu, 25 Jun 2009 08:49:51 -0700 (PDT) Received: by ewy6 with SMTP id 6so2389940ewy.37 for ; Thu, 25 Jun 2009 08:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=7fQadmFlc3eEyd/5SosgYBgWxDO6FlV95s5Ycxsa0Ps=; b=hkwj16dpqJ+pGQZDT9GmlDUYqWritip/mlBkORPMigz6jFOffbs90TGcqc/+82zyFb 27GuZx/lmqkKaB8wqJza7Z9YwpOFcSlt8Rm5sz/BI/PwVFRjaEKGzW+7sycb47kfCV4V fjJPrkvAwUFjvwAsZ/rj2sDl1rxvOH77F0ZCg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=T9UdjAJK/5MmMXcXKdpxRN18sVhCiKFtyb0DWg27KboK1iH4QjmMDrPI8xGWCqGkzP HjXkrvtwoMyh+kp0DDon+4YGgxo/KPn/ElG0/ho5OC1+bC0c/gJzhn3JbRerh/8+RfI8 nvQSOTeAIPWyTRSKJk1aQplYz921D5/hLxptE= MIME-Version: 1.0 Received: by 10.216.19.17 with SMTP id m17mr770671wem.187.1245944898685; Thu, 25 Jun 2009 08:48:18 -0700 (PDT) In-Reply-To: References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> Date: Thu, 25 Jun 2009 17:48:18 +0200 Message-ID: <9ae56b1e0906250848l106e8a16j39fbca1ff3541c36@mail.gmail.com> From: Hans Erik van Elburg To: Ian Elz Content-Type: multipart/alternative; boundary=0016364c76ff188d3a046d2e277d Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 15:49:55 -0000 --0016364c76ff188d3a046d2e277d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ok Ian, now I see what you mean. You are saying that if A calls B which forwards to C, that A indicating that privacy is required should not prohibit B to choose to deliver its identity to C, right? I think I agree with you that this is a point that needs to be addressed by 4244bis. Best Regards, /Hans Erik van Elburg On Thu, Jun 25, 2009 at 5:12 PM, Ian Elz wrote: > Mary, > > I am a little concerned about one answer that you gave: > > > If you have a Privacy header with a value of "none" and a H-I entry with > Privacy header parameter with value "history" what is the privacy of the > individual H-I entry? > [MB] We did not explicitly address the "none" in RFC 4244, but the > general statement is the privacy headers at the request level override > any at the hi-entry level. [/MB] > > This means that if privacy is required for an individual H-I entry but > the originating user included "Privacy:none" in the request then there > is no option to include the real URI in the H-I entry. > > This occurs as RFC3323 states in section 4.3: "However, if the Privacy > header value of 'none' is specified in a message, privacy services MUST > NOT perform any privacy function and MUST NOT remove or modify the > Privacy header." > > The only option for an intermediate node including a H-I entry where > "Privacy:none" is specified and privacy for the H-I URI is required is > to include an anonymous entry or not include the H-I entry. > > In your previous response you stated that we would violate RFC3323 if we > specified additional behaviour for privacy explicitly stated with a URI > -n the H-I entry. I don't believe that this is the case as RFC3323 only > considered privacy in a two party scenario and did not consider third > party identities being included in a message between two parties. H-I is > not the only case where this occurs as the Referred-By header when > included in the INVITE (or other request) which results from the REFER > has the same issue. > > RFC4244 was the first time that there was a recognition that privacy for > these individual third party identities may be required. To allow this > explicit statement of privacy to be overridden by a generic statement > which is applicable to a different user is counterintuitive. > > The original Privacy header is usually included by or on behalf of the > originating user and should not be allowed to specify the privacy of the > original called user, e.g. the 800 number, and prevent this identity > being presented if this user does not have the same level of privacy. > > The real issue with the 800 scenario is as you have stated is that the > answerer will not know the original called identity and will not be able > to correctly handle the call. As more generic call centres are used > which will answer calls on behalf of many different organizations using > CTI and the original called identity to have to implement a generic > system asking the caller who he originally called appear unprofessional, > is inefficient and unproductive. > > We have an opportunity to allow presentation of specific identities and > to solve this particular problem so we should take it. > > I hope that we can get some wider discussion on this issue so a more > general consensus can be obtained. > > Regards > > Ian > > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 24 June 2009 17:27 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > sipcore@ietf.org; Francois Audet > Subject: RE: 4244bis and privacy > > Hi Ian, > > Responses inline below [MB]. > > Mary. > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, June 24, 2009 10:37 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > Mary, > > I was not proposing that we change the handling of H-I which is based > upon local policy. If that causes an issue for a network operator then > they can modify their local policy accordingly or arrange with the proxy > vendor to modify their equipment to be more flexible with regards to > policy. > > Can you clarify for me: > > If you have a Privacy header with either "session" or "header" doe this > impact the H-I entries or will only a value of "history" impact the H-I > entries? > [MB] Yes, both "session" and "header" level privacy, consistent with RFC > 3323, mandate that entries be anonymized or dropped, with the latter > being the recommendation for "session" level privacy. RFC 4244 mandated > that they be dropped and 4244bis recommends they be anonymized. The > original intent for the value of "history" was for the tagging of the > individual entries, but you end up getting the header level > functionality as well. [/MB] > > If you have a Privacy header with a value of "none" and a H-I entry with > Privacy header parameter with value "history" what is the privacy of the > individual H-I entry? > [MB] We did not explicitly address the "none" in RFC 4244, but the > general statement is the privacy headers at the request level override > any at the hi-entry level. [/MB] > > From reading RFC4244 a Privacy header with value "history" will > effectively make all H-I entries private and there is currently no > option to include a H-I Privacy header parameter with value "none". > [MB] Correct, per my comment above. [/MB] > > H-I at present allows the inclusion of Privacy header parameters to > explicitly express privacy for an individual H-I entry but a single node > which includes a header "Privacy: history" makes all H-I entries private > even if this is not the requirements for the specific URI. > [MB] Correct, but the only node that should add the header is a node > which is responsible for the domain associated with the Request URI in > the incoming request or is authorized to do so. [/MB] > > I will admit that having worked in a telephony environment for a long > time I am used to having privacy of identities set on a per number basis > and the relative inflexibility of the IETF Privacy header is relatively > restrictive as to specifying which identities may be presented and which > not. > [MB] Yes, this is an entirely different paradigm. I developed telephony > s/w for over a decade and this is entirely different - it provides a lot > more flexibility, which makes things far, far less deterministic than > what you have in telephony switches where your routing and translations > are configured for the most part, with just a few capabilities for > controlling the privacy and it's a closed network. > > With RFC4244/4244bis, there MUST be a mechanism at the UAS or end > application that can handle a request that doesn't have the appropriate > information either because nodes didn't support History-Info or some > random node in the network applied privacy (which I think is highly > unlikely) - this is normative per section 5 of RFC 4244. So, the worst > case scenario I see for this 800 service (which will get to the right > UAS but without the exact 800 number that was dialed) is that it goes to > a default ACD group/customer service agent, etc. who then needs to > gather the appropriate information and in my experience this is often an > IVR system these days. So, the service is not broken when privacy is > applied in an undesireable manner, it's just not optimal. This is > something that should be addressed in the target-uri draft which has all > the details of how specific services use History-Info. > One other thing to consider is that most networks that are emulating > telephony type features use B2BUAs, which follow the UAS/UAC rules for > the header rather than the proxy rules, noting that the UAC can set the > Privacy header to whatever value it sees as appropriate for the request. > [/MB] > > > Regards > > Ian > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 24 June 2009 15:48 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > sipcore@ietf.org; Francois Audet > Subject: RE: 4244bis and privacy > > Hi Ian, > > I do not believe we should do the "override" behavior as I think that > violates RFC 3323, as the "history" is really a subset of the cases > whereby a UAC or proxy would add "session" or "header" to the request. > And, the latter two cases have the same (undesireable) result. I agree > this impacts your services, but we can't mandate that proxies provide > information that might violate their local policies and indeed a proxy's > local policies can result in the information being anonymized (or > removed if they can't anonymize) even in the "none" case. > > I do believe it's reasonable that we strongly recommend that the request > level (versus specific hi-entries) not be used and if it is used, the > consequence is that some services will not have the information they > need - this was the gist of my previous response (to which I did not get > any additional feedback). Now, we could add some text that the "none" > case SHOULD be used (e.g., added by first hop proxy) if it is desired > that the information not be subject to privacy restrictions. I do not > think it is then particularly useful to add logic around the proxy then > being able to tag the entries within their domain as subject to privacy. > I think that conflicts with the intent of the request level "none". > However, as I mention above, per the current text, a proxy can (based on > local policy) remove entries - so a proxy can capture hi within their > domain and not forward any of that information to the next hop in > another domain - you already have that functionality. But, I think this > introduces the general problem that you might be impacting other > services further down the line, which I thought was the problem you were > wanting to solve - not specifically your example service but, for > example, in the case that someone is debugging and they want the entire > history, so depending upon the service, this is also undesirable > behavior. > > > Regards, > Mary. > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, June 24, 2009 2:57 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > > Mary, > > [I have added the list to this thread for wider comment.] > > In the previous discussions I commented that in RFC4424 that a Privacy > header with value "history" effectively makes all H-I entries private > with the result that the H-I entries may be removed. > > There has now been a comprehensive discussion on indication of the > initial 'target' to the final recipient for call handling purposes. > > The main use case related to a freephone example where the answering > location may be a call centre where the original freephone number may be > required for correct call handling. > > If you now consider the following example (modified from Francois' text > in the latest draft - excuse any errors that I may have inserted) > > INVITE sip:sip:+18001234567@example.com > ;user=phone;p=x > Privacy: history > History-Info: > ;user=phone;p=x>;index=1;rt;aor > (1) > History-Info: > >;index=1.1;mp;aor > (2) > History-Info: >;index=1.1.1;rc > (3) > > In this case due to the Privacy header all of the H-I entries are > considered private and the +18001234567 will not be delivered to the > final destination with the result that call handling may not be correct. > The Privacy header may have been inserted by any of the nodes which > routed the message and inserted a H-I entry. > > If however the H-I was allowed to include a header parameter of > "?Privacy=none" in the H-I entry and that an explicit H-I entry privacy > value would be considered to have precedence over a Privacy header with > a value of "history" then the mapping of the +18001234567 could be > explicitly specified as not private and may be passed on. > > Thus when the mapping from sip:+18001234567@example.comto > sip:bob@biloxi.example.com when H-I entry > (2) above is included could > also insert the Privacy header parameter in H-I entry (1). > > Thus the message would appear as follows: > > INVITE sip:sip:+18001234567@example.com; > user=phone;p=x > Privacy: history > History-Info: > ;index=1;rt;ao > r > History-Info: > >;index=1.1;mp;aor > History-Info: >;index=1.1.1;rc > > This would result in all the H-I entries except (1) being considered > private with the result that the =1800... Number is passed for call > handling purposes. > > This change is backward compatible with the existing implementation as > any node using the existing functionality as defined in RFC4244 will > continue to be supported. > > The alternative is to remove the ability to include the value "history" > in the Privacy header and only allow this value in the Privacy header > parameter. This alternative is not backward compatible. > > Without this change a single node in the message path which includes a > header "Privacy: history" will prevent delivery of the aor and thus > prevent proper call handling. > > Ian Elz > > > > -----Original Message----- > From: Christer Holmberg > Sent: 23 June 2009 19:40 > To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida Schubert > Cc: Ian Elz > Subject: RE: 4244bis and privacy > > > Hi, > > I include Ian, so he can comment to your resposne himself. > > Regards, > > Christer > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Tuesday, June 23, 2009 9:40 PM > To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida > Schubert > Subject: RE: 4244bis and privacy > > Here was the thread of response and the last comment was from Ian that > he would consider the response: > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html > > And, there was not agreement on the "none" but rather to qualify the > SHOULD NOT forward. However, in the sipcore-4244bis-00, rather than > changing the text such that the headers SHOULD be removed, we recommend > that they be anonymized (in section 4.3.3.3.1). That is entirely > consistent with RFC 3324 and thus we have removed the recommendations to > remove the headers entirely. However, that changed never got done in > section 3.2, so we would need to change this: > "Thus, the History- Info header > SHOULD NOT be included in Requests where the requestor has indicated > a priv-value of Session- or Header-level privacy." > > But, I'm really beginning to be of the mindset that we should just > remove all the subsections of section 3 (i.e., leave the text in the > upper level section), so we don't have to keep worrying about > consistency. > > So, lets either fixt the text in 3.2 or remove altogether and then I > think we are really at the point of needing to submit this version so > folks that actually have an interest in it can review the updated > document. > > Mary. > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, June 23, 2009 1:10 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik > van Elburg; Shida Schubert > Subject: 4244bis and privacy > > > Hi, > > Below is a comment/proposal which one of my collegues (Ian Elz) gave on > the list a while ago, when the first version of 4244bis was submitted, > but was not incorporated. Do you think it would be useful? > > ------- > > While the HI approach to target may solve the problem of being able to > deliver the target URI to the final destination there is no guarantee > that it will actually be delivered. > > The problem arises with how Privacy is defined for HI. > > 4424 defines a new Privacy value "history" which may be placed in either > the Privacy header or as a header parameter to the HI entry. > > If one node uses the former option "Privacy: history" then this will > make all headers private and will result in all HI entries being removed > or made anonymous when the message containing the HI is delivered to the > user. > > There is a simple solution to this and that is to also allow the use of > the "none" Privacy value as a header parameter in the HI entry. This > would explicitly state that no privacy is required to the HI entry and > this would override a "history" value in the Privacy header. > > I pointed this out to Mary when the 4424bis draft was first published > but the change has not been made in the latest draft. > > The change is backward compatible and would not cause an issue with any > existing implementations. > > ------ > > Regards, > > Christer > > > > > --0016364c76ff188d3a046d2e277d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok Ian, now I see what you mean.

You are saying that if = A calls B which forwards to C, that A indicating that privacy is required s= hould not prohibit B to choose to deliver its identity to C, right?

I think I agree with you that this is a point that need= s to be addressed by 4244bis.

Best Regards,
<= div>/Hans Erik van Elburg

On Thu, = Jun 25, 2009 at 5:12 PM, Ian Elz <ian.elz@ericsson.com> wrote:
Mary,

I am a little concerned about one answer that you gave:


If you have a Privacy header with a value of "none" and a H-I ent= ry with
Privacy header parameter with value "history" what is the privacy= of the
individual H-I entry?
[MB] We did not explicitly address the "none" in RFC 4244, but th= e
general statement is the privacy headers at the request level override
any at the hi-entry level. [/MB]

This means that if privacy is required for an individual H-I entry bu= t
the originating user included "Privacy:none" in the request then = there
is no option to include the real URI in the H-I entry.

This occurs as RFC3323 states in section 4.3: "However, if the Privacy=
header value of 'none' is specified in a message, privacy services = MUST
NOT perform any privacy function and MUST NOT remove or modify the
Privacy header."

The only option for an intermediate node including a H-I entry where
"Privacy:none" is specified and privacy for the H-I URI is requir= ed is
to include an anonymous entry or not include the H-I entry.

In your previous response you stated that we would violate RFC3323 if we specified additional behaviour for privacy explicitly stated with a URI
-n the H-I entry. I don't believe that this is the case as RFC3323 only=
considered privacy in a two party scenario and did not consider third
party identities being included in a message between two parties. H-I is not the only case where this occurs as the Referred-By header when
included in the INVITE (or other request) which results from the REFER
has the same issue.

RFC4244 was the first time that there was a recognition that privacy for these individual third party identities may be required. To allow this
explicit statement of privacy to be overridden by a generic statement
which is applicable to a different user is counterintuitive.

The original Privacy header is usually included by or on behalf of the
originating user and should not be allowed to specify the privacy of the original called user, e.g. the 800 number, and prevent this identity
being presented if this user does not have the same level of privacy.

The real issue with the 800 scenario is as you have stated is that the
answerer will not know the original called identity and will not be able to correctly handle the call. As more generic call centres are used
which will answer calls on behalf of many different organizations using
CTI and the original called identity to have to implement a generic
system asking the caller who he originally called appear unprofessional, is inefficient and unproductive.

We have an opportunity to allow presentation of specific identities and
to solve this particular problem so we should take it.

I hope that we can get some wider discussion on this issue so a more
general consensus can be obtained.

Regards

Ian



-----Original Message-----
From: Mary Barnes [mailto:mary.ba= rnes@nortel.com]
Sent: 24 June 2009 17:27
To: Ian Elz
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
sipcore@ietf.org; Francois Audet Subject: RE: 4244bis and privacy

Hi Ian,

Responses inline below [MB].

Mary.

-----Original Message-----
From: Ian Elz [mailto:ian.elz@erics= son.com]
Sent: Wednesday, June 24, 2009 10:37 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
sipcore@ietf.org; Audet, Francois (= SC100:3055)
Subject: RE: 4244bis and privacy

Mary,

I was not proposing that we change the handling of H-I which is based
upon local policy. If that causes an issue for a network operator then
they can modify their local policy accordingly or arrange with the proxy vendor to modify their equipment to be more flexible with regards to
policy.

Can you clarify for me:

If you have a Privacy header with either "session" or "heade= r" doe this
impact the H-I entries or will only a value of "history" impact t= he H-I
entries?
[MB] Yes, both "session" and "header" level privacy, co= nsistent with RFC
3323, mandate that entries be anonymized or dropped, with the latter
being the recommendation for "session" level privacy. RFC 4244 ma= ndated
that they be dropped and 4244bis recommends they be anonymized. The
original intent for the value of "history" was for the tagging of= the
individual entries, but you end up getting the header level
functionality as well. [/MB]

If you have a Privacy header with a value of "none" and a H-I ent= ry with
Privacy header parameter with value "history" what is the privacy= of the
individual H-I entry?
[MB] We did not explicitly address the "none" in RFC 4244, but th= e
general statement is the privacy headers at the request level override
any at the hi-entry level. [/MB]

>From reading RFC4244 a Privacy header with value "history" will effectively make all H-I entries private and there is currently no
option to =A0include a H-I Privacy header parameter with value "none&q= uot;.
[MB] Correct, per my comment above. [/MB]

H-I at present allows the inclusion of Privacy header parameters to
explicitly express privacy for an individual H-I entry but a single node which includes a header "Privacy: history" makes all H-I entries = private
even if this is not the requirements for the specific URI.
[MB] Correct, but the only node that should add the header is a node
which is responsible for the domain associated with the Request URI in
the incoming request or is authorized to do so. [/MB]

I will admit that having worked in a telephony environment for a long
time I am used to having privacy of identities set on a per number basis and the relative inflexibility of the IETF Privacy header is relatively
restrictive as to specifying which identities may be presented and which not.
[MB] Yes, this is an entirely different paradigm. =A0I developed telephony<= br> s/w for over a decade and this is entirely different - it provides a lot more flexibility, which makes things far, far less deterministic than
what you have in telephony switches where your routing and translations
are configured for the most part, with just a few capabilities for
controlling the privacy and it's a closed network.

With RFC4244/4244bis, there MUST be a mechanism at the UAS or end
application that can handle a request that doesn't have the appropriate=
information either because nodes didn't support History-Info or some random node in the network applied privacy (which I think is highly
unlikely) - this is normative per section 5 of RFC 4244. =A0So, the worst case scenario I see for this 800 service =A0(which will get to the right UAS but without the exact 800 number that was dialed) is that it goes to a default ACD group/customer service agent, etc. who then needs to
gather the appropriate information and in my experience this is often an IVR system these days. =A0So, the service is not broken when privacy is
applied in an undesireable manner, it's just not optimal. =A0This is something that should be addressed in the target-uri draft which has all the details of how specific services use History-Info.
One other thing to consider is that most networks that are emulating
telephony type features use B2BUAs, which follow the UAS/UAC rules for
the header rather than the proxy rules, noting that the UAC can set the
Privacy header to whatever value it sees as appropriate for the request. [/MB]


Regards

Ian

-----Original Message-----
From: Mary Barnes [mailto:mary.ba= rnes@nortel.com]
Sent: 24 June 2009 15:48
To: Ian Elz
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
sipcore@ietf.org; Francois Audet Subject: RE: 4244bis and privacy

Hi Ian,

I do not believe we should do the "override" behavior as I think = that
violates RFC 3323, as the "history" is really a subset of the cas= es
whereby a UAC or proxy would add "session" or "header" = to the request.
And, the latter two cases have the same (undesireable) result. =A0 I agree<= br> this impacts your services, but we can't mandate that proxies provide information that might violate their local policies and indeed a proxy'= s
local policies can result in the information being anonymized (or
removed if they can't anonymize) even in the "none" case.

I do believe it's reasonable that we strongly recommend that the reques= t
level (versus specific hi-entries) not be used and if it is used, the
consequence is that some services will not have the information they
need - this was the gist of my previous response (to which I did not get any additional feedback). Now, we could add some text that the "none&q= uot;
case SHOULD be used (e.g., added by first hop proxy) if it is desired
that the information not be subject to privacy restrictions. I do not
think it is then particularly useful to add logic around the proxy then
being able to tag the entries within their domain as subject to privacy. I think that conflicts with the intent of the request level "none"= ;.
However, as I mention above, per the current text, a proxy can (based on local policy) remove entries - so a proxy can capture hi within their
domain and not forward any of that information to the next hop in
another domain - you already have that functionality. =A0But, I think this<= br> introduces the general problem that you might be impacting other
services further down the line, which I thought was the problem you were wanting to solve - not specifically your example service but, for
example, in the case that someone is debugging and they want the entire
history, so depending upon the service, this is also undesirable
behavior.


Regards,
Mary.

-----Original Message-----
From: Ian Elz [mailto:ian.elz@erics= son.com]
Sent: Wednesday, June 24, 2009 2:57 AM
To: Barnes, Mary (RICH2:AR00)
Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
sipcore@ietf.org; Audet, Francois (= SC100:3055)
Subject: RE: 4244bis and privacy


=A0Mary,

[I have added the list to this thread for wider comment.]

In the previous discussions I commented that in RFC4424 that a Privacy
header with value "history" effectively makes all H-I entries pri= vate
with the result that the H-I entries may be removed.

There has now been a comprehensive discussion on indication of the
initial 'target' to the final recipient for call handling purposes.=

The main use case related to a freephone example where the answering
location may be a call centre where the original freephone number may be required for correct call handling.

If you now consider the following example (modified from Francois' text=
in the latest draft - excuse any errors that I may have inserted)

INVITE sip:sip:+1= 8001234567@example.com;user=3Dphone;p=3Dx
Privacy: history
History-Info:
<sip:+18001234567@ex= ample.com;user=3Dphone;p=3Dx>;index=3D1;rt;aor =A0 =A0 =A0 =A0 (1) History-Info: <sip:bob@b= iloxi.example.com>;index=3D1.1;mp;aor
(2)
History-Info: <sip:bob@192.0.2.3<= /a>>;index=3D1.1.1;rc
(3)

In this case due to the Privacy header all of the H-I entries are
considered private and the +18001234567 will not be delivered to the
final destination with the result that call handling may not be correct. The Privacy header may have been inserted by any of the nodes which
routed the message and inserted a H-I entry.

If however the H-I was allowed to include a header parameter of
"?Privacy=3Dnone" in the H-I entry and that an explicit H-I entry= privacy
value would be considered to have precedence over a Privacy header with
a value of "history" then the mapping of the +18001234567 could b= e
explicitly specified as not private and may be passed on.

Thus when the mapping from sip:+18001234567@example.com to
sip:bob@biloxi.example.com<= /a> when H-I entry (2) above is included could
also insert the Privacy header parameter in H-I entry (1).

Thus the message would appear as follows:

INVITE sip:sip:+1= 8001234567@example.com; user=3Dphone;p=3Dx
Privacy: history
History-Info:
<sip:+18001234567@example.com?Privacy=3Dnone;us= er=3Dphone;p=3Dx>;index=3D1;rt;ao
r
History-Info: <sip:bob@b= iloxi.example.com>;index=3D1.1;mp;aor
History-Info: <sip:bob@192.0.2.3<= /a>>;index=3D1.1.1;rc

This would result in all the H-I entries except (1) being considered
private with the result that the =3D1800... Number is passed for call
handling purposes.

This change is backward compatible with the existing implementation as
any node using the existing functionality as defined in RFC4244 will
continue to be supported.

The alternative is to remove the ability to include the value "history= "
in the Privacy header and only allow this value in the Privacy header
parameter. This alternative is not backward compatible.

Without this change a single node in the message path which includes a
header "Privacy: history" will prevent delivery of the aor and th= us
prevent proper call handling.

Ian Elz



-----Original Message-----
From: Christer Holmberg
Sent: 23 June 2009 19:40
To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida Schu= bert
Cc: Ian Elz
Subject: RE: 4244bis and privacy


Hi,

I include Ian, so he can comment to your resposne himself.

Regards,

Christer


-----Original Message-----
From: Mary Barnes [mailto:mary.ba= rnes@nortel.com]
Sent: Tuesday, June 23, 2009 9:40 PM
To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida
Schubert
Subject: RE: 4244bis and privacy

Here was the thread of response and the last comment was from Ian that
he would consider the response:
http://www.ietf.org/mail-archive/web/sip/current/msg26948= .html

And, there was not agreement on the "none" but rather to qualify = the
SHOULD NOT forward. =A0However, in the sipcore-4244bis-00, rather than
changing the text such that the headers SHOULD be removed, we recommend
that they be anonymized (in section 4.3.3.3.1). =A0That is entirely
consistent with RFC 3324 and thus we have removed the recommendations to remove the headers entirely. However, that changed never got done in
section 3.2, so we would need to change this:
=A0 "Thus, the History- Info header
=A0 SHOULD NOT be included in Requests where the requestor has indicated =A0 a priv-value of Session- or Header-level privacy."

But, I'm really beginning to be of the mindset that we should just
remove all the subsections of section 3 (i.e., leave the text in the
upper level section), so we don't have to keep worrying about
consistency.

So, lets either fixt the text in 3.2 or remove altogether and then I
think we are really at the point of needing to submit this version so
folks that actually have an interest in it can review the updated
document.

Mary.

-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Tuesday, June 23, 2009 1:10 PM
To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik
van Elburg; Shida Schubert
Subject: 4244bis and privacy


Hi,

Below is a comment/proposal which one of my collegues (Ian Elz) gave on
the list a while ago, when the first version of 4244bis was submitted,
but was not incorporated. Do you think it would be useful?

-------

While the HI approach to target may solve the problem of being able to
deliver the target URI to the final destination there is no guarantee
that it will actually be delivered.

The problem arises with how Privacy is defined for HI.

4424 defines a new Privacy value "history" which may be placed in= either
the Privacy header or as a header parameter to the HI entry.

If one node uses the former option "Privacy: history" then this w= ill
make all headers private and will result in all HI entries being removed or made anonymous when the message containing the HI is delivered to the user.

There is a simple solution to this and that is to also allow the use of
the "none" Privacy value as a header parameter in the HI entry. T= his
would explicitly state that no privacy is required to the HI entry and
this would override a "history" value in the Privacy header.

I pointed this out to Mary when the 4424bis draft was first published
but the change has not been made in the latest draft.

The change is backward compatible and would not cause an issue with any
existing implementations.

------

Regards,

Christer





--0016364c76ff188d3a046d2e277d-- From AUDET@nortel.com Thu Jun 25 09:29:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49D83A67D2 for ; Thu, 25 Jun 2009 09:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.18 X-Spam-Level: X-Spam-Status: No, score=-6.18 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2LScv-I3lqC for ; Thu, 25 Jun 2009 09:29:13 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0559B3A6A90 for ; Thu, 25 Jun 2009 09:29:08 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5PGSPc25833; Thu, 25 Jun 2009 16:28:26 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9F5B1.D2380D3C" Date: Thu, 25 Jun 2009 11:27:23 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EB26254@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0906250848l106e8a16j39fbca1ff3541c36@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 4244bis and privacy thread-index: Acn1rF/25G9NhF7hQLaaPMONTzUgJQABMOXg References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> <9ae56b1e0906250848l106e8a16j39fbca1ff3541c36@mail.gmail.com> From: "Francois Audet" To: "Hans Erik van Elburg" , "Ian Elz" Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 16:29:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F5B1.D2380D3C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You mean "should not prohibit B to choose to deliver the identity of B = to C", right? ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, June 25, 2009 08:48 To: Ian Elz Cc: Barnes, Mary (RICH2:AR00); Christer Holmberg; Shida Schubert; = sipcore@ietf.org; Audet, Francois (SC100:3055) Subject: Re: 4244bis and privacy =09 =09 Ok Ian, now I see what you mean.=20 You are saying that if A calls B which forwards to C, that A indicating = that privacy is required should not prohibit B to choose to deliver its = identity to C, right? I think I agree with you that this is a point that needs to be = addressed by 4244bis. Best Regards, /Hans Erik van Elburg On Thu, Jun 25, 2009 at 5:12 PM, Ian Elz wrote: =09 Mary, =09 I am a little concerned about one answer that you gave: =09 If you have a Privacy header with a value of "none" and a H-I entry = with Privacy header parameter with value "history" what is the privacy of = the individual H-I entry? [MB] We did not explicitly address the "none" in RFC 4244, but the general statement is the privacy headers at the request level override any at the hi-entry level. [/MB] =09 =09 This means that if privacy is required for an individual H-I entry but the originating user included "Privacy:none" in the request then there is no option to include the real URI in the H-I entry. =09 This occurs as RFC3323 states in section 4.3: "However, if the Privacy header value of 'none' is specified in a message, privacy services = MUST NOT perform any privacy function and MUST NOT remove or modify the Privacy header." =09 The only option for an intermediate node including a H-I entry where "Privacy:none" is specified and privacy for the H-I URI is required is to include an anonymous entry or not include the H-I entry. =09 In your previous response you stated that we would violate RFC3323 if = we specified additional behaviour for privacy explicitly stated with a = URI -n the H-I entry. I don't believe that this is the case as RFC3323 = only considered privacy in a two party scenario and did not consider third party identities being included in a message between two parties. H-I = is not the only case where this occurs as the Referred-By header when included in the INVITE (or other request) which results from the REFER has the same issue. =09 RFC4244 was the first time that there was a recognition that privacy = for these individual third party identities may be required. To allow this explicit statement of privacy to be overridden by a generic statement which is applicable to a different user is counterintuitive. =09 The original Privacy header is usually included by or on behalf of the originating user and should not be allowed to specify the privacy of = the original called user, e.g. the 800 number, and prevent this identity being presented if this user does not have the same level of privacy. =09 The real issue with the 800 scenario is as you have stated is that the answerer will not know the original called identity and will not be = able to correctly handle the call. As more generic call centres are used which will answer calls on behalf of many different organizations = using CTI and the original called identity to have to implement a generic system asking the caller who he originally called appear = unprofessional, is inefficient and unproductive. =09 We have an opportunity to allow presentation of specific identities = and to solve this particular problem so we should take it. =09 I hope that we can get some wider discussion on this issue so a more general consensus can be obtained. =09 Regards =09 Ian =09 =09 =09 -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] =09 Sent: 24 June 2009 17:27 To: Ian Elz Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Francois Audet Subject: RE: 4244bis and privacy =09 Hi Ian, =09 Responses inline below [MB]. =09 Mary. =09 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Wednesday, June 24, 2009 10:37 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Audet, Francois (SC100:3055) Subject: RE: 4244bis and privacy =09 Mary, =09 I was not proposing that we change the handling of H-I which is based upon local policy. If that causes an issue for a network operator then they can modify their local policy accordingly or arrange with the = proxy vendor to modify their equipment to be more flexible with regards to policy. =09 Can you clarify for me: =09 If you have a Privacy header with either "session" or "header" doe = this impact the H-I entries or will only a value of "history" impact the = H-I entries? [MB] Yes, both "session" and "header" level privacy, consistent with = RFC 3323, mandate that entries be anonymized or dropped, with the latter being the recommendation for "session" level privacy. RFC 4244 = mandated that they be dropped and 4244bis recommends they be anonymized. The original intent for the value of "history" was for the tagging of the individual entries, but you end up getting the header level functionality as well. [/MB] =09 If you have a Privacy header with a value of "none" and a H-I entry = with Privacy header parameter with value "history" what is the privacy of = the individual H-I entry? [MB] We did not explicitly address the "none" in RFC 4244, but the general statement is the privacy headers at the request level override any at the hi-entry level. [/MB] =09 From reading RFC4244 a Privacy header with value "history" will effectively make all H-I entries private and there is currently no option to include a H-I Privacy header parameter with value "none". [MB] Correct, per my comment above. [/MB] =09 H-I at present allows the inclusion of Privacy header parameters to explicitly express privacy for an individual H-I entry but a single = node which includes a header "Privacy: history" makes all H-I entries = private even if this is not the requirements for the specific URI. [MB] Correct, but the only node that should add the header is a node which is responsible for the domain associated with the Request URI in the incoming request or is authorized to do so. [/MB] =09 I will admit that having worked in a telephony environment for a long time I am used to having privacy of identities set on a per number = basis and the relative inflexibility of the IETF Privacy header is = relatively restrictive as to specifying which identities may be presented and = which not. [MB] Yes, this is an entirely different paradigm. I developed = telephony s/w for over a decade and this is entirely different - it provides a = lot more flexibility, which makes things far, far less deterministic than what you have in telephony switches where your routing and = translations are configured for the most part, with just a few capabilities for controlling the privacy and it's a closed network. =09 With RFC4244/4244bis, there MUST be a mechanism at the UAS or end application that can handle a request that doesn't have the = appropriate information either because nodes didn't support History-Info or some random node in the network applied privacy (which I think is highly unlikely) - this is normative per section 5 of RFC 4244. So, the = worst case scenario I see for this 800 service (which will get to the right UAS but without the exact 800 number that was dialed) is that it goes = to a default ACD group/customer service agent, etc. who then needs to gather the appropriate information and in my experience this is often = an IVR system these days. So, the service is not broken when privacy is applied in an undesireable manner, it's just not optimal. This is something that should be addressed in the target-uri draft which has = all the details of how specific services use History-Info. One other thing to consider is that most networks that are emulating telephony type features use B2BUAs, which follow the UAS/UAC rules for the header rather than the proxy rules, noting that the UAC can set = the Privacy header to whatever value it sees as appropriate for the = request. [/MB] =09 =09 Regards =09 Ian =09 -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: 24 June 2009 15:48 To: Ian Elz Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Francois Audet Subject: RE: 4244bis and privacy =09 Hi Ian, =09 I do not believe we should do the "override" behavior as I think that violates RFC 3323, as the "history" is really a subset of the cases whereby a UAC or proxy would add "session" or "header" to the request. And, the latter two cases have the same (undesireable) result. I = agree this impacts your services, but we can't mandate that proxies provide information that might violate their local policies and indeed a = proxy's local policies can result in the information being anonymized (or removed if they can't anonymize) even in the "none" case. =09 I do believe it's reasonable that we strongly recommend that the = request level (versus specific hi-entries) not be used and if it is used, the consequence is that some services will not have the information they need - this was the gist of my previous response (to which I did not = get any additional feedback). Now, we could add some text that the "none" case SHOULD be used (e.g., added by first hop proxy) if it is desired that the information not be subject to privacy restrictions. I do not think it is then particularly useful to add logic around the proxy = then being able to tag the entries within their domain as subject to = privacy. I think that conflicts with the intent of the request level "none". However, as I mention above, per the current text, a proxy can (based = on local policy) remove entries - so a proxy can capture hi within their domain and not forward any of that information to the next hop in another domain - you already have that functionality. But, I think = this introduces the general problem that you might be impacting other services further down the line, which I thought was the problem you = were wanting to solve - not specifically your example service but, for example, in the case that someone is debugging and they want the = entire history, so depending upon the service, this is also undesirable behavior. =09 =09 Regards, Mary. =09 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Wednesday, June 24, 2009 2:57 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Audet, Francois (SC100:3055) Subject: RE: 4244bis and privacy =09 =09 Mary, =09 [I have added the list to this thread for wider comment.] =09 In the previous discussions I commented that in RFC4424 that a Privacy header with value "history" effectively makes all H-I entries private with the result that the H-I entries may be removed. =09 There has now been a comprehensive discussion on indication of the initial 'target' to the final recipient for call handling purposes. =09 The main use case related to a freephone example where the answering location may be a call centre where the original freephone number may = be required for correct call handling. =09 If you now consider the following example (modified from Francois' = text in the latest draft - excuse any errors that I may have inserted) =09 INVITE sip:sip:+18001234567@example.com = ;user=3Dphone;p=3Dx Privacy: history History-Info: = ;user=3Dphone;p=3Dx>;index=3D1;rt;aor (1) History-Info: >;index=3D1.1;mp;aor (2) History-Info: = >;index=3D1.1.1;rc (3) =09 In this case due to the Privacy header all of the H-I entries are considered private and the +18001234567 will not be delivered to the final destination with the result that call handling may not be = correct. The Privacy header may have been inserted by any of the nodes which routed the message and inserted a H-I entry. =09 If however the H-I was allowed to include a header parameter of "?Privacy=3Dnone" in the H-I entry and that an explicit H-I entry = privacy value would be considered to have precedence over a Privacy header = with a value of "history" then the mapping of the +18001234567 could be explicitly specified as not private and may be passed on. =09 Thus when the mapping from sip:+18001234567@example.com = to sip:bob@biloxi.example.com when = H-I entry (2) above is included could also insert the Privacy header parameter in H-I entry (1). =09 Thus the message would appear as follows: =09 INVITE sip:sip:+18001234567@example.com = ; user=3Dphone;p=3Dx Privacy: history History-Info: = ;index=3D= 1;rt;ao r History-Info: >;index=3D1.1;mp;aor History-Info: = >;index=3D1.1.1;rc =09 This would result in all the H-I entries except (1) being considered private with the result that the =3D1800... Number is passed for call handling purposes. =09 This change is backward compatible with the existing implementation as any node using the existing functionality as defined in RFC4244 will continue to be supported. =09 The alternative is to remove the ability to include the value = "history" in the Privacy header and only allow this value in the Privacy header parameter. This alternative is not backward compatible. =09 Without this change a single node in the message path which includes a header "Privacy: history" will prevent delivery of the aor and thus prevent proper call handling. =09 Ian Elz =09 =09 =09 -----Original Message----- From: Christer Holmberg Sent: 23 June 2009 19:40 To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida = Schubert Cc: Ian Elz Subject: RE: 4244bis and privacy =09 =09 Hi, =09 I include Ian, so he can comment to your resposne himself. =09 Regards, =09 Christer =09 =09 -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Tuesday, June 23, 2009 9:40 PM To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida Schubert Subject: RE: 4244bis and privacy =09 Here was the thread of response and the last comment was from Ian that he would consider the response: http://www.ietf.org/mail-archive/web/sip/current/msg26948.html =09 And, there was not agreement on the "none" but rather to qualify the SHOULD NOT forward. However, in the sipcore-4244bis-00, rather than changing the text such that the headers SHOULD be removed, we = recommend that they be anonymized (in section 4.3.3.3.1). That is entirely consistent with RFC 3324 and thus we have removed the recommendations = to remove the headers entirely. However, that changed never got done in section 3.2, so we would need to change this: "Thus, the History- Info header SHOULD NOT be included in Requests where the requestor has indicated a priv-value of Session- or Header-level privacy." =09 But, I'm really beginning to be of the mindset that we should just remove all the subsections of section 3 (i.e., leave the text in the upper level section), so we don't have to keep worrying about consistency. =09 So, lets either fixt the text in 3.2 or remove altogether and then I think we are really at the point of needing to submit this version so folks that actually have an interest in it can review the updated document. =09 Mary. =09 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, June 23, 2009 1:10 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik van Elburg; Shida Schubert Subject: 4244bis and privacy =09 =09 Hi, =09 Below is a comment/proposal which one of my collegues (Ian Elz) gave = on the list a while ago, when the first version of 4244bis was submitted, but was not incorporated. Do you think it would be useful? =09 ------- =09 While the HI approach to target may solve the problem of being able to deliver the target URI to the final destination there is no guarantee that it will actually be delivered. =09 The problem arises with how Privacy is defined for HI. =09 4424 defines a new Privacy value "history" which may be placed in = either the Privacy header or as a header parameter to the HI entry. =09 If one node uses the former option "Privacy: history" then this will make all headers private and will result in all HI entries being = removed or made anonymous when the message containing the HI is delivered to = the user. =09 There is a simple solution to this and that is to also allow the use = of the "none" Privacy value as a header parameter in the HI entry. This would explicitly state that no privacy is required to the HI entry and this would override a "history" value in the Privacy header. =09 I pointed this out to Mary when the 4424bis draft was first published but the change has not been made in the latest draft. =09 The change is backward compatible and would not cause an issue with = any existing implementations. =09 ------ =09 Regards, =09 Christer =09 =09 =09 =09 =09 ------_=_NextPart_001_01C9F5B1.D2380D3C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
You=20 mean "should not prohibit B to choose to deliver the identity of B to = C",=20 right?

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Thursday, June 25, = 2009=20 08:48
To: Ian Elz
Cc: Barnes, Mary (RICH2:AR00); = Christer=20 Holmberg; Shida Schubert; sipcore@ietf.org; Audet, Francois=20 (SC100:3055)
Subject: Re: 4244bis and = privacy

Ok Ian, now I see what you mean.

You are saying that if A calls B which forwards to C, that A = indicating=20 that privacy is required should not prohibit B to choose to deliver = its=20 identity to C, right?

I think I agree with you that this is a point that needs to be = addressed=20 by 4244bis.

Best Regards,
/Hans Erik van Elburg

On Thu, Jun 25, 2009 at 5:12 PM, Ian Elz = <ian.elz@ericsson.com> = wrote:
Mary,

I=20 am a little concerned about one answer that you gave:


If you have a Privacy header with a value of = "none"=20 and a H-I entry with
Privacy header parameter with value = "history" what=20 is the privacy of the
individual H-I entry?
[MB] We did not = explicitly=20 address the "none" in RFC 4244, but the
general statement is the = privacy=20 headers at the request level override
any at the hi-entry level.=20 [/MB]

This means that if privacy is required for an = individual=20 H-I entry but
the originating user included "Privacy:none" in the = request=20 then there
is no option to include the real URI in the H-I=20 entry.

This occurs as RFC3323 states in section 4.3: = "However, if the=20 Privacy
header value of 'none' is specified in a message, privacy = services MUST
NOT perform any privacy function and MUST NOT = remove or=20 modify the
Privacy header."

The only option for an = intermediate=20 node including a H-I entry where
"Privacy:none" is specified and = privacy=20 for the H-I URI is required is
to include an anonymous entry or = not=20 include the H-I entry.

In your previous response you stated = that we=20 would violate RFC3323 if we
specified additional behaviour for = privacy=20 explicitly stated with a URI
-n the H-I entry. I don't believe = that this=20 is the case as RFC3323 only
considered privacy in a two party = scenario=20 and did not consider third
party identities being included in a = message=20 between two parties. H-I is
not the only case where this occurs = as the=20 Referred-By header when
included in the INVITE (or other request) = which=20 results from the REFER
has the same issue.

RFC4244 was the = first=20 time that there was a recognition that privacy for
these = individual third=20 party identities may be required. To allow this
explicit = statement of=20 privacy to be overridden by a generic statement
which is = applicable to a=20 different user is counterintuitive.

The original Privacy = header is=20 usually included by or on behalf of the
originating user and = should not=20 be allowed to specify the privacy of the
original called user, = e.g. the=20 800 number, and prevent this identity
being presented if this = user does=20 not have the same level of privacy.

The real issue with the = 800=20 scenario is as you have stated is that the
answerer will not know = the=20 original called identity and will not be able
to correctly handle = the=20 call. As more generic call centres are used
which will answer = calls on=20 behalf of many different organizations using
CTI and the original = called=20 identity to have to implement a generic
system asking the caller = who he=20 originally called appear unprofessional,
is inefficient and=20 unproductive.

We have an opportunity to allow presentation of = specific identities and
to solve this particular problem so we = should=20 take it.

I hope that we can get some wider discussion on this = issue=20 so a more
general consensus can be obtained.

Regards

Ian



-----Original=20 Message-----
From: Mary Barnes [mailto:mary.barnes@nortel.com]
Sent: 24 June 2009 17:27
To: Ian Elz
Cc: = Christer=20 Holmberg; Hans Erik van Elburg; Shida Schubert;
sipcore@ietf.org; Francois=20 Audet
Subject: RE: 4244bis and privacy

Hi = Ian,

Responses=20 inline below [MB].

Mary.

-----Original = Message-----
From:=20 Ian Elz [mailto:ian.elz@ericsson.com]
Sent:=20 Wednesday, June 24, 2009 10:37 AM
To: Barnes, Mary = (RICH2:AR00)
Cc:=20 Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
sipcore@ietf.org; Audet, = Francois=20 (SC100:3055)
Subject: RE: 4244bis and = privacy

Mary,

I was=20 not proposing that we change the handling of H-I which is = based
upon=20 local policy. If that causes an issue for a network operator = then
they=20 can modify their local policy accordingly or arrange with the=20 proxy
vendor to modify their equipment to be more flexible with = regards=20 to
policy.

Can you clarify for me:

If you have a = Privacy=20 header with either "session" or "header" doe this
impact the H-I = entries=20 or will only a value of "history" impact the H-I
entries?
[MB] = Yes,=20 both "session" and "header" level privacy, consistent with = RFC
3323,=20 mandate that entries be anonymized or dropped, with the = latter
being the=20 recommendation for "session" level privacy. RFC 4244 = mandated
that they=20 be dropped and 4244bis recommends they be anonymized. = The
original intent=20 for the value of "history" was for the tagging of the
individual = entries,=20 but you end up getting the header level
functionality as well.=20 [/MB]

If you have a Privacy header with a value of "none" and = a H-I=20 entry with
Privacy header parameter with value "history" what is = the=20 privacy of the
individual H-I entry?
[MB] We did not = explicitly=20 address the "none" in RFC 4244, but the
general statement is the = privacy=20 headers at the request level override
any at the hi-entry level.=20 [/MB]

From reading RFC4244 a Privacy header with value = "history"=20 will
effectively make all H-I entries private and there is = currently=20 no
option to  include a H-I Privacy header parameter with = value=20 "none".
[MB] Correct, per my comment above. [/MB]

H-I at = present=20 allows the inclusion of Privacy header parameters to
explicitly = express=20 privacy for an individual H-I entry but a single node
which = includes a=20 header "Privacy: history" makes all H-I entries private
even if = this is=20 not the requirements for the specific URI.
[MB] Correct, but the = only=20 node that should add the header is a node
which is responsible = for the=20 domain associated with the Request URI in
the incoming request or = is=20 authorized to do so. [/MB]

I will admit that having worked in = a=20 telephony environment for a long
time I am used to having privacy = of=20 identities set on a per number basis
and the relative = inflexibility of=20 the IETF Privacy header is relatively
restrictive as to = specifying which=20 identities may be presented and which
not.
[MB] Yes, this is = an=20 entirely different paradigm.  I developed telephony
s/w for = over a=20 decade and this is entirely different - it provides a lot
more=20 flexibility, which makes things far, far less deterministic = than
what you=20 have in telephony switches where your routing and = translations
are=20 configured for the most part, with just a few capabilities=20 for
controlling the privacy and it's a closed = network.

With=20 RFC4244/4244bis, there MUST be a mechanism at the UAS or = end
application=20 that can handle a request that doesn't have the = appropriate
information=20 either because nodes didn't support History-Info or some
random = node in=20 the network applied privacy (which I think is highly
unlikely) - = this is=20 normative per section 5 of RFC 4244.  So, the worst
case = scenario I=20 see for this 800 service  (which will get to the right
UAS = but=20 without the exact 800 number that was dialed) is that it goes = to
a=20 default ACD group/customer service agent, etc. who then needs = to
gather=20 the appropriate information and in my experience this is often = an
IVR=20 system these days.  So, the service is not broken when privacy=20 is
applied in an undesireable manner, it's just not optimal. =  This=20 is
something that should be addressed in the target-uri draft = which has=20 all
the details of how specific services use History-Info.
One = other=20 thing to consider is that most networks that are = emulating
telephony type=20 features use B2BUAs, which follow the UAS/UAC rules for
the = header rather=20 than the proxy rules, noting that the UAC can set the
Privacy = header to=20 whatever value it sees as appropriate for the=20 request.
[/MB]


Regards

Ian

-----Original = Message-----
From: Mary Barnes [mailto:mary.barnes@nortel.com]
Sen= t: 24=20 June 2009 15:48
To: Ian Elz
Cc: Christer Holmberg; Hans Erik = van=20 Elburg; Shida Schubert;
sipcore@ietf.org; Francois=20 Audet
Subject: RE: 4244bis and privacy

Hi Ian,

I do = not=20 believe we should do the "override" behavior as I think = that
violates RFC=20 3323, as the "history" is really a subset of the cases
whereby a = UAC or=20 proxy would add "session" or "header" to the request.
And, the = latter two=20 cases have the same (undesireable) result.   I agree
this = impacts=20 your services, but we can't mandate that proxies = provide
information that=20 might violate their local policies and indeed a proxy's
local = policies=20 can result in the information being anonymized (or
removed if = they can't=20 anonymize) even in the "none" case.

I do believe it's = reasonable that=20 we strongly recommend that the request
level (versus specific = hi-entries)=20 not be used and if it is used, the
consequence is that some = services will=20 not have the information they
need - this was the gist of my = previous=20 response (to which I did not get
any additional feedback). Now, = we could=20 add some text that the "none"
case SHOULD be used (e.g., added by = first=20 hop proxy) if it is desired
that the information not be subject = to=20 privacy restrictions. I do not
think it is then particularly = useful to=20 add logic around the proxy then
being able to tag the entries = within=20 their domain as subject to privacy.
I think that conflicts with = the=20 intent of the request level "none".
However, as I mention above, = per the=20 current text, a proxy can (based on
local policy) remove entries = - so a=20 proxy can capture hi within their
domain and not forward any of = that=20 information to the next hop in
another domain - you already have = that=20 functionality.  But, I think this
introduces the general = problem=20 that you might be impacting other
services further down the line, = which I=20 thought was the problem you were
wanting to solve - not = specifically your=20 example service but, for
example, in the case that someone is = debugging=20 and they want the entire
history, so depending upon the service, = this is=20 also=20 = undesirable
behavior.


Regards,
Mary.

-----Origina= l=20 Message-----
From: Ian Elz [mailto:ian.elz@ericsson.com]
Sent:=20 Wednesday, June 24, 2009 2:57 AM
To: Barnes, Mary = (RICH2:AR00)
Cc:=20 Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
sipcore@ietf.org; Audet, = Francois=20 (SC100:3055)
Subject: RE: 4244bis and=20 privacy


 Mary,

[I have added the list to this = thread=20 for wider comment.]

In the previous discussions I commented = that in=20 RFC4424 that a Privacy
header with value "history" effectively = makes all=20 H-I entries private
with the result that the H-I entries may be=20 removed.

There has now been a comprehensive discussion on = indication=20 of the
initial 'target' to the final recipient for call handling=20 purposes.

The main use case related to a freephone example = where the=20 answering
location may be a call centre where the original = freephone=20 number may be
required for correct call handling.

If you = now=20 consider the following example (modified from Francois' text
in = the=20 latest draft - excuse any errors that I may have = inserted)

INVITE sip:sip:+180012345= 67@example.com;user=3Dphone;p=3Dx
Privacy:=20 history
History-Info:
<sip:+18001234567@example= .com;user=3Dphone;p=3Dx>;index=3D1;rt;aor=20         (1)
History-Info: <sip:bob@biloxi.example.com>;index=3D1.1;mp;aor
(2)
History-Info:=20 <sip:bob@192.0.2.3>;index=3D1.1= .1;rc
(3)

In=20 this case due to the Privacy header all of the H-I entries = are
considered=20 private and the +18001234567 will not be delivered to the
final=20 destination with the result that call handling may not be = correct.
The=20 Privacy header may have been inserted by any of the nodes = which
routed=20 the message and inserted a H-I entry.

If however the H-I was = allowed=20 to include a header parameter of
"?Privacy=3Dnone" in the H-I = entry and=20 that an explicit H-I entry privacy
value would be considered to = have=20 precedence over a Privacy header with
a value of "history" then = the=20 mapping of the +18001234567 could be
explicitly specified as not = private=20 and may be passed on.

Thus when the mapping from sip:+18001234567@example= .com=20 to
sip:bob@biloxi.example.com=20 when H-I entry (2) above is included could
also insert the = Privacy header=20 parameter in H-I entry (1).

Thus the message would appear as=20 follows:

INVITE sip:sip:+180012345= 67@example.com;=20 user=3Dphone;p=3Dx
Privacy: history
History-Info:
<sip:+18001234567@example.com?Privacy=3Dnone;user=3Dphone;= p=3Dx>;index=3D1;rt;ao
r
History-Info:=20 <sip:bob@biloxi.example.com>;index=3D1.1;mp;aor
History-Info:=20 <sip:bob@192.0.2.3>;index=3D1.1= .1;rc

This=20 would result in all the H-I entries except (1) being = considered
private=20 with the result that the =3D1800... Number is passed for = call
handling=20 purposes.

This change is backward compatible with the = existing=20 implementation as
any node using the existing functionality as = defined in=20 RFC4244 will
continue to be supported.

The alternative is = to=20 remove the ability to include the value "history"
in the Privacy = header=20 and only allow this value in the Privacy header
parameter. This=20 alternative is not backward compatible.

Without this change a = single=20 node in the message path which includes a
header "Privacy: = history" will=20 prevent delivery of the aor and thus
prevent proper call=20 handling.

Ian Elz



-----Original = Message-----
From:=20 Christer Holmberg
Sent: 23 June 2009 19:40
To: 'Mary Barnes'; = Francois=20 Audet; Hans Erik van Elburg; Shida Schubert
Cc: Ian = Elz
Subject: RE:=20 4244bis and privacy


Hi,

I include Ian, so he can = comment=20 to your resposne=20 himself.

Regards,

Christer


-----Original=20 Message-----
From: Mary Barnes [mailto:mary.barnes@nortel.com]
Sen= t:=20 Tuesday, June 23, 2009 9:40 PM
To: Christer Holmberg; Francois = Audet;=20 Hans Erik van Elburg; Shida
Schubert
Subject: RE: 4244bis and=20 privacy

Here was the thread of response and the last comment = was from=20 Ian that
he would consider the response:
http://www.ietf.org/mail-archive/web/sip/current/msg26948= .html

And,=20 there was not agreement on the "none" but rather to qualify = the
SHOULD=20 NOT forward.  However, in the sipcore-4244bis-00, rather=20 than
changing the text such that the headers SHOULD be removed, = we=20 recommend
that they be anonymized (in section 4.3.3.3.1). =  That is=20 entirely
consistent with RFC 3324 and thus we have removed the=20 recommendations to
remove the headers entirely. However, that = changed=20 never got done in
section 3.2, so we would need to change = this:
 =20 "Thus, the History- Info header
  SHOULD NOT be included in = Requests=20 where the requestor has indicated
  a priv-value of Session- = or=20 Header-level privacy."

But, I'm really beginning to be of the = mindset=20 that we should just
remove all the subsections of section 3 = (i.e., leave=20 the text in the
upper level section), so we don't have to keep = worrying=20 about
consistency.

So, lets either fixt the text in 3.2 or = remove=20 altogether and then I
think we are really at the point of needing = to=20 submit this version so
folks that actually have an interest in it = can=20 review the updated
document.

Mary.

-----Original=20 Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson= .com]
Sent:=20 Tuesday, June 23, 2009 1:10 PM
To: Barnes, Mary (RICH2:AR00); = Audet,=20 Francois (SC100:3055); Hans Erik
van Elburg; Shida = Schubert
Subject:=20 4244bis and privacy


Hi,

Below is a = comment/proposal which=20 one of my collegues (Ian Elz) gave on
the list a while ago, when = the=20 first version of 4244bis was submitted,
but was not incorporated. = Do you=20 think it would be useful?

-------

While the HI = approach to=20 target may solve the problem of being able to
deliver the target = URI to=20 the final destination there is no guarantee
that it will actually = be=20 delivered.

The problem arises with how Privacy is defined for = HI.

4424 defines a new Privacy value "history" which may be = placed in=20 either
the Privacy header or as a header parameter to the HI=20 entry.

If one node uses the former option "Privacy: history" = then=20 this will
make all headers private and will result in all HI = entries=20 being removed
or made anonymous when the message containing the = HI is=20 delivered to the
user.

There is a simple solution to this = and that=20 is to also allow the use of
the "none" Privacy value as a header=20 parameter in the HI entry. This
would explicitly state that no = privacy is=20 required to the HI entry and
this would override a "history" = value in the=20 Privacy header.

I pointed this out to Mary when the 4424bis = draft was=20 first published
but the change has not been made in the latest=20 draft.

The change is backward compatible and would not cause = an issue=20 with any
existing=20 = implementations.

------

Regards,

Christer




------_=_NextPart_001_01C9F5B1.D2380D3C-- From ietf.hanserik@gmail.com Thu Jun 25 09:31:46 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B1E63A68AE for ; Thu, 25 Jun 2009 09:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBjSh1RminXR for ; Thu, 25 Jun 2009 09:31:43 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 2FCEA3A6AB7 for ; Thu, 25 Jun 2009 09:31:42 -0700 (PDT) Received: by ewy6 with SMTP id 6so2441046ewy.37 for ; Thu, 25 Jun 2009 09:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Ueup5rMW2rx6WmSagRduFzoyf0KOGTQ0Dx5Ahlg67U8=; b=elXT99uXb1i+52uZ3lKkDB531RRWWwUZW5DBr6QzhFx/tzdaBEyctf2bsoqn0SBaPE wtBpv9avtDr3mOIJpwM5WpUCSxaQcG3l4IR+DZdgg7SIaH2KBhxjz4T2yJvFX0yJcUHh 4/e+uKCj01PcApCGPXW9BjzBlRGWWVIbeuw4k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=I+orYTYwo5WuVYeD1LyzZ/k6aokma57G2TYdGTLkRrPbHjgDGuMolkS/BdNf8a076J 7+mmkY69okVaeOlOGEN/sM15TlYMnuhHcqxOHeyaV0KuxTao+e4ErOTWliYKVCdGcjXF psJzKIEzxLKHbmAxcWkfPsOW4hF/ozoRXgMCc= MIME-Version: 1.0 Received: by 10.216.0.206 with SMTP id 56mr851740web.102.1245947451358; Thu, 25 Jun 2009 09:30:51 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EB26254@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> <9ae56b1e0906250848l106e8a16j39fbca1ff3541c36@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1EB26254@zrc2hxm0.corp.nortel.com> Date: Thu, 25 Jun 2009 18:30:51 +0200 Message-ID: <9ae56b1e0906250930x4fc8138bi181b61acb266b4b0@mail.gmail.com> From: Hans Erik van Elburg To: Francois Audet Content-Type: multipart/alternative; boundary=0016364ed9ae3f3d4e046d2ebfa3 Cc: Ian Elz , sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 16:31:46 -0000 --0016364ed9ae3f3d4e046d2ebfa3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yes. /Hans Erik van Elburg On Thu, Jun 25, 2009 at 6:27 PM, Francois Audet wrote: > You mean "should not prohibit B to choose to deliver the identity of B to > C", right? > > ------------------------------ > *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > *Sent:* Thursday, June 25, 2009 08:48 > *To:* Ian Elz > *Cc:* Barnes, Mary (RICH2:AR00); Christer Holmberg; Shida Schubert; > sipcore@ietf.org; Audet, Francois (SC100:3055) > *Subject:* Re: 4244bis and privacy > > Ok Ian, now I see what you mean. > You are saying that if A calls B which forwards to C, that A indicating > that privacy is required should not prohibit B to choose to deliver its > identity to C, right? > > I think I agree with you that this is a point that needs to be addressed by > 4244bis. > > Best Regards, > /Hans Erik van Elburg > > On Thu, Jun 25, 2009 at 5:12 PM, Ian Elz wrote: > >> Mary, >> >> I am a little concerned about one answer that you gave: >> >> >> If you have a Privacy header with a value of "none" and a H-I entry with >> Privacy header parameter with value "history" what is the privacy of the >> individual H-I entry? >> [MB] We did not explicitly address the "none" in RFC 4244, but the >> general statement is the privacy headers at the request level override >> any at the hi-entry level. [/MB] >> >> This means that if privacy is required for an individual H-I entry but >> the originating user included "Privacy:none" in the request then there >> is no option to include the real URI in the H-I entry. >> >> This occurs as RFC3323 states in section 4.3: "However, if the Privacy >> header value of 'none' is specified in a message, privacy services MUST >> NOT perform any privacy function and MUST NOT remove or modify the >> Privacy header." >> >> The only option for an intermediate node including a H-I entry where >> "Privacy:none" is specified and privacy for the H-I URI is required is >> to include an anonymous entry or not include the H-I entry. >> >> In your previous response you stated that we would violate RFC3323 if we >> specified additional behaviour for privacy explicitly stated with a URI >> -n the H-I entry. I don't believe that this is the case as RFC3323 only >> considered privacy in a two party scenario and did not consider third >> party identities being included in a message between two parties. H-I is >> not the only case where this occurs as the Referred-By header when >> included in the INVITE (or other request) which results from the REFER >> has the same issue. >> >> RFC4244 was the first time that there was a recognition that privacy for >> these individual third party identities may be required. To allow this >> explicit statement of privacy to be overridden by a generic statement >> which is applicable to a different user is counterintuitive. >> >> The original Privacy header is usually included by or on behalf of the >> originating user and should not be allowed to specify the privacy of the >> original called user, e.g. the 800 number, and prevent this identity >> being presented if this user does not have the same level of privacy. >> >> The real issue with the 800 scenario is as you have stated is that the >> answerer will not know the original called identity and will not be able >> to correctly handle the call. As more generic call centres are used >> which will answer calls on behalf of many different organizations using >> CTI and the original called identity to have to implement a generic >> system asking the caller who he originally called appear unprofessional, >> is inefficient and unproductive. >> >> We have an opportunity to allow presentation of specific identities and >> to solve this particular problem so we should take it. >> >> I hope that we can get some wider discussion on this issue so a more >> general consensus can be obtained. >> >> Regards >> >> Ian >> >> >> >> -----Original Message----- >> From: Mary Barnes [mailto:mary.barnes@nortel.com] >> Sent: 24 June 2009 17:27 >> To: Ian Elz >> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; >> sipcore@ietf.org; Francois Audet >> Subject: RE: 4244bis and privacy >> >> Hi Ian, >> >> Responses inline below [MB]. >> >> Mary. >> >> -----Original Message----- >> From: Ian Elz [mailto:ian.elz@ericsson.com] >> Sent: Wednesday, June 24, 2009 10:37 AM >> To: Barnes, Mary (RICH2:AR00) >> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; >> sipcore@ietf.org; Audet, Francois (SC100:3055) >> Subject: RE: 4244bis and privacy >> >> Mary, >> >> I was not proposing that we change the handling of H-I which is based >> upon local policy. If that causes an issue for a network operator then >> they can modify their local policy accordingly or arrange with the proxy >> vendor to modify their equipment to be more flexible with regards to >> policy. >> >> Can you clarify for me: >> >> If you have a Privacy header with either "session" or "header" doe this >> impact the H-I entries or will only a value of "history" impact the H-I >> entries? >> [MB] Yes, both "session" and "header" level privacy, consistent with RFC >> 3323, mandate that entries be anonymized or dropped, with the latter >> being the recommendation for "session" level privacy. RFC 4244 mandated >> that they be dropped and 4244bis recommends they be anonymized. The >> original intent for the value of "history" was for the tagging of the >> individual entries, but you end up getting the header level >> functionality as well. [/MB] >> >> If you have a Privacy header with a value of "none" and a H-I entry with >> Privacy header parameter with value "history" what is the privacy of the >> individual H-I entry? >> [MB] We did not explicitly address the "none" in RFC 4244, but the >> general statement is the privacy headers at the request level override >> any at the hi-entry level. [/MB] >> >> From reading RFC4244 a Privacy header with value "history" will >> effectively make all H-I entries private and there is currently no >> option to include a H-I Privacy header parameter with value "none". >> [MB] Correct, per my comment above. [/MB] >> >> H-I at present allows the inclusion of Privacy header parameters to >> explicitly express privacy for an individual H-I entry but a single node >> which includes a header "Privacy: history" makes all H-I entries private >> even if this is not the requirements for the specific URI. >> [MB] Correct, but the only node that should add the header is a node >> which is responsible for the domain associated with the Request URI in >> the incoming request or is authorized to do so. [/MB] >> >> I will admit that having worked in a telephony environment for a long >> time I am used to having privacy of identities set on a per number basis >> and the relative inflexibility of the IETF Privacy header is relatively >> restrictive as to specifying which identities may be presented and which >> not. >> [MB] Yes, this is an entirely different paradigm. I developed telephony >> s/w for over a decade and this is entirely different - it provides a lot >> more flexibility, which makes things far, far less deterministic than >> what you have in telephony switches where your routing and translations >> are configured for the most part, with just a few capabilities for >> controlling the privacy and it's a closed network. >> >> With RFC4244/4244bis, there MUST be a mechanism at the UAS or end >> application that can handle a request that doesn't have the appropriate >> information either because nodes didn't support History-Info or some >> random node in the network applied privacy (which I think is highly >> unlikely) - this is normative per section 5 of RFC 4244. So, the worst >> case scenario I see for this 800 service (which will get to the right >> UAS but without the exact 800 number that was dialed) is that it goes to >> a default ACD group/customer service agent, etc. who then needs to >> gather the appropriate information and in my experience this is often an >> IVR system these days. So, the service is not broken when privacy is >> applied in an undesireable manner, it's just not optimal. This is >> something that should be addressed in the target-uri draft which has all >> the details of how specific services use History-Info. >> One other thing to consider is that most networks that are emulating >> telephony type features use B2BUAs, which follow the UAS/UAC rules for >> the header rather than the proxy rules, noting that the UAC can set the >> Privacy header to whatever value it sees as appropriate for the request. >> [/MB] >> >> >> Regards >> >> Ian >> >> -----Original Message----- >> From: Mary Barnes [mailto:mary.barnes@nortel.com] >> Sent: 24 June 2009 15:48 >> To: Ian Elz >> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; >> sipcore@ietf.org; Francois Audet >> Subject: RE: 4244bis and privacy >> >> Hi Ian, >> >> I do not believe we should do the "override" behavior as I think that >> violates RFC 3323, as the "history" is really a subset of the cases >> whereby a UAC or proxy would add "session" or "header" to the request. >> And, the latter two cases have the same (undesireable) result. I agree >> this impacts your services, but we can't mandate that proxies provide >> information that might violate their local policies and indeed a proxy's >> local policies can result in the information being anonymized (or >> removed if they can't anonymize) even in the "none" case. >> >> I do believe it's reasonable that we strongly recommend that the request >> level (versus specific hi-entries) not be used and if it is used, the >> consequence is that some services will not have the information they >> need - this was the gist of my previous response (to which I did not get >> any additional feedback). Now, we could add some text that the "none" >> case SHOULD be used (e.g., added by first hop proxy) if it is desired >> that the information not be subject to privacy restrictions. I do not >> think it is then particularly useful to add logic around the proxy then >> being able to tag the entries within their domain as subject to privacy. >> I think that conflicts with the intent of the request level "none". >> However, as I mention above, per the current text, a proxy can (based on >> local policy) remove entries - so a proxy can capture hi within their >> domain and not forward any of that information to the next hop in >> another domain - you already have that functionality. But, I think this >> introduces the general problem that you might be impacting other >> services further down the line, which I thought was the problem you were >> wanting to solve - not specifically your example service but, for >> example, in the case that someone is debugging and they want the entire >> history, so depending upon the service, this is also undesirable >> behavior. >> >> >> Regards, >> Mary. >> >> -----Original Message----- >> From: Ian Elz [mailto:ian.elz@ericsson.com] >> Sent: Wednesday, June 24, 2009 2:57 AM >> To: Barnes, Mary (RICH2:AR00) >> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; >> sipcore@ietf.org; Audet, Francois (SC100:3055) >> Subject: RE: 4244bis and privacy >> >> >> Mary, >> >> [I have added the list to this thread for wider comment.] >> >> In the previous discussions I commented that in RFC4424 that a Privacy >> header with value "history" effectively makes all H-I entries private >> with the result that the H-I entries may be removed. >> >> There has now been a comprehensive discussion on indication of the >> initial 'target' to the final recipient for call handling purposes. >> >> The main use case related to a freephone example where the answering >> location may be a call centre where the original freephone number may be >> required for correct call handling. >> >> If you now consider the following example (modified from Francois' text >> in the latest draft - excuse any errors that I may have inserted) >> >> INVITE sip:sip:+18001234567@example.com >> ;user=phone;p=x >> Privacy: history >> History-Info: >> ;user=phone;p=x>;index=1;rt;aor >> (1) >> History-Info: >> >;index=1.1;mp;aor >> (2) >> History-Info: >;index=1.1.1;rc >> (3) >> >> In this case due to the Privacy header all of the H-I entries are >> considered private and the +18001234567 will not be delivered to the >> final destination with the result that call handling may not be correct. >> The Privacy header may have been inserted by any of the nodes which >> routed the message and inserted a H-I entry. >> >> If however the H-I was allowed to include a header parameter of >> "?Privacy=none" in the H-I entry and that an explicit H-I entry privacy >> value would be considered to have precedence over a Privacy header with >> a value of "history" then the mapping of the +18001234567 could be >> explicitly specified as not private and may be passed on. >> >> Thus when the mapping from sip:+18001234567@example.comto >> sip:bob@biloxi.example.com when H-I entry >> (2) above is included could >> also insert the Privacy header parameter in H-I entry (1). >> >> Thus the message would appear as follows: >> >> INVITE sip:sip:+18001234567@example.com; >> user=phone;p=x >> Privacy: history >> History-Info: >> ;index=1;rt;ao >> r >> History-Info: >> >;index=1.1;mp;aor >> History-Info: >;index=1.1.1;rc >> >> This would result in all the H-I entries except (1) being considered >> private with the result that the =1800... Number is passed for call >> handling purposes. >> >> This change is backward compatible with the existing implementation as >> any node using the existing functionality as defined in RFC4244 will >> continue to be supported. >> >> The alternative is to remove the ability to include the value "history" >> in the Privacy header and only allow this value in the Privacy header >> parameter. This alternative is not backward compatible. >> >> Without this change a single node in the message path which includes a >> header "Privacy: history" will prevent delivery of the aor and thus >> prevent proper call handling. >> >> Ian Elz >> >> >> >> -----Original Message----- >> From: Christer Holmberg >> Sent: 23 June 2009 19:40 >> To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida Schubert >> Cc: Ian Elz >> Subject: RE: 4244bis and privacy >> >> >> Hi, >> >> I include Ian, so he can comment to your resposne himself. >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: Mary Barnes [mailto:mary.barnes@nortel.com] >> Sent: Tuesday, June 23, 2009 9:40 PM >> To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida >> Schubert >> Subject: RE: 4244bis and privacy >> >> Here was the thread of response and the last comment was from Ian that >> he would consider the response: >> http://www.ietf.org/mail-archive/web/sip/current/msg26948.html >> >> And, there was not agreement on the "none" but rather to qualify the >> SHOULD NOT forward. However, in the sipcore-4244bis-00, rather than >> changing the text such that the headers SHOULD be removed, we recommend >> that they be anonymized (in section 4.3.3.3.1). That is entirely >> consistent with RFC 3324 and thus we have removed the recommendations to >> remove the headers entirely. However, that changed never got done in >> section 3.2, so we would need to change this: >> "Thus, the History- Info header >> SHOULD NOT be included in Requests where the requestor has indicated >> a priv-value of Session- or Header-level privacy." >> >> But, I'm really beginning to be of the mindset that we should just >> remove all the subsections of section 3 (i.e., leave the text in the >> upper level section), so we don't have to keep worrying about >> consistency. >> >> So, lets either fixt the text in 3.2 or remove altogether and then I >> think we are really at the point of needing to submit this version so >> folks that actually have an interest in it can review the updated >> document. >> >> Mary. >> >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Tuesday, June 23, 2009 1:10 PM >> To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik >> van Elburg; Shida Schubert >> Subject: 4244bis and privacy >> >> >> Hi, >> >> Below is a comment/proposal which one of my collegues (Ian Elz) gave on >> the list a while ago, when the first version of 4244bis was submitted, >> but was not incorporated. Do you think it would be useful? >> >> ------- >> >> While the HI approach to target may solve the problem of being able to >> deliver the target URI to the final destination there is no guarantee >> that it will actually be delivered. >> >> The problem arises with how Privacy is defined for HI. >> >> 4424 defines a new Privacy value "history" which may be placed in either >> the Privacy header or as a header parameter to the HI entry. >> >> If one node uses the former option "Privacy: history" then this will >> make all headers private and will result in all HI entries being removed >> or made anonymous when the message containing the HI is delivered to the >> user. >> >> There is a simple solution to this and that is to also allow the use of >> the "none" Privacy value as a header parameter in the HI entry. This >> would explicitly state that no privacy is required to the HI entry and >> this would override a "history" value in the Privacy header. >> >> I pointed this out to Mary when the 4424bis draft was first published >> but the change has not been made in the latest draft. >> >> The change is backward compatible and would not cause an issue with any >> existing implementations. >> >> ------ >> >> Regards, >> >> Christer >> >> >> >> >> > --0016364ed9ae3f3d4e046d2ebfa3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes.

/Hans Erik van Elburg

On Thu, Jun 25, 2009 at 6:27 PM, Francois Au= det <audet@nortel.= com> wrote:
You=20 mean "should not prohibit B to choose to deliver the identity of B to = C",=20 right?

From: Hans Erik= van Elburg=20 [mailto:ietf= .hanserik@gmail.com]
Sent: Thursday, June 25, 2009=20 08:48
To: Ian Elz
Cc: Barnes, Mary (RICH2:AR00); Chri= ster=20 Holmberg; Shida Schubert; sipcore@ietf.org; Audet, Francois=20 (SC100:3055)
Subject: Re: 4244bis and privacy

Ok Ian, now I see what you mean.

You are saying that if A calls B which forwards to C, that A indicat= ing=20 that privacy is required should not prohibit B to choose to deliver its= =20 identity to C, right?

I think I agree with you that this is a point that needs to be addre= ssed=20 by 4244bis.

Best Regards,
/Hans Erik van Elburg

On Thu, Jun 25, 2009 at 5:12 PM, Ian Elz <= ian.elz@ericsson.com>=20 wrote:
Mary,

I=20 am a little concerned about one answer that you gave:


If you have a Privacy header with a value of "none&qu= ot;=20 and a H-I entry with
Privacy header parameter with value "histo= ry" what=20 is the privacy of the
individual H-I entry?
[MB] We did not expli= citly=20 address the "none" in RFC 4244, but the
general statement = is the privacy=20 headers at the request level override
any at the hi-entry level.=20 [/MB]

This means that if privacy is required for an indivi= dual=20 H-I entry but
the originating user included "Privacy:none"= in the request=20 then there
is no option to include the real URI in the H-I=20 entry.

This occurs as RFC3323 states in section 4.3: "Howev= er, if the=20 Privacy
header value of 'none' is specified in a message, pr= ivacy=20 services MUST
NOT perform any privacy function and MUST NOT remove o= r=20 modify the
Privacy header."

The only option for an inter= mediate=20 node including a H-I entry where
"Privacy:none" is specifi= ed and privacy=20 for the H-I URI is required is
to include an anonymous entry or not= =20 include the H-I entry.

In your previous response you stated that= we=20 would violate RFC3323 if we
specified additional behaviour for priva= cy=20 explicitly stated with a URI
-n the H-I entry. I don't believe t= hat this=20 is the case as RFC3323 only
considered privacy in a two party scenar= io=20 and did not consider third
party identities being included in a mess= age=20 between two parties. H-I is
not the only case where this occurs as t= he=20 Referred-By header when
included in the INVITE (or other request) wh= ich=20 results from the REFER
has the same issue.

RFC4244 was the fi= rst=20 time that there was a recognition that privacy for
these individual = third=20 party identities may be required. To allow this
explicit statement o= f=20 privacy to be overridden by a generic statement
which is applicable = to a=20 different user is counterintuitive.

The original Privacy header = is=20 usually included by or on behalf of the
originating user and should = not=20 be allowed to specify the privacy of the
original called user, e.g. = the=20 800 number, and prevent this identity
being presented if this user d= oes=20 not have the same level of privacy.

The real issue with the 800= =20 scenario is as you have stated is that the
answerer will not know th= e=20 original called identity and will not be able
to correctly handle th= e=20 call. As more generic call centres are used
which will answer calls = on=20 behalf of many different organizations using
CTI and the original ca= lled=20 identity to have to implement a generic
system asking the caller who= he=20 originally called appear unprofessional,
is inefficient and=20 unproductive.

We have an opportunity to allow presentation of=20 specific identities and
to solve this particular problem so we shoul= d=20 take it.

I hope that we can get some wider discussion on this is= sue=20 so a more
general consensus can be obtained.

Regards

Ian



-----Original=20 Message-----
From: Mary Barnes [mailto:mary.barnes@nortel.com]
Sent: 24 June 2009 17:27
To: Ian Elz
Cc: Christer=20 Holmberg; Hans Erik van Elburg; Shida Schubert;
sipcore@ietf.org; Francois=20 Audet
Subject: RE: 4244bis and privacy

Hi Ian,

Respons= es=20 inline below [MB].

Mary.

-----Original Message-----
Fr= om:=20 Ian Elz [mailto:ian.elz@ericsson.com]
Sent:=20 Wednesday, June 24, 2009 10:37 AM
To: Barnes, Mary (RICH2:AR00)
C= c:=20 Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
sipcore@ietf.org; Audet, Fra= ncois=20 (SC100:3055)
Subject: RE: 4244bis and privacy

Mary,

I = was=20 not proposing that we change the handling of H-I which is based
upon= =20 local policy. If that causes an issue for a network operator then
th= ey=20 can modify their local policy accordingly or arrange with the=20 proxy
vendor to modify their equipment to be more flexible with rega= rds=20 to
policy.

Can you clarify for me:

If you have a Priva= cy=20 header with either "session" or "header" doe thisimpact the H-I entries=20 or will only a value of "history" impact the H-I
entries?<= br>[MB] Yes,=20 both "session" and "header" level privacy, consiste= nt with RFC
3323,=20 mandate that entries be anonymized or dropped, with the latter
being= the=20 recommendation for "session" level privacy. RFC 4244 mandated=
that they=20 be dropped and 4244bis recommends they be anonymized. The
original i= ntent=20 for the value of "history" was for the tagging of the
indi= vidual entries,=20 but you end up getting the header level
functionality as well.=20 [/MB]

If you have a Privacy header with a value of "none&qu= ot; and a H-I=20 entry with
Privacy header parameter with value "history" w= hat is the=20 privacy of the
individual H-I entry?
[MB] We did not explicitly= =20 address the "none" in RFC 4244, but the
general statement = is the privacy=20 headers at the request level override
any at the hi-entry level.=20 [/MB]

From reading RFC4244 a Privacy header with value "his= tory"=20 will
effectively make all H-I entries private and there is currently= =20 no
option to =A0include a H-I Privacy header parameter with value=20 "none".
[MB] Correct, per my comment above. [/MB]

H= -I at present=20 allows the inclusion of Privacy header parameters to
explicitly expr= ess=20 privacy for an individual H-I entry but a single node
which includes= a=20 header "Privacy: history" makes all H-I entries private
ev= en if this is=20 not the requirements for the specific URI.
[MB] Correct, but the onl= y=20 node that should add the header is a node
which is responsible for t= he=20 domain associated with the Request URI in
the incoming request or is= =20 authorized to do so. [/MB]

I will admit that having worked in a= =20 telephony environment for a long
time I am used to having privacy of= =20 identities set on a per number basis
and the relative inflexibility = of=20 the IETF Privacy header is relatively
restrictive as to specifying w= hich=20 identities may be presented and which
not.
[MB] Yes, this is an= =20 entirely different paradigm. =A0I developed telephony
s/w for over a= =20 decade and this is entirely different - it provides a lot
more=20 flexibility, which makes things far, far less deterministic than
wha= t you=20 have in telephony switches where your routing and translations
are= =20 configured for the most part, with just a few capabilities=20 for
controlling the privacy and it's a closed network.

Wi= th=20 RFC4244/4244bis, there MUST be a mechanism at the UAS or end
applica= tion=20 that can handle a request that doesn't have the appropriate
info= rmation=20 either because nodes didn't support History-Info or some
random = node in=20 the network applied privacy (which I think is highly
unlikely) - thi= s is=20 normative per section 5 of RFC 4244. =A0So, the worst
case scenario = I=20 see for this 800 service =A0(which will get to the right
UAS but=20 without the exact 800 number that was dialed) is that it goes to
a= =20 default ACD group/customer service agent, etc. who then needs to
gat= her=20 the appropriate information and in my experience this is often an
IV= R=20 system these days. =A0So, the service is not broken when privacy=20 is
applied in an undesireable manner, it's just not optimal. =A0= This=20 is
something that should be addressed in the target-uri draft which = has=20 all
the details of how specific services use History-Info.
One ot= her=20 thing to consider is that most networks that are emulating
telephony= type=20 features use B2BUAs, which follow the UAS/UAC rules for
the header r= ather=20 than the proxy rules, noting that the UAC can set the
Privacy header= to=20 whatever value it sees as appropriate for the=20 request.
[/MB]


Regards

Ian

-----Original=20 Message-----
From: Mary Barnes [mailto:mary.barnes@nortel.com]
Sent: 24=20 June 2009 15:48
To: Ian Elz
Cc: Christer Holmberg; Hans Erik van= =20 Elburg; Shida Schubert;
sipcore@ietf.org; Francois=20 Audet
Subject: RE: 4244bis and privacy

Hi Ian,

I do no= t=20 believe we should do the "override" behavior as I think that<= br>violates RFC=20 3323, as the "history" is really a subset of the cases
whe= reby a UAC or=20 proxy would add "session" or "header" to the reques= t.
And, the latter two=20 cases have the same (undesireable) result. =A0 I agree
this impacts= =20 your services, but we can't mandate that proxies provide
informa= tion that=20 might violate their local policies and indeed a proxy's
local po= licies=20 can result in the information being anonymized (or
removed if they c= an't=20 anonymize) even in the "none" case.

I do believe it= 9;s reasonable that=20 we strongly recommend that the request
level (versus specific hi-ent= ries)=20 not be used and if it is used, the
consequence is that some services= will=20 not have the information they
need - this was the gist of my previou= s=20 response (to which I did not get
any additional feedback). Now, we c= ould=20 add some text that the "none"
case SHOULD be used (e.g., a= dded by first=20 hop proxy) if it is desired
that the information not be subject to= =20 privacy restrictions. I do not
think it is then particularly useful = to=20 add logic around the proxy then
being able to tag the entries within= =20 their domain as subject to privacy.
I think that conflicts with the= =20 intent of the request level "none".
However, as I mention = above, per the=20 current text, a proxy can (based on
local policy) remove entries - s= o a=20 proxy can capture hi within their
domain and not forward any of that= =20 information to the next hop in
another domain - you already have tha= t=20 functionality. =A0But, I think this
introduces the general problem= =20 that you might be impacting other
services further down the line, wh= ich I=20 thought was the problem you were
wanting to solve - not specifically= your=20 example service but, for
example, in the case that someone is debugg= ing=20 and they want the entire
history, so depending upon the service, thi= s is=20 also=20 undesirable
behavior.


Regards,
Mary.

-----Origi= nal=20 Message-----
From: Ian Elz [mailto:ian.elz@ericsson.com]
Sent:=20 Wednesday, June 24, 2009 2:57 AM
To: Barnes, Mary (RICH2:AR00)
Cc= :=20 Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
sipcore@ietf.org; Audet, Fra= ncois=20 (SC100:3055)
Subject: RE: 4244bis and=20 privacy


=A0Mary,

[I have added the list to this threa= d=20 for wider comment.]

In the previous discussions I commented that= in=20 RFC4424 that a Privacy
header with value "history" effecti= vely makes all=20 H-I entries private
with the result that the H-I entries may be=20 removed.

There has now been a comprehensive discussion on indica= tion=20 of the
initial 'target' to the final recipient for call hand= ling=20 purposes.

The main use case related to a freephone example where= the=20 answering
location may be a call centre where the original freephone= =20 number may be
required for correct call handling.

If you now= =20 consider the following example (modified from Francois' text
in = the=20 latest draft - excuse any errors that I may have inserted)

INVIT= E sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx
Privacy:=20 history
History-Info:
<sip:+18001234567@example.com;user=3Dphon= e;p=3Dx>;index=3D1;rt;aor=20 =A0 =A0 =A0 =A0 (1)
History-Info: <sip:bob@biloxi.example.com>;inde= x=3D1.1;mp;aor
(2)
History-Info:=20 <sip:bob@19= 2.0.2.3>;index=3D1.1.1;rc
(3)

In=20 this case due to the Privacy header all of the H-I entries are
consi= dered=20 private and the +18001234567 will not be delivered to the
final=20 destination with the result that call handling may not be correct.
T= he=20 Privacy header may have been inserted by any of the nodes which
rout= ed=20 the message and inserted a H-I entry.

If however the H-I was all= owed=20 to include a header parameter of
"?Privacy=3Dnone" in the = H-I entry and=20 that an explicit H-I entry privacy
value would be considered to have= =20 precedence over a Privacy header with
a value of "history"= then the=20 mapping of the +18001234567 could be
explicitly specified as not pri= vate=20 and may be passed on.

Thus when the mapping from sip:+18001234567@exa= mple.com=20 to
sip:bob@biloxi.example.com=20 when H-I entry (2) above is included could
also insert the Privacy h= eader=20 parameter in H-I entry (1).

Thus the message would appear as=20 follows:

INVITE sip:sip:+18001234567@example.com;=20 user=3Dphone;p=3Dx
Privacy: history
History-Info:
<sip:+18001234567@example.com?Privacy=3Dnone;user=3Dphone;= p=3Dx>;index=3D1;rt;ao
r
History-Info:=20 <s= ip:bob@biloxi.example.com>;index=3D1.1;mp;aor
History-Info:=20 <sip:bob@19= 2.0.2.3>;index=3D1.1.1;rc

This=20 would result in all the H-I entries except (1) being considered
priv= ate=20 with the result that the =3D1800... Number is passed for call
handli= ng=20 purposes.

This change is backward compatible with the existing= =20 implementation as
any node using the existing functionality as defin= ed in=20 RFC4244 will
continue to be supported.

The alternative is to= =20 remove the ability to include the value "history"
in the P= rivacy header=20 and only allow this value in the Privacy header
parameter. This=20 alternative is not backward compatible.

Without this change a si= ngle=20 node in the message path which includes a
header "Privacy: hist= ory" will=20 prevent delivery of the aor and thus
prevent proper call=20 handling.

Ian Elz



-----Original Message-----
F= rom:=20 Christer Holmberg
Sent: 23 June 2009 19:40
To: 'Mary Barnes&#= 39;; Francois=20 Audet; Hans Erik van Elburg; Shida Schubert
Cc: Ian Elz
Subject: = RE:=20 4244bis and privacy


Hi,

I include Ian, so he can comm= ent=20 to your resposne=20 himself.

Regards,

Christer


-----Original=20 Message-----
From: Mary Barnes [mailto:mary.barnes@nortel.com]
Sent:=20 Tuesday, June 23, 2009 9:40 PM
To: Christer Holmberg; Francois Audet= ;=20 Hans Erik van Elburg; Shida
Schubert
Subject: RE: 4244bis and=20 privacy

Here was the thread of response and the last comment was= from=20 Ian that
he would consider the response:
http:/= /www.ietf.org/mail-archive/web/sip/current/msg26948.html

And,=20 there was not agreement on the "none" but rather to qualify t= he
SHOULD=20 NOT forward. =A0However, in the sipcore-4244bis-00, rather=20 than
changing the text such that the headers SHOULD be removed, we= =20 recommend
that they be anonymized (in section 4.3.3.3.1). =A0That is= =20 entirely
consistent with RFC 3324 and thus we have removed the=20 recommendations to
remove the headers entirely. However, that change= d=20 never got done in
section 3.2, so we would need to change this:
= =A0=20 "Thus, the History- Info header
=A0 SHOULD NOT be included in R= equests=20 where the requestor has indicated
=A0 a priv-value of Session- or=20 Header-level privacy."

But, I'm really beginning to be = of the mindset=20 that we should just
remove all the subsections of section 3 (i.e., l= eave=20 the text in the
upper level section), so we don't have to keep w= orrying=20 about
consistency.

So, lets either fixt the text in 3.2 or re= move=20 altogether and then I
think we are really at the point of needing to= =20 submit this version so
folks that actually have an interest in it ca= n=20 review the updated
document.

Mary.

-----Original=20 Message-----
From: Christer Holmberg [mailto:christer.holmberg@ericsson.com= ]
Sent:=20 Tuesday, June 23, 2009 1:10 PM
To: Barnes, Mary (RICH2:AR00); Audet,= =20 Francois (SC100:3055); Hans Erik
van Elburg; Shida Schubert
Subje= ct:=20 4244bis and privacy


Hi,

Below is a comment/proposal w= hich=20 one of my collegues (Ian Elz) gave on
the list a while ago, when the= =20 first version of 4244bis was submitted,
but was not incorporated. Do= you=20 think it would be useful?

-------

While the HI approach t= o=20 target may solve the problem of being able to
deliver the target URI= to=20 the final destination there is no guarantee
that it will actually be= =20 delivered.

The problem arises with how Privacy is defined for=20 HI.

4424 defines a new Privacy value "history" which m= ay be placed in=20 either
the Privacy header or as a header parameter to the HI=20 entry.

If one node uses the former option "Privacy: history= " then=20 this will
make all headers private and will result in all HI entries= =20 being removed
or made anonymous when the message containing the HI i= s=20 delivered to the
user.

There is a simple solution to this and= that=20 is to also allow the use of
the "none" Privacy value as a = header=20 parameter in the HI entry. This
would explicitly state that no priva= cy is=20 required to the HI entry and
this would override a "history&quo= t; value in the=20 Privacy header.

I pointed this out to Mary when the 4424bis draf= t was=20 first published
but the change has not been made in the latest=20 draft.

The change is backward compatible and would not cause an = issue=20 with any
existing=20 implementations.

------

Regards,

Christer

<= br>



--0016364ed9ae3f3d4e046d2ebfa3-- From ietf.hanserik@gmail.com Thu Jun 25 09:50:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BBFA28C0EA for ; Thu, 25 Jun 2009 09:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=-0.410, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, URI_HEX=0.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9aGAKAUT+6G for ; Thu, 25 Jun 2009 09:50:32 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 3520C3A69B4 for ; Thu, 25 Jun 2009 09:50:31 -0700 (PDT) Received: by ewy6 with SMTP id 6so2459549ewy.37 for ; Thu, 25 Jun 2009 09:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=MPBJSNwRZsIklW8K10Sgw5t56ZOsoj3FY7NPgpN2LYw=; b=NTbSoJQovlcsPybDTM0hCH1YfjFtjkV8Ozth6Oi3zItnqRc/4mwTjxVm2G0U5A6jbn dxmqHoFKIRuFl5NcY993/OhqJMDVITZm4F/i5YGXZ/u41ruT3C2V6wBhrG+xystB9XY+ tnIa7ifIoKTUIavuG6KdZgjgGrj3Ru5IAvvAg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=uwkDGiEJc+bGna4Y2HRsps9h2610usbyVFkEXkNIssxsXZ3BDF24fQYk6tOCjOhYM/ myugN+C0tmxKiaUuyxa4C/2mlL0jvPS0B/unQ3HXkFjil/eIiARUdTGoRnRxcz4NwcSo 0TYhd2R3RpcEgBEhkv8HMrhZggD3yELdZZqNA= MIME-Version: 1.0 Received: by 10.216.70.135 with SMTP id p7mr881716wed.138.1245948462283; Thu, 25 Jun 2009 09:47:42 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EB2629A@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EB2629A@zrc2hxm0.corp.nortel.com> Date: Thu, 25 Jun 2009 18:47:42 +0200 Message-ID: <9ae56b1e0906250947y658e78actf88374eeeca37384@mail.gmail.com> From: Hans Erik van Elburg To: Francois Audet Content-Type: multipart/alternative; boundary=001636d3474080c02c046d2efb55 Cc: Ian Elz , sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 16:50:39 -0000 --001636d3474080c02c046d2efb55 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit That's another use case. But given your set of info, I think that is correct. /Hans Erik van Elburg On Thu, Jun 25, 2009 at 6:37 PM, Francois Audet wrote: > So, let's say A calls B, B forwards to C. > > B has privacy turned on. > > A calls B. A history-info entry is added with sip:B. > > B retargets to C and sets privacy. > > I guess that would mean that B's proxy would have to parse the > History-Info > and anonymize all entries corresponding to B? > > Is this correct? > > > -----Original Message----- > > From: Barnes, Mary (RICH2:AR00) > > Sent: Thursday, June 25, 2009 09:29 > > To: Ian Elz > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > Subject: RE: 4244bis and privacy > > > > Hi Ian, > > > > Responses inline below [MB2]. > > > > Mary. > > > > -----Original Message----- > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > Sent: Thursday, June 25, 2009 10:13 AM > > To: Barnes, Mary (RICH2:AR00) > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > Subject: RE: 4244bis and privacy > > > > Mary, > > > > I am a little concerned about one answer that you gave: > > > > > > If you have a Privacy header with a value of "none" and a H-I > > entry with Privacy header parameter with value "history" what > > is the privacy of the individual H-I entry? > > [MB] We did not explicitly address the "none" in RFC 4244, > > but the general statement is the privacy headers at the > > request level override any at the hi-entry level. [/MB] > > > > This means that if privacy is required for an individual H-I > > entry but the originating user included "Privacy:none" in the > > request then there is no option to include the real URI in > > the H-I entry. > > [MB2] I'm confused here - the "none" definition is as you > > note below, thus "none" prohibits the removal or > > anonymization of the entries, thus I would think you would > > fine this functionality desireable. However, this does not > > prohibit an entity based on policy to anonymize (or remove > > entries if privacy is required for that domain if the entity > > does not have access to a privacy service). [/MB2] > > > > This occurs as RFC3323 states in section 4.3: "However, if > > the Privacy header value of 'none' is specified in a message, > > privacy services MUST NOT perform any privacy function and > > MUST NOT remove or modify the Privacy header." > > > > The only option for an intermediate node including a H-I > > entry where "Privacy:none" is specified and privacy for the > > H-I URI is required is to include an anonymous entry or not > > include the H-I entry. > > [MB2] If privacy is required then yes, you include anonymous > > entries or don't include. That's the basic privacy mechanism > > for privacy levels of "session" "header" and "history" in the > > R-URI or "history" in the specific entries, as well as when > > there is a policy for privacy for the entries added by a > > specific domain. The "none" really has no influence on the > > later case per se. [/MB2] > > > > In your previous response you stated that we would violate > > RFC3323 if we specified additional behaviour for privacy > > explicitly stated with a URI -n the H-I entry. I don't > > believe that this is the case as RFC3323 only considered > > privacy in a two party scenario and did not consider third > > party identities being included in a message between two > > parties. H-I is not the only case where this occurs as the > > Referred-By header when included in the INVITE (or other > > request) which results from the REFER has the same issue. > > [MB2] I can't necessarily disagree on this one (we can debate > > it either way). But to fix it requires an update to RFC 3323 > > and shouldn't be something that we want to fix in 4244bis. [/MB2] > > > > RFC4244 was the first time that there was a recognition that > > privacy for these individual third party identities may be > > required. To allow this explicit statement of privacy to be > > overridden by a generic statement which is applicable to a > > different user is counterintuitive. > > [MB2] See my comment above. But, as I have consistently said, > > the idea that an entity might want to override the "none" is > > entirely based on policy and 4244 and 4244bis allow privacy > > to be applied to the entries that are added by that entity if > > the policy dictates so (and we already say that). [/MB2] > > > > The original Privacy header is usually included by or on > > behalf of the originating user and should not be allowed to > > specify the privacy of the original called user, e.g. the 800 > > number, and prevent this identity being presented if this > > user does not have the same level of privacy. > > [MB2] As I tried to say in a previous response, a random > > entity (i.e., one for whom the R-URI is not in a domain under > > its control) cannot add a privacy header to the Request. Per > > RFC 3323 an entity may add the header to a request only if it > > has the appropriate relationship/authorization with the > > original called user who intiated the request. And, I would > > find it very surprising if an entity that did have > > responsibility would apply privacy since that would be > > counter intuitive and I would hope that SPs would be > > judicious in specifying the appropriate and inappropriate > > manner in which the proxies they deploy and interface with > > privatize the messages. The protocol CANNOT control this > > behavior and that's why there is the policy clause in 4244 > > and 4244bis. [/MB2] > > > > The real issue with the 800 scenario is as you have stated is > > that the answerer will not know the original called identity > > and will not be able to correctly handle the call. As more > > generic call centres are used which will answer calls on > > behalf of many different organizations using CTI and the > > original called identity to have to implement a generic > > system asking the caller who he originally called appear > > unprofessional, is inefficient and unproductive. > > [MB2] And, as I noted, it is rare for a call centre to route > > a call directly to an agent without a user providing some > > sort of input. Even companies like American Airlines, even > > though they have the info that I enter via the IVR, they > > still ask some basic questions and there are times when they > > have to reroute me. I don't think we can totally automate > > things. And, again, once the call hits the domain that is > > responsible for that 800 number the entities in that domain > > have control over how they muck with the R-URI, such that > > they should be able to use any IVR info to appropriately > > direct the call - it's not the number that's meaningful, but > > how the system gets the call to the right user and the > > additional information they provide as the call is presented > > to the agent. I would honestly think that having something > > other than an 800 number show up on the display would be far > > more useful and in my experience in the systems I developed > > we're usually talking about CTI interfaces so you have a lot > > you can do. And, actually all of this really doesn't matter > > in that you MUST be able to handle this situation independent > > of the privacy since History-Info is optional, you need > > default behavior assigned. [/MB2] > > > > We have an opportunity to allow presentation of specific > > identities and to solve this particular problem so we should take it. > > [MB2] The most we can do is to document the risks/impacts of > > the use of the Privacy headers at the R-URI level. There is > > already general text in 4244 and 4244bis that the privacy may > > impact whether the applications get the information. And, as > > I noted before, most commercial systems are using B2BUAs > > which will allow you far more control over the use of the > > Privacy headers in the network. But, again, I don't think > > that's something that should be address in 4244bis. [/MB2] > > > > I hope that we can get some wider discussion on this issue so > > a more general consensus can be obtained. > > > > Regards > > > > Ian > > > > > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: 24 June 2009 17:27 > > To: Ian Elz > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > > sipcore@ietf.org; Francois Audet > > Subject: RE: 4244bis and privacy > > > > Hi Ian, > > > > Responses inline below [MB]. > > > > Mary. > > > > -----Original Message----- > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > Sent: Wednesday, June 24, 2009 10:37 AM > > To: Barnes, Mary (RICH2:AR00) > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > Subject: RE: 4244bis and privacy > > > > Mary, > > > > I was not proposing that we change the handling of H-I which > > is based upon local policy. If that causes an issue for a > > network operator then they can modify their local policy > > accordingly or arrange with the proxy vendor to modify their > > equipment to be more flexible with regards to policy. > > > > Can you clarify for me: > > > > If you have a Privacy header with either "session" or > > "header" doe this impact the H-I entries or will only a value > > of "history" impact the H-I entries? > > [MB] Yes, both "session" and "header" level privacy, > > consistent with RFC 3323, mandate that entries be anonymized > > or dropped, with the latter being the recommendation for > > "session" level privacy. RFC 4244 mandated that they be > > dropped and 4244bis recommends they be anonymized. The > > original intent for the value of "history" was for the > > tagging of the individual entries, but you end up getting the > > header level functionality as well. [/MB] > > > > If you have a Privacy header with a value of "none" and a H-I > > entry with Privacy header parameter with value "history" what > > is the privacy of the individual H-I entry? > > [MB] We did not explicitly address the "none" in RFC 4244, > > but the general statement is the privacy headers at the > > request level override any at the hi-entry level. [/MB] > > > > From reading RFC4244 a Privacy header with value "history" > > will effectively make all H-I entries private and there is > > currently no option to include a H-I Privacy header > > parameter with value "none". > > [MB] Correct, per my comment above. [/MB] > > > > H-I at present allows the inclusion of Privacy header > > parameters to explicitly express privacy for an individual > > H-I entry but a single node which includes a header "Privacy: > > history" makes all H-I entries private even if this is not > > the requirements for the specific URI. > > [MB] Correct, but the only node that should add the header is > > a node which is responsible for the domain associated with > > the Request URI in the incoming request or is authorized to > > do so. [/MB] > > > > I will admit that having worked in a telephony environment > > for a long time I am used to having privacy of identities set > > on a per number basis and the relative inflexibility of the > > IETF Privacy header is relatively restrictive as to > > specifying which identities may be presented and which not. > > [MB] Yes, this is an entirely different paradigm. I > > developed telephony s/w for over a decade and this is > > entirely different - it provides a lot more flexibility, > > which makes things far, far less deterministic than what you > > have in telephony switches where your routing and > > translations are configured for the most part, with just a > > few capabilities for controlling the privacy and it's a > > closed network. > > > > With RFC4244/4244bis, there MUST be a mechanism at the UAS or > > end application that can handle a request that doesn't have > > the appropriate information either because nodes didn't > > support History-Info or some random node in the network > > applied privacy (which I think is highly > > unlikely) - this is normative per section 5 of RFC 4244. So, > > the worst case scenario I see for this 800 service (which > > will get to the right UAS but without the exact 800 number > > that was dialed) is that it goes to a default ACD > > group/customer service agent, etc. who then needs to gather > > the appropriate information and in my experience this is > > often an IVR system these days. So, the service is not > > broken when privacy is applied in an undesireable manner, > > it's just not optimal. This is something that should be > > addressed in the target-uri draft which has all the details > > of how specific services use History-Info. > > One other thing to consider is that most networks that are > > emulating telephony type features use B2BUAs, which follow > > the UAS/UAC rules for the header rather than the proxy rules, > > noting that the UAC can set the Privacy header to whatever > > value it sees as appropriate for the request. > > [/MB] > > > > > > Regards > > > > Ian > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: 24 June 2009 15:48 > > To: Ian Elz > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > > sipcore@ietf.org; Francois Audet > > Subject: RE: 4244bis and privacy > > > > Hi Ian, > > > > I do not believe we should do the "override" behavior as I > > think that violates RFC 3323, as the "history" is really a > > subset of the cases whereby a UAC or proxy would add > > "session" or "header" to the request. > > And, the latter two cases have the same (undesireable) > > result. I agree > > this impacts your services, but we can't mandate that proxies > > provide information that might violate their local policies > > and indeed a proxy's local policies can result in the > > information being anonymized (or removed if they can't > > anonymize) even in the "none" case. > > > > I do believe it's reasonable that we strongly recommend that > > the request level (versus specific hi-entries) not be used > > and if it is used, the consequence is that some services will > > not have the information they need - this was the gist of my > > previous response (to which I did not get any additional > > feedback). Now, we could add some text that the "none" > > case SHOULD be used (e.g., added by first hop proxy) if it is > > desired that the information not be subject to privacy > > restrictions. I do not think it is then particularly useful > > to add logic around the proxy then being able to tag the > > entries within their domain as subject to privacy. > > I think that conflicts with the intent of the request level "none". > > However, as I mention above, per the current text, a proxy > > can (based on local policy) remove entries - so a proxy can > > capture hi within their domain and not forward any of that > > information to the next hop in another domain - you already > > have that functionality. But, I think this introduces the > > general problem that you might be impacting other services > > further down the line, which I thought was the problem you > > were wanting to solve - not specifically your example service > > but, for example, in the case that someone is debugging and > > they want the entire history, so depending upon the service, > > this is also undesirable behavior. > > > > > > Regards, > > Mary. > > > > -----Original Message----- > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > Sent: Wednesday, June 24, 2009 2:57 AM > > To: Barnes, Mary (RICH2:AR00) > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > Subject: RE: 4244bis and privacy > > > > > > Mary, > > > > [I have added the list to this thread for wider comment.] > > > > In the previous discussions I commented that in RFC4424 that > > a Privacy header with value "history" effectively makes all > > H-I entries private with the result that the H-I entries may > > be removed. > > > > There has now been a comprehensive discussion on indication > > of the initial 'target' to the final recipient for call > > handling purposes. > > > > The main use case related to a freephone example where the > > answering location may be a call centre where the original > > freephone number may be required for correct call handling. > > > > If you now consider the following example (modified from > > Francois' text in the latest draft - excuse any errors that I > > may have inserted) > > > > INVITE sip:sip:+18001234567@example.com > ;user=phone;p=x > > Privacy: history > > History-Info: > > > ;user=phone;p=x>;index=1;rt;aor > > (1) > > History-Info: > >;index=1.1;mp;aor > > (2) > > History-Info: >;index=1.1.1;rc > > (3) > > > > In this case due to the Privacy header all of the H-I entries > > are considered private and the +18001234567 will not be > > delivered to the final destination with the result that call > > handling may not be correct. > > The Privacy header may have been inserted by any of the nodes > > which routed the message and inserted a H-I entry. > > > > If however the H-I was allowed to include a header parameter > > of "?Privacy=none" in the H-I entry and that an explicit H-I > > entry privacy value would be considered to have precedence > > over a Privacy header with a value of "history" then the > > mapping of the +18001234567 could be explicitly specified as > > not private and may be passed on. > > > > Thus when the mapping from sip:+18001234567@example.comto > > sip:bob@biloxi.example.com when H-I entry > (2) above is > > included could also insert the Privacy header parameter in > > H-I entry (1). > > > > Thus the message would appear as follows: > > > > INVITE sip:sip:+18001234567@example.com; > user=phone;p=x > > Privacy: history > > History-Info: > > ;ind > > ex=1;rt;ao > > r > > History-Info: > >;index=1.1;mp;aor > > History-Info: >;index=1.1.1;rc > > > > This would result in all the H-I entries except (1) being > > considered private with the result that the =1800... Number > > is passed for call handling purposes. > > > > This change is backward compatible with the existing > > implementation as any node using the existing functionality > > as defined in RFC4244 will continue to be supported. > > > > The alternative is to remove the ability to include the value > > "history" > > in the Privacy header and only allow this value in the > > Privacy header parameter. This alternative is not backward compatible. > > > > Without this change a single node in the message path which > > includes a header "Privacy: history" will prevent delivery of > > the aor and thus prevent proper call handling. > > > > Ian Elz > > > > > > > > -----Original Message----- > > From: Christer Holmberg > > Sent: 23 June 2009 19:40 > > To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; > > Shida Schubert > > Cc: Ian Elz > > Subject: RE: 4244bis and privacy > > > > > > Hi, > > > > I include Ian, so he can comment to your resposne himself. > > > > Regards, > > > > Christer > > > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: Tuesday, June 23, 2009 9:40 PM > > To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; > > Shida Schubert > > Subject: RE: 4244bis and privacy > > > > Here was the thread of response and the last comment was from > > Ian that he would consider the response: > > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html > > > > And, there was not agreement on the "none" but rather to > > qualify the SHOULD NOT forward. However, in the > > sipcore-4244bis-00, rather than changing the text such that > > the headers SHOULD be removed, we recommend that they be > > anonymized (in section 4.3.3.3.1). That is entirely > > consistent with RFC 3324 and thus we have removed the > > recommendations to remove the headers entirely. However, that > > changed never got done in section 3.2, so we would need to > > change this: > > "Thus, the History- Info header > > SHOULD NOT be included in Requests where the requestor has > > indicated > > a priv-value of Session- or Header-level privacy." > > > > But, I'm really beginning to be of the mindset that we should > > just remove all the subsections of section 3 (i.e., leave the > > text in the upper level section), so we don't have to keep > > worrying about consistency. > > > > So, lets either fixt the text in 3.2 or remove altogether and > > then I think we are really at the point of needing to submit > > this version so folks that actually have an interest in it > > can review the updated document. > > > > Mary. > > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, June 23, 2009 1:10 PM > > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); > > Hans Erik van Elburg; Shida Schubert > > Subject: 4244bis and privacy > > > > > > Hi, > > > > Below is a comment/proposal which one of my collegues (Ian > > Elz) gave on the list a while ago, when the first version of > > 4244bis was submitted, but was not incorporated. Do you think > > it would be useful? > > > > ------- > > > > While the HI approach to target may solve the problem of > > being able to deliver the target URI to the final destination > > there is no guarantee that it will actually be delivered. > > > > The problem arises with how Privacy is defined for HI. > > > > 4424 defines a new Privacy value "history" which may be > > placed in either the Privacy header or as a header parameter > > to the HI entry. > > > > If one node uses the former option "Privacy: history" then > > this will make all headers private and will result in all HI > > entries being removed or made anonymous when the message > > containing the HI is delivered to the user. > > > > There is a simple solution to this and that is to also allow > > the use of the "none" Privacy value as a header parameter in > > the HI entry. This would explicitly state that no privacy is > > required to the HI entry and this would override a "history" > > value in the Privacy header. > > > > I pointed this out to Mary when the 4424bis draft was first > > published but the change has not been made in the latest draft. > > > > The change is backward compatible and would not cause an > > issue with any existing implementations. > > > > ------ > > > > Regards, > > > > Christer > > > > > > > > > > > --001636d3474080c02c046d2efb55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's another use case.

But given your set of info,= I think that is correct.

/Hans Erik van Elburg

On Thu, Jun 25, 2009 at 6:37 PM, Francois Au= det <audet@nortel.= com> wrote:
So, let's say A calls B, B forwards to C.

B has privacy turned on.

A calls B. A history-info entry is added with sip:B.

B retargets to C and sets privacy.

I guess that would mean that B's proxy would have to parse the
History-Info
and anonymize all entries corresponding to B?

Is this correct?

> -----Original Message-----
> From: Barnes, Mary (RICH2:AR00)
> Sent: Thursday, June 25, 2009 09:29
> To: Ian Elz
> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
> sipcore@ietf.org; Audet, Francois (SC100:3055)
> Subject: RE: 4244bis and privacy
>
> Hi Ian,
>
> Responses inline below [MB2].
>
> Mary.
>
> -----Original Message-----
> From: Ian Elz [mailto:ian.elz@= ericsson.com]
> Sent: Thursday, June 25, 2009 10:13 AM
> To: Barnes, Mary (RICH2:AR00)
> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
> sipcore@ietf.org; Audet, Franc= ois (SC100:3055)
> Subject: RE: 4244bis and privacy
>
> Mary,
>
> I am a little concerned about one answer that you gave:
>
>
> If you have a Privacy header with a value of "none" and a H-= I
> entry with Privacy header parameter with value "history" wha= t
> is the privacy of the individual H-I entry?
> [MB] We did not explicitly address the "none" in RFC 4244, > but the general statement is the privacy headers at the
> request level override any at the hi-entry level. [/MB]
>
> This means that if privacy is required for an individual H-I
> entry but the originating user included "Privacy:none" in th= e
> request then there is no option to include the real URI in
> the H-I entry.
> [MB2] I'm confused here - the "none" definition is as yo= u
> note below, thus "none" prohibits the removal or
> anonymization of the entries, thus I would think you would
> fine this functionality desireable. However, this does not
> prohibit an entity based on policy to anonymize (or remove
> entries if privacy is required for that domain if the entity
> does not have access to a privacy service). [/MB2]
>
> This occurs as RFC3323 states in section 4.3: "However, if
> the Privacy header value of 'none' is specified in a message,<= br> > privacy services MUST NOT perform any privacy function and
> MUST NOT remove or modify the Privacy header."
>
> The only option for an intermediate node including a H-I
> entry where "Privacy:none" is specified and privacy for the<= br> > H-I URI is required is to include an anonymous entry or not
> include the H-I entry.
> [MB2] If privacy is required then yes, you include anonymous
> entries or don't include. That's the basic privacy mechanism > for privacy levels of "session" "header" and "= ;history" in the
> R-URI or "history" in the specific entries, as well as when<= br> > there is a policy for privacy for the entries added by a
> specific domain. The "none" really has no influence on the > later case per se. [/MB2]
>
> In your previous response you stated that we would violate
> RFC3323 if we specified additional behaviour for privacy
> explicitly stated with a URI -n the H-I entry. I don't
> believe that this is the case as RFC3323 only considered
> privacy in a two party scenario and did not consider third
> party identities being included in a message between two
> parties. H-I is not the only case where this occurs as the
> Referred-By header when included in the INVITE (or other
> request) which results from the REFER has the same issue.
> [MB2] I can't necessarily disagree on this one (we can debate
> it either way). But to fix it requires an update to RFC 3323
> and shouldn't be something that we want to fix in 4244bis. [/MB2]<= br> >
> RFC4244 was the first time that there was a recognition that
> privacy for these individual third party identities may be
> required. To allow this explicit statement of privacy to be
> overridden by a generic statement which is applicable to a
> different user is counterintuitive.
> [MB2] See my comment above. But, as I have consistently said,
> the idea that an entity might want to override the "none" is=
> entirely based on policy and 4244 and 4244bis allow privacy
> to be applied to the entries that are added by that entity if
> the policy dictates so (and we already say that). [/MB2]
>
> The original Privacy header is usually included by or on
> behalf of the originating user and should not be allowed to
> specify the privacy of the original called user, e.g. the 800
> number, and prevent this identity being presented if this
> user does not have the same level of privacy.
> [MB2] As I tried to say in a previous response, a random
> entity (i.e., one for whom the R-URI is not in a domain under
> its control) cannot add a privacy header to the Request. Per
> RFC 3323 an entity may add the header to a request only if it
> has the appropriate relationship/authorization with the
> original called user who intiated the request. And, I would
> find it very surprising if an entity that did have
> responsibility would apply privacy since that would be
> counter intuitive and I would hope that SPs would be
> judicious in specifying the appropriate and inappropriate
> manner in which the proxies they deploy and interface with
> privatize the messages. The protocol CANNOT control this
> behavior and that's why there is the policy clause in 4244
> and 4244bis. [/MB2]
>
> The real issue with the 800 scenario is as you have stated is
> that the answerer will not know the original called identity
> and will not be able to correctly handle the call. As more
> generic call centres are used which will answer calls on
> behalf of many different organizations using CTI and the
> original called identity to have to implement a generic
> system asking the caller who he originally called appear
> unprofessional, is inefficient and unproductive.
> [MB2] And, as I noted, it is rare for a call centre to route
> a call directly to an agent without a user providing some
> sort of input. Even companies like American Airlines, even
> though they have the info that I enter via the IVR, they
> still ask some basic questions and there are times when they
> have to reroute me. I don't think we can totally automate
> things. =A0And, again, once the call hits the domain that is
> responsible for that 800 number the entities in that domain
> have control over how they muck with the R-URI, such that
> they should be able to use any IVR info to appropriately
> direct the call - it's not the number that's meaningful, but > how the system gets the call to the right user and the
> additional information they provide as the call is presented
> to the agent. I would honestly think that having something
> other than an 800 number show up on the display would be far
> more useful and in my experience in the systems I developed
> we're usually talking about CTI interfaces so you have a lot
> you can do. =A0And, actually all of this really doesn't matter
> in that you MUST be able to handle this situation independent
> of the privacy since History-Info is optional, you need
> default behavior assigned. [/MB2]
>
> We have an opportunity to allow presentation of specific
> identities and to solve this particular problem so we should take it.<= br> > [MB2] The most we can do is to document the risks/impacts of
> the use of the Privacy headers at the R-URI level. There is
> already general text in 4244 and 4244bis that the privacy may
> impact whether the applications get the information. =A0And, as
> I noted before, most commercial systems are using B2BUAs
> which will allow you far more control over the use of the
> Privacy headers in the network. But, again, I don't think
> that's something that should be address in 4244bis. =A0[/MB2]
>
> I hope that we can get some wider discussion on this issue so
> a more general consensus can be obtained.
>
> Regards
>
> Ian
>
>
>
> -----Original Message-----
> From: Mary Barnes [mailto:ma= ry.barnes@nortel.com]
> Sent: 24 June 2009 17:27
> To: Ian Elz
> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
> sipcore@ietf.org; Francois Aud= et
> Subject: RE: 4244bis and privacy
>
> Hi Ian,
>
> Responses inline below [MB].
>
> Mary.
>
> -----Original Message-----
> From: Ian Elz [mailto:ian.elz@= ericsson.com]
> Sent: Wednesday, June 24, 2009 10:37 AM
> To: Barnes, Mary (RICH2:AR00)
> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
> sipcore@ietf.org; Audet, Franc= ois (SC100:3055)
> Subject: RE: 4244bis and privacy
>
> Mary,
>
> I was not proposing that we change the handling of H-I which
> is based upon local policy. If that causes an issue for a
> network operator then they can modify their local policy
> accordingly or arrange with the proxy vendor to modify their
> equipment to be more flexible with regards to policy.
>
> Can you clarify for me:
>
> If you have a Privacy header with either "session" or
> "header" doe this impact the H-I entries or will only a valu= e
> of "history" impact the H-I entries?
> [MB] Yes, both "session" and "header" level privac= y,
> consistent with RFC 3323, mandate that entries be anonymized
> or dropped, with the latter being the recommendation for
> "session" level privacy. RFC 4244 mandated that they be
> dropped and 4244bis recommends they be anonymized. The
> original intent for the value of "history" was for the
> tagging of the individual entries, but you end up getting the
> header level functionality as well. [/MB]
>
> If you have a Privacy header with a value of "none" and a H-= I
> entry with Privacy header parameter with value "history" wha= t
> is the privacy of the individual H-I entry?
> [MB] We did not explicitly address the "none" in RFC 4244, > but the general statement is the privacy headers at the
> request level override any at the hi-entry level. [/MB]
>
> From reading RFC4244 a Privacy header with value "history" > will effectively make all H-I entries private and there is
> currently no option to =A0include a H-I Privacy header
> parameter with value "none".
> [MB] Correct, per my comment above. [/MB]
>
> H-I at present allows the inclusion of Privacy header
> parameters to explicitly express privacy for an individual
> H-I entry but a single node which includes a header "Privacy:
> history" makes all H-I entries private even if this is not
> the requirements for the specific URI.
> [MB] Correct, but the only node that should add the header is
> a node which is responsible for the domain associated with
> the Request URI in the incoming request or is authorized to
> do so. [/MB]
>
> I will admit that having worked in a telephony environment
> for a long time I am used to having privacy of identities set
> on a per number basis and the relative inflexibility of the
> IETF Privacy header is relatively restrictive as to
> specifying which identities may be presented and which not.
> [MB] Yes, this is an entirely different paradigm. =A0I
> developed telephony s/w for over a decade and this is
> entirely different - it provides a lot more flexibility,
> which makes things far, far less deterministic than what you
> have in telephony switches where your routing and
> translations are configured for the most part, with just a
> few capabilities for controlling the privacy and it's a
> closed network.
>
> With RFC4244/4244bis, there MUST be a mechanism at the UAS or
> end application that can handle a request that doesn't have
> the appropriate information either because nodes didn't
> support History-Info or some random node in the network
> applied privacy (which I think is highly
> unlikely) - this is normative per section 5 of RFC 4244. =A0So,
> the worst case scenario I see for this 800 service =A0(which
> will get to the right UAS but without the exact 800 number
> that was dialed) is that it goes to a default ACD
> group/customer service agent, etc. who then needs to gather
> the appropriate information and in my experience this is
> often an IVR system these days. =A0So, the service is not
> broken when privacy is applied in an undesireable manner,
> it's just not optimal. =A0This is something that should be
> addressed in the target-uri draft which has all the details
> of how specific services use History-Info.
> One other thing to consider is that most networks that are
> emulating telephony type features use B2BUAs, which follow
> the UAS/UAC rules for the header rather than the proxy rules,
> noting that the UAC can set the Privacy header to whatever
> value it sees as appropriate for the request.
> [/MB]
>
>
> Regards
>
> Ian
>
> -----Original Message-----
> From: Mary Barnes [mailto:ma= ry.barnes@nortel.com]
> Sent: 24 June 2009 15:48
> To: Ian Elz
> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
> sipcore@ietf.org; Francois Aud= et
> Subject: RE: 4244bis and privacy
>
> Hi Ian,
>
> I do not believe we should do the "override" behavior as I > think that violates RFC 3323, as the "history" is really a > subset of the cases whereby a UAC or proxy would add
> "session" or "header" to the request.
> And, the latter two cases have the same (undesireable)
> result. =A0 I agree
> this impacts your services, but we can't mandate that proxies
> provide information that might violate their local policies
> and indeed a proxy's local policies can result in the
> information being anonymized (or removed if they can't
> anonymize) even in the "none" case.
>
> I do believe it's reasonable that we strongly recommend that
> the request level (versus specific hi-entries) not be used
> and if it is used, the consequence is that some services will
> not have the information they need - this was the gist of my
> previous response (to which I did not get any additional
> feedback). Now, we could add some text that the "none"
> case SHOULD be used (e.g., added by first hop proxy) if it is
> desired that the information not be subject to privacy
> restrictions. I do not think it is then particularly useful
> to add logic around the proxy then being able to tag the
> entries within their domain as subject to privacy.
> I think that conflicts with the intent of the request level "none= ".
> However, as I mention above, per the current text, a proxy
> can (based on local policy) remove entries - so a proxy can
> capture hi within their domain and not forward any of that
> information to the next hop in another domain - you already
> have that functionality. =A0But, I think this introduces the
> general problem that you might be impacting other services
> further down the line, which I thought was the problem you
> were wanting to solve - not specifically your example service
> but, for example, in the case that someone is debugging and
> they want the entire history, so depending upon the service,
> this is also undesirable behavior.
>
>
> Regards,
> Mary.
>
> -----Original Message-----
> From: Ian Elz [mailto:ian.elz@= ericsson.com]
> Sent: Wednesday, June 24, 2009 2:57 AM
> To: Barnes, Mary (RICH2:AR00)
> Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;
> sipcore@ietf.org; Audet, Franc= ois (SC100:3055)
> Subject: RE: 4244bis and privacy
>
>
> =A0Mary,
>
> [I have added the list to this thread for wider comment.]
>
> In the previous discussions I commented that in RFC4424 that
> a Privacy header with value "history" effectively makes all<= br> > H-I entries private with the result that the H-I entries may
> be removed.
>
> There has now been a comprehensive discussion on indication
> of the initial 'target' to the final recipient for call
> handling purposes.
>
> The main use case related to a freephone example where the
> answering location may be a call centre where the original
> freephone number may be required for correct call handling.
>
> If you now consider the following example (modified from
> Francois' text in the latest draft - excuse any errors that I
> may have inserted)
>
> INVITE sip:s= ip:+18001234567@example.com;user=3Dphone;p=3Dx
> Privacy: history
> History-Info:
> <sip:+180012345= 67@example.com;user=3Dphone;p=3Dx>;index=3D1;rt;aor
> =A0 =A0 =A0 =A0(1)
> History-Info: <sip:= bob@biloxi.example.com>;index=3D1.1;mp;aor
> (2)
> History-Info: <sip:bob@192.0= .2.3>;index=3D1.1.1;rc
> (3)
>
> In this case due to the Privacy header all of the H-I entries
> are considered private and the +18001234567 will not be
> delivered to the final destination with the result that call
> handling may not be correct.
> The Privacy header may have been inserted by any of the nodes
> which routed the message and inserted a H-I entry.
>
> If however the H-I was allowed to include a header parameter
> of "?Privacy=3Dnone" in the H-I entry and that an explicit H= -I
> entry privacy value would be considered to have precedence
> over a Privacy header with a value of "history" then the
> mapping of the +18001234567 could be explicitly specified as
> not private and may be passed on.
>
> Thus when the mapping from sip:+18001234567@example.com to
> sip:bob@biloxi.example= .com when H-I entry (2) above is
> included could also insert the Privacy header parameter in
> H-I entry (1).
>
> Thus the message would appear as follows:
>
> INVITE sip:s= ip:+18001234567@example.com; user=3Dphone;p=3Dx
> Privacy: history
> History-Info:
> <sip:+18001234567@example.com?Privacy=3Dno= ne;user=3Dphone;p=3Dx>;ind
> ex=3D1;rt;ao
> r
> History-Info: <sip:= bob@biloxi.example.com>;index=3D1.1;mp;aor
> History-Info: <sip:bob@192.0= .2.3>;index=3D1.1.1;rc
>
> This would result in all the H-I entries except (1) being
> considered private with the result that the =3D1800... Number
> is passed for call handling purposes.
>
> This change is backward compatible with the existing
> implementation as any node using the existing functionality
> as defined in RFC4244 will continue to be supported.
>
> The alternative is to remove the ability to include the value
> "history"
> in the Privacy header and only allow this value in the
> Privacy header parameter. This alternative is not backward compatible.=
>
> Without this change a single node in the message path which
> includes a header "Privacy: history" will prevent delivery o= f
> the aor and thus prevent proper call handling.
>
> Ian Elz
>
>
>
> -----Original Message-----
> From: Christer Holmberg
> Sent: 23 June 2009 19:40
> To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg;
> Shida Schubert
> Cc: Ian Elz
> Subject: RE: 4244bis and privacy
>
>
> Hi,
>
> I include Ian, so he can comment to your resposne himself.
>
> Regards,
>
> Christer
>
>
> -----Original Message-----
> From: Mary Barnes [mailto:ma= ry.barnes@nortel.com]
> Sent: Tuesday, June 23, 2009 9:40 PM
> To: Christer Holmberg; Francois Audet; Hans Erik van Elburg;
> Shida Schubert
> Subject: RE: 4244bis and privacy
>
> Here was the thread of response and the last comment was from
> Ian that he would consider the response:
> http://www.ietf.org/mail-archive/web/sip/current/msg= 26948.html
>
> And, there was not agreement on the "none" but rather to
> qualify the SHOULD NOT forward. =A0However, in the
> sipcore-4244bis-00, rather than changing the text such that
> the headers SHOULD be removed, we recommend that they be
> anonymized (in section 4.3.3.3.1). =A0That is entirely
> consistent with RFC 3324 and thus we have removed the
> recommendations to remove the headers entirely. However, that
> changed never got done in section 3.2, so we would need to
> change this:
> =A0 =A0"Thus, the History- Info header
> =A0 =A0SHOULD NOT be included in Requests where the requestor has
> indicated
> =A0 =A0a priv-value of Session- or Header-level privacy."
>
> But, I'm really beginning to be of the mindset that we should
> just remove all the subsections of section 3 (i.e., leave the
> text in the upper level section), so we don't have to keep
> worrying about consistency.
>
> So, lets either fixt the text in 3.2 or remove altogether and
> then I think we are really at the point of needing to submit
> this version so folks that actually have an interest in it
> can review the updated document.
>
> Mary.
>
> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> Sent: Tuesday, June 23, 2009 1:10 PM
> To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055);
> Hans Erik van Elburg; Shida Schubert
> Subject: 4244bis and privacy
>
>
> Hi,
>
> Below is a comment/proposal which one of my collegues (Ian
> Elz) gave on the list a while ago, when the first version of
> 4244bis was submitted, but was not incorporated. Do you think
> it would be useful?
>
> -------
>
> While the HI approach to target may solve the problem of
> being able to deliver the target URI to the final destination
> there is no guarantee that it will actually be delivered.
>
> The problem arises with how Privacy is defined for HI.
>
> 4424 defines a new Privacy value "history" which may be
> placed in either the Privacy header or as a header parameter
> to the HI entry.
>
> If one node uses the former option "Privacy: history" then > this will make all headers private and will result in all HI
> entries being removed or made anonymous when the message
> containing the HI is delivered to the user.
>
> There is a simple solution to this and that is to also allow
> the use of the "none" Privacy value as a header parameter in=
> the HI entry. This would explicitly state that no privacy is
> required to the HI entry and this would override a "history"=
> value in the Privacy header.
>
> I pointed this out to Mary when the 4424bis draft was first
> published but the change has not been made in the latest draft.
>
> The change is backward compatible and would not cause an
> issue with any existing implementations.
>
> ------
>
> Regards,
>
> Christer
>
>
>
>
>

--001636d3474080c02c046d2efb55-- From AUDET@nortel.com Thu Jun 25 09:54:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBD843A6DDE for ; Thu, 25 Jun 2009 09:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.066 X-Spam-Level: X-Spam-Status: No, score=-6.066 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynZD9QHTYbcd for ; Thu, 25 Jun 2009 09:54:14 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 038823A68F8 for ; Thu, 25 Jun 2009 09:54:11 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5PGaC513962; Thu, 25 Jun 2009 16:36:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 11:37:23 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EB2629A@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 4244bis and privacy thread-index: Acn0Lcc7X7sq6TfYRnWN9a4W8C0fHQAARIBQAADAA2AAGracUAAO1MaQAAH7tqAAAL/rAAAvtR7AAAMWtOAAATLMIA== References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Mary Barnes" , "Ian Elz" Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 16:54:16 -0000 So, let's say A calls B, B forwards to C. B has privacy turned on. A calls B. A history-info entry is added with sip:B. B retargets to C and sets privacy. I guess that would mean that B's proxy would have to parse the History-Info and anonymize all entries corresponding to B? Is this correct?=20 > -----Original Message----- > From: Barnes, Mary (RICH2:AR00)=20 > Sent: Thursday, June 25, 2009 09:29 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy >=20 > Hi Ian, >=20 > Responses inline below [MB2]. >=20 > Mary. >=20 > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Thursday, June 25, 2009 10:13 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy >=20 > Mary, >=20 > I am a little concerned about one answer that you gave: >=20 >=20 > If you have a Privacy header with a value of "none" and a H-I=20 > entry with Privacy header parameter with value "history" what=20 > is the privacy of the individual H-I entry? > [MB] We did not explicitly address the "none" in RFC 4244,=20 > but the general statement is the privacy headers at the=20 > request level override any at the hi-entry level. [/MB] > =20 > This means that if privacy is required for an individual H-I=20 > entry but the originating user included "Privacy:none" in the=20 > request then there is no option to include the real URI in=20 > the H-I entry. > [MB2] I'm confused here - the "none" definition is as you=20 > note below, thus "none" prohibits the removal or=20 > anonymization of the entries, thus I would think you would=20 > fine this functionality desireable. However, this does not=20 > prohibit an entity based on policy to anonymize (or remove=20 > entries if privacy is required for that domain if the entity=20 > does not have access to a privacy service). [/MB2] >=20 > This occurs as RFC3323 states in section 4.3: "However, if=20 > the Privacy header value of 'none' is specified in a message,=20 > privacy services MUST NOT perform any privacy function and=20 > MUST NOT remove or modify the Privacy header." >=20 > The only option for an intermediate node including a H-I=20 > entry where "Privacy:none" is specified and privacy for the=20 > H-I URI is required is to include an anonymous entry or not=20 > include the H-I entry. > [MB2] If privacy is required then yes, you include anonymous=20 > entries or don't include. That's the basic privacy mechanism=20 > for privacy levels of "session" "header" and "history" in the=20 > R-URI or "history" in the specific entries, as well as when=20 > there is a policy for privacy for the entries added by a=20 > specific domain. The "none" really has no influence on the=20 > later case per se. [/MB2] >=20 > In your previous response you stated that we would violate=20 > RFC3323 if we specified additional behaviour for privacy=20 > explicitly stated with a URI -n the H-I entry. I don't=20 > believe that this is the case as RFC3323 only considered=20 > privacy in a two party scenario and did not consider third=20 > party identities being included in a message between two=20 > parties. H-I is not the only case where this occurs as the=20 > Referred-By header when included in the INVITE (or other=20 > request) which results from the REFER has the same issue. > [MB2] I can't necessarily disagree on this one (we can debate=20 > it either way). But to fix it requires an update to RFC 3323=20 > and shouldn't be something that we want to fix in 4244bis. [/MB2] >=20 > RFC4244 was the first time that there was a recognition that=20 > privacy for these individual third party identities may be=20 > required. To allow this explicit statement of privacy to be=20 > overridden by a generic statement which is applicable to a=20 > different user is counterintuitive. > [MB2] See my comment above. But, as I have consistently said,=20 > the idea that an entity might want to override the "none" is=20 > entirely based on policy and 4244 and 4244bis allow privacy=20 > to be applied to the entries that are added by that entity if=20 > the policy dictates so (and we already say that). [/MB2] >=20 > The original Privacy header is usually included by or on=20 > behalf of the originating user and should not be allowed to=20 > specify the privacy of the original called user, e.g. the 800=20 > number, and prevent this identity being presented if this=20 > user does not have the same level of privacy. > [MB2] As I tried to say in a previous response, a random=20 > entity (i.e., one for whom the R-URI is not in a domain under=20 > its control) cannot add a privacy header to the Request. Per=20 > RFC 3323 an entity may add the header to a request only if it=20 > has the appropriate relationship/authorization with the=20 > original called user who intiated the request. And, I would=20 > find it very surprising if an entity that did have=20 > responsibility would apply privacy since that would be=20 > counter intuitive and I would hope that SPs would be=20 > judicious in specifying the appropriate and inappropriate=20 > manner in which the proxies they deploy and interface with=20 > privatize the messages. The protocol CANNOT control this=20 > behavior and that's why there is the policy clause in 4244=20 > and 4244bis. [/MB2] =20 >=20 > The real issue with the 800 scenario is as you have stated is=20 > that the answerer will not know the original called identity=20 > and will not be able to correctly handle the call. As more=20 > generic call centres are used which will answer calls on=20 > behalf of many different organizations using CTI and the=20 > original called identity to have to implement a generic=20 > system asking the caller who he originally called appear=20 > unprofessional, is inefficient and unproductive. > [MB2] And, as I noted, it is rare for a call centre to route=20 > a call directly to an agent without a user providing some=20 > sort of input. Even companies like American Airlines, even=20 > though they have the info that I enter via the IVR, they=20 > still ask some basic questions and there are times when they=20 > have to reroute me. I don't think we can totally automate=20 > things. And, again, once the call hits the domain that is=20 > responsible for that 800 number the entities in that domain=20 > have control over how they muck with the R-URI, such that=20 > they should be able to use any IVR info to appropriately=20 > direct the call - it's not the number that's meaningful, but=20 > how the system gets the call to the right user and the=20 > additional information they provide as the call is presented=20 > to the agent. I would honestly think that having something=20 > other than an 800 number show up on the display would be far=20 > more useful and in my experience in the systems I developed=20 > we're usually talking about CTI interfaces so you have a lot=20 > you can do. And, actually all of this really doesn't matter=20 > in that you MUST be able to handle this situation independent=20 > of the privacy since History-Info is optional, you need=20 > default behavior assigned. [/MB2]=20 >=20 > We have an opportunity to allow presentation of specific=20 > identities and to solve this particular problem so we should take it. > [MB2] The most we can do is to document the risks/impacts of=20 > the use of the Privacy headers at the R-URI level. There is=20 > already general text in 4244 and 4244bis that the privacy may=20 > impact whether the applications get the information. And, as=20 > I noted before, most commercial systems are using B2BUAs=20 > which will allow you far more control over the use of the=20 > Privacy headers in the network. But, again, I don't think=20 > that's something that should be address in 4244bis. [/MB2] >=20 > I hope that we can get some wider discussion on this issue so=20 > a more general consensus can be obtained. >=20 > Regards >=20 > Ian >=20 >=20 >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 24 June 2009 17:27 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Francois Audet > Subject: RE: 4244bis and privacy >=20 > Hi Ian, >=20 > Responses inline below [MB]. >=20 > Mary.=20 >=20 > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, June 24, 2009 10:37 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy >=20 > Mary, >=20 > I was not proposing that we change the handling of H-I which=20 > is based upon local policy. If that causes an issue for a=20 > network operator then they can modify their local policy=20 > accordingly or arrange with the proxy vendor to modify their=20 > equipment to be more flexible with regards to policy. >=20 > Can you clarify for me: >=20 > If you have a Privacy header with either "session" or=20 > "header" doe this impact the H-I entries or will only a value=20 > of "history" impact the H-I entries? > [MB] Yes, both "session" and "header" level privacy,=20 > consistent with RFC 3323, mandate that entries be anonymized=20 > or dropped, with the latter being the recommendation for=20 > "session" level privacy. RFC 4244 mandated that they be=20 > dropped and 4244bis recommends they be anonymized. The=20 > original intent for the value of "history" was for the=20 > tagging of the individual entries, but you end up getting the=20 > header level functionality as well. [/MB]=20 >=20 > If you have a Privacy header with a value of "none" and a H-I=20 > entry with Privacy header parameter with value "history" what=20 > is the privacy of the individual H-I entry? > [MB] We did not explicitly address the "none" in RFC 4244,=20 > but the general statement is the privacy headers at the=20 > request level override any at the hi-entry level. [/MB] >=20 > From reading RFC4244 a Privacy header with value "history"=20 > will effectively make all H-I entries private and there is=20 > currently no option to include a H-I Privacy header=20 > parameter with value "none". > [MB] Correct, per my comment above. [/MB] >=20 > H-I at present allows the inclusion of Privacy header=20 > parameters to explicitly express privacy for an individual=20 > H-I entry but a single node which includes a header "Privacy:=20 > history" makes all H-I entries private even if this is not=20 > the requirements for the specific URI. > [MB] Correct, but the only node that should add the header is=20 > a node which is responsible for the domain associated with=20 > the Request URI in the incoming request or is authorized to=20 > do so. [/MB] >=20 > I will admit that having worked in a telephony environment=20 > for a long time I am used to having privacy of identities set=20 > on a per number basis and the relative inflexibility of the=20 > IETF Privacy header is relatively restrictive as to=20 > specifying which identities may be presented and which not. > [MB] Yes, this is an entirely different paradigm. I=20 > developed telephony s/w for over a decade and this is=20 > entirely different - it provides a lot more flexibility,=20 > which makes things far, far less deterministic than what you=20 > have in telephony switches where your routing and=20 > translations are configured for the most part, with just a=20 > few capabilities for controlling the privacy and it's a=20 > closed network. =20 >=20 > With RFC4244/4244bis, there MUST be a mechanism at the UAS or=20 > end application that can handle a request that doesn't have=20 > the appropriate information either because nodes didn't=20 > support History-Info or some random node in the network=20 > applied privacy (which I think is highly > unlikely) - this is normative per section 5 of RFC 4244. So,=20 > the worst case scenario I see for this 800 service (which=20 > will get to the right UAS but without the exact 800 number=20 > that was dialed) is that it goes to a default ACD=20 > group/customer service agent, etc. who then needs to gather=20 > the appropriate information and in my experience this is=20 > often an IVR system these days. So, the service is not=20 > broken when privacy is applied in an undesireable manner,=20 > it's just not optimal. This is something that should be=20 > addressed in the target-uri draft which has all the details=20 > of how specific services use History-Info. > One other thing to consider is that most networks that are=20 > emulating telephony type features use B2BUAs, which follow=20 > the UAS/UAC rules for the header rather than the proxy rules,=20 > noting that the UAC can set the Privacy header to whatever=20 > value it sees as appropriate for the request. > [/MB] >=20 >=20 > Regards=20 >=20 > Ian >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 24 June 2009 15:48 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Francois Audet > Subject: RE: 4244bis and privacy >=20 > Hi Ian, >=20 > I do not believe we should do the "override" behavior as I=20 > think that violates RFC 3323, as the "history" is really a=20 > subset of the cases whereby a UAC or proxy would add=20 > "session" or "header" to the request. > And, the latter two cases have the same (undesireable)=20 > result. I agree > this impacts your services, but we can't mandate that proxies=20 > provide information that might violate their local policies=20 > and indeed a proxy's local policies can result in the=20 > information being anonymized (or removed if they can't=20 > anonymize) even in the "none" case.=20 >=20 > I do believe it's reasonable that we strongly recommend that=20 > the request level (versus specific hi-entries) not be used=20 > and if it is used, the consequence is that some services will=20 > not have the information they need - this was the gist of my=20 > previous response (to which I did not get any additional=20 > feedback). Now, we could add some text that the "none" > case SHOULD be used (e.g., added by first hop proxy) if it is=20 > desired that the information not be subject to privacy=20 > restrictions. I do not think it is then particularly useful=20 > to add logic around the proxy then being able to tag the=20 > entries within their domain as subject to privacy. > I think that conflicts with the intent of the request level "none". > However, as I mention above, per the current text, a proxy=20 > can (based on local policy) remove entries - so a proxy can=20 > capture hi within their domain and not forward any of that=20 > information to the next hop in another domain - you already=20 > have that functionality. But, I think this introduces the=20 > general problem that you might be impacting other services=20 > further down the line, which I thought was the problem you=20 > were wanting to solve - not specifically your example service=20 > but, for example, in the case that someone is debugging and=20 > they want the entire history, so depending upon the service,=20 > this is also undesirable behavior. =20 >=20 >=20 > Regards, > Mary.=20 >=20 > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, June 24, 2009 2:57 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy >=20 >=20 > Mary, >=20 > [I have added the list to this thread for wider comment.] >=20 > In the previous discussions I commented that in RFC4424 that=20 > a Privacy header with value "history" effectively makes all=20 > H-I entries private with the result that the H-I entries may=20 > be removed. >=20 > There has now been a comprehensive discussion on indication=20 > of the initial 'target' to the final recipient for call=20 > handling purposes. >=20 > The main use case related to a freephone example where the=20 > answering location may be a call centre where the original=20 > freephone number may be required for correct call handling. >=20 > If you now consider the following example (modified from=20 > Francois' text in the latest draft - excuse any errors that I=20 > may have inserted) >=20 > INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx > Privacy: history > History-Info: > ;index=3D1;rt;aor =20 > (1) > History-Info: ;index=3D1.1;mp;aor > (2) > History-Info: ;index=3D1.1.1;rc > (3) >=20 > In this case due to the Privacy header all of the H-I entries=20 > are considered private and the +18001234567 will not be=20 > delivered to the final destination with the result that call=20 > handling may not be correct. > The Privacy header may have been inserted by any of the nodes=20 > which routed the message and inserted a H-I entry. >=20 > If however the H-I was allowed to include a header parameter=20 > of "?Privacy=3Dnone" in the H-I entry and that an explicit H-I=20 > entry privacy value would be considered to have precedence=20 > over a Privacy header with a value of "history" then the=20 > mapping of the +18001234567 could be explicitly specified as=20 > not private and may be passed on. >=20 > Thus when the mapping from sip:+18001234567@example.com to=20 > sip:bob@biloxi.example.com when H-I entry (2) above is=20 > included could also insert the Privacy header parameter in=20 > H-I entry (1). >=20 > Thus the message would appear as follows: >=20 > INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx > Privacy: history > History-Info: > ;ind > ex=3D1;rt;ao > r > History-Info: ;index=3D1.1;mp;aor > History-Info: ;index=3D1.1.1;rc >=20 > This would result in all the H-I entries except (1) being=20 > considered private with the result that the =3D1800... Number=20 > is passed for call handling purposes. >=20 > This change is backward compatible with the existing=20 > implementation as any node using the existing functionality=20 > as defined in RFC4244 will continue to be supported. >=20 > The alternative is to remove the ability to include the value=20 > "history" > in the Privacy header and only allow this value in the=20 > Privacy header parameter. This alternative is not backward compatible. >=20 > Without this change a single node in the message path which=20 > includes a header "Privacy: history" will prevent delivery of=20 > the aor and thus prevent proper call handling. >=20 > Ian Elz >=20 >=20 >=20 > -----Original Message----- > From: Christer Holmberg > Sent: 23 June 2009 19:40 > To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg;=20 > Shida Schubert > Cc: Ian Elz > Subject: RE: 4244bis and privacy >=20 > =20 > Hi, >=20 > I include Ian, so he can comment to your resposne himself. >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Tuesday, June 23, 2009 9:40 PM > To: Christer Holmberg; Francois Audet; Hans Erik van Elburg;=20 > Shida Schubert > Subject: RE: 4244bis and privacy >=20 > Here was the thread of response and the last comment was from=20 > Ian that he would consider the response: > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html >=20 > And, there was not agreement on the "none" but rather to=20 > qualify the SHOULD NOT forward. However, in the=20 > sipcore-4244bis-00, rather than changing the text such that=20 > the headers SHOULD be removed, we recommend that they be=20 > anonymized (in section 4.3.3.3.1). That is entirely=20 > consistent with RFC 3324 and thus we have removed the=20 > recommendations to remove the headers entirely. However, that=20 > changed never got done in section 3.2, so we would need to=20 > change this: > "Thus, the History- Info header > SHOULD NOT be included in Requests where the requestor has=20 > indicated > a priv-value of Session- or Header-level privacy." >=20 > But, I'm really beginning to be of the mindset that we should=20 > just remove all the subsections of section 3 (i.e., leave the=20 > text in the upper level section), so we don't have to keep=20 > worrying about consistency. >=20 > So, lets either fixt the text in 3.2 or remove altogether and=20 > then I think we are really at the point of needing to submit=20 > this version so folks that actually have an interest in it=20 > can review the updated document.=20 >=20 > Mary.=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, June 23, 2009 1:10 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055);=20 > Hans Erik van Elburg; Shida Schubert > Subject: 4244bis and privacy >=20 >=20 > Hi, >=20 > Below is a comment/proposal which one of my collegues (Ian=20 > Elz) gave on the list a while ago, when the first version of=20 > 4244bis was submitted, but was not incorporated. Do you think=20 > it would be useful? >=20 > ------- >=20 > While the HI approach to target may solve the problem of=20 > being able to deliver the target URI to the final destination=20 > there is no guarantee that it will actually be delivered. >=20 > The problem arises with how Privacy is defined for HI. >=20 > 4424 defines a new Privacy value "history" which may be=20 > placed in either the Privacy header or as a header parameter=20 > to the HI entry. >=20 > If one node uses the former option "Privacy: history" then=20 > this will make all headers private and will result in all HI=20 > entries being removed or made anonymous when the message=20 > containing the HI is delivered to the user. >=20 > There is a simple solution to this and that is to also allow=20 > the use of the "none" Privacy value as a header parameter in=20 > the HI entry. This would explicitly state that no privacy is=20 > required to the HI entry and this would override a "history"=20 > value in the Privacy header. >=20 > I pointed this out to Mary when the 4424bis draft was first=20 > published but the change has not been made in the latest draft. >=20 > The change is backward compatible and would not cause an=20 > issue with any existing implementations. >=20 > ------ >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 From mary.barnes@nortel.com Thu Jun 25 10:17:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D3953A6960 for ; Thu, 25 Jun 2009 10:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.286 X-Spam-Level: X-Spam-Status: No, score=-6.286 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+JDdG92Q60H for ; Thu, 25 Jun 2009 10:17:57 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 3D4A03A6B1A for ; Thu, 25 Jun 2009 10:17:57 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5PGP0512536; Thu, 25 Jun 2009 16:25:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 11:28:50 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 4244bis and privacy thread-index: Acn0Lcc7X7sq6TfYRnWN9a4W8C0fHQAARIBQAADAA2AAGracUAAO1MaQAAH7tqAAAL/rAAAvtR7AAAMWtOA= References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Ian Elz" Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 17:17:59 -0000 Hi Ian, Responses inline below [MB2]. Mary. -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com]=20 Sent: Thursday, June 25, 2009 10:13 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Audet, Francois (SC100:3055) Subject: RE: 4244bis and privacy Mary, I am a little concerned about one answer that you gave: If you have a Privacy header with a value of "none" and a H-I entry with Privacy header parameter with value "history" what is the privacy of the individual H-I entry? [MB] We did not explicitly address the "none" in RFC 4244, but the general statement is the privacy headers at the request level override any at the hi-entry level. [/MB] =20 This means that if privacy is required for an individual H-I entry but the originating user included "Privacy:none" in the request then there is no option to include the real URI in the H-I entry. [MB2] I'm confused here - the "none" definition is as you note below, thus "none" prohibits the removal or anonymization of the entries, thus I would think you would fine this functionality desireable. However, this does not prohibit an entity based on policy to anonymize (or remove entries if privacy is required for that domain if the entity does not have access to a privacy service). [/MB2] This occurs as RFC3323 states in section 4.3: "However, if the Privacy header value of 'none' is specified in a message, privacy services MUST NOT perform any privacy function and MUST NOT remove or modify the Privacy header." The only option for an intermediate node including a H-I entry where "Privacy:none" is specified and privacy for the H-I URI is required is to include an anonymous entry or not include the H-I entry. [MB2] If privacy is required then yes, you include anonymous entries or don't include. That's the basic privacy mechanism for privacy levels of "session" "header" and "history" in the R-URI or "history" in the specific entries, as well as when there is a policy for privacy for the entries added by a specific domain. The "none" really has no influence on the later case per se. [/MB2] In your previous response you stated that we would violate RFC3323 if we specified additional behaviour for privacy explicitly stated with a URI -n the H-I entry. I don't believe that this is the case as RFC3323 only considered privacy in a two party scenario and did not consider third party identities being included in a message between two parties. H-I is not the only case where this occurs as the Referred-By header when included in the INVITE (or other request) which results from the REFER has the same issue. [MB2] I can't necessarily disagree on this one (we can debate it either way). But to fix it requires an update to RFC 3323 and shouldn't be something that we want to fix in 4244bis. [/MB2] RFC4244 was the first time that there was a recognition that privacy for these individual third party identities may be required. To allow this explicit statement of privacy to be overridden by a generic statement which is applicable to a different user is counterintuitive. [MB2] See my comment above. But, as I have consistently said, the idea that an entity might want to override the "none" is entirely based on policy and 4244 and 4244bis allow privacy to be applied to the entries that are added by that entity if the policy dictates so (and we already say that). [/MB2] The original Privacy header is usually included by or on behalf of the originating user and should not be allowed to specify the privacy of the original called user, e.g. the 800 number, and prevent this identity being presented if this user does not have the same level of privacy. [MB2] As I tried to say in a previous response, a random entity (i.e., one for whom the R-URI is not in a domain under its control) cannot add a privacy header to the Request. Per RFC 3323 an entity may add the header to a request only if it has the appropriate relationship/authorization with the original called user who intiated the request. And, I would find it very surprising if an entity that did have responsibility would apply privacy since that would be counter intuitive and I would hope that SPs would be judicious in specifying the appropriate and inappropriate manner in which the proxies they deploy and interface with privatize the messages. The protocol CANNOT control this behavior and that's why there is the policy clause in 4244 and 4244bis. [/MB2] =20 The real issue with the 800 scenario is as you have stated is that the answerer will not know the original called identity and will not be able to correctly handle the call. As more generic call centres are used which will answer calls on behalf of many different organizations using CTI and the original called identity to have to implement a generic system asking the caller who he originally called appear unprofessional, is inefficient and unproductive. [MB2] And, as I noted, it is rare for a call centre to route a call directly to an agent without a user providing some sort of input. Even companies like American Airlines, even though they have the info that I enter via the IVR, they still ask some basic questions and there are times when they have to reroute me. I don't think we can totally automate things. And, again, once the call hits the domain that is responsible for that 800 number the entities in that domain have control over how they muck with the R-URI, such that they should be able to use any IVR info to appropriately direct the call - it's not the number that's meaningful, but how the system gets the call to the right user and the additional information they provide as the call is presented to the agent. I would honestly think that having something other than an 800 number show up on the display would be far more useful and in my experience in the systems I developed we're usually talking about CTI interfaces so you have a lot you can do. And, actually all of this really doesn't matter in that you MUST be able to handle this situation independent of the privacy since History-Info is optional, you need default behavior assigned. [/MB2]=20 We have an opportunity to allow presentation of specific identities and to solve this particular problem so we should take it. [MB2] The most we can do is to document the risks/impacts of the use of the Privacy headers at the R-URI level. There is already general text in 4244 and 4244bis that the privacy may impact whether the applications get the information. And, as I noted before, most commercial systems are using B2BUAs which will allow you far more control over the use of the Privacy headers in the network. But, again, I don't think that's something that should be address in 4244bis. [/MB2] I hope that we can get some wider discussion on this issue so a more general consensus can be obtained. Regards Ian -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: 24 June 2009 17:27 To: Ian Elz Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Francois Audet Subject: RE: 4244bis and privacy Hi Ian, Responses inline below [MB]. Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Wednesday, June 24, 2009 10:37 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Audet, Francois (SC100:3055) Subject: RE: 4244bis and privacy Mary, I was not proposing that we change the handling of H-I which is based upon local policy. If that causes an issue for a network operator then they can modify their local policy accordingly or arrange with the proxy vendor to modify their equipment to be more flexible with regards to policy. Can you clarify for me: If you have a Privacy header with either "session" or "header" doe this impact the H-I entries or will only a value of "history" impact the H-I entries? [MB] Yes, both "session" and "header" level privacy, consistent with RFC 3323, mandate that entries be anonymized or dropped, with the latter being the recommendation for "session" level privacy. RFC 4244 mandated that they be dropped and 4244bis recommends they be anonymized. The original intent for the value of "history" was for the tagging of the individual entries, but you end up getting the header level functionality as well. [/MB]=20 If you have a Privacy header with a value of "none" and a H-I entry with Privacy header parameter with value "history" what is the privacy of the individual H-I entry? [MB] We did not explicitly address the "none" in RFC 4244, but the general statement is the privacy headers at the request level override any at the hi-entry level. [/MB] >From reading RFC4244 a Privacy header with value "history" will effectively make all H-I entries private and there is currently no option to include a H-I Privacy header parameter with value "none". [MB] Correct, per my comment above. [/MB] H-I at present allows the inclusion of Privacy header parameters to explicitly express privacy for an individual H-I entry but a single node which includes a header "Privacy: history" makes all H-I entries private even if this is not the requirements for the specific URI. [MB] Correct, but the only node that should add the header is a node which is responsible for the domain associated with the Request URI in the incoming request or is authorized to do so. [/MB] I will admit that having worked in a telephony environment for a long time I am used to having privacy of identities set on a per number basis and the relative inflexibility of the IETF Privacy header is relatively restrictive as to specifying which identities may be presented and which not. [MB] Yes, this is an entirely different paradigm. I developed telephony s/w for over a decade and this is entirely different - it provides a lot more flexibility, which makes things far, far less deterministic than what you have in telephony switches where your routing and translations are configured for the most part, with just a few capabilities for controlling the privacy and it's a closed network. =20 With RFC4244/4244bis, there MUST be a mechanism at the UAS or end application that can handle a request that doesn't have the appropriate information either because nodes didn't support History-Info or some random node in the network applied privacy (which I think is highly unlikely) - this is normative per section 5 of RFC 4244. So, the worst case scenario I see for this 800 service (which will get to the right UAS but without the exact 800 number that was dialed) is that it goes to a default ACD group/customer service agent, etc. who then needs to gather the appropriate information and in my experience this is often an IVR system these days. So, the service is not broken when privacy is applied in an undesireable manner, it's just not optimal. This is something that should be addressed in the target-uri draft which has all the details of how specific services use History-Info. One other thing to consider is that most networks that are emulating telephony type features use B2BUAs, which follow the UAS/UAC rules for the header rather than the proxy rules, noting that the UAC can set the Privacy header to whatever value it sees as appropriate for the request. [/MB] Regards=20 Ian -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: 24 June 2009 15:48 To: Ian Elz Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Francois Audet Subject: RE: 4244bis and privacy Hi Ian, I do not believe we should do the "override" behavior as I think that violates RFC 3323, as the "history" is really a subset of the cases whereby a UAC or proxy would add "session" or "header" to the request. And, the latter two cases have the same (undesireable) result. I agree this impacts your services, but we can't mandate that proxies provide information that might violate their local policies and indeed a proxy's local policies can result in the information being anonymized (or removed if they can't anonymize) even in the "none" case.=20 I do believe it's reasonable that we strongly recommend that the request level (versus specific hi-entries) not be used and if it is used, the consequence is that some services will not have the information they need - this was the gist of my previous response (to which I did not get any additional feedback). Now, we could add some text that the "none" case SHOULD be used (e.g., added by first hop proxy) if it is desired that the information not be subject to privacy restrictions. I do not think it is then particularly useful to add logic around the proxy then being able to tag the entries within their domain as subject to privacy. I think that conflicts with the intent of the request level "none". However, as I mention above, per the current text, a proxy can (based on local policy) remove entries - so a proxy can capture hi within their domain and not forward any of that information to the next hop in another domain - you already have that functionality. But, I think this introduces the general problem that you might be impacting other services further down the line, which I thought was the problem you were wanting to solve - not specifically your example service but, for example, in the case that someone is debugging and they want the entire history, so depending upon the service, this is also undesirable behavior. =20 Regards, Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Wednesday, June 24, 2009 2:57 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Audet, Francois (SC100:3055) Subject: RE: 4244bis and privacy Mary, [I have added the list to this thread for wider comment.] In the previous discussions I commented that in RFC4424 that a Privacy header with value "history" effectively makes all H-I entries private with the result that the H-I entries may be removed. There has now been a comprehensive discussion on indication of the initial 'target' to the final recipient for call handling purposes. The main use case related to a freephone example where the answering location may be a call centre where the original freephone number may be required for correct call handling. If you now consider the following example (modified from Francois' text in the latest draft - excuse any errors that I may have inserted) INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx Privacy: history History-Info: ;index=3D1;rt;aor = (1) History-Info: ;index=3D1.1;mp;aor (2) History-Info: ;index=3D1.1.1;rc (3) In this case due to the Privacy header all of the H-I entries are considered private and the +18001234567 will not be delivered to the final destination with the result that call handling may not be correct. The Privacy header may have been inserted by any of the nodes which routed the message and inserted a H-I entry. If however the H-I was allowed to include a header parameter of "?Privacy=3Dnone" in the H-I entry and that an explicit H-I entry = privacy value would be considered to have precedence over a Privacy header with a value of "history" then the mapping of the +18001234567 could be explicitly specified as not private and may be passed on. Thus when the mapping from sip:+18001234567@example.com to sip:bob@biloxi.example.com when H-I entry (2) above is included could also insert the Privacy header parameter in H-I entry (1). Thus the message would appear as follows: INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx Privacy: history History-Info: ;index=3D= 1;rt;ao r History-Info: ;index=3D1.1;mp;aor History-Info: ;index=3D1.1.1;rc This would result in all the H-I entries except (1) being considered private with the result that the =3D1800... Number is passed for call handling purposes. This change is backward compatible with the existing implementation as any node using the existing functionality as defined in RFC4244 will continue to be supported. The alternative is to remove the ability to include the value "history" in the Privacy header and only allow this value in the Privacy header parameter. This alternative is not backward compatible. Without this change a single node in the message path which includes a header "Privacy: history" will prevent delivery of the aor and thus prevent proper call handling. Ian Elz -----Original Message----- From: Christer Holmberg Sent: 23 June 2009 19:40 To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida Schubert Cc: Ian Elz Subject: RE: 4244bis and privacy =20 Hi, I include Ian, so he can comment to your resposne himself. Regards, Christer -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Tuesday, June 23, 2009 9:40 PM To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida Schubert Subject: RE: 4244bis and privacy Here was the thread of response and the last comment was from Ian that he would consider the response: http://www.ietf.org/mail-archive/web/sip/current/msg26948.html And, there was not agreement on the "none" but rather to qualify the SHOULD NOT forward. However, in the sipcore-4244bis-00, rather than changing the text such that the headers SHOULD be removed, we recommend that they be anonymized (in section 4.3.3.3.1). That is entirely consistent with RFC 3324 and thus we have removed the recommendations to remove the headers entirely. However, that changed never got done in section 3.2, so we would need to change this: "Thus, the History- Info header SHOULD NOT be included in Requests where the requestor has indicated a priv-value of Session- or Header-level privacy." But, I'm really beginning to be of the mindset that we should just remove all the subsections of section 3 (i.e., leave the text in the upper level section), so we don't have to keep worrying about consistency. So, lets either fixt the text in 3.2 or remove altogether and then I think we are really at the point of needing to submit this version so folks that actually have an interest in it can review the updated document.=20 Mary.=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, June 23, 2009 1:10 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik van Elburg; Shida Schubert Subject: 4244bis and privacy Hi, Below is a comment/proposal which one of my collegues (Ian Elz) gave on the list a while ago, when the first version of 4244bis was submitted, but was not incorporated. Do you think it would be useful? ------- While the HI approach to target may solve the problem of being able to deliver the target URI to the final destination there is no guarantee that it will actually be delivered. The problem arises with how Privacy is defined for HI. 4424 defines a new Privacy value "history" which may be placed in either the Privacy header or as a header parameter to the HI entry. If one node uses the former option "Privacy: history" then this will make all headers private and will result in all HI entries being removed or made anonymous when the message containing the HI is delivered to the user. There is a simple solution to this and that is to also allow the use of the "none" Privacy value as a header parameter in the HI entry. This would explicitly state that no privacy is required to the HI entry and this would override a "history" value in the Privacy header. I pointed this out to Mary when the 4424bis draft was first published but the change has not been made in the latest draft. The change is backward compatible and would not cause an issue with any existing implementations. ------ Regards, Christer From mary.barnes@nortel.com Thu Jun 25 11:09:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E6343A69C9 for ; Thu, 25 Jun 2009 11:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.99 X-Spam-Level: X-Spam-Status: No, score=-5.99 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twCPFLcc-HpG for ; Thu, 25 Jun 2009 11:09:42 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 3F2FF3A6A43 for ; Thu, 25 Jun 2009 11:09:23 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5PGsn516634; Thu, 25 Jun 2009 16:54:49 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 11:57:31 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EB26304@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EB2629A@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 4244bis and privacy thread-index: Acn0Lcc7X7sq6TfYRnWN9a4W8C0fHQAARIBQAADAA2AAGracUAAO1MaQAAH7tqAAAL/rAAAvtR7AAAMWtOAAATLMIAAAuBIw References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EB2629A@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Francois Audet" , "Ian Elz" Cc: sipcore@ietf.org, Shida Schubert Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 18:09:45 -0000 Yes. -----Original Message----- From: Audet, Francois (SC100:3055)=20 Sent: Thursday, June 25, 2009 11:37 AM To: Barnes, Mary (RICH2:AR00); 'Ian Elz' Cc: 'Christer Holmberg'; 'Hans Erik van Elburg'; 'Shida Schubert'; 'sipcore@ietf.org' Subject: RE: 4244bis and privacy So, let's say A calls B, B forwards to C. B has privacy turned on. A calls B. A history-info entry is added with sip:B. B retargets to C and sets privacy. I guess that would mean that B's proxy would have to parse the History-Info and anonymize all entries corresponding to B? Is this correct?=20 > -----Original Message----- > From: Barnes, Mary (RICH2:AR00) > Sent: Thursday, June 25, 2009 09:29 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy >=20 > Hi Ian, >=20 > Responses inline below [MB2]. >=20 > Mary. >=20 > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Thursday, June 25, 2009 10:13 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy >=20 > Mary, >=20 > I am a little concerned about one answer that you gave: >=20 >=20 > If you have a Privacy header with a value of "none" and a H-I entry=20 > with Privacy header parameter with value "history" what is the privacy > of the individual H-I entry? > [MB] We did not explicitly address the "none" in RFC 4244, but the=20 > general statement is the privacy headers at the request level override > any at the hi-entry level. [/MB] > =20 > This means that if privacy is required for an individual H-I entry but > the originating user included "Privacy:none" in the request then there > is no option to include the real URI in the H-I entry. > [MB2] I'm confused here - the "none" definition is as you note below,=20 > thus "none" prohibits the removal or anonymization of the entries,=20 > thus I would think you would fine this functionality desireable.=20 > However, this does not prohibit an entity based on policy to anonymize > (or remove entries if privacy is required for that domain if the=20 > entity does not have access to a privacy service). [/MB2] >=20 > This occurs as RFC3323 states in section 4.3: "However, if the Privacy > header value of 'none' is specified in a message, privacy services=20 > MUST NOT perform any privacy function and MUST NOT remove or modify=20 > the Privacy header." >=20 > The only option for an intermediate node including a H-I entry where=20 > "Privacy:none" is specified and privacy for the H-I URI is required is > to include an anonymous entry or not include the H-I entry. > [MB2] If privacy is required then yes, you include anonymous entries=20 > or don't include. That's the basic privacy mechanism for privacy=20 > levels of "session" "header" and "history" in the R-URI or "history"=20 > in the specific entries, as well as when there is a policy for privacy > for the entries added by a specific domain. The "none" really has no=20 > influence on the later case per se. [/MB2] >=20 > In your previous response you stated that we would violate > RFC3323 if we specified additional behaviour for privacy explicitly=20 > stated with a URI -n the H-I entry. I don't believe that this is the=20 > case as RFC3323 only considered privacy in a two party scenario and=20 > did not consider third party identities being included in a message=20 > between two parties. H-I is not the only case where this occurs as the > Referred-By header when included in the INVITE (or other > request) which results from the REFER has the same issue. > [MB2] I can't necessarily disagree on this one (we can debate it=20 > either way). But to fix it requires an update to RFC 3323 and=20 > shouldn't be something that we want to fix in 4244bis. [/MB2] >=20 > RFC4244 was the first time that there was a recognition that privacy=20 > for these individual third party identities may be required. To allow=20 > this explicit statement of privacy to be overridden by a generic=20 > statement which is applicable to a different user is counterintuitive. > [MB2] See my comment above. But, as I have consistently said, the idea > that an entity might want to override the "none" is entirely based on=20 > policy and 4244 and 4244bis allow privacy to be applied to the entries > that are added by that entity if the policy dictates so (and we=20 > already say that). [/MB2] >=20 > The original Privacy header is usually included by or on behalf of the > originating user and should not be allowed to specify the privacy of=20 > the original called user, e.g. the 800 number, and prevent this=20 > identity being presented if this user does not have the same level of=20 > privacy. > [MB2] As I tried to say in a previous response, a random entity (i.e., > one for whom the R-URI is not in a domain under its control) cannot=20 > add a privacy header to the Request. Per RFC 3323 an entity may add=20 > the header to a request only if it has the appropriate=20 > relationship/authorization with the original called user who intiated=20 > the request. And, I would find it very surprising if an entity that=20 > did have responsibility would apply privacy since that would be=20 > counter intuitive and I would hope that SPs would be judicious in=20 > specifying the appropriate and inappropriate manner in which the=20 > proxies they deploy and interface with privatize the messages. The=20 > protocol CANNOT control this behavior and that's why there is the=20 > policy clause in 4244 and 4244bis. [/MB2] >=20 > The real issue with the 800 scenario is as you have stated is that the > answerer will not know the original called identity and will not be=20 > able to correctly handle the call. As more generic call centres are=20 > used which will answer calls on behalf of many different organizations > using CTI and the original called identity to have to implement a=20 > generic system asking the caller who he originally called appear=20 > unprofessional, is inefficient and unproductive. > [MB2] And, as I noted, it is rare for a call centre to route a call=20 > directly to an agent without a user providing some sort of input. Even > companies like American Airlines, even though they have the info that=20 > I enter via the IVR, they still ask some basic questions and there are > times when they have to reroute me. I don't think we can totally=20 > automate things. And, again, once the call hits the domain that is=20 > responsible for that 800 number the entities in that domain have=20 > control over how they muck with the R-URI, such that they should be=20 > able to use any IVR info to appropriately direct the call - it's not=20 > the number that's meaningful, but how the system gets the call to the=20 > right user and the additional information they provide as the call is=20 > presented to the agent. I would honestly think that having something=20 > other than an 800 number show up on the display would be far more=20 > useful and in my experience in the systems I developed we're usually=20 > talking about CTI interfaces so you have a lot you can do. And,=20 > actually all of this really doesn't matter in that you MUST be able to > handle this situation independent of the privacy since History-Info is > optional, you need default behavior assigned. [/MB2] >=20 > We have an opportunity to allow presentation of specific identities=20 > and to solve this particular problem so we should take it. > [MB2] The most we can do is to document the risks/impacts of the use=20 > of the Privacy headers at the R-URI level. There is already general=20 > text in 4244 and 4244bis that the privacy may impact whether the=20 > applications get the information. And, as I noted before, most=20 > commercial systems are using B2BUAs which will allow you far more=20 > control over the use of the Privacy headers in the network. But,=20 > again, I don't think that's something that should be address in=20 > 4244bis. [/MB2] >=20 > I hope that we can get some wider discussion on this issue so a more=20 > general consensus can be obtained. >=20 > Regards >=20 > Ian >=20 >=20 >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 24 June 2009 17:27 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Francois Audet > Subject: RE: 4244bis and privacy >=20 > Hi Ian, >=20 > Responses inline below [MB]. >=20 > Mary.=20 >=20 > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, June 24, 2009 10:37 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy >=20 > Mary, >=20 > I was not proposing that we change the handling of H-I which is based=20 > upon local policy. If that causes an issue for a network operator then > they can modify their local policy accordingly or arrange with the=20 > proxy vendor to modify their equipment to be more flexible with=20 > regards to policy. >=20 > Can you clarify for me: >=20 > If you have a Privacy header with either "session" or "header" doe=20 > this impact the H-I entries or will only a value of "history" impact=20 > the H-I entries? > [MB] Yes, both "session" and "header" level privacy, consistent with=20 > RFC 3323, mandate that entries be anonymized or dropped, with the=20 > latter being the recommendation for "session" level privacy. RFC 4244=20 > mandated that they be dropped and 4244bis recommends they be=20 > anonymized. The original intent for the value of "history" was for the > tagging of the individual entries, but you end up getting the header=20 > level functionality as well. [/MB] >=20 > If you have a Privacy header with a value of "none" and a H-I entry=20 > with Privacy header parameter with value "history" what is the privacy > of the individual H-I entry? > [MB] We did not explicitly address the "none" in RFC 4244, but the=20 > general statement is the privacy headers at the request level override > any at the hi-entry level. [/MB] >=20 > From reading RFC4244 a Privacy header with value "history"=20 > will effectively make all H-I entries private and there is currently=20 > no option to include a H-I Privacy header parameter with value=20 > "none". > [MB] Correct, per my comment above. [/MB] >=20 > H-I at present allows the inclusion of Privacy header parameters to=20 > explicitly express privacy for an individual H-I entry but a single=20 > node which includes a header "Privacy: > history" makes all H-I entries private even if this is not the=20 > requirements for the specific URI. > [MB] Correct, but the only node that should add the header is a node=20 > which is responsible for the domain associated with the Request URI in > the incoming request or is authorized to do so. [/MB] >=20 > I will admit that having worked in a telephony environment for a long=20 > time I am used to having privacy of identities set on a per number=20 > basis and the relative inflexibility of the IETF Privacy header is=20 > relatively restrictive as to specifying which identities may be=20 > presented and which not. > [MB] Yes, this is an entirely different paradigm. I developed=20 > telephony s/w for over a decade and this is entirely different - it=20 > provides a lot more flexibility, which makes things far, far less=20 > deterministic than what you have in telephony switches where your=20 > routing and translations are configured for the most part, with just a > few capabilities for controlling the privacy and it's a closed=20 > network. >=20 > With RFC4244/4244bis, there MUST be a mechanism at the UAS or end=20 > application that can handle a request that doesn't have the=20 > appropriate information either because nodes didn't support=20 > History-Info or some random node in the network applied privacy (which > I think is highly > unlikely) - this is normative per section 5 of RFC 4244. So, the=20 > worst case scenario I see for this 800 service (which will get to the > right UAS but without the exact 800 number that was dialed) is that it > goes to a default ACD group/customer service agent, etc. who then=20 > needs to gather the appropriate information and in my experience this=20 > is often an IVR system these days. So, the service is not broken when > privacy is applied in an undesireable manner, it's just not optimal. =20 > This is something that should be addressed in the target-uri draft=20 > which has all the details of how specific services use History-Info. > One other thing to consider is that most networks that are emulating=20 > telephony type features use B2BUAs, which follow the UAS/UAC rules for > the header rather than the proxy rules, noting that the UAC can set=20 > the Privacy header to whatever value it sees as appropriate for the=20 > request. > [/MB] >=20 >=20 > Regards >=20 > Ian >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 24 June 2009 15:48 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Francois Audet > Subject: RE: 4244bis and privacy >=20 > Hi Ian, >=20 > I do not believe we should do the "override" behavior as I think that=20 > violates RFC 3323, as the "history" is really a subset of the cases=20 > whereby a UAC or proxy would add "session" or "header" to the request. > And, the latter two cases have the same (undesireable)=20 > result. I agree > this impacts your services, but we can't mandate that proxies provide=20 > information that might violate their local policies and indeed a=20 > proxy's local policies can result in the information being anonymized=20 > (or removed if they can't > anonymize) even in the "none" case.=20 >=20 > I do believe it's reasonable that we strongly recommend that the=20 > request level (versus specific hi-entries) not be used and if it is=20 > used, the consequence is that some services will not have the=20 > information they need - this was the gist of my previous response (to=20 > which I did not get any additional feedback). Now, we could add some=20 > text that the "none" > case SHOULD be used (e.g., added by first hop proxy) if it is desired=20 > that the information not be subject to privacy restrictions. I do not=20 > think it is then particularly useful to add logic around the proxy=20 > then being able to tag the entries within their domain as subject to=20 > privacy. > I think that conflicts with the intent of the request level "none". > However, as I mention above, per the current text, a proxy can (based=20 > on local policy) remove entries - so a proxy can capture hi within=20 > their domain and not forward any of that information to the next hop=20 > in another domain - you already have that functionality. But, I think > this introduces the general problem that you might be impacting other=20 > services further down the line, which I thought was the problem you=20 > were wanting to solve - not specifically your example service but, for > example, in the case that someone is debugging and they want the=20 > entire history, so depending upon the service, this is also=20 > undesirable behavior. >=20 >=20 > Regards, > Mary.=20 >=20 > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, June 24, 2009 2:57 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy >=20 >=20 > Mary, >=20 > [I have added the list to this thread for wider comment.] >=20 > In the previous discussions I commented that in RFC4424 that a Privacy > header with value "history" effectively makes all H-I entries private=20 > with the result that the H-I entries may be removed. >=20 > There has now been a comprehensive discussion on indication of the=20 > initial 'target' to the final recipient for call handling purposes. >=20 > The main use case related to a freephone example where the answering=20 > location may be a call centre where the original freephone number may=20 > be required for correct call handling. >=20 > If you now consider the following example (modified from Francois'=20 > text in the latest draft - excuse any errors that I may have inserted) >=20 > INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx > Privacy: history > History-Info: > ;index=3D1;rt;aor =20 > (1) > History-Info: ;index=3D1.1;mp;aor > (2) > History-Info: ;index=3D1.1.1;rc > (3) >=20 > In this case due to the Privacy header all of the H-I entries are=20 > considered private and the +18001234567 will not be delivered to the=20 > final destination with the result that call handling may not be=20 > correct. > The Privacy header may have been inserted by any of the nodes which=20 > routed the message and inserted a H-I entry. >=20 > If however the H-I was allowed to include a header parameter of=20 > "?Privacy=3Dnone" in the H-I entry and that an explicit H-I entry=20 > privacy value would be considered to have precedence over a Privacy=20 > header with a value of "history" then the mapping of the +18001234567=20 > could be explicitly specified as not private and may be passed on. >=20 > Thus when the mapping from sip:+18001234567@example.com to=20 > sip:bob@biloxi.example.com when H-I entry (2) above is included could=20 > also insert the Privacy header parameter in H-I entry (1). >=20 > Thus the message would appear as follows: >=20 > INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx > Privacy: history > History-Info: > ;ind > ex=3D1;rt;ao > r > History-Info: ;index=3D1.1;mp;aor > History-Info: ;index=3D1.1.1;rc >=20 > This would result in all the H-I entries except (1) being considered=20 > private with the result that the =3D1800... Number is passed for call=20 > handling purposes. >=20 > This change is backward compatible with the existing implementation as > any node using the existing functionality as defined in RFC4244 will=20 > continue to be supported. >=20 > The alternative is to remove the ability to include the value=20 > "history" > in the Privacy header and only allow this value in the Privacy header=20 > parameter. This alternative is not backward compatible. >=20 > Without this change a single node in the message path which includes a > header "Privacy: history" will prevent delivery of the aor and thus=20 > prevent proper call handling. >=20 > Ian Elz >=20 >=20 >=20 > -----Original Message----- > From: Christer Holmberg > Sent: 23 June 2009 19:40 > To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida=20 > Schubert > Cc: Ian Elz > Subject: RE: 4244bis and privacy >=20 > =20 > Hi, >=20 > I include Ian, so he can comment to your resposne himself. >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Tuesday, June 23, 2009 9:40 PM > To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida=20 > Schubert > Subject: RE: 4244bis and privacy >=20 > Here was the thread of response and the last comment was from Ian that > he would consider the response: > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html >=20 > And, there was not agreement on the "none" but rather to qualify the=20 > SHOULD NOT forward. However, in the sipcore-4244bis-00, rather than=20 > changing the text such that the headers SHOULD be removed, we=20 > recommend that they be anonymized (in section 4.3.3.3.1). That is=20 > entirely consistent with RFC 3324 and thus we have removed the=20 > recommendations to remove the headers entirely. However, that changed=20 > never got done in section 3.2, so we would need to change this: > "Thus, the History- Info header > SHOULD NOT be included in Requests where the requestor has=20 > indicated > a priv-value of Session- or Header-level privacy." >=20 > But, I'm really beginning to be of the mindset that we should just=20 > remove all the subsections of section 3 (i.e., leave the text in the=20 > upper level section), so we don't have to keep worrying about=20 > consistency. >=20 > So, lets either fixt the text in 3.2 or remove altogether and then I=20 > think we are really at the point of needing to submit this version so=20 > folks that actually have an interest in it can review the updated=20 > document. >=20 > Mary.=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, June 23, 2009 1:10 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik > van Elburg; Shida Schubert > Subject: 4244bis and privacy >=20 >=20 > Hi, >=20 > Below is a comment/proposal which one of my collegues (Ian > Elz) gave on the list a while ago, when the first version of 4244bis=20 > was submitted, but was not incorporated. Do you think it would be=20 > useful? >=20 > ------- >=20 > While the HI approach to target may solve the problem of being able to > deliver the target URI to the final destination there is no guarantee=20 > that it will actually be delivered. >=20 > The problem arises with how Privacy is defined for HI. >=20 > 4424 defines a new Privacy value "history" which may be placed in=20 > either the Privacy header or as a header parameter to the HI entry. >=20 > If one node uses the former option "Privacy: history" then this will=20 > make all headers private and will result in all HI entries being=20 > removed or made anonymous when the message containing the HI is=20 > delivered to the user. >=20 > There is a simple solution to this and that is to also allow the use=20 > of the "none" Privacy value as a header parameter in the HI entry.=20 > This would explicitly state that no privacy is required to the HI=20 > entry and this would override a "history" > value in the Privacy header. >=20 > I pointed this out to Mary when the 4424bis draft was first published=20 > but the change has not been made in the latest draft. >=20 > The change is backward compatible and would not cause an issue with=20 > any existing implementations. >=20 > ------ >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 From R.Jesske@telekom.de Thu Jun 25 12:22:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BB6028C0FD for ; Thu, 25 Jun 2009 12:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIXhbEAT-qeU for ; Thu, 25 Jun 2009 12:22:07 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 5F21D3A6976 for ; Thu, 25 Jun 2009 12:22:00 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 25 Jun 2009 21:13:43 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 21:13:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 21:13:41 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD4048F809B@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] 4244bis and privacy Thread-Index: Acn0Lcc7X7sq6TfYRnWN9a4W8C0fHQAARIBQAADAA2AAGracUAAO1MaQAAH7tqAAAL/rAAAvtR7AAAMWtOAABcee4A== References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com> From: To: , X-OriginalArrivalTime: 25 Jun 2009 19:13:43.0351 (UTC) FILETIME=[0E469C70:01C9F5C9] Cc: sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 19:22:09 -0000 Hi Marry and Ian, The whole discussion puzzle me. We have specified CDIV within TISPAN and = 3GPP.=20 There is described that privacy "none" can be used for entries. BUT = assuming that each entry has its own privacy statement if needed.=20 I fully agree on Mary's comment that a privacy "history" cannot = overruled by a privacy value "none" within a entry.=20 There may be operators that would like to keep the whole History Info = private even if entries has other statements, so the entity could add = privacy history to the whole header. Nothing more. On the other side a Application Server including a entry should have the = possibility to rewrite the entries so that instead of "history" for the = whole header the all received entries within the History-Info header = will be marked with "history" and the added header (which shall be = presented to the terminating user) will either be marked with "none" or = will not be marked. Perhaps a hint could be given, but I do not insist on it. Best Regards, Roland -----Urspr=FCngliche Nachricht----- Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im = Auftrag von Mary Barnes Gesendet: Donnerstag, 25. Juni 2009 18:29 An: Ian Elz Cc: sipcore@ietf.org; Shida Schubert Betreff: Re: [sipcore] 4244bis and privacy Hi Ian, Responses inline below [MB2]. Mary. -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com]=20 Sent: Thursday, June 25, 2009 10:13 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Audet, Francois (SC100:3055) Subject: RE: 4244bis and privacy Mary, I am a little concerned about one answer that you gave: If you have a Privacy header with a value of "none" and a H-I entry with Privacy header parameter with value "history" what is the privacy of the individual H-I entry? [MB] We did not explicitly address the "none" in RFC 4244, but the general statement is the privacy headers at the request level override any at the hi-entry level. [/MB] =20 This means that if privacy is required for an individual H-I entry but the originating user included "Privacy:none" in the request then there is no option to include the real URI in the H-I entry. [MB2] I'm confused here - the "none" definition is as you note below, thus "none" prohibits the removal or anonymization of the entries, thus I would think you would fine this functionality desireable. However, this does not prohibit an entity based on policy to anonymize (or remove entries if privacy is required for that domain if the entity does not have access to a privacy service). [/MB2] This occurs as RFC3323 states in section 4.3: "However, if the Privacy header value of 'none' is specified in a message, privacy services MUST NOT perform any privacy function and MUST NOT remove or modify the Privacy header." The only option for an intermediate node including a H-I entry where "Privacy:none" is specified and privacy for the H-I URI is required is to include an anonymous entry or not include the H-I entry. [MB2] If privacy is required then yes, you include anonymous entries or don't include. That's the basic privacy mechanism for privacy levels of "session" "header" and "history" in the R-URI or "history" in the specific entries, as well as when there is a policy for privacy for the entries added by a specific domain. The "none" really has no influence on the later case per se. [/MB2] In your previous response you stated that we would violate RFC3323 if we specified additional behaviour for privacy explicitly stated with a URI -n the H-I entry. I don't believe that this is the case as RFC3323 only considered privacy in a two party scenario and did not consider third party identities being included in a message between two parties. H-I is not the only case where this occurs as the Referred-By header when included in the INVITE (or other request) which results from the REFER has the same issue. [MB2] I can't necessarily disagree on this one (we can debate it either way). But to fix it requires an update to RFC 3323 and shouldn't be something that we want to fix in 4244bis. [/MB2] RFC4244 was the first time that there was a recognition that privacy for these individual third party identities may be required. To allow this explicit statement of privacy to be overridden by a generic statement which is applicable to a different user is counterintuitive. [MB2] See my comment above. But, as I have consistently said, the idea that an entity might want to override the "none" is entirely based on policy and 4244 and 4244bis allow privacy to be applied to the entries that are added by that entity if the policy dictates so (and we already say that). [/MB2] The original Privacy header is usually included by or on behalf of the originating user and should not be allowed to specify the privacy of the original called user, e.g. the 800 number, and prevent this identity being presented if this user does not have the same level of privacy. [MB2] As I tried to say in a previous response, a random entity (i.e., one for whom the R-URI is not in a domain under its control) cannot add a privacy header to the Request. Per RFC 3323 an entity may add the header to a request only if it has the appropriate relationship/authorization with the original called user who intiated the request. And, I would find it very surprising if an entity that did have responsibility would apply privacy since that would be counter intuitive and I would hope that SPs would be judicious in specifying the appropriate and inappropriate manner in which the proxies they deploy and interface with privatize the messages. The protocol CANNOT control this behavior and that's why there is the policy clause in 4244 and 4244bis. [/MB2] =20 The real issue with the 800 scenario is as you have stated is that the answerer will not know the original called identity and will not be able to correctly handle the call. As more generic call centres are used which will answer calls on behalf of many different organizations using CTI and the original called identity to have to implement a generic system asking the caller who he originally called appear unprofessional, is inefficient and unproductive. [MB2] And, as I noted, it is rare for a call centre to route a call directly to an agent without a user providing some sort of input. Even companies like American Airlines, even though they have the info that I enter via the IVR, they still ask some basic questions and there are times when they have to reroute me. I don't think we can totally automate things. And, again, once the call hits the domain that is responsible for that 800 number the entities in that domain have control over how they muck with the R-URI, such that they should be able to use any IVR info to appropriately direct the call - it's not the number that's meaningful, but how the system gets the call to the right user and the additional information they provide as the call is presented to the agent. I would honestly think that having something other than an 800 number show up on the display would be far more useful and in my experience in the systems I developed we're usually talking about CTI interfaces so you have a lot you can do. And, actually all of this really doesn't matter in that you MUST be able to handle this situation independent of the privacy since History-Info is optional, you need default behavior assigned. [/MB2]=20 We have an opportunity to allow presentation of specific identities and to solve this particular problem so we should take it. [MB2] The most we can do is to document the risks/impacts of the use of the Privacy headers at the R-URI level. There is already general text in 4244 and 4244bis that the privacy may impact whether the applications get the information. And, as I noted before, most commercial systems are using B2BUAs which will allow you far more control over the use of the Privacy headers in the network. But, again, I don't think that's something that should be address in 4244bis. [/MB2] I hope that we can get some wider discussion on this issue so a more general consensus can be obtained. Regards Ian -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: 24 June 2009 17:27 To: Ian Elz Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Francois Audet Subject: RE: 4244bis and privacy Hi Ian, Responses inline below [MB]. Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Wednesday, June 24, 2009 10:37 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Audet, Francois (SC100:3055) Subject: RE: 4244bis and privacy Mary, I was not proposing that we change the handling of H-I which is based upon local policy. If that causes an issue for a network operator then they can modify their local policy accordingly or arrange with the proxy vendor to modify their equipment to be more flexible with regards to policy. Can you clarify for me: If you have a Privacy header with either "session" or "header" doe this impact the H-I entries or will only a value of "history" impact the H-I entries? [MB] Yes, both "session" and "header" level privacy, consistent with RFC 3323, mandate that entries be anonymized or dropped, with the latter being the recommendation for "session" level privacy. RFC 4244 mandated that they be dropped and 4244bis recommends they be anonymized. The original intent for the value of "history" was for the tagging of the individual entries, but you end up getting the header level functionality as well. [/MB]=20 If you have a Privacy header with a value of "none" and a H-I entry with Privacy header parameter with value "history" what is the privacy of the individual H-I entry? [MB] We did not explicitly address the "none" in RFC 4244, but the general statement is the privacy headers at the request level override any at the hi-entry level. [/MB] >From reading RFC4244 a Privacy header with value "history" will effectively make all H-I entries private and there is currently no option to include a H-I Privacy header parameter with value "none". [MB] Correct, per my comment above. [/MB] H-I at present allows the inclusion of Privacy header parameters to explicitly express privacy for an individual H-I entry but a single node which includes a header "Privacy: history" makes all H-I entries private even if this is not the requirements for the specific URI. [MB] Correct, but the only node that should add the header is a node which is responsible for the domain associated with the Request URI in the incoming request or is authorized to do so. [/MB] I will admit that having worked in a telephony environment for a long time I am used to having privacy of identities set on a per number basis and the relative inflexibility of the IETF Privacy header is relatively restrictive as to specifying which identities may be presented and which not. [MB] Yes, this is an entirely different paradigm. I developed telephony s/w for over a decade and this is entirely different - it provides a lot more flexibility, which makes things far, far less deterministic than what you have in telephony switches where your routing and translations are configured for the most part, with just a few capabilities for controlling the privacy and it's a closed network. =20 With RFC4244/4244bis, there MUST be a mechanism at the UAS or end application that can handle a request that doesn't have the appropriate information either because nodes didn't support History-Info or some random node in the network applied privacy (which I think is highly unlikely) - this is normative per section 5 of RFC 4244. So, the worst case scenario I see for this 800 service (which will get to the right UAS but without the exact 800 number that was dialed) is that it goes to a default ACD group/customer service agent, etc. who then needs to gather the appropriate information and in my experience this is often an IVR system these days. So, the service is not broken when privacy is applied in an undesireable manner, it's just not optimal. This is something that should be addressed in the target-uri draft which has all the details of how specific services use History-Info. One other thing to consider is that most networks that are emulating telephony type features use B2BUAs, which follow the UAS/UAC rules for the header rather than the proxy rules, noting that the UAC can set the Privacy header to whatever value it sees as appropriate for the request. [/MB] Regards=20 Ian -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: 24 June 2009 15:48 To: Ian Elz Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Francois Audet Subject: RE: 4244bis and privacy Hi Ian, I do not believe we should do the "override" behavior as I think that violates RFC 3323, as the "history" is really a subset of the cases whereby a UAC or proxy would add "session" or "header" to the request. And, the latter two cases have the same (undesireable) result. I agree this impacts your services, but we can't mandate that proxies provide information that might violate their local policies and indeed a proxy's local policies can result in the information being anonymized (or removed if they can't anonymize) even in the "none" case.=20 I do believe it's reasonable that we strongly recommend that the request level (versus specific hi-entries) not be used and if it is used, the consequence is that some services will not have the information they need - this was the gist of my previous response (to which I did not get any additional feedback). Now, we could add some text that the "none" case SHOULD be used (e.g., added by first hop proxy) if it is desired that the information not be subject to privacy restrictions. I do not think it is then particularly useful to add logic around the proxy then being able to tag the entries within their domain as subject to privacy. I think that conflicts with the intent of the request level "none". However, as I mention above, per the current text, a proxy can (based on local policy) remove entries - so a proxy can capture hi within their domain and not forward any of that information to the next hop in another domain - you already have that functionality. But, I think this introduces the general problem that you might be impacting other services further down the line, which I thought was the problem you were wanting to solve - not specifically your example service but, for example, in the case that someone is debugging and they want the entire history, so depending upon the service, this is also undesirable behavior. =20 Regards, Mary.=20 -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Wednesday, June 24, 2009 2:57 AM To: Barnes, Mary (RICH2:AR00) Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; sipcore@ietf.org; Audet, Francois (SC100:3055) Subject: RE: 4244bis and privacy Mary, [I have added the list to this thread for wider comment.] In the previous discussions I commented that in RFC4424 that a Privacy header with value "history" effectively makes all H-I entries private with the result that the H-I entries may be removed. There has now been a comprehensive discussion on indication of the initial 'target' to the final recipient for call handling purposes. The main use case related to a freephone example where the answering location may be a call centre where the original freephone number may be required for correct call handling. If you now consider the following example (modified from Francois' text in the latest draft - excuse any errors that I may have inserted) INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx Privacy: history History-Info: ;index=3D1;rt;aor = (1) History-Info: ;index=3D1.1;mp;aor (2) History-Info: ;index=3D1.1.1;rc (3) In this case due to the Privacy header all of the H-I entries are considered private and the +18001234567 will not be delivered to the final destination with the result that call handling may not be correct. The Privacy header may have been inserted by any of the nodes which routed the message and inserted a H-I entry. If however the H-I was allowed to include a header parameter of "?Privacy=3Dnone" in the H-I entry and that an explicit H-I entry = privacy value would be considered to have precedence over a Privacy header with a value of "history" then the mapping of the +18001234567 could be explicitly specified as not private and may be passed on. Thus when the mapping from sip:+18001234567@example.com to sip:bob@biloxi.example.com when H-I entry (2) above is included could also insert the Privacy header parameter in H-I entry (1). Thus the message would appear as follows: INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx Privacy: history History-Info: ;index=3D= 1;rt;ao r History-Info: ;index=3D1.1;mp;aor History-Info: ;index=3D1.1.1;rc This would result in all the H-I entries except (1) being considered private with the result that the =3D1800... Number is passed for call handling purposes. This change is backward compatible with the existing implementation as any node using the existing functionality as defined in RFC4244 will continue to be supported. The alternative is to remove the ability to include the value "history" in the Privacy header and only allow this value in the Privacy header parameter. This alternative is not backward compatible. Without this change a single node in the message path which includes a header "Privacy: history" will prevent delivery of the aor and thus prevent proper call handling. Ian Elz -----Original Message----- From: Christer Holmberg Sent: 23 June 2009 19:40 To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida Schubert Cc: Ian Elz Subject: RE: 4244bis and privacy =20 Hi, I include Ian, so he can comment to your resposne himself. Regards, Christer -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: Tuesday, June 23, 2009 9:40 PM To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida Schubert Subject: RE: 4244bis and privacy Here was the thread of response and the last comment was from Ian that he would consider the response: http://www.ietf.org/mail-archive/web/sip/current/msg26948.html And, there was not agreement on the "none" but rather to qualify the SHOULD NOT forward. However, in the sipcore-4244bis-00, rather than changing the text such that the headers SHOULD be removed, we recommend that they be anonymized (in section 4.3.3.3.1). That is entirely consistent with RFC 3324 and thus we have removed the recommendations to remove the headers entirely. However, that changed never got done in section 3.2, so we would need to change this: "Thus, the History- Info header SHOULD NOT be included in Requests where the requestor has indicated a priv-value of Session- or Header-level privacy." But, I'm really beginning to be of the mindset that we should just remove all the subsections of section 3 (i.e., leave the text in the upper level section), so we don't have to keep worrying about consistency. So, lets either fixt the text in 3.2 or remove altogether and then I think we are really at the point of needing to submit this version so folks that actually have an interest in it can review the updated document.=20 Mary.=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, June 23, 2009 1:10 PM To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik van Elburg; Shida Schubert Subject: 4244bis and privacy Hi, Below is a comment/proposal which one of my collegues (Ian Elz) gave on the list a while ago, when the first version of 4244bis was submitted, but was not incorporated. Do you think it would be useful? ------- While the HI approach to target may solve the problem of being able to deliver the target URI to the final destination there is no guarantee that it will actually be delivered. The problem arises with how Privacy is defined for HI. 4424 defines a new Privacy value "history" which may be placed in either the Privacy header or as a header parameter to the HI entry. If one node uses the former option "Privacy: history" then this will make all headers private and will result in all HI entries being removed or made anonymous when the message containing the HI is delivered to the user. There is a simple solution to this and that is to also allow the use of the "none" Privacy value as a header parameter in the HI entry. This would explicitly state that no privacy is required to the HI entry and this would override a "history" value in the Privacy header. I pointed this out to Mary when the 4424bis draft was first published but the change has not been made in the latest draft. The change is backward compatible and would not cause an issue with any existing implementations. ------ Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From ietf.hanserik@gmail.com Thu Jun 25 13:33:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58D973A68EC for ; Thu, 25 Jun 2009 13:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UazfA25dBkt1 for ; Thu, 25 Jun 2009 13:33:40 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 591E23A67F2 for ; Thu, 25 Jun 2009 13:33:38 -0700 (PDT) Received: by ewy6 with SMTP id 6so2689109ewy.37 for ; Thu, 25 Jun 2009 13:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=vjftz17Rlm0tmQk8Zl960IScrwntp2SfiavHIhAE068=; b=R9DhTsAw+GhWFuywAqDnBqKXKOAA5bRDxeGuPBqvJZEEuoRGFLfZ4ErRzPvzEWeUoY QDf1g5wqKlNs3VUT5F3GhxX9ffm0ViEa7irJHovNa41uXCu7vX2tZqAXRAaiCGwR8c5A vU4DrvABMp7zIoKWVAZU2cpqS3wQlCtga1skE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=NQUHxTrsiLPtTnJFdPrQYDcw1MMNV3ZFS5XQRorR2PbhhXOAAoqF8Zi1QJBuPoGbUs K2ZfpBOE90U0fJvzAHkN1druLPzIder5oi05G7zzreWHX9M0JDFZjCVRLTkc2Ya2hJlO Q8fxM+/aBPYo8KUf1VbvsW8NTjNXoqKi8eZWQ= Received: by 10.210.79.3 with SMTP id c3mr3366425ebb.7.1245961931576; Thu, 25 Jun 2009 13:32:11 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 10sm9455eyd.18.2009.06.25.13.32.10 (version=SSLv3 cipher=RC4-MD5); Thu, 25 Jun 2009 13:32:11 -0700 (PDT) Message-ID: <4A43DEC9.1020802@gmail.com> Date: Thu, 25 Jun 2009 22:32:09 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: R.Jesske@telekom.de References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4048F809B@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4048F809B@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ian.elz@ericsson.com, sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 20:33:42 -0000 Hi Roland, I don't understand the argument, by the time that the History-Info leaves operator A that wishes complete privacy, all the History-Info headers should be anonymised according to 4244 and 4244bis. What is the point in mandating that operator A to force operator B to also anonymise the entries "owned" by operator B. It is of course without question that each operator has full privacy control over its own added entries. And each operator can based on local policy decide to remove the entire history if it things that is wise to do. /Hans Erik R.Jesske@telekom.de wrote: > Hi Marry and Ian, > The whole discussion puzzle me. We have specified CDIV within TISPAN and 3GPP. > There is described that privacy "none" can be used for entries. BUT assuming that each entry has its own privacy statement if needed. > I fully agree on Mary's comment that a privacy "history" cannot overruled by a privacy value "none" within a entry. > There may be operators that would like to keep the whole History Info private even if entries has other statements, so the entity could add privacy history to the whole header. Nothing more. > > On the other side a Application Server including a entry should have the possibility to rewrite the entries so that instead of "history" for the whole header the all received entries within the History-Info header will be marked with "history" and the added header (which shall be presented to the terminating user) will either be marked with "none" or will not be marked. > > Perhaps a hint could be given, but I do not insist on it. > > Best Regards, > > Roland > > > > -----Ursprüngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag von Mary Barnes > Gesendet: Donnerstag, 25. Juni 2009 18:29 > An: Ian Elz > Cc: sipcore@ietf.org; Shida Schubert > Betreff: Re: [sipcore] 4244bis and privacy > > Hi Ian, > > Responses inline below [MB2]. > > Mary. > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Thursday, June 25, 2009 10:13 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > Mary, > > I am a little concerned about one answer that you gave: > > > If you have a Privacy header with a value of "none" and a H-I entry with > Privacy header parameter with value "history" what is the privacy of the > individual H-I entry? > [MB] We did not explicitly address the "none" in RFC 4244, but the > general statement is the privacy headers at the request level override > any at the hi-entry level. [/MB] > > This means that if privacy is required for an individual H-I entry but > the originating user included "Privacy:none" in the request then there > is no option to include the real URI in the H-I entry. > [MB2] I'm confused here - the "none" definition is as you note below, > thus "none" prohibits the removal or anonymization of the entries, thus > I would think you would fine this functionality desireable. However, > this does not prohibit an entity based on policy to anonymize (or remove > entries if privacy is required for that domain if the entity does not > have access to a privacy service). [/MB2] > > This occurs as RFC3323 states in section 4.3: "However, if the Privacy > header value of 'none' is specified in a message, privacy services MUST > NOT perform any privacy function and MUST NOT remove or modify the > Privacy header." > > The only option for an intermediate node including a H-I entry where > "Privacy:none" is specified and privacy for the H-I URI is required is > to include an anonymous entry or not include the H-I entry. > [MB2] If privacy is required then yes, you include anonymous entries or > don't include. That's the basic privacy mechanism for privacy levels of > "session" "header" and "history" in the R-URI or "history" in the > specific entries, as well as when there is a policy for privacy for the > entries added by a specific domain. The "none" really has no influence > on the later case per se. [/MB2] > > In your previous response you stated that we would violate RFC3323 if we > specified additional behaviour for privacy explicitly stated with a URI > -n the H-I entry. I don't believe that this is the case as RFC3323 only > considered privacy in a two party scenario and did not consider third > party identities being included in a message between two parties. H-I is > not the only case where this occurs as the Referred-By header when > included in the INVITE (or other request) which results from the REFER > has the same issue. > [MB2] I can't necessarily disagree on this one (we can debate it either > way). But to fix it requires an update to RFC 3323 and shouldn't be > something that we want to fix in 4244bis. [/MB2] > > RFC4244 was the first time that there was a recognition that privacy for > these individual third party identities may be required. To allow this > explicit statement of privacy to be overridden by a generic statement > which is applicable to a different user is counterintuitive. > [MB2] See my comment above. But, as I have consistently said, the idea > that an entity might want to override the "none" is entirely based on > policy and 4244 and 4244bis allow privacy to be applied to the entries > that are added by that entity if the policy dictates so (and we already > say that). [/MB2] > > The original Privacy header is usually included by or on behalf of the > originating user and should not be allowed to specify the privacy of the > original called user, e.g. the 800 number, and prevent this identity > being presented if this user does not have the same level of privacy. > [MB2] As I tried to say in a previous response, a random entity (i.e., > one for whom the R-URI is not in a domain under its control) cannot add > a privacy header to the Request. Per RFC 3323 an entity may add the > header to a request only if it has the appropriate > relationship/authorization with the original called user who intiated > the request. And, I would find it very surprising if an entity that did > have responsibility would apply privacy since that would be counter > intuitive and I would hope that SPs would be judicious in specifying the > appropriate and inappropriate manner in which the proxies they deploy > and interface with privatize the messages. The protocol CANNOT control > this behavior and that's why there is the policy clause in 4244 and > 4244bis. [/MB2] > > The real issue with the 800 scenario is as you have stated is that the > answerer will not know the original called identity and will not be able > to correctly handle the call. As more generic call centres are used > which will answer calls on behalf of many different organizations using > CTI and the original called identity to have to implement a generic > system asking the caller who he originally called appear unprofessional, > is inefficient and unproductive. > [MB2] And, as I noted, it is rare for a call centre to route a call > directly to an agent without a user providing some sort of input. Even > companies like American Airlines, even though they have the info that I > enter via the IVR, they still ask some basic questions and there are > times when they have to reroute me. I don't think we can totally > automate things. And, again, once the call hits the domain that is > responsible for that 800 number the entities in that domain have control > over how they muck with the R-URI, such that they should be able to use > any IVR info to appropriately direct the call - it's not the number > that's meaningful, but how the system gets the call to the right user > and the additional information they provide as the call is presented to > the agent. I would honestly think that having something other than an > 800 number show up on the display would be far more useful and in my > experience in the systems I developed we're usually talking about CTI > interfaces so you have a lot you can do. And, actually all of this > really doesn't matter in that you MUST be able to handle this situation > independent of the privacy since History-Info is optional, you need > default behavior assigned. [/MB2] > > We have an opportunity to allow presentation of specific identities and > to solve this particular problem so we should take it. > [MB2] The most we can do is to document the risks/impacts of the use of > the Privacy headers at the R-URI level. There is already general text in > 4244 and 4244bis that the privacy may impact whether the applications > get the information. And, as I noted before, most commercial systems > are using B2BUAs which will allow you far more control over the use of > the Privacy headers in the network. But, again, I don't think that's > something that should be address in 4244bis. [/MB2] > > I hope that we can get some wider discussion on this issue so a more > general consensus can be obtained. > > Regards > > Ian > > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 24 June 2009 17:27 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > sipcore@ietf.org; Francois Audet > Subject: RE: 4244bis and privacy > > Hi Ian, > > Responses inline below [MB]. > > Mary. > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, June 24, 2009 10:37 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > Mary, > > I was not proposing that we change the handling of H-I which is based > upon local policy. If that causes an issue for a network operator then > they can modify their local policy accordingly or arrange with the proxy > vendor to modify their equipment to be more flexible with regards to > policy. > > Can you clarify for me: > > If you have a Privacy header with either "session" or "header" doe this > impact the H-I entries or will only a value of "history" impact the H-I > entries? > [MB] Yes, both "session" and "header" level privacy, consistent with RFC > 3323, mandate that entries be anonymized or dropped, with the latter > being the recommendation for "session" level privacy. RFC 4244 mandated > that they be dropped and 4244bis recommends they be anonymized. The > original intent for the value of "history" was for the tagging of the > individual entries, but you end up getting the header level > functionality as well. [/MB] > > If you have a Privacy header with a value of "none" and a H-I entry with > Privacy header parameter with value "history" what is the privacy of the > individual H-I entry? > [MB] We did not explicitly address the "none" in RFC 4244, but the > general statement is the privacy headers at the request level override > any at the hi-entry level. [/MB] > > From reading RFC4244 a Privacy header with value "history" will > effectively make all H-I entries private and there is currently no > option to include a H-I Privacy header parameter with value "none". > [MB] Correct, per my comment above. [/MB] > > H-I at present allows the inclusion of Privacy header parameters to > explicitly express privacy for an individual H-I entry but a single node > which includes a header "Privacy: history" makes all H-I entries private > even if this is not the requirements for the specific URI. > [MB] Correct, but the only node that should add the header is a node > which is responsible for the domain associated with the Request URI in > the incoming request or is authorized to do so. [/MB] > > I will admit that having worked in a telephony environment for a long > time I am used to having privacy of identities set on a per number basis > and the relative inflexibility of the IETF Privacy header is relatively > restrictive as to specifying which identities may be presented and which > not. > [MB] Yes, this is an entirely different paradigm. I developed telephony > s/w for over a decade and this is entirely different - it provides a lot > more flexibility, which makes things far, far less deterministic than > what you have in telephony switches where your routing and translations > are configured for the most part, with just a few capabilities for > controlling the privacy and it's a closed network. > > With RFC4244/4244bis, there MUST be a mechanism at the UAS or end > application that can handle a request that doesn't have the appropriate > information either because nodes didn't support History-Info or some > random node in the network applied privacy (which I think is highly > unlikely) - this is normative per section 5 of RFC 4244. So, the worst > case scenario I see for this 800 service (which will get to the right > UAS but without the exact 800 number that was dialed) is that it goes to > a default ACD group/customer service agent, etc. who then needs to > gather the appropriate information and in my experience this is often an > IVR system these days. So, the service is not broken when privacy is > applied in an undesireable manner, it's just not optimal. This is > something that should be addressed in the target-uri draft which has all > the details of how specific services use History-Info. > One other thing to consider is that most networks that are emulating > telephony type features use B2BUAs, which follow the UAS/UAC rules for > the header rather than the proxy rules, noting that the UAC can set the > Privacy header to whatever value it sees as appropriate for the request. > [/MB] > > > Regards > > Ian > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 24 June 2009 15:48 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > sipcore@ietf.org; Francois Audet > Subject: RE: 4244bis and privacy > > Hi Ian, > > I do not believe we should do the "override" behavior as I think that > violates RFC 3323, as the "history" is really a subset of the cases > whereby a UAC or proxy would add "session" or "header" to the request. > And, the latter two cases have the same (undesireable) result. I agree > this impacts your services, but we can't mandate that proxies provide > information that might violate their local policies and indeed a proxy's > local policies can result in the information being anonymized (or > removed if they can't anonymize) even in the "none" case. > > I do believe it's reasonable that we strongly recommend that the request > level (versus specific hi-entries) not be used and if it is used, the > consequence is that some services will not have the information they > need - this was the gist of my previous response (to which I did not get > any additional feedback). Now, we could add some text that the "none" > case SHOULD be used (e.g., added by first hop proxy) if it is desired > that the information not be subject to privacy restrictions. I do not > think it is then particularly useful to add logic around the proxy then > being able to tag the entries within their domain as subject to privacy. > I think that conflicts with the intent of the request level "none". > However, as I mention above, per the current text, a proxy can (based on > local policy) remove entries - so a proxy can capture hi within their > domain and not forward any of that information to the next hop in > another domain - you already have that functionality. But, I think this > introduces the general problem that you might be impacting other > services further down the line, which I thought was the problem you were > wanting to solve - not specifically your example service but, for > example, in the case that someone is debugging and they want the entire > history, so depending upon the service, this is also undesirable > behavior. > > > Regards, > Mary. > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, June 24, 2009 2:57 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > > Mary, > > [I have added the list to this thread for wider comment.] > > In the previous discussions I commented that in RFC4424 that a Privacy > header with value "history" effectively makes all H-I entries private > with the result that the H-I entries may be removed. > > There has now been a comprehensive discussion on indication of the > initial 'target' to the final recipient for call handling purposes. > > The main use case related to a freephone example where the answering > location may be a call centre where the original freephone number may be > required for correct call handling. > > If you now consider the following example (modified from Francois' text > in the latest draft - excuse any errors that I may have inserted) > > INVITE sip:sip:+18001234567@example.com;user=phone;p=x > Privacy: history > History-Info: > ;index=1;rt;aor (1) > History-Info: ;index=1.1;mp;aor > (2) > History-Info: ;index=1.1.1;rc > (3) > > In this case due to the Privacy header all of the H-I entries are > considered private and the +18001234567 will not be delivered to the > final destination with the result that call handling may not be correct. > The Privacy header may have been inserted by any of the nodes which > routed the message and inserted a H-I entry. > > If however the H-I was allowed to include a header parameter of > "?Privacy=none" in the H-I entry and that an explicit H-I entry privacy > value would be considered to have precedence over a Privacy header with > a value of "history" then the mapping of the +18001234567 could be > explicitly specified as not private and may be passed on. > > Thus when the mapping from sip:+18001234567@example.com to > sip:bob@biloxi.example.com when H-I entry (2) above is included could > also insert the Privacy header parameter in H-I entry (1). > > Thus the message would appear as follows: > > INVITE sip:sip:+18001234567@example.com; user=phone;p=x > Privacy: history > History-Info: > ;index=1;rt;ao > r > History-Info: ;index=1.1;mp;aor > History-Info: ;index=1.1.1;rc > > This would result in all the H-I entries except (1) being considered > private with the result that the =1800... Number is passed for call > handling purposes. > > This change is backward compatible with the existing implementation as > any node using the existing functionality as defined in RFC4244 will > continue to be supported. > > The alternative is to remove the ability to include the value "history" > in the Privacy header and only allow this value in the Privacy header > parameter. This alternative is not backward compatible. > > Without this change a single node in the message path which includes a > header "Privacy: history" will prevent delivery of the aor and thus > prevent proper call handling. > > Ian Elz > > > > -----Original Message----- > From: Christer Holmberg > Sent: 23 June 2009 19:40 > To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida Schubert > Cc: Ian Elz > Subject: RE: 4244bis and privacy > > > Hi, > > I include Ian, so he can comment to your resposne himself. > > Regards, > > Christer > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Tuesday, June 23, 2009 9:40 PM > To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida > Schubert > Subject: RE: 4244bis and privacy > > Here was the thread of response and the last comment was from Ian that > he would consider the response: > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html > > And, there was not agreement on the "none" but rather to qualify the > SHOULD NOT forward. However, in the sipcore-4244bis-00, rather than > changing the text such that the headers SHOULD be removed, we recommend > that they be anonymized (in section 4.3.3.3.1). That is entirely > consistent with RFC 3324 and thus we have removed the recommendations to > remove the headers entirely. However, that changed never got done in > section 3.2, so we would need to change this: > "Thus, the History- Info header > SHOULD NOT be included in Requests where the requestor has indicated > a priv-value of Session- or Header-level privacy." > > But, I'm really beginning to be of the mindset that we should just > remove all the subsections of section 3 (i.e., leave the text in the > upper level section), so we don't have to keep worrying about > consistency. > > So, lets either fixt the text in 3.2 or remove altogether and then I > think we are really at the point of needing to submit this version so > folks that actually have an interest in it can review the updated > document. > > Mary. > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, June 23, 2009 1:10 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik > van Elburg; Shida Schubert > Subject: 4244bis and privacy > > > Hi, > > Below is a comment/proposal which one of my collegues (Ian Elz) gave on > the list a while ago, when the first version of 4244bis was submitted, > but was not incorporated. Do you think it would be useful? > > ------- > > While the HI approach to target may solve the problem of being able to > deliver the target URI to the final destination there is no guarantee > that it will actually be delivered. > > The problem arises with how Privacy is defined for HI. > > 4424 defines a new Privacy value "history" which may be placed in either > the Privacy header or as a header parameter to the HI entry. > > If one node uses the former option "Privacy: history" then this will > make all headers private and will result in all HI entries being removed > or made anonymous when the message containing the HI is delivered to the > user. > > There is a simple solution to this and that is to also allow the use of > the "none" Privacy value as a header parameter in the HI entry. This > would explicitly state that no privacy is required to the HI entry and > this would override a "history" value in the Privacy header. > > I pointed this out to Mary when the 4424bis draft was first published > but the change has not been made in the latest draft. > > The change is backward compatible and would not cause an issue with any > existing implementations. > > ------ > > Regards, > > Christer > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From R.Jesske@telekom.de Thu Jun 25 14:32:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6168F3A6807 for ; Thu, 25 Jun 2009 14:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.762 X-Spam-Level: X-Spam-Status: No, score=-1.762 tagged_above=-999 required=5 tests=[AWL=1.488, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqthrRLo6-dM for ; Thu, 25 Jun 2009 14:32:54 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id CC5503A67A3 for ; Thu, 25 Jun 2009 14:32:51 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 25 Jun 2009 23:31:45 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 23:31:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 23:31:36 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD4048F80AC@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <4A43DEC9.1020802@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] 4244bis and privacy Thread-Index: Acn11AWR+Z7be2FAQvKtnWIFO4vfcAAB1KHQ References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4048F809B@S4DE8PSAAQB.mitte.t-com.de> <4A43DEC9.1020802@gmail.com> From: To: X-OriginalArrivalTime: 25 Jun 2009 21:31:38.0398 (UTC) FILETIME=[529693E0:01C9F5DC] Cc: ian.elz@ericsson.com, sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 21:32:56 -0000 Hi Hans Erik, We have also to take regulatory into consideration. In Germany the last = trusted network is responsible for anonymising information.=20 But nevertheless if Network provider A wants to have History completely = private this operator will set privacy history for the header. If the succeeding Operator want to present elements the AS which adds a = entry has then to re label all entries from the preceding network and = the entries from it's own network will be unmarked within the Header. But never the less I fully agree to your last sentence. The real Question is if this should really be allowed that a entry = marked with "none" overrules the privacy statement "history" for the = complete header. I'm against this behaviour.=20 Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Gesendet: Donnerstag, 25. Juni 2009 22:32 An: Jesske, Roland Cc: mary.barnes@nortel.com; ian.elz@ericsson.com; sipcore@ietf.org; = shida@agnada.com Betreff: Re: [sipcore] 4244bis and privacy Hi Roland, I don't understand the argument, by the time that the History-Info=20 leaves operator A that wishes complete privacy, all the History-Info=20 headers should be anonymised according to 4244 and 4244bis. What is the point in mandating that operator A to force operator B to=20 also anonymise the entries "owned" by operator B. It is of course without question that each operator has full privacy=20 control over its own added entries. And each operator can based on local = policy decide to remove the entire history if it things that is wise to = do. /Hans Erik R.Jesske@telekom.de wrote: > Hi Marry and Ian, > The whole discussion puzzle me. We have specified CDIV within TISPAN = and 3GPP.=20 > There is described that privacy "none" can be used for entries. BUT = assuming that each entry has its own privacy statement if needed.=20 > I fully agree on Mary's comment that a privacy "history" cannot = overruled by a privacy value "none" within a entry.=20 > There may be operators that would like to keep the whole History Info = private even if entries has other statements, so the entity could add = privacy history to the whole header. Nothing more. > > On the other side a Application Server including a entry should have = the possibility to rewrite the entries so that instead of "history" for = the whole header the all received entries within the History-Info header = will be marked with "history" and the added header (which shall be = presented to the terminating user) will either be marked with "none" or = will not be marked. > > Perhaps a hint could be given, but I do not insist on it. > > Best Regards, > > Roland > > > > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im = Auftrag von Mary Barnes > Gesendet: Donnerstag, 25. Juni 2009 18:29 > An: Ian Elz > Cc: sipcore@ietf.org; Shida Schubert > Betreff: Re: [sipcore] 4244bis and privacy > > Hi Ian, > > Responses inline below [MB2]. > > Mary. > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com]=20 > Sent: Thursday, June 25, 2009 10:13 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > Mary, > > I am a little concerned about one answer that you gave: > > > If you have a Privacy header with a value of "none" and a H-I entry = with > Privacy header parameter with value "history" what is the privacy of = the > individual H-I entry? > [MB] We did not explicitly address the "none" in RFC 4244, but the > general statement is the privacy headers at the request level override > any at the hi-entry level. [/MB] > =20 > This means that if privacy is required for an individual H-I entry but > the originating user included "Privacy:none" in the request then there > is no option to include the real URI in the H-I entry. > [MB2] I'm confused here - the "none" definition is as you note below, > thus "none" prohibits the removal or anonymization of the entries, = thus > I would think you would fine this functionality desireable. However, > this does not prohibit an entity based on policy to anonymize (or = remove > entries if privacy is required for that domain if the entity does not > have access to a privacy service). [/MB2] > > This occurs as RFC3323 states in section 4.3: "However, if the Privacy > header value of 'none' is specified in a message, privacy services = MUST > NOT perform any privacy function and MUST NOT remove or modify the > Privacy header." > > The only option for an intermediate node including a H-I entry where > "Privacy:none" is specified and privacy for the H-I URI is required is > to include an anonymous entry or not include the H-I entry. > [MB2] If privacy is required then yes, you include anonymous entries = or > don't include. That's the basic privacy mechanism for privacy levels = of > "session" "header" and "history" in the R-URI or "history" in the > specific entries, as well as when there is a policy for privacy for = the > entries added by a specific domain. The "none" really has no influence > on the later case per se. [/MB2] > > In your previous response you stated that we would violate RFC3323 if = we > specified additional behaviour for privacy explicitly stated with a = URI > -n the H-I entry. I don't believe that this is the case as RFC3323 = only > considered privacy in a two party scenario and did not consider third > party identities being included in a message between two parties. H-I = is > not the only case where this occurs as the Referred-By header when > included in the INVITE (or other request) which results from the REFER > has the same issue. > [MB2] I can't necessarily disagree on this one (we can debate it = either > way). But to fix it requires an update to RFC 3323 and shouldn't be > something that we want to fix in 4244bis. [/MB2] > > RFC4244 was the first time that there was a recognition that privacy = for > these individual third party identities may be required. To allow this > explicit statement of privacy to be overridden by a generic statement > which is applicable to a different user is counterintuitive. > [MB2] See my comment above. But, as I have consistently said, the idea > that an entity might want to override the "none" is entirely based on > policy and 4244 and 4244bis allow privacy to be applied to the entries > that are added by that entity if the policy dictates so (and we = already > say that). [/MB2] > > The original Privacy header is usually included by or on behalf of the > originating user and should not be allowed to specify the privacy of = the > original called user, e.g. the 800 number, and prevent this identity > being presented if this user does not have the same level of privacy. > [MB2] As I tried to say in a previous response, a random entity (i.e., > one for whom the R-URI is not in a domain under its control) cannot = add > a privacy header to the Request. Per RFC 3323 an entity may add the > header to a request only if it has the appropriate > relationship/authorization with the original called user who intiated > the request. And, I would find it very surprising if an entity that = did > have responsibility would apply privacy since that would be counter > intuitive and I would hope that SPs would be judicious in specifying = the > appropriate and inappropriate manner in which the proxies they deploy > and interface with privatize the messages. The protocol CANNOT control > this behavior and that's why there is the policy clause in 4244 and > 4244bis. [/MB2] =20 > > The real issue with the 800 scenario is as you have stated is that the > answerer will not know the original called identity and will not be = able > to correctly handle the call. As more generic call centres are used > which will answer calls on behalf of many different organizations = using > CTI and the original called identity to have to implement a generic > system asking the caller who he originally called appear = unprofessional, > is inefficient and unproductive. > [MB2] And, as I noted, it is rare for a call centre to route a call > directly to an agent without a user providing some sort of input. Even > companies like American Airlines, even though they have the info that = I > enter via the IVR, they still ask some basic questions and there are > times when they have to reroute me. I don't think we can totally > automate things. And, again, once the call hits the domain that is > responsible for that 800 number the entities in that domain have = control > over how they muck with the R-URI, such that they should be able to = use > any IVR info to appropriately direct the call - it's not the number > that's meaningful, but how the system gets the call to the right user > and the additional information they provide as the call is presented = to > the agent. I would honestly think that having something other than an > 800 number show up on the display would be far more useful and in my > experience in the systems I developed we're usually talking about CTI > interfaces so you have a lot you can do. And, actually all of this > really doesn't matter in that you MUST be able to handle this = situation > independent of the privacy since History-Info is optional, you need > default behavior assigned. [/MB2]=20 > > We have an opportunity to allow presentation of specific identities = and > to solve this particular problem so we should take it. > [MB2] The most we can do is to document the risks/impacts of the use = of > the Privacy headers at the R-URI level. There is already general text = in > 4244 and 4244bis that the privacy may impact whether the applications > get the information. And, as I noted before, most commercial systems > are using B2BUAs which will allow you far more control over the use of > the Privacy headers in the network. But, again, I don't think that's > something that should be address in 4244bis. [/MB2] > > I hope that we can get some wider discussion on this issue so a more > general consensus can be obtained. > > Regards > > Ian > > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 24 June 2009 17:27 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > sipcore@ietf.org; Francois Audet > Subject: RE: 4244bis and privacy > > Hi Ian, > > Responses inline below [MB]. > > Mary.=20 > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, June 24, 2009 10:37 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > Mary, > > I was not proposing that we change the handling of H-I which is based > upon local policy. If that causes an issue for a network operator then > they can modify their local policy accordingly or arrange with the = proxy > vendor to modify their equipment to be more flexible with regards to > policy. > > Can you clarify for me: > > If you have a Privacy header with either "session" or "header" doe = this > impact the H-I entries or will only a value of "history" impact the = H-I > entries? > [MB] Yes, both "session" and "header" level privacy, consistent with = RFC > 3323, mandate that entries be anonymized or dropped, with the latter > being the recommendation for "session" level privacy. RFC 4244 = mandated > that they be dropped and 4244bis recommends they be anonymized. The > original intent for the value of "history" was for the tagging of the > individual entries, but you end up getting the header level > functionality as well. [/MB]=20 > > If you have a Privacy header with a value of "none" and a H-I entry = with > Privacy header parameter with value "history" what is the privacy of = the > individual H-I entry? > [MB] We did not explicitly address the "none" in RFC 4244, but the > general statement is the privacy headers at the request level override > any at the hi-entry level. [/MB] > > From reading RFC4244 a Privacy header with value "history" will > effectively make all H-I entries private and there is currently no > option to include a H-I Privacy header parameter with value "none". > [MB] Correct, per my comment above. [/MB] > > H-I at present allows the inclusion of Privacy header parameters to > explicitly express privacy for an individual H-I entry but a single = node > which includes a header "Privacy: history" makes all H-I entries = private > even if this is not the requirements for the specific URI. > [MB] Correct, but the only node that should add the header is a node > which is responsible for the domain associated with the Request URI in > the incoming request or is authorized to do so. [/MB] > > I will admit that having worked in a telephony environment for a long > time I am used to having privacy of identities set on a per number = basis > and the relative inflexibility of the IETF Privacy header is = relatively > restrictive as to specifying which identities may be presented and = which > not. > [MB] Yes, this is an entirely different paradigm. I developed = telephony > s/w for over a decade and this is entirely different - it provides a = lot > more flexibility, which makes things far, far less deterministic than > what you have in telephony switches where your routing and = translations > are configured for the most part, with just a few capabilities for > controlling the privacy and it's a closed network. =20 > > With RFC4244/4244bis, there MUST be a mechanism at the UAS or end > application that can handle a request that doesn't have the = appropriate > information either because nodes didn't support History-Info or some > random node in the network applied privacy (which I think is highly > unlikely) - this is normative per section 5 of RFC 4244. So, the = worst > case scenario I see for this 800 service (which will get to the right > UAS but without the exact 800 number that was dialed) is that it goes = to > a default ACD group/customer service agent, etc. who then needs to > gather the appropriate information and in my experience this is often = an > IVR system these days. So, the service is not broken when privacy is > applied in an undesireable manner, it's just not optimal. This is > something that should be addressed in the target-uri draft which has = all > the details of how specific services use History-Info. > One other thing to consider is that most networks that are emulating > telephony type features use B2BUAs, which follow the UAS/UAC rules for > the header rather than the proxy rules, noting that the UAC can set = the > Privacy header to whatever value it sees as appropriate for the = request. > [/MB] > > > Regards=20 > > Ian > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 24 June 2009 15:48 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > sipcore@ietf.org; Francois Audet > Subject: RE: 4244bis and privacy > > Hi Ian, > > I do not believe we should do the "override" behavior as I think that > violates RFC 3323, as the "history" is really a subset of the cases > whereby a UAC or proxy would add "session" or "header" to the request. > And, the latter two cases have the same (undesireable) result. I = agree > this impacts your services, but we can't mandate that proxies provide > information that might violate their local policies and indeed a = proxy's > local policies can result in the information being anonymized (or > removed if they can't anonymize) even in the "none" case.=20 > > I do believe it's reasonable that we strongly recommend that the = request > level (versus specific hi-entries) not be used and if it is used, the > consequence is that some services will not have the information they > need - this was the gist of my previous response (to which I did not = get > any additional feedback). Now, we could add some text that the "none" > case SHOULD be used (e.g., added by first hop proxy) if it is desired > that the information not be subject to privacy restrictions. I do not > think it is then particularly useful to add logic around the proxy = then > being able to tag the entries within their domain as subject to = privacy. > I think that conflicts with the intent of the request level "none". > However, as I mention above, per the current text, a proxy can (based = on > local policy) remove entries - so a proxy can capture hi within their > domain and not forward any of that information to the next hop in > another domain - you already have that functionality. But, I think = this > introduces the general problem that you might be impacting other > services further down the line, which I thought was the problem you = were > wanting to solve - not specifically your example service but, for > example, in the case that someone is debugging and they want the = entire > history, so depending upon the service, this is also undesirable > behavior. =20 > > > Regards, > Mary.=20 > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, June 24, 2009 2:57 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert; > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > > Mary, > > [I have added the list to this thread for wider comment.] > > In the previous discussions I commented that in RFC4424 that a Privacy > header with value "history" effectively makes all H-I entries private > with the result that the H-I entries may be removed. > > There has now been a comprehensive discussion on indication of the > initial 'target' to the final recipient for call handling purposes. > > The main use case related to a freephone example where the answering > location may be a call centre where the original freephone number may = be > required for correct call handling. > > If you now consider the following example (modified from Francois' = text > in the latest draft - excuse any errors that I may have inserted) > > INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx > Privacy: history > History-Info: > ;index=3D1;rt;aor = (1) > History-Info: ;index=3D1.1;mp;aor > (2) > History-Info: ;index=3D1.1.1;rc > (3) > > In this case due to the Privacy header all of the H-I entries are > considered private and the +18001234567 will not be delivered to the > final destination with the result that call handling may not be = correct. > The Privacy header may have been inserted by any of the nodes which > routed the message and inserted a H-I entry. > > If however the H-I was allowed to include a header parameter of > "?Privacy=3Dnone" in the H-I entry and that an explicit H-I entry = privacy > value would be considered to have precedence over a Privacy header = with > a value of "history" then the mapping of the +18001234567 could be > explicitly specified as not private and may be passed on. > > Thus when the mapping from sip:+18001234567@example.com to > sip:bob@biloxi.example.com when H-I entry (2) above is included could > also insert the Privacy header parameter in H-I entry (1). > > Thus the message would appear as follows: > > INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx > Privacy: history > History-Info: > = ;index=3D= 1;rt;ao > r > History-Info: ;index=3D1.1;mp;aor > History-Info: ;index=3D1.1.1;rc > > This would result in all the H-I entries except (1) being considered > private with the result that the =3D1800... Number is passed for call > handling purposes. > > This change is backward compatible with the existing implementation as > any node using the existing functionality as defined in RFC4244 will > continue to be supported. > > The alternative is to remove the ability to include the value = "history" > in the Privacy header and only allow this value in the Privacy header > parameter. This alternative is not backward compatible. > > Without this change a single node in the message path which includes a > header "Privacy: history" will prevent delivery of the aor and thus > prevent proper call handling. > > Ian Elz > > > > -----Original Message----- > From: Christer Holmberg > Sent: 23 June 2009 19:40 > To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida = Schubert > Cc: Ian Elz > Subject: RE: 4244bis and privacy > > =20 > Hi, > > I include Ian, so he can comment to your resposne himself. > > Regards, > > Christer > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Tuesday, June 23, 2009 9:40 PM > To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida > Schubert > Subject: RE: 4244bis and privacy > > Here was the thread of response and the last comment was from Ian that > he would consider the response: > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html > > And, there was not agreement on the "none" but rather to qualify the > SHOULD NOT forward. However, in the sipcore-4244bis-00, rather than > changing the text such that the headers SHOULD be removed, we = recommend > that they be anonymized (in section 4.3.3.3.1). That is entirely > consistent with RFC 3324 and thus we have removed the recommendations = to > remove the headers entirely. However, that changed never got done in > section 3.2, so we would need to change this: > "Thus, the History- Info header > SHOULD NOT be included in Requests where the requestor has = indicated > a priv-value of Session- or Header-level privacy." > > But, I'm really beginning to be of the mindset that we should just > remove all the subsections of section 3 (i.e., leave the text in the > upper level section), so we don't have to keep worrying about > consistency. > > So, lets either fixt the text in 3.2 or remove altogether and then I > think we are really at the point of needing to submit this version so > folks that actually have an interest in it can review the updated > document.=20 > > Mary.=20 > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, June 23, 2009 1:10 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik > van Elburg; Shida Schubert > Subject: 4244bis and privacy > > > Hi, > > Below is a comment/proposal which one of my collegues (Ian Elz) gave = on > the list a while ago, when the first version of 4244bis was submitted, > but was not incorporated. Do you think it would be useful? > > ------- > > While the HI approach to target may solve the problem of being able to > deliver the target URI to the final destination there is no guarantee > that it will actually be delivered. > > The problem arises with how Privacy is defined for HI. > > 4424 defines a new Privacy value "history" which may be placed in = either > the Privacy header or as a header parameter to the HI entry. > > If one node uses the former option "Privacy: history" then this will > make all headers private and will result in all HI entries being = removed > or made anonymous when the message containing the HI is delivered to = the > user. > > There is a simple solution to this and that is to also allow the use = of > the "none" Privacy value as a header parameter in the HI entry. This > would explicitly state that no privacy is required to the HI entry and > this would override a "history" value in the Privacy header. > > I pointed this out to Mary when the 4424bis draft was first published > but the change has not been made in the latest draft. > > The change is backward compatible and would not cause an issue with = any > existing implementations. > > ------ > > Regards, > > Christer > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > =20 From mary.barnes@nortel.com Thu Jun 25 14:35:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 137DA3A695F for ; Thu, 25 Jun 2009 14:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.29 X-Spam-Level: X-Spam-Status: No, score=-6.29 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rvyzKhADYmy for ; Thu, 25 Jun 2009 14:35:28 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 628263A68EC for ; Thu, 25 Jun 2009 14:35:28 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5PLVX504770; Thu, 25 Jun 2009 21:31:33 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 16:34:48 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EB26A79@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A43DEC9.1020802@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] 4244bis and privacy thread-index: Acn11Ac/JM5AVTb5RlaHyFu0d+s73AACBAng References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4048F809B@S4DE8PSAAQB.mitte.t-com.de> <4A43DEC9.1020802@gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" , Cc: ian.elz@ericsson.com, sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 21:35:31 -0000 I agree with Hans and the important point is the last statement. A proxy = can add as many entries as they want within their domain(s) of = responsibility, it's when that message leaves that domain, that the = message MUST follow the RFC 3323 rules for the message. And, I do think = the issues being discussed are more with how RFC 3323 is specified than = with the use of privacy in 4244/4244bis. We reference RFC 3323 and I = think it would cause more problems than it would help to try to pull in = more detail as to how that works with History-Info. To me, that's more = something that the applications must consider and I believe we have = enough information in the document currently telling them such. The best = approach IMHO would be to add some of the examples we have been = discussing to the target-uri document which describes how you can = realize these services using the core SIP building blocks of = 4244/4244bis and RFC 3323. =20 Regards, Mary.=20 -----Original Message----- From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, June 25, 2009 3:32 PM To: R.Jesske@telekom.de Cc: Barnes, Mary (RICH2:AR00); ian.elz@ericsson.com; sipcore@ietf.org; = shida@agnada.com Subject: Re: [sipcore] 4244bis and privacy Hi Roland, I don't understand the argument, by the time that the History-Info = leaves operator A that wishes complete privacy, all the History-Info = headers should be anonymised according to 4244 and 4244bis. What is the point in mandating that operator A to force operator B to = also anonymise the entries "owned" by operator B. It is of course without question that each operator has full privacy = control over its own added entries. And each operator can based on local = policy decide to remove the entire history if it things that is wise to = do. /Hans Erik R.Jesske@telekom.de wrote: > Hi Marry and Ian, > The whole discussion puzzle me. We have specified CDIV within TISPAN = and 3GPP.=20 > There is described that privacy "none" can be used for entries. BUT = assuming that each entry has its own privacy statement if needed.=20 > I fully agree on Mary's comment that a privacy "history" cannot = overruled by a privacy value "none" within a entry.=20 > There may be operators that would like to keep the whole History Info = private even if entries has other statements, so the entity could add = privacy history to the whole header. Nothing more. > > On the other side a Application Server including a entry should have = the possibility to rewrite the entries so that instead of "history" for = the whole header the all received entries within the History-Info header = will be marked with "history" and the added header (which shall be = presented to the terminating user) will either be marked with "none" or = will not be marked. > > Perhaps a hint could be given, but I do not insist on it. > > Best Regards, > > Roland > > > > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im=20 > Auftrag von Mary Barnes > Gesendet: Donnerstag, 25. Juni 2009 18:29 > An: Ian Elz > Cc: sipcore@ietf.org; Shida Schubert > Betreff: Re: [sipcore] 4244bis and privacy > > Hi Ian, > > Responses inline below [MB2]. > > Mary. > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Thursday, June 25, 2009 10:13 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > Mary, > > I am a little concerned about one answer that you gave: > > > If you have a Privacy header with a value of "none" and a H-I entry=20 > with Privacy header parameter with value "history" what is the privacy = > of the individual H-I entry? > [MB] We did not explicitly address the "none" in RFC 4244, but the=20 > general statement is the privacy headers at the request level override = > any at the hi-entry level. [/MB] > =20 > This means that if privacy is required for an individual H-I entry but = > the originating user included "Privacy:none" in the request then there = > is no option to include the real URI in the H-I entry. > [MB2] I'm confused here - the "none" definition is as you note below,=20 > thus "none" prohibits the removal or anonymization of the entries,=20 > thus I would think you would fine this functionality desireable.=20 > However, this does not prohibit an entity based on policy to anonymize = > (or remove entries if privacy is required for that domain if the=20 > entity does not have access to a privacy service). [/MB2] > > This occurs as RFC3323 states in section 4.3: "However, if the Privacy = > header value of 'none' is specified in a message, privacy services=20 > MUST NOT perform any privacy function and MUST NOT remove or modify=20 > the Privacy header." > > The only option for an intermediate node including a H-I entry where=20 > "Privacy:none" is specified and privacy for the H-I URI is required is = > to include an anonymous entry or not include the H-I entry. > [MB2] If privacy is required then yes, you include anonymous entries=20 > or don't include. That's the basic privacy mechanism for privacy=20 > levels of "session" "header" and "history" in the R-URI or "history"=20 > in the specific entries, as well as when there is a policy for privacy = > for the entries added by a specific domain. The "none" really has no=20 > influence on the later case per se. [/MB2] > > In your previous response you stated that we would violate RFC3323 if=20 > we specified additional behaviour for privacy explicitly stated with a = > URI -n the H-I entry. I don't believe that this is the case as RFC3323 = > only considered privacy in a two party scenario and did not consider=20 > third party identities being included in a message between two=20 > parties. H-I is not the only case where this occurs as the Referred-By = > header when included in the INVITE (or other request) which results=20 > from the REFER has the same issue. > [MB2] I can't necessarily disagree on this one (we can debate it=20 > either way). But to fix it requires an update to RFC 3323 and=20 > shouldn't be something that we want to fix in 4244bis. [/MB2] > > RFC4244 was the first time that there was a recognition that privacy=20 > for these individual third party identities may be required. To allow=20 > this explicit statement of privacy to be overridden by a generic=20 > statement which is applicable to a different user is counterintuitive. > [MB2] See my comment above. But, as I have consistently said, the idea = > that an entity might want to override the "none" is entirely based on=20 > policy and 4244 and 4244bis allow privacy to be applied to the entries = > that are added by that entity if the policy dictates so (and we=20 > already say that). [/MB2] > > The original Privacy header is usually included by or on behalf of the = > originating user and should not be allowed to specify the privacy of=20 > the original called user, e.g. the 800 number, and prevent this=20 > identity being presented if this user does not have the same level of = privacy. > [MB2] As I tried to say in a previous response, a random entity (i.e., = > one for whom the R-URI is not in a domain under its control) cannot=20 > add a privacy header to the Request. Per RFC 3323 an entity may add=20 > the header to a request only if it has the appropriate=20 > relationship/authorization with the original called user who intiated=20 > the request. And, I would find it very surprising if an entity that=20 > did have responsibility would apply privacy since that would be=20 > counter intuitive and I would hope that SPs would be judicious in=20 > specifying the appropriate and inappropriate manner in which the=20 > proxies they deploy and interface with privatize the messages. The=20 > protocol CANNOT control this behavior and that's why there is the=20 > policy clause in 4244 and 4244bis. [/MB2] > > The real issue with the 800 scenario is as you have stated is that the = > answerer will not know the original called identity and will not be=20 > able to correctly handle the call. As more generic call centres are=20 > used which will answer calls on behalf of many different organizations = > using CTI and the original called identity to have to implement a=20 > generic system asking the caller who he originally called appear=20 > unprofessional, is inefficient and unproductive. > [MB2] And, as I noted, it is rare for a call centre to route a call=20 > directly to an agent without a user providing some sort of input. Even = > companies like American Airlines, even though they have the info that=20 > I enter via the IVR, they still ask some basic questions and there are = > times when they have to reroute me. I don't think we can totally=20 > automate things. And, again, once the call hits the domain that is=20 > responsible for that 800 number the entities in that domain have=20 > control over how they muck with the R-URI, such that they should be=20 > able to use any IVR info to appropriately direct the call - it's not=20 > the number that's meaningful, but how the system gets the call to the=20 > right user and the additional information they provide as the call is=20 > presented to the agent. I would honestly think that having something=20 > other than an 800 number show up on the display would be far more=20 > useful and in my experience in the systems I developed we're usually=20 > talking about CTI interfaces so you have a lot you can do. And,=20 > actually all of this really doesn't matter in that you MUST be able to = > handle this situation independent of the privacy since History-Info is = > optional, you need default behavior assigned. [/MB2] > > We have an opportunity to allow presentation of specific identities=20 > and to solve this particular problem so we should take it. > [MB2] The most we can do is to document the risks/impacts of the use=20 > of the Privacy headers at the R-URI level. There is already general=20 > text in > 4244 and 4244bis that the privacy may impact whether the applications=20 > get the information. And, as I noted before, most commercial systems=20 > are using B2BUAs which will allow you far more control over the use of = > the Privacy headers in the network. But, again, I don't think that's=20 > something that should be address in 4244bis. [/MB2] > > I hope that we can get some wider discussion on this issue so a more=20 > general consensus can be obtained. > > Regards > > Ian > > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 24 June 2009 17:27 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Francois Audet > Subject: RE: 4244bis and privacy > > Hi Ian, > > Responses inline below [MB]. > > Mary.=20 > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, June 24, 2009 10:37 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > Mary, > > I was not proposing that we change the handling of H-I which is based=20 > upon local policy. If that causes an issue for a network operator then = > they can modify their local policy accordingly or arrange with the=20 > proxy vendor to modify their equipment to be more flexible with=20 > regards to policy. > > Can you clarify for me: > > If you have a Privacy header with either "session" or "header" doe=20 > this impact the H-I entries or will only a value of "history" impact=20 > the H-I entries? > [MB] Yes, both "session" and "header" level privacy, consistent with=20 > RFC 3323, mandate that entries be anonymized or dropped, with the=20 > latter being the recommendation for "session" level privacy. RFC 4244=20 > mandated that they be dropped and 4244bis recommends they be=20 > anonymized. The original intent for the value of "history" was for the = > tagging of the individual entries, but you end up getting the header=20 > level functionality as well. [/MB] > > If you have a Privacy header with a value of "none" and a H-I entry=20 > with Privacy header parameter with value "history" what is the privacy = > of the individual H-I entry? > [MB] We did not explicitly address the "none" in RFC 4244, but the=20 > general statement is the privacy headers at the request level override = > any at the hi-entry level. [/MB] > > From reading RFC4244 a Privacy header with value "history" will=20 > effectively make all H-I entries private and there is currently no=20 > option to include a H-I Privacy header parameter with value "none". > [MB] Correct, per my comment above. [/MB] > > H-I at present allows the inclusion of Privacy header parameters to=20 > explicitly express privacy for an individual H-I entry but a single=20 > node which includes a header "Privacy: history" makes all H-I entries=20 > private even if this is not the requirements for the specific URI. > [MB] Correct, but the only node that should add the header is a node=20 > which is responsible for the domain associated with the Request URI in = > the incoming request or is authorized to do so. [/MB] > > I will admit that having worked in a telephony environment for a long=20 > time I am used to having privacy of identities set on a per number=20 > basis and the relative inflexibility of the IETF Privacy header is=20 > relatively restrictive as to specifying which identities may be=20 > presented and which not. > [MB] Yes, this is an entirely different paradigm. I developed=20 > telephony s/w for over a decade and this is entirely different - it=20 > provides a lot more flexibility, which makes things far, far less=20 > deterministic than what you have in telephony switches where your=20 > routing and translations are configured for the most part, with just a = > few capabilities for controlling the privacy and it's a closed = network. > > With RFC4244/4244bis, there MUST be a mechanism at the UAS or end=20 > application that can handle a request that doesn't have the=20 > appropriate information either because nodes didn't support=20 > History-Info or some random node in the network applied privacy (which = > I think is highly > unlikely) - this is normative per section 5 of RFC 4244. So, the=20 > worst case scenario I see for this 800 service (which will get to the = > right UAS but without the exact 800 number that was dialed) is that it = > goes to a default ACD group/customer service agent, etc. who then=20 > needs to gather the appropriate information and in my experience this=20 > is often an IVR system these days. So, the service is not broken when = > privacy is applied in an undesireable manner, it's just not optimal. =20 > This is something that should be addressed in the target-uri draft=20 > which has all the details of how specific services use History-Info. > One other thing to consider is that most networks that are emulating=20 > telephony type features use B2BUAs, which follow the UAS/UAC rules for = > the header rather than the proxy rules, noting that the UAC can set=20 > the Privacy header to whatever value it sees as appropriate for the = request. > [/MB] > > > Regards > > Ian > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 24 June 2009 15:48 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Francois Audet > Subject: RE: 4244bis and privacy > > Hi Ian, > > I do not believe we should do the "override" behavior as I think that=20 > violates RFC 3323, as the "history" is really a subset of the cases=20 > whereby a UAC or proxy would add "session" or "header" to the request. > And, the latter two cases have the same (undesireable) result. I = agree > this impacts your services, but we can't mandate that proxies provide=20 > information that might violate their local policies and indeed a=20 > proxy's local policies can result in the information being anonymized=20 > (or removed if they can't anonymize) even in the "none" case. > > I do believe it's reasonable that we strongly recommend that the=20 > request level (versus specific hi-entries) not be used and if it is=20 > used, the consequence is that some services will not have the=20 > information they need - this was the gist of my previous response (to=20 > which I did not get any additional feedback). Now, we could add some = text that the "none" > case SHOULD be used (e.g., added by first hop proxy) if it is desired=20 > that the information not be subject to privacy restrictions. I do not=20 > think it is then particularly useful to add logic around the proxy=20 > then being able to tag the entries within their domain as subject to = privacy. > I think that conflicts with the intent of the request level "none". > However, as I mention above, per the current text, a proxy can (based=20 > on local policy) remove entries - so a proxy can capture hi within=20 > their domain and not forward any of that information to the next hop=20 > in another domain - you already have that functionality. But, I think = > this introduces the general problem that you might be impacting other=20 > services further down the line, which I thought was the problem you=20 > were wanting to solve - not specifically your example service but, for = > example, in the case that someone is debugging and they want the=20 > entire history, so depending upon the service, this is also=20 > undesirable behavior. > > > Regards, > Mary.=20 > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, June 24, 2009 2:57 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > > Mary, > > [I have added the list to this thread for wider comment.] > > In the previous discussions I commented that in RFC4424 that a Privacy = > header with value "history" effectively makes all H-I entries private=20 > with the result that the H-I entries may be removed. > > There has now been a comprehensive discussion on indication of the=20 > initial 'target' to the final recipient for call handling purposes. > > The main use case related to a freephone example where the answering=20 > location may be a call centre where the original freephone number may=20 > be required for correct call handling. > > If you now consider the following example (modified from Francois'=20 > text in the latest draft - excuse any errors that I may have inserted) > > INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx > Privacy: history > History-Info: > ;index=3D1;rt;aor = (1) > History-Info: ;index=3D1.1;mp;aor > (2) > History-Info: ;index=3D1.1.1;rc > (3) > > In this case due to the Privacy header all of the H-I entries are=20 > considered private and the +18001234567 will not be delivered to the=20 > final destination with the result that call handling may not be = correct. > The Privacy header may have been inserted by any of the nodes which=20 > routed the message and inserted a H-I entry. > > If however the H-I was allowed to include a header parameter of=20 > "?Privacy=3Dnone" in the H-I entry and that an explicit H-I entry=20 > privacy value would be considered to have precedence over a Privacy=20 > header with a value of "history" then the mapping of the +18001234567=20 > could be explicitly specified as not private and may be passed on. > > Thus when the mapping from sip:+18001234567@example.com to=20 > sip:bob@biloxi.example.com when H-I entry (2) above is included could=20 > also insert the Privacy header parameter in H-I entry (1). > > Thus the message would appear as follows: > > INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx > Privacy: history > History-Info: > = ;index=3D= 1;rt; > ao > r > History-Info: ;index=3D1.1;mp;aor > History-Info: ;index=3D1.1.1;rc > > This would result in all the H-I entries except (1) being considered=20 > private with the result that the =3D1800... Number is passed for call=20 > handling purposes. > > This change is backward compatible with the existing implementation as = > any node using the existing functionality as defined in RFC4244 will=20 > continue to be supported. > > The alternative is to remove the ability to include the value = "history" > in the Privacy header and only allow this value in the Privacy header=20 > parameter. This alternative is not backward compatible. > > Without this change a single node in the message path which includes a = > header "Privacy: history" will prevent delivery of the aor and thus=20 > prevent proper call handling. > > Ian Elz > > > > -----Original Message----- > From: Christer Holmberg > Sent: 23 June 2009 19:40 > To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida=20 > Schubert > Cc: Ian Elz > Subject: RE: 4244bis and privacy > > =20 > Hi, > > I include Ian, so he can comment to your resposne himself. > > Regards, > > Christer > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Tuesday, June 23, 2009 9:40 PM > To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida=20 > Schubert > Subject: RE: 4244bis and privacy > > Here was the thread of response and the last comment was from Ian that = > he would consider the response: > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html > > And, there was not agreement on the "none" but rather to qualify the=20 > SHOULD NOT forward. However, in the sipcore-4244bis-00, rather than=20 > changing the text such that the headers SHOULD be removed, we=20 > recommend that they be anonymized (in section 4.3.3.3.1). That is=20 > entirely consistent with RFC 3324 and thus we have removed the=20 > recommendations to remove the headers entirely. However, that changed=20 > never got done in section 3.2, so we would need to change this: > "Thus, the History- Info header > SHOULD NOT be included in Requests where the requestor has = indicated > a priv-value of Session- or Header-level privacy." > > But, I'm really beginning to be of the mindset that we should just=20 > remove all the subsections of section 3 (i.e., leave the text in the=20 > upper level section), so we don't have to keep worrying about=20 > consistency. > > So, lets either fixt the text in 3.2 or remove altogether and then I=20 > think we are really at the point of needing to submit this version so=20 > folks that actually have an interest in it can review the updated=20 > document. > > Mary.=20 > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, June 23, 2009 1:10 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik = > van Elburg; Shida Schubert > Subject: 4244bis and privacy > > > Hi, > > Below is a comment/proposal which one of my collegues (Ian Elz) gave=20 > on the list a while ago, when the first version of 4244bis was=20 > submitted, but was not incorporated. Do you think it would be useful? > > ------- > > While the HI approach to target may solve the problem of being able to = > deliver the target URI to the final destination there is no guarantee=20 > that it will actually be delivered. > > The problem arises with how Privacy is defined for HI. > > 4424 defines a new Privacy value "history" which may be placed in=20 > either the Privacy header or as a header parameter to the HI entry. > > If one node uses the former option "Privacy: history" then this will=20 > make all headers private and will result in all HI entries being=20 > removed or made anonymous when the message containing the HI is=20 > delivered to the user. > > There is a simple solution to this and that is to also allow the use=20 > of the "none" Privacy value as a header parameter in the HI entry.=20 > This would explicitly state that no privacy is required to the HI=20 > entry and this would override a "history" value in the Privacy header. > > I pointed this out to Mary when the 4424bis draft was first published=20 > but the change has not been made in the latest draft. > > The change is backward compatible and would not cause an issue with=20 > any existing implementations. > > ------ > > Regards, > > Christer > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > =20 From mary.barnes@nortel.com Thu Jun 25 14:44:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B1773A67A3 for ; Thu, 25 Jun 2009 14:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.294 X-Spam-Level: X-Spam-Status: No, score=-6.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PinAXKuDH8DG for ; Thu, 25 Jun 2009 14:44:16 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 4239C3A68F5 for ; Thu, 25 Jun 2009 14:44:15 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5PLg6506717; Thu, 25 Jun 2009 21:42:06 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 16:45:22 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EB26AB5@zrc2hxm0.corp.nortel.com> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4048F80AC@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] 4244bis and privacy thread-index: Acn11AWR+Z7be2FAQvKtnWIFO4vfcAAB1KHQAABgLvA= References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4048F809B@S4DE8PSAAQB.mitte.t-com.de> <4A43DEC9.1020802@gmail.com> <9886E5FCA6D76549A3011068483A4BD4048F80AC@S4DE8PSAAQB.mitte.t-com.de> From: "Mary Barnes" To: , Cc: ian.elz@ericsson.com, sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 21:44:19 -0000 Roland, The reason you can't have "none" at the request level and "history" at = the entry level is because RFC 3323 states that you MUST NOT apply = privacy to the message. Even if you put "history" in the entries, the = privacy service would just ignore that - per RFC 3323. So, if you want = to change that behavior, then RFC 3323 should be changed - i.e., the = MUST NOT for the "none" could be changed to a SHOULD NOT and then a = general statement about possible exceptions. Then, we could add = something to RFC 4244 for this case. But, changing RFC 3323 is totally = out of scope for what we are currently working on. =20 That all said, I would sure think that if you are leaving a "trusted = network" that you have a B2BUA in there, as I've said in other threads. = Thus, the B2BUA builds a new request and certainly can add a privacy = header that it believes is appropriate since the outgoing request is = done by the UAC function of a B2BUA.=20 Mary.=20 -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: Thursday, June 25, 2009 4:32 PM To: ietf.hanserik@gmail.com Cc: Barnes, Mary (RICH2:AR00); ian.elz@ericsson.com; sipcore@ietf.org; = shida@agnada.com Subject: AW: [sipcore] 4244bis and privacy Hi Hans Erik, We have also to take regulatory into consideration. In Germany the last = trusted network is responsible for anonymising information.=20 But nevertheless if Network provider A wants to have History completely = private this operator will set privacy history for the header. If the succeeding Operator want to present elements the AS which adds a = entry has then to re label all entries from the preceding network and = the entries from it's own network will be unmarked within the Header. But never the less I fully agree to your last sentence. The real Question is if this should really be allowed that a entry = marked with "none" overrules the privacy statement "history" for the = complete header. I'm against this behaviour.=20 Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Gesendet: Donnerstag, 25. Juni 2009 22:32 An: Jesske, Roland Cc: mary.barnes@nortel.com; ian.elz@ericsson.com; sipcore@ietf.org; = shida@agnada.com Betreff: Re: [sipcore] 4244bis and privacy Hi Roland, I don't understand the argument, by the time that the History-Info = leaves operator A that wishes complete privacy, all the History-Info = headers should be anonymised according to 4244 and 4244bis. What is the point in mandating that operator A to force operator B to = also anonymise the entries "owned" by operator B. It is of course without question that each operator has full privacy = control over its own added entries. And each operator can based on local = policy decide to remove the entire history if it things that is wise to = do. /Hans Erik R.Jesske@telekom.de wrote: > Hi Marry and Ian, > The whole discussion puzzle me. We have specified CDIV within TISPAN = and 3GPP.=20 > There is described that privacy "none" can be used for entries. BUT = assuming that each entry has its own privacy statement if needed.=20 > I fully agree on Mary's comment that a privacy "history" cannot = overruled by a privacy value "none" within a entry.=20 > There may be operators that would like to keep the whole History Info = private even if entries has other statements, so the entity could add = privacy history to the whole header. Nothing more. > > On the other side a Application Server including a entry should have = the possibility to rewrite the entries so that instead of "history" for = the whole header the all received entries within the History-Info header = will be marked with "history" and the added header (which shall be = presented to the terminating user) will either be marked with "none" or = will not be marked. > > Perhaps a hint could be given, but I do not insist on it. > > Best Regards, > > Roland > > > > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im=20 > Auftrag von Mary Barnes > Gesendet: Donnerstag, 25. Juni 2009 18:29 > An: Ian Elz > Cc: sipcore@ietf.org; Shida Schubert > Betreff: Re: [sipcore] 4244bis and privacy > > Hi Ian, > > Responses inline below [MB2]. > > Mary. > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Thursday, June 25, 2009 10:13 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > Mary, > > I am a little concerned about one answer that you gave: > > > If you have a Privacy header with a value of "none" and a H-I entry=20 > with Privacy header parameter with value "history" what is the privacy = > of the individual H-I entry? > [MB] We did not explicitly address the "none" in RFC 4244, but the=20 > general statement is the privacy headers at the request level override = > any at the hi-entry level. [/MB] > =20 > This means that if privacy is required for an individual H-I entry but = > the originating user included "Privacy:none" in the request then there = > is no option to include the real URI in the H-I entry. > [MB2] I'm confused here - the "none" definition is as you note below,=20 > thus "none" prohibits the removal or anonymization of the entries,=20 > thus I would think you would fine this functionality desireable.=20 > However, this does not prohibit an entity based on policy to anonymize = > (or remove entries if privacy is required for that domain if the=20 > entity does not have access to a privacy service). [/MB2] > > This occurs as RFC3323 states in section 4.3: "However, if the Privacy = > header value of 'none' is specified in a message, privacy services=20 > MUST NOT perform any privacy function and MUST NOT remove or modify=20 > the Privacy header." > > The only option for an intermediate node including a H-I entry where=20 > "Privacy:none" is specified and privacy for the H-I URI is required is = > to include an anonymous entry or not include the H-I entry. > [MB2] If privacy is required then yes, you include anonymous entries=20 > or don't include. That's the basic privacy mechanism for privacy=20 > levels of "session" "header" and "history" in the R-URI or "history"=20 > in the specific entries, as well as when there is a policy for privacy = > for the entries added by a specific domain. The "none" really has no=20 > influence on the later case per se. [/MB2] > > In your previous response you stated that we would violate RFC3323 if=20 > we specified additional behaviour for privacy explicitly stated with a = > URI -n the H-I entry. I don't believe that this is the case as RFC3323 = > only considered privacy in a two party scenario and did not consider=20 > third party identities being included in a message between two=20 > parties. H-I is not the only case where this occurs as the Referred-By = > header when included in the INVITE (or other request) which results=20 > from the REFER has the same issue. > [MB2] I can't necessarily disagree on this one (we can debate it=20 > either way). But to fix it requires an update to RFC 3323 and=20 > shouldn't be something that we want to fix in 4244bis. [/MB2] > > RFC4244 was the first time that there was a recognition that privacy=20 > for these individual third party identities may be required. To allow=20 > this explicit statement of privacy to be overridden by a generic=20 > statement which is applicable to a different user is counterintuitive. > [MB2] See my comment above. But, as I have consistently said, the idea = > that an entity might want to override the "none" is entirely based on=20 > policy and 4244 and 4244bis allow privacy to be applied to the entries = > that are added by that entity if the policy dictates so (and we=20 > already say that). [/MB2] > > The original Privacy header is usually included by or on behalf of the = > originating user and should not be allowed to specify the privacy of=20 > the original called user, e.g. the 800 number, and prevent this=20 > identity being presented if this user does not have the same level of = privacy. > [MB2] As I tried to say in a previous response, a random entity (i.e., = > one for whom the R-URI is not in a domain under its control) cannot=20 > add a privacy header to the Request. Per RFC 3323 an entity may add=20 > the header to a request only if it has the appropriate=20 > relationship/authorization with the original called user who intiated=20 > the request. And, I would find it very surprising if an entity that=20 > did have responsibility would apply privacy since that would be=20 > counter intuitive and I would hope that SPs would be judicious in=20 > specifying the appropriate and inappropriate manner in which the=20 > proxies they deploy and interface with privatize the messages. The=20 > protocol CANNOT control this behavior and that's why there is the=20 > policy clause in 4244 and 4244bis. [/MB2] > > The real issue with the 800 scenario is as you have stated is that the = > answerer will not know the original called identity and will not be=20 > able to correctly handle the call. As more generic call centres are=20 > used which will answer calls on behalf of many different organizations = > using CTI and the original called identity to have to implement a=20 > generic system asking the caller who he originally called appear=20 > unprofessional, is inefficient and unproductive. > [MB2] And, as I noted, it is rare for a call centre to route a call=20 > directly to an agent without a user providing some sort of input. Even = > companies like American Airlines, even though they have the info that=20 > I enter via the IVR, they still ask some basic questions and there are = > times when they have to reroute me. I don't think we can totally=20 > automate things. And, again, once the call hits the domain that is=20 > responsible for that 800 number the entities in that domain have=20 > control over how they muck with the R-URI, such that they should be=20 > able to use any IVR info to appropriately direct the call - it's not=20 > the number that's meaningful, but how the system gets the call to the=20 > right user and the additional information they provide as the call is=20 > presented to the agent. I would honestly think that having something=20 > other than an 800 number show up on the display would be far more=20 > useful and in my experience in the systems I developed we're usually=20 > talking about CTI interfaces so you have a lot you can do. And,=20 > actually all of this really doesn't matter in that you MUST be able to = > handle this situation independent of the privacy since History-Info is = > optional, you need default behavior assigned. [/MB2] > > We have an opportunity to allow presentation of specific identities=20 > and to solve this particular problem so we should take it. > [MB2] The most we can do is to document the risks/impacts of the use=20 > of the Privacy headers at the R-URI level. There is already general=20 > text in > 4244 and 4244bis that the privacy may impact whether the applications=20 > get the information. And, as I noted before, most commercial systems=20 > are using B2BUAs which will allow you far more control over the use of = > the Privacy headers in the network. But, again, I don't think that's=20 > something that should be address in 4244bis. [/MB2] > > I hope that we can get some wider discussion on this issue so a more=20 > general consensus can be obtained. > > Regards > > Ian > > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 24 June 2009 17:27 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Francois Audet > Subject: RE: 4244bis and privacy > > Hi Ian, > > Responses inline below [MB]. > > Mary.=20 > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, June 24, 2009 10:37 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > Mary, > > I was not proposing that we change the handling of H-I which is based=20 > upon local policy. If that causes an issue for a network operator then = > they can modify their local policy accordingly or arrange with the=20 > proxy vendor to modify their equipment to be more flexible with=20 > regards to policy. > > Can you clarify for me: > > If you have a Privacy header with either "session" or "header" doe=20 > this impact the H-I entries or will only a value of "history" impact=20 > the H-I entries? > [MB] Yes, both "session" and "header" level privacy, consistent with=20 > RFC 3323, mandate that entries be anonymized or dropped, with the=20 > latter being the recommendation for "session" level privacy. RFC 4244=20 > mandated that they be dropped and 4244bis recommends they be=20 > anonymized. The original intent for the value of "history" was for the = > tagging of the individual entries, but you end up getting the header=20 > level functionality as well. [/MB] > > If you have a Privacy header with a value of "none" and a H-I entry=20 > with Privacy header parameter with value "history" what is the privacy = > of the individual H-I entry? > [MB] We did not explicitly address the "none" in RFC 4244, but the=20 > general statement is the privacy headers at the request level override = > any at the hi-entry level. [/MB] > > From reading RFC4244 a Privacy header with value "history" will=20 > effectively make all H-I entries private and there is currently no=20 > option to include a H-I Privacy header parameter with value "none". > [MB] Correct, per my comment above. [/MB] > > H-I at present allows the inclusion of Privacy header parameters to=20 > explicitly express privacy for an individual H-I entry but a single=20 > node which includes a header "Privacy: history" makes all H-I entries=20 > private even if this is not the requirements for the specific URI. > [MB] Correct, but the only node that should add the header is a node=20 > which is responsible for the domain associated with the Request URI in = > the incoming request or is authorized to do so. [/MB] > > I will admit that having worked in a telephony environment for a long=20 > time I am used to having privacy of identities set on a per number=20 > basis and the relative inflexibility of the IETF Privacy header is=20 > relatively restrictive as to specifying which identities may be=20 > presented and which not. > [MB] Yes, this is an entirely different paradigm. I developed=20 > telephony s/w for over a decade and this is entirely different - it=20 > provides a lot more flexibility, which makes things far, far less=20 > deterministic than what you have in telephony switches where your=20 > routing and translations are configured for the most part, with just a = > few capabilities for controlling the privacy and it's a closed = network. > > With RFC4244/4244bis, there MUST be a mechanism at the UAS or end=20 > application that can handle a request that doesn't have the=20 > appropriate information either because nodes didn't support=20 > History-Info or some random node in the network applied privacy (which = > I think is highly > unlikely) - this is normative per section 5 of RFC 4244. So, the=20 > worst case scenario I see for this 800 service (which will get to the = > right UAS but without the exact 800 number that was dialed) is that it = > goes to a default ACD group/customer service agent, etc. who then=20 > needs to gather the appropriate information and in my experience this=20 > is often an IVR system these days. So, the service is not broken when = > privacy is applied in an undesireable manner, it's just not optimal. =20 > This is something that should be addressed in the target-uri draft=20 > which has all the details of how specific services use History-Info. > One other thing to consider is that most networks that are emulating=20 > telephony type features use B2BUAs, which follow the UAS/UAC rules for = > the header rather than the proxy rules, noting that the UAC can set=20 > the Privacy header to whatever value it sees as appropriate for the = request. > [/MB] > > > Regards > > Ian > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 24 June 2009 15:48 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Francois Audet > Subject: RE: 4244bis and privacy > > Hi Ian, > > I do not believe we should do the "override" behavior as I think that=20 > violates RFC 3323, as the "history" is really a subset of the cases=20 > whereby a UAC or proxy would add "session" or "header" to the request. > And, the latter two cases have the same (undesireable) result. I = agree > this impacts your services, but we can't mandate that proxies provide=20 > information that might violate their local policies and indeed a=20 > proxy's local policies can result in the information being anonymized=20 > (or removed if they can't anonymize) even in the "none" case. > > I do believe it's reasonable that we strongly recommend that the=20 > request level (versus specific hi-entries) not be used and if it is=20 > used, the consequence is that some services will not have the=20 > information they need - this was the gist of my previous response (to=20 > which I did not get any additional feedback). Now, we could add some = text that the "none" > case SHOULD be used (e.g., added by first hop proxy) if it is desired=20 > that the information not be subject to privacy restrictions. I do not=20 > think it is then particularly useful to add logic around the proxy=20 > then being able to tag the entries within their domain as subject to = privacy. > I think that conflicts with the intent of the request level "none". > However, as I mention above, per the current text, a proxy can (based=20 > on local policy) remove entries - so a proxy can capture hi within=20 > their domain and not forward any of that information to the next hop=20 > in another domain - you already have that functionality. But, I think = > this introduces the general problem that you might be impacting other=20 > services further down the line, which I thought was the problem you=20 > were wanting to solve - not specifically your example service but, for = > example, in the case that someone is debugging and they want the=20 > entire history, so depending upon the service, this is also=20 > undesirable behavior. > > > Regards, > Mary.=20 > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, June 24, 2009 2:57 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > > Mary, > > [I have added the list to this thread for wider comment.] > > In the previous discussions I commented that in RFC4424 that a Privacy = > header with value "history" effectively makes all H-I entries private=20 > with the result that the H-I entries may be removed. > > There has now been a comprehensive discussion on indication of the=20 > initial 'target' to the final recipient for call handling purposes. > > The main use case related to a freephone example where the answering=20 > location may be a call centre where the original freephone number may=20 > be required for correct call handling. > > If you now consider the following example (modified from Francois'=20 > text in the latest draft - excuse any errors that I may have inserted) > > INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx > Privacy: history > History-Info: > ;index=3D1;rt;aor = (1) > History-Info: ;index=3D1.1;mp;aor > (2) > History-Info: ;index=3D1.1.1;rc > (3) > > In this case due to the Privacy header all of the H-I entries are=20 > considered private and the +18001234567 will not be delivered to the=20 > final destination with the result that call handling may not be = correct. > The Privacy header may have been inserted by any of the nodes which=20 > routed the message and inserted a H-I entry. > > If however the H-I was allowed to include a header parameter of=20 > "?Privacy=3Dnone" in the H-I entry and that an explicit H-I entry=20 > privacy value would be considered to have precedence over a Privacy=20 > header with a value of "history" then the mapping of the +18001234567=20 > could be explicitly specified as not private and may be passed on. > > Thus when the mapping from sip:+18001234567@example.com to=20 > sip:bob@biloxi.example.com when H-I entry (2) above is included could=20 > also insert the Privacy header parameter in H-I entry (1). > > Thus the message would appear as follows: > > INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx > Privacy: history > History-Info: > = ;index=3D= 1;rt; > ao > r > History-Info: ;index=3D1.1;mp;aor > History-Info: ;index=3D1.1.1;rc > > This would result in all the H-I entries except (1) being considered=20 > private with the result that the =3D1800... Number is passed for call=20 > handling purposes. > > This change is backward compatible with the existing implementation as = > any node using the existing functionality as defined in RFC4244 will=20 > continue to be supported. > > The alternative is to remove the ability to include the value = "history" > in the Privacy header and only allow this value in the Privacy header=20 > parameter. This alternative is not backward compatible. > > Without this change a single node in the message path which includes a = > header "Privacy: history" will prevent delivery of the aor and thus=20 > prevent proper call handling. > > Ian Elz > > > > -----Original Message----- > From: Christer Holmberg > Sent: 23 June 2009 19:40 > To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida=20 > Schubert > Cc: Ian Elz > Subject: RE: 4244bis and privacy > > =20 > Hi, > > I include Ian, so he can comment to your resposne himself. > > Regards, > > Christer > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Tuesday, June 23, 2009 9:40 PM > To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida=20 > Schubert > Subject: RE: 4244bis and privacy > > Here was the thread of response and the last comment was from Ian that = > he would consider the response: > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html > > And, there was not agreement on the "none" but rather to qualify the=20 > SHOULD NOT forward. However, in the sipcore-4244bis-00, rather than=20 > changing the text such that the headers SHOULD be removed, we=20 > recommend that they be anonymized (in section 4.3.3.3.1). That is=20 > entirely consistent with RFC 3324 and thus we have removed the=20 > recommendations to remove the headers entirely. However, that changed=20 > never got done in section 3.2, so we would need to change this: > "Thus, the History- Info header > SHOULD NOT be included in Requests where the requestor has = indicated > a priv-value of Session- or Header-level privacy." > > But, I'm really beginning to be of the mindset that we should just=20 > remove all the subsections of section 3 (i.e., leave the text in the=20 > upper level section), so we don't have to keep worrying about=20 > consistency. > > So, lets either fixt the text in 3.2 or remove altogether and then I=20 > think we are really at the point of needing to submit this version so=20 > folks that actually have an interest in it can review the updated=20 > document. > > Mary.=20 > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, June 23, 2009 1:10 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik = > van Elburg; Shida Schubert > Subject: 4244bis and privacy > > > Hi, > > Below is a comment/proposal which one of my collegues (Ian Elz) gave=20 > on the list a while ago, when the first version of 4244bis was=20 > submitted, but was not incorporated. Do you think it would be useful? > > ------- > > While the HI approach to target may solve the problem of being able to = > deliver the target URI to the final destination there is no guarantee=20 > that it will actually be delivered. > > The problem arises with how Privacy is defined for HI. > > 4424 defines a new Privacy value "history" which may be placed in=20 > either the Privacy header or as a header parameter to the HI entry. > > If one node uses the former option "Privacy: history" then this will=20 > make all headers private and will result in all HI entries being=20 > removed or made anonymous when the message containing the HI is=20 > delivered to the user. > > There is a simple solution to this and that is to also allow the use=20 > of the "none" Privacy value as a header parameter in the HI entry.=20 > This would explicitly state that no privacy is required to the HI=20 > entry and this would override a "history" value in the Privacy header. > > I pointed this out to Mary when the 4424bis draft was first published=20 > but the change has not been made in the latest draft. > > The change is backward compatible and would not cause an issue with=20 > any existing implementations. > > ------ > > Regards, > > Christer > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > =20 From R.Jesske@telekom.de Thu Jun 25 15:01:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BA813A6941 for ; Thu, 25 Jun 2009 15:01:54 -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=1.190, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-FN926uTtqz for ; Thu, 25 Jun 2009 15:01:51 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id A8CFD3A6976 for ; Thu, 25 Jun 2009 15:01:49 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 26 Jun 2009 00:01:47 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Jun 2009 00:01:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Jun 2009 00:01:42 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD4048F80AE@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EB26AB5@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] 4244bis and privacy Thread-Index: Acn11AWR+Z7be2FAQvKtnWIFO4vfcAAB1KHQAABgLvAAANmSIA== References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4048F809B@S4DE8PSAAQB.mitte.t-com.de> <4A43DEC9.1020802@gmail.com> <9886E5FCA6D76549A3011068483A4BD4048F80AC@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1EB26AB5@zrc2hxm0.corp.nortel.com> From: To: , X-OriginalArrivalTime: 25 Jun 2009 22:01:47.0342 (UTC) FILETIME=[88CD86E0:01C9F5E0] Cc: ian.elz@ericsson.com, sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 22:01:54 -0000 Mary, As I said before I don't want this behaviour.=20 So everything shall be as it is already described. Roland=20 -----Urspr=FCngliche Nachricht----- Von: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Gesendet: Donnerstag, 25. Juni 2009 23:45 An: Jesske, Roland; ietf.hanserik@gmail.com Cc: ian.elz@ericsson.com; sipcore@ietf.org; shida@agnada.com Betreff: RE: [sipcore] 4244bis and privacy Roland, The reason you can't have "none" at the request level and "history" at = the entry level is because RFC 3323 states that you MUST NOT apply = privacy to the message. Even if you put "history" in the entries, the = privacy service would just ignore that - per RFC 3323. So, if you want = to change that behavior, then RFC 3323 should be changed - i.e., the = MUST NOT for the "none" could be changed to a SHOULD NOT and then a = general statement about possible exceptions. Then, we could add = something to RFC 4244 for this case. But, changing RFC 3323 is totally = out of scope for what we are currently working on. =20 That all said, I would sure think that if you are leaving a "trusted = network" that you have a B2BUA in there, as I've said in other threads. = Thus, the B2BUA builds a new request and certainly can add a privacy = header that it believes is appropriate since the outgoing request is = done by the UAC function of a B2BUA.=20 Mary.=20 -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: Thursday, June 25, 2009 4:32 PM To: ietf.hanserik@gmail.com Cc: Barnes, Mary (RICH2:AR00); ian.elz@ericsson.com; sipcore@ietf.org; = shida@agnada.com Subject: AW: [sipcore] 4244bis and privacy Hi Hans Erik, We have also to take regulatory into consideration. In Germany the last = trusted network is responsible for anonymising information.=20 But nevertheless if Network provider A wants to have History completely = private this operator will set privacy history for the header. If the succeeding Operator want to present elements the AS which adds a = entry has then to re label all entries from the preceding network and = the entries from it's own network will be unmarked within the Header. But never the less I fully agree to your last sentence. The real Question is if this should really be allowed that a entry = marked with "none" overrules the privacy statement "history" for the = complete header. I'm against this behaviour.=20 Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Gesendet: Donnerstag, 25. Juni 2009 22:32 An: Jesske, Roland Cc: mary.barnes@nortel.com; ian.elz@ericsson.com; sipcore@ietf.org; = shida@agnada.com Betreff: Re: [sipcore] 4244bis and privacy Hi Roland, I don't understand the argument, by the time that the History-Info = leaves operator A that wishes complete privacy, all the History-Info = headers should be anonymised according to 4244 and 4244bis. What is the point in mandating that operator A to force operator B to = also anonymise the entries "owned" by operator B. It is of course without question that each operator has full privacy = control over its own added entries. And each operator can based on local = policy decide to remove the entire history if it things that is wise to = do. /Hans Erik R.Jesske@telekom.de wrote: > Hi Marry and Ian, > The whole discussion puzzle me. We have specified CDIV within TISPAN = and 3GPP.=20 > There is described that privacy "none" can be used for entries. BUT = assuming that each entry has its own privacy statement if needed.=20 > I fully agree on Mary's comment that a privacy "history" cannot = overruled by a privacy value "none" within a entry.=20 > There may be operators that would like to keep the whole History Info = private even if entries has other statements, so the entity could add = privacy history to the whole header. Nothing more. > > On the other side a Application Server including a entry should have = the possibility to rewrite the entries so that instead of "history" for = the whole header the all received entries within the History-Info header = will be marked with "history" and the added header (which shall be = presented to the terminating user) will either be marked with "none" or = will not be marked. > > Perhaps a hint could be given, but I do not insist on it. > > Best Regards, > > Roland > > > > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im=20 > Auftrag von Mary Barnes > Gesendet: Donnerstag, 25. Juni 2009 18:29 > An: Ian Elz > Cc: sipcore@ietf.org; Shida Schubert > Betreff: Re: [sipcore] 4244bis and privacy > > Hi Ian, > > Responses inline below [MB2]. > > Mary. > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Thursday, June 25, 2009 10:13 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > Mary, > > I am a little concerned about one answer that you gave: > > > If you have a Privacy header with a value of "none" and a H-I entry=20 > with Privacy header parameter with value "history" what is the privacy = > of the individual H-I entry? > [MB] We did not explicitly address the "none" in RFC 4244, but the=20 > general statement is the privacy headers at the request level override = > any at the hi-entry level. [/MB] > =20 > This means that if privacy is required for an individual H-I entry but = > the originating user included "Privacy:none" in the request then there = > is no option to include the real URI in the H-I entry. > [MB2] I'm confused here - the "none" definition is as you note below,=20 > thus "none" prohibits the removal or anonymization of the entries,=20 > thus I would think you would fine this functionality desireable.=20 > However, this does not prohibit an entity based on policy to anonymize = > (or remove entries if privacy is required for that domain if the=20 > entity does not have access to a privacy service). [/MB2] > > This occurs as RFC3323 states in section 4.3: "However, if the Privacy = > header value of 'none' is specified in a message, privacy services=20 > MUST NOT perform any privacy function and MUST NOT remove or modify=20 > the Privacy header." > > The only option for an intermediate node including a H-I entry where=20 > "Privacy:none" is specified and privacy for the H-I URI is required is = > to include an anonymous entry or not include the H-I entry. > [MB2] If privacy is required then yes, you include anonymous entries=20 > or don't include. That's the basic privacy mechanism for privacy=20 > levels of "session" "header" and "history" in the R-URI or "history"=20 > in the specific entries, as well as when there is a policy for privacy = > for the entries added by a specific domain. The "none" really has no=20 > influence on the later case per se. [/MB2] > > In your previous response you stated that we would violate RFC3323 if=20 > we specified additional behaviour for privacy explicitly stated with a = > URI -n the H-I entry. I don't believe that this is the case as RFC3323 = > only considered privacy in a two party scenario and did not consider=20 > third party identities being included in a message between two=20 > parties. H-I is not the only case where this occurs as the Referred-By = > header when included in the INVITE (or other request) which results=20 > from the REFER has the same issue. > [MB2] I can't necessarily disagree on this one (we can debate it=20 > either way). But to fix it requires an update to RFC 3323 and=20 > shouldn't be something that we want to fix in 4244bis. [/MB2] > > RFC4244 was the first time that there was a recognition that privacy=20 > for these individual third party identities may be required. To allow=20 > this explicit statement of privacy to be overridden by a generic=20 > statement which is applicable to a different user is counterintuitive. > [MB2] See my comment above. But, as I have consistently said, the idea = > that an entity might want to override the "none" is entirely based on=20 > policy and 4244 and 4244bis allow privacy to be applied to the entries = > that are added by that entity if the policy dictates so (and we=20 > already say that). [/MB2] > > The original Privacy header is usually included by or on behalf of the = > originating user and should not be allowed to specify the privacy of=20 > the original called user, e.g. the 800 number, and prevent this=20 > identity being presented if this user does not have the same level of = privacy. > [MB2] As I tried to say in a previous response, a random entity (i.e., = > one for whom the R-URI is not in a domain under its control) cannot=20 > add a privacy header to the Request. Per RFC 3323 an entity may add=20 > the header to a request only if it has the appropriate=20 > relationship/authorization with the original called user who intiated=20 > the request. And, I would find it very surprising if an entity that=20 > did have responsibility would apply privacy since that would be=20 > counter intuitive and I would hope that SPs would be judicious in=20 > specifying the appropriate and inappropriate manner in which the=20 > proxies they deploy and interface with privatize the messages. The=20 > protocol CANNOT control this behavior and that's why there is the=20 > policy clause in 4244 and 4244bis. [/MB2] > > The real issue with the 800 scenario is as you have stated is that the = > answerer will not know the original called identity and will not be=20 > able to correctly handle the call. As more generic call centres are=20 > used which will answer calls on behalf of many different organizations = > using CTI and the original called identity to have to implement a=20 > generic system asking the caller who he originally called appear=20 > unprofessional, is inefficient and unproductive. > [MB2] And, as I noted, it is rare for a call centre to route a call=20 > directly to an agent without a user providing some sort of input. Even = > companies like American Airlines, even though they have the info that=20 > I enter via the IVR, they still ask some basic questions and there are = > times when they have to reroute me. I don't think we can totally=20 > automate things. And, again, once the call hits the domain that is=20 > responsible for that 800 number the entities in that domain have=20 > control over how they muck with the R-URI, such that they should be=20 > able to use any IVR info to appropriately direct the call - it's not=20 > the number that's meaningful, but how the system gets the call to the=20 > right user and the additional information they provide as the call is=20 > presented to the agent. I would honestly think that having something=20 > other than an 800 number show up on the display would be far more=20 > useful and in my experience in the systems I developed we're usually=20 > talking about CTI interfaces so you have a lot you can do. And,=20 > actually all of this really doesn't matter in that you MUST be able to = > handle this situation independent of the privacy since History-Info is = > optional, you need default behavior assigned. [/MB2] > > We have an opportunity to allow presentation of specific identities=20 > and to solve this particular problem so we should take it. > [MB2] The most we can do is to document the risks/impacts of the use=20 > of the Privacy headers at the R-URI level. There is already general=20 > text in > 4244 and 4244bis that the privacy may impact whether the applications=20 > get the information. And, as I noted before, most commercial systems=20 > are using B2BUAs which will allow you far more control over the use of = > the Privacy headers in the network. But, again, I don't think that's=20 > something that should be address in 4244bis. [/MB2] > > I hope that we can get some wider discussion on this issue so a more=20 > general consensus can be obtained. > > Regards > > Ian > > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 24 June 2009 17:27 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Francois Audet > Subject: RE: 4244bis and privacy > > Hi Ian, > > Responses inline below [MB]. > > Mary.=20 > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, June 24, 2009 10:37 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > Mary, > > I was not proposing that we change the handling of H-I which is based=20 > upon local policy. If that causes an issue for a network operator then = > they can modify their local policy accordingly or arrange with the=20 > proxy vendor to modify their equipment to be more flexible with=20 > regards to policy. > > Can you clarify for me: > > If you have a Privacy header with either "session" or "header" doe=20 > this impact the H-I entries or will only a value of "history" impact=20 > the H-I entries? > [MB] Yes, both "session" and "header" level privacy, consistent with=20 > RFC 3323, mandate that entries be anonymized or dropped, with the=20 > latter being the recommendation for "session" level privacy. RFC 4244=20 > mandated that they be dropped and 4244bis recommends they be=20 > anonymized. The original intent for the value of "history" was for the = > tagging of the individual entries, but you end up getting the header=20 > level functionality as well. [/MB] > > If you have a Privacy header with a value of "none" and a H-I entry=20 > with Privacy header parameter with value "history" what is the privacy = > of the individual H-I entry? > [MB] We did not explicitly address the "none" in RFC 4244, but the=20 > general statement is the privacy headers at the request level override = > any at the hi-entry level. [/MB] > > From reading RFC4244 a Privacy header with value "history" will=20 > effectively make all H-I entries private and there is currently no=20 > option to include a H-I Privacy header parameter with value "none". > [MB] Correct, per my comment above. [/MB] > > H-I at present allows the inclusion of Privacy header parameters to=20 > explicitly express privacy for an individual H-I entry but a single=20 > node which includes a header "Privacy: history" makes all H-I entries=20 > private even if this is not the requirements for the specific URI. > [MB] Correct, but the only node that should add the header is a node=20 > which is responsible for the domain associated with the Request URI in = > the incoming request or is authorized to do so. [/MB] > > I will admit that having worked in a telephony environment for a long=20 > time I am used to having privacy of identities set on a per number=20 > basis and the relative inflexibility of the IETF Privacy header is=20 > relatively restrictive as to specifying which identities may be=20 > presented and which not. > [MB] Yes, this is an entirely different paradigm. I developed=20 > telephony s/w for over a decade and this is entirely different - it=20 > provides a lot more flexibility, which makes things far, far less=20 > deterministic than what you have in telephony switches where your=20 > routing and translations are configured for the most part, with just a = > few capabilities for controlling the privacy and it's a closed = network. > > With RFC4244/4244bis, there MUST be a mechanism at the UAS or end=20 > application that can handle a request that doesn't have the=20 > appropriate information either because nodes didn't support=20 > History-Info or some random node in the network applied privacy (which = > I think is highly > unlikely) - this is normative per section 5 of RFC 4244. So, the=20 > worst case scenario I see for this 800 service (which will get to the = > right UAS but without the exact 800 number that was dialed) is that it = > goes to a default ACD group/customer service agent, etc. who then=20 > needs to gather the appropriate information and in my experience this=20 > is often an IVR system these days. So, the service is not broken when = > privacy is applied in an undesireable manner, it's just not optimal. =20 > This is something that should be addressed in the target-uri draft=20 > which has all the details of how specific services use History-Info. > One other thing to consider is that most networks that are emulating=20 > telephony type features use B2BUAs, which follow the UAS/UAC rules for = > the header rather than the proxy rules, noting that the UAC can set=20 > the Privacy header to whatever value it sees as appropriate for the = request. > [/MB] > > > Regards > > Ian > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 24 June 2009 15:48 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Francois Audet > Subject: RE: 4244bis and privacy > > Hi Ian, > > I do not believe we should do the "override" behavior as I think that=20 > violates RFC 3323, as the "history" is really a subset of the cases=20 > whereby a UAC or proxy would add "session" or "header" to the request. > And, the latter two cases have the same (undesireable) result. I = agree > this impacts your services, but we can't mandate that proxies provide=20 > information that might violate their local policies and indeed a=20 > proxy's local policies can result in the information being anonymized=20 > (or removed if they can't anonymize) even in the "none" case. > > I do believe it's reasonable that we strongly recommend that the=20 > request level (versus specific hi-entries) not be used and if it is=20 > used, the consequence is that some services will not have the=20 > information they need - this was the gist of my previous response (to=20 > which I did not get any additional feedback). Now, we could add some = text that the "none" > case SHOULD be used (e.g., added by first hop proxy) if it is desired=20 > that the information not be subject to privacy restrictions. I do not=20 > think it is then particularly useful to add logic around the proxy=20 > then being able to tag the entries within their domain as subject to = privacy. > I think that conflicts with the intent of the request level "none". > However, as I mention above, per the current text, a proxy can (based=20 > on local policy) remove entries - so a proxy can capture hi within=20 > their domain and not forward any of that information to the next hop=20 > in another domain - you already have that functionality. But, I think = > this introduces the general problem that you might be impacting other=20 > services further down the line, which I thought was the problem you=20 > were wanting to solve - not specifically your example service but, for = > example, in the case that someone is debugging and they want the=20 > entire history, so depending upon the service, this is also=20 > undesirable behavior. > > > Regards, > Mary.=20 > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, June 24, 2009 2:57 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > > Mary, > > [I have added the list to this thread for wider comment.] > > In the previous discussions I commented that in RFC4424 that a Privacy = > header with value "history" effectively makes all H-I entries private=20 > with the result that the H-I entries may be removed. > > There has now been a comprehensive discussion on indication of the=20 > initial 'target' to the final recipient for call handling purposes. > > The main use case related to a freephone example where the answering=20 > location may be a call centre where the original freephone number may=20 > be required for correct call handling. > > If you now consider the following example (modified from Francois'=20 > text in the latest draft - excuse any errors that I may have inserted) > > INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx > Privacy: history > History-Info: > ;index=3D1;rt;aor = (1) > History-Info: ;index=3D1.1;mp;aor > (2) > History-Info: ;index=3D1.1.1;rc > (3) > > In this case due to the Privacy header all of the H-I entries are=20 > considered private and the +18001234567 will not be delivered to the=20 > final destination with the result that call handling may not be = correct. > The Privacy header may have been inserted by any of the nodes which=20 > routed the message and inserted a H-I entry. > > If however the H-I was allowed to include a header parameter of=20 > "?Privacy=3Dnone" in the H-I entry and that an explicit H-I entry=20 > privacy value would be considered to have precedence over a Privacy=20 > header with a value of "history" then the mapping of the +18001234567=20 > could be explicitly specified as not private and may be passed on. > > Thus when the mapping from sip:+18001234567@example.com to=20 > sip:bob@biloxi.example.com when H-I entry (2) above is included could=20 > also insert the Privacy header parameter in H-I entry (1). > > Thus the message would appear as follows: > > INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx > Privacy: history > History-Info: > = ;index=3D= 1;rt; > ao > r > History-Info: ;index=3D1.1;mp;aor > History-Info: ;index=3D1.1.1;rc > > This would result in all the H-I entries except (1) being considered=20 > private with the result that the =3D1800... Number is passed for call=20 > handling purposes. > > This change is backward compatible with the existing implementation as = > any node using the existing functionality as defined in RFC4244 will=20 > continue to be supported. > > The alternative is to remove the ability to include the value = "history" > in the Privacy header and only allow this value in the Privacy header=20 > parameter. This alternative is not backward compatible. > > Without this change a single node in the message path which includes a = > header "Privacy: history" will prevent delivery of the aor and thus=20 > prevent proper call handling. > > Ian Elz > > > > -----Original Message----- > From: Christer Holmberg > Sent: 23 June 2009 19:40 > To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida=20 > Schubert > Cc: Ian Elz > Subject: RE: 4244bis and privacy > > =20 > Hi, > > I include Ian, so he can comment to your resposne himself. > > Regards, > > Christer > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Tuesday, June 23, 2009 9:40 PM > To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida=20 > Schubert > Subject: RE: 4244bis and privacy > > Here was the thread of response and the last comment was from Ian that = > he would consider the response: > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html > > And, there was not agreement on the "none" but rather to qualify the=20 > SHOULD NOT forward. However, in the sipcore-4244bis-00, rather than=20 > changing the text such that the headers SHOULD be removed, we=20 > recommend that they be anonymized (in section 4.3.3.3.1). That is=20 > entirely consistent with RFC 3324 and thus we have removed the=20 > recommendations to remove the headers entirely. However, that changed=20 > never got done in section 3.2, so we would need to change this: > "Thus, the History- Info header > SHOULD NOT be included in Requests where the requestor has = indicated > a priv-value of Session- or Header-level privacy." > > But, I'm really beginning to be of the mindset that we should just=20 > remove all the subsections of section 3 (i.e., leave the text in the=20 > upper level section), so we don't have to keep worrying about=20 > consistency. > > So, lets either fixt the text in 3.2 or remove altogether and then I=20 > think we are really at the point of needing to submit this version so=20 > folks that actually have an interest in it can review the updated=20 > document. > > Mary.=20 > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, June 23, 2009 1:10 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik = > van Elburg; Shida Schubert > Subject: 4244bis and privacy > > > Hi, > > Below is a comment/proposal which one of my collegues (Ian Elz) gave=20 > on the list a while ago, when the first version of 4244bis was=20 > submitted, but was not incorporated. Do you think it would be useful? > > ------- > > While the HI approach to target may solve the problem of being able to = > deliver the target URI to the final destination there is no guarantee=20 > that it will actually be delivered. > > The problem arises with how Privacy is defined for HI. > > 4424 defines a new Privacy value "history" which may be placed in=20 > either the Privacy header or as a header parameter to the HI entry. > > If one node uses the former option "Privacy: history" then this will=20 > make all headers private and will result in all HI entries being=20 > removed or made anonymous when the message containing the HI is=20 > delivered to the user. > > There is a simple solution to this and that is to also allow the use=20 > of the "none" Privacy value as a header parameter in the HI entry.=20 > This would explicitly state that no privacy is required to the HI=20 > entry and this would override a "history" value in the Privacy header. > > I pointed this out to Mary when the 4424bis draft was first published=20 > but the change has not been made in the latest draft. > > The change is backward compatible and would not cause an issue with=20 > any existing implementations. > > ------ > > Regards, > > Christer > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > =20 From mary.barnes@nortel.com Thu Jun 25 15:32:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6CD93A67D8 for ; Thu, 25 Jun 2009 15:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqJHNDPuSZP1 for ; Thu, 25 Jun 2009 15:32:01 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 00C6F3A6840 for ; Thu, 25 Jun 2009 15:32:00 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5PMTko13511; Thu, 25 Jun 2009 22:29:46 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Jun 2009 17:33:19 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EB26B9C@zrc2hxm0.corp.nortel.com> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4048F80AE@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] 4244bis and privacy thread-index: Acn11AWR+Z7be2FAQvKtnWIFO4vfcAAB1KHQAABgLvAAANmSIAABKTAw References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4048F809B@S4DE8PSAAQB.mitte.t-com.de> <4A43DEC9.1020802@gmail.com> <9886E5FCA6D76549A3011068483A4BD4048F80AC@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1EB26AB5@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4048F80AE@S4DE8PSAAQB.mitte.t-com.de> From: "Mary Barnes" To: , Cc: ian.elz@ericsson.com, sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 22:32:09 -0000 Okay - I see what you were saying now - so no issue at all. Thanks, Mary.=20 -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 Sent: Thursday, June 25, 2009 5:02 PM To: Barnes, Mary (RICH2:AR00); ietf.hanserik@gmail.com Cc: ian.elz@ericsson.com; sipcore@ietf.org; shida@agnada.com Subject: AW: [sipcore] 4244bis and privacy Mary, As I said before I don't want this behaviour.=20 So everything shall be as it is already described. Roland=20 -----Urspr=FCngliche Nachricht----- Von: Mary Barnes [mailto:mary.barnes@nortel.com] Gesendet: Donnerstag, 25. Juni 2009 23:45 An: Jesske, Roland; ietf.hanserik@gmail.com Cc: ian.elz@ericsson.com; sipcore@ietf.org; shida@agnada.com Betreff: RE: [sipcore] 4244bis and privacy Roland, The reason you can't have "none" at the request level and "history" at = the entry level is because RFC 3323 states that you MUST NOT apply = privacy to the message. Even if you put "history" in the entries, the = privacy service would just ignore that - per RFC 3323. So, if you want = to change that behavior, then RFC 3323 should be changed - i.e., the = MUST NOT for the "none" could be changed to a SHOULD NOT and then a = general statement about possible exceptions. Then, we could add = something to RFC 4244 for this case. But, changing RFC 3323 is totally = out of scope for what we are currently working on. =20 That all said, I would sure think that if you are leaving a "trusted = network" that you have a B2BUA in there, as I've said in other threads. = Thus, the B2BUA builds a new request and certainly can add a privacy = header that it believes is appropriate since the outgoing request is = done by the UAC function of a B2BUA.=20 Mary.=20 -----Original Message----- From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] Sent: Thursday, June 25, 2009 4:32 PM To: ietf.hanserik@gmail.com Cc: Barnes, Mary (RICH2:AR00); ian.elz@ericsson.com; sipcore@ietf.org; = shida@agnada.com Subject: AW: [sipcore] 4244bis and privacy Hi Hans Erik, We have also to take regulatory into consideration. In Germany the last = trusted network is responsible for anonymising information.=20 But nevertheless if Network provider A wants to have History completely = private this operator will set privacy history for the header. If the succeeding Operator want to present elements the AS which adds a = entry has then to re label all entries from the preceding network and = the entries from it's own network will be unmarked within the Header. But never the less I fully agree to your last sentence. The real Question is if this should really be allowed that a entry = marked with "none" overrules the privacy statement "history" for the = complete header. I'm against this behaviour.=20 Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Gesendet: Donnerstag, 25. Juni 2009 22:32 An: Jesske, Roland Cc: mary.barnes@nortel.com; ian.elz@ericsson.com; sipcore@ietf.org; = shida@agnada.com Betreff: Re: [sipcore] 4244bis and privacy Hi Roland, I don't understand the argument, by the time that the History-Info = leaves operator A that wishes complete privacy, all the History-Info = headers should be anonymised according to 4244 and 4244bis. What is the point in mandating that operator A to force operator B to = also anonymise the entries "owned" by operator B. It is of course without question that each operator has full privacy = control over its own added entries. And each operator can based on local = policy decide to remove the entire history if it things that is wise to = do. /Hans Erik R.Jesske@telekom.de wrote: > Hi Marry and Ian, > The whole discussion puzzle me. We have specified CDIV within TISPAN = and 3GPP.=20 > There is described that privacy "none" can be used for entries. BUT = assuming that each entry has its own privacy statement if needed.=20 > I fully agree on Mary's comment that a privacy "history" cannot = overruled by a privacy value "none" within a entry.=20 > There may be operators that would like to keep the whole History Info = private even if entries has other statements, so the entity could add = privacy history to the whole header. Nothing more. > > On the other side a Application Server including a entry should have = the possibility to rewrite the entries so that instead of "history" for = the whole header the all received entries within the History-Info header = will be marked with "history" and the added header (which shall be = presented to the terminating user) will either be marked with "none" or = will not be marked. > > Perhaps a hint could be given, but I do not insist on it. > > Best Regards, > > Roland > > > > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im=20 > Auftrag von Mary Barnes > Gesendet: Donnerstag, 25. Juni 2009 18:29 > An: Ian Elz > Cc: sipcore@ietf.org; Shida Schubert > Betreff: Re: [sipcore] 4244bis and privacy > > Hi Ian, > > Responses inline below [MB2]. > > Mary. > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Thursday, June 25, 2009 10:13 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > Mary, > > I am a little concerned about one answer that you gave: > > > If you have a Privacy header with a value of "none" and a H-I entry=20 > with Privacy header parameter with value "history" what is the privacy = > of the individual H-I entry? > [MB] We did not explicitly address the "none" in RFC 4244, but the=20 > general statement is the privacy headers at the request level override = > any at the hi-entry level. [/MB] > =20 > This means that if privacy is required for an individual H-I entry but = > the originating user included "Privacy:none" in the request then there = > is no option to include the real URI in the H-I entry. > [MB2] I'm confused here - the "none" definition is as you note below,=20 > thus "none" prohibits the removal or anonymization of the entries,=20 > thus I would think you would fine this functionality desireable. > However, this does not prohibit an entity based on policy to anonymize = > (or remove entries if privacy is required for that domain if the=20 > entity does not have access to a privacy service). [/MB2] > > This occurs as RFC3323 states in section 4.3: "However, if the Privacy = > header value of 'none' is specified in a message, privacy services=20 > MUST NOT perform any privacy function and MUST NOT remove or modify=20 > the Privacy header." > > The only option for an intermediate node including a H-I entry where=20 > "Privacy:none" is specified and privacy for the H-I URI is required is = > to include an anonymous entry or not include the H-I entry. > [MB2] If privacy is required then yes, you include anonymous entries=20 > or don't include. That's the basic privacy mechanism for privacy=20 > levels of "session" "header" and "history" in the R-URI or "history" > in the specific entries, as well as when there is a policy for privacy = > for the entries added by a specific domain. The "none" really has no=20 > influence on the later case per se. [/MB2] > > In your previous response you stated that we would violate RFC3323 if=20 > we specified additional behaviour for privacy explicitly stated with a = > URI -n the H-I entry. I don't believe that this is the case as RFC3323 = > only considered privacy in a two party scenario and did not consider=20 > third party identities being included in a message between two=20 > parties. H-I is not the only case where this occurs as the Referred-By = > header when included in the INVITE (or other request) which results=20 > from the REFER has the same issue. > [MB2] I can't necessarily disagree on this one (we can debate it=20 > either way). But to fix it requires an update to RFC 3323 and=20 > shouldn't be something that we want to fix in 4244bis. [/MB2] > > RFC4244 was the first time that there was a recognition that privacy=20 > for these individual third party identities may be required. To allow=20 > this explicit statement of privacy to be overridden by a generic=20 > statement which is applicable to a different user is counterintuitive. > [MB2] See my comment above. But, as I have consistently said, the idea = > that an entity might want to override the "none" is entirely based on=20 > policy and 4244 and 4244bis allow privacy to be applied to the entries = > that are added by that entity if the policy dictates so (and we=20 > already say that). [/MB2] > > The original Privacy header is usually included by or on behalf of the = > originating user and should not be allowed to specify the privacy of=20 > the original called user, e.g. the 800 number, and prevent this=20 > identity being presented if this user does not have the same level of = privacy. > [MB2] As I tried to say in a previous response, a random entity (i.e., = > one for whom the R-URI is not in a domain under its control) cannot=20 > add a privacy header to the Request. Per RFC 3323 an entity may add=20 > the header to a request only if it has the appropriate=20 > relationship/authorization with the original called user who intiated=20 > the request. And, I would find it very surprising if an entity that=20 > did have responsibility would apply privacy since that would be=20 > counter intuitive and I would hope that SPs would be judicious in=20 > specifying the appropriate and inappropriate manner in which the=20 > proxies they deploy and interface with privatize the messages. The=20 > protocol CANNOT control this behavior and that's why there is the=20 > policy clause in 4244 and 4244bis. [/MB2] > > The real issue with the 800 scenario is as you have stated is that the = > answerer will not know the original called identity and will not be=20 > able to correctly handle the call. As more generic call centres are=20 > used which will answer calls on behalf of many different organizations = > using CTI and the original called identity to have to implement a=20 > generic system asking the caller who he originally called appear=20 > unprofessional, is inefficient and unproductive. > [MB2] And, as I noted, it is rare for a call centre to route a call=20 > directly to an agent without a user providing some sort of input. Even = > companies like American Airlines, even though they have the info that=20 > I enter via the IVR, they still ask some basic questions and there are = > times when they have to reroute me. I don't think we can totally=20 > automate things. And, again, once the call hits the domain that is=20 > responsible for that 800 number the entities in that domain have=20 > control over how they muck with the R-URI, such that they should be=20 > able to use any IVR info to appropriately direct the call - it's not=20 > the number that's meaningful, but how the system gets the call to the=20 > right user and the additional information they provide as the call is=20 > presented to the agent. I would honestly think that having something=20 > other than an 800 number show up on the display would be far more=20 > useful and in my experience in the systems I developed we're usually=20 > talking about CTI interfaces so you have a lot you can do. And,=20 > actually all of this really doesn't matter in that you MUST be able to = > handle this situation independent of the privacy since History-Info is = > optional, you need default behavior assigned. [/MB2] > > We have an opportunity to allow presentation of specific identities=20 > and to solve this particular problem so we should take it. > [MB2] The most we can do is to document the risks/impacts of the use=20 > of the Privacy headers at the R-URI level. There is already general=20 > text in > 4244 and 4244bis that the privacy may impact whether the applications=20 > get the information. And, as I noted before, most commercial systems=20 > are using B2BUAs which will allow you far more control over the use of = > the Privacy headers in the network. But, again, I don't think that's=20 > something that should be address in 4244bis. [/MB2] > > I hope that we can get some wider discussion on this issue so a more=20 > general consensus can be obtained. > > Regards > > Ian > > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 24 June 2009 17:27 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Francois Audet > Subject: RE: 4244bis and privacy > > Hi Ian, > > Responses inline below [MB]. > > Mary.=20 > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, June 24, 2009 10:37 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > Mary, > > I was not proposing that we change the handling of H-I which is based=20 > upon local policy. If that causes an issue for a network operator then = > they can modify their local policy accordingly or arrange with the=20 > proxy vendor to modify their equipment to be more flexible with=20 > regards to policy. > > Can you clarify for me: > > If you have a Privacy header with either "session" or "header" doe=20 > this impact the H-I entries or will only a value of "history" impact=20 > the H-I entries? > [MB] Yes, both "session" and "header" level privacy, consistent with=20 > RFC 3323, mandate that entries be anonymized or dropped, with the=20 > latter being the recommendation for "session" level privacy. RFC 4244=20 > mandated that they be dropped and 4244bis recommends they be=20 > anonymized. The original intent for the value of "history" was for the = > tagging of the individual entries, but you end up getting the header=20 > level functionality as well. [/MB] > > If you have a Privacy header with a value of "none" and a H-I entry=20 > with Privacy header parameter with value "history" what is the privacy = > of the individual H-I entry? > [MB] We did not explicitly address the "none" in RFC 4244, but the=20 > general statement is the privacy headers at the request level override = > any at the hi-entry level. [/MB] > > From reading RFC4244 a Privacy header with value "history" will=20 > effectively make all H-I entries private and there is currently no=20 > option to include a H-I Privacy header parameter with value "none". > [MB] Correct, per my comment above. [/MB] > > H-I at present allows the inclusion of Privacy header parameters to=20 > explicitly express privacy for an individual H-I entry but a single=20 > node which includes a header "Privacy: history" makes all H-I entries=20 > private even if this is not the requirements for the specific URI. > [MB] Correct, but the only node that should add the header is a node=20 > which is responsible for the domain associated with the Request URI in = > the incoming request or is authorized to do so. [/MB] > > I will admit that having worked in a telephony environment for a long=20 > time I am used to having privacy of identities set on a per number=20 > basis and the relative inflexibility of the IETF Privacy header is=20 > relatively restrictive as to specifying which identities may be=20 > presented and which not. > [MB] Yes, this is an entirely different paradigm. I developed=20 > telephony s/w for over a decade and this is entirely different - it=20 > provides a lot more flexibility, which makes things far, far less=20 > deterministic than what you have in telephony switches where your=20 > routing and translations are configured for the most part, with just a = > few capabilities for controlling the privacy and it's a closed = network. > > With RFC4244/4244bis, there MUST be a mechanism at the UAS or end=20 > application that can handle a request that doesn't have the=20 > appropriate information either because nodes didn't support=20 > History-Info or some random node in the network applied privacy (which = > I think is highly > unlikely) - this is normative per section 5 of RFC 4244. So, the=20 > worst case scenario I see for this 800 service (which will get to the = > right UAS but without the exact 800 number that was dialed) is that it = > goes to a default ACD group/customer service agent, etc. who then=20 > needs to gather the appropriate information and in my experience this=20 > is often an IVR system these days. So, the service is not broken when = > privacy is applied in an undesireable manner, it's just not optimal. > This is something that should be addressed in the target-uri draft=20 > which has all the details of how specific services use History-Info. > One other thing to consider is that most networks that are emulating=20 > telephony type features use B2BUAs, which follow the UAS/UAC rules for = > the header rather than the proxy rules, noting that the UAC can set=20 > the Privacy header to whatever value it sees as appropriate for the = request. > [/MB] > > > Regards > > Ian > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: 24 June 2009 15:48 > To: Ian Elz > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Francois Audet > Subject: RE: 4244bis and privacy > > Hi Ian, > > I do not believe we should do the "override" behavior as I think that=20 > violates RFC 3323, as the "history" is really a subset of the cases=20 > whereby a UAC or proxy would add "session" or "header" to the request. > And, the latter two cases have the same (undesireable) result. I = agree > this impacts your services, but we can't mandate that proxies provide=20 > information that might violate their local policies and indeed a=20 > proxy's local policies can result in the information being anonymized=20 > (or removed if they can't anonymize) even in the "none" case. > > I do believe it's reasonable that we strongly recommend that the=20 > request level (versus specific hi-entries) not be used and if it is=20 > used, the consequence is that some services will not have the=20 > information they need - this was the gist of my previous response (to=20 > which I did not get any additional feedback). Now, we could add some = text that the "none" > case SHOULD be used (e.g., added by first hop proxy) if it is desired=20 > that the information not be subject to privacy restrictions. I do not=20 > think it is then particularly useful to add logic around the proxy=20 > then being able to tag the entries within their domain as subject to = privacy. > I think that conflicts with the intent of the request level "none". > However, as I mention above, per the current text, a proxy can (based=20 > on local policy) remove entries - so a proxy can capture hi within=20 > their domain and not forward any of that information to the next hop=20 > in another domain - you already have that functionality. But, I think = > this introduces the general problem that you might be impacting other=20 > services further down the line, which I thought was the problem you=20 > were wanting to solve - not specifically your example service but, for = > example, in the case that someone is debugging and they want the=20 > entire history, so depending upon the service, this is also=20 > undesirable behavior. > > > Regards, > Mary.=20 > > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com] > Sent: Wednesday, June 24, 2009 2:57 AM > To: Barnes, Mary (RICH2:AR00) > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > sipcore@ietf.org; Audet, Francois (SC100:3055) > Subject: RE: 4244bis and privacy > > > Mary, > > [I have added the list to this thread for wider comment.] > > In the previous discussions I commented that in RFC4424 that a Privacy = > header with value "history" effectively makes all H-I entries private=20 > with the result that the H-I entries may be removed. > > There has now been a comprehensive discussion on indication of the=20 > initial 'target' to the final recipient for call handling purposes. > > The main use case related to a freephone example where the answering=20 > location may be a call centre where the original freephone number may=20 > be required for correct call handling. > > If you now consider the following example (modified from Francois'=20 > text in the latest draft - excuse any errors that I may have inserted) > > INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx > Privacy: history > History-Info: > ;index=3D1;rt;aor = (1) > History-Info: ;index=3D1.1;mp;aor > (2) > History-Info: ;index=3D1.1.1;rc > (3) > > In this case due to the Privacy header all of the H-I entries are=20 > considered private and the +18001234567 will not be delivered to the=20 > final destination with the result that call handling may not be = correct. > The Privacy header may have been inserted by any of the nodes which=20 > routed the message and inserted a H-I entry. > > If however the H-I was allowed to include a header parameter of=20 > "?Privacy=3Dnone" in the H-I entry and that an explicit H-I entry=20 > privacy value would be considered to have precedence over a Privacy=20 > header with a value of "history" then the mapping of the +18001234567=20 > could be explicitly specified as not private and may be passed on. > > Thus when the mapping from sip:+18001234567@example.com to=20 > sip:bob@biloxi.example.com when H-I entry (2) above is included could=20 > also insert the Privacy header parameter in H-I entry (1). > > Thus the message would appear as follows: > > INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx > Privacy: history > History-Info: > = ;index=3D= 1;rt; > ao > r > History-Info: ;index=3D1.1;mp;aor > History-Info: ;index=3D1.1.1;rc > > This would result in all the H-I entries except (1) being considered=20 > private with the result that the =3D1800... Number is passed for call=20 > handling purposes. > > This change is backward compatible with the existing implementation as = > any node using the existing functionality as defined in RFC4244 will=20 > continue to be supported. > > The alternative is to remove the ability to include the value = "history" > in the Privacy header and only allow this value in the Privacy header=20 > parameter. This alternative is not backward compatible. > > Without this change a single node in the message path which includes a = > header "Privacy: history" will prevent delivery of the aor and thus=20 > prevent proper call handling. > > Ian Elz > > > > -----Original Message----- > From: Christer Holmberg > Sent: 23 June 2009 19:40 > To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida=20 > Schubert > Cc: Ian Elz > Subject: RE: 4244bis and privacy > > =20 > Hi, > > I include Ian, so he can comment to your resposne himself. > > Regards, > > Christer > > > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Tuesday, June 23, 2009 9:40 PM > To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida=20 > Schubert > Subject: RE: 4244bis and privacy > > Here was the thread of response and the last comment was from Ian that = > he would consider the response: > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html > > And, there was not agreement on the "none" but rather to qualify the=20 > SHOULD NOT forward. However, in the sipcore-4244bis-00, rather than=20 > changing the text such that the headers SHOULD be removed, we=20 > recommend that they be anonymized (in section 4.3.3.3.1). That is=20 > entirely consistent with RFC 3324 and thus we have removed the=20 > recommendations to remove the headers entirely. However, that changed=20 > never got done in section 3.2, so we would need to change this: > "Thus, the History- Info header > SHOULD NOT be included in Requests where the requestor has = indicated > a priv-value of Session- or Header-level privacy." > > But, I'm really beginning to be of the mindset that we should just=20 > remove all the subsections of section 3 (i.e., leave the text in the=20 > upper level section), so we don't have to keep worrying about=20 > consistency. > > So, lets either fixt the text in 3.2 or remove altogether and then I=20 > think we are really at the point of needing to submit this version so=20 > folks that actually have an interest in it can review the updated=20 > document. > > Mary.=20 > > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Tuesday, June 23, 2009 1:10 PM > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); Hans Erik = > van Elburg; Shida Schubert > Subject: 4244bis and privacy > > > Hi, > > Below is a comment/proposal which one of my collegues (Ian Elz) gave=20 > on the list a while ago, when the first version of 4244bis was=20 > submitted, but was not incorporated. Do you think it would be useful? > > ------- > > While the HI approach to target may solve the problem of being able to = > deliver the target URI to the final destination there is no guarantee=20 > that it will actually be delivered. > > The problem arises with how Privacy is defined for HI. > > 4424 defines a new Privacy value "history" which may be placed in=20 > either the Privacy header or as a header parameter to the HI entry. > > If one node uses the former option "Privacy: history" then this will=20 > make all headers private and will result in all HI entries being=20 > removed or made anonymous when the message containing the HI is=20 > delivered to the user. > > There is a simple solution to this and that is to also allow the use=20 > of the "none" Privacy value as a header parameter in the HI entry.=20 > This would explicitly state that no privacy is required to the HI=20 > entry and this would override a "history" value in the Privacy header. > > I pointed this out to Mary when the 4424bis draft was first published=20 > but the change has not been made in the latest draft. > > The change is backward compatible and would not cause an issue with=20 > any existing implementations. > > ------ > > Regards, > > Christer > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > =20 From gao.yang2@zte.com.cn Thu Jun 25 19:12:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E0E3A6AB1; Thu, 25 Jun 2009 19:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.635 X-Spam-Level: X-Spam-Status: No, score=-97.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZZkGQL46vbz; Thu, 25 Jun 2009 19:12:56 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id E52BD3A6A99; Thu, 25 Jun 2009 19:12:55 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111642001811080; Fri, 26 Jun 2009 08:24:44 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 59484.3950215940; Fri, 26 Jun 2009 08:34:08 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n5Q0eGqe071367; Fri, 26 Jun 2009 08:40:16 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4A438271.2030909@alcatel-lucent.com> To: "Vijay K. Gurbani" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 26 Jun 2009 09:39:45 +0900 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-06-26 08:40:17, Serialize complete at 2009-06-26 08:40:17 Content-Type: multipart/alternative; boundary="=_alternative 0003ACA9C82575E1_=" X-MAIL: mse1.zte.com.cn n5Q0eGqe071367 Cc: SIPCORE , sipcore-bounces@ietf.org Subject: Re: [sipcore] Input requested on how to proceed with the essential corrections to RFC 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 02:12:58 -0000 This is a multipart message in MIME format. --=_alternative 0003ACA9C82575E1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkFzIGN1cnJlbnRseSwgY29ycmVjdGlvbiBvZiB0ZXh0cyBmb3IgUkZDMzI2MSBhcmUg aW4gZGlmZmVyZW50IHN0YXRlcywgDQpzdWNoIGFzIHNvbWUgaW4gUkZDIHN0YXRlcywgc29tZSBp biAgV0cgZHJhZnQgc3RhdGVzIGFuZCBvdGhlcnMgaW4gDQpQZXJzb25hbCBkcmFmdCBzdGF0ZXMu DQpTbywgY29tYmluYXRpb24gb2YgdGhlIGFsbCBtYXkgYmUgYSB1bm1hbmFnZWFibGUgd29yay4g RnVydGhlciwgbWFraW5nIHRoZSANCnRleHRzIGluIFJGQyBzdGF0ZXMgaW50byBhIG5ldyBXRyBk cmFmdC9SRkMgbWF5IG1ha2UgcGVvcGxlIA0KY29uZnVzaW5nKGVzcGVjaWFsbHkgZm9yIGNpdGF0 aW9uIG9mIHN1Y2ggUkZDcykuDQoNClNvLCBJIHRoaW5rIG1ha2luZyB0aGVtIHNlcGFyYXRlbHkg bWlnaHQgYmV0dGVyLg0KQW5kIEkgdGhpbmsgd2UgY2FuIHVzaW5nIGEgbmV3IHRleHQgYXMgdGhl IGxpc3Qgb2YgdGhlIGN1cnJlbnRseSANCmNvcnJlbGF0aXZlIGFjdGl2ZSBkcmFmdC9SRkNzLiBU aGVuLCBwZW9wbGUgd2FudGluZyB0byBoYXZlIGEgbWFpbiB2aWV3IG9mIA0KUkZDJ3MgY29ycmVj dGlvbiBjYW4gcmVmZXIgdG8gdGhhdCBsaXN0Lg0KDQpUaGFua3MsDQoNCkdhbw0KDQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6 IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJA enRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNCiJW aWpheSBLLiBHdXJiYW5pIiA8dmtnQGFsY2F0ZWwtbHVjZW50LmNvbT4gDQq3orz+yMs6ICBzaXBj b3JlLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMDktMDYtMjUgMjE6NTgNCg0KytW8/sjLDQpHb256YWxv IENhbWFyaWxsbyA8R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tPg0Ks63LzQ0KU0lQQ09S RSA8c2lwY29yZUBpZXRmLm9yZz4NCtb3zOINClJlOiBbc2lwY29yZV0gSW5wdXQgcmVxdWVzdGVk IG9uIGhvdyB0byBwcm9jZWVkIHdpdGggdGhlIGVzc2VudGlhbCANCmNvcnJlY3Rpb25zIHRvIFJG QyAzMjYxDQoNCg0KDQoNCg0KDQpHb256YWxvIENhbWFyaWxsbyB3cm90ZToNClsuLi5dDQo+IFRo ZSBjb25jcmV0ZSBkZWNpc2lvbiB3ZSBoYXZlIHRvIG1ha2UgaXMgd2hldGhlciBpdCBtYWtlcyBz ZW5zZSB0byBtZXJnZSANCg0KPiB0aGUgZm9sbG93aW5nIGRyYWZ0cyBpbiBhIGJhdGNoLCBwZXIg dGhlIGVzc2VudGlhbCBjb3JyZWN0aW9ucyBwcm9jZXNzLCANCj4gb3Igd2hldGhlciB3ZSBhZHZh bmNlIHRoZXNlIGRyYWZ0cyBpbmRlcGVuZGVudGx5Lg0KPiANCj4gaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1zaXAtaXB2Ni1hYm5mLWZpeC0wMw0KPiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1zcGFya3Mtc2lwLWludmZpeC0wMw0KPiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1jYW1hcmlsbG8tc2lwcGluZy1yZWludml0ZS0wMA0KPiANCj4g V2Ugd291bGQgYXBwcmVjaWF0ZSB0aGUgZmVlZGJhY2sgb2YgdGhlIFdHIG9uIHRoaXMgaXNzdWUg c28gdGhhdCB3ZSBjYW4gDQo+IG1ha2UgcHJvZ3Jlc3MgdXBkYXRpbmcgUkZDIDMyNjEuDQoNCkdv bnphbG86IEkgZG9uJ3QgaGF2ZSBhIGhhcmQgb3BpbmlvbiBvbmUgd2F5IG9yIHRoZSBvdGhlci4N Cg0KVGhhdCBzYWlkLCBhIHF1aWNrIGFuYWx5c2lzIG9uIHRoZSBleGlzdGluZyBjb3JwdXMgb2Yg UkZDcyB0bw0Kc2VlIHdoaWNoIFJGQyBoYXMgYmVlbiB1cGRhdGVkIGJ5IHRoZSBtb3N0IG51bWJl ciBvZiBSRkNzDQpyZXZlYWxzIHRoYXQgcmZjMTAzNSBoYXMgYmVlbiB1cGRhdGVkIGJ5IDIwIFJG Q3MgKGFuZCByZmMxMDM1DQppcyBhIHN0YW5kYXJkcyB0cmFjayBkb2N1bWVudCksIGZvbGxvd2Vk IGJ5IHJmYzEwMzQgKDE0IHVwZGF0ZXMuKQ0KVGhlIG5leHQgaGlnaGVzdCBkaXN0cmlidXRpb24g YmluIGZyb20gdGhlcmUgY2x1c3RlcnMNCmFyb3VuZCAzLTUgdXBkYXRlcy4NCg0KU28sIGlmIHRo ZSBwYXN0IGluIHRoZSBmb3JtIG9mIHJmYzEwMzUgaXMgYW55IGd1aWRlLCB0aGVuDQpyZmMzMjYx IGhhcyBhIHdheSB0byBnbywgYW5kIHdlIHNob3VsZCBiZSBva2F5IGJ5IGhhdmluZyBlYWNoDQpp bmRpdmlkdWFsIGRvY3VtZW50IHVwZGF0ZSByZmMzMjYxIGluZGVwZW5kZW50bHkuDQoNCk9yIGFs dGVybmF0aXZlbHksIHlvdSBjYW4gYWR2YW5jZSB0aGUgZHJhZnRzIHRoYXQgaGF2ZQ0KYmVlbiBw cmV2aW91c2x5IGlkZW50aWZpZWQgYXMgcGFydCBvZiB0aGUgZXNzZW50aWFsIGNvcnJlY3Rpb25z DQpwcm9jZXNzIGluIGEgYmF0Y2gsIGJ1dCBvbmNlIHRoYXQgaXMgZG9uZSwgcmV2ZXJ0IGJhY2sg dG8gdGhlDQpub3JtYWwgbW9kZSBvZiBvcGVyYXRpb25zIC0tIGVhY2ggZmlsZSB1cGRhdGVzIHRo ZSBiYXNlIFJGQyBpbg0KaXRzIG93biBtYW5uZXIuDQoNCi0gdmlqYXkNCi0tIA0KVmlqYXkgSy4g R3VyYmFuaSwgQmVsbCBMYWJvcmF0b3JpZXMsIEFsY2F0ZWwtTHVjZW50DQoxOTYwIEx1Y2VudCBM YW5lLCBSbS4gOUMtNTMzLCBOYXBlcnZpbGxlLCBJbGxpbm9pcyA2MDU2NiAoVVNBKQ0KRW1haWw6 IHZrZ0B7YWxjYXRlbC1sdWNlbnQuY29tLGJlbGwtbGFicy5jb20sYWNtLm9yZ30NCldlYjogICBo dHRwOi8vZWN0LmJlbGwtbGFicy5jb20vd2hvL3ZrZy8NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoN Cg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVy J3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwu IFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5 IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBj b21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21p dHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhl IHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNz ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlm eSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0 aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVz c2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNw YW0gc3lzdGVtLg0K --=_alternative 0003ACA9C82575E1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QXMgY3VycmVudGx5LCBjb3JyZWN0aW9u IG9mIHRleHRzIGZvcg0KUkZDMzI2MSBhcmUgaW4gZGlmZmVyZW50IHN0YXRlcywgc3VjaCBhcyBz b21lIGluIFJGQyBzdGF0ZXMsIHNvbWUgaW4gJm5ic3A7V0cNCmRyYWZ0IHN0YXRlcyBhbmQgb3Ro ZXJzIGluIFBlcnNvbmFsIGRyYWZ0IHN0YXRlcy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPlNvLCBjb21iaW5hdGlvbiBvZiB0aGUgYWxsIG1heSBiZSBhDQp1bm1h bmFnZWFibGUgd29yay4gRnVydGhlciwgbWFraW5nIHRoZSB0ZXh0cyBpbiBSRkMgc3RhdGVzIGlu dG8gYSBuZXcgV0cNCmRyYWZ0L1JGQyBtYXkgbWFrZSBwZW9wbGUgY29uZnVzaW5nKGVzcGVjaWFs bHkgZm9yIGNpdGF0aW9uIG9mIHN1Y2ggUkZDcykuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TbywgSSB0aGluayBtYWtpbmcgdGhlbSBzZXBhcmF0ZWx5 IG1pZ2h0DQpiZXR0ZXIuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5BbmQgSSB0aGluayB3ZSBjYW4gdXNpbmcgYSBuZXcgdGV4dA0KYXMgdGhlIGxpc3Qgb2YgdGhl IGN1cnJlbnRseSBjb3JyZWxhdGl2ZSBhY3RpdmUgZHJhZnQvUkZDcy4gVGhlbiwgcGVvcGxlDQp3 YW50aW5nIHRvIGhhdmUgYSBtYWluIHZpZXcgb2YgUkZDJ3MgY29ycmVjdGlvbiBjYW4gcmVmZXIg dG8gdGhhdCBsaXN0LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+VGhhbmtzLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+R2FvPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiBaaXAgJm5ic3A7ICZu YnNwOzogMjEwMDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiBUZWwyICZu YnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29t LmNuPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdp ZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7VmlqYXkgSy4g R3VyYmFuaSZxdW90Ow0KJmx0O3ZrZ0BhbGNhdGVsLWx1Y2VudC5jb20mZ3Q7PC9iPiA8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7c2lwY29y ZS1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjIwMDktMDYtMjUgMjE6NTg8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+R29uemFsbyBDYW1hcmlsbG8gJmx0O0dvbnphbG8uQ2FtYXJp bGxvQGVyaWNzc29uLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlNJUENPUkUgJmx0O3NpcGNv cmVAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW3NpcGNvcmVdIElucHV0IHJl cXVlc3RlZCBvbiBob3cNCnRvIHByb2NlZWQgd2l0aCB0aGUgZXNzZW50aWFsIGNvcnJlY3Rpb25z IHRvIFJGQyAzMjYxPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yPjx0dD5Hb256YWxvIENhbWFyaWxsbyB3cm90ZTo8YnI+DQpbLi4uXTxicj4NCiZn dDsgVGhlIGNvbmNyZXRlIGRlY2lzaW9uIHdlIGhhdmUgdG8gbWFrZSBpcyB3aGV0aGVyIGl0IG1h a2VzIHNlbnNlIHRvDQptZXJnZSA8YnI+DQomZ3Q7IHRoZSBmb2xsb3dpbmcgZHJhZnRzIGluIGEg YmF0Y2gsIHBlciB0aGUgZXNzZW50aWFsIGNvcnJlY3Rpb25zIHByb2Nlc3MsDQo8YnI+DQomZ3Q7 IG9yIHdoZXRoZXIgd2UgYWR2YW5jZSB0aGVzZSBkcmFmdHMgaW5kZXBlbmRlbnRseS48YnI+DQom Z3Q7IDxicj4NCiZndDsgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zaXAt aXB2Ni1hYm5mLWZpeC0wMzxicj4NCiZndDsgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtc3BhcmtzLXNpcC1pbnZmaXgtMDM8YnI+DQomZ3Q7IGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWNhbWFyaWxsby1zaXBwaW5nLXJlaW52aXRlLTAwPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IFdlIHdvdWxkIGFwcHJlY2lhdGUgdGhlIGZlZWRiYWNrIG9mIHRoZSBXRyBvbiB0aGlzIGlz c3VlIHNvIHRoYXQgd2UNCmNhbiA8YnI+DQomZ3Q7IG1ha2UgcHJvZ3Jlc3MgdXBkYXRpbmcgUkZD IDMyNjEuPGJyPg0KPGJyPg0KR29uemFsbzogSSBkb24ndCBoYXZlIGEgaGFyZCBvcGluaW9uIG9u ZSB3YXkgb3IgdGhlIG90aGVyLjxicj4NCjxicj4NClRoYXQgc2FpZCwgYSBxdWljayBhbmFseXNp cyBvbiB0aGUgZXhpc3RpbmcgY29ycHVzIG9mIFJGQ3MgdG88YnI+DQpzZWUgd2hpY2ggUkZDIGhh cyBiZWVuIHVwZGF0ZWQgYnkgdGhlIG1vc3QgbnVtYmVyIG9mIFJGQ3M8YnI+DQpyZXZlYWxzIHRo YXQgcmZjMTAzNSBoYXMgYmVlbiB1cGRhdGVkIGJ5IDIwIFJGQ3MgKGFuZCByZmMxMDM1PGJyPg0K aXMgYSBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQpLCBmb2xsb3dlZCBieSByZmMxMDM0ICgxNCB1 cGRhdGVzLik8YnI+DQpUaGUgbmV4dCBoaWdoZXN0IGRpc3RyaWJ1dGlvbiBiaW4gZnJvbSB0aGVy ZSBjbHVzdGVyczxicj4NCmFyb3VuZCAzLTUgdXBkYXRlcy48YnI+DQo8YnI+DQpTbywgaWYgdGhl IHBhc3QgaW4gdGhlIGZvcm0gb2YgcmZjMTAzNSBpcyBhbnkgZ3VpZGUsIHRoZW48YnI+DQpyZmMz MjYxIGhhcyBhIHdheSB0byBnbywgYW5kIHdlIHNob3VsZCBiZSBva2F5IGJ5IGhhdmluZyBlYWNo PGJyPg0KaW5kaXZpZHVhbCBkb2N1bWVudCB1cGRhdGUgcmZjMzI2MSBpbmRlcGVuZGVudGx5Ljxi cj4NCjxicj4NCk9yIGFsdGVybmF0aXZlbHksIHlvdSBjYW4gYWR2YW5jZSB0aGUgZHJhZnRzIHRo YXQgaGF2ZTxicj4NCmJlZW4gcHJldmlvdXNseSBpZGVudGlmaWVkIGFzIHBhcnQgb2YgdGhlIGVz c2VudGlhbCBjb3JyZWN0aW9uczxicj4NCnByb2Nlc3MgaW4gYSBiYXRjaCwgYnV0IG9uY2UgdGhh dCBpcyBkb25lLCByZXZlcnQgYmFjayB0byB0aGU8YnI+DQpub3JtYWwgbW9kZSBvZiBvcGVyYXRp b25zIC0tIGVhY2ggZmlsZSB1cGRhdGVzIHRoZSBiYXNlIFJGQyBpbjxicj4NCml0cyBvd24gbWFu bmVyLjxicj4NCjxicj4NCi0gdmlqYXk8YnI+DQotLSA8YnI+DQpWaWpheSBLLiBHdXJiYW5pLCBC ZWxsIExhYm9yYXRvcmllcywgQWxjYXRlbC1MdWNlbnQ8YnI+DQoxOTYwIEx1Y2VudCBMYW5lLCBS bS4gOUMtNTMzLCBOYXBlcnZpbGxlLCBJbGxpbm9pcyA2MDU2NiAoVVNBKTxicj4NCkVtYWlsOiB2 a2dAe2FsY2F0ZWwtbHVjZW50LmNvbSxiZWxsLWxhYnMuY29tLGFjbS5vcmd9PGJyPg0KV2ViOiAm bmJzcDsgaHR0cDovL2VjdC5iZWxsLWxhYnMuY29tL3doby92a2cvPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzaXBjb3JlIG1haWxpbmcg bGlzdDxicj4NCnNpcGNvcmVAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpcGNvcmU8YnI+DQo8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48 cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5i c3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMm bmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwm bmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBp ZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0 byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZu YnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50 cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVy cy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJh bnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJz cDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3Vz ZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5i c3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJ ZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZu YnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtv cmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3Zp ZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2Fy ZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVy Lg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNw O2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJz cDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0003ACA9C82575E1_=-- From adam@nostrum.com Thu Jun 25 19:47:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CFF43A67E3 for ; Thu, 25 Jun 2009 19:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.375 X-Spam-Level: X-Spam-Status: No, score=-1.375 tagged_above=-999 required=5 tests=[AWL=-1.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLdwxg7T21Mg for ; Thu, 25 Jun 2009 19:47:54 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 327863A6849 for ; Thu, 25 Jun 2009 19:47:53 -0700 (PDT) Received: from [192.168.0.128] (ppp-70-249-149-101.dsl.rcsntx.swbell.net [70.249.149.101]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n5Q2m58L039370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Jun 2009 21:48:06 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A4436E5.8080404@nostrum.com> Date: Thu, 25 Jun 2009 21:48:05 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090223 Lightning/1.0pre Thunderbird/3.0b2 MIME-Version: 1.0 To: SIPCORE Content-Type: multipart/alternative; boundary="------------070307040709040202060406" Received-SPF: pass (nostrum.com: 70.249.149.101 is authenticated by a trusted mechanism) Cc: gao.yang2@zte.com.cn Subject: [sipcore] [Fwd: Re: Re: Input requested on how to proceed with the essential corrections to RFC 3261] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 02:47:56 -0000 This is a multi-part message in MIME format. --------------070307040709040202060406 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit For some reason, the IETF mailing list software misprocessed this message as a bounce. I'm forwarding it to the list. /a -------- Original Message -------- Subject: Re: Re: [sipcore] Input requested on how to proceed with the essential corrections to RFC 3261 Date: Fri, 26 Jun 2009 09:39:45 +0900 From: gao.yang2@zte.com.cn To: Vijay K. Gurbani CC: Gonzalo Camarillo , SIPCORE , sipcore-bounces@ietf.org Hi, As currently, correction of texts for RFC3261 are in different states, such as some in RFC states, some in WG draft states and others in Personal draft states. So, combination of the all may be a unmanageable work. Further, making the texts in RFC states into a new WG draft/RFC may make people confusing(especially for citation of such RFCs). So, I think making them separately might better. And I think we can using a new text as the list of the currently correlative active draft/RFCs. Then, people wanting to have a main view of RFC's correction can refer to that list. Thanks, Gao =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== *"Vijay K. Gurbani" * ·˘ĽţČË: sipcore-bounces@ietf.org 2009-06-25 21:58 ĘŐĽţČË Gonzalo Camarillo ł­ËÍ SIPCORE Ö÷Ěâ Re: [sipcore] Input requested on how to proceed with the essential corrections to RFC 3261 Gonzalo Camarillo wrote: [...] > The concrete decision we have to make is whether it makes sense to merge > the following drafts in a batch, per the essential corrections process, > or whether we advance these drafts independently. > > http://tools.ietf.org/html/draft-ietf-sip-ipv6-abnf-fix-03 > http://tools.ietf.org/html/draft-sparks-sip-invfix-03 > http://tools.ietf.org/html/draft-camarillo-sipping-reinvite-00 > > We would appreciate the feedback of the WG on this issue so that we can > make progress updating RFC 3261. Gonzalo: I don't have a hard opinion one way or the other. That said, a quick analysis on the existing corpus of RFCs to see which RFC has been updated by the most number of RFCs reveals that rfc1035 has been updated by 20 RFCs (and rfc1035 is a standards track document), followed by rfc1034 (14 updates.) The next highest distribution bin from there clusters around 3-5 updates. So, if the past in the form of rfc1035 is any guide, then rfc3261 has a way to go, and we should be okay by having each individual document update rfc3261 independently. Or alternatively, you can advance the drafts that have been previously identified as part of the essential corrections process in a batch, but once that is done, revert back to the normal mode of operations -- each file updates the base RFC in its own manner. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --------------070307040709040202060406 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: 8bit For some reason, the IETF mailing list software misprocessed this message as a bounce. I'm forwarding it to the list.

/a

-------- Original Message --------
Subject: Re: Re: [sipcore] Input requested on how to proceed with the essential corrections to RFC 3261
Date: Fri, 26 Jun 2009 09:39:45 +0900
From: gao.yang2@zte.com.cn
To: Vijay K. Gurbani <vkg@alcatel-lucent.com>
CC: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, SIPCORE <sipcore@ietf.org>, sipcore-bounces@ietf.org



Hi,

As currently, correction of texts for RFC3261 are in different states, such as some in RFC states, some in  WG draft states and others in Personal draft states.
So, combination of the all may be a unmanageable work. Further, making the texts in RFC states into a new WG draft/RFC may make people confusing(especially for citation of such RFCs).

So, I think making them separately might better.
And I think we can using a new text as the list of the currently correlative active draft/RFCs. Then, people wanting to have a main view of RFC's correction can refer to that list.

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================


"Vijay K. Gurbani" <vkg@alcatel-lucent.com>
·˘ĽţČË:  sipcore-bounces@ietf.org

2009-06-25 21:58

ĘŐĽţČË
 Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
ł­ËÍ
 SIPCORE <sipcore@ietf.org>
Ö÷Ěâ
 Re: [sipcore] Input requested on how to proceed with the essential corrections to RFC 3261







Gonzalo Camarillo wrote:
[...]
> The concrete decision we have to make is whether it makes sense to merge
> the following drafts in a batch, per the essential corrections process,
> or whether we advance these drafts independently.
>
> http://tools.ietf.org/html/draft-ietf-sip-ipv6-abnf-fix-03
> http://tools.ietf.org/html/draft-sparks-sip-invfix-03
> http://tools.ietf.org/html/draft-camarillo-sipping-reinvite-00
>
> We would appreciate the feedback of the WG on this issue so that we can
> make progress updating RFC 3261.

Gonzalo: I don't have a hard opinion one way or the other.

That said, a quick analysis on the existing corpus of RFCs to
see which RFC has been updated by the most number of RFCs
reveals that rfc1035 has been updated by 20 RFCs (and rfc1035
is a standards track document), followed by rfc1034 (14 updates.)
The next highest distribution bin from there clusters
around 3-5 updates.

So, if the past in the form of rfc1035 is any guide, then
rfc3261 has a way to go, and we should be okay by having each
individual document update rfc3261 independently.

Or alternatively, you can advance the drafts that have
been previously identified as part of the essential corrections
process in a batch, but once that is done, revert back to the
normal mode of operations -- each file updates the base RFC in
its own manner.

- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--------------070307040709040202060406-- From john.elwell@siemens-enterprise.com Fri Jun 26 00:38:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDA6B3A68B3 for ; Fri, 26 Jun 2009 00:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzklOoCvxTMm for ; Fri, 26 Jun 2009 00:38:36 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id D47BA3A683A for ; Fri, 26 Jun 2009 00:38:35 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KLU006214UJW3@siemenscomms.co.uk> for sipcore@ietf.org; Fri, 26 Jun 2009 08:30:19 +0100 (BST) Date: Fri, 26 Jun 2009 08:30:17 +0100 From: "Elwell, John" In-reply-to: <1ECE0EB50388174790F9694F77522CCF1EB26AB5@zrc2hxm0.corp.nortel.com> To: Mary Barnes , R.Jesske@telekom.de, ietf.hanserik@gmail.com Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00213AA4C@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] 4244bis and privacy Thread-Index: Acn11AWR+Z7be2FAQvKtnWIFO4vfcAAB1KHQAABgLvAAFKai8A== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4048F809B@S4DE8PSAAQB.mitte.t-com.de> <4A43DEC9.1020802@gmail.com> <9886E5FCA6D76549A3011068483A4BD4048F80AC@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1EB26AB5@zrc2hxm0.corp.nortel.com> Cc: ian.elz@ericsson.com, sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 07:38:38 -0000 =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: 25 June 2009 22:45 > To: R.Jesske@telekom.de; ietf.hanserik@gmail.com > Cc: ian.elz@ericsson.com; sipcore@ietf.org; shida@agnada.com > Subject: Re: [sipcore] 4244bis and privacy >=20 > Roland, >=20 > The reason you can't have "none" at the request level and=20 > "history" at the entry level is because RFC 3323 states that=20 > you MUST NOT apply privacy to the message. Even if you put=20 > "history" in the entries, the privacy service would just=20 > ignore that - per RFC 3323. So, if you want to change that=20 > behavior, then RFC 3323 should be changed - i.e., the MUST=20 > NOT for the "none" could be changed to a SHOULD NOT and then=20 > a general statement about possible exceptions. Then, we could=20 > add something to RFC 4244 for this case. But, changing RFC=20 > 3323 is totally out of scope for what we are currently working on. =20 [JRE] I would interpret privacy 'none' in RFC 3323 as meaning that a = downstream entity must not anonymise or remove any information that the = UAC has already placed in the request. If a downstream entity chooses: - not to add H-I, - to add anonymised H-I, or - to anonymise an H-I entry that some intermediate entity has added, I don't see that as being in violation of what the UAC has requested. John >=20 > That all said, I would sure think that if you are leaving a=20 > "trusted network" that you have a B2BUA in there, as I've=20 > said in other threads. Thus, the B2BUA builds a new request=20 > and certainly can add a privacy header that it believes is=20 > appropriate since the outgoing request is done by the UAC=20 > function of a B2BUA.=20 >=20 > Mary.=20 >=20 >=20 > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de]=20 > Sent: Thursday, June 25, 2009 4:32 PM > To: ietf.hanserik@gmail.com > Cc: Barnes, Mary (RICH2:AR00); ian.elz@ericsson.com;=20 > sipcore@ietf.org; shida@agnada.com > Subject: AW: [sipcore] 4244bis and privacy >=20 > Hi Hans Erik, > We have also to take regulatory into consideration. In=20 > Germany the last trusted network is responsible for=20 > anonymising information.=20 >=20 > But nevertheless if Network provider A wants to have History=20 > completely private this operator will set privacy history for=20 > the header. > If the succeeding Operator want to present elements the AS=20 > which adds a entry has then to re label all entries from the=20 > preceding network and the entries from it's own network will=20 > be unmarked within the Header. >=20 > But never the less I fully agree to your last sentence. >=20 > The real Question is if this should really be allowed that a=20 > entry marked with "none" overrules the privacy statement=20 > "history" for the complete header. >=20 > I'm against this behaviour.=20 >=20 > Best Regards >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Gesendet: Donnerstag, 25. Juni 2009 22:32 > An: Jesske, Roland > Cc: mary.barnes@nortel.com; ian.elz@ericsson.com;=20 > sipcore@ietf.org; shida@agnada.com > Betreff: Re: [sipcore] 4244bis and privacy >=20 > Hi Roland, >=20 > I don't understand the argument, by the time that the=20 > History-Info leaves operator A that wishes complete privacy,=20 > all the History-Info headers should be anonymised according=20 > to 4244 and 4244bis. >=20 > What is the point in mandating that operator A to force=20 > operator B to also anonymise the entries "owned" by operator B. >=20 > It is of course without question that each operator has full=20 > privacy control over its own added entries. And each operator=20 > can based on local policy decide to remove the entire history=20 > if it things that is wise to do. >=20 > /Hans Erik >=20 >=20 > R.Jesske@telekom.de wrote: > > Hi Marry and Ian, > > The whole discussion puzzle me. We have specified CDIV=20 > within TISPAN and 3GPP.=20 > > There is described that privacy "none" can be used for=20 > entries. BUT assuming that each entry has its own privacy=20 > statement if needed.=20 > > I fully agree on Mary's comment that a privacy "history"=20 > cannot overruled by a privacy value "none" within a entry.=20 > > There may be operators that would like to keep the whole=20 > History Info private even if entries has other statements, so=20 > the entity could add privacy history to the whole header.=20 > Nothing more. > > > > On the other side a Application Server including a entry=20 > should have the possibility to rewrite the entries so that=20 > instead of "history" for the whole header the all received=20 > entries within the History-Info header will be marked with=20 > "history" and the added header (which shall be presented to=20 > the terminating user) will either be marked with "none" or=20 > will not be marked. > > > > Perhaps a hint could be given, but I do not insist on it. > > > > Best Regards, > > > > Roland > > > > > > > > -----Urspr=FCngliche Nachricht----- > > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im=20 > > Auftrag von Mary Barnes > > Gesendet: Donnerstag, 25. Juni 2009 18:29 > > An: Ian Elz > > Cc: sipcore@ietf.org; Shida Schubert > > Betreff: Re: [sipcore] 4244bis and privacy > > > > Hi Ian, > > > > Responses inline below [MB2]. > > > > Mary. > > > > -----Original Message----- > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > Sent: Thursday, June 25, 2009 10:13 AM > > To: Barnes, Mary (RICH2:AR00) > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > Subject: RE: 4244bis and privacy > > > > Mary, > > > > I am a little concerned about one answer that you gave: > > > > > > If you have a Privacy header with a value of "none" and a H-I entry=20 > > with Privacy header parameter with value "history" what is=20 > the privacy=20 > > of the individual H-I entry? > > [MB] We did not explicitly address the "none" in RFC 4244, but the=20 > > general statement is the privacy headers at the request=20 > level override=20 > > any at the hi-entry level. [/MB] > > =20 > > This means that if privacy is required for an individual=20 > H-I entry but=20 > > the originating user included "Privacy:none" in the request=20 > then there=20 > > is no option to include the real URI in the H-I entry. > > [MB2] I'm confused here - the "none" definition is as you=20 > note below,=20 > > thus "none" prohibits the removal or anonymization of the entries,=20 > > thus I would think you would fine this functionality desireable.=20 > > However, this does not prohibit an entity based on policy=20 > to anonymize=20 > > (or remove entries if privacy is required for that domain if the=20 > > entity does not have access to a privacy service). [/MB2] > > > > This occurs as RFC3323 states in section 4.3: "However, if=20 > the Privacy=20 > > header value of 'none' is specified in a message, privacy services=20 > > MUST NOT perform any privacy function and MUST NOT remove or modify=20 > > the Privacy header." > > > > The only option for an intermediate node including a H-I=20 > entry where=20 > > "Privacy:none" is specified and privacy for the H-I URI is=20 > required is=20 > > to include an anonymous entry or not include the H-I entry. > > [MB2] If privacy is required then yes, you include=20 > anonymous entries=20 > > or don't include. That's the basic privacy mechanism for privacy=20 > > levels of "session" "header" and "history" in the R-URI or=20 > "history"=20 > > in the specific entries, as well as when there is a policy=20 > for privacy=20 > > for the entries added by a specific domain. The "none"=20 > really has no=20 > > influence on the later case per se. [/MB2] > > > > In your previous response you stated that we would violate=20 > RFC3323 if=20 > > we specified additional behaviour for privacy explicitly=20 > stated with a=20 > > URI -n the H-I entry. I don't believe that this is the case=20 > as RFC3323=20 > > only considered privacy in a two party scenario and did not=20 > consider=20 > > third party identities being included in a message between two=20 > > parties. H-I is not the only case where this occurs as the=20 > Referred-By=20 > > header when included in the INVITE (or other request) which results=20 > > from the REFER has the same issue. > > [MB2] I can't necessarily disagree on this one (we can debate it=20 > > either way). But to fix it requires an update to RFC 3323 and=20 > > shouldn't be something that we want to fix in 4244bis. [/MB2] > > > > RFC4244 was the first time that there was a recognition=20 > that privacy=20 > > for these individual third party identities may be=20 > required. To allow=20 > > this explicit statement of privacy to be overridden by a generic=20 > > statement which is applicable to a different user is=20 > counterintuitive. > > [MB2] See my comment above. But, as I have consistently=20 > said, the idea=20 > > that an entity might want to override the "none" is=20 > entirely based on=20 > > policy and 4244 and 4244bis allow privacy to be applied to=20 > the entries=20 > > that are added by that entity if the policy dictates so (and we=20 > > already say that). [/MB2] > > > > The original Privacy header is usually included by or on=20 > behalf of the=20 > > originating user and should not be allowed to specify the=20 > privacy of=20 > > the original called user, e.g. the 800 number, and prevent this=20 > > identity being presented if this user does not have the=20 > same level of privacy. > > [MB2] As I tried to say in a previous response, a random=20 > entity (i.e.,=20 > > one for whom the R-URI is not in a domain under its control) cannot=20 > > add a privacy header to the Request. Per RFC 3323 an entity may add=20 > > the header to a request only if it has the appropriate=20 > > relationship/authorization with the original called user=20 > who intiated=20 > > the request. And, I would find it very surprising if an entity that=20 > > did have responsibility would apply privacy since that would be=20 > > counter intuitive and I would hope that SPs would be judicious in=20 > > specifying the appropriate and inappropriate manner in which the=20 > > proxies they deploy and interface with privatize the messages. The=20 > > protocol CANNOT control this behavior and that's why there is the=20 > > policy clause in 4244 and 4244bis. [/MB2] > > > > The real issue with the 800 scenario is as you have stated=20 > is that the=20 > > answerer will not know the original called identity and will not be=20 > > able to correctly handle the call. As more generic call centres are=20 > > used which will answer calls on behalf of many different=20 > organizations=20 > > using CTI and the original called identity to have to implement a=20 > > generic system asking the caller who he originally called appear=20 > > unprofessional, is inefficient and unproductive. > > [MB2] And, as I noted, it is rare for a call centre to route a call=20 > > directly to an agent without a user providing some sort of=20 > input. Even=20 > > companies like American Airlines, even though they have the=20 > info that=20 > > I enter via the IVR, they still ask some basic questions=20 > and there are=20 > > times when they have to reroute me. I don't think we can totally=20 > > automate things. And, again, once the call hits the domain that is=20 > > responsible for that 800 number the entities in that domain have=20 > > control over how they muck with the R-URI, such that they should be=20 > > able to use any IVR info to appropriately direct the call -=20 > it's not=20 > > the number that's meaningful, but how the system gets the=20 > call to the=20 > > right user and the additional information they provide as=20 > the call is=20 > > presented to the agent. I would honestly think that having=20 > something=20 > > other than an 800 number show up on the display would be far more=20 > > useful and in my experience in the systems I developed=20 > we're usually=20 > > talking about CTI interfaces so you have a lot you can do. And,=20 > > actually all of this really doesn't matter in that you MUST=20 > be able to=20 > > handle this situation independent of the privacy since=20 > History-Info is=20 > > optional, you need default behavior assigned. [/MB2] > > > > We have an opportunity to allow presentation of specific identities=20 > > and to solve this particular problem so we should take it. > > [MB2] The most we can do is to document the risks/impacts=20 > of the use=20 > > of the Privacy headers at the R-URI level. There is already general=20 > > text in > > 4244 and 4244bis that the privacy may impact whether the=20 > applications=20 > > get the information. And, as I noted before, most=20 > commercial systems=20 > > are using B2BUAs which will allow you far more control over=20 > the use of=20 > > the Privacy headers in the network. But, again, I don't=20 > think that's=20 > > something that should be address in 4244bis. [/MB2] > > > > I hope that we can get some wider discussion on this issue=20 > so a more=20 > > general consensus can be obtained. > > > > Regards > > > > Ian > > > > > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: 24 June 2009 17:27 > > To: Ian Elz > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > sipcore@ietf.org; Francois Audet > > Subject: RE: 4244bis and privacy > > > > Hi Ian, > > > > Responses inline below [MB]. > > > > Mary.=20 > > > > -----Original Message----- > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > Sent: Wednesday, June 24, 2009 10:37 AM > > To: Barnes, Mary (RICH2:AR00) > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > Subject: RE: 4244bis and privacy > > > > Mary, > > > > I was not proposing that we change the handling of H-I=20 > which is based=20 > > upon local policy. If that causes an issue for a network=20 > operator then=20 > > they can modify their local policy accordingly or arrange with the=20 > > proxy vendor to modify their equipment to be more flexible with=20 > > regards to policy. > > > > Can you clarify for me: > > > > If you have a Privacy header with either "session" or "header" doe=20 > > this impact the H-I entries or will only a value of=20 > "history" impact=20 > > the H-I entries? > > [MB] Yes, both "session" and "header" level privacy,=20 > consistent with=20 > > RFC 3323, mandate that entries be anonymized or dropped, with the=20 > > latter being the recommendation for "session" level=20 > privacy. RFC 4244=20 > > mandated that they be dropped and 4244bis recommends they be=20 > > anonymized. The original intent for the value of "history"=20 > was for the=20 > > tagging of the individual entries, but you end up getting=20 > the header=20 > > level functionality as well. [/MB] > > > > If you have a Privacy header with a value of "none" and a H-I entry=20 > > with Privacy header parameter with value "history" what is=20 > the privacy=20 > > of the individual H-I entry? > > [MB] We did not explicitly address the "none" in RFC 4244, but the=20 > > general statement is the privacy headers at the request=20 > level override=20 > > any at the hi-entry level. [/MB] > > > > From reading RFC4244 a Privacy header with value "history" will=20 > > effectively make all H-I entries private and there is currently no=20 > > option to include a H-I Privacy header parameter with value "none". > > [MB] Correct, per my comment above. [/MB] > > > > H-I at present allows the inclusion of Privacy header parameters to=20 > > explicitly express privacy for an individual H-I entry but a single=20 > > node which includes a header "Privacy: history" makes all=20 > H-I entries=20 > > private even if this is not the requirements for the specific URI. > > [MB] Correct, but the only node that should add the header=20 > is a node=20 > > which is responsible for the domain associated with the=20 > Request URI in=20 > > the incoming request or is authorized to do so. [/MB] > > > > I will admit that having worked in a telephony environment=20 > for a long=20 > > time I am used to having privacy of identities set on a per number=20 > > basis and the relative inflexibility of the IETF Privacy header is=20 > > relatively restrictive as to specifying which identities may be=20 > > presented and which not. > > [MB] Yes, this is an entirely different paradigm. I developed=20 > > telephony s/w for over a decade and this is entirely different - it=20 > > provides a lot more flexibility, which makes things far, far less=20 > > deterministic than what you have in telephony switches where your=20 > > routing and translations are configured for the most part,=20 > with just a=20 > > few capabilities for controlling the privacy and it's a=20 > closed network. > > > > With RFC4244/4244bis, there MUST be a mechanism at the UAS or end=20 > > application that can handle a request that doesn't have the=20 > > appropriate information either because nodes didn't support=20 > > History-Info or some random node in the network applied=20 > privacy (which=20 > > I think is highly > > unlikely) - this is normative per section 5 of RFC 4244. So, the=20 > > worst case scenario I see for this 800 service (which will=20 > get to the=20 > > right UAS but without the exact 800 number that was dialed)=20 > is that it=20 > > goes to a default ACD group/customer service agent, etc. who then=20 > > needs to gather the appropriate information and in my=20 > experience this=20 > > is often an IVR system these days. So, the service is not=20 > broken when=20 > > privacy is applied in an undesireable manner, it's just not=20 > optimal. =20 > > This is something that should be addressed in the target-uri draft=20 > > which has all the details of how specific services use History-Info. > > One other thing to consider is that most networks that are=20 > emulating=20 > > telephony type features use B2BUAs, which follow the=20 > UAS/UAC rules for=20 > > the header rather than the proxy rules, noting that the UAC can set=20 > > the Privacy header to whatever value it sees as appropriate=20 > for the request. > > [/MB] > > > > > > Regards > > > > Ian > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: 24 June 2009 15:48 > > To: Ian Elz > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > sipcore@ietf.org; Francois Audet > > Subject: RE: 4244bis and privacy > > > > Hi Ian, > > > > I do not believe we should do the "override" behavior as I=20 > think that=20 > > violates RFC 3323, as the "history" is really a subset of the cases=20 > > whereby a UAC or proxy would add "session" or "header" to=20 > the request. > > And, the latter two cases have the same (undesireable)=20 > result. I agree > > this impacts your services, but we can't mandate that=20 > proxies provide=20 > > information that might violate their local policies and indeed a=20 > > proxy's local policies can result in the information being=20 > anonymized=20 > > (or removed if they can't anonymize) even in the "none" case. > > > > I do believe it's reasonable that we strongly recommend that the=20 > > request level (versus specific hi-entries) not be used and if it is=20 > > used, the consequence is that some services will not have the=20 > > information they need - this was the gist of my previous=20 > response (to=20 > > which I did not get any additional feedback). Now, we could=20 > add some text that the "none" > > case SHOULD be used (e.g., added by first hop proxy) if it=20 > is desired=20 > > that the information not be subject to privacy=20 > restrictions. I do not=20 > > think it is then particularly useful to add logic around the proxy=20 > > then being able to tag the entries within their domain as=20 > subject to privacy. > > I think that conflicts with the intent of the request level "none". > > However, as I mention above, per the current text, a proxy=20 > can (based=20 > > on local policy) remove entries - so a proxy can capture hi within=20 > > their domain and not forward any of that information to the=20 > next hop=20 > > in another domain - you already have that functionality. =20 > But, I think=20 > > this introduces the general problem that you might be=20 > impacting other=20 > > services further down the line, which I thought was the problem you=20 > > were wanting to solve - not specifically your example=20 > service but, for=20 > > example, in the case that someone is debugging and they want the=20 > > entire history, so depending upon the service, this is also=20 > > undesirable behavior. > > > > > > Regards, > > Mary.=20 > > > > -----Original Message----- > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > Sent: Wednesday, June 24, 2009 2:57 AM > > To: Barnes, Mary (RICH2:AR00) > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > Subject: RE: 4244bis and privacy > > > > > > Mary, > > > > [I have added the list to this thread for wider comment.] > > > > In the previous discussions I commented that in RFC4424=20 > that a Privacy=20 > > header with value "history" effectively makes all H-I=20 > entries private=20 > > with the result that the H-I entries may be removed. > > > > There has now been a comprehensive discussion on indication of the=20 > > initial 'target' to the final recipient for call handling purposes. > > > > The main use case related to a freephone example where the=20 > answering=20 > > location may be a call centre where the original freephone=20 > number may=20 > > be required for correct call handling. > > > > If you now consider the following example (modified from Francois'=20 > > text in the latest draft - excuse any errors that I may=20 > have inserted) > > > > INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx > > Privacy: history > > History-Info: > >=20 > ;index=3D1;rt;aor =20 > (1) > > History-Info: ;index=3D1.1;mp;aor > > (2) > > History-Info: ;index=3D1.1.1;rc > > (3) > > > > In this case due to the Privacy header all of the H-I entries are=20 > > considered private and the +18001234567 will not be=20 > delivered to the=20 > > final destination with the result that call handling may=20 > not be correct. > > The Privacy header may have been inserted by any of the nodes which=20 > > routed the message and inserted a H-I entry. > > > > If however the H-I was allowed to include a header parameter of=20 > > "?Privacy=3Dnone" in the H-I entry and that an explicit H-I entry=20 > > privacy value would be considered to have precedence over a Privacy=20 > > header with a value of "history" then the mapping of the=20 > +18001234567=20 > > could be explicitly specified as not private and may be passed on. > > > > Thus when the mapping from sip:+18001234567@example.com to=20 > > sip:bob@biloxi.example.com when H-I entry (2) above is=20 > included could=20 > > also insert the Privacy header parameter in H-I entry (1). > > > > Thus the message would appear as follows: > > > > INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx > > Privacy: history > > History-Info: > >=20 > = ;index=3D= 1;rt; > > ao > > r > > History-Info: ;index=3D1.1;mp;aor > > History-Info: ;index=3D1.1.1;rc > > > > This would result in all the H-I entries except (1) being=20 > considered=20 > > private with the result that the =3D1800... Number is passed for = call=20 > > handling purposes. > > > > This change is backward compatible with the existing=20 > implementation as=20 > > any node using the existing functionality as defined in=20 > RFC4244 will=20 > > continue to be supported. > > > > The alternative is to remove the ability to include the=20 > value "history" > > in the Privacy header and only allow this value in the=20 > Privacy header=20 > > parameter. This alternative is not backward compatible. > > > > Without this change a single node in the message path which=20 > includes a=20 > > header "Privacy: history" will prevent delivery of the aor and thus=20 > > prevent proper call handling. > > > > Ian Elz > > > > > > > > -----Original Message----- > > From: Christer Holmberg > > Sent: 23 June 2009 19:40 > > To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida=20 > > Schubert > > Cc: Ian Elz > > Subject: RE: 4244bis and privacy > > > > =20 > > Hi, > > > > I include Ian, so he can comment to your resposne himself. > > > > Regards, > > > > Christer > > > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: Tuesday, June 23, 2009 9:40 PM > > To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida=20 > > Schubert > > Subject: RE: 4244bis and privacy > > > > Here was the thread of response and the last comment was=20 > from Ian that=20 > > he would consider the response: > > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html > > > > And, there was not agreement on the "none" but rather to=20 > qualify the=20 > > SHOULD NOT forward. However, in the sipcore-4244bis-00,=20 > rather than=20 > > changing the text such that the headers SHOULD be removed, we=20 > > recommend that they be anonymized (in section 4.3.3.3.1). That is=20 > > entirely consistent with RFC 3324 and thus we have removed the=20 > > recommendations to remove the headers entirely. However,=20 > that changed=20 > > never got done in section 3.2, so we would need to change this: > > "Thus, the History- Info header > > SHOULD NOT be included in Requests where the requestor=20 > has indicated > > a priv-value of Session- or Header-level privacy." > > > > But, I'm really beginning to be of the mindset that we should just=20 > > remove all the subsections of section 3 (i.e., leave the=20 > text in the=20 > > upper level section), so we don't have to keep worrying about=20 > > consistency. > > > > So, lets either fixt the text in 3.2 or remove altogether=20 > and then I=20 > > think we are really at the point of needing to submit this=20 > version so=20 > > folks that actually have an interest in it can review the updated=20 > > document. > > > > Mary.=20 > > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, June 23, 2009 1:10 PM > > To: Barnes, Mary (RICH2:AR00); Audet, Francois=20 > (SC100:3055); Hans Erik=20 > > van Elburg; Shida Schubert > > Subject: 4244bis and privacy > > > > > > Hi, > > > > Below is a comment/proposal which one of my collegues (Ian=20 > Elz) gave=20 > > on the list a while ago, when the first version of 4244bis was=20 > > submitted, but was not incorporated. Do you think it would=20 > be useful? > > > > ------- > > > > While the HI approach to target may solve the problem of=20 > being able to=20 > > deliver the target URI to the final destination there is no=20 > guarantee=20 > > that it will actually be delivered. > > > > The problem arises with how Privacy is defined for HI. > > > > 4424 defines a new Privacy value "history" which may be placed in=20 > > either the Privacy header or as a header parameter to the HI entry. > > > > If one node uses the former option "Privacy: history" then=20 > this will=20 > > make all headers private and will result in all HI entries being=20 > > removed or made anonymous when the message containing the HI is=20 > > delivered to the user. > > > > There is a simple solution to this and that is to also=20 > allow the use=20 > > of the "none" Privacy value as a header parameter in the HI entry.=20 > > This would explicitly state that no privacy is required to the HI=20 > > entry and this would override a "history" value in the=20 > Privacy header. > > > > I pointed this out to Mary when the 4424bis draft was first=20 > published=20 > > but the change has not been made in the latest draft. > > > > The change is backward compatible and would not cause an issue with=20 > > any existing implementations. > > > > ------ > > > > Regards, > > > > Christer > > > > > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From ian.elz@ericsson.com Fri Jun 26 01:23:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D81E3A68EE for ; Fri, 26 Jun 2009 01:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6voHxHWpzMbJ for ; Fri, 26 Jun 2009 01:23:08 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4A82C3A687F for ; Fri, 26 Jun 2009 01:23:06 -0700 (PDT) X-AuditID: c1b4fb3c-b7bdcae0000052f9-0e-4a4481a25be5 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id F4.67.21241.2A1844A4; Fri, 26 Jun 2009 10:06:58 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 Jun 2009 10:06:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Jun 2009 10:07:30 +0200 Message-ID: In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00213AA4C@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] 4244bis and privacy Thread-Index: Acn11AWR+Z7be2FAQvKtnWIFO4vfcAAB1KHQAABgLvAAFKai8AAAYdKw References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4048F809B@S4DE8PSAAQB.mitte.t-com.de> <4A43DEC9.1020802@gmail.com> <9886E5FCA6D76549A3011068483A4BD4048F80AC@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1EB26AB5@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D00213AA4C@GBNTHT12009MSX.gb002.siemens.net> From: "Ian Elz" To: "Elwell, John" , "Mary Barnes" , , X-OriginalArrivalTime: 26 Jun 2009 08:06:57.0996 (UTC) FILETIME=[13A3A0C0:01C9F635] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 08:23:11 -0000 John, Your statement " not anonymise or remove any information that the UAC = has already placed in the request " is the key here. The UAC has not included the H-I entry, particularly the one containing = the identity of the diverting party. This was not considered in RFC3323 and we have an issue where we cannot = determine which entity included which information. This creates a = problem where a restriction by the originating party will prevent a = downstream identity from permitting presentation of their identity. I agree with Mary that this probably requires an update to RFC3323 so we = should start by updating RFC3323 and then move on to the other impacted = RFCs. The issue that this will raise for H-I is that there will be = another change required after the Privacy RFC has been agreed. This is far from ideal but the 4424bis draft contains a lot more than = just this issue. Ian -----Original Message----- From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 Sent: 26 June 2009 08:30 To: Mary Barnes; R.Jesske@telekom.de; ietf.hanserik@gmail.com Cc: Ian Elz; sipcore@ietf.org; shida@agnada.com Subject: RE: [sipcore] 4244bis and privacy =20 > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: 25 June 2009 22:45 > To: R.Jesske@telekom.de; ietf.hanserik@gmail.com > Cc: ian.elz@ericsson.com; sipcore@ietf.org; shida@agnada.com > Subject: Re: [sipcore] 4244bis and privacy >=20 > Roland, >=20 > The reason you can't have "none" at the request level and "history" at = > the entry level is because RFC 3323 states that you MUST NOT apply=20 > privacy to the message. Even if you put "history" in the entries, the=20 > privacy service would just ignore that - per RFC 3323. So, if you=20 > want to change that behavior, then RFC 3323 should be changed - i.e.,=20 > the MUST NOT for the "none" could be changed to a SHOULD NOT and then=20 > a general statement about possible exceptions. Then, we could add=20 > something to RFC 4244 for this case. But, changing RFC > 3323 is totally out of scope for what we are currently working on. =20 [JRE] I would interpret privacy 'none' in RFC 3323 as meaning that a = downstream entity must not anonymise or remove any information that the = UAC has already placed in the request. If a downstream entity chooses: - not to add H-I, - to add anonymised H-I, or - to anonymise an H-I entry that some intermediate entity has added, I = don't see that as being in violation of what the UAC has requested. John >=20 > That all said, I would sure think that if you are leaving a "trusted=20 > network" that you have a B2BUA in there, as I've said in other=20 > threads. Thus, the B2BUA builds a new request and certainly can add a=20 > privacy header that it believes is appropriate since the outgoing=20 > request is done by the UAC function of a B2BUA. >=20 > Mary.=20 >=20 >=20 > -----Original Message----- > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > Sent: Thursday, June 25, 2009 4:32 PM > To: ietf.hanserik@gmail.com > Cc: Barnes, Mary (RICH2:AR00); ian.elz@ericsson.com; sipcore@ietf.org; = > shida@agnada.com > Subject: AW: [sipcore] 4244bis and privacy >=20 > Hi Hans Erik, > We have also to take regulatory into consideration. In Germany the=20 > last trusted network is responsible for anonymising information. >=20 > But nevertheless if Network provider A wants to have History=20 > completely private this operator will set privacy history for the=20 > header. > If the succeeding Operator want to present elements the AS which adds=20 > a entry has then to re label all entries from the preceding network=20 > and the entries from it's own network will be unmarked within the=20 > Header. >=20 > But never the less I fully agree to your last sentence. >=20 > The real Question is if this should really be allowed that a entry=20 > marked with "none" overrules the privacy statement "history" for the=20 > complete header. >=20 > I'm against this behaviour.=20 >=20 > Best Regards >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Gesendet: Donnerstag, 25. Juni 2009 22:32 > An: Jesske, Roland > Cc: mary.barnes@nortel.com; ian.elz@ericsson.com; sipcore@ietf.org;=20 > shida@agnada.com > Betreff: Re: [sipcore] 4244bis and privacy >=20 > Hi Roland, >=20 > I don't understand the argument, by the time that the History-Info=20 > leaves operator A that wishes complete privacy, all the History-Info=20 > headers should be anonymised according to 4244 and 4244bis. >=20 > What is the point in mandating that operator A to force operator B to=20 > also anonymise the entries "owned" by operator B. >=20 > It is of course without question that each operator has full privacy=20 > control over its own added entries. And each operator can based on=20 > local policy decide to remove the entire history if it things that is=20 > wise to do. >=20 > /Hans Erik >=20 >=20 > R.Jesske@telekom.de wrote: > > Hi Marry and Ian, > > The whole discussion puzzle me. We have specified CDIV > within TISPAN and 3GPP.=20 > > There is described that privacy "none" can be used for > entries. BUT assuming that each entry has its own privacy statement if = > needed. > > I fully agree on Mary's comment that a privacy "history"=20 > cannot overruled by a privacy value "none" within a entry.=20 > > There may be operators that would like to keep the whole > History Info private even if entries has other statements, so the=20 > entity could add privacy history to the whole header. > Nothing more. > > > > On the other side a Application Server including a entry > should have the possibility to rewrite the entries so that instead of=20 > "history" for the whole header the all received entries within the=20 > History-Info header will be marked with "history" and the added header = > (which shall be presented to the terminating user) will either be=20 > marked with "none" or will not be marked. > > > > Perhaps a hint could be given, but I do not insist on it. > > > > Best Regards, > > > > Roland > > > > > > > > -----Urspr=FCngliche Nachricht----- > > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im=20 > > Auftrag von Mary Barnes > > Gesendet: Donnerstag, 25. Juni 2009 18:29 > > An: Ian Elz > > Cc: sipcore@ietf.org; Shida Schubert > > Betreff: Re: [sipcore] 4244bis and privacy > > > > Hi Ian, > > > > Responses inline below [MB2]. > > > > Mary. > > > > -----Original Message----- > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > Sent: Thursday, June 25, 2009 10:13 AM > > To: Barnes, Mary (RICH2:AR00) > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > Subject: RE: 4244bis and privacy > > > > Mary, > > > > I am a little concerned about one answer that you gave: > > > > > > If you have a Privacy header with a value of "none" and a H-I entry=20 > > with Privacy header parameter with value "history" what is > the privacy > > of the individual H-I entry? > > [MB] We did not explicitly address the "none" in RFC 4244, but the=20 > > general statement is the privacy headers at the request > level override > > any at the hi-entry level. [/MB] > > =20 > > This means that if privacy is required for an individual > H-I entry but > > the originating user included "Privacy:none" in the request > then there > > is no option to include the real URI in the H-I entry. > > [MB2] I'm confused here - the "none" definition is as you > note below, > > thus "none" prohibits the removal or anonymization of the entries,=20 > > thus I would think you would fine this functionality desireable. > > However, this does not prohibit an entity based on policy > to anonymize > > (or remove entries if privacy is required for that domain if the=20 > > entity does not have access to a privacy service). [/MB2] > > > > This occurs as RFC3323 states in section 4.3: "However, if > the Privacy > > header value of 'none' is specified in a message, privacy services=20 > > MUST NOT perform any privacy function and MUST NOT remove or modify=20 > > the Privacy header." > > > > The only option for an intermediate node including a H-I > entry where > > "Privacy:none" is specified and privacy for the H-I URI is > required is > > to include an anonymous entry or not include the H-I entry. > > [MB2] If privacy is required then yes, you include > anonymous entries > > or don't include. That's the basic privacy mechanism for privacy=20 > > levels of "session" "header" and "history" in the R-URI or > "history"=20 > > in the specific entries, as well as when there is a policy > for privacy > > for the entries added by a specific domain. The "none"=20 > really has no > > influence on the later case per se. [/MB2] > > > > In your previous response you stated that we would violate > RFC3323 if > > we specified additional behaviour for privacy explicitly > stated with a > > URI -n the H-I entry. I don't believe that this is the case > as RFC3323 > > only considered privacy in a two party scenario and did not > consider > > third party identities being included in a message between two=20 > > parties. H-I is not the only case where this occurs as the > Referred-By > > header when included in the INVITE (or other request) which results=20 > > from the REFER has the same issue. > > [MB2] I can't necessarily disagree on this one (we can debate it=20 > > either way). But to fix it requires an update to RFC 3323 and=20 > > shouldn't be something that we want to fix in 4244bis. [/MB2] > > > > RFC4244 was the first time that there was a recognition > that privacy > > for these individual third party identities may be > required. To allow > > this explicit statement of privacy to be overridden by a generic=20 > > statement which is applicable to a different user is > counterintuitive. > > [MB2] See my comment above. But, as I have consistently > said, the idea > > that an entity might want to override the "none" is > entirely based on > > policy and 4244 and 4244bis allow privacy to be applied to > the entries > > that are added by that entity if the policy dictates so (and we=20 > > already say that). [/MB2] > > > > The original Privacy header is usually included by or on > behalf of the > > originating user and should not be allowed to specify the > privacy of > > the original called user, e.g. the 800 number, and prevent this=20 > > identity being presented if this user does not have the > same level of privacy. > > [MB2] As I tried to say in a previous response, a random > entity (i.e., > > one for whom the R-URI is not in a domain under its control) cannot=20 > > add a privacy header to the Request. Per RFC 3323 an entity may add=20 > > the header to a request only if it has the appropriate=20 > > relationship/authorization with the original called user > who intiated > > the request. And, I would find it very surprising if an entity that=20 > > did have responsibility would apply privacy since that would be=20 > > counter intuitive and I would hope that SPs would be judicious in=20 > > specifying the appropriate and inappropriate manner in which the=20 > > proxies they deploy and interface with privatize the messages. The=20 > > protocol CANNOT control this behavior and that's why there is the=20 > > policy clause in 4244 and 4244bis. [/MB2] > > > > The real issue with the 800 scenario is as you have stated > is that the > > answerer will not know the original called identity and will not be=20 > > able to correctly handle the call. As more generic call centres are=20 > > used which will answer calls on behalf of many different > organizations > > using CTI and the original called identity to have to implement a=20 > > generic system asking the caller who he originally called appear=20 > > unprofessional, is inefficient and unproductive. > > [MB2] And, as I noted, it is rare for a call centre to route a call=20 > > directly to an agent without a user providing some sort of > input. Even > > companies like American Airlines, even though they have the > info that > > I enter via the IVR, they still ask some basic questions > and there are > > times when they have to reroute me. I don't think we can totally=20 > > automate things. And, again, once the call hits the domain that is=20 > > responsible for that 800 number the entities in that domain have=20 > > control over how they muck with the R-URI, such that they should be=20 > > able to use any IVR info to appropriately direct the call - > it's not > > the number that's meaningful, but how the system gets the > call to the > > right user and the additional information they provide as > the call is > > presented to the agent. I would honestly think that having > something > > other than an 800 number show up on the display would be far more=20 > > useful and in my experience in the systems I developed > we're usually > > talking about CTI interfaces so you have a lot you can do. And,=20 > > actually all of this really doesn't matter in that you MUST > be able to > > handle this situation independent of the privacy since > History-Info is > > optional, you need default behavior assigned. [/MB2] > > > > We have an opportunity to allow presentation of specific identities=20 > > and to solve this particular problem so we should take it. > > [MB2] The most we can do is to document the risks/impacts > of the use > > of the Privacy headers at the R-URI level. There is already general=20 > > text in > > 4244 and 4244bis that the privacy may impact whether the > applications > > get the information. And, as I noted before, most > commercial systems > > are using B2BUAs which will allow you far more control over > the use of > > the Privacy headers in the network. But, again, I don't > think that's > > something that should be address in 4244bis. [/MB2] > > > > I hope that we can get some wider discussion on this issue > so a more > > general consensus can be obtained. > > > > Regards > > > > Ian > > > > > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: 24 June 2009 17:27 > > To: Ian Elz > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > sipcore@ietf.org; Francois Audet > > Subject: RE: 4244bis and privacy > > > > Hi Ian, > > > > Responses inline below [MB]. > > > > Mary.=20 > > > > -----Original Message----- > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > Sent: Wednesday, June 24, 2009 10:37 AM > > To: Barnes, Mary (RICH2:AR00) > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > Subject: RE: 4244bis and privacy > > > > Mary, > > > > I was not proposing that we change the handling of H-I > which is based > > upon local policy. If that causes an issue for a network > operator then > > they can modify their local policy accordingly or arrange with the=20 > > proxy vendor to modify their equipment to be more flexible with=20 > > regards to policy. > > > > Can you clarify for me: > > > > If you have a Privacy header with either "session" or "header" doe=20 > > this impact the H-I entries or will only a value of > "history" impact > > the H-I entries? > > [MB] Yes, both "session" and "header" level privacy, > consistent with > > RFC 3323, mandate that entries be anonymized or dropped, with the=20 > > latter being the recommendation for "session" level > privacy. RFC 4244 > > mandated that they be dropped and 4244bis recommends they be=20 > > anonymized. The original intent for the value of "history" > was for the > > tagging of the individual entries, but you end up getting > the header > > level functionality as well. [/MB] > > > > If you have a Privacy header with a value of "none" and a H-I entry=20 > > with Privacy header parameter with value "history" what is > the privacy > > of the individual H-I entry? > > [MB] We did not explicitly address the "none" in RFC 4244, but the=20 > > general statement is the privacy headers at the request > level override > > any at the hi-entry level. [/MB] > > > > From reading RFC4244 a Privacy header with value "history" will=20 > > effectively make all H-I entries private and there is currently no=20 > > option to include a H-I Privacy header parameter with value "none". > > [MB] Correct, per my comment above. [/MB] > > > > H-I at present allows the inclusion of Privacy header parameters to=20 > > explicitly express privacy for an individual H-I entry but a single=20 > > node which includes a header "Privacy: history" makes all > H-I entries > > private even if this is not the requirements for the specific URI. > > [MB] Correct, but the only node that should add the header > is a node > > which is responsible for the domain associated with the > Request URI in > > the incoming request or is authorized to do so. [/MB] > > > > I will admit that having worked in a telephony environment > for a long > > time I am used to having privacy of identities set on a per number=20 > > basis and the relative inflexibility of the IETF Privacy header is=20 > > relatively restrictive as to specifying which identities may be=20 > > presented and which not. > > [MB] Yes, this is an entirely different paradigm. I developed=20 > > telephony s/w for over a decade and this is entirely different - it=20 > > provides a lot more flexibility, which makes things far, far less=20 > > deterministic than what you have in telephony switches where your=20 > > routing and translations are configured for the most part, > with just a > > few capabilities for controlling the privacy and it's a > closed network. > > > > With RFC4244/4244bis, there MUST be a mechanism at the UAS or end=20 > > application that can handle a request that doesn't have the=20 > > appropriate information either because nodes didn't support=20 > > History-Info or some random node in the network applied > privacy (which > > I think is highly > > unlikely) - this is normative per section 5 of RFC 4244. So, the=20 > > worst case scenario I see for this 800 service (which will > get to the > > right UAS but without the exact 800 number that was dialed) > is that it > > goes to a default ACD group/customer service agent, etc. who then=20 > > needs to gather the appropriate information and in my > experience this > > is often an IVR system these days. So, the service is not > broken when > > privacy is applied in an undesireable manner, it's just not > optimal. =20 > > This is something that should be addressed in the target-uri draft=20 > > which has all the details of how specific services use History-Info. > > One other thing to consider is that most networks that are > emulating > > telephony type features use B2BUAs, which follow the > UAS/UAC rules for > > the header rather than the proxy rules, noting that the UAC can set=20 > > the Privacy header to whatever value it sees as appropriate > for the request. > > [/MB] > > > > > > Regards > > > > Ian > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: 24 June 2009 15:48 > > To: Ian Elz > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > sipcore@ietf.org; Francois Audet > > Subject: RE: 4244bis and privacy > > > > Hi Ian, > > > > I do not believe we should do the "override" behavior as I > think that > > violates RFC 3323, as the "history" is really a subset of the cases=20 > > whereby a UAC or proxy would add "session" or "header" to > the request. > > And, the latter two cases have the same (undesireable) > result. I agree > > this impacts your services, but we can't mandate that > proxies provide > > information that might violate their local policies and indeed a=20 > > proxy's local policies can result in the information being > anonymized > > (or removed if they can't anonymize) even in the "none" case. > > > > I do believe it's reasonable that we strongly recommend that the=20 > > request level (versus specific hi-entries) not be used and if it is=20 > > used, the consequence is that some services will not have the=20 > > information they need - this was the gist of my previous > response (to > > which I did not get any additional feedback). Now, we could > add some text that the "none" > > case SHOULD be used (e.g., added by first hop proxy) if it > is desired > > that the information not be subject to privacy > restrictions. I do not > > think it is then particularly useful to add logic around the proxy=20 > > then being able to tag the entries within their domain as > subject to privacy. > > I think that conflicts with the intent of the request level "none". > > However, as I mention above, per the current text, a proxy > can (based > > on local policy) remove entries - so a proxy can capture hi within=20 > > their domain and not forward any of that information to the > next hop > > in another domain - you already have that functionality. =20 > But, I think > > this introduces the general problem that you might be > impacting other > > services further down the line, which I thought was the problem you=20 > > were wanting to solve - not specifically your example > service but, for > > example, in the case that someone is debugging and they want the=20 > > entire history, so depending upon the service, this is also=20 > > undesirable behavior. > > > > > > Regards, > > Mary.=20 > > > > -----Original Message----- > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > Sent: Wednesday, June 24, 2009 2:57 AM > > To: Barnes, Mary (RICH2:AR00) > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > Subject: RE: 4244bis and privacy > > > > > > Mary, > > > > [I have added the list to this thread for wider comment.] > > > > In the previous discussions I commented that in RFC4424 > that a Privacy > > header with value "history" effectively makes all H-I > entries private > > with the result that the H-I entries may be removed. > > > > There has now been a comprehensive discussion on indication of the=20 > > initial 'target' to the final recipient for call handling purposes. > > > > The main use case related to a freephone example where the > answering > > location may be a call centre where the original freephone > number may > > be required for correct call handling. > > > > If you now consider the following example (modified from Francois'=20 > > text in the latest draft - excuse any errors that I may > have inserted) > > > > INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx > > Privacy: history > > History-Info: > >=20 > ;index=3D1;rt;aor =20 > (1) > > History-Info: ;index=3D1.1;mp;aor > > (2) > > History-Info: ;index=3D1.1.1;rc > > (3) > > > > In this case due to the Privacy header all of the H-I entries are=20 > > considered private and the +18001234567 will not be > delivered to the > > final destination with the result that call handling may > not be correct. > > The Privacy header may have been inserted by any of the nodes which=20 > > routed the message and inserted a H-I entry. > > > > If however the H-I was allowed to include a header parameter of=20 > > "?Privacy=3Dnone" in the H-I entry and that an explicit H-I entry=20 > > privacy value would be considered to have precedence over a Privacy=20 > > header with a value of "history" then the mapping of the > +18001234567 > > could be explicitly specified as not private and may be passed on. > > > > Thus when the mapping from sip:+18001234567@example.com to=20 > > sip:bob@biloxi.example.com when H-I entry (2) above is > included could > > also insert the Privacy header parameter in H-I entry (1). > > > > Thus the message would appear as follows: > > > > INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx > > Privacy: history > > History-Info: > >=20 > = ;index=3D= 1;rt; > > ao > > r > > History-Info: ;index=3D1.1;mp;aor > > History-Info: ;index=3D1.1.1;rc > > > > This would result in all the H-I entries except (1) being > considered > > private with the result that the =3D1800... Number is passed for = call=20 > > handling purposes. > > > > This change is backward compatible with the existing > implementation as > > any node using the existing functionality as defined in > RFC4244 will > > continue to be supported. > > > > The alternative is to remove the ability to include the > value "history" > > in the Privacy header and only allow this value in the > Privacy header > > parameter. This alternative is not backward compatible. > > > > Without this change a single node in the message path which > includes a > > header "Privacy: history" will prevent delivery of the aor and thus=20 > > prevent proper call handling. > > > > Ian Elz > > > > > > > > -----Original Message----- > > From: Christer Holmberg > > Sent: 23 June 2009 19:40 > > To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida=20 > > Schubert > > Cc: Ian Elz > > Subject: RE: 4244bis and privacy > > > > =20 > > Hi, > > > > I include Ian, so he can comment to your resposne himself. > > > > Regards, > > > > Christer > > > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: Tuesday, June 23, 2009 9:40 PM > > To: Christer Holmberg; Francois Audet; Hans Erik van Elburg; Shida=20 > > Schubert > > Subject: RE: 4244bis and privacy > > > > Here was the thread of response and the last comment was > from Ian that > > he would consider the response: > > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html > > > > And, there was not agreement on the "none" but rather to > qualify the > > SHOULD NOT forward. However, in the sipcore-4244bis-00, > rather than > > changing the text such that the headers SHOULD be removed, we=20 > > recommend that they be anonymized (in section 4.3.3.3.1). That is=20 > > entirely consistent with RFC 3324 and thus we have removed the=20 > > recommendations to remove the headers entirely. However, > that changed > > never got done in section 3.2, so we would need to change this: > > "Thus, the History- Info header > > SHOULD NOT be included in Requests where the requestor > has indicated > > a priv-value of Session- or Header-level privacy." > > > > But, I'm really beginning to be of the mindset that we should just=20 > > remove all the subsections of section 3 (i.e., leave the > text in the > > upper level section), so we don't have to keep worrying about=20 > > consistency. > > > > So, lets either fixt the text in 3.2 or remove altogether > and then I > > think we are really at the point of needing to submit this > version so > > folks that actually have an interest in it can review the updated=20 > > document. > > > > Mary.=20 > > > > -----Original Message----- > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > Sent: Tuesday, June 23, 2009 1:10 PM > > To: Barnes, Mary (RICH2:AR00); Audet, Francois > (SC100:3055); Hans Erik > > van Elburg; Shida Schubert > > Subject: 4244bis and privacy > > > > > > Hi, > > > > Below is a comment/proposal which one of my collegues (Ian > Elz) gave > > on the list a while ago, when the first version of 4244bis was=20 > > submitted, but was not incorporated. Do you think it would > be useful? > > > > ------- > > > > While the HI approach to target may solve the problem of > being able to > > deliver the target URI to the final destination there is no > guarantee > > that it will actually be delivered. > > > > The problem arises with how Privacy is defined for HI. > > > > 4424 defines a new Privacy value "history" which may be placed in=20 > > either the Privacy header or as a header parameter to the HI entry. > > > > If one node uses the former option "Privacy: history" then > this will > > make all headers private and will result in all HI entries being=20 > > removed or made anonymous when the message containing the HI is=20 > > delivered to the user. > > > > There is a simple solution to this and that is to also > allow the use > > of the "none" Privacy value as a header parameter in the HI entry.=20 > > This would explicitly state that no privacy is required to the HI=20 > > entry and this would override a "history" value in the > Privacy header. > > > > I pointed this out to Mary when the 4424bis draft was first > published > > but the change has not been made in the latest draft. > > > > The change is backward compatible and would not cause an issue with=20 > > any existing implementations. > > > > ------ > > > > Regards, > > > > Christer > > > > > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From AUDET@nortel.com Fri Jun 26 08:55:36 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CAA33A6922 for ; Fri, 26 Jun 2009 08:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.364 X-Spam-Level: X-Spam-Status: No, score=-6.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLUhZwIgD9mu for ; Fri, 26 Jun 2009 08:55:33 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 6E5213A6882 for ; Fri, 26 Jun 2009 08:55:33 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5QFsBU15215; Fri, 26 Jun 2009 15:54:12 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Jun 2009 10:54:56 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EB6BD69@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] 4244bis and privacy thread-index: Acn11AWR+Z7be2FAQvKtnWIFO4vfcAAB1KHQAABgLvAAFKai8AAAYdKwABEiZHA= References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com><9886E5FCA6D76549A3011068483A4BD4048F809B@S4DE8PSAAQB.mitte.t-com.de><4A43DEC9.1020802@gmail.com><9886E5FCA6D76549A3011068483A4BD4048F80AC@S4DE8PSAAQB.mitte.t-com.de><1ECE0EB50388174790F9694F77522CCF1EB26AB5@zrc2hxm0.corp.nortel.com><0D5F89FAC29E2C41B98A6A762007F5D00213AA4C@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Ian Elz" , "Elwell, John" , "Mary Barnes" , , Cc: sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 15:55:36 -0000 I do see things that we should fix right-away in History-Info, regarding = privacy. I also think that History-Info shouldn't "overstrech" and get too deep into the nitty gritty of privacy. What should be in HI is high level = guidance. In section 3.1, for example, it says that Privacy header will determine = if a History-Info *header field* can be included by an intermediary. This = does not make any sense. What it should say is that the Privacy header will determine if=20 a history-info *entry* can be added for the UA inserting the Privacy = header. So, in my opinion, we can go ahead and fix that right now. I don't think we need to get into super low-level procedural=20 descriptions of the type "proxy MUST this and that if Privacy =3D=3D this and that". I believe privacy matters are policy-level decisions that service providers and enteprises will have, and they are not going=20 to be implemented by simplistic procedural rules from an RFC. Comments? =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Ian Elz > Sent: Friday, June 26, 2009 01:08 > To: Elwell, John; Barnes, Mary (RICH2:AR00);=20 > R.Jesske@telekom.de; ietf.hanserik@gmail.com > Cc: sipcore@ietf.org; shida@agnada.com > Subject: Re: [sipcore] 4244bis and privacy >=20 > John, >=20 > Your statement " not anonymise or remove any information that=20 > the UAC has already placed in the request " is the key here. >=20 > The UAC has not included the H-I entry, particularly the one=20 > containing the identity of the diverting party. >=20 > This was not considered in RFC3323 and we have an issue where=20 > we cannot determine which entity included which information.=20 > This creates a problem where a restriction by the originating=20 > party will prevent a downstream identity from permitting=20 > presentation of their identity. >=20 > I agree with Mary that this probably requires an update to=20 > RFC3323 so we should start by updating RFC3323 and then move=20 > on to the other impacted RFCs. The issue that this will raise=20 > for H-I is that there will be another change required after=20 > the Privacy RFC has been agreed. >=20 > This is far from ideal but the 4424bis draft contains a lot=20 > more than just this issue. >=20 > Ian >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: 26 June 2009 08:30 > To: Mary Barnes; R.Jesske@telekom.de; ietf.hanserik@gmail.com > Cc: Ian Elz; sipcore@ietf.org; shida@agnada.com > Subject: RE: [sipcore] 4244bis and privacy >=20 > =20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > > Sent: 25 June 2009 22:45 > > To: R.Jesske@telekom.de; ietf.hanserik@gmail.com > > Cc: ian.elz@ericsson.com; sipcore@ietf.org; shida@agnada.com > > Subject: Re: [sipcore] 4244bis and privacy > >=20 > > Roland, > >=20 > > The reason you can't have "none" at the request level and=20 > "history" at=20 > > the entry level is because RFC 3323 states that you MUST NOT apply=20 > > privacy to the message. Even if you put "history" in the=20 > entries, the=20 > > privacy service would just ignore that - per RFC 3323. So, if you=20 > > want to change that behavior, then RFC 3323 should be=20 > changed - i.e.,=20 > > the MUST NOT for the "none" could be changed to a SHOULD=20 > NOT and then=20 > > a general statement about possible exceptions. Then, we could add=20 > > something to RFC 4244 for this case. But, changing RFC > > 3323 is totally out of scope for what we are currently working on. =20 > [JRE] I would interpret privacy 'none' in RFC 3323 as meaning=20 > that a downstream entity must not anonymise or remove any=20 > information that the UAC has already placed in the request.=20 > If a downstream entity chooses: > - not to add H-I, > - to add anonymised H-I, or > - to anonymise an H-I entry that some intermediate entity has=20 > added, I don't see that as being in violation of what the UAC=20 > has requested. >=20 > John >=20 >=20 > >=20 > > That all said, I would sure think that if you are leaving a=20 > "trusted=20 > > network" that you have a B2BUA in there, as I've said in other=20 > > threads. Thus, the B2BUA builds a new request and certainly=20 > can add a=20 > > privacy header that it believes is appropriate since the outgoing=20 > > request is done by the UAC function of a B2BUA. > >=20 > > Mary.=20 > >=20 > >=20 > > -----Original Message----- > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > > Sent: Thursday, June 25, 2009 4:32 PM > > To: ietf.hanserik@gmail.com > > Cc: Barnes, Mary (RICH2:AR00); ian.elz@ericsson.com;=20 > sipcore@ietf.org;=20 > > shida@agnada.com > > Subject: AW: [sipcore] 4244bis and privacy > >=20 > > Hi Hans Erik, > > We have also to take regulatory into consideration. In Germany the=20 > > last trusted network is responsible for anonymising information. > >=20 > > But nevertheless if Network provider A wants to have History=20 > > completely private this operator will set privacy history for the=20 > > header. > > If the succeeding Operator want to present elements the AS=20 > which adds=20 > > a entry has then to re label all entries from the preceding network=20 > > and the entries from it's own network will be unmarked within the=20 > > Header. > >=20 > > But never the less I fully agree to your last sentence. > >=20 > > The real Question is if this should really be allowed that a entry=20 > > marked with "none" overrules the privacy statement=20 > "history" for the=20 > > complete header. > >=20 > > I'm against this behaviour.=20 > >=20 > > Best Regards > >=20 > > Roland > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > Gesendet: Donnerstag, 25. Juni 2009 22:32 > > An: Jesske, Roland > > Cc: mary.barnes@nortel.com; ian.elz@ericsson.com; sipcore@ietf.org;=20 > > shida@agnada.com > > Betreff: Re: [sipcore] 4244bis and privacy > >=20 > > Hi Roland, > >=20 > > I don't understand the argument, by the time that the History-Info=20 > > leaves operator A that wishes complete privacy, all the=20 > History-Info=20 > > headers should be anonymised according to 4244 and 4244bis. > >=20 > > What is the point in mandating that operator A to force=20 > operator B to=20 > > also anonymise the entries "owned" by operator B. > >=20 > > It is of course without question that each operator has=20 > full privacy=20 > > control over its own added entries. And each operator can based on=20 > > local policy decide to remove the entire history if it=20 > things that is=20 > > wise to do. > >=20 > > /Hans Erik > >=20 > >=20 > > R.Jesske@telekom.de wrote: > > > Hi Marry and Ian, > > > The whole discussion puzzle me. We have specified CDIV > > within TISPAN and 3GPP.=20 > > > There is described that privacy "none" can be used for > > entries. BUT assuming that each entry has its own privacy=20 > statement if=20 > > needed. > > > I fully agree on Mary's comment that a privacy "history"=20 > > cannot overruled by a privacy value "none" within a entry.=20 > > > There may be operators that would like to keep the whole > > History Info private even if entries has other statements, so the=20 > > entity could add privacy history to the whole header. > > Nothing more. > > > > > > On the other side a Application Server including a entry > > should have the possibility to rewrite the entries so that=20 > instead of=20 > > "history" for the whole header the all received entries within the=20 > > History-Info header will be marked with "history" and the=20 > added header=20 > > (which shall be presented to the terminating user) will either be=20 > > marked with "none" or will not be marked. > > > > > > Perhaps a hint could be given, but I do not insist on it. > > > > > > Best Regards, > > > > > > Roland > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] Im=20 > > > Auftrag von Mary Barnes > > > Gesendet: Donnerstag, 25. Juni 2009 18:29 > > > An: Ian Elz > > > Cc: sipcore@ietf.org; Shida Schubert > > > Betreff: Re: [sipcore] 4244bis and privacy > > > > > > Hi Ian, > > > > > > Responses inline below [MB2]. > > > > > > Mary. > > > > > > -----Original Message----- > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > Sent: Thursday, June 25, 2009 10:13 AM > > > To: Barnes, Mary (RICH2:AR00) > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > Subject: RE: 4244bis and privacy > > > > > > Mary, > > > > > > I am a little concerned about one answer that you gave: > > > > > > > > > If you have a Privacy header with a value of "none" and a=20 > H-I entry=20 > > > with Privacy header parameter with value "history" what is > > the privacy > > > of the individual H-I entry? > > > [MB] We did not explicitly address the "none" in RFC=20 > 4244, but the=20 > > > general statement is the privacy headers at the request > > level override > > > any at the hi-entry level. [/MB] > > > =20 > > > This means that if privacy is required for an individual > > H-I entry but > > > the originating user included "Privacy:none" in the request > > then there > > > is no option to include the real URI in the H-I entry. > > > [MB2] I'm confused here - the "none" definition is as you > > note below, > > > thus "none" prohibits the removal or anonymization of the=20 > entries,=20 > > > thus I would think you would fine this functionality desireable. > > > However, this does not prohibit an entity based on policy > > to anonymize > > > (or remove entries if privacy is required for that domain if the=20 > > > entity does not have access to a privacy service). [/MB2] > > > > > > This occurs as RFC3323 states in section 4.3: "However, if > > the Privacy > > > header value of 'none' is specified in a message, privacy=20 > services=20 > > > MUST NOT perform any privacy function and MUST NOT remove=20 > or modify=20 > > > the Privacy header." > > > > > > The only option for an intermediate node including a H-I > > entry where > > > "Privacy:none" is specified and privacy for the H-I URI is > > required is > > > to include an anonymous entry or not include the H-I entry. > > > [MB2] If privacy is required then yes, you include > > anonymous entries > > > or don't include. That's the basic privacy mechanism for privacy=20 > > > levels of "session" "header" and "history" in the R-URI or > > "history"=20 > > > in the specific entries, as well as when there is a policy > > for privacy > > > for the entries added by a specific domain. The "none"=20 > > really has no > > > influence on the later case per se. [/MB2] > > > > > > In your previous response you stated that we would violate > > RFC3323 if > > > we specified additional behaviour for privacy explicitly > > stated with a > > > URI -n the H-I entry. I don't believe that this is the case > > as RFC3323 > > > only considered privacy in a two party scenario and did not > > consider > > > third party identities being included in a message between two=20 > > > parties. H-I is not the only case where this occurs as the > > Referred-By > > > header when included in the INVITE (or other request)=20 > which results=20 > > > from the REFER has the same issue. > > > [MB2] I can't necessarily disagree on this one (we can debate it=20 > > > either way). But to fix it requires an update to RFC 3323 and=20 > > > shouldn't be something that we want to fix in 4244bis. [/MB2] > > > > > > RFC4244 was the first time that there was a recognition > > that privacy > > > for these individual third party identities may be > > required. To allow > > > this explicit statement of privacy to be overridden by a generic=20 > > > statement which is applicable to a different user is > > counterintuitive. > > > [MB2] See my comment above. But, as I have consistently > > said, the idea > > > that an entity might want to override the "none" is > > entirely based on > > > policy and 4244 and 4244bis allow privacy to be applied to > > the entries > > > that are added by that entity if the policy dictates so (and we=20 > > > already say that). [/MB2] > > > > > > The original Privacy header is usually included by or on > > behalf of the > > > originating user and should not be allowed to specify the > > privacy of > > > the original called user, e.g. the 800 number, and prevent this=20 > > > identity being presented if this user does not have the > > same level of privacy. > > > [MB2] As I tried to say in a previous response, a random > > entity (i.e., > > > one for whom the R-URI is not in a domain under its=20 > control) cannot=20 > > > add a privacy header to the Request. Per RFC 3323 an=20 > entity may add=20 > > > the header to a request only if it has the appropriate=20 > > > relationship/authorization with the original called user > > who intiated > > > the request. And, I would find it very surprising if an=20 > entity that=20 > > > did have responsibility would apply privacy since that would be=20 > > > counter intuitive and I would hope that SPs would be judicious in=20 > > > specifying the appropriate and inappropriate manner in which the=20 > > > proxies they deploy and interface with privatize the=20 > messages. The=20 > > > protocol CANNOT control this behavior and that's why there is the=20 > > > policy clause in 4244 and 4244bis. [/MB2] > > > > > > The real issue with the 800 scenario is as you have stated > > is that the > > > answerer will not know the original called identity and=20 > will not be=20 > > > able to correctly handle the call. As more generic call=20 > centres are=20 > > > used which will answer calls on behalf of many different > > organizations > > > using CTI and the original called identity to have to implement a=20 > > > generic system asking the caller who he originally called appear=20 > > > unprofessional, is inefficient and unproductive. > > > [MB2] And, as I noted, it is rare for a call centre to=20 > route a call=20 > > > directly to an agent without a user providing some sort of > > input. Even > > > companies like American Airlines, even though they have the > > info that > > > I enter via the IVR, they still ask some basic questions > > and there are > > > times when they have to reroute me. I don't think we can totally=20 > > > automate things. And, again, once the call hits the=20 > domain that is=20 > > > responsible for that 800 number the entities in that domain have=20 > > > control over how they muck with the R-URI, such that they=20 > should be=20 > > > able to use any IVR info to appropriately direct the call - > > it's not > > > the number that's meaningful, but how the system gets the > > call to the > > > right user and the additional information they provide as > > the call is > > > presented to the agent. I would honestly think that having > > something > > > other than an 800 number show up on the display would be far more=20 > > > useful and in my experience in the systems I developed > > we're usually > > > talking about CTI interfaces so you have a lot you can do. And,=20 > > > actually all of this really doesn't matter in that you MUST > > be able to > > > handle this situation independent of the privacy since > > History-Info is > > > optional, you need default behavior assigned. [/MB2] > > > > > > We have an opportunity to allow presentation of specific=20 > identities=20 > > > and to solve this particular problem so we should take it. > > > [MB2] The most we can do is to document the risks/impacts > > of the use > > > of the Privacy headers at the R-URI level. There is=20 > already general=20 > > > text in > > > 4244 and 4244bis that the privacy may impact whether the > > applications > > > get the information. And, as I noted before, most > > commercial systems > > > are using B2BUAs which will allow you far more control over > > the use of > > > the Privacy headers in the network. But, again, I don't > > think that's > > > something that should be address in 4244bis. [/MB2] > > > > > > I hope that we can get some wider discussion on this issue > > so a more > > > general consensus can be obtained. > > > > > > Regards > > > > > > Ian > > > > > > > > > > > > -----Original Message----- > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > Sent: 24 June 2009 17:27 > > > To: Ian Elz > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > sipcore@ietf.org; Francois Audet > > > Subject: RE: 4244bis and privacy > > > > > > Hi Ian, > > > > > > Responses inline below [MB]. > > > > > > Mary.=20 > > > > > > -----Original Message----- > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > Sent: Wednesday, June 24, 2009 10:37 AM > > > To: Barnes, Mary (RICH2:AR00) > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > Subject: RE: 4244bis and privacy > > > > > > Mary, > > > > > > I was not proposing that we change the handling of H-I > > which is based > > > upon local policy. If that causes an issue for a network > > operator then > > > they can modify their local policy accordingly or arrange=20 > with the=20 > > > proxy vendor to modify their equipment to be more flexible with=20 > > > regards to policy. > > > > > > Can you clarify for me: > > > > > > If you have a Privacy header with either "session" or=20 > "header" doe=20 > > > this impact the H-I entries or will only a value of > > "history" impact > > > the H-I entries? > > > [MB] Yes, both "session" and "header" level privacy, > > consistent with > > > RFC 3323, mandate that entries be anonymized or dropped, with the=20 > > > latter being the recommendation for "session" level > > privacy. RFC 4244 > > > mandated that they be dropped and 4244bis recommends they be=20 > > > anonymized. The original intent for the value of "history" > > was for the > > > tagging of the individual entries, but you end up getting > > the header > > > level functionality as well. [/MB] > > > > > > If you have a Privacy header with a value of "none" and a=20 > H-I entry=20 > > > with Privacy header parameter with value "history" what is > > the privacy > > > of the individual H-I entry? > > > [MB] We did not explicitly address the "none" in RFC=20 > 4244, but the=20 > > > general statement is the privacy headers at the request > > level override > > > any at the hi-entry level. [/MB] > > > > > > From reading RFC4244 a Privacy header with value "history" will=20 > > > effectively make all H-I entries private and there is=20 > currently no=20 > > > option to include a H-I Privacy header parameter with=20 > value "none". > > > [MB] Correct, per my comment above. [/MB] > > > > > > H-I at present allows the inclusion of Privacy header=20 > parameters to=20 > > > explicitly express privacy for an individual H-I entry=20 > but a single=20 > > > node which includes a header "Privacy: history" makes all > > H-I entries > > > private even if this is not the requirements for the specific URI. > > > [MB] Correct, but the only node that should add the header > > is a node > > > which is responsible for the domain associated with the > > Request URI in > > > the incoming request or is authorized to do so. [/MB] > > > > > > I will admit that having worked in a telephony environment > > for a long > > > time I am used to having privacy of identities set on a=20 > per number=20 > > > basis and the relative inflexibility of the IETF Privacy=20 > header is=20 > > > relatively restrictive as to specifying which identities may be=20 > > > presented and which not. > > > [MB] Yes, this is an entirely different paradigm. I developed=20 > > > telephony s/w for over a decade and this is entirely=20 > different - it=20 > > > provides a lot more flexibility, which makes things far, far less=20 > > > deterministic than what you have in telephony switches where your=20 > > > routing and translations are configured for the most part, > > with just a > > > few capabilities for controlling the privacy and it's a > > closed network. > > > > > > With RFC4244/4244bis, there MUST be a mechanism at the UAS or end=20 > > > application that can handle a request that doesn't have the=20 > > > appropriate information either because nodes didn't support=20 > > > History-Info or some random node in the network applied > > privacy (which > > > I think is highly > > > unlikely) - this is normative per section 5 of RFC 4244. So, the=20 > > > worst case scenario I see for this 800 service (which will > > get to the > > > right UAS but without the exact 800 number that was dialed) > > is that it > > > goes to a default ACD group/customer service agent, etc. who then=20 > > > needs to gather the appropriate information and in my > > experience this > > > is often an IVR system these days. So, the service is not > > broken when > > > privacy is applied in an undesireable manner, it's just not > > optimal. =20 > > > This is something that should be addressed in the=20 > target-uri draft=20 > > > which has all the details of how specific services use=20 > History-Info. > > > One other thing to consider is that most networks that are > > emulating > > > telephony type features use B2BUAs, which follow the > > UAS/UAC rules for > > > the header rather than the proxy rules, noting that the=20 > UAC can set=20 > > > the Privacy header to whatever value it sees as appropriate > > for the request. > > > [/MB] > > > > > > > > > Regards > > > > > > Ian > > > > > > -----Original Message----- > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > Sent: 24 June 2009 15:48 > > > To: Ian Elz > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > sipcore@ietf.org; Francois Audet > > > Subject: RE: 4244bis and privacy > > > > > > Hi Ian, > > > > > > I do not believe we should do the "override" behavior as I > > think that > > > violates RFC 3323, as the "history" is really a subset of=20 > the cases=20 > > > whereby a UAC or proxy would add "session" or "header" to > > the request. > > > And, the latter two cases have the same (undesireable) > > result. I agree > > > this impacts your services, but we can't mandate that > > proxies provide > > > information that might violate their local policies and indeed a=20 > > > proxy's local policies can result in the information being > > anonymized > > > (or removed if they can't anonymize) even in the "none" case. > > > > > > I do believe it's reasonable that we strongly recommend that the=20 > > > request level (versus specific hi-entries) not be used=20 > and if it is=20 > > > used, the consequence is that some services will not have the=20 > > > information they need - this was the gist of my previous > > response (to > > > which I did not get any additional feedback). Now, we could > > add some text that the "none" > > > case SHOULD be used (e.g., added by first hop proxy) if it > > is desired > > > that the information not be subject to privacy > > restrictions. I do not > > > think it is then particularly useful to add logic around=20 > the proxy=20 > > > then being able to tag the entries within their domain as > > subject to privacy. > > > I think that conflicts with the intent of the request=20 > level "none". > > > However, as I mention above, per the current text, a proxy > > can (based > > > on local policy) remove entries - so a proxy can capture=20 > hi within=20 > > > their domain and not forward any of that information to the > > next hop > > > in another domain - you already have that functionality. =20 > > But, I think > > > this introduces the general problem that you might be > > impacting other > > > services further down the line, which I thought was the=20 > problem you=20 > > > were wanting to solve - not specifically your example > > service but, for > > > example, in the case that someone is debugging and they want the=20 > > > entire history, so depending upon the service, this is also=20 > > > undesirable behavior. > > > > > > > > > Regards, > > > Mary.=20 > > > > > > -----Original Message----- > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > Sent: Wednesday, June 24, 2009 2:57 AM > > > To: Barnes, Mary (RICH2:AR00) > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > Subject: RE: 4244bis and privacy > > > > > > > > > Mary, > > > > > > [I have added the list to this thread for wider comment.] > > > > > > In the previous discussions I commented that in RFC4424 > > that a Privacy > > > header with value "history" effectively makes all H-I > > entries private > > > with the result that the H-I entries may be removed. > > > > > > There has now been a comprehensive discussion on=20 > indication of the=20 > > > initial 'target' to the final recipient for call handling=20 > purposes. > > > > > > The main use case related to a freephone example where the > > answering > > > location may be a call centre where the original freephone > > number may > > > be required for correct call handling. > > > > > > If you now consider the following example (modified from=20 > Francois'=20 > > > text in the latest draft - excuse any errors that I may > > have inserted) > > > > > > INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx > > > Privacy: history > > > History-Info: > > >=20 > > ;index=3D1;rt;aor =20 > > (1) > > > History-Info: ;index=3D1.1;mp;aor > > > (2) > > > History-Info: ;index=3D1.1.1;rc > > > (3) > > > > > > In this case due to the Privacy header all of the H-I entries are=20 > > > considered private and the +18001234567 will not be > > delivered to the > > > final destination with the result that call handling may > > not be correct. > > > The Privacy header may have been inserted by any of the=20 > nodes which=20 > > > routed the message and inserted a H-I entry. > > > > > > If however the H-I was allowed to include a header parameter of=20 > > > "?Privacy=3Dnone" in the H-I entry and that an explicit H-I entry=20 > > > privacy value would be considered to have precedence over=20 > a Privacy=20 > > > header with a value of "history" then the mapping of the > > +18001234567 > > > could be explicitly specified as not private and may be passed on. > > > > > > Thus when the mapping from sip:+18001234567@example.com to=20 > > > sip:bob@biloxi.example.com when H-I entry (2) above is > > included could > > > also insert the Privacy header parameter in H-I entry (1). > > > > > > Thus the message would appear as follows: > > > > > > INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx > > > Privacy: history > > > History-Info: > > >=20 > >=20 > = ;index=3D= 1;rt; > > > ao > > > r > > > History-Info: ;index=3D1.1;mp;aor > > > History-Info: ;index=3D1.1.1;rc > > > > > > This would result in all the H-I entries except (1) being > > considered > > > private with the result that the =3D1800... Number is=20 > passed for call=20 > > > handling purposes. > > > > > > This change is backward compatible with the existing > > implementation as > > > any node using the existing functionality as defined in > > RFC4244 will > > > continue to be supported. > > > > > > The alternative is to remove the ability to include the > > value "history" > > > in the Privacy header and only allow this value in the > > Privacy header > > > parameter. This alternative is not backward compatible. > > > > > > Without this change a single node in the message path which > > includes a > > > header "Privacy: history" will prevent delivery of the=20 > aor and thus=20 > > > prevent proper call handling. > > > > > > Ian Elz > > > > > > > > > > > > -----Original Message----- > > > From: Christer Holmberg > > > Sent: 23 June 2009 19:40 > > > To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida=20 > > > Schubert > > > Cc: Ian Elz > > > Subject: RE: 4244bis and privacy > > > > > > =20 > > > Hi, > > > > > > I include Ian, so he can comment to your resposne himself. > > > > > > Regards, > > > > > > Christer > > > > > > > > > -----Original Message----- > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > Sent: Tuesday, June 23, 2009 9:40 PM > > > To: Christer Holmberg; Francois Audet; Hans Erik van=20 > Elburg; Shida=20 > > > Schubert > > > Subject: RE: 4244bis and privacy > > > > > > Here was the thread of response and the last comment was > > from Ian that > > > he would consider the response: > > > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html > > > > > > And, there was not agreement on the "none" but rather to > > qualify the > > > SHOULD NOT forward. However, in the sipcore-4244bis-00, > > rather than > > > changing the text such that the headers SHOULD be removed, we=20 > > > recommend that they be anonymized (in section 4.3.3.3.1).=20 > That is=20 > > > entirely consistent with RFC 3324 and thus we have removed the=20 > > > recommendations to remove the headers entirely. However, > > that changed > > > never got done in section 3.2, so we would need to change this: > > > "Thus, the History- Info header > > > SHOULD NOT be included in Requests where the requestor > > has indicated > > > a priv-value of Session- or Header-level privacy." > > > > > > But, I'm really beginning to be of the mindset that we=20 > should just=20 > > > remove all the subsections of section 3 (i.e., leave the > > text in the > > > upper level section), so we don't have to keep worrying about=20 > > > consistency. > > > > > > So, lets either fixt the text in 3.2 or remove altogether > > and then I > > > think we are really at the point of needing to submit this > > version so > > > folks that actually have an interest in it can review the updated=20 > > > document. > > > > > > Mary.=20 > > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Tuesday, June 23, 2009 1:10 PM > > > To: Barnes, Mary (RICH2:AR00); Audet, Francois > > (SC100:3055); Hans Erik > > > van Elburg; Shida Schubert > > > Subject: 4244bis and privacy > > > > > > > > > Hi, > > > > > > Below is a comment/proposal which one of my collegues (Ian > > Elz) gave > > > on the list a while ago, when the first version of 4244bis was=20 > > > submitted, but was not incorporated. Do you think it would > > be useful? > > > > > > ------- > > > > > > While the HI approach to target may solve the problem of > > being able to > > > deliver the target URI to the final destination there is no > > guarantee > > > that it will actually be delivered. > > > > > > The problem arises with how Privacy is defined for HI. > > > > > > 4424 defines a new Privacy value "history" which may be placed in=20 > > > either the Privacy header or as a header parameter to the=20 > HI entry. > > > > > > If one node uses the former option "Privacy: history" then > > this will > > > make all headers private and will result in all HI entries being=20 > > > removed or made anonymous when the message containing the HI is=20 > > > delivered to the user. > > > > > > There is a simple solution to this and that is to also > > allow the use > > > of the "none" Privacy value as a header parameter in the=20 > HI entry.=20 > > > This would explicitly state that no privacy is required to the HI=20 > > > entry and this would override a "history" value in the > > Privacy header. > > > > > > I pointed this out to Mary when the 4424bis draft was first > > published > > > but the change has not been made in the latest draft. > > > > > > The change is backward compatible and would not cause an=20 > issue with=20 > > > any existing implementations. > > > > > > ------ > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > =20 > > _______________________________________________ > > 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 >=20 From ian.elz@ericsson.com Mon Jun 29 03:25:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E05193A68EE for ; Mon, 29 Jun 2009 03:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-BR8mA+92jH for ; Mon, 29 Jun 2009 03:25:21 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A194E3A6AAD for ; Mon, 29 Jun 2009 03:25:19 -0700 (PDT) X-AuditID: c1b4fb3e-b7be1ae000004757-cf-4a4896a0abc5 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id B2.8C.18263.0A6984A4; Mon, 29 Jun 2009 12:25:37 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Jun 2009 12:25:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Jun 2009 12:26:11 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EB6BD69@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] 4244bis and privacy Thread-Index: Acn11AWR+Z7be2FAQvKtnWIFO4vfcAAB1KHQAABgLvAAFKai8AAAYdKwABEiZHAAitux8A== References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com><9886E5FCA6D76549A3011068483A4BD4048F809B@S4DE8PSAAQB.mitte.t-com.de><4A43DEC9.1020802@gmail.com><9886E5FCA6D76549A3011068483A4BD4048F80AC@S4DE8PSAAQB.mitte.t-com.de><1ECE0EB50388174790F9694F77522CCF1EB26AB5@zrc2hxm0.corp.nortel.com><0D5F89FAC29E2C41B98A6A762007F5D00213AA4C@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1EB6BD69@zrc2hxm0.corp.nortel.com> From: "Ian Elz" To: "Francois Audet" , "Elwell, John" , "Mary Barnes" , , X-OriginalArrivalTime: 29 Jun 2009 10:25:36.0173 (UTC) FILETIME=[F0E5F5D0:01C9F8A3] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 10:25:25 -0000 Francios, I agree that 4244bis should not specify the actions of proxies etc where = this is a matter of local policy. My original proposed change was to allow the inclusion of the value = "none" in the alongside the value "history" to be included in the = Privacy header parameter escaped in the hi-targeted-to-uri. (RFC4244 = section 4.1) It appears however that the current interpretation of the Privacy header = means that the value included in the Privacy header, which is applicable = to the originating rather than retargeting user is applied to the = retargeting user rather than the explicit value included for the = retargeting user. The escaped privacy value is only used if there is no = Privacy header or the Privacy header only contains the value "user". The end result of this interpretation is that including an explicit = value "none" escaped as a Privacy parameter would have no effect and = would have the same meaning as not including a Privacy header parameter = escaped in the hi-targeted-to-uri. 4244bis is not the place to extend the sip Privacy handling to specify = how 3rd party identities in sip messages should have their own specific = privacy maintained. Allowing the inclusion of the explicitly Privacy=3Dnone value in the = hi-targeted-to-uri would not change any handling at this time but would = make the new H-I RFC suitable for use if an updated privacy RFC is = proposed which does have specific support for 3rd party identities. H-I is not the only place where the explicit privacy of 3rd party = identities is required. The Referred-By header is one other case where a = similar explicit privacy may need to be considered in the future. regards Ian -----Original Message----- From: Francois Audet [mailto:audet@nortel.com]=20 Sent: 26 June 2009 16:55 To: Ian Elz; Elwell, John; Mary Barnes; R.Jesske@telekom.de; = ietf.hanserik@gmail.com Cc: sipcore@ietf.org; shida@agnada.com Subject: RE: [sipcore] 4244bis and privacy I do see things that we should fix right-away in History-Info, regarding = privacy. I also think that History-Info shouldn't "overstrech" and get too deep = into the nitty gritty of privacy. What should be in HI is high level = guidance. In section 3.1, for example, it says that Privacy header will determine = if a History-Info *header field* can be included by an intermediary. = This does not make any sense. What it should say is that the Privacy = header will determine if a history-info *entry* can be added for the UA = inserting the Privacy header. So, in my opinion, we can go ahead and fix that right now. I don't think we need to get into super low-level procedural = descriptions of the type "proxy MUST this and that if Privacy =3D=3D = this and that". I believe privacy matters are policy-level decisions = that service providers and enteprises will have, and they are not going = to be implemented by simplistic procedural rules from an RFC. Comments? =20 > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Ian Elz > Sent: Friday, June 26, 2009 01:08 > To: Elwell, John; Barnes, Mary (RICH2:AR00); R.Jesske@telekom.de;=20 > ietf.hanserik@gmail.com > Cc: sipcore@ietf.org; shida@agnada.com > Subject: Re: [sipcore] 4244bis and privacy >=20 > John, >=20 > Your statement " not anonymise or remove any information that the UAC=20 > has already placed in the request " is the key here. >=20 > The UAC has not included the H-I entry, particularly the one=20 > containing the identity of the diverting party. >=20 > This was not considered in RFC3323 and we have an issue where we=20 > cannot determine which entity included which information. > This creates a problem where a restriction by the originating party=20 > will prevent a downstream identity from permitting presentation of=20 > their identity. >=20 > I agree with Mary that this probably requires an update to > RFC3323 so we should start by updating RFC3323 and then move on to the = > other impacted RFCs. The issue that this will raise for H-I is that=20 > there will be another change required after the Privacy RFC has been=20 > agreed. >=20 > This is far from ideal but the 4424bis draft contains a lot more than=20 > just this issue. >=20 > Ian >=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: 26 June 2009 08:30 > To: Mary Barnes; R.Jesske@telekom.de; ietf.hanserik@gmail.com > Cc: Ian Elz; sipcore@ietf.org; shida@agnada.com > Subject: RE: [sipcore] 4244bis and privacy >=20 > =20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > > Sent: 25 June 2009 22:45 > > To: R.Jesske@telekom.de; ietf.hanserik@gmail.com > > Cc: ian.elz@ericsson.com; sipcore@ietf.org; shida@agnada.com > > Subject: Re: [sipcore] 4244bis and privacy > >=20 > > Roland, > >=20 > > The reason you can't have "none" at the request level and > "history" at > > the entry level is because RFC 3323 states that you MUST NOT apply=20 > > privacy to the message. Even if you put "history" in the > entries, the > > privacy service would just ignore that - per RFC 3323. So, if you=20 > > want to change that behavior, then RFC 3323 should be > changed - i.e., > > the MUST NOT for the "none" could be changed to a SHOULD > NOT and then > > a general statement about possible exceptions. Then, we could add=20 > > something to RFC 4244 for this case. But, changing RFC > > 3323 is totally out of scope for what we are currently working on. =20 > [JRE] I would interpret privacy 'none' in RFC 3323 as meaning that a=20 > downstream entity must not anonymise or remove any information that=20 > the UAC has already placed in the request. > If a downstream entity chooses: > - not to add H-I, > - to add anonymised H-I, or > - to anonymise an H-I entry that some intermediate entity has added, I = > don't see that as being in violation of what the UAC has requested. >=20 > John >=20 >=20 > >=20 > > That all said, I would sure think that if you are leaving a > "trusted > > network" that you have a B2BUA in there, as I've said in other=20 > > threads. Thus, the B2BUA builds a new request and certainly > can add a > > privacy header that it believes is appropriate since the outgoing=20 > > request is done by the UAC function of a B2BUA. > >=20 > > Mary.=20 > >=20 > >=20 > > -----Original Message----- > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > > Sent: Thursday, June 25, 2009 4:32 PM > > To: ietf.hanserik@gmail.com > > Cc: Barnes, Mary (RICH2:AR00); ian.elz@ericsson.com; > sipcore@ietf.org; > > shida@agnada.com > > Subject: AW: [sipcore] 4244bis and privacy > >=20 > > Hi Hans Erik, > > We have also to take regulatory into consideration. In Germany the=20 > > last trusted network is responsible for anonymising information. > >=20 > > But nevertheless if Network provider A wants to have History=20 > > completely private this operator will set privacy history for the=20 > > header. > > If the succeeding Operator want to present elements the AS > which adds > > a entry has then to re label all entries from the preceding network=20 > > and the entries from it's own network will be unmarked within the=20 > > Header. > >=20 > > But never the less I fully agree to your last sentence. > >=20 > > The real Question is if this should really be allowed that a entry=20 > > marked with "none" overrules the privacy statement > "history" for the > > complete header. > >=20 > > I'm against this behaviour.=20 > >=20 > > Best Regards > >=20 > > Roland > >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > Gesendet: Donnerstag, 25. Juni 2009 22:32 > > An: Jesske, Roland > > Cc: mary.barnes@nortel.com; ian.elz@ericsson.com; sipcore@ietf.org;=20 > > shida@agnada.com > > Betreff: Re: [sipcore] 4244bis and privacy > >=20 > > Hi Roland, > >=20 > > I don't understand the argument, by the time that the History-Info=20 > > leaves operator A that wishes complete privacy, all the > History-Info > > headers should be anonymised according to 4244 and 4244bis. > >=20 > > What is the point in mandating that operator A to force > operator B to > > also anonymise the entries "owned" by operator B. > >=20 > > It is of course without question that each operator has > full privacy > > control over its own added entries. And each operator can based on=20 > > local policy decide to remove the entire history if it > things that is > > wise to do. > >=20 > > /Hans Erik > >=20 > >=20 > > R.Jesske@telekom.de wrote: > > > Hi Marry and Ian, > > > The whole discussion puzzle me. We have specified CDIV > > within TISPAN and 3GPP.=20 > > > There is described that privacy "none" can be used for > > entries. BUT assuming that each entry has its own privacy > statement if > > needed. > > > I fully agree on Mary's comment that a privacy "history"=20 > > cannot overruled by a privacy value "none" within a entry.=20 > > > There may be operators that would like to keep the whole > > History Info private even if entries has other statements, so the=20 > > entity could add privacy history to the whole header. > > Nothing more. > > > > > > On the other side a Application Server including a entry > > should have the possibility to rewrite the entries so that > instead of > > "history" for the whole header the all received entries within the=20 > > History-Info header will be marked with "history" and the > added header > > (which shall be presented to the terminating user) will either be=20 > > marked with "none" or will not be marked. > > > > > > Perhaps a hint could be given, but I do not insist on it. > > > > > > Best Regards, > > > > > > Roland > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] Im > > > Auftrag von Mary Barnes > > > Gesendet: Donnerstag, 25. Juni 2009 18:29 > > > An: Ian Elz > > > Cc: sipcore@ietf.org; Shida Schubert > > > Betreff: Re: [sipcore] 4244bis and privacy > > > > > > Hi Ian, > > > > > > Responses inline below [MB2]. > > > > > > Mary. > > > > > > -----Original Message----- > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > Sent: Thursday, June 25, 2009 10:13 AM > > > To: Barnes, Mary (RICH2:AR00) > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > Subject: RE: 4244bis and privacy > > > > > > Mary, > > > > > > I am a little concerned about one answer that you gave: > > > > > > > > > If you have a Privacy header with a value of "none" and a > H-I entry > > > with Privacy header parameter with value "history" what is > > the privacy > > > of the individual H-I entry? > > > [MB] We did not explicitly address the "none" in RFC > 4244, but the > > > general statement is the privacy headers at the request > > level override > > > any at the hi-entry level. [/MB] > > > =20 > > > This means that if privacy is required for an individual > > H-I entry but > > > the originating user included "Privacy:none" in the request > > then there > > > is no option to include the real URI in the H-I entry. > > > [MB2] I'm confused here - the "none" definition is as you > > note below, > > > thus "none" prohibits the removal or anonymization of the > entries, > > > thus I would think you would fine this functionality desireable. > > > However, this does not prohibit an entity based on policy > > to anonymize > > > (or remove entries if privacy is required for that domain if the=20 > > > entity does not have access to a privacy service). [/MB2] > > > > > > This occurs as RFC3323 states in section 4.3: "However, if > > the Privacy > > > header value of 'none' is specified in a message, privacy > services > > > MUST NOT perform any privacy function and MUST NOT remove > or modify > > > the Privacy header." > > > > > > The only option for an intermediate node including a H-I > > entry where > > > "Privacy:none" is specified and privacy for the H-I URI is > > required is > > > to include an anonymous entry or not include the H-I entry. > > > [MB2] If privacy is required then yes, you include > > anonymous entries > > > or don't include. That's the basic privacy mechanism for privacy=20 > > > levels of "session" "header" and "history" in the R-URI or > > "history"=20 > > > in the specific entries, as well as when there is a policy > > for privacy > > > for the entries added by a specific domain. The "none"=20 > > really has no > > > influence on the later case per se. [/MB2] > > > > > > In your previous response you stated that we would violate > > RFC3323 if > > > we specified additional behaviour for privacy explicitly > > stated with a > > > URI -n the H-I entry. I don't believe that this is the case > > as RFC3323 > > > only considered privacy in a two party scenario and did not > > consider > > > third party identities being included in a message between two=20 > > > parties. H-I is not the only case where this occurs as the > > Referred-By > > > header when included in the INVITE (or other request) > which results > > > from the REFER has the same issue. > > > [MB2] I can't necessarily disagree on this one (we can debate it=20 > > > either way). But to fix it requires an update to RFC 3323 and=20 > > > shouldn't be something that we want to fix in 4244bis. [/MB2] > > > > > > RFC4244 was the first time that there was a recognition > > that privacy > > > for these individual third party identities may be > > required. To allow > > > this explicit statement of privacy to be overridden by a generic=20 > > > statement which is applicable to a different user is > > counterintuitive. > > > [MB2] See my comment above. But, as I have consistently > > said, the idea > > > that an entity might want to override the "none" is > > entirely based on > > > policy and 4244 and 4244bis allow privacy to be applied to > > the entries > > > that are added by that entity if the policy dictates so (and we=20 > > > already say that). [/MB2] > > > > > > The original Privacy header is usually included by or on > > behalf of the > > > originating user and should not be allowed to specify the > > privacy of > > > the original called user, e.g. the 800 number, and prevent this=20 > > > identity being presented if this user does not have the > > same level of privacy. > > > [MB2] As I tried to say in a previous response, a random > > entity (i.e., > > > one for whom the R-URI is not in a domain under its > control) cannot > > > add a privacy header to the Request. Per RFC 3323 an > entity may add > > > the header to a request only if it has the appropriate=20 > > > relationship/authorization with the original called user > > who intiated > > > the request. And, I would find it very surprising if an > entity that > > > did have responsibility would apply privacy since that would be=20 > > > counter intuitive and I would hope that SPs would be judicious in=20 > > > specifying the appropriate and inappropriate manner in which the=20 > > > proxies they deploy and interface with privatize the > messages. The > > > protocol CANNOT control this behavior and that's why there is the=20 > > > policy clause in 4244 and 4244bis. [/MB2] > > > > > > The real issue with the 800 scenario is as you have stated > > is that the > > > answerer will not know the original called identity and > will not be > > > able to correctly handle the call. As more generic call > centres are > > > used which will answer calls on behalf of many different > > organizations > > > using CTI and the original called identity to have to implement a=20 > > > generic system asking the caller who he originally called appear=20 > > > unprofessional, is inefficient and unproductive. > > > [MB2] And, as I noted, it is rare for a call centre to > route a call > > > directly to an agent without a user providing some sort of > > input. Even > > > companies like American Airlines, even though they have the > > info that > > > I enter via the IVR, they still ask some basic questions > > and there are > > > times when they have to reroute me. I don't think we can totally=20 > > > automate things. And, again, once the call hits the > domain that is > > > responsible for that 800 number the entities in that domain have=20 > > > control over how they muck with the R-URI, such that they > should be > > > able to use any IVR info to appropriately direct the call - > > it's not > > > the number that's meaningful, but how the system gets the > > call to the > > > right user and the additional information they provide as > > the call is > > > presented to the agent. I would honestly think that having > > something > > > other than an 800 number show up on the display would be far more=20 > > > useful and in my experience in the systems I developed > > we're usually > > > talking about CTI interfaces so you have a lot you can do. And,=20 > > > actually all of this really doesn't matter in that you MUST > > be able to > > > handle this situation independent of the privacy since > > History-Info is > > > optional, you need default behavior assigned. [/MB2] > > > > > > We have an opportunity to allow presentation of specific > identities > > > and to solve this particular problem so we should take it. > > > [MB2] The most we can do is to document the risks/impacts > > of the use > > > of the Privacy headers at the R-URI level. There is > already general > > > text in > > > 4244 and 4244bis that the privacy may impact whether the > > applications > > > get the information. And, as I noted before, most > > commercial systems > > > are using B2BUAs which will allow you far more control over > > the use of > > > the Privacy headers in the network. But, again, I don't > > think that's > > > something that should be address in 4244bis. [/MB2] > > > > > > I hope that we can get some wider discussion on this issue > > so a more > > > general consensus can be obtained. > > > > > > Regards > > > > > > Ian > > > > > > > > > > > > -----Original Message----- > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > Sent: 24 June 2009 17:27 > > > To: Ian Elz > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > sipcore@ietf.org; Francois Audet > > > Subject: RE: 4244bis and privacy > > > > > > Hi Ian, > > > > > > Responses inline below [MB]. > > > > > > Mary.=20 > > > > > > -----Original Message----- > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > Sent: Wednesday, June 24, 2009 10:37 AM > > > To: Barnes, Mary (RICH2:AR00) > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > Subject: RE: 4244bis and privacy > > > > > > Mary, > > > > > > I was not proposing that we change the handling of H-I > > which is based > > > upon local policy. If that causes an issue for a network > > operator then > > > they can modify their local policy accordingly or arrange > with the > > > proxy vendor to modify their equipment to be more flexible with=20 > > > regards to policy. > > > > > > Can you clarify for me: > > > > > > If you have a Privacy header with either "session" or > "header" doe > > > this impact the H-I entries or will only a value of > > "history" impact > > > the H-I entries? > > > [MB] Yes, both "session" and "header" level privacy, > > consistent with > > > RFC 3323, mandate that entries be anonymized or dropped, with the=20 > > > latter being the recommendation for "session" level > > privacy. RFC 4244 > > > mandated that they be dropped and 4244bis recommends they be=20 > > > anonymized. The original intent for the value of "history" > > was for the > > > tagging of the individual entries, but you end up getting > > the header > > > level functionality as well. [/MB] > > > > > > If you have a Privacy header with a value of "none" and a > H-I entry > > > with Privacy header parameter with value "history" what is > > the privacy > > > of the individual H-I entry? > > > [MB] We did not explicitly address the "none" in RFC > 4244, but the > > > general statement is the privacy headers at the request > > level override > > > any at the hi-entry level. [/MB] > > > > > > From reading RFC4244 a Privacy header with value "history" will=20 > > > effectively make all H-I entries private and there is > currently no > > > option to include a H-I Privacy header parameter with > value "none". > > > [MB] Correct, per my comment above. [/MB] > > > > > > H-I at present allows the inclusion of Privacy header > parameters to > > > explicitly express privacy for an individual H-I entry > but a single > > > node which includes a header "Privacy: history" makes all > > H-I entries > > > private even if this is not the requirements for the specific URI. > > > [MB] Correct, but the only node that should add the header > > is a node > > > which is responsible for the domain associated with the > > Request URI in > > > the incoming request or is authorized to do so. [/MB] > > > > > > I will admit that having worked in a telephony environment > > for a long > > > time I am used to having privacy of identities set on a > per number > > > basis and the relative inflexibility of the IETF Privacy > header is > > > relatively restrictive as to specifying which identities may be=20 > > > presented and which not. > > > [MB] Yes, this is an entirely different paradigm. I developed=20 > > > telephony s/w for over a decade and this is entirely > different - it > > > provides a lot more flexibility, which makes things far, far less=20 > > > deterministic than what you have in telephony switches where your=20 > > > routing and translations are configured for the most part, > > with just a > > > few capabilities for controlling the privacy and it's a > > closed network. > > > > > > With RFC4244/4244bis, there MUST be a mechanism at the UAS or end=20 > > > application that can handle a request that doesn't have the=20 > > > appropriate information either because nodes didn't support=20 > > > History-Info or some random node in the network applied > > privacy (which > > > I think is highly > > > unlikely) - this is normative per section 5 of RFC 4244. So, the=20 > > > worst case scenario I see for this 800 service (which will > > get to the > > > right UAS but without the exact 800 number that was dialed) > > is that it > > > goes to a default ACD group/customer service agent, etc. who then=20 > > > needs to gather the appropriate information and in my > > experience this > > > is often an IVR system these days. So, the service is not > > broken when > > > privacy is applied in an undesireable manner, it's just not > > optimal. =20 > > > This is something that should be addressed in the > target-uri draft > > > which has all the details of how specific services use > History-Info. > > > One other thing to consider is that most networks that are > > emulating > > > telephony type features use B2BUAs, which follow the > > UAS/UAC rules for > > > the header rather than the proxy rules, noting that the > UAC can set > > > the Privacy header to whatever value it sees as appropriate > > for the request. > > > [/MB] > > > > > > > > > Regards > > > > > > Ian > > > > > > -----Original Message----- > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > Sent: 24 June 2009 15:48 > > > To: Ian Elz > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > sipcore@ietf.org; Francois Audet > > > Subject: RE: 4244bis and privacy > > > > > > Hi Ian, > > > > > > I do not believe we should do the "override" behavior as I > > think that > > > violates RFC 3323, as the "history" is really a subset of > the cases > > > whereby a UAC or proxy would add "session" or "header" to > > the request. > > > And, the latter two cases have the same (undesireable) > > result. I agree > > > this impacts your services, but we can't mandate that > > proxies provide > > > information that might violate their local policies and indeed a=20 > > > proxy's local policies can result in the information being > > anonymized > > > (or removed if they can't anonymize) even in the "none" case. > > > > > > I do believe it's reasonable that we strongly recommend that the=20 > > > request level (versus specific hi-entries) not be used > and if it is > > > used, the consequence is that some services will not have the=20 > > > information they need - this was the gist of my previous > > response (to > > > which I did not get any additional feedback). Now, we could > > add some text that the "none" > > > case SHOULD be used (e.g., added by first hop proxy) if it > > is desired > > > that the information not be subject to privacy > > restrictions. I do not > > > think it is then particularly useful to add logic around > the proxy > > > then being able to tag the entries within their domain as > > subject to privacy. > > > I think that conflicts with the intent of the request > level "none". > > > However, as I mention above, per the current text, a proxy > > can (based > > > on local policy) remove entries - so a proxy can capture > hi within > > > their domain and not forward any of that information to the > > next hop > > > in another domain - you already have that functionality. =20 > > But, I think > > > this introduces the general problem that you might be > > impacting other > > > services further down the line, which I thought was the > problem you > > > were wanting to solve - not specifically your example > > service but, for > > > example, in the case that someone is debugging and they want the=20 > > > entire history, so depending upon the service, this is also=20 > > > undesirable behavior. > > > > > > > > > Regards, > > > Mary.=20 > > > > > > -----Original Message----- > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > Sent: Wednesday, June 24, 2009 2:57 AM > > > To: Barnes, Mary (RICH2:AR00) > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > Subject: RE: 4244bis and privacy > > > > > > > > > Mary, > > > > > > [I have added the list to this thread for wider comment.] > > > > > > In the previous discussions I commented that in RFC4424 > > that a Privacy > > > header with value "history" effectively makes all H-I > > entries private > > > with the result that the H-I entries may be removed. > > > > > > There has now been a comprehensive discussion on > indication of the > > > initial 'target' to the final recipient for call handling > purposes. > > > > > > The main use case related to a freephone example where the > > answering > > > location may be a call centre where the original freephone > > number may > > > be required for correct call handling. > > > > > > If you now consider the following example (modified from > Francois'=20 > > > text in the latest draft - excuse any errors that I may > > have inserted) > > > > > > INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx > > > Privacy: history > > > History-Info: > > >=20 > > ;index=3D1;rt;aor =20 > > (1) > > > History-Info: ;index=3D1.1;mp;aor > > > (2) > > > History-Info: ;index=3D1.1.1;rc > > > (3) > > > > > > In this case due to the Privacy header all of the H-I entries are=20 > > > considered private and the +18001234567 will not be > > delivered to the > > > final destination with the result that call handling may > > not be correct. > > > The Privacy header may have been inserted by any of the > nodes which > > > routed the message and inserted a H-I entry. > > > > > > If however the H-I was allowed to include a header parameter of=20 > > > "?Privacy=3Dnone" in the H-I entry and that an explicit H-I entry=20 > > > privacy value would be considered to have precedence over > a Privacy > > > header with a value of "history" then the mapping of the > > +18001234567 > > > could be explicitly specified as not private and may be passed on. > > > > > > Thus when the mapping from sip:+18001234567@example.com to=20 > > > sip:bob@biloxi.example.com when H-I entry (2) above is > > included could > > > also insert the Privacy header parameter in H-I entry (1). > > > > > > Thus the message would appear as follows: > > > > > > INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx > > > Privacy: history > > > History-Info: > > >=20 > >=20 > = ;index=3D= 1;rt; > > > ao > > > r > > > History-Info: ;index=3D1.1;mp;aor > > > History-Info: ;index=3D1.1.1;rc > > > > > > This would result in all the H-I entries except (1) being > > considered > > > private with the result that the =3D1800... Number is > passed for call > > > handling purposes. > > > > > > This change is backward compatible with the existing > > implementation as > > > any node using the existing functionality as defined in > > RFC4244 will > > > continue to be supported. > > > > > > The alternative is to remove the ability to include the > > value "history" > > > in the Privacy header and only allow this value in the > > Privacy header > > > parameter. This alternative is not backward compatible. > > > > > > Without this change a single node in the message path which > > includes a > > > header "Privacy: history" will prevent delivery of the > aor and thus > > > prevent proper call handling. > > > > > > Ian Elz > > > > > > > > > > > > -----Original Message----- > > > From: Christer Holmberg > > > Sent: 23 June 2009 19:40 > > > To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida=20 > > > Schubert > > > Cc: Ian Elz > > > Subject: RE: 4244bis and privacy > > > > > > =20 > > > Hi, > > > > > > I include Ian, so he can comment to your resposne himself. > > > > > > Regards, > > > > > > Christer > > > > > > > > > -----Original Message----- > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > Sent: Tuesday, June 23, 2009 9:40 PM > > > To: Christer Holmberg; Francois Audet; Hans Erik van > Elburg; Shida > > > Schubert > > > Subject: RE: 4244bis and privacy > > > > > > Here was the thread of response and the last comment was > > from Ian that > > > he would consider the response: > > > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html > > > > > > And, there was not agreement on the "none" but rather to > > qualify the > > > SHOULD NOT forward. However, in the sipcore-4244bis-00, > > rather than > > > changing the text such that the headers SHOULD be removed, we=20 > > > recommend that they be anonymized (in section 4.3.3.3.1). > That is > > > entirely consistent with RFC 3324 and thus we have removed the=20 > > > recommendations to remove the headers entirely. However, > > that changed > > > never got done in section 3.2, so we would need to change this: > > > "Thus, the History- Info header > > > SHOULD NOT be included in Requests where the requestor > > has indicated > > > a priv-value of Session- or Header-level privacy." > > > > > > But, I'm really beginning to be of the mindset that we > should just > > > remove all the subsections of section 3 (i.e., leave the > > text in the > > > upper level section), so we don't have to keep worrying about=20 > > > consistency. > > > > > > So, lets either fixt the text in 3.2 or remove altogether > > and then I > > > think we are really at the point of needing to submit this > > version so > > > folks that actually have an interest in it can review the updated=20 > > > document. > > > > > > Mary.=20 > > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > Sent: Tuesday, June 23, 2009 1:10 PM > > > To: Barnes, Mary (RICH2:AR00); Audet, Francois > > (SC100:3055); Hans Erik > > > van Elburg; Shida Schubert > > > Subject: 4244bis and privacy > > > > > > > > > Hi, > > > > > > Below is a comment/proposal which one of my collegues (Ian > > Elz) gave > > > on the list a while ago, when the first version of 4244bis was=20 > > > submitted, but was not incorporated. Do you think it would > > be useful? > > > > > > ------- > > > > > > While the HI approach to target may solve the problem of > > being able to > > > deliver the target URI to the final destination there is no > > guarantee > > > that it will actually be delivered. > > > > > > The problem arises with how Privacy is defined for HI. > > > > > > 4424 defines a new Privacy value "history" which may be placed in=20 > > > either the Privacy header or as a header parameter to the > HI entry. > > > > > > If one node uses the former option "Privacy: history" then > > this will > > > make all headers private and will result in all HI entries being=20 > > > removed or made anonymous when the message containing the HI is=20 > > > delivered to the user. > > > > > > There is a simple solution to this and that is to also > > allow the use > > > of the "none" Privacy value as a header parameter in the > HI entry.=20 > > > This would explicitly state that no privacy is required to the HI=20 > > > entry and this would override a "history" value in the > > Privacy header. > > > > > > I pointed this out to Mary when the 4424bis draft was first > > published > > > but the change has not been made in the latest draft. > > > > > > The change is backward compatible and would not cause an > issue with > > > any existing implementations. > > > > > > ------ > > > > > > Regards, > > > > > > Christer > > > > > > > > > > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > =20 > > _______________________________________________ > > 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 >=20 From AUDET@nortel.com Mon Jun 29 16:06:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5F503A6C6D for ; Mon, 29 Jun 2009 16:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.072 X-Spam-Level: X-Spam-Status: No, score=-6.072 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyNXLyvHgaHb for ; Mon, 29 Jun 2009 16:06:25 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 96D333A6876 for ; Mon, 29 Jun 2009 16:06:25 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n5TN6dU02344; Mon, 29 Jun 2009 23:06:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Jun 2009 18:05:47 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EBE2181@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] 4244bis and privacy thread-index: Acn11AWR+Z7be2FAQvKtnWIFO4vfcAAB1KHQAABgLvAAFKai8AAAYdKwABEiZHAAitux8AAa+YTg References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com><9886E5FCA6D76549A3011068483A4BD4048F809B@S4DE8PSAAQB.mitte.t-com.de><4A43DEC9.1020802@gmail.com><9886E5FCA6D76549A3011068483A4BD4048F80AC@S4DE8PSAAQB.mitte.t-com.de><1ECE0EB50388174790F9694F77522CCF1EB26AB5@zrc2hxm0.corp.nortel.com><0D5F89FAC29E2C41B98A6A762007F5D00213AA4C@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1EB6BD69@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Ian Elz" , "Elwell, John" , "Mary Barnes" , , Cc: sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 23:06:28 -0000 I think the current "interpretation" is not terribly useful. I prefer your suggestion. The current RFC 4244 text is not very clear. It seems to me that: - Privacy should associated with a specific hi-entry (and perhaps any entry that corresponds to that same user), and not the header itself. - That way, it is possible that specific entries be anonymize, but not others. For example, if you call me without privacy, and I call = forward you to John with privacy setup for myself, John should see an entry = for you and an anonymized entry for me. - There is no reason why "none" couldn't be used in this context. Again, = with the same example as above, John could requies "none" for him, and I could set privacy on for myself. I don't think this type of rule for 4244bis would require any change whatsoever to RFC 3323. It would be completely self-contained in 4244bis. Comments? > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com]=20 > Sent: Monday, June 29, 2009 03:26 > To: Audet, Francois (SC100:3055); Elwell, John; Barnes, Mary=20 > (RICH2:AR00); R.Jesske@telekom.de; ietf.hanserik@gmail.com > Cc: sipcore@ietf.org; shida@agnada.com > Subject: RE: [sipcore] 4244bis and privacy >=20 > Francios, >=20 > I agree that 4244bis should not specify the actions of=20 > proxies etc where this is a matter of local policy. >=20 > My original proposed change was to allow the inclusion of the=20 > value "none" in the alongside the value "history" to be=20 > included in the Privacy header parameter escaped in the=20 > hi-targeted-to-uri. (RFC4244 section 4.1) >=20 > It appears however that the current interpretation of the=20 > Privacy header means that the value included in the Privacy=20 > header, which is applicable to the originating rather than=20 > retargeting user is applied to the retargeting user rather=20 > than the explicit value included for the retargeting user.=20 > The escaped privacy value is only used if there is no Privacy=20 > header or the Privacy header only contains the value "user". >=20 > The end result of this interpretation is that including an=20 > explicit value "none" escaped as a Privacy parameter would=20 > have no effect and would have the same meaning as not=20 > including a Privacy header parameter escaped in the=20 > hi-targeted-to-uri. >=20 > 4244bis is not the place to extend the sip Privacy handling=20 > to specify how 3rd party identities in sip messages should=20 > have their own specific privacy maintained. >=20 > Allowing the inclusion of the explicitly Privacy=3Dnone value=20 > in the hi-targeted-to-uri would not change any handling at=20 > this time but would make the new H-I RFC suitable for use if=20 > an updated privacy RFC is proposed which does have specific=20 > support for 3rd party identities. >=20 > H-I is not the only place where the explicit privacy of 3rd=20 > party identities is required. The Referred-By header is one=20 > other case where a similar explicit privacy may need to be=20 > considered in the future. >=20 > regards >=20 > Ian >=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 26 June 2009 16:55 > To: Ian Elz; Elwell, John; Mary Barnes; R.Jesske@telekom.de;=20 > ietf.hanserik@gmail.com > Cc: sipcore@ietf.org; shida@agnada.com > Subject: RE: [sipcore] 4244bis and privacy >=20 > I do see things that we should fix right-away in=20 > History-Info, regarding privacy. >=20 > I also think that History-Info shouldn't "overstrech" and get=20 > too deep into the nitty gritty of privacy. What should be in=20 > HI is high level guidance. >=20 > In section 3.1, for example, it says that Privacy header will=20 > determine if a History-Info *header field* can be included by=20 > an intermediary. This does not make any sense. What it should=20 > say is that the Privacy header will determine if a=20 > history-info *entry* can be added for the UA inserting the=20 > Privacy header. >=20 > So, in my opinion, we can go ahead and fix that right now. >=20 > I don't think we need to get into super low-level procedural=20 > descriptions of the type "proxy MUST this and that if Privacy=20 > =3D=3D this and that". I believe privacy matters are policy-level=20 > decisions that service providers and enteprises will have,=20 > and they are not going to be implemented by simplistic=20 > procedural rules from an RFC. >=20 > Comments? > =20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Ian Elz > > Sent: Friday, June 26, 2009 01:08 > > To: Elwell, John; Barnes, Mary (RICH2:AR00); R.Jesske@telekom.de;=20 > > ietf.hanserik@gmail.com > > Cc: sipcore@ietf.org; shida@agnada.com > > Subject: Re: [sipcore] 4244bis and privacy > >=20 > > John, > >=20 > > Your statement " not anonymise or remove any information=20 > that the UAC=20 > > has already placed in the request " is the key here. > >=20 > > The UAC has not included the H-I entry, particularly the one=20 > > containing the identity of the diverting party. > >=20 > > This was not considered in RFC3323 and we have an issue where we=20 > > cannot determine which entity included which information. > > This creates a problem where a restriction by the originating party=20 > > will prevent a downstream identity from permitting presentation of=20 > > their identity. > >=20 > > I agree with Mary that this probably requires an update to > > RFC3323 so we should start by updating RFC3323 and then=20 > move on to the=20 > > other impacted RFCs. The issue that this will raise for H-I is that=20 > > there will be another change required after the Privacy RFC=20 > has been=20 > > agreed. > >=20 > > This is far from ideal but the 4424bis draft contains a lot=20 > more than=20 > > just this issue. > >=20 > > Ian > >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: 26 June 2009 08:30 > > To: Mary Barnes; R.Jesske@telekom.de; ietf.hanserik@gmail.com > > Cc: Ian Elz; sipcore@ietf.org; shida@agnada.com > > Subject: RE: [sipcore] 4244bis and privacy > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > > > Sent: 25 June 2009 22:45 > > > To: R.Jesske@telekom.de; ietf.hanserik@gmail.com > > > Cc: ian.elz@ericsson.com; sipcore@ietf.org; shida@agnada.com > > > Subject: Re: [sipcore] 4244bis and privacy > > >=20 > > > Roland, > > >=20 > > > The reason you can't have "none" at the request level and > > "history" at > > > the entry level is because RFC 3323 states that you MUST=20 > NOT apply=20 > > > privacy to the message. Even if you put "history" in the > > entries, the > > > privacy service would just ignore that - per RFC 3323. =20 > So, if you=20 > > > want to change that behavior, then RFC 3323 should be > > changed - i.e., > > > the MUST NOT for the "none" could be changed to a SHOULD > > NOT and then > > > a general statement about possible exceptions. Then, we could add=20 > > > something to RFC 4244 for this case. But, changing RFC > > > 3323 is totally out of scope for what we are currently=20 > working on. =20 > > [JRE] I would interpret privacy 'none' in RFC 3323 as=20 > meaning that a=20 > > downstream entity must not anonymise or remove any information that=20 > > the UAC has already placed in the request. > > If a downstream entity chooses: > > - not to add H-I, > > - to add anonymised H-I, or > > - to anonymise an H-I entry that some intermediate entity=20 > has added, I=20 > > don't see that as being in violation of what the UAC has requested. > >=20 > > John > >=20 > >=20 > > >=20 > > > That all said, I would sure think that if you are leaving a > > "trusted > > > network" that you have a B2BUA in there, as I've said in other=20 > > > threads. Thus, the B2BUA builds a new request and certainly > > can add a > > > privacy header that it believes is appropriate since the outgoing=20 > > > request is done by the UAC function of a B2BUA. > > >=20 > > > Mary.=20 > > >=20 > > >=20 > > > -----Original Message----- > > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > > > Sent: Thursday, June 25, 2009 4:32 PM > > > To: ietf.hanserik@gmail.com > > > Cc: Barnes, Mary (RICH2:AR00); ian.elz@ericsson.com; > > sipcore@ietf.org; > > > shida@agnada.com > > > Subject: AW: [sipcore] 4244bis and privacy > > >=20 > > > Hi Hans Erik, > > > We have also to take regulatory into consideration. In=20 > Germany the=20 > > > last trusted network is responsible for anonymising information. > > >=20 > > > But nevertheless if Network provider A wants to have History=20 > > > completely private this operator will set privacy history for the=20 > > > header. > > > If the succeeding Operator want to present elements the AS > > which adds > > > a entry has then to re label all entries from the=20 > preceding network=20 > > > and the entries from it's own network will be unmarked within the=20 > > > Header. > > >=20 > > > But never the less I fully agree to your last sentence. > > >=20 > > > The real Question is if this should really be allowed=20 > that a entry=20 > > > marked with "none" overrules the privacy statement > > "history" for the > > > complete header. > > >=20 > > > I'm against this behaviour.=20 > > >=20 > > > Best Regards > > >=20 > > > Roland > > >=20 > > > -----Urspr=FCngliche Nachricht----- > > > Von: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > > Gesendet: Donnerstag, 25. Juni 2009 22:32 > > > An: Jesske, Roland > > > Cc: mary.barnes@nortel.com; ian.elz@ericsson.com;=20 > sipcore@ietf.org;=20 > > > shida@agnada.com > > > Betreff: Re: [sipcore] 4244bis and privacy > > >=20 > > > Hi Roland, > > >=20 > > > I don't understand the argument, by the time that the=20 > History-Info=20 > > > leaves operator A that wishes complete privacy, all the > > History-Info > > > headers should be anonymised according to 4244 and 4244bis. > > >=20 > > > What is the point in mandating that operator A to force > > operator B to > > > also anonymise the entries "owned" by operator B. > > >=20 > > > It is of course without question that each operator has > > full privacy > > > control over its own added entries. And each operator can=20 > based on=20 > > > local policy decide to remove the entire history if it > > things that is > > > wise to do. > > >=20 > > > /Hans Erik > > >=20 > > >=20 > > > R.Jesske@telekom.de wrote: > > > > Hi Marry and Ian, > > > > The whole discussion puzzle me. We have specified CDIV > > > within TISPAN and 3GPP.=20 > > > > There is described that privacy "none" can be used for > > > entries. BUT assuming that each entry has its own privacy > > statement if > > > needed. > > > > I fully agree on Mary's comment that a privacy "history"=20 > > > cannot overruled by a privacy value "none" within a entry.=20 > > > > There may be operators that would like to keep the whole > > > History Info private even if entries has other statements, so the=20 > > > entity could add privacy history to the whole header. > > > Nothing more. > > > > > > > > On the other side a Application Server including a entry > > > should have the possibility to rewrite the entries so that > > instead of > > > "history" for the whole header the all received entries=20 > within the=20 > > > History-Info header will be marked with "history" and the > > added header > > > (which shall be presented to the terminating user) will either be=20 > > > marked with "none" or will not be marked. > > > > > > > > Perhaps a hint could be given, but I do not insist on it. > > > > > > > > Best Regards, > > > > > > > > Roland > > > > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] Im > > > > Auftrag von Mary Barnes > > > > Gesendet: Donnerstag, 25. Juni 2009 18:29 > > > > An: Ian Elz > > > > Cc: sipcore@ietf.org; Shida Schubert > > > > Betreff: Re: [sipcore] 4244bis and privacy > > > > > > > > Hi Ian, > > > > > > > > Responses inline below [MB2]. > > > > > > > > Mary. > > > > > > > > -----Original Message----- > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > Sent: Thursday, June 25, 2009 10:13 AM > > > > To: Barnes, Mary (RICH2:AR00) > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > Subject: RE: 4244bis and privacy > > > > > > > > Mary, > > > > > > > > I am a little concerned about one answer that you gave: > > > > > > > > > > > > If you have a Privacy header with a value of "none" and a > > H-I entry > > > > with Privacy header parameter with value "history" what is > > > the privacy > > > > of the individual H-I entry? > > > > [MB] We did not explicitly address the "none" in RFC > > 4244, but the > > > > general statement is the privacy headers at the request > > > level override > > > > any at the hi-entry level. [/MB] > > > > =20 > > > > This means that if privacy is required for an individual > > > H-I entry but > > > > the originating user included "Privacy:none" in the request > > > then there > > > > is no option to include the real URI in the H-I entry. > > > > [MB2] I'm confused here - the "none" definition is as you > > > note below, > > > > thus "none" prohibits the removal or anonymization of the > > entries, > > > > thus I would think you would fine this functionality desireable. > > > > However, this does not prohibit an entity based on policy > > > to anonymize > > > > (or remove entries if privacy is required for that=20 > domain if the=20 > > > > entity does not have access to a privacy service). [/MB2] > > > > > > > > This occurs as RFC3323 states in section 4.3: "However, if > > > the Privacy > > > > header value of 'none' is specified in a message, privacy > > services > > > > MUST NOT perform any privacy function and MUST NOT remove > > or modify > > > > the Privacy header." > > > > > > > > The only option for an intermediate node including a H-I > > > entry where > > > > "Privacy:none" is specified and privacy for the H-I URI is > > > required is > > > > to include an anonymous entry or not include the H-I entry. > > > > [MB2] If privacy is required then yes, you include > > > anonymous entries > > > > or don't include. That's the basic privacy mechanism=20 > for privacy=20 > > > > levels of "session" "header" and "history" in the R-URI or > > > "history"=20 > > > > in the specific entries, as well as when there is a policy > > > for privacy > > > > for the entries added by a specific domain. The "none"=20 > > > really has no > > > > influence on the later case per se. [/MB2] > > > > > > > > In your previous response you stated that we would violate > > > RFC3323 if > > > > we specified additional behaviour for privacy explicitly > > > stated with a > > > > URI -n the H-I entry. I don't believe that this is the case > > > as RFC3323 > > > > only considered privacy in a two party scenario and did not > > > consider > > > > third party identities being included in a message between two=20 > > > > parties. H-I is not the only case where this occurs as the > > > Referred-By > > > > header when included in the INVITE (or other request) > > which results > > > > from the REFER has the same issue. > > > > [MB2] I can't necessarily disagree on this one (we can=20 > debate it=20 > > > > either way). But to fix it requires an update to RFC 3323 and=20 > > > > shouldn't be something that we want to fix in 4244bis. [/MB2] > > > > > > > > RFC4244 was the first time that there was a recognition > > > that privacy > > > > for these individual third party identities may be > > > required. To allow > > > > this explicit statement of privacy to be overridden by=20 > a generic=20 > > > > statement which is applicable to a different user is > > > counterintuitive. > > > > [MB2] See my comment above. But, as I have consistently > > > said, the idea > > > > that an entity might want to override the "none" is > > > entirely based on > > > > policy and 4244 and 4244bis allow privacy to be applied to > > > the entries > > > > that are added by that entity if the policy dictates so (and we=20 > > > > already say that). [/MB2] > > > > > > > > The original Privacy header is usually included by or on > > > behalf of the > > > > originating user and should not be allowed to specify the > > > privacy of > > > > the original called user, e.g. the 800 number, and prevent this=20 > > > > identity being presented if this user does not have the > > > same level of privacy. > > > > [MB2] As I tried to say in a previous response, a random > > > entity (i.e., > > > > one for whom the R-URI is not in a domain under its > > control) cannot > > > > add a privacy header to the Request. Per RFC 3323 an > > entity may add > > > > the header to a request only if it has the appropriate=20 > > > > relationship/authorization with the original called user > > > who intiated > > > > the request. And, I would find it very surprising if an > > entity that > > > > did have responsibility would apply privacy since that would be=20 > > > > counter intuitive and I would hope that SPs would be=20 > judicious in=20 > > > > specifying the appropriate and inappropriate manner in=20 > which the=20 > > > > proxies they deploy and interface with privatize the > > messages. The > > > > protocol CANNOT control this behavior and that's why=20 > there is the=20 > > > > policy clause in 4244 and 4244bis. [/MB2] > > > > > > > > The real issue with the 800 scenario is as you have stated > > > is that the > > > > answerer will not know the original called identity and > > will not be > > > > able to correctly handle the call. As more generic call > > centres are > > > > used which will answer calls on behalf of many different > > > organizations > > > > using CTI and the original called identity to have to=20 > implement a=20 > > > > generic system asking the caller who he originally=20 > called appear=20 > > > > unprofessional, is inefficient and unproductive. > > > > [MB2] And, as I noted, it is rare for a call centre to > > route a call > > > > directly to an agent without a user providing some sort of > > > input. Even > > > > companies like American Airlines, even though they have the > > > info that > > > > I enter via the IVR, they still ask some basic questions > > > and there are > > > > times when they have to reroute me. I don't think we=20 > can totally=20 > > > > automate things. And, again, once the call hits the > > domain that is > > > > responsible for that 800 number the entities in that=20 > domain have=20 > > > > control over how they muck with the R-URI, such that they > > should be > > > > able to use any IVR info to appropriately direct the call - > > > it's not > > > > the number that's meaningful, but how the system gets the > > > call to the > > > > right user and the additional information they provide as > > > the call is > > > > presented to the agent. I would honestly think that having > > > something > > > > other than an 800 number show up on the display would=20 > be far more=20 > > > > useful and in my experience in the systems I developed > > > we're usually > > > > talking about CTI interfaces so you have a lot you can=20 > do. And,=20 > > > > actually all of this really doesn't matter in that you MUST > > > be able to > > > > handle this situation independent of the privacy since > > > History-Info is > > > > optional, you need default behavior assigned. [/MB2] > > > > > > > > We have an opportunity to allow presentation of specific > > identities > > > > and to solve this particular problem so we should take it. > > > > [MB2] The most we can do is to document the risks/impacts > > > of the use > > > > of the Privacy headers at the R-URI level. There is > > already general > > > > text in > > > > 4244 and 4244bis that the privacy may impact whether the > > > applications > > > > get the information. And, as I noted before, most > > > commercial systems > > > > are using B2BUAs which will allow you far more control over > > > the use of > > > > the Privacy headers in the network. But, again, I don't > > > think that's > > > > something that should be address in 4244bis. [/MB2] > > > > > > > > I hope that we can get some wider discussion on this issue > > > so a more > > > > general consensus can be obtained. > > > > > > > > Regards > > > > > > > > Ian > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > Sent: 24 June 2009 17:27 > > > > To: Ian Elz > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > > sipcore@ietf.org; Francois Audet > > > > Subject: RE: 4244bis and privacy > > > > > > > > Hi Ian, > > > > > > > > Responses inline below [MB]. > > > > > > > > Mary.=20 > > > > > > > > -----Original Message----- > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > Sent: Wednesday, June 24, 2009 10:37 AM > > > > To: Barnes, Mary (RICH2:AR00) > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > Subject: RE: 4244bis and privacy > > > > > > > > Mary, > > > > > > > > I was not proposing that we change the handling of H-I > > > which is based > > > > upon local policy. If that causes an issue for a network > > > operator then > > > > they can modify their local policy accordingly or arrange > > with the > > > > proxy vendor to modify their equipment to be more flexible with=20 > > > > regards to policy. > > > > > > > > Can you clarify for me: > > > > > > > > If you have a Privacy header with either "session" or > > "header" doe > > > > this impact the H-I entries or will only a value of > > > "history" impact > > > > the H-I entries? > > > > [MB] Yes, both "session" and "header" level privacy, > > > consistent with > > > > RFC 3323, mandate that entries be anonymized or=20 > dropped, with the=20 > > > > latter being the recommendation for "session" level > > > privacy. RFC 4244 > > > > mandated that they be dropped and 4244bis recommends they be=20 > > > > anonymized. The original intent for the value of "history" > > > was for the > > > > tagging of the individual entries, but you end up getting > > > the header > > > > level functionality as well. [/MB] > > > > > > > > If you have a Privacy header with a value of "none" and a > > H-I entry > > > > with Privacy header parameter with value "history" what is > > > the privacy > > > > of the individual H-I entry? > > > > [MB] We did not explicitly address the "none" in RFC > > 4244, but the > > > > general statement is the privacy headers at the request > > > level override > > > > any at the hi-entry level. [/MB] > > > > > > > > From reading RFC4244 a Privacy header with value "history" will=20 > > > > effectively make all H-I entries private and there is > > currently no > > > > option to include a H-I Privacy header parameter with > > value "none". > > > > [MB] Correct, per my comment above. [/MB] > > > > > > > > H-I at present allows the inclusion of Privacy header > > parameters to > > > > explicitly express privacy for an individual H-I entry > > but a single > > > > node which includes a header "Privacy: history" makes all > > > H-I entries > > > > private even if this is not the requirements for the=20 > specific URI. > > > > [MB] Correct, but the only node that should add the header > > > is a node > > > > which is responsible for the domain associated with the > > > Request URI in > > > > the incoming request or is authorized to do so. [/MB] > > > > > > > > I will admit that having worked in a telephony environment > > > for a long > > > > time I am used to having privacy of identities set on a > > per number > > > > basis and the relative inflexibility of the IETF Privacy > > header is > > > > relatively restrictive as to specifying which identities may be=20 > > > > presented and which not. > > > > [MB] Yes, this is an entirely different paradigm. I developed=20 > > > > telephony s/w for over a decade and this is entirely > > different - it > > > > provides a lot more flexibility, which makes things=20 > far, far less=20 > > > > deterministic than what you have in telephony switches=20 > where your=20 > > > > routing and translations are configured for the most part, > > > with just a > > > > few capabilities for controlling the privacy and it's a > > > closed network. > > > > > > > > With RFC4244/4244bis, there MUST be a mechanism at the=20 > UAS or end=20 > > > > application that can handle a request that doesn't have the=20 > > > > appropriate information either because nodes didn't support=20 > > > > History-Info or some random node in the network applied > > > privacy (which > > > > I think is highly > > > > unlikely) - this is normative per section 5 of RFC=20 > 4244. So, the=20 > > > > worst case scenario I see for this 800 service (which will > > > get to the > > > > right UAS but without the exact 800 number that was dialed) > > > is that it > > > > goes to a default ACD group/customer service agent,=20 > etc. who then=20 > > > > needs to gather the appropriate information and in my > > > experience this > > > > is often an IVR system these days. So, the service is not > > > broken when > > > > privacy is applied in an undesireable manner, it's just not > > > optimal. =20 > > > > This is something that should be addressed in the > > target-uri draft > > > > which has all the details of how specific services use > > History-Info. > > > > One other thing to consider is that most networks that are > > > emulating > > > > telephony type features use B2BUAs, which follow the > > > UAS/UAC rules for > > > > the header rather than the proxy rules, noting that the > > UAC can set > > > > the Privacy header to whatever value it sees as appropriate > > > for the request. > > > > [/MB] > > > > > > > > > > > > Regards > > > > > > > > Ian > > > > > > > > -----Original Message----- > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > Sent: 24 June 2009 15:48 > > > > To: Ian Elz > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > > sipcore@ietf.org; Francois Audet > > > > Subject: RE: 4244bis and privacy > > > > > > > > Hi Ian, > > > > > > > > I do not believe we should do the "override" behavior as I > > > think that > > > > violates RFC 3323, as the "history" is really a subset of > > the cases > > > > whereby a UAC or proxy would add "session" or "header" to > > > the request. > > > > And, the latter two cases have the same (undesireable) > > > result. I agree > > > > this impacts your services, but we can't mandate that > > > proxies provide > > > > information that might violate their local policies and=20 > indeed a=20 > > > > proxy's local policies can result in the information being > > > anonymized > > > > (or removed if they can't anonymize) even in the "none" case. > > > > > > > > I do believe it's reasonable that we strongly recommend=20 > that the=20 > > > > request level (versus specific hi-entries) not be used > > and if it is > > > > used, the consequence is that some services will not have the=20 > > > > information they need - this was the gist of my previous > > > response (to > > > > which I did not get any additional feedback). Now, we could > > > add some text that the "none" > > > > case SHOULD be used (e.g., added by first hop proxy) if it > > > is desired > > > > that the information not be subject to privacy > > > restrictions. I do not > > > > think it is then particularly useful to add logic around > > the proxy > > > > then being able to tag the entries within their domain as > > > subject to privacy. > > > > I think that conflicts with the intent of the request > > level "none". > > > > However, as I mention above, per the current text, a proxy > > > can (based > > > > on local policy) remove entries - so a proxy can capture > > hi within > > > > their domain and not forward any of that information to the > > > next hop > > > > in another domain - you already have that functionality. =20 > > > But, I think > > > > this introduces the general problem that you might be > > > impacting other > > > > services further down the line, which I thought was the > > problem you > > > > were wanting to solve - not specifically your example > > > service but, for > > > > example, in the case that someone is debugging and they=20 > want the=20 > > > > entire history, so depending upon the service, this is also=20 > > > > undesirable behavior. > > > > > > > > > > > > Regards, > > > > Mary.=20 > > > > > > > > -----Original Message----- > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > Sent: Wednesday, June 24, 2009 2:57 AM > > > > To: Barnes, Mary (RICH2:AR00) > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > Mary, > > > > > > > > [I have added the list to this thread for wider comment.] > > > > > > > > In the previous discussions I commented that in RFC4424 > > > that a Privacy > > > > header with value "history" effectively makes all H-I > > > entries private > > > > with the result that the H-I entries may be removed. > > > > > > > > There has now been a comprehensive discussion on > > indication of the > > > > initial 'target' to the final recipient for call handling > > purposes. > > > > > > > > The main use case related to a freephone example where the > > > answering > > > > location may be a call centre where the original freephone > > > number may > > > > be required for correct call handling. > > > > > > > > If you now consider the following example (modified from > > Francois'=20 > > > > text in the latest draft - excuse any errors that I may > > > have inserted) > > > > > > > > INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx > > > > Privacy: history > > > > History-Info: > > > >=20 > > > ;index=3D1;rt;aor = =20 > > > (1) > > > > History-Info: ;index=3D1.1;mp;aor > > > > (2) > > > > History-Info: ;index=3D1.1.1;rc > > > > (3) > > > > > > > > In this case due to the Privacy header all of the H-I=20 > entries are=20 > > > > considered private and the +18001234567 will not be > > > delivered to the > > > > final destination with the result that call handling may > > > not be correct. > > > > The Privacy header may have been inserted by any of the > > nodes which > > > > routed the message and inserted a H-I entry. > > > > > > > > If however the H-I was allowed to include a header parameter of=20 > > > > "?Privacy=3Dnone" in the H-I entry and that an explicit H-I = entry=20 > > > > privacy value would be considered to have precedence over > > a Privacy > > > > header with a value of "history" then the mapping of the > > > +18001234567 > > > > could be explicitly specified as not private and may be=20 > passed on. > > > > > > > > Thus when the mapping from sip:+18001234567@example.com to=20 > > > > sip:bob@biloxi.example.com when H-I entry (2) above is > > > included could > > > > also insert the Privacy header parameter in H-I entry (1). > > > > > > > > Thus the message would appear as follows: > > > > > > > > INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx > > > > Privacy: history > > > > History-Info: > > > >=20 > > >=20 > >=20 > = ;index=3D= 1;rt; > > > > ao > > > > r > > > > History-Info: ;index=3D1.1;mp;aor > > > > History-Info: ;index=3D1.1.1;rc > > > > > > > > This would result in all the H-I entries except (1) being > > > considered > > > > private with the result that the =3D1800... Number is > > passed for call > > > > handling purposes. > > > > > > > > This change is backward compatible with the existing > > > implementation as > > > > any node using the existing functionality as defined in > > > RFC4244 will > > > > continue to be supported. > > > > > > > > The alternative is to remove the ability to include the > > > value "history" > > > > in the Privacy header and only allow this value in the > > > Privacy header > > > > parameter. This alternative is not backward compatible. > > > > > > > > Without this change a single node in the message path which > > > includes a > > > > header "Privacy: history" will prevent delivery of the > > aor and thus > > > > prevent proper call handling. > > > > > > > > Ian Elz > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Christer Holmberg > > > > Sent: 23 June 2009 19:40 > > > > To: 'Mary Barnes'; Francois Audet; Hans Erik van Elburg; Shida=20 > > > > Schubert > > > > Cc: Ian Elz > > > > Subject: RE: 4244bis and privacy > > > > > > > > =20 > > > > Hi, > > > > > > > > I include Ian, so he can comment to your resposne himself. > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > -----Original Message----- > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > Sent: Tuesday, June 23, 2009 9:40 PM > > > > To: Christer Holmberg; Francois Audet; Hans Erik van > > Elburg; Shida > > > > Schubert > > > > Subject: RE: 4244bis and privacy > > > > > > > > Here was the thread of response and the last comment was > > > from Ian that > > > > he would consider the response: > > > > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html > > > > > > > > And, there was not agreement on the "none" but rather to > > > qualify the > > > > SHOULD NOT forward. However, in the sipcore-4244bis-00, > > > rather than > > > > changing the text such that the headers SHOULD be removed, we=20 > > > > recommend that they be anonymized (in section 4.3.3.3.1). > > That is > > > > entirely consistent with RFC 3324 and thus we have removed the=20 > > > > recommendations to remove the headers entirely. However, > > > that changed > > > > never got done in section 3.2, so we would need to change this: > > > > "Thus, the History- Info header > > > > SHOULD NOT be included in Requests where the requestor > > > has indicated > > > > a priv-value of Session- or Header-level privacy." > > > > > > > > But, I'm really beginning to be of the mindset that we > > should just > > > > remove all the subsections of section 3 (i.e., leave the > > > text in the > > > > upper level section), so we don't have to keep worrying about=20 > > > > consistency. > > > > > > > > So, lets either fixt the text in 3.2 or remove altogether > > > and then I > > > > think we are really at the point of needing to submit this > > > version so > > > > folks that actually have an interest in it can review=20 > the updated=20 > > > > document. > > > > > > > > Mary.=20 > > > > > > > > -----Original Message----- > > > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > > > > Sent: Tuesday, June 23, 2009 1:10 PM > > > > To: Barnes, Mary (RICH2:AR00); Audet, Francois > > > (SC100:3055); Hans Erik > > > > van Elburg; Shida Schubert > > > > Subject: 4244bis and privacy > > > > > > > > > > > > Hi, > > > > > > > > Below is a comment/proposal which one of my collegues (Ian > > > Elz) gave > > > > on the list a while ago, when the first version of 4244bis was=20 > > > > submitted, but was not incorporated. Do you think it would > > > be useful? > > > > > > > > ------- > > > > > > > > While the HI approach to target may solve the problem of > > > being able to > > > > deliver the target URI to the final destination there is no > > > guarantee > > > > that it will actually be delivered. > > > > > > > > The problem arises with how Privacy is defined for HI. > > > > > > > > 4424 defines a new Privacy value "history" which may be=20 > placed in=20 > > > > either the Privacy header or as a header parameter to the > > HI entry. > > > > > > > > If one node uses the former option "Privacy: history" then > > > this will > > > > make all headers private and will result in all HI=20 > entries being=20 > > > > removed or made anonymous when the message containing the HI is=20 > > > > delivered to the user. > > > > > > > > There is a simple solution to this and that is to also > > > allow the use > > > > of the "none" Privacy value as a header parameter in the > > HI entry.=20 > > > > This would explicitly state that no privacy is required=20 > to the HI=20 > > > > entry and this would override a "history" value in the > > > Privacy header. > > > > > > > > I pointed this out to Mary when the 4424bis draft was first > > > published > > > > but the change has not been made in the latest draft. > > > > > > > > The change is backward compatible and would not cause an > > issue with > > > > any existing implementations. > > > > > > > > ------ > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > sipcore mailing list > > > > sipcore@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > > > > sipcore mailing list > > > > sipcore@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > =20 > > > _______________________________________________ > > > 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 > >=20 >=20 From vkg@alcatel-lucent.com Mon Jun 29 23:09:12 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA2A3A69FA for ; Mon, 29 Jun 2009 23:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ery5dqswn9U for ; Mon, 29 Jun 2009 23:09:11 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 085C93A67B3 for ; Mon, 29 Jun 2009 23:08:45 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id n5U6965L024486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Jun 2009 01:09:06 -0500 (CDT) Received: from shoonya.ih.lucent.com (guard.research.bell-labs.com [135.104.2.9]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n5U694gW001357 for ; Tue, 30 Jun 2009 01:09:05 -0500 (CDT) Message-ID: <4A49AC25.7010602@alcatel-lucent.com> Date: Tue, 30 Jun 2009 01:09:41 -0500 From: Vijay Gurbani User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: sipcore@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [sipcore] I-D on TCP/SCTP connection reuse X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 06:09:12 -0000 Folks: When we had moved connect-reuse ahead for IESG review, we had decided to take out the parts dealing with reusing TCP and SCTP connections. The plan was to have a new I-D that documents how to use TCP and SCTP connection reuse. A draft along those lines is now available; please see http://tools.ietf.org/html/draft-jain-sip-transport-layer-connection-reuse-00. Any comments on it will be most helpful. At this point, we are not sure where to target it -- sipcore is probably the closest. But for now, if you can focus on the contents of the draft, that'll be most helpful. Thank you. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://ect.bell-labs.com/who/vkg From john.elwell@siemens-enterprise.com Tue Jun 30 00:30:20 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6BD3A6E0A for ; Tue, 30 Jun 2009 00:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV-ia9jn-m+p for ; Tue, 30 Jun 2009 00:30:17 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 6F5BA3A6DFD for ; Tue, 30 Jun 2009 00:30:16 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KM100508JID7W@siemenscomms.co.uk> for sipcore@ietf.org; Tue, 30 Jun 2009 08:30:13 +0100 (BST) Date: Tue, 30 Jun 2009 08:30:11 +0100 From: "Elwell, John" In-reply-to: <1ECE0EB50388174790F9694F77522CCF1EBE2181@zrc2hxm0.corp.nortel.com> To: Francois Audet , Ian Elz , Mary Barnes , R.Jesske@telekom.de, ietf.hanserik@gmail.com Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00213B56F@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] 4244bis and privacy Thread-Index: Acn11AWR+Z7be2FAQvKtnWIFO4vfcAAB1KHQAABgLvAAFKai8AAAYdKwABEiZHAAitux8AAa+YTgABHtvHA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4048F809B@S4DE8PSAAQB.mitte.t-com.de> <4A43DEC9.1020802@gmail.com> <9886E5FCA6D76549A3011068483A4BD4048F80AC@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1EB26AB5@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D00213AA4C@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1EB6BD69@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EBE2181@zrc2hxm0.corp.nortel.com> Cc: sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 07:30:20 -0000 Yes, I think something like this makes sense. John=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: 30 June 2009 00:06 > To: Ian Elz; Elwell, John; Mary Barnes; R.Jesske@telekom.de;=20 > ietf.hanserik@gmail.com > Cc: sipcore@ietf.org; shida@agnada.com > Subject: RE: [sipcore] 4244bis and privacy >=20 > I think the current "interpretation" is not terribly useful. I prefer > your suggestion. The current RFC 4244 text is not very clear. >=20 > It seems to me that: > - Privacy should associated with a specific hi-entry (and perhaps any > entry that corresponds to that same user), and not the=20 > header itself. > - That way, it is possible that specific entries be anonymize, but not > others. For example, if you call me without privacy, and I=20 > call forward > you to John with privacy setup for myself, John should see=20 > an entry for > you and an anonymized entry for me. > - There is no reason why "none" couldn't be used in this=20 > context. Again,=20 > with the same example as above, John could requies "none"=20 > for him, and > I could set privacy on for myself. >=20 > I don't think this type of rule for 4244bis would require any change > whatsoever to RFC 3323. It would be completely self-contained in > 4244bis. >=20 > Comments? >=20 > > -----Original Message----- > > From: Ian Elz [mailto:ian.elz@ericsson.com]=20 > > Sent: Monday, June 29, 2009 03:26 > > To: Audet, Francois (SC100:3055); Elwell, John; Barnes, Mary=20 > > (RICH2:AR00); R.Jesske@telekom.de; ietf.hanserik@gmail.com > > Cc: sipcore@ietf.org; shida@agnada.com > > Subject: RE: [sipcore] 4244bis and privacy > >=20 > > Francios, > >=20 > > I agree that 4244bis should not specify the actions of=20 > > proxies etc where this is a matter of local policy. > >=20 > > My original proposed change was to allow the inclusion of the=20 > > value "none" in the alongside the value "history" to be=20 > > included in the Privacy header parameter escaped in the=20 > > hi-targeted-to-uri. (RFC4244 section 4.1) > >=20 > > It appears however that the current interpretation of the=20 > > Privacy header means that the value included in the Privacy=20 > > header, which is applicable to the originating rather than=20 > > retargeting user is applied to the retargeting user rather=20 > > than the explicit value included for the retargeting user.=20 > > The escaped privacy value is only used if there is no Privacy=20 > > header or the Privacy header only contains the value "user". > >=20 > > The end result of this interpretation is that including an=20 > > explicit value "none" escaped as a Privacy parameter would=20 > > have no effect and would have the same meaning as not=20 > > including a Privacy header parameter escaped in the=20 > > hi-targeted-to-uri. > >=20 > > 4244bis is not the place to extend the sip Privacy handling=20 > > to specify how 3rd party identities in sip messages should=20 > > have their own specific privacy maintained. > >=20 > > Allowing the inclusion of the explicitly Privacy=3Dnone value=20 > > in the hi-targeted-to-uri would not change any handling at=20 > > this time but would make the new H-I RFC suitable for use if=20 > > an updated privacy RFC is proposed which does have specific=20 > > support for 3rd party identities. > >=20 > > H-I is not the only place where the explicit privacy of 3rd=20 > > party identities is required. The Referred-By header is one=20 > > other case where a similar explicit privacy may need to be=20 > > considered in the future. > >=20 > > regards > >=20 > > Ian > >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: 26 June 2009 16:55 > > To: Ian Elz; Elwell, John; Mary Barnes; R.Jesske@telekom.de;=20 > > ietf.hanserik@gmail.com > > Cc: sipcore@ietf.org; shida@agnada.com > > Subject: RE: [sipcore] 4244bis and privacy > >=20 > > I do see things that we should fix right-away in=20 > > History-Info, regarding privacy. > >=20 > > I also think that History-Info shouldn't "overstrech" and get=20 > > too deep into the nitty gritty of privacy. What should be in=20 > > HI is high level guidance. > >=20 > > In section 3.1, for example, it says that Privacy header will=20 > > determine if a History-Info *header field* can be included by=20 > > an intermediary. This does not make any sense. What it should=20 > > say is that the Privacy header will determine if a=20 > > history-info *entry* can be added for the UA inserting the=20 > > Privacy header. > >=20 > > So, in my opinion, we can go ahead and fix that right now. > >=20 > > I don't think we need to get into super low-level procedural=20 > > descriptions of the type "proxy MUST this and that if Privacy=20 > > =3D=3D this and that". I believe privacy matters are policy-level=20 > > decisions that service providers and enteprises will have,=20 > > and they are not going to be implemented by simplistic=20 > > procedural rules from an RFC. > >=20 > > Comments? > > =20 > >=20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Ian Elz > > > Sent: Friday, June 26, 2009 01:08 > > > To: Elwell, John; Barnes, Mary (RICH2:AR00); R.Jesske@telekom.de;=20 > > > ietf.hanserik@gmail.com > > > Cc: sipcore@ietf.org; shida@agnada.com > > > Subject: Re: [sipcore] 4244bis and privacy > > >=20 > > > John, > > >=20 > > > Your statement " not anonymise or remove any information=20 > > that the UAC=20 > > > has already placed in the request " is the key here. > > >=20 > > > The UAC has not included the H-I entry, particularly the one=20 > > > containing the identity of the diverting party. > > >=20 > > > This was not considered in RFC3323 and we have an issue where we=20 > > > cannot determine which entity included which information. > > > This creates a problem where a restriction by the=20 > originating party=20 > > > will prevent a downstream identity from permitting=20 > presentation of=20 > > > their identity. > > >=20 > > > I agree with Mary that this probably requires an update to > > > RFC3323 so we should start by updating RFC3323 and then=20 > > move on to the=20 > > > other impacted RFCs. The issue that this will raise for=20 > H-I is that=20 > > > there will be another change required after the Privacy RFC=20 > > has been=20 > > > agreed. > > >=20 > > > This is far from ideal but the 4424bis draft contains a lot=20 > > more than=20 > > > just this issue. > > >=20 > > > Ian > > >=20 > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: 26 June 2009 08:30 > > > To: Mary Barnes; R.Jesske@telekom.de; ietf.hanserik@gmail.com > > > Cc: Ian Elz; sipcore@ietf.org; shida@agnada.com > > > Subject: RE: [sipcore] 4244bis and privacy > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > > > > Sent: 25 June 2009 22:45 > > > > To: R.Jesske@telekom.de; ietf.hanserik@gmail.com > > > > Cc: ian.elz@ericsson.com; sipcore@ietf.org; shida@agnada.com > > > > Subject: Re: [sipcore] 4244bis and privacy > > > >=20 > > > > Roland, > > > >=20 > > > > The reason you can't have "none" at the request level and > > > "history" at > > > > the entry level is because RFC 3323 states that you MUST=20 > > NOT apply=20 > > > > privacy to the message. Even if you put "history" in the > > > entries, the > > > > privacy service would just ignore that - per RFC 3323. =20 > > So, if you=20 > > > > want to change that behavior, then RFC 3323 should be > > > changed - i.e., > > > > the MUST NOT for the "none" could be changed to a SHOULD > > > NOT and then > > > > a general statement about possible exceptions. Then, we=20 > could add=20 > > > > something to RFC 4244 for this case. But, changing RFC > > > > 3323 is totally out of scope for what we are currently=20 > > working on. =20 > > > [JRE] I would interpret privacy 'none' in RFC 3323 as=20 > > meaning that a=20 > > > downstream entity must not anonymise or remove any=20 > information that=20 > > > the UAC has already placed in the request. > > > If a downstream entity chooses: > > > - not to add H-I, > > > - to add anonymised H-I, or > > > - to anonymise an H-I entry that some intermediate entity=20 > > has added, I=20 > > > don't see that as being in violation of what the UAC has=20 > requested. > > >=20 > > > John > > >=20 > > >=20 > > > >=20 > > > > That all said, I would sure think that if you are leaving a > > > "trusted > > > > network" that you have a B2BUA in there, as I've said in other=20 > > > > threads. Thus, the B2BUA builds a new request and certainly > > > can add a > > > > privacy header that it believes is appropriate since=20 > the outgoing=20 > > > > request is done by the UAC function of a B2BUA. > > > >=20 > > > > Mary.=20 > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > > > > Sent: Thursday, June 25, 2009 4:32 PM > > > > To: ietf.hanserik@gmail.com > > > > Cc: Barnes, Mary (RICH2:AR00); ian.elz@ericsson.com; > > > sipcore@ietf.org; > > > > shida@agnada.com > > > > Subject: AW: [sipcore] 4244bis and privacy > > > >=20 > > > > Hi Hans Erik, > > > > We have also to take regulatory into consideration. In=20 > > Germany the=20 > > > > last trusted network is responsible for anonymising information. > > > >=20 > > > > But nevertheless if Network provider A wants to have History=20 > > > > completely private this operator will set privacy=20 > history for the=20 > > > > header. > > > > If the succeeding Operator want to present elements the AS > > > which adds > > > > a entry has then to re label all entries from the=20 > > preceding network=20 > > > > and the entries from it's own network will be unmarked=20 > within the=20 > > > > Header. > > > >=20 > > > > But never the less I fully agree to your last sentence. > > > >=20 > > > > The real Question is if this should really be allowed=20 > > that a entry=20 > > > > marked with "none" overrules the privacy statement > > > "history" for the > > > > complete header. > > > >=20 > > > > I'm against this behaviour.=20 > > > >=20 > > > > Best Regards > > > >=20 > > > > Roland > > > >=20 > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > > > Gesendet: Donnerstag, 25. Juni 2009 22:32 > > > > An: Jesske, Roland > > > > Cc: mary.barnes@nortel.com; ian.elz@ericsson.com;=20 > > sipcore@ietf.org;=20 > > > > shida@agnada.com > > > > Betreff: Re: [sipcore] 4244bis and privacy > > > >=20 > > > > Hi Roland, > > > >=20 > > > > I don't understand the argument, by the time that the=20 > > History-Info=20 > > > > leaves operator A that wishes complete privacy, all the > > > History-Info > > > > headers should be anonymised according to 4244 and 4244bis. > > > >=20 > > > > What is the point in mandating that operator A to force > > > operator B to > > > > also anonymise the entries "owned" by operator B. > > > >=20 > > > > It is of course without question that each operator has > > > full privacy > > > > control over its own added entries. And each operator can=20 > > based on=20 > > > > local policy decide to remove the entire history if it > > > things that is > > > > wise to do. > > > >=20 > > > > /Hans Erik > > > >=20 > > > >=20 > > > > R.Jesske@telekom.de wrote: > > > > > Hi Marry and Ian, > > > > > The whole discussion puzzle me. We have specified CDIV > > > > within TISPAN and 3GPP.=20 > > > > > There is described that privacy "none" can be used for > > > > entries. BUT assuming that each entry has its own privacy > > > statement if > > > > needed. > > > > > I fully agree on Mary's comment that a privacy "history"=20 > > > > cannot overruled by a privacy value "none" within a entry.=20 > > > > > There may be operators that would like to keep the whole > > > > History Info private even if entries has other=20 > statements, so the=20 > > > > entity could add privacy history to the whole header. > > > > Nothing more. > > > > > > > > > > On the other side a Application Server including a entry > > > > should have the possibility to rewrite the entries so that > > > instead of > > > > "history" for the whole header the all received entries=20 > > within the=20 > > > > History-Info header will be marked with "history" and the > > > added header > > > > (which shall be presented to the terminating user) will=20 > either be=20 > > > > marked with "none" or will not be marked. > > > > > > > > > > Perhaps a hint could be given, but I do not insist on it. > > > > > > > > > > Best Regards, > > > > > > > > > > Roland > > > > > > > > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > Von: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] Im > > > > > Auftrag von Mary Barnes > > > > > Gesendet: Donnerstag, 25. Juni 2009 18:29 > > > > > An: Ian Elz > > > > > Cc: sipcore@ietf.org; Shida Schubert > > > > > Betreff: Re: [sipcore] 4244bis and privacy > > > > > > > > > > Hi Ian, > > > > > > > > > > Responses inline below [MB2]. > > > > > > > > > > Mary. > > > > > > > > > > -----Original Message----- > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > > Sent: Thursday, June 25, 2009 10:13 AM > > > > > To: Barnes, Mary (RICH2:AR00) > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > Mary, > > > > > > > > > > I am a little concerned about one answer that you gave: > > > > > > > > > > > > > > > If you have a Privacy header with a value of "none" and a > > > H-I entry > > > > > with Privacy header parameter with value "history" what is > > > > the privacy > > > > > of the individual H-I entry? > > > > > [MB] We did not explicitly address the "none" in RFC > > > 4244, but the > > > > > general statement is the privacy headers at the request > > > > level override > > > > > any at the hi-entry level. [/MB] > > > > > =20 > > > > > This means that if privacy is required for an individual > > > > H-I entry but > > > > > the originating user included "Privacy:none" in the request > > > > then there > > > > > is no option to include the real URI in the H-I entry. > > > > > [MB2] I'm confused here - the "none" definition is as you > > > > note below, > > > > > thus "none" prohibits the removal or anonymization of the > > > entries, > > > > > thus I would think you would fine this functionality=20 > desireable. > > > > > However, this does not prohibit an entity based on policy > > > > to anonymize > > > > > (or remove entries if privacy is required for that=20 > > domain if the=20 > > > > > entity does not have access to a privacy service). [/MB2] > > > > > > > > > > This occurs as RFC3323 states in section 4.3: "However, if > > > > the Privacy > > > > > header value of 'none' is specified in a message, privacy > > > services > > > > > MUST NOT perform any privacy function and MUST NOT remove > > > or modify > > > > > the Privacy header." > > > > > > > > > > The only option for an intermediate node including a H-I > > > > entry where > > > > > "Privacy:none" is specified and privacy for the H-I URI is > > > > required is > > > > > to include an anonymous entry or not include the H-I entry. > > > > > [MB2] If privacy is required then yes, you include > > > > anonymous entries > > > > > or don't include. That's the basic privacy mechanism=20 > > for privacy=20 > > > > > levels of "session" "header" and "history" in the R-URI or > > > > "history"=20 > > > > > in the specific entries, as well as when there is a policy > > > > for privacy > > > > > for the entries added by a specific domain. The "none"=20 > > > > really has no > > > > > influence on the later case per se. [/MB2] > > > > > > > > > > In your previous response you stated that we would violate > > > > RFC3323 if > > > > > we specified additional behaviour for privacy explicitly > > > > stated with a > > > > > URI -n the H-I entry. I don't believe that this is the case > > > > as RFC3323 > > > > > only considered privacy in a two party scenario and did not > > > > consider > > > > > third party identities being included in a message=20 > between two=20 > > > > > parties. H-I is not the only case where this occurs as the > > > > Referred-By > > > > > header when included in the INVITE (or other request) > > > which results > > > > > from the REFER has the same issue. > > > > > [MB2] I can't necessarily disagree on this one (we can=20 > > debate it=20 > > > > > either way). But to fix it requires an update to RFC 3323 and=20 > > > > > shouldn't be something that we want to fix in 4244bis. [/MB2] > > > > > > > > > > RFC4244 was the first time that there was a recognition > > > > that privacy > > > > > for these individual third party identities may be > > > > required. To allow > > > > > this explicit statement of privacy to be overridden by=20 > > a generic=20 > > > > > statement which is applicable to a different user is > > > > counterintuitive. > > > > > [MB2] See my comment above. But, as I have consistently > > > > said, the idea > > > > > that an entity might want to override the "none" is > > > > entirely based on > > > > > policy and 4244 and 4244bis allow privacy to be applied to > > > > the entries > > > > > that are added by that entity if the policy dictates=20 > so (and we=20 > > > > > already say that). [/MB2] > > > > > > > > > > The original Privacy header is usually included by or on > > > > behalf of the > > > > > originating user and should not be allowed to specify the > > > > privacy of > > > > > the original called user, e.g. the 800 number, and=20 > prevent this=20 > > > > > identity being presented if this user does not have the > > > > same level of privacy. > > > > > [MB2] As I tried to say in a previous response, a random > > > > entity (i.e., > > > > > one for whom the R-URI is not in a domain under its > > > control) cannot > > > > > add a privacy header to the Request. Per RFC 3323 an > > > entity may add > > > > > the header to a request only if it has the appropriate=20 > > > > > relationship/authorization with the original called user > > > > who intiated > > > > > the request. And, I would find it very surprising if an > > > entity that > > > > > did have responsibility would apply privacy since=20 > that would be=20 > > > > > counter intuitive and I would hope that SPs would be=20 > > judicious in=20 > > > > > specifying the appropriate and inappropriate manner in=20 > > which the=20 > > > > > proxies they deploy and interface with privatize the > > > messages. The > > > > > protocol CANNOT control this behavior and that's why=20 > > there is the=20 > > > > > policy clause in 4244 and 4244bis. [/MB2] > > > > > > > > > > The real issue with the 800 scenario is as you have stated > > > > is that the > > > > > answerer will not know the original called identity and > > > will not be > > > > > able to correctly handle the call. As more generic call > > > centres are > > > > > used which will answer calls on behalf of many different > > > > organizations > > > > > using CTI and the original called identity to have to=20 > > implement a=20 > > > > > generic system asking the caller who he originally=20 > > called appear=20 > > > > > unprofessional, is inefficient and unproductive. > > > > > [MB2] And, as I noted, it is rare for a call centre to > > > route a call > > > > > directly to an agent without a user providing some sort of > > > > input. Even > > > > > companies like American Airlines, even though they have the > > > > info that > > > > > I enter via the IVR, they still ask some basic questions > > > > and there are > > > > > times when they have to reroute me. I don't think we=20 > > can totally=20 > > > > > automate things. And, again, once the call hits the > > > domain that is > > > > > responsible for that 800 number the entities in that=20 > > domain have=20 > > > > > control over how they muck with the R-URI, such that they > > > should be > > > > > able to use any IVR info to appropriately direct the call - > > > > it's not > > > > > the number that's meaningful, but how the system gets the > > > > call to the > > > > > right user and the additional information they provide as > > > > the call is > > > > > presented to the agent. I would honestly think that having > > > > something > > > > > other than an 800 number show up on the display would=20 > > be far more=20 > > > > > useful and in my experience in the systems I developed > > > > we're usually > > > > > talking about CTI interfaces so you have a lot you can=20 > > do. And,=20 > > > > > actually all of this really doesn't matter in that you MUST > > > > be able to > > > > > handle this situation independent of the privacy since > > > > History-Info is > > > > > optional, you need default behavior assigned. [/MB2] > > > > > > > > > > We have an opportunity to allow presentation of specific > > > identities > > > > > and to solve this particular problem so we should take it. > > > > > [MB2] The most we can do is to document the risks/impacts > > > > of the use > > > > > of the Privacy headers at the R-URI level. There is > > > already general > > > > > text in > > > > > 4244 and 4244bis that the privacy may impact whether the > > > > applications > > > > > get the information. And, as I noted before, most > > > > commercial systems > > > > > are using B2BUAs which will allow you far more control over > > > > the use of > > > > > the Privacy headers in the network. But, again, I don't > > > > think that's > > > > > something that should be address in 4244bis. [/MB2] > > > > > > > > > > I hope that we can get some wider discussion on this issue > > > > so a more > > > > > general consensus can be obtained. > > > > > > > > > > Regards > > > > > > > > > > Ian > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > > Sent: 24 June 2009 17:27 > > > > > To: Ian Elz > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > > > sipcore@ietf.org; Francois Audet > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > Hi Ian, > > > > > > > > > > Responses inline below [MB]. > > > > > > > > > > Mary.=20 > > > > > > > > > > -----Original Message----- > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > > Sent: Wednesday, June 24, 2009 10:37 AM > > > > > To: Barnes, Mary (RICH2:AR00) > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > Mary, > > > > > > > > > > I was not proposing that we change the handling of H-I > > > > which is based > > > > > upon local policy. If that causes an issue for a network > > > > operator then > > > > > they can modify their local policy accordingly or arrange > > > with the > > > > > proxy vendor to modify their equipment to be more=20 > flexible with=20 > > > > > regards to policy. > > > > > > > > > > Can you clarify for me: > > > > > > > > > > If you have a Privacy header with either "session" or > > > "header" doe > > > > > this impact the H-I entries or will only a value of > > > > "history" impact > > > > > the H-I entries? > > > > > [MB] Yes, both "session" and "header" level privacy, > > > > consistent with > > > > > RFC 3323, mandate that entries be anonymized or=20 > > dropped, with the=20 > > > > > latter being the recommendation for "session" level > > > > privacy. RFC 4244 > > > > > mandated that they be dropped and 4244bis recommends they be=20 > > > > > anonymized. The original intent for the value of "history" > > > > was for the > > > > > tagging of the individual entries, but you end up getting > > > > the header > > > > > level functionality as well. [/MB] > > > > > > > > > > If you have a Privacy header with a value of "none" and a > > > H-I entry > > > > > with Privacy header parameter with value "history" what is > > > > the privacy > > > > > of the individual H-I entry? > > > > > [MB] We did not explicitly address the "none" in RFC > > > 4244, but the > > > > > general statement is the privacy headers at the request > > > > level override > > > > > any at the hi-entry level. [/MB] > > > > > > > > > > From reading RFC4244 a Privacy header with value=20 > "history" will=20 > > > > > effectively make all H-I entries private and there is > > > currently no > > > > > option to include a H-I Privacy header parameter with > > > value "none". > > > > > [MB] Correct, per my comment above. [/MB] > > > > > > > > > > H-I at present allows the inclusion of Privacy header > > > parameters to > > > > > explicitly express privacy for an individual H-I entry > > > but a single > > > > > node which includes a header "Privacy: history" makes all > > > > H-I entries > > > > > private even if this is not the requirements for the=20 > > specific URI. > > > > > [MB] Correct, but the only node that should add the header > > > > is a node > > > > > which is responsible for the domain associated with the > > > > Request URI in > > > > > the incoming request or is authorized to do so. [/MB] > > > > > > > > > > I will admit that having worked in a telephony environment > > > > for a long > > > > > time I am used to having privacy of identities set on a > > > per number > > > > > basis and the relative inflexibility of the IETF Privacy > > > header is > > > > > relatively restrictive as to specifying which=20 > identities may be=20 > > > > > presented and which not. > > > > > [MB] Yes, this is an entirely different paradigm. I=20 > developed=20 > > > > > telephony s/w for over a decade and this is entirely > > > different - it > > > > > provides a lot more flexibility, which makes things=20 > > far, far less=20 > > > > > deterministic than what you have in telephony switches=20 > > where your=20 > > > > > routing and translations are configured for the most part, > > > > with just a > > > > > few capabilities for controlling the privacy and it's a > > > > closed network. > > > > > > > > > > With RFC4244/4244bis, there MUST be a mechanism at the=20 > > UAS or end=20 > > > > > application that can handle a request that doesn't have the=20 > > > > > appropriate information either because nodes didn't support=20 > > > > > History-Info or some random node in the network applied > > > > privacy (which > > > > > I think is highly > > > > > unlikely) - this is normative per section 5 of RFC=20 > > 4244. So, the=20 > > > > > worst case scenario I see for this 800 service (which will > > > > get to the > > > > > right UAS but without the exact 800 number that was dialed) > > > > is that it > > > > > goes to a default ACD group/customer service agent,=20 > > etc. who then=20 > > > > > needs to gather the appropriate information and in my > > > > experience this > > > > > is often an IVR system these days. So, the service is not > > > > broken when > > > > > privacy is applied in an undesireable manner, it's just not > > > > optimal. =20 > > > > > This is something that should be addressed in the > > > target-uri draft > > > > > which has all the details of how specific services use > > > History-Info. > > > > > One other thing to consider is that most networks that are > > > > emulating > > > > > telephony type features use B2BUAs, which follow the > > > > UAS/UAC rules for > > > > > the header rather than the proxy rules, noting that the > > > UAC can set > > > > > the Privacy header to whatever value it sees as appropriate > > > > for the request. > > > > > [/MB] > > > > > > > > > > > > > > > Regards > > > > > > > > > > Ian > > > > > > > > > > -----Original Message----- > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > > Sent: 24 June 2009 15:48 > > > > > To: Ian Elz > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > > > sipcore@ietf.org; Francois Audet > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > Hi Ian, > > > > > > > > > > I do not believe we should do the "override" behavior as I > > > > think that > > > > > violates RFC 3323, as the "history" is really a subset of > > > the cases > > > > > whereby a UAC or proxy would add "session" or "header" to > > > > the request. > > > > > And, the latter two cases have the same (undesireable) > > > > result. I agree > > > > > this impacts your services, but we can't mandate that > > > > proxies provide > > > > > information that might violate their local policies and=20 > > indeed a=20 > > > > > proxy's local policies can result in the information being > > > > anonymized > > > > > (or removed if they can't anonymize) even in the "none" case. > > > > > > > > > > I do believe it's reasonable that we strongly recommend=20 > > that the=20 > > > > > request level (versus specific hi-entries) not be used > > > and if it is > > > > > used, the consequence is that some services will not have the=20 > > > > > information they need - this was the gist of my previous > > > > response (to > > > > > which I did not get any additional feedback). Now, we could > > > > add some text that the "none" > > > > > case SHOULD be used (e.g., added by first hop proxy) if it > > > > is desired > > > > > that the information not be subject to privacy > > > > restrictions. I do not > > > > > think it is then particularly useful to add logic around > > > the proxy > > > > > then being able to tag the entries within their domain as > > > > subject to privacy. > > > > > I think that conflicts with the intent of the request > > > level "none". > > > > > However, as I mention above, per the current text, a proxy > > > > can (based > > > > > on local policy) remove entries - so a proxy can capture > > > hi within > > > > > their domain and not forward any of that information to the > > > > next hop > > > > > in another domain - you already have that functionality. =20 > > > > But, I think > > > > > this introduces the general problem that you might be > > > > impacting other > > > > > services further down the line, which I thought was the > > > problem you > > > > > were wanting to solve - not specifically your example > > > > service but, for > > > > > example, in the case that someone is debugging and they=20 > > want the=20 > > > > > entire history, so depending upon the service, this is also=20 > > > > > undesirable behavior. > > > > > > > > > > > > > > > Regards, > > > > > Mary.=20 > > > > > > > > > > -----Original Message----- > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > > Sent: Wednesday, June 24, 2009 2:57 AM > > > > > To: Barnes, Mary (RICH2:AR00) > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida Schubert;=20 > > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > > > > Mary, > > > > > > > > > > [I have added the list to this thread for wider comment.] > > > > > > > > > > In the previous discussions I commented that in RFC4424 > > > > that a Privacy > > > > > header with value "history" effectively makes all H-I > > > > entries private > > > > > with the result that the H-I entries may be removed. > > > > > > > > > > There has now been a comprehensive discussion on > > > indication of the > > > > > initial 'target' to the final recipient for call handling > > > purposes. > > > > > > > > > > The main use case related to a freephone example where the > > > > answering > > > > > location may be a call centre where the original freephone > > > > number may > > > > > be required for correct call handling. > > > > > > > > > > If you now consider the following example (modified from > > > Francois'=20 > > > > > text in the latest draft - excuse any errors that I may > > > > have inserted) > > > > > > > > > > INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx > > > > > Privacy: history > > > > > History-Info: > > > > >=20 > > > > = ;index=3D1;rt;aor =20 > > > > (1) > > > > > History-Info: ;index=3D1.1;mp;aor > > > > > (2) > > > > > History-Info: ;index=3D1.1.1;rc > > > > > (3) > > > > > > > > > > In this case due to the Privacy header all of the H-I=20 > > entries are=20 > > > > > considered private and the +18001234567 will not be > > > > delivered to the > > > > > final destination with the result that call handling may > > > > not be correct. > > > > > The Privacy header may have been inserted by any of the > > > nodes which > > > > > routed the message and inserted a H-I entry. > > > > > > > > > > If however the H-I was allowed to include a header=20 > parameter of=20 > > > > > "?Privacy=3Dnone" in the H-I entry and that an explicit=20 > H-I entry=20 > > > > > privacy value would be considered to have precedence over > > > a Privacy > > > > > header with a value of "history" then the mapping of the > > > > +18001234567 > > > > > could be explicitly specified as not private and may be=20 > > passed on. > > > > > > > > > > Thus when the mapping from sip:+18001234567@example.com to=20 > > > > > sip:bob@biloxi.example.com when H-I entry (2) above is > > > > included could > > > > > also insert the Privacy header parameter in H-I entry (1). > > > > > > > > > > Thus the message would appear as follows: > > > > > > > > > > INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx > > > > > Privacy: history > > > > > History-Info: > > > > >=20 > > > >=20 > > >=20 > >=20 > = ;index=3D= 1;rt; > > > > > ao > > > > > r > > > > > History-Info: ;index=3D1.1;mp;aor > > > > > History-Info: ;index=3D1.1.1;rc > > > > > > > > > > This would result in all the H-I entries except (1) being > > > > considered > > > > > private with the result that the =3D1800... Number is > > > passed for call > > > > > handling purposes. > > > > > > > > > > This change is backward compatible with the existing > > > > implementation as > > > > > any node using the existing functionality as defined in > > > > RFC4244 will > > > > > continue to be supported. > > > > > > > > > > The alternative is to remove the ability to include the > > > > value "history" > > > > > in the Privacy header and only allow this value in the > > > > Privacy header > > > > > parameter. This alternative is not backward compatible. > > > > > > > > > > Without this change a single node in the message path which > > > > includes a > > > > > header "Privacy: history" will prevent delivery of the > > > aor and thus > > > > > prevent proper call handling. > > > > > > > > > > Ian Elz > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg > > > > > Sent: 23 June 2009 19:40 > > > > > To: 'Mary Barnes'; Francois Audet; Hans Erik van=20 > Elburg; Shida=20 > > > > > Schubert > > > > > Cc: Ian Elz > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > =20 > > > > > Hi, > > > > > > > > > > I include Ian, so he can comment to your resposne himself. > > > > > > > > > > Regards, > > > > > > > > > > Christer > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > > Sent: Tuesday, June 23, 2009 9:40 PM > > > > > To: Christer Holmberg; Francois Audet; Hans Erik van > > > Elburg; Shida > > > > > Schubert > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > Here was the thread of response and the last comment was > > > > from Ian that > > > > > he would consider the response: > > > > > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html > > > > > > > > > > And, there was not agreement on the "none" but rather to > > > > qualify the > > > > > SHOULD NOT forward. However, in the sipcore-4244bis-00, > > > > rather than > > > > > changing the text such that the headers SHOULD be removed, we=20 > > > > > recommend that they be anonymized (in section 4.3.3.3.1). > > > That is > > > > > entirely consistent with RFC 3324 and thus we have=20 > removed the=20 > > > > > recommendations to remove the headers entirely. However, > > > > that changed > > > > > never got done in section 3.2, so we would need to=20 > change this: > > > > > "Thus, the History- Info header > > > > > SHOULD NOT be included in Requests where the requestor > > > > has indicated > > > > > a priv-value of Session- or Header-level privacy." > > > > > > > > > > But, I'm really beginning to be of the mindset that we > > > should just > > > > > remove all the subsections of section 3 (i.e., leave the > > > > text in the > > > > > upper level section), so we don't have to keep worrying about=20 > > > > > consistency. > > > > > > > > > > So, lets either fixt the text in 3.2 or remove altogether > > > > and then I > > > > > think we are really at the point of needing to submit this > > > > version so > > > > > folks that actually have an interest in it can review=20 > > the updated=20 > > > > > document. > > > > > > > > > > Mary.=20 > > > > > > > > > > -----Original Message----- > > > > > From: Christer Holmberg=20 > [mailto:christer.holmberg@ericsson.com] > > > > > Sent: Tuesday, June 23, 2009 1:10 PM > > > > > To: Barnes, Mary (RICH2:AR00); Audet, Francois > > > > (SC100:3055); Hans Erik > > > > > van Elburg; Shida Schubert > > > > > Subject: 4244bis and privacy > > > > > > > > > > > > > > > Hi, > > > > > > > > > > Below is a comment/proposal which one of my collegues (Ian > > > > Elz) gave > > > > > on the list a while ago, when the first version of=20 > 4244bis was=20 > > > > > submitted, but was not incorporated. Do you think it would > > > > be useful? > > > > > > > > > > ------- > > > > > > > > > > While the HI approach to target may solve the problem of > > > > being able to > > > > > deliver the target URI to the final destination there is no > > > > guarantee > > > > > that it will actually be delivered. > > > > > > > > > > The problem arises with how Privacy is defined for HI. > > > > > > > > > > 4424 defines a new Privacy value "history" which may be=20 > > placed in=20 > > > > > either the Privacy header or as a header parameter to the > > > HI entry. > > > > > > > > > > If one node uses the former option "Privacy: history" then > > > > this will > > > > > make all headers private and will result in all HI=20 > > entries being=20 > > > > > removed or made anonymous when the message containing=20 > the HI is=20 > > > > > delivered to the user. > > > > > > > > > > There is a simple solution to this and that is to also > > > > allow the use > > > > > of the "none" Privacy value as a header parameter in the > > > HI entry.=20 > > > > > This would explicitly state that no privacy is required=20 > > to the HI=20 > > > > > entry and this would override a "history" value in the > > > > Privacy header. > > > > > > > > > > I pointed this out to Mary when the 4424bis draft was first > > > > published > > > > > but the change has not been made in the latest draft. > > > > > > > > > > The change is backward compatible and would not cause an > > > issue with > > > > > any existing implementations. > > > > > > > > > > ------ > > > > > > > > > > Regards, > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > sipcore mailing list > > > > > sipcore@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > _______________________________________________ > > > > > sipcore mailing list > > > > > sipcore@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > =20 > > > > _______________________________________________ > > > > 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 > > >=20 > >=20 >=20 From AUDET@nortel.com Tue Jun 30 10:40:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 762163A63CB for ; Tue, 30 Jun 2009 10:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.069 X-Spam-Level: X-Spam-Status: No, score=-6.069 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mpKiNquAFXQ for ; Tue, 30 Jun 2009 10:40:06 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id ADCAB28C387 for ; Tue, 30 Jun 2009 10:40:05 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5UHbDD10641; Tue, 30 Jun 2009 17:37:14 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Jun 2009 12:38:26 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EC32E75@zrc2hxm0.corp.nortel.com> In-Reply-To: A<0D5F89FAC29E2C41B98A6A762007F5D00213B56F@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] 4244bis and privacy thread-index: Acn11AWR+Z7be2FAQvKtnWIFO4vfcAAB1KHQAABgLvAAFKai8AAAYdKwABEiZHAAitux8AAa+YTgABHtvHAAFTS98A== References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4048F809B@S4DE8PSAAQB.mitte.t-com.de> <4A43DEC9.1020802@gmail.com> <9886E5FCA6D76549A3011068483A4BD4048F80AC@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1EB26AB5@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D00213AA4C@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522C! CF1EB6BD6 9@zrc2hxm0.c orp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EBE2181@zrc2hxm0.corp.nortel.com> A<0D5F89FAC29E2C41B98A6A762007F5D00213B56F@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , "Ian Elz" , "Mary Barnes" , , Cc: sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] 4244bis and privacy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 17:40:09 -0000 Ok, I'll go ahead and write something up along those lines in the = draft). I will avoid getting into nitty gritty details in 4244bis because I don't think we should be stepping on the toes of greater Privacy issues (i.e., enhancement to 3323, extending for=20 multiparty, and so on).=20 Cheers. > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Tuesday, June 30, 2009 00:30 > To: Audet, Francois (SC100:3055); Ian Elz; Barnes, Mary=20 > (RICH2:AR00); R.Jesske@telekom.de; ietf.hanserik@gmail.com > Cc: sipcore@ietf.org; shida@agnada.com > Subject: RE: [sipcore] 4244bis and privacy >=20 > Yes, I think something like this makes sense. >=20 > John=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: 30 June 2009 00:06 > > To: Ian Elz; Elwell, John; Mary Barnes; R.Jesske@telekom.de;=20 > > ietf.hanserik@gmail.com > > Cc: sipcore@ietf.org; shida@agnada.com > > Subject: RE: [sipcore] 4244bis and privacy > >=20 > > I think the current "interpretation" is not terribly=20 > useful. I prefer=20 > > your suggestion. The current RFC 4244 text is not very clear. > >=20 > > It seems to me that: > > - Privacy should associated with a specific hi-entry (and=20 > perhaps any > > entry that corresponds to that same user), and not the header=20 > > itself. > > - That way, it is possible that specific entries be=20 > anonymize, but not > > others. For example, if you call me without privacy, and I call=20 > > forward > > you to John with privacy setup for myself, John should=20 > see an entry=20 > > for > > you and an anonymized entry for me. > > - There is no reason why "none" couldn't be used in this context.=20 > > Again, > > with the same example as above, John could requies "none"=20 > > for him, and > > I could set privacy on for myself. > >=20 > > I don't think this type of rule for 4244bis would require=20 > any change=20 > > whatsoever to RFC 3323. It would be completely self-contained in=20 > > 4244bis. > >=20 > > Comments? > >=20 > > > -----Original Message----- > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > Sent: Monday, June 29, 2009 03:26 > > > To: Audet, Francois (SC100:3055); Elwell, John; Barnes, Mary=20 > > > (RICH2:AR00); R.Jesske@telekom.de; ietf.hanserik@gmail.com > > > Cc: sipcore@ietf.org; shida@agnada.com > > > Subject: RE: [sipcore] 4244bis and privacy > > >=20 > > > Francios, > > >=20 > > > I agree that 4244bis should not specify the actions of=20 > proxies etc=20 > > > where this is a matter of local policy. > > >=20 > > > My original proposed change was to allow the inclusion of=20 > the value=20 > > > "none" in the alongside the value "history" to be included in the=20 > > > Privacy header parameter escaped in the=20 > hi-targeted-to-uri. (RFC4244=20 > > > section 4.1) > > >=20 > > > It appears however that the current interpretation of the Privacy=20 > > > header means that the value included in the Privacy=20 > header, which is=20 > > > applicable to the originating rather than retargeting user is=20 > > > applied to the retargeting user rather than the explicit value=20 > > > included for the retargeting user. > > > The escaped privacy value is only used if there is no=20 > Privacy header=20 > > > or the Privacy header only contains the value "user". > > >=20 > > > The end result of this interpretation is that including=20 > an explicit=20 > > > value "none" escaped as a Privacy parameter would have no=20 > effect and=20 > > > would have the same meaning as not including a Privacy header=20 > > > parameter escaped in the hi-targeted-to-uri. > > >=20 > > > 4244bis is not the place to extend the sip Privacy handling to=20 > > > specify how 3rd party identities in sip messages should=20 > have their=20 > > > own specific privacy maintained. > > >=20 > > > Allowing the inclusion of the explicitly Privacy=3Dnone=20 > value in the=20 > > > hi-targeted-to-uri would not change any handling at this time but=20 > > > would make the new H-I RFC suitable for use if an updated privacy=20 > > > RFC is proposed which does have specific support for 3rd party=20 > > > identities. > > >=20 > > > H-I is not the only place where the explicit privacy of 3rd party=20 > > > identities is required. The Referred-By header is one other case=20 > > > where a similar explicit privacy may need to be considered in the=20 > > > future. > > >=20 > > > regards > > >=20 > > > Ian > > >=20 > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: 26 June 2009 16:55 > > > To: Ian Elz; Elwell, John; Mary Barnes; R.Jesske@telekom.de;=20 > > > ietf.hanserik@gmail.com > > > Cc: sipcore@ietf.org; shida@agnada.com > > > Subject: RE: [sipcore] 4244bis and privacy > > >=20 > > > I do see things that we should fix right-away in History-Info,=20 > > > regarding privacy. > > >=20 > > > I also think that History-Info shouldn't "overstrech" and get too=20 > > > deep into the nitty gritty of privacy. What should be in=20 > HI is high=20 > > > level guidance. > > >=20 > > > In section 3.1, for example, it says that Privacy header will=20 > > > determine if a History-Info *header field* can be included by an=20 > > > intermediary. This does not make any sense. What it should say is=20 > > > that the Privacy header will determine if a history-info=20 > *entry* can=20 > > > be added for the UA inserting the Privacy header. > > >=20 > > > So, in my opinion, we can go ahead and fix that right now. > > >=20 > > > I don't think we need to get into super low-level procedural=20 > > > descriptions of the type "proxy MUST this and that if Privacy = =3D=3D=20 > > > this and that". I believe privacy matters are=20 > policy-level decisions=20 > > > that service providers and enteprises will have, and they are not=20 > > > going to be implemented by simplistic procedural rules=20 > from an RFC. > > >=20 > > > Comments? > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Ian Elz > > > > Sent: Friday, June 26, 2009 01:08 > > > > To: Elwell, John; Barnes, Mary (RICH2:AR00);=20 > R.Jesske@telekom.de;=20 > > > > ietf.hanserik@gmail.com > > > > Cc: sipcore@ietf.org; shida@agnada.com > > > > Subject: Re: [sipcore] 4244bis and privacy > > > >=20 > > > > John, > > > >=20 > > > > Your statement " not anonymise or remove any information > > > that the UAC > > > > has already placed in the request " is the key here. > > > >=20 > > > > The UAC has not included the H-I entry, particularly the one=20 > > > > containing the identity of the diverting party. > > > >=20 > > > > This was not considered in RFC3323 and we have an issue=20 > where we=20 > > > > cannot determine which entity included which information. > > > > This creates a problem where a restriction by the > > originating party > > > > will prevent a downstream identity from permitting > > presentation of > > > > their identity. > > > >=20 > > > > I agree with Mary that this probably requires an update to > > > > RFC3323 so we should start by updating RFC3323 and then > > > move on to the > > > > other impacted RFCs. The issue that this will raise for > > H-I is that > > > > there will be another change required after the Privacy RFC > > > has been > > > > agreed. > > > >=20 > > > > This is far from ideal but the 4424bis draft contains a lot > > > more than > > > > just this issue. > > > >=20 > > > > Ian > > > >=20 > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: 26 June 2009 08:30 > > > > To: Mary Barnes; R.Jesske@telekom.de; ietf.hanserik@gmail.com > > > > Cc: Ian Elz; sipcore@ietf.org; shida@agnada.com > > > > Subject: RE: [sipcore] 4244bis and privacy > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > > > > > Sent: 25 June 2009 22:45 > > > > > To: R.Jesske@telekom.de; ietf.hanserik@gmail.com > > > > > Cc: ian.elz@ericsson.com; sipcore@ietf.org; shida@agnada.com > > > > > Subject: Re: [sipcore] 4244bis and privacy > > > > >=20 > > > > > Roland, > > > > >=20 > > > > > The reason you can't have "none" at the request level and > > > > "history" at > > > > > the entry level is because RFC 3323 states that you MUST > > > NOT apply > > > > > privacy to the message. Even if you put "history" in the > > > > entries, the > > > > > privacy service would just ignore that - per RFC 3323. =20 > > > So, if you > > > > > want to change that behavior, then RFC 3323 should be > > > > changed - i.e., > > > > > the MUST NOT for the "none" could be changed to a SHOULD > > > > NOT and then > > > > > a general statement about possible exceptions. Then, we > > could add > > > > > something to RFC 4244 for this case. But, changing RFC > > > > > 3323 is totally out of scope for what we are currently > > > working on. =20 > > > > [JRE] I would interpret privacy 'none' in RFC 3323 as > > > meaning that a > > > > downstream entity must not anonymise or remove any > > information that > > > > the UAC has already placed in the request. > > > > If a downstream entity chooses: > > > > - not to add H-I, > > > > - to add anonymised H-I, or > > > > - to anonymise an H-I entry that some intermediate entity > > > has added, I > > > > don't see that as being in violation of what the UAC has > > requested. > > > >=20 > > > > John > > > >=20 > > > >=20 > > > > >=20 > > > > > That all said, I would sure think that if you are leaving a > > > > "trusted > > > > > network" that you have a B2BUA in there, as I've said=20 > in other=20 > > > > > threads. Thus, the B2BUA builds a new request and certainly > > > > can add a > > > > > privacy header that it believes is appropriate since > > the outgoing > > > > > request is done by the UAC function of a B2BUA. > > > > >=20 > > > > > Mary.=20 > > > > >=20 > > > > >=20 > > > > > -----Original Message----- > > > > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > > > > > Sent: Thursday, June 25, 2009 4:32 PM > > > > > To: ietf.hanserik@gmail.com > > > > > Cc: Barnes, Mary (RICH2:AR00); ian.elz@ericsson.com; > > > > sipcore@ietf.org; > > > > > shida@agnada.com > > > > > Subject: AW: [sipcore] 4244bis and privacy > > > > >=20 > > > > > Hi Hans Erik, > > > > > We have also to take regulatory into consideration. In > > > Germany the > > > > > last trusted network is responsible for anonymising=20 > information. > > > > >=20 > > > > > But nevertheless if Network provider A wants to have History=20 > > > > > completely private this operator will set privacy > > history for the > > > > > header. > > > > > If the succeeding Operator want to present elements the AS > > > > which adds > > > > > a entry has then to re label all entries from the > > > preceding network > > > > > and the entries from it's own network will be unmarked > > within the > > > > > Header. > > > > >=20 > > > > > But never the less I fully agree to your last sentence. > > > > >=20 > > > > > The real Question is if this should really be allowed > > > that a entry > > > > > marked with "none" overrules the privacy statement > > > > "history" for the > > > > > complete header. > > > > >=20 > > > > > I'm against this behaviour.=20 > > > > >=20 > > > > > Best Regards > > > > >=20 > > > > > Roland > > > > >=20 > > > > > -----Urspr=FCngliche Nachricht----- > > > > > Von: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > > > > Gesendet: Donnerstag, 25. Juni 2009 22:32 > > > > > An: Jesske, Roland > > > > > Cc: mary.barnes@nortel.com; ian.elz@ericsson.com; > > > sipcore@ietf.org; > > > > > shida@agnada.com > > > > > Betreff: Re: [sipcore] 4244bis and privacy > > > > >=20 > > > > > Hi Roland, > > > > >=20 > > > > > I don't understand the argument, by the time that the > > > History-Info > > > > > leaves operator A that wishes complete privacy, all the > > > > History-Info > > > > > headers should be anonymised according to 4244 and 4244bis. > > > > >=20 > > > > > What is the point in mandating that operator A to force > > > > operator B to > > > > > also anonymise the entries "owned" by operator B. > > > > >=20 > > > > > It is of course without question that each operator has > > > > full privacy > > > > > control over its own added entries. And each operator can > > > based on > > > > > local policy decide to remove the entire history if it > > > > things that is > > > > > wise to do. > > > > >=20 > > > > > /Hans Erik > > > > >=20 > > > > >=20 > > > > > R.Jesske@telekom.de wrote: > > > > > > Hi Marry and Ian, > > > > > > The whole discussion puzzle me. We have specified CDIV > > > > > within TISPAN and 3GPP.=20 > > > > > > There is described that privacy "none" can be used for > > > > > entries. BUT assuming that each entry has its own privacy > > > > statement if > > > > > needed. > > > > > > I fully agree on Mary's comment that a privacy "history"=20 > > > > > cannot overruled by a privacy value "none" within a entry.=20 > > > > > > There may be operators that would like to keep the whole > > > > > History Info private even if entries has other > > statements, so the > > > > > entity could add privacy history to the whole header. > > > > > Nothing more. > > > > > > > > > > > > On the other side a Application Server including a entry > > > > > should have the possibility to rewrite the entries so that > > > > instead of > > > > > "history" for the whole header the all received entries > > > within the > > > > > History-Info header will be marked with "history" and the > > > > added header > > > > > (which shall be presented to the terminating user) will > > either be > > > > > marked with "none" or will not be marked. > > > > > > > > > > > > Perhaps a hint could be given, but I do not insist on it. > > > > > > > > > > > > Best Regards, > > > > > > > > > > > > Roland > > > > > > > > > > > > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > > Von: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] Im > > > > > > Auftrag von Mary Barnes > > > > > > Gesendet: Donnerstag, 25. Juni 2009 18:29 > > > > > > An: Ian Elz > > > > > > Cc: sipcore@ietf.org; Shida Schubert > > > > > > Betreff: Re: [sipcore] 4244bis and privacy > > > > > > > > > > > > Hi Ian, > > > > > > > > > > > > Responses inline below [MB2]. > > > > > > > > > > > > Mary. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > > > Sent: Thursday, June 25, 2009 10:13 AM > > > > > > To: Barnes, Mary (RICH2:AR00) > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida=20 > Schubert;=20 > > > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > Mary, > > > > > > > > > > > > I am a little concerned about one answer that you gave: > > > > > > > > > > > > > > > > > > If you have a Privacy header with a value of "none" and a > > > > H-I entry > > > > > > with Privacy header parameter with value "history" what is > > > > > the privacy > > > > > > of the individual H-I entry? > > > > > > [MB] We did not explicitly address the "none" in RFC > > > > 4244, but the > > > > > > general statement is the privacy headers at the request > > > > > level override > > > > > > any at the hi-entry level. [/MB] > > > > > > =20 > > > > > > This means that if privacy is required for an individual > > > > > H-I entry but > > > > > > the originating user included "Privacy:none" in the request > > > > > then there > > > > > > is no option to include the real URI in the H-I entry. > > > > > > [MB2] I'm confused here - the "none" definition is as you > > > > > note below, > > > > > > thus "none" prohibits the removal or anonymization of the > > > > entries, > > > > > > thus I would think you would fine this functionality > > desireable. > > > > > > However, this does not prohibit an entity based on policy > > > > > to anonymize > > > > > > (or remove entries if privacy is required for that > > > domain if the > > > > > > entity does not have access to a privacy service). [/MB2] > > > > > > > > > > > > This occurs as RFC3323 states in section 4.3: "However, if > > > > > the Privacy > > > > > > header value of 'none' is specified in a message, privacy > > > > services > > > > > > MUST NOT perform any privacy function and MUST NOT remove > > > > or modify > > > > > > the Privacy header." > > > > > > > > > > > > The only option for an intermediate node including a H-I > > > > > entry where > > > > > > "Privacy:none" is specified and privacy for the H-I URI is > > > > > required is > > > > > > to include an anonymous entry or not include the H-I entry. > > > > > > [MB2] If privacy is required then yes, you include > > > > > anonymous entries > > > > > > or don't include. That's the basic privacy mechanism > > > for privacy > > > > > > levels of "session" "header" and "history" in the R-URI or > > > > > "history"=20 > > > > > > in the specific entries, as well as when there is a policy > > > > > for privacy > > > > > > for the entries added by a specific domain. The "none"=20 > > > > > really has no > > > > > > influence on the later case per se. [/MB2] > > > > > > > > > > > > In your previous response you stated that we would violate > > > > > RFC3323 if > > > > > > we specified additional behaviour for privacy explicitly > > > > > stated with a > > > > > > URI -n the H-I entry. I don't believe that this is the case > > > > > as RFC3323 > > > > > > only considered privacy in a two party scenario and did not > > > > > consider > > > > > > third party identities being included in a message > > between two > > > > > > parties. H-I is not the only case where this occurs as the > > > > > Referred-By > > > > > > header when included in the INVITE (or other request) > > > > which results > > > > > > from the REFER has the same issue. > > > > > > [MB2] I can't necessarily disagree on this one (we can > > > debate it > > > > > > either way). But to fix it requires an update to=20 > RFC 3323 and=20 > > > > > > shouldn't be something that we want to fix in=20 > 4244bis. [/MB2] > > > > > > > > > > > > RFC4244 was the first time that there was a recognition > > > > > that privacy > > > > > > for these individual third party identities may be > > > > > required. To allow > > > > > > this explicit statement of privacy to be overridden by > > > a generic > > > > > > statement which is applicable to a different user is > > > > > counterintuitive. > > > > > > [MB2] See my comment above. But, as I have consistently > > > > > said, the idea > > > > > > that an entity might want to override the "none" is > > > > > entirely based on > > > > > > policy and 4244 and 4244bis allow privacy to be applied to > > > > > the entries > > > > > > that are added by that entity if the policy dictates > > so (and we > > > > > > already say that). [/MB2] > > > > > > > > > > > > The original Privacy header is usually included by or on > > > > > behalf of the > > > > > > originating user and should not be allowed to specify the > > > > > privacy of > > > > > > the original called user, e.g. the 800 number, and > > prevent this > > > > > > identity being presented if this user does not have the > > > > > same level of privacy. > > > > > > [MB2] As I tried to say in a previous response, a random > > > > > entity (i.e., > > > > > > one for whom the R-URI is not in a domain under its > > > > control) cannot > > > > > > add a privacy header to the Request. Per RFC 3323 an > > > > entity may add > > > > > > the header to a request only if it has the appropriate=20 > > > > > > relationship/authorization with the original called user > > > > > who intiated > > > > > > the request. And, I would find it very surprising if an > > > > entity that > > > > > > did have responsibility would apply privacy since > > that would be > > > > > > counter intuitive and I would hope that SPs would be > > > judicious in > > > > > > specifying the appropriate and inappropriate manner in > > > which the > > > > > > proxies they deploy and interface with privatize the > > > > messages. The > > > > > > protocol CANNOT control this behavior and that's why > > > there is the > > > > > > policy clause in 4244 and 4244bis. [/MB2] > > > > > > > > > > > > The real issue with the 800 scenario is as you have stated > > > > > is that the > > > > > > answerer will not know the original called identity and > > > > will not be > > > > > > able to correctly handle the call. As more generic call > > > > centres are > > > > > > used which will answer calls on behalf of many different > > > > > organizations > > > > > > using CTI and the original called identity to have to > > > implement a > > > > > > generic system asking the caller who he originally > > > called appear > > > > > > unprofessional, is inefficient and unproductive. > > > > > > [MB2] And, as I noted, it is rare for a call centre to > > > > route a call > > > > > > directly to an agent without a user providing some sort of > > > > > input. Even > > > > > > companies like American Airlines, even though they have the > > > > > info that > > > > > > I enter via the IVR, they still ask some basic questions > > > > > and there are > > > > > > times when they have to reroute me. I don't think we > > > can totally > > > > > > automate things. And, again, once the call hits the > > > > domain that is > > > > > > responsible for that 800 number the entities in that > > > domain have > > > > > > control over how they muck with the R-URI, such that they > > > > should be > > > > > > able to use any IVR info to appropriately direct the call - > > > > > it's not > > > > > > the number that's meaningful, but how the system gets the > > > > > call to the > > > > > > right user and the additional information they provide as > > > > > the call is > > > > > > presented to the agent. I would honestly think that having > > > > > something > > > > > > other than an 800 number show up on the display would > > > be far more > > > > > > useful and in my experience in the systems I developed > > > > > we're usually > > > > > > talking about CTI interfaces so you have a lot you can > > > do. And, > > > > > > actually all of this really doesn't matter in that you MUST > > > > > be able to > > > > > > handle this situation independent of the privacy since > > > > > History-Info is > > > > > > optional, you need default behavior assigned. [/MB2] > > > > > > > > > > > > We have an opportunity to allow presentation of specific > > > > identities > > > > > > and to solve this particular problem so we should take it. > > > > > > [MB2] The most we can do is to document the risks/impacts > > > > > of the use > > > > > > of the Privacy headers at the R-URI level. There is > > > > already general > > > > > > text in > > > > > > 4244 and 4244bis that the privacy may impact whether the > > > > > applications > > > > > > get the information. And, as I noted before, most > > > > > commercial systems > > > > > > are using B2BUAs which will allow you far more control over > > > > > the use of > > > > > > the Privacy headers in the network. But, again, I don't > > > > > think that's > > > > > > something that should be address in 4244bis. [/MB2] > > > > > > > > > > > > I hope that we can get some wider discussion on this issue > > > > > so a more > > > > > > general consensus can be obtained. > > > > > > > > > > > > Regards > > > > > > > > > > > > Ian > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > > > Sent: 24 June 2009 17:27 > > > > > > To: Ian Elz > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida=20 > Schubert;=20 > > > > > > sipcore@ietf.org; Francois Audet > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > Hi Ian, > > > > > > > > > > > > Responses inline below [MB]. > > > > > > > > > > > > Mary.=20 > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > > > Sent: Wednesday, June 24, 2009 10:37 AM > > > > > > To: Barnes, Mary (RICH2:AR00) > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida=20 > Schubert;=20 > > > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > Mary, > > > > > > > > > > > > I was not proposing that we change the handling of H-I > > > > > which is based > > > > > > upon local policy. If that causes an issue for a network > > > > > operator then > > > > > > they can modify their local policy accordingly or arrange > > > > with the > > > > > > proxy vendor to modify their equipment to be more > > flexible with > > > > > > regards to policy. > > > > > > > > > > > > Can you clarify for me: > > > > > > > > > > > > If you have a Privacy header with either "session" or > > > > "header" doe > > > > > > this impact the H-I entries or will only a value of > > > > > "history" impact > > > > > > the H-I entries? > > > > > > [MB] Yes, both "session" and "header" level privacy, > > > > > consistent with > > > > > > RFC 3323, mandate that entries be anonymized or > > > dropped, with the > > > > > > latter being the recommendation for "session" level > > > > > privacy. RFC 4244 > > > > > > mandated that they be dropped and 4244bis=20 > recommends they be=20 > > > > > > anonymized. The original intent for the value of "history" > > > > > was for the > > > > > > tagging of the individual entries, but you end up getting > > > > > the header > > > > > > level functionality as well. [/MB] > > > > > > > > > > > > If you have a Privacy header with a value of "none" and a > > > > H-I entry > > > > > > with Privacy header parameter with value "history" what is > > > > > the privacy > > > > > > of the individual H-I entry? > > > > > > [MB] We did not explicitly address the "none" in RFC > > > > 4244, but the > > > > > > general statement is the privacy headers at the request > > > > > level override > > > > > > any at the hi-entry level. [/MB] > > > > > > > > > > > > From reading RFC4244 a Privacy header with value > > "history" will > > > > > > effectively make all H-I entries private and there is > > > > currently no > > > > > > option to include a H-I Privacy header parameter with > > > > value "none". > > > > > > [MB] Correct, per my comment above. [/MB] > > > > > > > > > > > > H-I at present allows the inclusion of Privacy header > > > > parameters to > > > > > > explicitly express privacy for an individual H-I entry > > > > but a single > > > > > > node which includes a header "Privacy: history" makes all > > > > > H-I entries > > > > > > private even if this is not the requirements for the > > > specific URI. > > > > > > [MB] Correct, but the only node that should add the header > > > > > is a node > > > > > > which is responsible for the domain associated with the > > > > > Request URI in > > > > > > the incoming request or is authorized to do so. [/MB] > > > > > > > > > > > > I will admit that having worked in a telephony environment > > > > > for a long > > > > > > time I am used to having privacy of identities set on a > > > > per number > > > > > > basis and the relative inflexibility of the IETF Privacy > > > > header is > > > > > > relatively restrictive as to specifying which > > identities may be > > > > > > presented and which not. > > > > > > [MB] Yes, this is an entirely different paradigm. I > > developed > > > > > > telephony s/w for over a decade and this is entirely > > > > different - it > > > > > > provides a lot more flexibility, which makes things > > > far, far less > > > > > > deterministic than what you have in telephony switches > > > where your > > > > > > routing and translations are configured for the most part, > > > > > with just a > > > > > > few capabilities for controlling the privacy and it's a > > > > > closed network. > > > > > > > > > > > > With RFC4244/4244bis, there MUST be a mechanism at the > > > UAS or end > > > > > > application that can handle a request that doesn't have the=20 > > > > > > appropriate information either because nodes didn't support=20 > > > > > > History-Info or some random node in the network applied > > > > > privacy (which > > > > > > I think is highly > > > > > > unlikely) - this is normative per section 5 of RFC > > > 4244. So, the > > > > > > worst case scenario I see for this 800 service (which will > > > > > get to the > > > > > > right UAS but without the exact 800 number that was dialed) > > > > > is that it > > > > > > goes to a default ACD group/customer service agent, > > > etc. who then > > > > > > needs to gather the appropriate information and in my > > > > > experience this > > > > > > is often an IVR system these days. So, the service is not > > > > > broken when > > > > > > privacy is applied in an undesireable manner, it's just not > > > > > optimal. =20 > > > > > > This is something that should be addressed in the > > > > target-uri draft > > > > > > which has all the details of how specific services use > > > > History-Info. > > > > > > One other thing to consider is that most networks that are > > > > > emulating > > > > > > telephony type features use B2BUAs, which follow the > > > > > UAS/UAC rules for > > > > > > the header rather than the proxy rules, noting that the > > > > UAC can set > > > > > > the Privacy header to whatever value it sees as appropriate > > > > > for the request. > > > > > > [/MB] > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Ian > > > > > > > > > > > > -----Original Message----- > > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > > > Sent: 24 June 2009 15:48 > > > > > > To: Ian Elz > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida=20 > Schubert;=20 > > > > > > sipcore@ietf.org; Francois Audet > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > Hi Ian, > > > > > > > > > > > > I do not believe we should do the "override" behavior as I > > > > > think that > > > > > > violates RFC 3323, as the "history" is really a subset of > > > > the cases > > > > > > whereby a UAC or proxy would add "session" or "header" to > > > > > the request. > > > > > > And, the latter two cases have the same (undesireable) > > > > > result. I agree > > > > > > this impacts your services, but we can't mandate that > > > > > proxies provide > > > > > > information that might violate their local policies and > > > indeed a > > > > > > proxy's local policies can result in the information being > > > > > anonymized > > > > > > (or removed if they can't anonymize) even in the=20 > "none" case. > > > > > > > > > > > > I do believe it's reasonable that we strongly recommend > > > that the > > > > > > request level (versus specific hi-entries) not be used > > > > and if it is > > > > > > used, the consequence is that some services will=20 > not have the=20 > > > > > > information they need - this was the gist of my previous > > > > > response (to > > > > > > which I did not get any additional feedback). Now, we could > > > > > add some text that the "none" > > > > > > case SHOULD be used (e.g., added by first hop proxy) if it > > > > > is desired > > > > > > that the information not be subject to privacy > > > > > restrictions. I do not > > > > > > think it is then particularly useful to add logic around > > > > the proxy > > > > > > then being able to tag the entries within their domain as > > > > > subject to privacy. > > > > > > I think that conflicts with the intent of the request > > > > level "none". > > > > > > However, as I mention above, per the current text, a proxy > > > > > can (based > > > > > > on local policy) remove entries - so a proxy can capture > > > > hi within > > > > > > their domain and not forward any of that information to the > > > > > next hop > > > > > > in another domain - you already have that functionality. =20 > > > > > But, I think > > > > > > this introduces the general problem that you might be > > > > > impacting other > > > > > > services further down the line, which I thought was the > > > > problem you > > > > > > were wanting to solve - not specifically your example > > > > > service but, for > > > > > > example, in the case that someone is debugging and they > > > want the > > > > > > entire history, so depending upon the service, this is also=20 > > > > > > undesirable behavior. > > > > > > > > > > > > > > > > > > Regards, > > > > > > Mary.=20 > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > > > Sent: Wednesday, June 24, 2009 2:57 AM > > > > > > To: Barnes, Mary (RICH2:AR00) > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida=20 > Schubert;=20 > > > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > > > > > > > Mary, > > > > > > > > > > > > [I have added the list to this thread for wider comment.] > > > > > > > > > > > > In the previous discussions I commented that in RFC4424 > > > > > that a Privacy > > > > > > header with value "history" effectively makes all H-I > > > > > entries private > > > > > > with the result that the H-I entries may be removed. > > > > > > > > > > > > There has now been a comprehensive discussion on > > > > indication of the > > > > > > initial 'target' to the final recipient for call handling > > > > purposes. > > > > > > > > > > > > The main use case related to a freephone example where the > > > > > answering > > > > > > location may be a call centre where the original freephone > > > > > number may > > > > > > be required for correct call handling. > > > > > > > > > > > > If you now consider the following example (modified from > > > > Francois'=20 > > > > > > text in the latest draft - excuse any errors that I may > > > > > have inserted) > > > > > > > > > > > > INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx > > > > > > Privacy: history > > > > > > History-Info: > > > > > >=20 > > > > > = ;index=3D1;rt;aor =20 > > > > > (1) > > > > > > History-Info: = ;index=3D1.1;mp;aor > > > > > > (2) > > > > > > History-Info: ;index=3D1.1.1;rc > > > > > > (3) > > > > > > > > > > > > In this case due to the Privacy header all of the H-I > > > entries are > > > > > > considered private and the +18001234567 will not be > > > > > delivered to the > > > > > > final destination with the result that call handling may > > > > > not be correct. > > > > > > The Privacy header may have been inserted by any of the > > > > nodes which > > > > > > routed the message and inserted a H-I entry. > > > > > > > > > > > > If however the H-I was allowed to include a header > > parameter of > > > > > > "?Privacy=3Dnone" in the H-I entry and that an explicit > > H-I entry > > > > > > privacy value would be considered to have precedence over > > > > a Privacy > > > > > > header with a value of "history" then the mapping of the > > > > > +18001234567 > > > > > > could be explicitly specified as not private and may be > > > passed on. > > > > > > > > > > > > Thus when the mapping from sip:+18001234567@example.com to=20 > > > > > > sip:bob@biloxi.example.com when H-I entry (2) above is > > > > > included could > > > > > > also insert the Privacy header parameter in H-I entry (1). > > > > > > > > > > > > Thus the message would appear as follows: > > > > > > > > > > > > INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx > > > > > > Privacy: history > > > > > > History-Info: > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 > = ;index=3D= 1;rt; > > > > > > ao > > > > > > r > > > > > > History-Info: = ;index=3D1.1;mp;aor > > > > > > History-Info: ;index=3D1.1.1;rc > > > > > > > > > > > > This would result in all the H-I entries except (1) being > > > > > considered > > > > > > private with the result that the =3D1800... Number is > > > > passed for call > > > > > > handling purposes. > > > > > > > > > > > > This change is backward compatible with the existing > > > > > implementation as > > > > > > any node using the existing functionality as defined in > > > > > RFC4244 will > > > > > > continue to be supported. > > > > > > > > > > > > The alternative is to remove the ability to include the > > > > > value "history" > > > > > > in the Privacy header and only allow this value in the > > > > > Privacy header > > > > > > parameter. This alternative is not backward compatible. > > > > > > > > > > > > Without this change a single node in the message path which > > > > > includes a > > > > > > header "Privacy: history" will prevent delivery of the > > > > aor and thus > > > > > > prevent proper call handling. > > > > > > > > > > > > Ian Elz > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Christer Holmberg > > > > > > Sent: 23 June 2009 19:40 > > > > > > To: 'Mary Barnes'; Francois Audet; Hans Erik van > > Elburg; Shida > > > > > > Schubert > > > > > > Cc: Ian Elz > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > =20 > > > > > > Hi, > > > > > > > > > > > > I include Ian, so he can comment to your resposne himself. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > > > Sent: Tuesday, June 23, 2009 9:40 PM > > > > > > To: Christer Holmberg; Francois Audet; Hans Erik van > > > > Elburg; Shida > > > > > > Schubert > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > Here was the thread of response and the last comment was > > > > > from Ian that > > > > > > he would consider the response: > > > > > >=20 > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html > > > > > > > > > > > > And, there was not agreement on the "none" but rather to > > > > > qualify the > > > > > > SHOULD NOT forward. However, in the sipcore-4244bis-00, > > > > > rather than > > > > > > changing the text such that the headers SHOULD be=20 > removed, we=20 > > > > > > recommend that they be anonymized (in section 4.3.3.3.1). > > > > That is > > > > > > entirely consistent with RFC 3324 and thus we have > > removed the > > > > > > recommendations to remove the headers entirely. However, > > > > > that changed > > > > > > never got done in section 3.2, so we would need to > > change this: > > > > > > "Thus, the History- Info header > > > > > > SHOULD NOT be included in Requests where the requestor > > > > > has indicated > > > > > > a priv-value of Session- or Header-level privacy." > > > > > > > > > > > > But, I'm really beginning to be of the mindset that we > > > > should just > > > > > > remove all the subsections of section 3 (i.e., leave the > > > > > text in the > > > > > > upper level section), so we don't have to keep=20 > worrying about=20 > > > > > > consistency. > > > > > > > > > > > > So, lets either fixt the text in 3.2 or remove altogether > > > > > and then I > > > > > > think we are really at the point of needing to submit this > > > > > version so > > > > > > folks that actually have an interest in it can review > > > the updated > > > > > > document. > > > > > > > > > > > > Mary.=20 > > > > > > > > > > > > -----Original Message----- > > > > > > From: Christer Holmberg > > [mailto:christer.holmberg@ericsson.com] > > > > > > Sent: Tuesday, June 23, 2009 1:10 PM > > > > > > To: Barnes, Mary (RICH2:AR00); Audet, Francois > > > > > (SC100:3055); Hans Erik > > > > > > van Elburg; Shida Schubert > > > > > > Subject: 4244bis and privacy > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > Below is a comment/proposal which one of my collegues (Ian > > > > > Elz) gave > > > > > > on the list a while ago, when the first version of > > 4244bis was > > > > > > submitted, but was not incorporated. Do you think it would > > > > > be useful? > > > > > > > > > > > > ------- > > > > > > > > > > > > While the HI approach to target may solve the problem of > > > > > being able to > > > > > > deliver the target URI to the final destination there is no > > > > > guarantee > > > > > > that it will actually be delivered. > > > > > > > > > > > > The problem arises with how Privacy is defined for HI. > > > > > > > > > > > > 4424 defines a new Privacy value "history" which may be > > > placed in > > > > > > either the Privacy header or as a header parameter to the > > > > HI entry. > > > > > > > > > > > > If one node uses the former option "Privacy: history" then > > > > > this will > > > > > > make all headers private and will result in all HI > > > entries being > > > > > > removed or made anonymous when the message containing > > the HI is > > > > > > delivered to the user. > > > > > > > > > > > > There is a simple solution to this and that is to also > > > > > allow the use > > > > > > of the "none" Privacy value as a header parameter in the > > > > HI entry.=20 > > > > > > This would explicitly state that no privacy is required > > > to the HI > > > > > > entry and this would override a "history" value in the > > > > > Privacy header. > > > > > > > > > > > > I pointed this out to Mary when the 4424bis draft was first > > > > > published > > > > > > but the change has not been made in the latest draft. > > > > > > > > > > > > The change is backward compatible and would not cause an > > > > issue with > > > > > > any existing implementations. > > > > > > > > > > > > ------ > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > sipcore mailing list > > > > > > sipcore@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > _______________________________________________ > > > > > > sipcore mailing list > > > > > > sipcore@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > =20 > > > > > _______________________________________________ > > > > > 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 > > > >=20 > > >=20 > >=20 >=20 From adam@nostrum.com Tue Jun 30 13:38:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8121628C3FB for ; Tue, 30 Jun 2009 13:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2ikNp5R-Giy for ; Tue, 30 Jun 2009 13:38:31 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 3702C3A6962 for ; Tue, 30 Jun 2009 13:38:31 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-101.dsl.rcsntx.swbell.net [70.249.149.101]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n5UKcnj7041139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Jun 2009 15:38:49 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A4A77D9.1020700@nostrum.com> Date: Tue, 30 Jun 2009 15:38:49 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: sipcore@ietf.org References: <4A16F967.6050509@nostrum.com> <4A30B989.9040805@nostrum.com> In-Reply-To: <4A30B989.9040805@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.149.101 is authenticated by a trusted mechanism) Subject: [sipcore] LAST CALL: Re: IETF 75: Agenda Time Requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 20:38:32 -0000 [as chair] So far, the chairs have received three requests for agenda time: * draft-ietf-sipcore-keep * history-info-bis / target-uri * 3265-bis Unless we receive additional requests before the end of this week, we will be instructing the secretariat to reduce the amount of face-to-face meeting time to one hour, so as to alleviate any scheduling conflicts that we would otherwise cause. After we do this, it will be too late to request additional agenda time. If you want to discuss something in Stockholm other than these three items, speak up now. /a Adam Roach wrote: > On 22-May-2009, Adam Roach wrote: >> If you wish to request agenda time, please send these three pieces of >> information to the SIPCORE chairs on or before June 3rd. > > > That was, of course, a typo. The deadline for agenda requests is July > 3rd. Please see the original mail below (with the date corrected) for > further details. > > /a > > >> [as chair] >> >> In keeping with the spirit of our charter, we intend to run SIPCORE >> face-to-face meetings in a very focused fashion. To that end, >> requests for SIPCORE agenda time need to contain the following >> information: >> >> 1. The name of the draft or drafts under discussion >> 2. A list of open issues to be addressed >> 3. A pointer to non-trivial mailing list discussion of the draft (the >> subject line of associated threads is sufficient) >> >> Presentations are expected to be focused around the list of open >> issues, not the general contents of or changes to the document. >> Tutorial content must be limited to explaining the open issues and >> potential resolutions to those issues. >> >> Please note that it will be very difficult to have non-trivial >> mailing list discussion of drafts that are submitted very close to >> the document submission deadlines. We strongly encourage authors who >> plan to request agenda time to publish a revised document well ahead >> of the deadlines. >> >> Currently, we have requested a total of 3.5 hours of meeting time at >> the upcoming meeting in Stockholm this July. Depending on the total >> number of open issues and the associated volume of mailing list >> traffic, we may reduce this to 2.5 hours or even 1 hour. >> >> If you wish to request agenda time, please send these three pieces of >> information to the SIPCORE chairs on or before July 3rd. Length of >> timeslots will be determined based on the number and complexity of >> open issues in the agenda request. If a new open issue arises after >> submission of a request, please notify the chairs so that we can >> adjust timeslots accordingly. >> >> For the sake of clarity: the discussion will not be limited to the >> open items listed in your request; it can include open items that >> arise after you submit your request. So, if your list of open items >> is somewhat weak but you expect that difficult points may arise >> between June 3rd and the Stockholm meeting, please send in a request >> indicating that fact. >> >> /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore