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

[Ted Hardie <[e-mail]>]

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.

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

			


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