Re: [Sip] a question about IETF draft location conveyance 09
Ted Hardie <hardie@qualcomm.com> Wed, 21 November 2007 21:02 UTC
Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuwiJ-00080f-UL; Wed, 21 Nov 2007 16:02:27 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IuwiH-00080S-TO for sip-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 16:02:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuwiH-0007yt-Hf for sip@ietf.org; Wed, 21 Nov 2007 16:02:25 -0500
Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuwiD-0004S4-0d for sip@ietf.org; Wed, 21 Nov 2007 16:02:25 -0500
Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lALL2JUM008483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Nov 2007 13:02:19 -0800
Received: from [67.169.50.136] (carbuncle.qualcomm.com [129.46.226.27]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lALL2InA005852; Wed, 21 Nov 2007 13:02:19 -0800
Mime-Version: 1.0
Message-Id: <p06240608c36a4849ecf3@[67.169.50.136]>
In-Reply-To: <XFE-SJC-211EAOeIiGX000013f8@xfe-sjc-211.amer.cisco.com>
References: <4742BDF5.9040302@unibo.it> <XFE-SJC-212qXLFfJNw000012bf@xfe-sjc-212.amer.cisco.com> <p06240607c36a38613297@[67.169.50.136]> <XFE-SJC-211EAOeIiGX000013f8@xfe-sjc-211.amer.cisco.com>
Date: Wed, 21 Nov 2007 13:02:16 -0800
To: "James M. Polk" <jmpolk@cisco.com>, Daniel Grotti <daniel.grotti@unibo.it>, IETF SIP List <sip@ietf.org>
From: Ted Hardie <hardie@qualcomm.com>
Subject: Re: [Sip] a question about IETF draft location conveyance 09
Content-Type: text/plain; charset="us-ascii"
X-PerlMx: Message inspected by PerlMx
X-PerlMx: Message inspected by PerlMx
X-Spam-Score: -4.0 (----)
X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b
Cc:
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org
At 2:28 PM -0600 11/21/07, James M. Polk wrote: >Ted > >The "recipient=" within the Geolocation header is a SIP parameter, in a SIP document. Everything discussed in Geopriv regarding this document needs to be approved in SIP too. The SIP WG hasn't heard this part of the discussion because most members of SIP aren't subscribed to the Geopriv list. That SIP parameter in a SIP document relates to a PIDF-LO object carried by SIP; in that context, SIP is a using protocol of the GEOPRIV framework. SIP folks should certainly understand the work they're reusing, or the implementations won't do the right thing. But re-starting the conversation in SIP without reference to the discussions that have already occurred in GeoPRIV is a recipe for conflict at IETF Last Call. We might as well start getting people on the same page now. From my perspective, the right way to do that is to start the discussion from where it last left off, even if that wasn't in the same group. That tells people where the consensus of that group was and informs the rest of the discussion. > >I'm on the agenda right now to present in SIP in Vancouver, and this is one issue I'd like the SIP WG to comment on, so I'll be asking it there. I look forward to your presentation. Further commments inline. >the rest of my reply is in-line > >At 01:51 PM 11/21/2007, Ted Hardie wrote: >>At 6:33 PM -0600 11/20/07, James M. Polk wrote: >>>Daniel >>> >>>wow... you nailed this one quickly. >>> >>>Neither the SIP WG nor Geopriv WG have a position with regard to this. I don't like the parameter at all, and have said so from its introduction into discussions about putting it in the draft. I don't think it accomplishes much more than confusion or a false sense of security by implementors. >> >>Well, I think the Geopriv working group discussed this a great deal, and that >>there was reasonable (albeit rough) consensus that it be included. Anyone >>interested can certainly see a lively debate on the Geopriv list. > >and where was the SIP WG discussion on a SIP header parameter? Since this parameter, from what you state below, has a UA understanding the topology of a request - all the way to the endpoint - which is not part of the Geopriv charter to know or make decisions on, where's that discussion, at least as confirmation that SIP UAC's can know the full topology of a network enough to make this decision (that can't be changed)? You are making a big leap here. It doesn't have a UA understanding of the topology; it has User control over private information. The user gets to say by whom his or her location gets used; that's a core aspect of RFC 4119 and friends, and you don't get to reuse that work without getting that assumption built in. We've had exceptions for emergency services (discussed in the ECRIT BCPs), but they're not general. If a user does not want that private information used by the SIP routing system but is willing to give it to the SIP entity receiving the call, the system has to provide a way of making that clear. We discussed several ways to achieve that (including changes to 4119), and there was pretty clear consensus on this way forward. The version with retransmission-allowed or routing-query-allowed did not see support, nor did redefining "retransmission=no" to mean "except for SIP". Yes, this does mean that a UA that sends a location object with recipient=end-point may have a call fail if location-based routing is absolutely required; so will any call not containing location, though, and the UA will have to be able to handle that case. It may very well be what is wanted, as we discussed in relation to taxi services at some length (I may be willing to send my location to a local taxi service so it can send the taxi, but not willing to send my location to the sip-routing system so it can pick a taxi-service local to me). >For example, Alice calls PizzaHut.com, and Pizza Hut routes her call to the Pizza Hut store most local to wherever she is to take her order. Does her UAC understand this type of call well enough to have "recipient=both"? Or would it just enter "recipient=endpoint", thus preventing her SIP request from being retargetted? > >How does her UAC understand the different from this type of call to Pizza Hut from merely a complaint to Pizza Hut corporate? > >I still can't seem to get over this simple example of a limitation and assumption created by this header parameter that the caller doesn't control. Perhaps I don't see what you mean by "caller doesn't control" here. Can you elaborate? > >>The current text is: >>A locationValue has the following independent header parameters, >> >>(snip of other parameters) >> >>the "recipient=" parameter to allow recipients to infer what SIP >> element type this locationValue was intended to be for. The >> types are >> >> o "endpoint" - meaning the ultimate destination UAS; >> >> o "routing-entity" - meaning SIP servers that route messages >> based on the location contents of requests; and >> >> o "both" - meaning this locationValue is to be viewed by both >> types of SIP entities. >> >> Not all SIP entities have to read the locationValue within a >> Geolocation header, therefore a parameter value of "both" does >> not mean "every" SIP element receiving this request, it means all >> that care to pay attention to a locationValue. The default >> behavior of SIP entities reading the locationValue is that if >> this header parameter is NOT present, the intended recipient is >> the destination UAS. >> >>A proxy seeing a locationValue with a recipient= tag of >>routing-entity or both MAY do location based routing using >>the location (as the draft says, it does not have to). A proxy >>seeing a locationValue with a recipient=endpoint should understand >>that the locationValue was not intended to be used for >>location-based routing. The draft is pretty clear that the >>privacy rules in RFC 4119; in Section 5 it says pretty bluntly: >> >> Location Recipients MUST obey the privacy and security rules in the >> PIDF-LO as described in RFC 4119 regarding retransmission and >> retention. >> >>If a proxy is not the intended recipient, as given in this parameter, >>it shouldn't be storing or acting on this data, just sending it along. >> >> >>>That said, a proxy has "ar" capabilities wrt the Geolocation according to Table 1. (on page 7), and associated text states this pretty clearly. There is no text (not even a hint) that a proxy cannot read a location because "recipient=endpoint", therefore it can. I would take this "recipient=" parameter as a hint to each type of SIP entity that >>> >>> + if a UAS receives this parameter (meaning in a SIP request with >>> a Geolocation header), and it is set to "recipient", the UAS >>> shouldn't ignore the location in the request (like it otherwise >>> might). >>> >>> + If a proxy receives this parameter (meaning in a SIP request with >>> a Geolocation header), and it is set to "server", the proxy >>> shouldn't ignore the location in the request (like it otherwise >>> might). >>> >>>I don't think either indication *ever* means the other SIP entity type cannot view the location, based on the parameter. >> >>I don't understand what you mean by "view" here. A proxy putting this to memory >>in order to send it along is doing fine; someone doing location-based-routing when >>recipient=endpoint is not doing the right thing (except in the Emergency Services >>case, where all bets are off). > >RFC3261 says proxies can view message bodies that aren't encrypted. And what does "view" mean here? If it understands it enough to know how to use a pidf-lo object for location-based routing, it pretty much has to understand it enough to know that it is not an intended recipient of such a body, based on the header here and the pidf-lo internal rules. If it doesn't understand pidf-lo, then "viewing" it means something like "copying", "forwarding", or similar, no? >I don't see the text giving an exemption in the emergency case, not at least in this doc. The exception is in the ECRIT documents, or was the last I checked (sorry that I have no time to confirm now). > >> >The only exception I can think of is a Location-by-value hidden by S/MIME means no one save who has the decryption key can view the contents of what's encrypted. >>> >>>Does this make sense? >> >>I suggest we continue the conversation in GeoPRIV if we have further discussion >>on this particular point. > >But this is a SIP parameter, and a SIP document. Everything discussed in Geopriv needs to be approved in SIP too. The SIP WG hasn't heard this part of the discussion because most members of SIP aren't subscribed to the Geopriv list. I'm reluctant to suggest cross-posting, but I do believe that folks commenting on this should be aware of the discussion in the Geopriv group prior to this. I continue to recommend that folks review the geopriv archive, searching for the document name, in order to get that context. Note that deciding to ignore the privacy implications of geopriv's framework is simply going to create "confusion and delay", as my son's favorite railroad director says, and if we actually hope to see this work we need to work within the framework as much as we can. regards, Ted Hardie >> Ted >> >> >> >>>James >>> >>>At 04:59 AM 11/20/2007, Daniel Grotti wrote: >>>>Hi all, >>>>I'd like to ask a question about "draft-ietf-sip-location-conveyance-09.txt". >>>> >>>>How does Proxy Server have to work when a Geolocation Header contain "recipient=endpoint" parameter ? >>>>Does the Proxy server just have to forward the SIP message (without do anything else) or can it read the information conveyed ? >>>>thanks, >>>>Regards >>>>daniel >>>> >>>>-- >>>> >>>>--------------------------------------------------- >>>>Daniel Grotti >>>>DEIS - University of Bologna >>>>Via Venezia, 52 - 47023 Cesena (FC) - ITALY >>>> >>>>Contacts >>>>e-mail : daniel.grotti@unibo.it >>>>Skype name : Daniel Grotti >>>>--------------------------------------------------- >>>> >>>> >>>> >>>>_______________________________________________ >>>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>>This list is for NEW development of the core SIP Protocol >>>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>>Use sipping@ietf.org for new developments on the application of sip >>> >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] a question about IETF draft location convey… Daniel Grotti
- Re: [Sip] a question about IETF draft location co… James M. Polk
- Re: [Sip] a question about IETF draft location co… Ted Hardie
- Re: [Sip] a question about IETF draft location co… James M. Polk
- Re: [Sip] a question about IETF draft location co… Ted Hardie
- Re: [Sip] a question about IETF draft location co… James M. Polk
- Re: [Sip] a question about IETF draft location co… Ted Hardie
- Re: [Sip] a question about IETF draft location co… Dean Willis
- R: [Sip] a question about IETF draft location con… daniel grotti
- Re: R: [Sip] a question about IETF draft location… Hannes Tschofenig
- R: R: [Sip] a question about IETF draft location … daniel grotti
- Re: R: R: [Sip] a question about IETF draft locat… Hannes Tschofenig
- R: R: R: [Sip] a question about IETF draft locati… daniel grotti
- Re: R: R: [Sip] a question about IETF draft locat… Dean Willis
- R: R: R: [Sip] a question about IETF draft locati… daniel grotti
- RE: R: R: [Sip] a question about IETF draft locat… DRAGE, Keith (Keith)
- RE: R: R: [Sip] a question about IETF draft locat… James M. Polk
- Re: R: R: [Sip] a question about IETF draft locat… Matt Lepinski
- Re: R: R: [Sip] a question about IETF draft locat… James M. Polk
- RE: R: R: [Sip] a question about IETF draft locat… Ted Hardie
- Re: R: R: [Sip] a question about IETF draft locat… Ted Hardie
- Re: R: R: [Sip] a question about IETF draft locat… Dean Willis
- Re: R: R: [Sip] a question about IETF draft locat… James M. Polk
- Re: R: [Sip] a question about IETF draft location… James M. Polk
- Re: [Sip] a question about IETF draft location co… James M. Polk
- Re: R: [Sip] a question about IETF draft location… Paul Kyzivat