Re: [sipcore] geo URI and conveyance: conclusion?

["Richard L. Barnes" <[e-mail]>]

After chatting with Martin and Alex, here's another possibility:

Clearly, a client that is capable of sending a GEO URI can just as  
well send a PIDF-LO document with the same information (in a lot more  
bits).  So we can view the use of a GEO URI as an optimization, for  
those times when you don't need what PIDF-LO offers.  Given  that  
interpretation, you could basically say "use a GEO URI if you don't  
want any contraints, otherwise generate a PIDF-LO".  Suggested text:
"
Clients embedding location in a SIP message by value typically do so  
by embedding a PIDF-LO message body and adding CID URI to the  
Geolocation header.  In some cases, a location value can be expressed  
much more compactly using a GEO URI [RFC5870], namely when the  
following two conditions apply:
1. The location being expressed is a point (optionally with an  
uncertainty radius), and
2. The client does not wish to express privacy preferences.
When used with the SIP Geolocation header, a GEO URI is equivalent to  
a PIDF-LO document with the following contents:
    o Entity: From address of SIP message
    o Location information: Point or circle equivalent to GEO URI (see  
[RFC5870] for translation)
    o Privacy rules:
       o retransmission-allowed: true
       o retention-expiry: unlimited (any date very far in the future)
       o ruleset-reference: null
       o note-well: null
A client that wishes to express more restrictive privacy rules than  
these defaults should create a PIDF-LO document encoding these rules,  
and include the PIDF-LO document in the SIP message (rather than a GEO  
URI).
"




On Jul 26, 2010, at 4:27 PM, Richard L. Barnes wrote:

> I was afraid that Alex would notice :)
>
> The concern here is about privacy, since the geo URI scheme doesn't  
> include GEOPRIV-like rules.  In fact, the privacy part of RFC 5870  
> has the following text:
> "
> However, if a 'geo' URI is used in a context where it identifies the  
> location of a Target, it becomes part of a Location Object and is  
> therefore subject to GEOPRIV rules. Therefore, when 'geo' URIs are  
> put into such contexts, the privacy requirements of RFC 3693 MUST be  
> met.
> "
>
> So in order to use a geo URI in SIP, we would need to do something  
> about privacy rules.  The only easy approach that occurs to me is to  
> specify fixed rules that come along with putting a GEO URI in a  
> Geolocation header.  Suggested text:
> "
> Including a "geo:" URI in a Geolocation header associates that  
> location with the entity that originated the SIP message, making it  
> in effect a Location Object in the terms of RFC 3693. In particular,  
> there is a need for such location objects to have privacy rules that  
> accompany the object.  A "geo:" URI in a Geolocation header is  
> assigned a default set of privacy rules, equivalent to the default  
> rules in RFC 4119:
>   o retransmission-allowed: false
>   o retention-expires: 24 hours from time of transmission
>   o ruleset-reference: null
>   o note-well: null
> "
>
>
>
> On Jul 26, 2010, at 4:05 PM, Alexander Mayrhofer wrote:
>
>>> I missed the conclusions regarding geo URI.  I got the bit
>>> where we decided that we needed to have _some_ text, but I'm
>>> not sure what we decided what the text might look like.
>>
>> Adding "geo:" to SIP Location Conveyance was actually one of the  
>> first
>> applications that came to my mind when i started the draft. I'm more
>> than happy to help with the text - i'm in Maastricht for the whole  
>> week
>> for face to face discussions.
>>
>> Alex
>> _______________________________________________
>> sipcore mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore