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

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

Return-Path: <rbarnes@bbn.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08FE23A6900 for <sipcore@core3.amsl.com>; Mon, 26 Jul 2010 09:07:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psQCbJZcX7LY for <sipcore@core3.amsl.com>; Mon, 26 Jul 2010 09:07:27 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 0C8333A682F for <sipcore@ietf.org>; Mon, 26 Jul 2010 09:07:26 -0700 (PDT)
Received: from [128.89.252.234] (port=52082 helo=dhcp-22e1.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1OdQDS-000CDE-F0; Mon, 26 Jul 2010 12:07:47 -0400
Message-Id: <131C4B82-812A-4193-86A7-0D66900732C6@bbn.com>
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: Alexander Mayrhofer <alexander.mayrhofer@nic.at>, sipcore@ietf.org, Martin Thomson <Martin.Thomson@andrew.com>
In-Reply-To: <3F1B4843-6FB8-40FD-AF4E-3BC8141D12C5@bbn.com>
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: <8B0A9FCBB9832F43971E38010638454F03EB77364D@SISPE7MB1.commscope.com> <8BC845943058D844ABFC73D2220D46650943B104@nics-mail.sbg.nic.at> <3F1B4843-6FB8-40FD-AF4E-3BC8141D12C5@bbn.com>
X-Mailer: Apple Mail (2.936)
Subject: Re: [sipcore] geo URI and conveyance: conclusion?
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=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  
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
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore