Re: [Sip] a question about IETF draft location conveyance 09

["James M. Polk" <[e-mail]>]

At 03:02 PM 11/21/2007, Ted Hardie wrote:
>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.

Ted -- This header parameter is for a PIDF-LO, yes -- but it pertains 
to the SIP WG's expertise in knowing and agreeing with SIP's ability 
to foresee the type of topology from UAC to UAS, and each server 
(whether there even is one) in between.  I'm not so sure the SIP WG 
agrees that a UAC can make this determination, and am soliciting 
their input here in a broad way.

Can a UAC understand enough about the topology of the Internet to 
understand where it is sending a request, including how SIP servers 
may or may not act upon that request?

I believe, if the answer is no, the the "recipient=" parameter is a 
flawed SIP header parameter.

If the answer is yes, then it stays with no further arguments from me.


> >
> >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.

The above question is what I'll propose to the SIP WG, nothing 
more.  If they ask for an example, I'll give them the Pizza Hut 
example I did on this thread a few messages ago.


>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 : [e-mail]
> >>>>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 [e-mail] for questions on current sip
> >>>>Use [e-mail] 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 [e-mail] for questions on current sip
> >>>Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip