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

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

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.

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.

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)?

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.


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

I don't see the text giving an exemption in the emergency case, not 
at least in this doc.


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

>                                 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