Re: [sipcore] geo URI and conveyance: conclusion?
"Thomson, Martin" <Martin.Thomson@andrew.com> Mon, 26 July 2010 16:11 UTC
Return-Path: <Martin.Thomson@andrew.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 A45FC3A6C59 for <sipcore@core3.amsl.com>; Mon, 26 Jul 2010 09:11:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.301
X-Spam-Level:
X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[AWL=-0.703, 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 v23tuG40KSml for <sipcore@core3.amsl.com>; Mon, 26 Jul 2010 09:11:43 -0700 (PDT)
Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 46F913A6C51 for <sipcore@ietf.org>; Mon, 26 Jul 2010 09:11:42 -0700 (PDT)
Received: from [10.86.20.102] ([10.86.20.102]:23463 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S28674315Ab0GZQMC (ORCPT <rfc822; sipcore@ietf.org>); Mon, 26 Jul 2010 11:12:02 -0500
Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 26 Jul 2010 11:10:21 -0500
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 27 Jul 2010 00:10:18 +0800
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: "Richard L. Barnes" <rbarnes@bbn.com>, Alexander Mayrhofer <alexander.mayrhofer@nic.at>, "sipcore@ietf.org" <sipcore@ietf.org>
Date: Tue, 27 Jul 2010 00:12:28 +0800
Thread-Topic: [sipcore] geo URI and conveyance: conclusion?
Thread-Index: Acss3LLetQ0r6p4zRGukfDfE0QrM0wAAIeYw
Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB773653@SISPE7MB1.commscope.com>
References: <8B0A9FCBB9832F43971E38010638454F03EB77364D@SISPE7MB1.commscope.com> <8BC845943058D844ABFC73D2220D46650943B104@nics-mail.sbg.nic.at> <3F1B4843-6FB8-40FD-AF4E-3BC8141D12C5@bbn.com> <131C4B82-812A-4193-86A7-0D66900732C6@bbn.com>
In-Reply-To: <131C4B82-812A-4193-86A7-0D66900732C6@bbn.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_8B0A9FCBB9832F43971E38010638454F03EB773653SISPE7MB1comm_"
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com
X-BCN-Sender: Martin.Thomson@andrew.com
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:11:49 -0000
A pseudonym would suffice for the entity. There is no need to say that the entity identified in the From header is at that location, only that the location is relevant to the request. --Martin From: Richard L. Barnes [mailto:rbarnes@bbn.com] Sent: Monday, 26 July 2010 6:08 PM To: Alexander Mayrhofer; sipcore@ietf.org; Thomson, Martin Subject: Re: [sipcore] geo URI and conveyance: conclusion? 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<mailto:sipcore@ietf.org> https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org<mailto:sipcore@ietf.org> https://www.ietf.org/mailman/listinfo/sipcore
- [sipcore] geo URI and conveyance: conclusion? Thomson, Martin
- Re: [sipcore] geo URI and conveyance: conclusion? Alexander Mayrhofer
- Re: [sipcore] geo URI and conveyance: conclusion? Richard L. Barnes
- Re: [sipcore] geo URI and conveyance: conclusion? Thomson, Martin
- Re: [sipcore] geo URI and conveyance: conclusion? James M. Polk
- Re: [sipcore] geo URI and conveyance: conclusion? Alexander Mayrhofer
- Re: [sipcore] geo URI and conveyance: conclusion? Richard L. Barnes
- Re: [sipcore] geo URI and conveyance: conclusion? James M. Polk
- Re: [sipcore] geo URI and conveyance: conclusion? Richard L. Barnes
- Re: [sipcore] geo URI and conveyance: conclusion? Thomson, Martin
- Re: [sipcore] geo URI and conveyance: conclusion? Adam Roach
- Re: [sipcore] geo URI and conveyance: conclusion? James M. Polk
- Re: [sipcore] geo URI and conveyance: conclusion? Adam Roach