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

"Richard L. Barnes" <> Mon, 26 July 2010 16:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08FE23A6900 for <>; Mon, 26 Jul 2010 09:07:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id psQCbJZcX7LY for <>; Mon, 26 Jul 2010 09:07:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0C8333A682F for <>; Mon, 26 Jul 2010 09:07:26 -0700 (PDT)
Received: from [] (port=52082 by with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <>) id 1OdQDS-000CDE-F0; Mon, 26 Jul 2010 12:07:47 -0400
Message-Id: <>
From: "Richard L. Barnes" <>
To: Alexander Mayrhofer <>,, Martin Thomson <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="Apple-Mail-7--941930371"
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 26 Jul 2010 18:07:43 +0200
References: <> <> <>
X-Mailer: Apple Mail (2.936)
Subject: Re: [sipcore] geo URI and conveyance: conclusion?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Jul 2010 16:07:33 -0000

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  

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
> _______________________________________________
> sipcore mailing list