From robinsg@huawei.com Thu Jul 1 02:21:19 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65AF13A6860 for ; Thu, 1 Jul 2010 02:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.721 X-Spam-Level: X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 FpbkmS8ZKtDT for ; Thu, 1 Jul 2010 02:21:14 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 222DA3A68AA for ; Thu, 1 Jul 2010 02:21:13 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4V00MZRGNDG8@szxga02-in.huawei.com> for geopriv@ietf.org; Thu, 01 Jul 2010 17:21:14 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4V00EL1GND9Q@szxga02-in.huawei.com> for geopriv@ietf.org; Thu, 01 Jul 2010 17:21:13 +0800 (CST) Received: from [10.70.109.60] by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L4V00FEPGND9R@szxml04-in.huawei.com> for geopriv@ietf.org; Thu, 01 Jul 2010 17:21:13 +0800 (CST) Date: Thu, 01 Jul 2010 17:21:13 +0800 From: Robins George To: geopriv@ietf.org Message-id: <4C2C5E09.4090907@huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Y6/nMTWDAVJUmy9VF2I7Jw)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 Subject: [Geopriv] Fwd: I-D Action:draft-george-geopriv-lamp-post-00.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robinsg@huawei.com List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 09:21:19 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Y6/nMTWDAVJUmy9VF2I7Jw) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT The ECRIT WG believes, GEO-PRIV WG would be more appropriate to discuss this draft [1], by considering the previous discussions happened in the GEO-PRIV mailing list. More over, draft is talking about location information. Will everyone please give this draft a review, and post comments, questions, and suggested changes? [1] - draft-george-ecrit-lamp-post-02 - robins. -------- Original Message -------- Subject: I-D Action:draft-george-geopriv-lamp-post-00.txt Date: Thu, 01 Jul 2010 02:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Civic Location Format Extension for Utility and Lamp Post Numbers Author(s) : R. George, et al. Filename : draft-george-geopriv-lamp-post-00.txt Pages : 6 Date : 2010-07-01 This document describes an extension to civic location format and adds two new CAtypes: PN (pole number) and MP (milepost). Pole Numbers are used on poles such as lamp posts or utility poles, and can be used in some circumstances as location information. Mileposts are numeric values measured from an end of a trail, road, railway line or other feature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-george-geopriv-lamp-post-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Boundary_(ID_Y6/nMTWDAVJUmy9VF2I7Jw) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT
The ECRIT WG believes, GEO-PRIV WG would be more appropriate to discuss this draft [1], by considering the previous discussions happened in the GEO-PRIV mailing list. More over, draft is talking about location information.

Will everyone please give this draft a review, and post comments, questions, and suggested changes?  

[1] - draft-george-ecrit-lamp-post-02

- robins.



-------- Original Message --------
Subject: I-D Action:draft-george-geopriv-lamp-post-00.txt
Date: Thu, 01 Jul 2010 02:15:02 -0700 (PDT)
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Civic Location Format Extension for Utility and Lamp Post Numbers
	Author(s)       : R. George, et al.
	Filename        : draft-george-geopriv-lamp-post-00.txt
	Pages           : 6
	Date            : 2010-07-01

This document describes an extension to civic location format and
adds two new CAtypes: PN (pole number) and MP (milepost).  Pole
Numbers are used on poles such as lamp posts or utility poles, and
can be used in some circumstances as location information.  Mileposts
are numeric values measured from an end of a trail, road, railway
line or other feature.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-george-geopriv-lamp-post-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--Boundary_(ID_Y6/nMTWDAVJUmy9VF2I7Jw)-- From mccann.stephen@gmail.com Thu Jul 1 04:53:28 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE02C3A68D5 for ; Thu, 1 Jul 2010 04:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.844 X-Spam-Level: X-Spam-Status: No, score=-0.844 tagged_above=-999 required=5 tests=[AWL=-1.259, BAYES_40=-0.185, J_CHICKENPOX_56=0.6] 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 0Gg+A9k4nNOD for ; Thu, 1 Jul 2010 04:53:27 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 90F5A3A684B for ; Thu, 1 Jul 2010 04:53:27 -0700 (PDT) Received: by bwz7 with SMTP id 7so1052574bwz.31 for ; Thu, 01 Jul 2010 04:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=oGzQN4MfBgPtrDg+qYhIz85MPvTg6PxJtD8cZVTpekw=; b=T4Vi3fXcnscJkDCh2E//dkh6ow9keLRm9CuW4VxPjdCzHo0GV/mNLRJz/zdUEqdLbI 9BuRlmvpclhhPhMGPmxGIl+27oHMMG+QP1uP8j3alCk2S+A3SHBtroy412gmDR3KhfKE TxqQIYaPeE5oxldMI1mDyGtBpbTlTT6VNXbio= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tBhBcCzLZRB0SaeDMErEB1uTHfCpJVg9zOfCYxua+28XgH3NzDIZJSgvuApK7/Y6az psSTRXQCYMym0I8XC+9oNO/W2FkjXcvnto8Xi9a2y7GXlN6gWHwjQ39M9JM2NtM2ZpY4 PZoJ7DHcLuHDVf7s79oq7NjV6tdusi8AGwrHs= MIME-Version: 1.0 Received: by 10.204.18.75 with SMTP id v11mr7060186bka.62.1277985215386; Thu, 01 Jul 2010 04:53:35 -0700 (PDT) Received: by 10.204.65.68 with HTTP; Thu, 1 Jul 2010 04:53:35 -0700 (PDT) In-Reply-To: <5377BCAA-26AD-4E82-9703-1AF5148CBD7A@bbn.com> References: <5377BCAA-26AD-4E82-9703-1AF5148CBD7A@bbn.com> Date: Thu, 1 Jul 2010 12:53:35 +0100 Message-ID: From: Stephen McCann To: "Richard L. Barnes" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: geopriv@ietf.org, loc-imp@googlegroups.com Subject: Re: [Geopriv] HELD in Firefox X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 11:53:28 -0000 Richard, Is there any chance of a quick demo in Maastricht, please? Kind regards Stephen On 30 June 2010 19:50, Richard L. Barnes wrote: > An FYI on implementation: > > The first pre-beta version of Firefox 4.0, released today, includes a > minimal version of HELD, as a location provider for the W3C Geolocation A= PI. > =A0The profile of HELD implemented is as follows: > -- Requests have no , but they do have a obj= ect > with a set of WiFi measurements > -- The only responses that are used are ones that contain a , > representing a point with an uncertainty radius. > -- Civic addresses and location URIs are not used. > > HELD is not enabled by defuault. =A0To use it: > 1. Open about:config > 2. Set geo.wifi.protocol =3D 1 > 3. Set geo.wifi.uri to the URI of a HELD server. =A0For testing, I have b= een > using , which proxies > requests through to the Google location server. > > Once this is set up, queries to the W3C Geolocation API should initiate a > HELD query to the specified server. > > You can download the pre-release builds here: > > > Finally, of course, this being pre-beta software, there's a minor bug to > fix. =A0Inside the 'components' directory for Firefox, find > NetworkGeolocationProvider.js, and change line 354 from this: > =A0 =A0 =A0 =A0 =A0 =A0switch (this.protocol) { > to this: > =A0 =A0 =A0 =A0 =A0 =A0switch (protocol) { > Everything should of course work perfectly :) > > --Richard > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > From acooper@cdt.org Fri Jul 2 02:34:57 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92F813A692E for ; Fri, 2 Jul 2010 02:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=0.581, BAYES_00=-2.599] 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 QKPnkEm+v9eT for ; Fri, 2 Jul 2010 02:34:56 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 2E1313A6902 for ; Fri, 2 Jul 2010 02:34:56 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for geopriv@ietf.org; Fri, 2 Jul 2010 05:35:05 -0400 Message-Id: <2DA192FC-336B-4B3A-B80D-AB762094C2E0@cdt.org> From: Alissa Cooper To: geopriv@ietf.org In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 2 Jul 2010 10:33:57 +0100 References: X-Mailer: Apple Mail (2.936) Subject: Re: [Geopriv] Call for consensus: WG item adoption X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 09:34:57 -0000 Thanks all for responding. It looks like we have pretty clear consensus to adopt all three as WG items and keep the work going on them, so that's what we'll do. Alissa On Jun 22, 2010, at 12:46 PM, Alissa Cooper wrote: > Since we've progressed a number of WG items recently, we have space > in our queue for some new ones. I'd like to make a call for > consensus about adopting the following three documents as GEOPRIV > work items: > > 1) draft-thomson-geopriv-relative-location-01 > 2) draft-thomson-geopriv-held-measurements-06 > 3) draft-winterbottom-geopriv-deref-protocol-03 > > These were all among the documents that received expressions of > support from the working group at IETF 77 [1]. The top two have been > recently revised to address feedback from the meeting, the list, and > design team work. > > Please send your responses about each document to the list no later > than Monday, June 28. > > Alissa > > [1] http://www.ietf.org/mail-archive/web/geopriv/current/msg08428.html > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > From James.Winterbottom@andrew.com Fri Jul 2 03:42:08 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6252F3A67EE for ; Fri, 2 Jul 2010 03:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] 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 gaafEzYxcUKE for ; Fri, 2 Jul 2010 03:42:07 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 82D093A67E9 for ; Fri, 2 Jul 2010 03:42:07 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:13515 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S282341Ab0GBKmT convert rfc822-to-8bit (ORCPT ); Fri, 2 Jul 2010 05:42:19 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Fri, 2 Jul 2010 05:42:18 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 2 Jul 2010 18:42:16 +0800 From: "Winterbottom, James" To: Alissa Cooper , "geopriv@ietf.org" Date: Fri, 2 Jul 2010 18:42:02 +0800 Thread-Topic: [Geopriv] Call for consensus: WG item adoption Thread-Index: AcsZyeAawxQy0mRjRGS8lDkrB8tE0AACVTrS Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120E7AE3DBD@SISPE7MB1.commscope.com> References: , <2DA192FC-336B-4B3A-B80D-AB762094C2E0@cdt.org> In-Reply-To: <2DA192FC-336B-4B3A-B80D-AB762094C2E0@cdt.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [Geopriv] Call for consensus: WG item adoption X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 10:42:08 -0000 Thanks Alissa. ________________________________________ From: geopriv-bounces@ietf.org [geopriv-bounces@ietf.org] On Behalf Of Alissa Cooper [acooper@cdt.org] Sent: Friday, July 02, 2010 4:33 AM To: geopriv@ietf.org Subject: Re: [Geopriv] Call for consensus: WG item adoption Thanks all for responding. It looks like we have pretty clear consensus to adopt all three as WG items and keep the work going on them, so that's what we'll do. Alissa On Jun 22, 2010, at 12:46 PM, Alissa Cooper wrote: > Since we've progressed a number of WG items recently, we have space > in our queue for some new ones. I'd like to make a call for > consensus about adopting the following three documents as GEOPRIV > work items: > > 1) draft-thomson-geopriv-relative-location-01 > 2) draft-thomson-geopriv-held-measurements-06 > 3) draft-winterbottom-geopriv-deref-protocol-03 > > These were all among the documents that received expressions of > support from the working group at IETF 77 [1]. The top two have been > recently revised to address feedback from the meeting, the list, and > design team work. > > Please send your responses about each document to the list no later > than Monday, June 28. > > Alissa > > [1] http://www.ietf.org/mail-archive/web/geopriv/current/msg08428.html > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv From creed@opengeospatial.org Sat Jul 3 12:37:04 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23423A68B5 for ; Sat, 3 Jul 2010 12:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 IyCz+Cssgnlz for ; Sat, 3 Jul 2010 12:37:03 -0700 (PDT) Received: from mail.opengeospatial.org (mail.opengeospatial.org [66.244.86.40]) by core3.amsl.com (Postfix) with ESMTP id 6CE703A68A5 for ; Sat, 3 Jul 2010 12:37:03 -0700 (PDT) Received: from creedPC (m3c2336d0.tmodns.net [208.54.35.60]) (authenticated bits=0) by mail.opengeospatial.org (8.13.8/8.13.8/Debian-3+etch1) with ESMTP id o63JaalO001656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 3 Jul 2010 15:36:38 -0400 Message-ID: <36C28078E8E347DC9E8EDC7901FE7CF3@creedPC> From: "Carl Reed" To: , References: <4C2C5E09.4090907@huawei.com> In-Reply-To: <4C2C5E09.4090907@huawei.com> Date: Sat, 3 Jul 2010 13:36:35 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0183_01CB1AB4.C1AEE090" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6001.18000 x-mimeole: Produced By Microsoft MimeOLE V6.0.6001.18049 X-Virus-Scanned: clamav-milter 0.95.3 at mail X-Virus-Status: Clean Subject: Re: [Geopriv] Fwd: I-D Action:draft-george-geopriv-lamp-post-00.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 19:37:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0183_01CB1AB4.C1AEE090 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Robins - I would suggest adding some clauses stating that MP shall be used in = conjunction with RD or some other feature type that references a linear = feature, such as a stream, road, or trail. A mile marker/post means = nothing unless there is a reference feature. Also, there are often rules = regarding from which "end" of the feature the marker is calculated from. = Not sure if this information needs to also be encoded. Perhaps worth = some discussion. Finally, the mile market issue was intensely discussed = in the NENA Next Generation Data Working Group. This discussion was part = of the larger addressing standards discussion. Unfortunately, I cannot = remember the outcome :-( but we can find out. Also, for those interested, there is an ISO standard for an abstract = model for linear referencing (ISO 19148). Regards Carl Reed CTO OGC ----- Original Message -----=20 From: Robins George=20 To: geopriv@ietf.org=20 Sent: Thursday, July 01, 2010 3:21 AM Subject: [Geopriv] Fwd: I-D = Action:draft-george-geopriv-lamp-post-00.txt The ECRIT WG believes, GEO-PRIV WG would be more appropriate to = discuss this draft [1], by considering the previous discussions happened = in the GEO-PRIV mailing list. More over, draft is talking about location = information. Will everyone please give this draft a review, and post comments, = questions, and suggested changes? =20 [1] - draft-george-ecrit-lamp-post-02 - robins. -------- Original Message -------- Subject: I-D = Action:draft-george-geopriv-lamp-post-00.txt=20 Date: Thu, 01 Jul 2010 02:15:02 -0700 (PDT)=20 From: Internet-Drafts@ietf.org=20 Reply-To: internet-drafts@ietf.org=20 To: i-d-announce@ietf.org=20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Civic Location Format Extension for Utility and Lamp = Post Numbers Author(s) : R. George, et al. Filename : draft-george-geopriv-lamp-post-00.txt Pages : 6 Date : 2010-07-01 This document describes an extension to civic location format and adds two new CAtypes: PN (pole number) and MP (milepost). Pole Numbers are used on poles such as lamp posts or utility poles, and can be used in some circumstances as location information. Mileposts are numeric values measured from an end of a trail, road, railway line or other feature. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-george-geopriv-lamp-post-00.txt= Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -------------------------------------------------------------------------= ----- _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www.ietf.org/mailman/listinfo/geopriv ------=_NextPart_000_0183_01CB1AB4.C1AEE090 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Robins -
 
I would suggest adding some clauses = stating that MP=20 shall be used in conjunction with RD or some other feature type that = references=20 a linear feature, such as a stream, road, or trail. A mile marker/post = means=20 nothing unless there is a reference feature. Also, there are = often=20 rules regarding from which "end" of the feature the marker is calculated = from.=20 Not sure if this information needs to also be encoded. Perhaps worth = some=20 discussion. Finally, the mile market issue was intensely discussed in = the NENA=20 Next Generation Data Working Group. This discussion was part of the = larger=20 addressing standards discussion. Unfortunately, I cannot remember the = outcome=20 :-( but we can find out.
 
Also, for those interested, there is an = ISO=20 standard for an abstract model for linear referencing (ISO = 19148).
 
Regards

Carl Reed
CTO
OGC
----- Original Message -----
From:=20 Robins George=20
Sent: Thursday, July 01, 2010 = 3:21=20 AM
Subject: [Geopriv] Fwd: I-D=20 Action:draft-george-geopriv-lamp-post-00.txt


The ECRIT WG believes, GEO-PRIV WG would be more=20 appropriate to discuss this draft [1], by considering the previous = discussions=20 happened in the GEO-PRIV mailing list. More over, draft is talking = about=20 location information.

Will everyone please give this draft a = review,=20 and post comments, questions, and suggested changes?  

[1] = -=20 draft-george-ecrit-lamp-post-02

- = robins.



--------=20 Original Message --------=20 =
Subject: I-D Action:draft-george-geopriv-lamp-post-00.txt
Date: Thu, 01 Jul 2010 02:15:02 -0700 (PDT)
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org


A New Internet-Draft is available from the =
on-line Internet-Drafts directories.

	Title           : Civic Location Format Extension for Utility and Lamp =
Post Numbers
	Author(s)       : R. George, et al.
	Filename        : draft-george-geopriv-lamp-post-00.txt
	Pages           : 6
	Date            : 2010-07-01

This document describes an extension to civic location format and
adds two new CAtypes: PN (pole number) and MP (milepost).  Pole
Numbers are used on poles such as lamp posts or utility poles, and
can be used in some circumstances as location information.  Mileposts
are numeric values measured from an end of a trail, road, railway
line or other feature.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-george-geopriv-lamp-p=
ost-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-=
drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_______________________________________________
Geopriv = mailing=20 = list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv=
------=_NextPart_000_0183_01CB1AB4.C1AEE090-- From br@brianrosen.net Sat Jul 3 13:53:40 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94AB73A67F1 for ; Sat, 3 Jul 2010 13:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 JqwOaLwQuiri for ; Sat, 3 Jul 2010 13:53:34 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [70.87.156.98]) by core3.amsl.com (Postfix) with ESMTP id 3849C3A67B8 for ; Sat, 3 Jul 2010 13:53:31 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.15]) by ebru.winwebhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OV9i9-0004rB-Sg; Sat, 03 Jul 2010 15:53:23 -0500 Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: multipart/alternative; boundary=Apple-Mail-1--764512556 From: Brian Rosen X-Priority: 3 In-Reply-To: <36C28078E8E347DC9E8EDC7901FE7CF3@creedPC> Date: Sat, 3 Jul 2010 16:53:18 -0400 Message-Id: <917C86FD-5CF8-42D8-AF6C-18339497D1FA@brianrosen.net> References: <4C2C5E09.4090907@huawei.com> <36C28078E8E347DC9E8EDC7901FE7CF3@creedPC> To: Carl Reed X-Mailer: Apple Mail (2.1075.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: geopriv@ietf.org Subject: Re: [Geopriv] Fwd: I-D Action:draft-george-geopriv-lamp-post-00.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 20:53:40 -0000 --Apple-Mail-1--764512556 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes I am a co-author on this draft, and the milepost addition to the lamp post original was motivated by the NENA requirement to have a milepost. I agree that the MP nearly always needs a road name. So does a house number. The current documents don't have requirements like that, primarily because we keep finding odd cases that don't meet what we thought was a simple rule. Brian On Jul 3, 2010, at 3:36 PM, Carl Reed wrote: > Robins - > > I would suggest adding some clauses stating that MP shall be used in > conjunction with RD or some other feature type that references a > linear feature, such as a stream, road, or trail. A mile marker/post > means nothing unless there is a reference feature. Also, there are > often rules regarding from which "end" of the feature the marker is > calculated from. Not sure if this information needs to also be > encoded. Perhaps worth some discussion. Finally, the mile market > issue was intensely discussed in the NENA Next Generation Data > Working Group. This discussion was part of the larger addressing > standards discussion. Unfortunately, I cannot remember the outcome :- > ( but we can find out. > > Also, for those interested, there is an ISO standard for an abstract > model for linear referencing (ISO 19148). > > Regards > > Carl Reed > CTO > OGC > ----- Original Message ----- > From: Robins George > To: geopriv@ietf.org > Sent: Thursday, July 01, 2010 3:21 AM > Subject: [Geopriv] Fwd: I-D Action:draft-george-geopriv-lamp- > post-00.txt > > > The ECRIT WG believes, GEO-PRIV WG would be more appropriate to > discuss this draft [1], by considering the previous discussions > happened in the GEO-PRIV mailing list. More over, draft is talking > about location information. > > Will everyone please give this draft a review, and post comments, > questions, and suggested changes? > > [1] - draft-george-ecrit-lamp-post-02 > > - robins. > > > > -------- Original Message -------- > Subject: I-D Action:draft-george-geopriv-lamp-post-00.txt > Date: Thu, 01 Jul 2010 02:15:02 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Civic Location Format Extension for Utility and > Lamp Post Numbers > Author(s) : R. George, et al. > Filename : draft-george-geopriv-lamp-post-00.txt > Pages : 6 > Date : 2010-07-01 > > This document describes an extension to civic location format and > adds two new CAtypes: PN (pole number) and MP (milepost). Pole > Numbers are used on poles such as lamp posts or utility poles, and > can be used in some circumstances as location information. Mileposts > are numeric values measured from an end of a trail, road, railway > line or other feature. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-george-geopriv-lamp-post-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv --Apple-Mail-1--764512556 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I am a co-author on this draft, and the milepost = addition to the lamp post original was motivated by the NENA requirement = to have a milepost.

I agree that the MP nearly always = needs a road name.  So does a house number.  The current = documents don't have requirements like that, primarily because we keep = finding odd cases that don't meet what we thought was a simple = rule.

Brian
On Jul 3, 2010, at = 3:36 PM, Carl Reed wrote:

Robins = -
 
I = would suggest adding some clauses stating that MP shall be used in = conjunction with RD or some other feature type that references a linear = feature, such as a stream, road, or trail. A mile marker/post means = nothing unless there is a reference feature. Also, there are = often rules regarding from which "end" of the feature the marker is = calculated from. Not sure if this information needs to also be encoded. = Perhaps worth some discussion. Finally, the mile market issue was = intensely discussed in the NENA Next Generation Data Working Group. This = discussion was part of the larger addressing standards discussion. = Unfortunately, I cannot remember the outcome :-( but we can find = out.
 
Also, = for those interested, there is an ISO standard for an abstract model for = linear referencing (ISO 19148).
 
Regards

Carl Reed
CTO
OGC
----- Original Message = -----
 Thursday,= July 01, 2010 3:21 AM
Subject: [Geopriv] Fwd: I-D = Action:draft-george-geopriv-lamp-post-00.txt


The = ECRIT WG believes, GEO-PRIV WG would be more appropriate to discuss this = draft [1], by considering the previous discussions happened in the = GEO-PRIV mailing list. More over, draft is talking about location = information.

Will everyone please give this draft a review, and = post comments, questions, and suggested changes?  

[1] - = draft-george-ecrit-lamp-post-02

- robins.



-------- = Original Message --------= = <= /tbody>
Subject:I-D = Action:draft-george-geopriv-lamp-post-00.txt
Date:Thu, 01 = Jul 2010 02:15:02 -0700 (PDT)
From:Internet-Drafts@ietf.org
Reply-To:internet-drafts@ietf.org
To:i-d-announce@ietf.org


A New Internet-Draft is available from the =
on-line Internet-Drafts directories.

	Title           : Civic Location Format Extension for Utility =
and Lamp Post Numbers
	Author(s)       : R. George, et al.
	Filename        : draft-george-geopriv-lamp-post-00.txt
	Pages           : 6
	Date            : 2010-07-01

This document describes an extension to civic location format and
adds two new CAtypes: PN (pole number) and MP (milepost).  Pole
Numbers are used on poles such as lamp posts or utility poles, and
can be used in some circumstances as location information.  Mileposts
are numeric values measured from an end of a trail, road, railway
line or other feature.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-george-geopriv-lamp-pos=
t-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-d=
rafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.




_________________________________= ______________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.or= g/mailman/listinfo/geopriv
___________________________= ____________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.or= g/mailman/listinfo/geopriv

= --Apple-Mail-1--764512556-- From thompson@ieee.org Sun Jul 4 12:45:17 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45FCC3A68A4 for ; Sun, 4 Jul 2010 12:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.998 X-Spam-Level: X-Spam-Status: No, score=-99.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] 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 FGAugonakXzK for ; Sun, 4 Jul 2010 12:45:16 -0700 (PDT) Received: from smtp102.prem.mail.sp1.yahoo.com (smtp102.prem.mail.sp1.yahoo.com [98.136.44.57]) by core3.amsl.com (Postfix) with SMTP id 93BCE3A6834 for ; Sun, 4 Jul 2010 12:45:16 -0700 (PDT) Received: (qmail 21857 invoked from network); 4 Jul 2010 19:45:14 -0000 Received: from geoff-thompsons-macbook-2.local (thompson@64.9.238.93 with plain) by smtp102.prem.mail.sp1.yahoo.com with SMTP; 04 Jul 2010 12:45:14 -0700 PDT X-Yahoo-SMTP: QyU90.qswBBpdAOL14e1mfwUogr5DY5wzs_aWTD7HWypLbttNQmnq7k- X-YMail-OSG: f6JDrEQVM1kpR0I3AP6uZrVZlHypMvW3mznah3zbB8VE3sh Zj2Rm7ar8L1ckyDhuKLtP1rc0G5RmW0F5_.3ubVxLXjmC47KFbsmv7viAKsd tpC2J4x06j7L0dCa0ZbUP0Rp0oCdpQNZRERAyyYqnHmvGzGHK.UEY9E8tSF2 Ln.3xVU63w84jtLn82.PN9.AzXtNt6reusOE8RXkz320WHbEVhpcIDg6c15x C8a.eV2AQfizLhm_G.Hph5QqPAuBz3vU0P3KWpbQ_Ri5r5iTWfEjV7iwhv72 9 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C30E4C9.1010006@ieee.org> Date: Sun, 04 Jul 2010 12:45:13 -0700 From: Geoff Thompson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: geopriv@ietf.org, Brian Rosen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Geoff Thompson Subject: Re: [Geopriv] I-D, Action:draft-george-geopriv-lamp-post-00.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: thompson@ieee.org List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2010 19:45:17 -0000 Brian- It seems lik a bad idea to let perfectly good assumptions (like a MP or a house number "needs" a road name) get screwed up by unusual exception as you have noted. Why not, instead, just charge ahead but allow a special value of road name ("NULL" ?) that notes that in this case it is known that a road name does not exist? The entered value should probably be differentiated from that which would be provided if the value of road name were "unknown". Geoff > Message: 2 > Date: Sat, 3 Jul 2010 16:53:18 -0400 > From: Brian Rosen > Subject: Re: [Geopriv] Fwd: I-D > Action:draft-george-geopriv-lamp-post-00.txt > To: Carl Reed > Cc: geopriv@ietf.org > Message-ID:<917C86FD-5CF8-42D8-AF6C-18339497D1FA@brianrosen.net> > Content-Type: text/plain; charset="us-ascii"; Format="flowed"; > DelSp="yes" > > I am a co-author on this draft, and the milepost addition to the lamp > post original was motivated by the NENA requirement to have a milepost. > > I agree that the MP nearly always needs a road name. So does a house > number. The current documents don't have requirements like that, > primarily because we keep finding odd cases that don't meet what we > thought was a simple rule. > > Brian From br@brianrosen.net Sun Jul 4 15:23:12 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4BD3A6403 for ; Sun, 4 Jul 2010 15:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] 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 HcCojKBIOruL for ; Sun, 4 Jul 2010 15:23:12 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [70.87.156.98]) by core3.amsl.com (Postfix) with ESMTP id F29303A6359 for ; Sun, 4 Jul 2010 15:23:11 -0700 (PDT) Received: from [209.173.57.233] (helo=[192.168.130.14]) by ebru.winwebhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1OVXaa-0002qw-TX; Sun, 04 Jul 2010 17:23:05 -0500 Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Brian Rosen In-Reply-To: <4C30E4C9.1010006@ieee.org> Date: Sun, 4 Jul 2010 18:23:06 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <4C30E4C9.1010006@ieee.org> To: thompson@ieee.org X-Mailer: Apple Mail (2.1075.2) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: geopriv@ietf.org Subject: Re: [Geopriv] I-D, Action:draft-george-geopriv-lamp-post-00.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2010 22:23:12 -0000 While I do want to change the basic way the PIDF schema is defined, enforcing a restriction in the schema seems like a poor choice. I am loth to define a null road name; that's a big change to the way PIDF works; if you don't have an element, you don't include it, rather than include it with a null value. I'll ask around the PIDF cognoscenti to see what they think. Brian On Jul 4, 2010, at 3:45 PM, Geoff Thompson wrote: > Brian- > It seems lik a bad idea to let perfectly good assumptions (like a MP > or a house number "needs" a road name) get screwed up by unusual > exception as you have noted. > > Why not, instead, just charge ahead but allow a special value of > road name ("NULL" ?) that notes that in this case it is known that a > road name does not exist? The entered value should probably be > differentiated from that which would be provided if the value of > road name were "unknown". > > Geoff >> Message: 2 >> Date: Sat, 3 Jul 2010 16:53:18 -0400 >> From: Brian Rosen >> Subject: Re: [Geopriv] Fwd: I-D >> Action:draft-george-geopriv-lamp-post-00.txt >> To: Carl Reed >> Cc: geopriv@ietf.org >> Message-ID:<917C86FD-5CF8-42D8-AF6C-18339497D1FA@brianrosen.net> >> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; >> DelSp="yes" >> >> I am a co-author on this draft, and the milepost addition to the lamp >> post original was motivated by the NENA requirement to have a >> milepost. >> >> I agree that the MP nearly always needs a road name. So does a house >> number. The current documents don't have requirements like that, >> primarily because we keep finding odd cases that don't meet what we >> thought was a simple rule. >> >> Brian From Martin.Thomson@andrew.com Sun Jul 4 23:35:40 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6DC83A68E1 for ; Sun, 4 Jul 2010 23:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, GB_I_LETTER=-2] 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 AwqoTvg6Viab for ; Sun, 4 Jul 2010 23:35:39 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 0D26B3A68CF for ; Sun, 4 Jul 2010 23:35:39 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:32218 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S333348Ab0GEGfj (ORCPT ); Mon, 5 Jul 2010 01:35:39 -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, 5 Jul 2010 01:35:39 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Mon, 5 Jul 2010 14:35:38 +0800 From: "Thomson, Martin" To: Brian Rosen , "thompson@ieee.org" Date: Mon, 5 Jul 2010 14:37:41 +0800 Thread-Topic: [Geopriv] I-D, Action:draft-george-geopriv-lamp-post-00.txt Thread-Index: Acsbx4DM8q39KaawQcaQ3kvrNa829QAQlKmA Message-ID: <8B0A9FCBB9832F43971E38010638454F03E9DCC79E@SISPE7MB1.commscope.com> References: <4C30E4C9.1010006@ieee.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "geopriv@ietf.org" Subject: Re: [Geopriv] I-D, Action:draft-george-geopriv-lamp-post-00.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 06:35:40 -0000 VGhpcyBwcm9ibGVtIGlzIG5vdCBqdXN0IGxpbWl0ZWQgdG8gdGhlc2UgY29udmVudGlvbnMgZm9y IHRob3JvdWdoZmFyZXMuICBUaGUgaW50ZXJwcmV0YXRpb24gb2YgbWFueSBwYXJ0cyBvZiBhIGNp dmljIGFkZHJlc3MgcmVseSBvbiB0aGUgY29udGV4dCBwcm92aWRlZCBieSBvdGhlciBlbGVtZW50 cy4NCg0KVGhlIHNvbHV0aW9uIGlzIHJlYWxseSBzaW1wbGUuICBEb24ndCBvbWl0IHVzZWZ1bCBz dHVmZi4NCg0KQSBwb3N0YWwgd29ya2VyIHRoYXQgcmVjZWl2ZXMgYSBsZXR0ZXIgYWRkcmVzc2Vk IHRvICIxNjAwIChhYnNlbnQpIEF2ZW51ZSIgaXMgd2VsbC1qdXN0aWZpZWQgaWYgc2hlIGRlY2lk ZXMgdGhhdCBzaGUgaXMgbm90IGdvaW5nIHRvIGRlbGl2ZXIgdGhlIGxldHRlciBbMV0uICANCg0K SWYgeW91IHdhbnQgdG8gZW5zdXJlIHRoYXQgdGhlIGxldHRlciBnZXRzIGRlbGl2ZXJlZCwgeW91 IHB1dCB0aGUgcmVzdCBvZiB0aGUgYWRkcmVzcyBpbi4gIE5vIGRpZmZlcmVudCBoZXJlLiAgDQoN CkFueSBzeXN0ZW0gb2YgY29uc3RyYWludHMgaXMgbGlrZWx5IHRvIGZhaWwgaW50ZXJuYXRpb25h bGx5Lg0KDQpNYWtpbmcgaG91c2UgbnVtYmVyIHJlbGF0aXZlIHRvIHRoZSB0aG9yb3VnaGZhcmUg aXMgbm90IHBvc3NpYmxlLiAgVGhlcmUgaXMgdGhlIHRob3JvdWdoZmFyZSBicmFuY2hpbmcgd2Ug ZW5jb3VudGVyZWQsIHdoaWNoIHdvdWxkIGNvbXBsaWNhdGUgaXQuICBUaGUgcGVyZmVjdGx5IGxv Z2ljYWwgbnVtYmVyaW5nIHN5c3RlbSBlbXBsb3llZCBieSB0aGUgSmFwYW5lc2UgZm9yIGhvdXNl IG51bWJlcmluZywgd2hpY2ggaXMgcmVsYXRpdmUgdG8gdGhlIGJsb2NrIFsxXSwgd291bGQgbWFr ZSBpdCBldmVuIG1vcmUgZGlmZmljdWx0IHRvIGNvZGlmeS4NCg0KLS1NYXJ0aW4NCg0KWzFdIE5v IGFsbG93YW5jZXMgbWFkZSBmb3Igb3Zlcmx5IHplYWxvdXMgcG9zdGllcyB3aG8ga25vdyB0aGF0 IHRoZXJlIGlzIG9ubHkgb25lIDE2MDAgb24gYW4gQXZlbnVlIGluIHRoZSBjaXR5IGFuZCBkZWxp dmVyIHRoZSBsZXR0ZXIgYW55d2F5Lg0KDQpbMl0gaHR0cDovL2VuLndpa2lwZWRpYS5vcmcvd2lr aS9Ib3VzZV9udW1iZXJpbmcjSmFwYW5fYW5kX0tvcmVhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogZ2VvcHJpdi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Z2VvcHJp di1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgQnJpYW4gUm9zZW4NCj4gU2VudDog TW9uZGF5LCA1IEp1bHkgMjAxMCA4OjIzIEFNDQo+IFRvOiB0aG9tcHNvbkBpZWVlLm9yZw0KPiBD YzogZ2VvcHJpdkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0dlb3ByaXZdIEktRCwgQWN0aW9u OmRyYWZ0LWdlb3JnZS1nZW9wcml2LWxhbXAtcG9zdC0NCj4gMDAudHh0DQo+IA0KPiBXaGlsZSBJ IGRvIHdhbnQgdG8gY2hhbmdlIHRoZSBiYXNpYyB3YXkgdGhlIFBJREYgc2NoZW1hIGlzIGRlZmlu ZWQsDQo+IGVuZm9yY2luZyBhIHJlc3RyaWN0aW9uIGluIHRoZSBzY2hlbWEgc2VlbXMgbGlrZSBh IHBvb3IgY2hvaWNlLiAgIEkgYW0NCj4gbG90aCB0byBkZWZpbmUgYSBudWxsIHJvYWQgbmFtZTsg dGhhdCdzIGEgYmlnIGNoYW5nZSB0byB0aGUgd2F5IFBJREYNCj4gd29ya3M7IGlmIHlvdSBkb24n dCBoYXZlIGFuIGVsZW1lbnQsIHlvdSBkb24ndCBpbmNsdWRlIGl0LCByYXRoZXIgdGhhbg0KPiBp bmNsdWRlIGl0IHdpdGggYSBudWxsIHZhbHVlLg0KPiANCj4gSSdsbCBhc2sgYXJvdW5kIHRoZSBQ SURGIGNvZ25vc2NlbnRpIHRvIHNlZSB3aGF0IHRoZXkgdGhpbmsuDQo+IA0KPiBCcmlhbg0KPiBP biBKdWwgNCwgMjAxMCwgYXQgMzo0NSBQTSwgR2VvZmYgVGhvbXBzb24gd3JvdGU6DQo+IA0KPiA+ IEJyaWFuLQ0KPiA+IEl0IHNlZW1zIGxpayBhIGJhZCBpZGVhIHRvIGxldCBwZXJmZWN0bHkgZ29v ZCBhc3N1bXB0aW9ucyAobGlrZSBhIE1QDQo+ID4gb3IgYSBob3VzZSBudW1iZXIgIm5lZWRzIiBh IHJvYWQgbmFtZSkgZ2V0IHNjcmV3ZWQgdXAgYnkgdW51c3VhbA0KPiA+IGV4Y2VwdGlvbiBhcyB5 b3UgaGF2ZSBub3RlZC4NCj4gPg0KPiA+IFdoeSBub3QsIGluc3RlYWQsIGp1c3QgY2hhcmdlIGFo ZWFkIGJ1dCBhbGxvdyBhIHNwZWNpYWwgdmFsdWUgb2YNCj4gPiByb2FkIG5hbWUgKCJOVUxMIiA/ KSB0aGF0IG5vdGVzIHRoYXQgaW4gdGhpcyBjYXNlIGl0IGlzIGtub3duIHRoYXQgYQ0KPiA+IHJv YWQgbmFtZSBkb2VzIG5vdCBleGlzdD8gIFRoZSBlbnRlcmVkIHZhbHVlIHNob3VsZCBwcm9iYWJs eSBiZQ0KPiA+IGRpZmZlcmVudGlhdGVkIGZyb20gdGhhdCB3aGljaCB3b3VsZCBiZSBwcm92aWRl ZCBpZiB0aGUgdmFsdWUgb2YNCj4gPiByb2FkIG5hbWUgd2VyZSAidW5rbm93biIuDQo+ID4NCj4g PiBHZW9mZg0KPiA+PiBNZXNzYWdlOiAyDQo+ID4+IERhdGU6IFNhdCwgMyBKdWwgMjAxMCAxNjo1 MzoxOCAtMDQwMA0KPiA+PiBGcm9tOiBCcmlhbiBSb3NlbjxickBicmlhbnJvc2VuLm5ldD4NCj4g Pj4gU3ViamVjdDogUmU6IFtHZW9wcml2XSBGd2Q6IEktRA0KPiA+PiAJQWN0aW9uOmRyYWZ0LWdl b3JnZS1nZW9wcml2LWxhbXAtcG9zdC0wMC50eHQNCj4gPj4gVG86IENhcmwgUmVlZDxjcmVlZEBv cGVuZ2Vvc3BhdGlhbC5vcmc+DQo+ID4+IENjOiBnZW9wcml2QGlldGYub3JnDQo+ID4+IE1lc3Nh Z2UtSUQ6PDkxN0M4NkZELTVDRjgtNDJEOC1BRjZDLTE4MzM5NDk3RDFGQUBicmlhbnJvc2VuLm5l dD4NCj4gPj4gQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSI7IEZv cm1hdD0iZmxvd2VkIjsNCj4gPj4gCURlbFNwPSJ5ZXMiDQo+ID4+DQo+ID4+IEkgYW0gYSBjby1h dXRob3Igb24gdGhpcyBkcmFmdCwgYW5kIHRoZSBtaWxlcG9zdCBhZGRpdGlvbiB0byB0aGUNCj4g bGFtcA0KPiA+PiBwb3N0IG9yaWdpbmFsIHdhcyBtb3RpdmF0ZWQgYnkgdGhlIE5FTkEgcmVxdWly ZW1lbnQgdG8gaGF2ZSBhDQo+ID4+IG1pbGVwb3N0Lg0KPiA+Pg0KPiA+PiBJIGFncmVlIHRoYXQg dGhlIE1QIG5lYXJseSBhbHdheXMgbmVlZHMgYSByb2FkIG5hbWUuICBTbyBkb2VzIGENCj4gaG91 c2UNCj4gPj4gbnVtYmVyLiAgVGhlIGN1cnJlbnQgZG9jdW1lbnRzIGRvbid0IGhhdmUgcmVxdWly ZW1lbnRzIGxpa2UgdGhhdCwNCj4gPj4gcHJpbWFyaWx5IGJlY2F1c2Ugd2Uga2VlcCBmaW5kaW5n IG9kZCBjYXNlcyB0aGF0IGRvbid0IG1lZXQgd2hhdCB3ZQ0KPiA+PiB0aG91Z2h0IHdhcyBhIHNp bXBsZSBydWxlLg0KPiA+Pg0KPiA+PiBCcmlhbg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gR2VvcHJpdiBtYWlsaW5nIGxpc3QNCj4gR2Vv cHJpdkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dl b3ByaXYNCg== From hgs@cs.columbia.edu Sun Jul 4 23:48:45 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445593A6912 for ; Sun, 4 Jul 2010 23:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] 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 MPoynnfmDL5N for ; Sun, 4 Jul 2010 23:48:43 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id B96473A6905 for ; Sun, 4 Jul 2010 23:48:43 -0700 (PDT) Received: from [192.168.11.9] (85-23-27-240-Torikatu-TR1.suomi.net [85.23.27.240]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id o656mVBM027096 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 5 Jul 2010 02:48:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E9DCC79E@SISPE7MB1.commscope.com> Date: Mon, 5 Jul 2010 02:48:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C30E4C9.1010006@ieee.org> <8B0A9FCBB9832F43971E38010638454F03E9DCC79E@SISPE7MB1.commscope.com> To: "Thomson, Martin" X-Mailer: Apple Mail (2.1081) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: "geopriv@ietf.org" , "thompson@ieee.org" Subject: Re: [Geopriv] I-D, Action:draft-george-geopriv-lamp-post-00.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 06:48:45 -0000 Agreed. In addition, the element generating the content may not be fully = aware of these conventions, so it is difficult for the origin to know in = many cases whether an address is complete, exists, sufficient, etc. = Plus, an address may be sufficient for one purpose (e.g., for some = routing purposes, you may not need the house number or apartment number) = and useless for another (mail delivery pretty much requires a house = number, and maybe even an apartment number and postal code). Henning On Jul 5, 2010, at 2:37 AM, Thomson, Martin wrote: > This problem is not just limited to these conventions for = thoroughfares. The interpretation of many parts of a civic address rely = on the context provided by other elements. >=20 > The solution is really simple. Don't omit useful stuff. >=20 > A postal worker that receives a letter addressed to "1600 (absent) = Avenue" is well-justified if she decides that she is not going to = deliver the letter [1]. =20 >=20 > If you want to ensure that the letter gets delivered, you put the rest = of the address in. No different here. =20 >=20 > Any system of constraints is likely to fail internationally. >=20 > Making house number relative to the thoroughfare is not possible. = There is the thoroughfare branching we encountered, which would = complicate it. The perfectly logical numbering system employed by the = Japanese for house numbering, which is relative to the block [1], would = make it even more difficult to codify. >=20 > --Martin >=20 > [1] No allowances made for overly zealous posties who know that there = is only one 1600 on an Avenue in the city and deliver the letter anyway. >=20 > [2] http://en.wikipedia.org/wiki/House_numbering#Japan_and_Korea >=20 >> -----Original Message----- >> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On >> Behalf Of Brian Rosen >> Sent: Monday, 5 July 2010 8:23 AM >> To: thompson@ieee.org >> Cc: geopriv@ietf.org >> Subject: Re: [Geopriv] I-D, Action:draft-george-geopriv-lamp-post- >> 00.txt >>=20 >> While I do want to change the basic way the PIDF schema is defined, >> enforcing a restriction in the schema seems like a poor choice. I = am >> loth to define a null road name; that's a big change to the way PIDF >> works; if you don't have an element, you don't include it, rather = than >> include it with a null value. >>=20 >> I'll ask around the PIDF cognoscenti to see what they think. >>=20 >> Brian >> On Jul 4, 2010, at 3:45 PM, Geoff Thompson wrote: >>=20 >>> Brian- >>> It seems lik a bad idea to let perfectly good assumptions (like a MP >>> or a house number "needs" a road name) get screwed up by unusual >>> exception as you have noted. >>>=20 >>> Why not, instead, just charge ahead but allow a special value of >>> road name ("NULL" ?) that notes that in this case it is known that a >>> road name does not exist? The entered value should probably be >>> differentiated from that which would be provided if the value of >>> road name were "unknown". >>>=20 >>> Geoff >>>> Message: 2 >>>> Date: Sat, 3 Jul 2010 16:53:18 -0400 >>>> From: Brian Rosen >>>> Subject: Re: [Geopriv] Fwd: I-D >>>> Action:draft-george-geopriv-lamp-post-00.txt >>>> To: Carl Reed >>>> Cc: geopriv@ietf.org >>>> Message-ID:<917C86FD-5CF8-42D8-AF6C-18339497D1FA@brianrosen.net> >>>> Content-Type: text/plain; charset=3D"us-ascii"; Format=3D"flowed"; >>>> DelSp=3D"yes" >>>>=20 >>>> I am a co-author on this draft, and the milepost addition to the >> lamp >>>> post original was motivated by the NENA requirement to have a >>>> milepost. >>>>=20 >>>> I agree that the MP nearly always needs a road name. So does a >> house >>>> number. The current documents don't have requirements like that, >>>> primarily because we keep finding odd cases that don't meet what we >>>> thought was a simple rule. >>>>=20 >>>> Brian >>=20 >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv >=20 From robinsg@huawei.com Mon Jul 5 00:36:48 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A44B53A6967 for ; Mon, 5 Jul 2010 00:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 HCkg3JKpd5RF for ; Mon, 5 Jul 2010 00:36:47 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 2B6AD3A6823 for ; Mon, 5 Jul 2010 00:36:47 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5200INHQH12Y@szxga02-in.huawei.com> for geopriv@ietf.org; Mon, 05 Jul 2010 15:36:37 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L520058CQH1KG@szxga02-in.huawei.com> for geopriv@ietf.org; Mon, 05 Jul 2010 15:36:37 +0800 (CST) Received: from [10.70.109.60] by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L52005M1QH1CH@szxml06-in.huawei.com> for geopriv@ietf.org; Mon, 05 Jul 2010 15:36:37 +0800 (CST) Date: Mon, 05 Jul 2010 15:36:37 +0800 From: Robins George In-reply-to: <36C28078E8E347DC9E8EDC7901FE7CF3@creedPC> To: Carl Reed Message-id: <4C318B85.3010609@huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_SHvk8J9clkqj6BcqxA0j5A)" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 References: <4C2C5E09.4090907@huawei.com> <36C28078E8E347DC9E8EDC7901FE7CF3@creedPC> Cc: geopriv@ietf.org Subject: Re: [Geopriv] I-D Action:draft-george-geopriv-lamp-post-00.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robinsg@huawei.com List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 07:36:48 -0000 This is a multi-part message in MIME format. --Boundary_(ID_SHvk8J9clkqj6BcqxA0j5A) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Carl, Agree that we need a reference feature to this CAtype. Will it make sense to consider MP with a parameter to specify additional information (what kind, road name ... ?) Unfortunately, that required a new xml namespace, a registry ... -Robins On 7/4/2010 3:36 AM, Carl Reed wrote: > Robins - > I would suggest adding some clauses stating that MP shall be used in > conjunction with RD or some other feature type that references a > linear feature, such as a stream, road, or trail. A mile marker/post > means nothing unless there is a reference feature. Also, there are > often rules regarding from which "end" of the feature the marker is > calculated from. Not sure if this information needs to also be > encoded. Perhaps worth some discussion. Finally, the mile market issue > was intensely discussed in the NENA Next Generation Data Working > Group. This discussion was part of the larger addressing standards > discussion. Unfortunately, I cannot remember the outcome :-( but we > can find out. > Also, for those interested, there is an ISO standard for an abstract > model for linear referencing (ISO 19148). > Regards > > Carl Reed > CTO > OGC > > ----- Original Message ----- > *From:* Robins George > *To:* geopriv@ietf.org > *Sent:* Thursday, July 01, 2010 3:21 AM > *Subject:* [Geopriv] Fwd: I-D > Action:draft-george-geopriv-lamp-post-00.txt > > > The ECRIT WG believes, GEO-PRIV WG would be more appropriate to > discuss this draft [1], by considering the previous discussions > happened in the GEO-PRIV mailing list. More over, draft is talking > about location information. > > Will everyone please give this draft a review, and post comments, > questions, and suggested changes? > > [1] - draft-george-ecrit-lamp-post-02 > > - robins. > > > > -------- Original Message -------- > Subject: I-D Action:draft-george-geopriv-lamp-post-00.txt > Date: Thu, 01 Jul 2010 02:15:02 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Civic Location Format Extension for Utility and Lamp Post Numbers > Author(s) : R. George, et al. > Filename : draft-george-geopriv-lamp-post-00.txt > Pages : 6 > Date : 2010-07-01 > > This document describes an extension to civic location format and > adds two new CAtypes: PN (pole number) and MP (milepost). Pole > Numbers are used on poles such as lamp posts or utility poles, and > can be used in some circumstances as location information. Mileposts > are numeric values measured from an end of a trail, road, railway > line or other feature. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-george-geopriv-lamp-post-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > ------------------------------------------------------------------------ > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv > --Boundary_(ID_SHvk8J9clkqj6BcqxA0j5A) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Carl,

Agree that we need a reference feature to this CAtype. Will it make sense to consider MP with a parameter to specify additional information (what kind, road name ... ?) Unfortunately, that required a new xml namespace, a registry ... 

-Robins

On 7/4/2010 3:36 AM, Carl Reed wrote:
Robins -
 
I would suggest adding some clauses stating that MP shall be used in conjunction with RD or some other feature type that references a linear feature, such as a stream, road, or trail. A mile marker/post means nothing unless there is a reference feature. Also, there are often rules regarding from which "end" of the feature the marker is calculated from. Not sure if this information needs to also be encoded. Perhaps worth some discussion. Finally, the mile market issue was intensely discussed in the NENA Next Generation Data Working Group. This discussion was part of the larger addressing standards discussion. Unfortunately, I cannot remember the outcome :-( but we can find out.
 
Also, for those interested, there is an ISO standard for an abstract model for linear referencing (ISO 19148).
 
Regards

Carl Reed
CTO
OGC
----- Original Message -----
Sent: Thursday, July 01, 2010 3:21 AM
Subject: [Geopriv] Fwd: I-D Action:draft-george-geopriv-lamp-post-00.txt


The ECRIT WG believes, GEO-PRIV WG would be more appropriate to discuss this draft [1], by considering the previous discussions happened in the GEO-PRIV mailing list. More over, draft is talking about location information.

Will everyone please give this draft a review, and post comments, questions, and suggested changes?  

[1] - draft-george-ecrit-lamp-post-02

- robins.



-------- Original Message --------
Subject: I-D Action:draft-george-geopriv-lamp-post-00.txt
Date: Thu, 01 Jul 2010 02:15:02 -0700 (PDT)
From: Internet-Drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Civic Location Format Extension for Utility and Lamp Post Numbers
	Author(s)       : R. George, et al.
	Filename        : draft-george-geopriv-lamp-post-00.txt
	Pages           : 6
	Date            : 2010-07-01

This document describes an extension to civic location format and
adds two new CAtypes: PN (pole number) and MP (milepost).  Pole
Numbers are used on poles such as lamp posts or utility poles, and
can be used in some circumstances as location information.  Mileposts
are numeric values measured from an end of a trail, road, railway
line or other feature.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-george-geopriv-lamp-post-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

    


_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
--Boundary_(ID_SHvk8J9clkqj6BcqxA0j5A)-- From root@core3.amsl.com Mon Jul 5 05:00:01 2010 Return-Path: X-Original-To: geopriv@ietf.org Delivered-To: geopriv@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7042E3A68A5; Mon, 5 Jul 2010 05:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100705120001.7042E3A68A5@core3.amsl.com> Date: Mon, 5 Jul 2010 05:00:01 -0700 (PDT) Cc: geopriv@ietf.org Subject: [Geopriv] I-D Action:draft-ietf-geopriv-deref-protocol-00.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 12:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Geographic Location/Privacy Working Group of the IETF. Title : A Location Dereferencing Protocol Using HELD Author(s) : J. Winterbottom, et al. Filename : draft-ietf-geopriv-deref-protocol-00.txt Pages : 22 Date : 2010-07-04 This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereferencing protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). The document assumes that a Location Recipient possesses a secure HELD URI that can be used in conjunction with the HELD protocol to request the location of the Target. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-deref-protocol-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-geopriv-deref-protocol-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-05044523.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 5 05:00:01 2010 Return-Path: X-Original-To: geopriv@ietf.org Delivered-To: geopriv@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7A6323A68C6; Mon, 5 Jul 2010 05:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100705120001.7A6323A68C6@core3.amsl.com> Date: Mon, 5 Jul 2010 05:00:01 -0700 (PDT) Cc: geopriv@ietf.org Subject: [Geopriv] I-D Action:draft-ietf-geopriv-held-measurements-00.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 12:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Geographic Location/Privacy Working Group of the IETF. Title : Using Device-provided Location-Related Measurements in Location Configuration Protocols Author(s) : M. Thomson, J. Winterbottom Filename : draft-ietf-geopriv-held-measurements-00.txt Pages : 69 Date : 2010-07-04 A method is described by which a Device is able to provide location- related measurement data to a LIS within a request for location information. Location-related measurement information are observations concerning properties related to the position of a Device, which could be data about network attachment or about the physical environment. When a LIS generates location information for a Device, information from the Device can improve the accuracy of the location estimate. A basic set of location-related measurements are defined, including common modes of network attachment as well as assisted Global Navigation Satellite System (GNSS) parameters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-held-measurements-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-geopriv-held-measurements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-05044602.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 5 07:45:02 2010 Return-Path: X-Original-To: geopriv@ietf.org Delivered-To: geopriv@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 483963A699D; Mon, 5 Jul 2010 07:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100705144502.483963A699D@core3.amsl.com> Date: Mon, 5 Jul 2010 07:45:02 -0700 (PDT) Cc: geopriv@ietf.org Subject: [Geopriv] I-D Action:draft-ietf-geopriv-relative-location-00.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 14:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Geographic Location/Privacy Working Group of the IETF. Title : Relative Location Representation Author(s) : M. Thomson, et al. Filename : draft-ietf-geopriv-relative-location-00.txt Pages : 34 Date : 2010-07-05 This document defines an extension to PIDF-LO (RFC4119) for the expression of location information that is defined relative to a reference point. The reference point may be expressed as a geodetic or civic location, and the relative offset may be one of several shapes. Optionally, a reference to a secondary document (such as a map image) can be included, along with the relationship of the map coordinate system to the reference/offset coordinate system to allow display of the map with the reference point and the relative offset. Also included in this document is a Type/Length/Value (TLV) representation of the relative location for use in other protocols that use TLVs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-relative-location-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-geopriv-relative-location-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-05074412.I-D@ietf.org> --NextPart-- From thompson@ieee.org Mon Jul 5 11:27:40 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23FD3A6836 for ; Mon, 5 Jul 2010 11:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.298 X-Spam-Level: X-Spam-Status: No, score=-101.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] 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 k2jTVT-mkUwk for ; Mon, 5 Jul 2010 11:27:39 -0700 (PDT) Received: from smtp107.prem.mail.sp1.yahoo.com (smtp107.prem.mail.sp1.yahoo.com [98.136.44.62]) by core3.amsl.com (Postfix) with SMTP id DA5D73A676A for ; Mon, 5 Jul 2010 11:27:39 -0700 (PDT) Received: (qmail 32190 invoked from network); 5 Jul 2010 18:27:41 -0000 Received: from geoff-thompsons-macbook-2.local (thompson@64.9.238.93 with plain) by smtp107.prem.mail.sp1.yahoo.com with SMTP; 05 Jul 2010 11:27:40 -0700 PDT X-Yahoo-SMTP: QyU90.qswBBpdAOL14e1mfwUogr5DY5wzs_aWTD7HWypLbttNQmnq7k- X-YMail-OSG: eM.RMjIVM1mYKZ8Q7oLocl5ZJAFK.aRIZscaWPnYyX45xkX EpiPg7BWJa_hxEXPgD0N6ZVYGe9Jr8_pKQfeUckvqUd_43ZeoOqdNpi8KFud Qnr2VmQWIA9z0zdtit_JjDpnrXvCPGNJgLnWH0KbPDQyku0QeLdd7SQEYCeo dSIqmqUd3CePVLGj41_CdBtTLC_qrIeFV2EcIbdAmsZOwrrrv_x7NomEdfVz tqp0WzYQxg29IMd4KJihgQ2fnXvwewFrfYwCttiPZQl9MSX7BnrwpwmUKtWc I X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C32241C.9090909@ieee.org> Date: Mon, 05 Jul 2010 11:27:40 -0700 From: Geoff Thompson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Brian Rosen References: <4C30E4C9.1010006@ieee.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: geopriv@ietf.org Subject: Re: [Geopriv] I-D, Action:draft-george-geopriv-lamp-post-00.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: thompson@ieee.org List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 18:27:40 -0000 Brian- It seems to me that this is somewhat different than "if you don't have an element, you don't include it". The cases you cite are more "we do have the element, the known name is an empty value". (that being significantly different from "unknown" or unsupplied for an unknown reason) It seems simpler to change the syntax than to do something like what the US Feds did a number of years ago. That was to decree that (in order to qualify for federal money for local rescue squads) every house in your area had to have a street address with both a registered street name (beit a private or public street) and a monotonic "house" number. No surprise, that imposed a significant real world implementation burden with lots of hangover. I look forward to the feedback from the cognoscenti Geoff On 4/7/10 3:23 PM, Brian Rosen wrote: > While I do want to change the basic way the PIDF schema is defined, > enforcing a restriction in the schema seems like a poor choice. I am > loth to define a null road name; that's a big change to the way PIDF > works; if you don't have an element, you don't include it, rather than > include it with a null value. > > I'll ask around the PIDF cognoscenti to see what they think. > > Brian > On Jul 4, 2010, at 3:45 PM, Geoff Thompson wrote: > >> Brian- >> It seems lik a bad idea to let perfectly good assumptions (like a MP >> or a house number "needs" a road name) get screwed up by unusual >> exception as you have noted. >> >> Why not, instead, just charge ahead but allow a special value of road >> name ("NULL" ?) that notes that in this case it is known that a road >> name does not exist? The entered value should probably be >> differentiated from that which would be provided if the value of road >> name were "unknown". >> >> Geoff >>> Message: 2 >>> Date: Sat, 3 Jul 2010 16:53:18 -0400 >>> From: Brian Rosen >>> Subject: Re: [Geopriv] Fwd: I-D >>> Action:draft-george-geopriv-lamp-post-00.txt >>> To: Carl Reed >>> Cc: geopriv@ietf.org >>> Message-ID:<917C86FD-5CF8-42D8-AF6C-18339497D1FA@brianrosen.net> >>> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; >>> DelSp="yes" >>> >>> I am a co-author on this draft, and the milepost addition to the lamp >>> post original was motivated by the NENA requirement to have a milepost. >>> >>> I agree that the MP nearly always needs a road name. So does a house >>> number. The current documents don't have requirements like that, >>> primarily because we keep finding odd cases that don't meet what we >>> thought was a simple rule. >>> >>> Brian > > From hgs@cs.columbia.edu Mon Jul 5 11:37:13 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27933A67EE for ; Mon, 5 Jul 2010 11:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.599 X-Spam-Level: X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 1xUKbfdTC6CY for ; Mon, 5 Jul 2010 11:37:12 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by core3.amsl.com (Postfix) with ESMTP id E525E3A676A for ; Mon, 5 Jul 2010 11:37:11 -0700 (PDT) Received: from [192.168.11.9] (85-23-27-240-Torikatu-TR1.suomi.net [85.23.27.240]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id o65IatVW022801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 5 Jul 2010 14:37:05 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <4C32241C.9090909@ieee.org> Date: Mon, 5 Jul 2010 14:36:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <38BB7CF6-DB09-4BB0-9318-48A93D996B42@cs.columbia.edu> References: <4C30E4C9.1010006@ieee.org> <4C32241C.9090909@ieee.org> To: thompson@ieee.org X-Mailer: Apple Mail (2.1081) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: geopriv@ietf.org Subject: Re: [Geopriv] I-D, Action:draft-george-geopriv-lamp-post-00.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 18:37:13 -0000 I admit that I fail to see the practical difference for software. You = can obviously already specify an empty field if you really insist, but = there are two cases: - the recipient needs the information - being told that we know it to be = empty isn't too helpful, since that's not a legal value - the recipient doesn't need the information - whether this is or = just omitted makes no difference. We should strive to keep things simple - special cases that are likely = to be done wrong in practice don't seem to help here. Henning On Jul 5, 2010, at 2:27 PM, Geoff Thompson wrote: > Brian- >=20 > It seems to me that this is somewhat different than "if you don't have = an element, you don't include it". > The cases you cite are more "we do have the element, the known name is = an empty value". > (that being significantly different from "unknown" or unsupplied = for an unknown reason) >=20 > It seems simpler to change the syntax than to do something like what = the US Feds did a number of years ago. That was to decree that (in = order to qualify for federal money for local rescue squads) every house = in your area had to have a street address with both a registered street = name (beit a private or public street) and a monotonic "house" number. = No surprise, that imposed a significant real world implementation burden = with lots of hangover. >=20 > I look forward to the feedback from the cognoscenti >=20 > Geoff >=20 > On 4/7/10 3:23 PM, Brian Rosen wrote: >> While I do want to change the basic way the PIDF schema is defined, = enforcing a restriction in the schema seems like a poor choice. I am = loth to define a null road name; that's a big change to the way PIDF = works; if you don't have an element, you don't include it, rather than = include it with a null value. >>=20 >> I'll ask around the PIDF cognoscenti to see what they think. >>=20 >> Brian >> On Jul 4, 2010, at 3:45 PM, Geoff Thompson wrote: >>=20 >>> Brian- >>> It seems lik a bad idea to let perfectly good assumptions (like a MP = or a house number "needs" a road name) get screwed up by unusual = exception as you have noted. >>>=20 >>> Why not, instead, just charge ahead but allow a special value of = road name ("NULL" ?) that notes that in this case it is known that a = road name does not exist? The entered value should probably be = differentiated from that which would be provided if the value of road = name were "unknown". >>>=20 >>> Geoff >>>> Message: 2 >>>> Date: Sat, 3 Jul 2010 16:53:18 -0400 >>>> From: Brian Rosen >>>> Subject: Re: [Geopriv] Fwd: I-D >>>> Action:draft-george-geopriv-lamp-post-00.txt >>>> To: Carl Reed >>>> Cc: geopriv@ietf.org >>>> Message-ID:<917C86FD-5CF8-42D8-AF6C-18339497D1FA@brianrosen.net> >>>> Content-Type: text/plain; charset=3D"us-ascii"; Format=3D"flowed"; >>>> DelSp=3D"yes" >>>>=20 >>>> I am a co-author on this draft, and the milepost addition to the = lamp >>>> post original was motivated by the NENA requirement to have a = milepost. >>>>=20 >>>> I agree that the MP nearly always needs a road name. So does a = house >>>> number. The current documents don't have requirements like that, >>>> primarily because we keep finding odd cases that don't meet what we >>>> thought was a simple rule. >>>>=20 >>>> Brian >>=20 >>=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv >=20 From thompson@ieee.org Mon Jul 5 11:52:02 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 331773A67EE for ; Mon, 5 Jul 2010 11:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.947 X-Spam-Level: X-Spam-Status: No, score=-102.947 tagged_above=-999 required=5 tests=[AWL=1.650, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] 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 AotUSMP5CCIc for ; Mon, 5 Jul 2010 11:52:00 -0700 (PDT) Received: from smtp106.prem.mail.sp1.yahoo.com (smtp106.prem.mail.sp1.yahoo.com [98.136.44.61]) by core3.amsl.com (Postfix) with SMTP id 6AA713A676A for ; Mon, 5 Jul 2010 11:52:00 -0700 (PDT) Received: (qmail 47137 invoked from network); 5 Jul 2010 18:52:00 -0000 Received: from geoff-thompsons-macbook-2.local (thompson@64.9.238.93 with plain) by smtp106.prem.mail.sp1.yahoo.com with SMTP; 05 Jul 2010 11:52:00 -0700 PDT X-Yahoo-SMTP: QyU90.qswBBpdAOL14e1mfwUogr5DY5wzs_aWTD7HWypLbttNQmnq7k- X-YMail-OSG: KdHI3JUVM1m12tm1nNW9KIkOPrzN5D3WnzDkp.QmJ8G_8L2 FybaF5VPGz5Kgh2u9wmsEPfO.eEYRgcBPlBiJxhRDBQCVZPvGr.cEYyGrykY q2iHyFINRCBb7hXDdf0EPwAc4hd3Qu3_fpXA_mfV1T8BFME4mlPHhHBwlMK3 4Whw8XJyBEwDNndRhpndbLf7JqqOnl6EpAIXQ6jC4vD2_pTUOlvpX.x4jmr0 2Ms2hM3KIq6dGPRFNtgc613dq2OePxz9TVTCNDXyZnxhPb7YsxrhDRxBvMSA r X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C3229CF.3080909@ieee.org> Date: Mon, 05 Jul 2010 11:51:59 -0700 From: Geoff Thompson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: Henning Schulzrinne References: <4C30E4C9.1010006@ieee.org> <8B0A9FCBB9832F43971E38010638454F03E9DCC79E@SISPE7MB1.commscope.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080001060007000803040504" Cc: "geopriv@ietf.org" , "Thomson, Martin" Subject: Re: [Geopriv] I-D, Action:draft-george-geopriv-lamp-post-00.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: thompson@ieee.org List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 18:52:02 -0000 This is a multi-part message in MIME format. --------------080001060007000803040504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Henning- Your point about "an address may be sufficient for one purpose and useless for another" is certainly true. Real world example, valid at least in the USA, is that the address for parcel delivery (e.g. UPS, FedEx, Pizza Hut) and emergency services may well be invalid for postal delivery (e.g. Post Office box with an entirely different post code) Geoff On 4/7/10 11:48 PM, Henning Schulzrinne wrote: > Agreed. In addition, the element generating the content may not be fully aware of these conventions, so it is difficult for the origin to know in many cases whether an address is complete, exists, sufficient, etc. Plus, an address may be sufficient for one purpose (e.g., for some routing purposes, you may not need the house number or apartment number) and useless for another (mail delivery pretty much requires a house number, and maybe even an apartment number and postal code). > > Henning > > On Jul 5, 2010, at 2:37 AM, Thomson, Martin wrote: > > >> This problem is not just limited to these conventions for thoroughfares. The interpretation of many parts of a civic address rely on the context provided by other elements. >> >> The solution is really simple. Don't omit useful stuff. >> >> A postal worker that receives a letter addressed to "1600 (absent) Avenue" is well-justified if she decides that she is not going to deliver the letter [1]. >> >> If you want to ensure that the letter gets delivered, you put the rest of the address in. No different here. >> >> Any system of constraints is likely to fail internationally. >> >> Making house number relative to the thoroughfare is not possible. There is the thoroughfare branching we encountered, which would complicate it. The perfectly logical numbering system employed by the Japanese for house numbering, which is relative to the block [1], would make it even more difficult to codify. >> >> --Martin >> >> [1] No allowances made for overly zealous posties who know that there is only one 1600 on an Avenue in the city and deliver the letter anyway. >> >> [2] http://en.wikipedia.org/wiki/House_numbering#Japan_and_Korea >> >> >>> -----Original Message----- >>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On >>> Behalf Of Brian Rosen >>> Sent: Monday, 5 July 2010 8:23 AM >>> To: thompson@ieee.org >>> Cc: geopriv@ietf.org >>> Subject: Re: [Geopriv] I-D, Action:draft-george-geopriv-lamp-post- >>> 00.txt >>> >>> While I do want to change the basic way the PIDF schema is defined, >>> enforcing a restriction in the schema seems like a poor choice. I am >>> loth to define a null road name; that's a big change to the way PIDF >>> works; if you don't have an element, you don't include it, rather than >>> include it with a null value. >>> >>> I'll ask around the PIDF cognoscenti to see what they think. >>> >>> Brian >>> On Jul 4, 2010, at 3:45 PM, Geoff Thompson wrote: >>> >>> >>>> Brian- >>>> It seems lik a bad idea to let perfectly good assumptions (like a MP >>>> or a house number "needs" a road name) get screwed up by unusual >>>> exception as you have noted. >>>> >>>> Why not, instead, just charge ahead but allow a special value of >>>> road name ("NULL" ?) that notes that in this case it is known that a >>>> road name does not exist? The entered value should probably be >>>> differentiated from that which would be provided if the value of >>>> road name were "unknown". >>>> >>>> Geoff >>>> >>>>> Message: 2 >>>>> Date: Sat, 3 Jul 2010 16:53:18 -0400 >>>>> From: Brian Rosen >>>>> Subject: Re: [Geopriv] Fwd: I-D >>>>> Action:draft-george-geopriv-lamp-post-00.txt >>>>> To: Carl Reed >>>>> Cc: geopriv@ietf.org >>>>> Message-ID:<917C86FD-5CF8-42D8-AF6C-18339497D1FA@brianrosen.net> >>>>> Content-Type: text/plain; charset="us-ascii"; Format="flowed"; >>>>> DelSp="yes" >>>>> >>>>> I am a co-author on this draft, and the milepost addition to the >>>>> >>> lamp >>> >>>>> post original was motivated by the NENA requirement to have a >>>>> milepost. >>>>> >>>>> I agree that the MP nearly always needs a road name. So does a >>>>> >>> house >>> >>>>> number. The current documents don't have requirements like that, >>>>> primarily because we keep finding odd cases that don't meet what we >>>>> thought was a simple rule. >>>>> >>>>> Brian >>>>> >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www.ietf.org/mailman/listinfo/geopriv >>> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv >> >> > > > --------------080001060007000803040504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Henning-
Your point about "an address may be sufficient for one purpose and useless for another" is certainly true.
Real world example, valid at least in the USA, is that the address for parcel delivery (e.g. UPS, FedEx, Pizza Hut) and emergency services may well be invalid for postal delivery (e.g. Post Office box with an entirely different post code)

Geoff

On 4/7/10 11:48 PM, Henning Schulzrinne wrote:
Agreed. In addition, the element generating the content may not be fully aware of these conventions, so it is difficult for the origin to know in many cases whether an address is complete, exists, sufficient, etc. Plus, an address may be sufficient for one purpose (e.g., for some routing purposes, you may not need the house number or apartment number) and useless for another (mail delivery pretty much requires a house number, and maybe even an apartment number and postal code).

Henning

On Jul 5, 2010, at 2:37 AM, Thomson, Martin wrote:

  
This problem is not just limited to these conventions for thoroughfares.  The interpretation of many parts of a civic address rely on the context provided by other elements.

The solution is really simple.  Don't omit useful stuff.

A postal worker that receives a letter addressed to "1600 (absent) Avenue" is well-justified if she decides that she is not going to deliver the letter [1].  

If you want to ensure that the letter gets delivered, you put the rest of the address in.  No different here.  

Any system of constraints is likely to fail internationally.

Making house number relative to the thoroughfare is not possible.  There is the thoroughfare branching we encountered, which would complicate it.  The perfectly logical numbering system employed by the Japanese for house numbering, which is relative to the block [1], would make it even more difficult to codify.

--Martin

[1] No allowances made for overly zealous posties who know that there is only one 1600 on an Avenue in the city and deliver the letter anyway.

[2] http://en.wikipedia.org/wiki/House_numbering#Japan_and_Korea

    
-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
Behalf Of Brian Rosen
Sent: Monday, 5 July 2010 8:23 AM
To: thompson@ieee.org
Cc: geopriv@ietf.org
Subject: Re: [Geopriv] I-D, Action:draft-george-geopriv-lamp-post-
00.txt

While I do want to change the basic way the PIDF schema is defined,
enforcing a restriction in the schema seems like a poor choice.   I am
loth to define a null road name; that's a big change to the way PIDF
works; if you don't have an element, you don't include it, rather than
include it with a null value.

I'll ask around the PIDF cognoscenti to see what they think.

Brian
On Jul 4, 2010, at 3:45 PM, Geoff Thompson wrote:

      
Brian-
It seems lik a bad idea to let perfectly good assumptions (like a MP
or a house number "needs" a road name) get screwed up by unusual
exception as you have noted.

Why not, instead, just charge ahead but allow a special value of
road name ("NULL" ?) that notes that in this case it is known that a
road name does not exist?  The entered value should probably be
differentiated from that which would be provided if the value of
road name were "unknown".

Geoff
        
Message: 2
Date: Sat, 3 Jul 2010 16:53:18 -0400
From: Brian Rosen<br@brianrosen.net>
Subject: Re: [Geopriv] Fwd: I-D
	Action:draft-george-geopriv-lamp-post-00.txt
To: Carl Reed<creed@opengeospatial.org>
Cc: geopriv@ietf.org
Message-ID:<917C86FD-5CF8-42D8-AF6C-18339497D1FA@brianrosen.net>
Content-Type: text/plain; charset="us-ascii"; Format="flowed";
	DelSp="yes"

I am a co-author on this draft, and the milepost addition to the
          
lamp
      
post original was motivated by the NENA requirement to have a
milepost.

I agree that the MP nearly always needs a road name.  So does a
          
house
      
number.  The current documents don't have requirements like that,
primarily because we keep finding odd cases that don't meet what we
thought was a simple rule.

Brian
          
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
      
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

    


  
--------------080001060007000803040504-- From root@core3.amsl.com Mon Jul 5 14:15:01 2010 Return-Path: X-Original-To: geopriv@ietf.org Delivered-To: geopriv@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D103B3A6824; Mon, 5 Jul 2010 14:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100705211501.D103B3A6824@core3.amsl.com> Date: Mon, 5 Jul 2010 14:15:01 -0700 (PDT) Cc: geopriv@ietf.org Subject: [Geopriv] I-D Action:draft-ietf-geopriv-rfc3825bis-11.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 21:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Geographic Location/Privacy Working Group of the IETF. Title : Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information Author(s) : J. Polk, et al. Filename : draft-ietf-geopriv-rfc3825bis-11.txt Pages : 30 Date : 2010-07-05 This document specifies Dynamic Host Configuration Protocol Options (both DHCPv4 and DHCPv6) for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes Latitude, Longitude, and Altitude, with resolution or uncertainty indicators for each. Separate parameters indicate the reference datum for each of these values. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-rfc3825bis-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-geopriv-rfc3825bis-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-05140344.I-D@ietf.org> --NextPart-- From rjsparks@nostrum.com Fri Jul 9 07:30:19 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C26C13A67A1 for ; Fri, 9 Jul 2010 07:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-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 t1H5UCW28TIC for ; Fri, 9 Jul 2010 07:30:06 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 7DC0E3A659C for ; Fri, 9 Jul 2010 07:30:02 -0700 (PDT) Received: from [192.168.2.105] (pool-173-71-46-100.dllstx.fios.verizon.net [173.71.46.100]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o69EU6oK002072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 9 Jul 2010 09:30:06 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Jul 2010 09:30:06 -0500 Message-Id: <6FE17961-9480-4436-93A8-F12EF1AD3C7C@nostrum.com> To: GEOPRIV Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Received-SPF: pass (nostrum.com: 173.71.46.100 is authenticated by a trusted mechanism) Subject: [Geopriv] AD Review: draft-ietf-geopriv-arch-02 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 14:30:20 -0000 I am requesting IETF LC for this document - watch for an announcement of = it soon. I have two questions for the group to discuss during IETF LC: 1) Why is this draft a BCP? It is updating two Informational documents. It adds some normative language (particularly in section 3.2) that = might=20 push it into BCP territory. It would be worth re-reading the = document from thinking about which of these requirements are restatements of = requirements in other documents, which are new requirements on protocols, and = which are new requirements on implementations and deployments (my read is = that there are new requirements here in the last category and it would help to = highlight that in the draft). 2) The RECOMMENDED policy of "Intersection" (actually the very existence of the policy) seems to be at odds with the general principle of = additivity for rules. Can text be added explaining why this conflict is = appropriate? =20 RjS= From wwwrun@core3.amsl.com Fri Jul 9 08:10:32 2010 Return-Path: X-Original-To: geopriv@ietf.org Delivered-To: geopriv@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 82D2A3A68C8; Fri, 9 Jul 2010 08:10:32 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100709151032.82D2A3A68C8@core3.amsl.com> Date: Fri, 9 Jul 2010 08:10:32 -0700 (PDT) Cc: geopriv@ietf.org Subject: [Geopriv] Last Call: draft-ietf-geopriv-arch (An Architecture for Location and Location Privacy in Internet Applications) to BCP X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 15:10:32 -0000 The IESG has received a request from the Geographic Location/Privacy WG (geopriv) to consider the following document: - 'An Architecture for Location and Location Privacy in Internet Applications ' as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-07-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-geopriv-arch-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18940&rfc_flag=0 From acooper@cdt.org Tue Jul 20 00:29:31 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B5E3A6C26 for ; Tue, 20 Jul 2010 00:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] 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 bUn3wjGK2LTl for ; Tue, 20 Jul 2010 00:29:23 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 5762D3A69ED for ; Tue, 20 Jul 2010 00:29:22 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for geopriv@ietf.org; Tue, 20 Jul 2010 03:29:35 -0400 Message-Id: <07E5D092-425A-46D5-A5F8-76FAC4AD6C31@cdt.org> From: Alissa Cooper To: geopriv@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 20 Jul 2010 08:29:32 +0100 X-Mailer: Apple Mail (2.936) Subject: [Geopriv] IETF 78 Agenda X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 07:29:31 -0000 Our agenda for IETF 78 is below. Please send suggestions for edits to the list ASAP if you have any. INTRO: 5m Chairs intro & administrivia LIGHTNING TALKS: 5m draft-ietf-sipcore-location-conveyance (J. Polk) 5m draft-barnes-hard-problem (R. Barnes) 5m draft-ietf-geopriv-dhcp-lbyr-uri-option (J. Polk) WG DRAFT UPDATES: 20m draft-ietf-geopriv-held-measurements (M. Thomson) 20m draft-ietf-geopriv-relative-location (B. Rosen) 20m draft-ietf-geopriv-deref-protocol (M. Thomson) NEW DRAFT PRESENTATIONS: 20m draft-thomson-geopriv-res-gw-lis-discovery (R. Bellis) 20m draft-george-ecrit-lamp-post (R. George) 20m draft-barnes-geopriv-policy-uri (R. Barnes) From mlinsner@cisco.com Thu Jul 22 06:29:54 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A31903A6AF5 for ; Thu, 22 Jul 2010 06:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 kzpUvQ1UgOPq for ; Thu, 22 Jul 2010 06:29:53 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id F2A523A6B04 for ; Thu, 22 Jul 2010 06:29:52 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0GADPlR0xAZnwN/2dsb2JhbACfd2sGpjabHYU2BIhZ Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 22 Jul 2010 13:30:09 +0000 Received: from [10.116.195.117] (rtp-mlinsner-8714.cisco.com [10.116.195.117]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6MDU9BM013479 for ; Thu, 22 Jul 2010 13:30:09 GMT User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Thu, 22 Jul 2010 09:30:07 -0400 From: Marc Linsner To: "geopriv@ietf.org" Message-ID: Thread-Topic: Not going to the social? Thread-Index: Acspof/n3t0XhOFXLU+xI18YapFfGw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [Geopriv] Not going to the social? X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 13:29:54 -0000 This *may* be interesting....a 1 hour session titled: Location-Sharing Technologies: Privacy Risks and Controls http://net.educause.edu/live1020 -Marc- From acooper@cdt.org Fri Jul 23 09:24:02 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEB083A69E7 for ; Fri, 23 Jul 2010 09:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.756 X-Spam-Level: X-Spam-Status: No, score=-2.756 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599] 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 RWQbVAlEMx4d for ; Fri, 23 Jul 2010 09:24:01 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 6E5423A6359 for ; Fri, 23 Jul 2010 09:24:01 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Fri, 23 Jul 2010 12:24:15 -0400 Message-Id: From: Alissa Cooper To: Richard L. Barnes In-Reply-To: <28F4411F-1C65-4FAF-94F6-635ED462E152@bbn.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Jul 2010 17:24:13 +0100 References: <20100530233709.84DDF3A6967@core3.amsl.com> <28F4411F-1C65-4FAF-94F6-635ED462E152@bbn.com> X-Mailer: Apple Mail (2.936) Cc: geopriv@ietf.org Subject: Re: [Geopriv] Fwd: New Version Notification for draft-barnes-geopriv-policy-uri-01 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 16:24:02 -0000 (individual hat on) Hi Richard, I think this is an interesting (and probably necessary) idea, but it has some gaps that need filling in. A couple of thoughts to tee up before the meeting: 3.1 says: "Knowledge of the policy URI can be considered adequate evidence of authorization. While the Location Server MAY deny any particular request according to local policy, it SHOULD allow all requests (with any of the three methods). This does not prevent a Location Server from applying local policy in determining how to authorize any of these requests. For instance, a Location Server might allow clients to inspect policy (GET), but not to update it (PUT)." I find the multiple caveats here to be confusing. I think the outcome you're looking for is that an LS SHOULD allow all requests, but it MAY deny certain requests based on local authorization policy (e.g., allowing GETs but not PUTs, or only allowing dereferences from certain clients). Is that right? 3.2: This section discusses both policies for access to location and policies for access to policy URIs. Combining them like this is pretty confusing, and I'm not sure that either part is complete. For access to location, you say that the default policy has to be what it would be if there were no policy, but you don't say what the default policy is. The example in 5.3 suggests that the default policy's transformations are Didn't the default policy used to also include retransmission-allowed = FALSE and retention-expiry = 24 hours? What happened to those? For access to policy URIs, it says "A Location Server chooses whether or not to provide a policy URI based on local policy." I'm confused about the LS "providing" a URI in HELD. You describe a mechanism in 5.1 for *creating* a URI. But how does an LS provide a URI that has previously been created? If a Target issues the HELD request in 5.1, and then a third party issues a query containing both a "requestPolicyUri" element and a "device" element, does the original URI get overwritten? Or is that the point at which the "local policy" referenced above gets checked to see whether the third party is authorized to overwrite (or receive?) the URI? As to your question below about LSes providing other policy URIs, since the requests aren't coming via HELD or DHCP, what would you intend to specify other than making a generic statement that an LS can hand out policy URIs via other protocols? It seems like an LS that implements other protocols could do that already if it wanted to. Alissa On Jun 1, 2010, at 1:34 AM, Richard L. Barnes wrote: > Hey all, > > James, Martin, and I have put together a new version of the policy- > uri draft. As a reminder, this draft defines a way for a location > server to associate location URIs with "policy URIs" that allow the > target to control the policy associated with the location URI, and a > simple usage of HTTP to manipulate policy (which is forward- > compatible with WebDAV / XCAP). > > The major unresolved point of discussion among the author team that > I would like to bring to the list is whether this draft should also > allow the LS to provide a policy URI that is *not* associated with a > location URI. This policy URI would govern queries for the target's > location that are not based on a location URI provided through HELD > or DHCP, e.g., a third-party query. > > Comments welcome! > > Thanks, > --Richard > > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: May 30, 2010 7:37:08 PM EDT >> To: martin.thomson@andrew.com >> Cc: rbarnes@bbn.com,james.winterbottom@andrew.com >> Subject: New Version Notification for draft-barnes-geopriv-policy- >> uri-01 >> >> >> A new version of I-D, draft-barnes-geopriv-policy-uri-01.txt has >> been successfully submitted by Martin Thomson and posted to the >> IETF repository. >> >> Filename: draft-barnes-geopriv-policy-uri >> Revision: 01 >> Title: Location Configuration Extensions for Policy Management >> Creation_date: 2010-05-31 >> WG ID: Independent Submission >> Number_of_pages: 16 >> >> Abstract: >> Current location configuration protocols are capable of provisioning >> an Internet host with a location URI that refers to the host's >> location. These protocols lack a mechanism for the target host to >> inspect or set the privacy rules that are applied to the URIs they >> distribute. This document extends the current location configuration >> protocols to provide hosts with a reference to the rules that are >> applied to a URI, so that the host can view or set these rules. >> >> >> >> The IETF Secretariat. >> >> > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv From creed@opengeospatial.org Fri Jul 23 15:35:42 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B94D3A68ED for ; Fri, 23 Jul 2010 15:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, STOX_REPLY_TYPE=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 yyZ-Un0Ifiae for ; Fri, 23 Jul 2010 15:35:38 -0700 (PDT) Received: from mail.opengeospatial.org (mail.opengeospatial.org [66.244.86.40]) by core3.amsl.com (Postfix) with ESMTP id CDF4A3A67EB for ; Fri, 23 Jul 2010 15:35:37 -0700 (PDT) Received: from CarlandSusieOf (c-76-25-20-162.hsd1.co.comcast.net [76.25.20.162]) (authenticated bits=0) by mail.opengeospatial.org (8.13.8/8.13.8/Debian-3+etch1) with ESMTP id o6NMZs7B023038 for ; Fri, 23 Jul 2010 18:35:54 -0400 Message-ID: <1E6CE5CA67A44717B7C930AD9E4259ED@CarlandSusieOf> From: "Carl Reed" To: Date: Fri, 23 Jul 2010 16:35:39 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 x-mimeole: Produced By Microsoft MimeOLE V6.0.6000.16669 X-Virus-Scanned: clamav-milter 0.95.3 at mail X-Virus-Status: Clean Subject: [Geopriv] FYI: OGC Seeks Comments on MovingObjectSnapshot Standard X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 22:35:42 -0000 Thought that this might be of interest. Carl ----- Original Message ----- From: "OGC Press" To: ; Sent: Friday, July 23, 2010 3:01 PM Subject: [Pc] OGC Seeks Comments on MovingObjectSnapshot Standard > PRESS ANNOUNCEMENT FOR IMMEDIATE RELEASE > For information about this announcement, contact: > > Lance McKee > Senior Staff Writer > Open Geospatial Consortium (OGC) > Tel: +1-508-655-5858 > lmckee@opengeospatial.org > > ----------------------------------------------------------------------- > > > Wayland, Mass., 23 July, 2010 - The Open Geospatial Consortium, Inc. > (OGC®) is seeking public comment on a Geography Markup Language > (GML) XML encoding for describing the characteristics of a moving > object, such as a GPS enabled car. This candidate standard provides a > way of describing in simple terms the motion of an object, such as a > car driving through city streets or a person walking in a park. > > This candidate standard fills a need for "lightweight" packets of > tracking information, such as direction and velocity that can be > communicated between diverse platforms and applications supporting > mobile location-aware devices. The GML encoding used in this candidate > standard is compatible with a wide range of other standard encodings > used in other communities, such as emergency services. > > The candidate standard and information on submitting comments on this > document are available at > http://www.opengeospatial.org/standards/requests/69. > The public comment period closes on August 23rd, 2010. > > The OGC is an international consortium of more than 395 companies, > government agencies, research organizations, and universities > participating in a consensus process to develop publicly available > geospatial standards. OGC Standards empower technology developers to > make geospatial information and services accessible and useful with > any application that needs to be geospatially enabled. Visit the > OGC website at http://www.opengeospatial.org/. > _______________________________________________ > Pc mailing list > Pc@lists.opengeospatial.org > https://lists.opengeospatial.org/mailman/listinfo/pc > > From Martin.Thomson@andrew.com Sun Jul 25 03:28:03 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4683D3A67B2 for ; Sun, 25 Jul 2010 03:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-1.872, BAYES_20=-0.74] 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 gKJqK4JFG476 for ; Sun, 25 Jul 2010 03:28:02 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 32D003A68CD for ; Sun, 25 Jul 2010 03:28:02 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:64965 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S28611338Ab0GYK2V (ORCPT ); Sun, 25 Jul 2010 05:28:21 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sun, 25 Jul 2010 05:28:21 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Sun, 25 Jul 2010 18:28:17 +0800 From: "Thomson, Martin" To: "geopriv@ietf.org" Date: Sun, 25 Jul 2010 18:30:24 +0800 Thread-Topic: geopriv-policy and obscuring location Thread-Index: Acsr5GQHl/GgEaWjSiq43Fztv3OAXA== Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB7734FE@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {2D6D99C1-E2E8-4A50-BBB2-D3A8DF5E3DA5} x-cr-hashedpuzzle: AcVe AsZP BTc1 D3hj FKQx GzNf IgGu Jcdr OUXz PsbV RxeP SlZ+ SnXS UB4G U0Cj VJXX; 2; ZwBlAG8AcAByAGkAdgBAAGkAZQB0AGYALgBvAHIAZwA7AGgAYQBuAG4AZQBzAC4AdABzAGMAaABvAGYAZQBuAGkAZwBAAGcAbQB4AC4AbgBlAHQA; Sosha1_v1; 7; {2D6D99C1-E2E8-4A50-BBB2-D3A8DF5E3DA5}; bQBhAHIAdABpAG4ALgB0AGgAbwBtAHMAbwBuAEAAYQBuAGQAcgBlAHcALgBjAG8AbQA=; Sun, 25 Jul 2010 10:30:24 GMT; ZwBlAG8AcAByAGkAdgAtAHAAbwBsAGkAYwB5ACAAYQBuAGQAIABvAGIAcwBjAHUAcgBpAG4AZwAgAGwAbwBjAGEAdABpAG8AbgA= acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: [Geopriv] geopriv-policy and obscuring location X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 10:28:03 -0000 VGhlIGZpbmFsIGlzc3VlIHdpdGggZ2VvcHJpdi1wb2xpY3kgaXMgc3VtbWFyaXplZCBpbiBwaWN0 b3JpYWwgZm9ybSBoZXJlOg0KDQpodHRwOi8vd3d3LmZsaWNrci5jb20vcGhvdG9zLzQ5MDk5Mjg5 QE4wNS80ODI1OTA1NzExL2xpZ2h0Ym94Lw0KDQpJbiBzaG9ydDogd2UgY29uY2x1ZGUgdGhhdCBp ZiB5b3Ugd2FudCB0byBwcm90ZWN0IHRoZSBpbnN0YW50YW5lb3VzIGxvY2F0aW9uIGFuZCBwcmV2 ZW50IG1vdmVtZW50IGZyb20gZXhwb3NpbmcgdGhhdCBsb2NhdGlvbiwgdGhlbiB5b3UgaGF2ZSB0 byBvYnNjdXJlIGFueSBsb2NhdGlvbiBieSBfdHdpY2VfIHRoZSBhbW91bnQuDQoNCkZvciByYW5k b21pemF0aW9uIG9mIHggbWV0cmVzOg0KDQoxLiBZb3Ugc3RvcmUgdGhlIGN1cnJlbnQgbG9jYXRp b24uICBUaGlzIHByb2Nlc3MgaXMgcmVwZWF0ZWQgb25seSB3aGVuIHRoZSBvcmlnaW5hbCBsb2Nh dGlvbiBpcyBtb3JlIHRoYW4geCBtZXRyZXMgZnJvbSB0aGlzIGxvY2F0aW9uLg0KDQoyLiBZb3Ug bW92ZSB0aGUgbG9jYXRpb24gcmFuZG9tbHkgYnkgdXAgdG8geCBtZXRyZXMuICBZb3UgZXhwYW5k IHRoZSB1bmNlcnRhaW50eSByZWdpb24gdG8gZW5jb21wYXNzIHRoZSBhcmVhIHRoYXQgZG9lcyBu b3QgdHJpZ2dlciB0aGUgY3JlYXRpb24gb2YgYSBuZXcgbG9jYXRpb24gKHRoZSBhcmVhIGZyb20g c3RlcCAxKS4NCg0KVGhlIHVuY2VydGFpbnR5IG9mIHRoZSByZXN1bHRpbmcgbG9jYXRpb24gaXMg YXQgbGVhc3QgMnggbWV0cmVzLg0KDQpUaGlzIGNhbiBiZSBvdmVya2lsbCwgcGFydGljdWxhcmx5 IGZvciBzdGF0aWMgbG9jYXRpb25zLCBidXQgaXQgc2VlbXMgdG8gYmUgdGhlIGJlc3QgdHJhZGVv ZmYgYmV0d2VlbiBzaW1wbGljaXR5LCB1c2FiaWxpdHksIGFuZCBwcm90ZWN0aW9uLg0KDQpDcmVk aXQgdG8gUm9iZXJ0IFNwYXJrcyBhbmQgV2FycmVuIEt1bWFyaSBmb3IgZXhwb3NpbmcgdGhlIHBy b2JsZW0gYW5kIGJyYWluc3Rvcm1pbmcgc29sdXRpb25zLg0KDQotLU1hcnRpbg0K From Martin.Thomson@andrew.com Sun Jul 25 07:43:24 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22F9D3A6807 for ; Sun, 25 Jul 2010 07:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=-2.110, BAYES_50=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 UV73Cvygq6-E for ; Sun, 25 Jul 2010 07:43:22 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 557873A679C for ; Sun, 25 Jul 2010 07:43:22 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:30330 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S28620791Ab0GYOnm (ORCPT ); Sun, 25 Jul 2010 09:43:42 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sun, 25 Jul 2010 09:43:41 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Sun, 25 Jul 2010 22:43:37 +0800 From: "Thomson, Martin" To: Carl Reed Date: Sun, 25 Jul 2010 22:45:48 +0800 Thread-Topic: [Geopriv] FYI: OGC Seeks Comments on MovingObjectSnapshot Standard Thread-Index: Acsqt3SiyV7zJ4lyRyW8q+vINFjAAwBTgy4A Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB77350D@SISPE7MB1.commscope.com> References: <1E6CE5CA67A44717B7C930AD9E4259ED@CarlandSusieOf> In-Reply-To: <1E6CE5CA67A44717B7C930AD9E4259ED@CarlandSusieOf> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "requests@opengeospatial.org" , "geopriv@ietf.org" Subject: Re: [Geopriv] FYI: OGC Seeks Comments on MovingObjectSnapshot Standard X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 14:43:24 -0000 UHJlZmFjZToNCg0KVGhpcyBpcyBhbGwgd3JpdHRlbiB3aXRoIHRoZSBleHBlcmllbmNlIG9mIGJ1 aWxkaW5nIGEgKHZlcnkpIHNpbWlsYXIgc29sdXRpb24gZm9yIHRoZSBJRVRGOg0KDQogIDxodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNpbmdoLWdlb3ByaXYtcGlkZi1sby1k eW5hbWljLz4NCg0KQXMgd2VsbCBhcyBpbnZvbHZlbWVudCBpbiBXM0MgZ2VvbG9jYXRpb24gYW5k IHRoZWlyIGVmZm9ydHMgaW4gdGhpcyBmaWVsZC4NCg0KTXkgY29tbWVudHMgYXJlIG1vdGl2YXRl ZCBieSB3YW50aW5nIHRvIG1pbmltaXplIHRoZSBkaWZmZXJlbmNlcyBiZXR3ZWVuIHNvbHV0aW9u cy4NCg0KUEFSVCBBDQoNCjEuIEV2YWx1YXRvcjogTWFydGluIFRob21zb24gPG1haWx0bzptYXJ0 aW4udGhvbXNvbkBhbmRyZXcuY29tPg0KMi4gU3VibWlzc2lvbjogTW92aW5nIE9iamVjdCBTbmFw c2hvdCAoMTAtMDM0cjMpDQoNClBBUlQgQg0KDQoxLiBSZXF1aXJlbWVudDogbi9hDQoyLiBJbXBs ZW1lbnRhdGlvbiBTcGVjaWZpY2F0aW9uIFNlY3Rpb24gbnVtYmVyOiA1LjINCjMuIENyaXRpY2Fs aXR5OiBNYWpvcg0KNC4gQ29tbWVudHMvanVzdGlmaWNhdGlvbnMgZm9yIGNoYW5nZXM6DQpWZXJ0 aWNhbCBwb3NpdGlvbiBpcyBub3QgcHJvdmlkZWQgd2l0aGluIHRoZSBQb2ludCBlbGVtZW50LCBp dCBpcyBpbnN0ZWFkIHByb3ZpZGVkIGFzIGEgc2VwYXJhdGUgZWxlbWVudC4gIFdoaWxlIHRoZXJl IGlzIHByZWNlZGVudCBmb3IgdGhpcywgaXQgaXMgdW5uZWNlc3NhcnkgYW5kIGl0IGFjdHVhbGx5 IGNvbXBsaWNhdGVzIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgc3BlY2lmaWNhdGlvbi4gIFVz aW5nIDQzMjYgd2hlcmUgdGhlIGFsdGl0dWRlL2VsZXZhdGlvbiBpcyB1bmtub3duIGFuZCA0OTc5 IHdoZXJlIHRoZSBlbGV2YXRpb24gaXMga25vd24gd291bGQgYmUgYm90aCBzaW1wbGVyIGFuZCBl YXNpZXIgdG8gaW1wbGVtZW50Lg0KDQoxLiBSZXF1aXJlbWVudDogbi9hDQoyLiBJbXBsZW1lbnRh dGlvbiBTcGVjaWZpY2F0aW9uIFNlY3Rpb24gbnVtYmVyOiA1LjMNCjMuIENyaXRpY2FsaXR5OiBN aW5vcg0KNC4gQ29tbWVudHMvanVzdGlmaWNhdGlvbnMgZm9yIGNoYW5nZXM6DQpUaGUgZGVzY3Jp cHRpb24gb2YgdGhlIGxvY2FsIHRhbmdlbnQgcGxhbmUgY291bGQgYmUgZXhwYW5kZWQgdXBvbiB0 byBpbmNsdWRlIGEgbW9yZSByaWdvcm91cyBkZWZpbml0aW9uIGluIHRlcm1zIG9mIHRoZSBwb3Np dGlvbi4gIFRoaXMgZGVmaW5pdGlvbiBjb3VsZCBkZWZpbmUgdmVjdG9ycyBpbiBXR1M4NCBFQ0VG IENhcnRlc2lhbiBzcGFjZSwgZm9yIGV4YW1wbGUuDQoNCjEuIFJlcXVpcmVtZW50OiBuL2ENCjIu IEltcGxlbWVudGF0aW9uIFNwZWNpZmljYXRpb24gU2VjdGlvbiBudW1iZXI6IDcNCjMuIENyaXRp Y2FsaXR5OiBNYWpvcg0KNC4gQ29tbWVudHMvanVzdGlmaWNhdGlvbnMgZm9yIGNoYW5nZXM6DQpU aGUgc2NhbGFyQWNjZWxlcmF0aW9uIGNvbXBvbmVudCBsYWNrcyBkZXNjcmlwdGlvbiBpbiB0aGUg Ym9keSBvZiB0aGUgZG9jdW1lbnQuICBIb3dldmVyLCBJIHdvdWxkIHJlY29tbWVuZCBpdHMgcmVt b3ZhbCBlbnRpcmVseS4gIEEgbW9yZSBjb21wbGV0ZSAoYW5kIHRoZXJlZm9yZSB1c2VmdWwpIHNw ZWNpZmljYXRpb24gZm9yIGluc3RhbnRhbmVvdXMgYWNjZWxlcmF0aW9uIGlzIHVuZGVyIGRpc2N1 c3Npb24gaW4gdGhlIFczQyBpbiByZWxhdGlvbiB0byB0aGVpciBkZXZpY2Ugb3JpZW50YXRpb24g QVBJLg0KDQoxLiBSZXF1aXJlbWVudDogbi9hDQoyLiBJbXBsZW1lbnRhdGlvbiBTcGVjaWZpY2F0 aW9uIFNlY3Rpb24gbnVtYmVyOiA1LjQNCjMuIENyaXRpY2FsaXR5OiBNaW5vcg0KNC4gQ29tbWVu dHMvanVzdGlmaWNhdGlvbnMgZm9yIGNoYW5nZXM6DQpUaGUgZG9jdW1lbnQgb25seSBwcm92aWRl cyBmb3IgYSBkZWZpbml0aW9uIG9mIHZlbG9jaXR5IG9uIHRoZSBMVFAuICBUaGlzIGlzIGxpa2Vs eSB0byBiZSBjb25zdHJhaW5pbmcgZm9yIG1hbnkgYXBwbGljYXRpb25zLg0KDQoxLiBSZXF1aXJl bWVudDogbi9hDQoyLiBJbXBsZW1lbnRhdGlvbiBTcGVjaWZpY2F0aW9uIFNlY3Rpb24gbnVtYmVy OiA2DQozLiBDcml0aWNhbGl0eTogRWRpdG9yaWFsDQo0LiBDb21tZW50cy9qdXN0aWZpY2F0aW9u cyBmb3IgY2hhbmdlczoNClRoZSBleGFtcGxlIGRvZXMgbm90IGluY2x1ZGUgYW4gc3JzTmFtZSBh dHRyaWJ1dGUuDQoNCi0tTWFydGluDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogZ2VvcHJpdi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Z2VvcHJpdi1ib3VuY2VzQGll dGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgQ2FybCBSZWVkDQo+IFNlbnQ6IFNhdHVyZGF5LCAyNCBK dWx5IDIwMTAgMTI6MzYgQU0NCj4gVG86IGdlb3ByaXZAaWV0Zi5vcmcNCj4gU3ViamVjdDogW0dl b3ByaXZdIEZZSTogT0dDIFNlZWtzIENvbW1lbnRzIG9uIE1vdmluZ09iamVjdFNuYXBzaG90DQo+ IFN0YW5kYXJkDQo+IA0KPiBUaG91Z2h0IHRoYXQgdGhpcyBtaWdodCBiZSBvZiBpbnRlcmVzdC4N Cj4gDQo+IENhcmwNCj4gDQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4gRnJvbTog Ik9HQyBQcmVzcyIgPGFubm91bmNlQG9wZW5nZW9zcGF0aWFsLm9yZz4NCj4gVG86IDx0Y0BsaXN0 cy5vcGVuZ2Vvc3BhdGlhbC5vcmc+OyA8cGNAbGlzdHMub3Blbmdlb3NwYXRpYWwub3JnPg0KPiBT ZW50OiBGcmlkYXksIEp1bHkgMjMsIDIwMTAgMzowMSBQTQ0KPiBTdWJqZWN0OiBbUGNdIE9HQyBT ZWVrcyBDb21tZW50cyBvbiBNb3ZpbmdPYmplY3RTbmFwc2hvdCBTdGFuZGFyZA0KPiANCj4gDQo+ ID4gUFJFU1MgQU5OT1VOQ0VNRU5UIEZPUiBJTU1FRElBVEUgUkVMRUFTRQ0KPiA+IEZvciBpbmZv cm1hdGlvbiBhYm91dCB0aGlzIGFubm91bmNlbWVudCwgY29udGFjdDoNCj4gPg0KPiA+IExhbmNl IE1jS2VlDQo+ID4gU2VuaW9yIFN0YWZmIFdyaXRlcg0KPiA+IE9wZW4gR2Vvc3BhdGlhbCBDb25z b3J0aXVtIChPR0MpDQo+ID4gVGVsOiArMS01MDgtNjU1LTU4NTgNCj4gPiBsbWNrZWVAb3Blbmdl b3NwYXRpYWwub3JnDQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gLS0NCj4gPg0KPiA+DQo+ID4g V2F5bGFuZCwgTWFzcy4sIDIzIEp1bHksIDIwMTAgLSBUaGUgT3BlbiBHZW9zcGF0aWFsIENvbnNv cnRpdW0sIEluYy4NCj4gPiAoT0dDwq4pIGlzIHNlZWtpbmcgcHVibGljIGNvbW1lbnQgb24gYSBH ZW9ncmFwaHkgTWFya3VwIExhbmd1YWdlDQo+ID4gKEdNTCkgWE1MIGVuY29kaW5nIGZvciBkZXNj cmliaW5nIHRoZSBjaGFyYWN0ZXJpc3RpY3Mgb2YgYSBtb3ZpbmcNCj4gPiBvYmplY3QsIHN1Y2gg YXMgYSBHUFMgZW5hYmxlZCBjYXIuIFRoaXMgY2FuZGlkYXRlIHN0YW5kYXJkIHByb3ZpZGVzIGEN Cj4gPiB3YXkgb2YgZGVzY3JpYmluZyBpbiBzaW1wbGUgdGVybXMgdGhlIG1vdGlvbiBvZiBhbiBv YmplY3QsIHN1Y2ggYXMgYQ0KPiA+IGNhciBkcml2aW5nIHRocm91Z2ggY2l0eSBzdHJlZXRzIG9y IGEgcGVyc29uIHdhbGtpbmcgaW4gYSBwYXJrLg0KPiA+DQo+ID4gVGhpcyBjYW5kaWRhdGUgc3Rh bmRhcmQgZmlsbHMgYSBuZWVkIGZvciAibGlnaHR3ZWlnaHQiIHBhY2tldHMgb2YNCj4gPiB0cmFj a2luZyBpbmZvcm1hdGlvbiwgc3VjaCBhcyBkaXJlY3Rpb24gYW5kIHZlbG9jaXR5IHRoYXQgY2Fu IGJlDQo+ID4gY29tbXVuaWNhdGVkIGJldHdlZW4gZGl2ZXJzZSBwbGF0Zm9ybXMgYW5kIGFwcGxp Y2F0aW9ucyBzdXBwb3J0aW5nDQo+ID4gbW9iaWxlIGxvY2F0aW9uLWF3YXJlIGRldmljZXMuIFRo ZSBHTUwgZW5jb2RpbmcgdXNlZCBpbiB0aGlzDQo+IGNhbmRpZGF0ZQ0KPiA+IHN0YW5kYXJkIGlz IGNvbXBhdGlibGUgd2l0aCBhIHdpZGUgcmFuZ2Ugb2Ygb3RoZXIgc3RhbmRhcmQgZW5jb2Rpbmdz DQo+ID4gdXNlZCBpbiBvdGhlciBjb21tdW5pdGllcywgc3VjaCBhcyBlbWVyZ2VuY3kgc2Vydmlj ZXMuDQo+ID4NCj4gPiBUaGUgY2FuZGlkYXRlIHN0YW5kYXJkIGFuZCBpbmZvcm1hdGlvbiBvbiBz dWJtaXR0aW5nIGNvbW1lbnRzIG9uIHRoaXMNCj4gPiBkb2N1bWVudCBhcmUgYXZhaWxhYmxlIGF0 DQo+ID4gaHR0cDovL3d3dy5vcGVuZ2Vvc3BhdGlhbC5vcmcvc3RhbmRhcmRzL3JlcXVlc3RzLzY5 Lg0KPiA+IFRoZSBwdWJsaWMgY29tbWVudCBwZXJpb2QgY2xvc2VzIG9uIEF1Z3VzdCAyM3JkLCAy MDEwLg0KPiA+DQo+ID4gVGhlIE9HQyBpcyBhbiBpbnRlcm5hdGlvbmFsIGNvbnNvcnRpdW0gb2Yg bW9yZSB0aGFuIDM5NSBjb21wYW5pZXMsDQo+ID4gZ292ZXJubWVudCBhZ2VuY2llcywgcmVzZWFy Y2ggb3JnYW5pemF0aW9ucywgYW5kIHVuaXZlcnNpdGllcw0KPiA+IHBhcnRpY2lwYXRpbmcgaW4g YSBjb25zZW5zdXMgcHJvY2VzcyB0byBkZXZlbG9wIHB1YmxpY2x5IGF2YWlsYWJsZQ0KPiA+IGdl b3NwYXRpYWwgc3RhbmRhcmRzLiBPR0MgU3RhbmRhcmRzIGVtcG93ZXIgdGVjaG5vbG9neSBkZXZl bG9wZXJzIHRvDQo+ID4gbWFrZSBnZW9zcGF0aWFsIGluZm9ybWF0aW9uIGFuZCBzZXJ2aWNlcyBh Y2Nlc3NpYmxlIGFuZCB1c2VmdWwgd2l0aA0KPiA+IGFueSBhcHBsaWNhdGlvbiB0aGF0IG5lZWRz IHRvIGJlIGdlb3NwYXRpYWxseSBlbmFibGVkLiBWaXNpdCB0aGUNCj4gPiBPR0Mgd2Vic2l0ZSBh dCAgIGh0dHA6Ly93d3cub3Blbmdlb3NwYXRpYWwub3JnLy4NCj4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IFBjIG1haWxpbmcgbGlzdA0KPiA+ IFBjQGxpc3RzLm9wZW5nZW9zcGF0aWFsLm9yZw0KPiA+IGh0dHBzOi8vbGlzdHMub3Blbmdlb3Nw YXRpYWwub3JnL21haWxtYW4vbGlzdGluZm8vcGMNCj4gPg0KPiA+DQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBHZW9wcml2IG1haWxpbmcg bGlzdA0KPiBHZW9wcml2QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZ2VvcHJpdg0K From creed@opengeospatial.org Mon Jul 26 07:11:02 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EBFC3A6B84 for ; Mon, 26 Jul 2010 07:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.635 X-Spam-Level: X-Spam-Status: No, score=0.635 tagged_above=-999 required=5 tests=[AWL=-2.366, BAYES_95=3, 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 YX0Gs--tfroL for ; Mon, 26 Jul 2010 07:11:01 -0700 (PDT) Received: from mail.opengeospatial.org (mail.opengeospatial.org [66.244.86.40]) by core3.amsl.com (Postfix) with ESMTP id BC15D3A6982 for ; Mon, 26 Jul 2010 07:11:00 -0700 (PDT) Received: from CarlandSusieOf (c-76-25-20-162.hsd1.co.comcast.net [76.25.20.162]) (authenticated bits=0) by mail.opengeospatial.org (8.13.8/8.13.8/Debian-3+etch1) with ESMTP id o6QEBJC7005843 for ; Mon, 26 Jul 2010 10:11:20 -0400 Message-ID: <6EA5EDCFFE43431E9692876C7838A6C7@CarlandSusieOf> From: "Carl Reed" To: Date: Mon, 26 Jul 2010 08:07:44 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B7_01CB2C99.A07B6190" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 X-Virus-Scanned: clamav-milter 0.95.3 at mail X-Virus-Status: Clean Subject: [Geopriv] MIT Tech article on privacy, location, and friend finder applications X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:11:02 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00B7_01CB2C99.A07B6190 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thought this might be of interest. Use cases etc. http://www.technologyreview.com/computing/25855/page1/ Carl Reed, PhD CTO and Executive Director Specification Program OGC The OGC: Helping the World to Communicate Geographically --------------------- This communication, including attachments, is for the exclusive use of = addressee and may contain proprietary, confidential or privileged = information. If you are not the intended recipient, any use, copying, = disclosure, dissemination or distribution is strictly prohibited. If you = are not the intended recipient, please notify the sender immediately by = return email and delete this communication and destroy all copies. "The important thing is not to stop questioning." -- Albert Einstein=20 "Security is mostly a superstition. It does not exist in nature. Life is = either a daring adventure or nothing." -- Helen Keller ------=_NextPart_000_00B7_01CB2C99.A07B6190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thought this might be of interest. Use cases etc.
 
http://ww= w.technologyreview.com/computing/25855/page1/
 
 
Carl Reed, PhD
CTO and Executive Director Specification=20 Program
OGC
 
The OGC: Helping the World to Communicate Geographically
 
---------------------
 
This communication, including attachments, is for the exclusive use = of=20 addressee and may contain proprietary, confidential or privileged = information.=20 If you are not the intended recipient, any use, copying, disclosure,=20 dissemination or distribution is strictly prohibited. If you are not the = intended recipient, please notify the sender  immediately by return = email=20 and delete this communication and destroy all copies.
 
"The important thing is not to stop questioning." -- Albert = Einstein=20
"Security is mostly a superstition. It does not exist in nature. = Life is=20 either a daring adventure or nothing." -- Helen Keller =
------=_NextPart_000_00B7_01CB2C99.A07B6190-- From Martin.Thomson@andrew.com Mon Jul 26 23:00:15 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A998B3A6899 for ; Mon, 26 Jul 2010 23:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.27 X-Spam-Level: X-Spam-Status: No, score=-3.27 tagged_above=-999 required=5 tests=[AWL=-0.671, BAYES_00=-2.599] 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 trca9AluJJAp for ; Mon, 26 Jul 2010 23:00:08 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id DD0283A67F9 for ; Mon, 26 Jul 2010 23:00:07 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:7792 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S28702352Ab0G0GA3 (ORCPT ); Tue, 27 Jul 2010 01:00:29 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 27 Jul 2010 00:58:40 -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 13:58:38 +0800 From: "Thomson, Martin" To: Alissa Cooper , Richard L.Barnes Date: Tue, 27 Jul 2010 13:58:37 +0800 Thread-Topic: [Geopriv] Fwd: New Version Notification for draft-barnes-geopriv-policy-uri-01 Thread-Index: Acsqg4sEKtpAMj9oQ0++lOPphTQAoACvsr0g Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB773702@SISPE7MB1.commscope.com> References: <20100530233709.84DDF3A6967@core3.amsl.com> <28F4411F-1C65-4FAF-94F6-635ED462E152@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "geopriv@ietf.org" Subject: Re: [Geopriv] Fwd: New Version Notification for draft-barnes-geopriv-policy-uri-01 X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 06:00:16 -0000 SGkgQWxpc3NhLA0KDQpJdCBsb29rcyBsaWtlIG1vc3Qgb2YgdGhpcyBpcyBhbiBhcnRlZmFjdCBv ZiBteSBpbmFiaWxpdHkgdG8gZ2VuZXJhdGUgc2FuZSBwcm9zZSA6KSAgSQ0KDQogDQo+IDMuMSBz YXlzOg0KLi4uDQo+IEkgZmluZCB0aGUgbXVsdGlwbGUgY2F2ZWF0cyBoZXJlIHRvIGJlIGNvbmZ1 c2luZy4gSSB0aGluayB0aGUgb3V0Y29tZQ0KPiB5b3UncmUgbG9va2luZyBmb3IgaXMgdGhhdCBh biBMUyBTSE9VTEQgYWxsb3cgYWxsIHJlcXVlc3RzLCBidXQgaXQgTUFZDQo+IGRlbnkgY2VydGFp biByZXF1ZXN0cyBiYXNlZCBvbiBsb2NhbCBhdXRob3JpemF0aW9uIHBvbGljeSAoZS5nLiwNCj4g YWxsb3dpbmcgR0VUcyBidXQgbm90IFBVVHMsIG9yIG9ubHkgYWxsb3dpbmcgZGVyZWZlcmVuY2Vz IGZyb20gY2VydGFpbg0KPiBjbGllbnRzKS4gSXMgdGhhdCByaWdodD8NCg0KQ29ycmVjdC4gIEkn bGwgdGFrZSBhIHNlY29uZCBnbyBhdCB0aGlzLg0KDQo+IDMuMjogVGhpcyBzZWN0aW9uIGRpc2N1 c3NlcyBib3RoIHBvbGljaWVzIGZvciBhY2Nlc3MgdG8gbG9jYXRpb24gYW5kDQo+IHBvbGljaWVz IGZvciBhY2Nlc3MgdG8gcG9saWN5IFVSSXMuIENvbWJpbmluZyB0aGVtIGxpa2UgdGhpcyBpcyBw cmV0dHkNCj4gY29uZnVzaW5nLCBhbmQgSSdtIG5vdCBzdXJlIHRoYXQgZWl0aGVyIHBhcnQgaXMg Y29tcGxldGUuIEZvciBhY2Nlc3MNCj4gdG8gbG9jYXRpb24sIHlvdSBzYXkgdGhhdCB0aGUgZGVm YXVsdCBwb2xpY3kgaGFzIHRvIGJlIHdoYXQgaXQgd291bGQNCj4gYmUgaWYgdGhlcmUgd2VyZSBu byBwb2xpY3ksIGJ1dCB5b3UgZG9uJ3Qgc2F5IHdoYXQgdGhlIGRlZmF1bHQgcG9saWN5DQo+IGlz LiBUaGUgZXhhbXBsZSBpbiA1LjMgc3VnZ2VzdHMgdGhhdCB0aGUgZGVmYXVsdCBwb2xpY3kncw0K PiB0cmFuc2Zvcm1hdGlvbnMgYXJlDQo+IA0KPiAgICAgICAgIDx0cmFuc2Zvcm1hdGlvbnM+DQo+ ICAgICAgICAgICA8Z3A6cHJvdmlkZS1sb2NhdGlvbi8+DQo+ICAgICAgICAgPC90cmFuc2Zvcm1h dGlvbnM+DQo+IA0KPiBEaWRuJ3QgdGhlIGRlZmF1bHQgcG9saWN5IHVzZWQgdG8gYWxzbyBpbmNs dWRlIHJldHJhbnNtaXNzaW9uLWFsbG93ZWQNCj4gPSBGQUxTRSBhbmQgcmV0ZW50aW9uLWV4cGly eSA9IDI0IGhvdXJzPyBXaGF0IGhhcHBlbmVkIHRvIHRob3NlPw0KDQpUaGFua3MuICBXZSBzaG91 bGQgYmUgZXhwbGljaXQgYWJvdXQgd2hhdCB0aGUgZGVmYXVsdCBwb2xpY3kgaXMuICBBbmQgSSBt aXNzZWQgdGhvc2UuDQogDQo+IEZvciBhY2Nlc3MgdG8gcG9saWN5IFVSSXMsIGl0IHNheXMNCj4g DQo+ICJBIExvY2F0aW9uIFNlcnZlciBjaG9vc2VzIHdoZXRoZXIgb3Igbm90IHRvIHByb3ZpZGUg YSBwb2xpY3kgVVJJDQo+IGJhc2VkIG9uIGxvY2FsIHBvbGljeS4iDQo+IA0KPiBJJ20gY29uZnVz ZWQgYWJvdXQgdGhlIExTICJwcm92aWRpbmciIGEgVVJJIGluIEhFTEQuIFlvdSBkZXNjcmliZSBh DQo+IG1lY2hhbmlzbSBpbiA1LjEgZm9yICpjcmVhdGluZyogYSBVUkkuIEJ1dCBob3cgZG9lcyBh biBMUyBwcm92aWRlIGENCj4gVVJJIHRoYXQgaGFzIHByZXZpb3VzbHkgYmVlbiBjcmVhdGVkPw0K DQpJdCBkb2Vzbid0IGhhdmUgdG8gYW5kIGl0IHByb2JhYmx5IHNob3VsZCBub3QuICBJJ2xsIGV4 cGFuZCBvbiB0aGlzIGJlbG93Lg0KDQo+IElmIGEgVGFyZ2V0IGlzc3VlcyB0aGUgSEVMRA0KPiBy ZXF1ZXN0IGluIDUuMSwgYW5kIHRoZW4gYSB0aGlyZCBwYXJ0eSBpc3N1ZXMgYSBxdWVyeSBjb250 YWluaW5nIGJvdGgNCj4gYSAicmVxdWVzdFBvbGljeVVyaSIgZWxlbWVudCBhbmQgYSAiZGV2aWNl IiBlbGVtZW50LCBkb2VzIHRoZSBvcmlnaW5hbA0KPiBVUkkgZ2V0IG92ZXJ3cml0dGVuPyBPciBp cyB0aGF0IHRoZSBwb2ludCBhdCB3aGljaCB0aGUgImxvY2FsIHBvbGljeSINCj4gcmVmZXJlbmNl ZCBhYm92ZSBnZXRzIGNoZWNrZWQgdG8gc2VlIHdoZXRoZXIgdGhlIHRoaXJkIHBhcnR5IGlzDQo+ IGF1dGhvcml6ZWQgdG8gb3ZlcndyaXRlIChvciByZWNlaXZlPykgdGhlIFVSST8NCg0KQSBwb2xp Y3kgVVJJIGFwcGxpZXMgdG8gYSBzaW5nbGUgbG9jYXRpb24gVVJJIC0gaWYgd2UgaGF2ZW4ndCB0 aGVuIHdlJ2QgYmV0dGVyIGZpeCBpdC4NCg0KRm9sbG93aW5nIG9uIGZyb20gdGhpcywgd2UgZG9u J3Qgd2FudCB0byBwcm92aWRlIHRoZSBzYW1lIGxvY2F0aW9uIFVSSSB0byB1bmNvcnJlbGF0ZWQg cmVxdWVzdHMgZm9yIHRoZSBzYW1lIFRhcmdldCwgd2hpY2ggbWVhbnMgZGlmZmVyZW50IHBvbGlj eSBVUklzLiAgU29tZSB0ZXh0IG9uIHRoaXMgd291bGQgYmUgYSBnb29kIGlkZWEuICBJIHRoaW5r IHRoYXQgdGhlcmUgbWlnaHQgYmUgc29tZXRoaW5nIGluIFJGQzU4MDggb24gdW5pcXVlbmVzcyBv ZiBVUklzLCBidXQgaWYgdGhlcmUgaXNuJ3Qgd2Ugc2hvdWxkIG1ha2UgZXhwbGljaXQgbm90ZSBv ZiBpdC4NCg0KVGhlIG1haW4gcmVhc29uIGZvciB0aGlzIGlzIHRoYXQgYSBzaW5nbGUgVGFyZ2V0 IGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIHRoZSBMSVMsIGNvdWxkIGFjdHVhbGx5IGJlIHNldmVy YWwgZGlmZmVyZW50IGRldmljZXMgYW5kIC0gYnkgZXh0ZW5zaW9uIC0gcGVvcGxlLiAgVGhlc2Ug cGVvcGxlIGNhbiBoYXZlIGRpZmZlcmVudCBwcmVmZXJlbmNlcyBhbmQgcG9saWNpZXMgYW5kIHRo ZXkgbWlnaHQgd2FudCB0byBlbnN1cmUgdGhhdCB0aGVpciBwb2xpY2llcyAoYW5kIGlkZW50aXR5 KSByZW1haW4gZGlzdGluY3QuICBPbmNlIHlvdSBzdGFydCBhdHRyaWJ1dGluZyBwb2xpY3kgdG8g VVJJcywgZ2l2aW5nIGVhY2ggYSB1bmlxdWUgbG9jYXRpb24gVVJJIGVuc3VyZXMgdGhhdCB0aGV5 IGRvbid0IHRyYW1wbGUgb24gZWFjaCBvdGhlcidzIHBvbGljaWVzLiAgRXZlbiB0aGUgYWJpbGl0 eSB0byBzZWUgYW5vdGhlciBwZXJzb24ncyBwb2xpY3kgaXMgc3VmZmljaWVudCByZWFzb24gZm9y IHNlcGFyYXRpb24uDQoNCldoZW4geW91IGFkZCBhIHRoaXJkIHBhcnR5IGludG8gdGhlIGVxdWF0 aW9uLCBpdCBnZXRzIGV2ZW4gd29yc2UuICBGb3IgaW5zdGFuY2UsIHlvdSBkb24ndCB3YW50IHlv dXIgc2VydmljZSBwcm92aWRlciBtZXNzaW5nIHdpdGggeW91ciBwb2xpY3kuICBJZiB0aGV5IGhh dmUgdG8gc2V0IHBvbGljeSwgdGhlbiB0aGV5IGNhbiAoYW5kIHNob3VsZCkgZG8gc28gdHJhbnNw YXJlbnRseSBieSBhbHRlcmluZyB0aGUgaW5pdGlhbCBwb2xpY3kgeW91IGdldCBmb3IgdGhlIGxv Y2F0aW9uIFVSSSBhbmQgcHJldmVudGluZyB5b3UgZnJvbSBkZXN0cm95aW5nIHRoZWlyIHJ1bGVz Lg0KDQpPZiBjb3Vyc2UsIHVuaXF1ZW5lc3Mgb2YgVVJJcyBtYXR0ZXJzIGNvbnNpZGVyYWJseSBs ZXNzIGZvciBwdXJlIGF1dGhvcml6YXRpb24gYnkgcG9zc2Vzc2lvbi4NCg0KT2J2aW91c2x5LCB0 aGlzIG5lZWRzIHRleHQuICBJJ2xsIHByb3Bvc2Ugc29tZXRoaW5nIGxhdGVyLg0KDQo+IEFzIHRv IHlvdXIgcXVlc3Rpb24gYmVsb3cgYWJvdXQgTFNlcyBwcm92aWRpbmcgb3RoZXIgcG9saWN5IFVS SXMsDQo+IHNpbmNlIHRoZSByZXF1ZXN0cyBhcmVuJ3QgY29taW5nIHZpYSBIRUxEIG9yIERIQ1As IHdoYXQgd291bGQgeW91DQo+IGludGVuZCB0byBzcGVjaWZ5IG90aGVyIHRoYW4gbWFraW5nIGEg Z2VuZXJpYyBzdGF0ZW1lbnQgdGhhdCBhbiBMUyBjYW4NCj4gaGFuZCBvdXQgcG9saWN5IFVSSXMg dmlhIG90aGVyIHByb3RvY29scz8gSXQgc2VlbXMgbGlrZSBhbiBMUyB0aGF0DQo+IGltcGxlbWVu dHMgb3RoZXIgcHJvdG9jb2xzIGNvdWxkIGRvIHRoYXQgYWxyZWFkeSBpZiBpdCB3YW50ZWQgdG8u DQoNClRoZSBpZGVhIHRoYXQgYSBwb2xpY3kgVVJJIGFwcGxpZXMgdG8gYSBzcGVjaWZpYyBsb2Nh dGlvbiBVUkkgdGVuZHMgdG8gYmlhcyBtZSBhZ2FpbnN0IHdoYXQgUmljaGFyZCBpcyB0YWxraW5n IGFib3V0LiAgVGhlIHNhbWUgdW5kZXJseWluZyByZWFzb25zIGFwcGx5Lg0KDQo+IA0KPiBBbGlz c2ENCg== From jmpolk@cisco.com Wed Jul 28 03:03:02 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0FB83A6A4D for ; Wed, 28 Jul 2010 03:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.565 X-Spam-Level: X-Spam-Status: No, score=-10.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Iio6aTvyXkTb for ; Wed, 28 Jul 2010 03:03:01 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A001928C118 for ; Wed, 28 Jul 2010 03:03:01 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADOdT0xAZnwM/2dsb2JhbACfbXGkOJsUhTYEhAw X-IronPort-AV: E=Sophos;i="4.55,273,1278288000"; d="scan'208";a="140196015" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 28 Jul 2010 10:03:24 +0000 Received: from jmpolk-wxp01.cisco.com (ams3-vpn-dhcp3629.cisco.com [10.61.78.45]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6SA3Nae014796 for ; Wed, 28 Jul 2010 10:03:23 GMT Message-Id: <201007281003.o6SA3Nae014796@rtp-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 28 Jul 2010 04:57:03 -0500 To: geopriv@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Geopriv] DHCP Location URI Option -08 submitted X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 10:03:02 -0000 Geopriv Working with Richard help with the text, I submitted a new version of http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option-08.txt with the following changes to the last paragraph of the intro, I have replaced the sentence: "All of this is outside the scope of this document (since this will not be accomplished using DHCP). " with "This document does not provide mechanisms for the LS to tell the client about policies or for the client to specify a policy for the LS. While an LS should apply an appropriate access-control policy, clients must assume that the LS will provide location in response to any request (following the possession model [RFC5808]). For further discussion of privacy, see the Security Considerations. " In the security section, I replaced the following text "...not secure in a practical sense ..." with "does not provide security at the network layer. Instead, it relies on lower-layer security mechanisms. " and replaced "That said, having the location URI does not mean an unauthorized entity has the location of a client. The location URI still needs to be dereferenced to learn the location of the client. This dereferencing function, which is not done using DHCP, is done by requesting the location record at a Location Server, which can challenge each request it receives based on the policy provided by the Ruleholder. The Ruleholder, as defined in RFC 3693, configures the authentication and authorization policies for the location revelation of a Target. This includes giving out more or less precise location information in a response, therefore it can answer a bad-hat, but not allow it from learning exactly where a client is." with "Once a client has a URI, it needs information on how the location server will control access to dereference requests. A client might treat a tightly access-controlled URI differently from one that can be dereferenced by anyone on the Internet (i.e., one following the "possession model"). With the LuriTypes defined in this document, the DHCP option for delivering location URIs can only tell the user how long the URI will be valid. Since the client doesn't know what policy will be applied during this validity interval, clients MUST handle location URIs as if they could be dereferenced by anybody until they expire. For example, such open location URIs should only be transmitted in encrypted channels. Nonetheless, location servers SHOULD apply appropriate access control policies, for example by limiting the number of queries that any given client can make, or limiting access to users within an enterprise. Extensions to this option, such as [ID-POLICY-URI] can provide mechanisms for accessing and provisioning policy. Giving users access to policy information will allow them to make more informed decisions about how to use their location URIs. Allowing users to provide policy information to the LS will enable them to tailor access control policies to their needs (within the bounds of policy that the LS will accept)." From root@core3.amsl.com Wed Jul 28 03:15:09 2010 Return-Path: X-Original-To: geopriv@ietf.org Delivered-To: geopriv@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D218D28C13C; Wed, 28 Jul 2010 03:15:05 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100728101508.D218D28C13C@core3.amsl.com> Date: Wed, 28 Jul 2010 03:15:05 -0700 (PDT) Cc: geopriv@ietf.org Subject: [Geopriv] I-D Action:draft-ietf-geopriv-dhcp-lbyr-uri-option-08.txt X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 10:15:09 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Geographic Location/Privacy Working Group of the IETF. Title : Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI) Author(s) : J. Polk Filename : draft-ietf-geopriv-dhcp-lbyr-uri-option-08.txt Pages : 13 Date : 2010-07-28 This document creates a Dynamic Host Configuration Protocol (DHCP) Option for transmitting a client's geolocation Uniform Resource Identifier (URI) of a client, which can be dereferenced in a separate transaction by the client or an entity the client sends this URI to. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-geopriv-dhcp-lbyr-uri-option-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-28030100.I-D@ietf.org> --NextPart-- From Martin.Thomson@andrew.com Wed Jul 28 03:27:25 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E80A3A6A75 for ; Wed, 28 Jul 2010 03:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.159 X-Spam-Level: X-Spam-Status: No, score=-3.159 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599] 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 ZQpbP9dIsn4r for ; Wed, 28 Jul 2010 03:27:05 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id B0F853A6A6B for ; Wed, 28 Jul 2010 03:27:01 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:40658 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S207483Ab0G1K1Y (ORCPT ); Wed, 28 Jul 2010 05:27:24 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Wed, 28 Jul 2010 05:27:24 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 28 Jul 2010 18:27:21 +0800 From: "Thomson, Martin" To: "James M. Polk" , "geopriv@ietf.org" Date: Wed, 28 Jul 2010 18:29:34 +0800 Thread-Topic: [Geopriv] DHCP Location URI Option -08 submitted Thread-Index: AcsuPos11hHvLIB2Qgad6oU+/bSLoQAASRGA Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB7738A2@SISPE7MB1.commscope.com> References: <201007281003.o6SA3Nae014796@rtp-core-1.cisco.com> In-Reply-To: <201007281003.o6SA3Nae014796@rtp-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [Geopriv] DHCP Location URI Option -08 submitted X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 10:27:25 -0000 VGhhdCdzIGdyZWF0LiAgVGhpcyBhZGRyZXNzZXMgdGhlIGF1dGhvcml6YXRpb24gcG9saWN5IGFz cGVjdHMgdmVyeSB3ZWxsLg0KDQotLU1hcnRpbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IGdlb3ByaXYtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmdlb3ByaXYtYm91 bmNlc0BpZXRmLm9yZ10gT24NCj4gQmVoYWxmIE9mIEphbWVzIE0uIFBvbGsNCj4gU2VudDogV2Vk bmVzZGF5LCAyOCBKdWx5IDIwMTAgMTE6NTcgQU0NCj4gVG86IGdlb3ByaXZAaWV0Zi5vcmcNCj4g U3ViamVjdDogW0dlb3ByaXZdIERIQ1AgTG9jYXRpb24gVVJJIE9wdGlvbiAtMDggc3VibWl0dGVk DQo+IA0KPiBHZW9wcml2DQo+IA0KPiBXb3JraW5nIHdpdGggUmljaGFyZCBoZWxwIHdpdGggdGhl IHRleHQsIEkgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YNCj4gaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1nZW9wcml2LWRoY3AtbGJ5ci11cmktDQo+IG9w dGlvbi0wOC50eHQNCj4gd2l0aCB0aGUgZm9sbG93aW5nIGNoYW5nZXMNCj4gDQo+IHRvIHRoZSBs YXN0IHBhcmFncmFwaCBvZiB0aGUgaW50cm8sIEkgaGF2ZSByZXBsYWNlZCB0aGUgc2VudGVuY2U6 DQo+IA0KPiAiQWxsIG9mIHRoaXMgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVu dCAoc2luY2UgdGhpcyB3aWxsDQo+IG5vdCBiZSBhY2NvbXBsaXNoZWQgdXNpbmcgREhDUCkuICIN Cj4gDQo+IHdpdGgNCj4gDQo+ICJUaGlzIGRvY3VtZW50IGRvZXMgbm90IHByb3ZpZGUgbWVjaGFu aXNtcyBmb3IgdGhlIExTIHRvIHRlbGwgdGhlDQo+IGNsaWVudCBhYm91dCBwb2xpY2llcyBvciBm b3IgdGhlIGNsaWVudCB0byBzcGVjaWZ5IGEgcG9saWN5IGZvciB0aGUNCj4gTFMuIFdoaWxlIGFu IExTIHNob3VsZCBhcHBseSBhbiBhcHByb3ByaWF0ZSBhY2Nlc3MtY29udHJvbCBwb2xpY3ksDQo+ IGNsaWVudHMgbXVzdCBhc3N1bWUgdGhhdCB0aGUgTFMgd2lsbCBwcm92aWRlIGxvY2F0aW9uIGlu IHJlc3BvbnNlIHRvDQo+IGFueSByZXF1ZXN0IChmb2xsb3dpbmcgdGhlIHBvc3Nlc3Npb24gbW9k ZWwgW1JGQzU4MDhdKS4gIEZvciBmdXJ0aGVyDQo+IGRpc2N1c3Npb24gb2YgcHJpdmFjeSwgc2Vl IHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucy4gIg0KPiANCj4gSW4gdGhlIHNlY3VyaXR5IHNl Y3Rpb24sIEkgcmVwbGFjZWQgdGhlIGZvbGxvd2luZyB0ZXh0DQo+IA0KPiAiLi4ubm90IHNlY3Vy ZSBpbiBhIHByYWN0aWNhbCBzZW5zZSAuLi4iDQo+IA0KPiB3aXRoDQo+IA0KPiAiZG9lcyBub3Qg cHJvdmlkZSBzZWN1cml0eSBhdCB0aGUgbmV0d29yayBsYXllci4gIEluc3RlYWQsIGl0IHJlbGll cw0KPiBvbiBsb3dlci1sYXllciBzZWN1cml0eSBtZWNoYW5pc21zLiAgIg0KPiANCj4gYW5kIHJl cGxhY2VkDQo+IA0KPiAiVGhhdCBzYWlkLCBoYXZpbmcgdGhlIGxvY2F0aW9uIFVSSSBkb2VzIG5v dCBtZWFuIGFuIHVuYXV0aG9yaXplZA0KPiAgICAgZW50aXR5IGhhcyB0aGUgbG9jYXRpb24gb2Yg YSBjbGllbnQuICBUaGUgbG9jYXRpb24gVVJJIHN0aWxsIG5lZWRzDQo+ICAgICB0byBiZSBkZXJl ZmVyZW5jZWQgdG8gbGVhcm4gdGhlIGxvY2F0aW9uIG9mIHRoZSBjbGllbnQuICBUaGlzDQo+ICAg ICBkZXJlZmVyZW5jaW5nIGZ1bmN0aW9uLCB3aGljaCBpcyBub3QgZG9uZSB1c2luZyBESENQLCBp cyBkb25lIGJ5DQo+ICAgICByZXF1ZXN0aW5nIHRoZSBsb2NhdGlvbiByZWNvcmQgYXQgYSBMb2Nh dGlvbiBTZXJ2ZXIsIHdoaWNoIGNhbg0KPiAgICAgY2hhbGxlbmdlIGVhY2ggcmVxdWVzdCBpdCBy ZWNlaXZlcyBiYXNlZCBvbiB0aGUgcG9saWN5IHByb3ZpZGVkIGJ5DQo+ICAgICB0aGUgUnVsZWhv bGRlci4gIFRoZSBSdWxlaG9sZGVyLCBhcyBkZWZpbmVkIGluIFJGQyAzNjkzLCBjb25maWd1cmVz DQo+ICAgICB0aGUgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gcG9saWNpZXMgZm9y IHRoZSBsb2NhdGlvbg0KPiAgICAgcmV2ZWxhdGlvbiBvZiBhIFRhcmdldC4gIFRoaXMgaW5jbHVk ZXMgZ2l2aW5nIG91dCBtb3JlIG9yIGxlc3MNCj4gICAgIHByZWNpc2UgbG9jYXRpb24gaW5mb3Jt YXRpb24gaW4gYSByZXNwb25zZSwgdGhlcmVmb3JlIGl0IGNhbiBhbnN3ZXINCj4gICAgIGEgYmFk LWhhdCwgYnV0IG5vdCBhbGxvdyBpdCBmcm9tIGxlYXJuaW5nIGV4YWN0bHkgd2hlcmUgYSBjbGll bnQNCj4gaXMuIg0KPiANCj4gd2l0aA0KPiANCj4gICAgICJPbmNlIGEgY2xpZW50IGhhcyBhIFVS SSwgaXQgbmVlZHMgaW5mb3JtYXRpb24gb24gaG93IHRoZQ0KPiBsb2NhdGlvbiBzZXJ2ZXIgd2ls bCBjb250cm9sIGFjY2VzcyB0byBkZXJlZmVyZW5jZSByZXF1ZXN0cy4gIEENCj4gY2xpZW50IG1p Z2h0IHRyZWF0IGEgdGlnaHRseSBhY2Nlc3MtY29udHJvbGxlZCBVUkkgZGlmZmVyZW50bHkgZnJv bQ0KPiBvbmUgdGhhdCBjYW4gYmUgZGVyZWZlcmVuY2VkIGJ5IGFueW9uZSBvbiB0aGUgSW50ZXJu ZXQgKGkuZS4sIG9uZQ0KPiBmb2xsb3dpbmcgdGhlICJwb3NzZXNzaW9uIG1vZGVsIikuICBXaXRo IHRoZSBMdXJpVHlwZXMgZGVmaW5lZCBpbg0KPiB0aGlzIGRvY3VtZW50LCB0aGUgREhDUCBvcHRp b24gZm9yIGRlbGl2ZXJpbmcgbG9jYXRpb24gVVJJcyBjYW4gb25seQ0KPiB0ZWxsIHRoZSB1c2Vy IGhvdyBsb25nIHRoZSBVUkkgd2lsbCBiZSB2YWxpZC4gIFNpbmNlIHRoZSBjbGllbnQNCj4gZG9l c24ndCBrbm93IHdoYXQgcG9saWN5IHdpbGwgYmUgYXBwbGllZCBkdXJpbmcgdGhpcyB2YWxpZGl0 eQ0KPiBpbnRlcnZhbCwgY2xpZW50cyBNVVNUIGhhbmRsZSBsb2NhdGlvbiBVUklzIGFzIGlmIHRo ZXkgY291bGQgYmUNCj4gZGVyZWZlcmVuY2VkIGJ5IGFueWJvZHkgdW50aWwgdGhleSBleHBpcmUu ICBGb3IgZXhhbXBsZSwgc3VjaCBvcGVuDQo+IGxvY2F0aW9uIFVSSXMgc2hvdWxkIG9ubHkgYmUg dHJhbnNtaXR0ZWQgaW4gZW5jcnlwdGVkDQo+IGNoYW5uZWxzLiAgTm9uZXRoZWxlc3MsIGxvY2F0 aW9uIHNlcnZlcnMgU0hPVUxEIGFwcGx5IGFwcHJvcHJpYXRlDQo+IGFjY2VzcyBjb250cm9sIHBv bGljaWVzLCBmb3IgZXhhbXBsZSBieSBsaW1pdGluZyB0aGUgbnVtYmVyIG9mDQo+IHF1ZXJpZXMg dGhhdCBhbnkgZ2l2ZW4gY2xpZW50IGNhbiBtYWtlLCBvciBsaW1pdGluZyBhY2Nlc3MgdG8gdXNl cnMNCj4gd2l0aGluIGFuIGVudGVycHJpc2UuDQo+IA0KPiBFeHRlbnNpb25zIHRvIHRoaXMgb3B0 aW9uLCBzdWNoIGFzIFtJRC1QT0xJQ1ktVVJJXSBjYW4gcHJvdmlkZQ0KPiBtZWNoYW5pc21zIGZv ciBhY2Nlc3NpbmcgYW5kIHByb3Zpc2lvbmluZyBwb2xpY3kuICBHaXZpbmcgdXNlcnMNCj4gYWNj ZXNzIHRvIHBvbGljeSBpbmZvcm1hdGlvbiB3aWxsIGFsbG93IHRoZW0gdG8gbWFrZSBtb3JlIGlu Zm9ybWVkDQo+IGRlY2lzaW9ucyBhYm91dCBob3cgdG8gdXNlIHRoZWlyIGxvY2F0aW9uIFVSSXMu ICBBbGxvd2luZyB1c2VycyB0bw0KPiBwcm92aWRlIHBvbGljeSBpbmZvcm1hdGlvbiB0byB0aGUg TFMgd2lsbCBlbmFibGUgdGhlbSB0byB0YWlsb3INCj4gYWNjZXNzIGNvbnRyb2wgcG9saWNpZXMg dG8gdGhlaXIgbmVlZHMgKHdpdGhpbiB0aGUgYm91bmRzIG9mIHBvbGljeQ0KPiB0aGF0IHRoZSBM UyB3aWxsIGFjY2VwdCkuIg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gR2VvcHJpdiBtYWlsaW5nIGxpc3QNCj4gR2VvcHJpdkBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dlb3ByaXYNCg== From rbarnes@bbn.com Thu Jul 29 01:15:26 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1ADA928C0FF for ; Thu, 29 Jul 2010 01:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[AWL=-1.240, BAYES_50=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 nPHHY3Vw01VE for ; Thu, 29 Jul 2010 01:15:12 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 953A23A6A50 for ; Thu, 29 Jul 2010 01:15:08 -0700 (PDT) Received: from [128.89.253.91] (port=49231 helo=dhcp-22e1.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OeOH5-0004e6-LL for geopriv@ietf.org; Thu, 29 Jul 2010 04:15:32 -0400 Message-Id: <07CFE9F3-000A-43EA-A9FB-D2F9D448A44C@bbn.com> From: "Richard L. Barnes" To: geopriv@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Jul 2010 10:15:28 +0200 X-Mailer: Apple Mail (2.936) Subject: [Geopriv] IETF 78 Draft Minutes X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 08:15:26 -0000 Draft minutes below, please send comments by the end of the week. --Richard Minutes - GEOPRIV - IETF 78 Summary (prepared by Richard Barnes): Chairs' Introduction The chairs briefly reviewed document status. Alissa Cooper called for more feedback on Roberts comments on draft-ietf-geopriv-arch draft-ietf-sipcore-location-conveyance (James Polk) New version includes significant simplifications. Further revisions will follow based on SIPCORE discussions. Major open issue is how to handle GEO URIs. draft-ietf-geopriv-dhcp-lbyr-uri-option (James Polk) New version out today incorporates new privacy text, and should be ready for WGLC. Chairs will issue WGLC soon. draft-barnes-hard-problem (Richard Barnes) Raising awareness of High Assurance Redirection problem, related to secure service delegation via the DNS. Contact Richard Barnes or Peter Saint-Andre if interested. draft-ietf-geopriv-held-measurements (Martin Thomson) Current draft has updated security considerations. Needs more review before publication, both from a security perspective and with regard to the individual measurement elements. draft-ietf-geopriv-deref-protocol (Martin Thomson) Privacy concerns remain, since there's no current mechanism for managing access control policies. Proposal to add a GET-based deref mechanism was thouroughly debated, with several attendees expressing a preference for having only one mechanism (GET or POST). draft-ietf-geopriv-relative-location (Brian Rosen) Current document is essentially the same as the last. No objections in the room to the current approach. Agreement that document will reference the relevant IEEE 802 spec as a motivation for the TLV formats. draft-thomson-geopriv-res-gw-lis-discovery (Ray Bellis) Continuing security and privacy issues, including an instance of the HARD problem and concern over exposing location servers. Discussion will continue on the list. draft-george-geopriv-lamp-post (Brian Rosen) Basically no change from last time. There was discussion of alternative, more general approaches, but ultimately the group preferred a more specific approach. draft-barnes-geopriv-policy-uri (Richard Barnes) Mechanism to allow clients to control policy on location URIs. Hannes Tschofenig noted possible efficiency gains could result from just including policy in a HELD transaction. Strong consensus to work on the problem, but there will be further discussion of efficiency concerns before adoption. Martin Thomson raised an issue with draft-ietf-geopriv-policy, where the current location fuzzing algorithm can cause a moving target's location to be exposed more precisely. The authors will work to correct the algorithm. Brian Rosen made a proposal to re-design the format for civic addresses, moving to a more generic type/value format. Participant opinions varied widely, and discussion will continue on the list. Raw minutes from Adam Roach follow ---------------------------------- GEOPRIV - July 18, 2010 @ 1300 Introduction - Chairs ===================== * Agenda bash, chairs (see slides) - Martin Thomson: Asks for fewer than 20 minutes for LIS discovery, suggests timeslot at end for GEOPRIV policy - Chairs agree to "credit forward" any unused time from LIS discovery * Document status review, chairs (see slides) * Call from chairs to comment on architecture doc in IETF LC sipcore-location-conveyance - James Polk ======================================== * Summary of changes to document (see slides) (see also SIPCORE minutes) - James asks room for any objections to the various decisions made in SIPCORE session regarding the document. None registered. - Cullen: looks like the same people in the room; the comments & complaints should be the same. DHCP Location by reference URI option- James Polk ================================================= * Summary of changes (see slides) - Chairs: Only outstanding issue was addressing privacy considerations, which is addressed in -08 - Martin Thomson: We agreed to remove "version" and "removed" tags. They aren't needed with suboptions. James thinks this change can be collected in with WGLC - Chairs: document to be WGLC soon. The HARD Problem -- Chairs ========================== * See slides for summary of problem - Encourage participants to contact Richard Barnes and/or Peter St. Andre for further details and feedback HELD Measurements - Martin Thomson ================================== * Document Status (see slides) - Author call for feedback on WiFi measurement procedure changes * Security Updates (see slides) - Author call for feedback on new security text (list reviews have been sparse on the topic so far). - Hannes Tschofennig: Agrees that the security story is unsurprising and a little depressing. - Martin: The idea of a supporting observation is that a device provides a measurement (without any protection from spoofing), and the LIS has the ability to request proof of the measurement, then a greater degree of assurance is possible. - Alissa: Can you give an example? - Martin: For example, if a cell ID is provided, the LIS might request information relating to the radio output of that cell ID at the moment. * Remaining work (see slides) - Cullen Jennings: Splitting up the document to prevent IPR disclosures from disrupting the whole mechanism is a simple means to do so. The cost of doing so is very low. - Gabor: The measurements section is not in agreement with ??? -- the round trip time, for example. For delivering BSSID, there is a suggestion that APs can sign their mac address to provide better reliablity. - Martin: It would be great if you could put those points on the list. - Chairs: Input from IEEE and 3GPP would be great. - Chairs: Do people think the security sections are accurate and comprehensive? [Note the presence of nods from the room] Deref protocol - Martin Thompson ================================ * Status Update (see slides) - Cullen: Likes the text in the draft. Is concerned that the security is based on "you will do something, but don't have any normative statements about how." Worried that it's not mandatory to implement a security scheme in a client that can be assured to be in a server. - Hannes: The concern is that there's no mandatory-to-implement security mechanism. You need to have bilateral agreements between the client and the server to ensure security. - Cullen: For example, there's no way to specify an ACL. It gives examples of how it can be done, but nothing that is guaranteed to be there. - Martin: When we say "possession model," it is a mechanism for doing this. Not a good one, but one nonetheless. - Hannes: It would be difficult to say that this document needs to solve this problem, when other documents haven't been required to do so. - Cullen: Yes, many documents have this problem. I don't think we are in line with our charter -- we need to do privacy as an integral part of the protocol, not bolt it on later. - Alissa: NENA tests have been using possession model for this purpose. - Hannes: (missed some comments here about the use of OAUTH). - Richard: propose an extension for identity-based access controls. - Hannes: No, it's not the same. If someone comes along from an OAUTH token, that's a very different thing than coming in with HTTP Digest authentication. - Marc: Agree with Cullen -- we understand the posession model, but we're not really ready to embrace it without other security. - Randy Gellens: The purpose of GEOPRIV is to make sure we don't forget to include privacy at the beginning. Also, as a possible partial solution: LEMONADE came up with a "pawn ticket URL" approach in which the URL includes a role restriction. For example, "this URL can only be derigetered by a user the server trusts." We might consider something similar, e.g.: "this URI can be resolved only by something the LIS trusts, like a PSAP or a call router." That fits in well with the NENA model. This would provide at least more than we have now. - Hannes: Any IPR on this mechanism? - Randy: Not aware of any. - Hannes: Does about the same thing as posession. * Issue: HTTP GET Requests (see slides for summary) - Cullen: It's better to return an error. The client has done something that the protocol didn't expect. In this case, it would be better for things to fail, than for them to succeed in the wrong way. - Martin: The rationale for using POST instead of GET is because normal usage might not be idempotent. But in deref, idempotence is guaranteed, so there's no harm. - Alex Mayerhofer: If you deal with GET, you also need to consider the other HTTP methods. Also, keep in mind that POST usually changes something on the server, while GET should not. - Brian: If we decide GET is *the* way to do this, then that's fine. But right now we say POST is the mechanism. We don't need two mechanisms for the same thing. If you do this mechanism, then you've done POST. If you don't, then you can't make sense of what happend for GET. - Alex: You want to add caching considerations. - Cullen: It's not clear that this is idempotent. If it's one-time use, then it's not. - Martin: We don't have that concept. - Cullen: but we need one to make sure that the possession model works. - Martin: But how can you make sure you know the user got what they needed? - [Whole working group talking at once] - Richard Barnes (at floor mic): Why are we using HELD in the first place? It's so we can send parameters (e.g. geodetic versus civic). The GET could be a simplified interface. - Adam Roach: Just pick one. - Brian Rosen: I'm okay with GET. You can get what you need with GET. - Richard: We started out with POST because that's what HELD used. But a lot of the document says "don't do what HELD says." So, if all we want is a small number of parameters, then... - Martin: We might need this to be extensible. - Richard: As long as it fits into key/value, it can go into a query string. - Jon: I worry that if we shave this down to the query string, then we back ourselves into a corner, and end up with something that is not as future proof. - Martin: Take it to the list. - Jonathan Lennox: Making it GET makes the caching properties come back into play. This could be useful, and could be dangerous. Relative Location - Brian Rosen =============================== * No significant updates since Anaheim (see slides). * Major open issue: what to do if you don't understand the extension? (see slides) - Martin Thomson: Thought we discussed & closed the topic. The resolution is already in the draft. - Brian: If Martin is happy with what's in the document, then I'm happy. * To Do (see slides) - Martin: We need to define the bucket that all the bits go in. 802.11v has defined a bucket, and they're one of the key consumers of this work. We can define our own bucket -- do we need to? - Brian: And should we do it in this draft? I'm bothered that we don't have a bucket, but don't think it goes here. - Martin: So, if 802.11v has what they need, can we kill the binary parts? - Everyone: No, 802.11v cites this document. - Dorthy: The goal is to have an IETF document that everyone can use. The copy of data into 802.11v is a failsafe in case the IETF work doesn't complete. - Brian: So, should the IETF define the bucket? - Dorthy: It's hard to speak for the whole group. Personally, it would be nice to have, but not critical. - Geoff Thompson: Is there text in 802.11v that says this text goes away? - [some disagreement here -- Geoff and Dorthy to work offline to reach conclusion] - Richard: Would it make sense to reference the 802.11v bucket? - Brian: No objection. - Martin: Just looking for something a bit more concrete than the current situation. - Marc: Clearly, in 802.11v, the container is DHCP. Semantically, it makes no sense to put relative location in DHCP. - Dorthy: Agree with Marc's comments. If we need an official response on a specific question, would be happy to get that answer for GEOPRIV. - Brian: Would there be an objection to referencing the 802.11v informatively as an example? - Dorthy: No, as long as it can be used in other buckets as well. ************************************************************************* * Compromise: the REL LOC document will informatively reference the 802 * * document as an *example* of how these TLVs can be used. * ************************************************************************* res-gw lis discovery draft - Ray Bellis ======================================= * Query for WG adoption (see slides) - Richard Barnes: We need to make sure we know that there can be a good security & privacy story before we adopt the document. There are also some IPv6 concerns. Think we need to know that there is *some* story that can be told before we adopt. - Hannes: Lots of the text is repeated from other documents about things like Layer 7 LCP. Relating to a previous meeting: the fundamental problem is that you don't get DHCP to the endpoints becuase intermediaries don't understand the extension. Have there been investigations about how large this problem might be? - Ray: Not with respect to the specific mechanism. Have seen just about no home gateways that let arbitrary DHCP options through. - Hannes: So how about PPP extensions? - Ray: We tried. - Cullen: With regard to the "tree climing" problem, consider that typing, e.g., "Cisco" into a URL bar for a browser will result in 4 or 5 queries. It hasn't broken DNS yet. [ Some comment I didn't understand about IPv6 and certain prefixes ] - Martin: Think we can address tree climing concerns. Think we can address privacy concerns (although it will be a challenge). We have the same kinds of problems in WGs like ALTO. Having a good description of the problem would help progress. - Ray: In 3rd party case -- privacy is addresses by 3rd parties having bilateral agreements with LIS. - Richard: Isn't that true for advertising partners also? - Hannes: Perhaps DNS isn't the right mechanism. Things like anycast. Yes, it wouldn't support 3rd party queries, but that might be better. Have concerns that 3rd party queries would be used outside of emergency contexts. - Jon: Yes, we could document the shortcomings, but the shortcomings are catastrophic. There must be some way that we can do 1st party in a way that you're communicating to the access network only from within the access network. DHCP provides this. We need something similar. - Martin: that's a bit of an exaggeration. You can find the server, not the actual location. - Jon: If there were a good authorization model for the 3rd party case, then you can have a good solution. But aside from the emergency case, any valid authorizaiton model is hard to beleive. - Ray: The ISP could respond to queries from anywhere, or have ACLs for who queries. - Jon: We really need to have a better description around the requirements for the solution before we can move forward. - Chairs: Sounds like we need to keep talking about this, and possibly consider other mechanisms. We should take the discussion to the list. Lamp-Post - Brian Rosen ======================= * Adds two civic address fields (CA types) to PIDF-LO (see slides) * Open Issue: two different CA types. Can we unify them and include other kinds of posts? (see slides) - Martin: Could we add this on with prefix? - Brian: Prefix has gone through. - Roger Marshall: How about call boxes, manhole covers? - Brian: The question is whether these are customarily used to locate things. You'll say things like "I'm on I-10, milepost 78". - Hannes: So how does this work? Usually you get PIDF-LO from a server. But you're talking about things that the user would provide, like lamp-posts. - Brian: Right now, it's just a CA. The question is: if you pass a lamp-post, and that's the only location you pass, is that a valid query? The answer for a lamp-post is "yes." - Hannes: But how does it get in the device in the first place? - Brian: A good example is a train -- it will provide location by milepost. - Richard: I'm concerned, though, that there are tons of numbered things out there. It would be nice if we could do this without updating the XML schema each time. - Geoff: this is an element of linear addressing along a path. - Brian: True for mileposts, not necessarily for lampposts. - Geoff: Stuff that is arbitrarily numbered across a 2D space... are we adequately differentiating those? - Brian: For the existing draft we sure are. - Roger Marshall: This is too specific. We need to find something like a grid that these can fit into. In terms of where this comes from, we could have a reverse lookup on lat/long. - Martin: Or it could come from RFID, or barcodes, etc. - Richard: Or smart roads. - Martin: I agree that we want a better abstraction for these kinds of things. - Hannes: Don't you need a registry? - Brian: You need to know that it is a lamp post. - Hannu: Are we talking about distance from some known point? - Brian: No, it's an identifier for the lamp post. - Keith Drage: So, with the canal example, you have (for examples) bridges and locks. You have to know which one you're talking about. - Martin: It looks like a registry just masks the problem. If we attempt to develop a taxonomy, we'll take forever. So, let people establish their own schemes for disambiguation, and local name spaces. If they need to number lampposts in China, then they can use local convention for differentiating number schemes. - Brian: That works as long as instructions for encoding addresses in a specific country have a list of valid values for this kind of thing. - Cullen: It's not like we have hundreds of thousands of these things. If we make it open-ended, then the chance you'll have to do manual entry or normalization goes way up. We have two things in front of us, let's just standardize them. - Alex: Concerned that we're adding CA types to PIDF-LO without already having everything defined for every known system - Alex: We need to keep in mind what happens when you have conflicts between CA types -- some kind of priority among them. - Chairs: Is this a problem that needs a solution? Do we need a document to be able to address these two numbered things (lamp posts, mile markers) - Geoff: Originally, I wanted more complexity, but now think we should do these two, and maybe add more in the future. *************************************************************************** Chair call for hums: Should we work on this kind of thing? *********************************************************** *** Wide agreement that we need to work on this problem *** *********************************************************** Should we focus on these two issues? [versus] Should we make a more general solution? ******************************************************************** *** Some hums on both sides, with a bias for a specific solution *** ******************************************************************** *************************************************************************** Geopriv policy URI - Richard Barnes =================================== * Motivation (see slides) * Mechanism description (see slides "Provide a control channel", "Accessing the control channel", "Complexity") * Next steps? - Hannes: This relates to HELD and DHCP -- namely, how one gets these references. Also, how does one get the format for this policy? Is it useful to have a separate protocol mechanism to convey this information? What this means is that, when you get location, you need to do another transaction. So, why don't we do this in-band? And, if we don't want to do it in-band (e.g. DHCP), then why don't we do what we previously worked on (XCAP)? Or using WEBDAV? - Richard: You can view this as using a very simple profile of XCAP or WEBDAV. - Hannes: How would this work in the situation that other people can see the policy URL? - Richard: You use HTTPS, just like HELD says. For DHCP, you need to rely on link security. - Cullen: This is clever. You split the posession model for the 1st party, and a non-posession model for the 3rd party. Not terribly fond of XCAP. - Martin: We have a patch operation for HTTP that makes XCAP unnecessary. - Marc: We need to go to HELD an DHCP LbyR to reflect the security requirements. - Hannes: HELD was much more efficient at this. - Martin: Really, I don't care. - Hannes: Security is one issue. But if you have multiple choices, you have to know which one to pick. - Martin: We need to determine whether ACL whitelist policies is what we need. This is specific to deref. - Richard: This gives a control channel for putting permission on location deref. There's a different question about authenticating the asking entities, but that's the deref draft. - Martin: But is this a requirement? I think I'm hearing that it is. WRT performance, was thinking about an extension that would help with performance. - Hannes: In HELD, you do an HTTP exchange and get the location. You then shuffle the policy along with at the same time, versus doing a completely separate protocol exchange. - Martin: So the suggestion is that we add a mechanism to add the policy to the location request, as an optimization. Chair query: should the WG take this work on? ************************************************ *** Unanimous support for taking the work on *** ************************************************ - Chair: recommend addressing the performance issue on the list, and then will call for consensus on adoption. Location obsfucation - Martin Thomson ===================================== * Read the mailing list, there's a link to a useful image in there. * Short summary: creation of a new circle when location obsfucation is in effect can reveal lots of information about actual locaion. Need to come up with a way to generate new circles. Heresy - Brian Rosen ==================== * Adding a new CA type requires us to define a new schema. * Suggest redefining civic address, with backwards compatibility, such that we have a single element that has a "type/value" indication. - Jon Peterson: Probably a good idea to fix this. - Alex: This does add flexibility in adding new things, but also adds great flexibility in how things can go wrong. Plus, you're pretty much devolving to key/value. - Richard: We're pretty much already at key/value, but with the complexity of XML. If we have to break compatibility to do things, then let's do that now. - Adam: Will RELAX NG fix this? - Brian: We asked XML experts, and they don't think so. - Chairs: Continue offline or on-list. We're out of time. From rbarnes@bbn.com Fri Jul 30 05:05:14 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24BB93A68F6 for ; Fri, 30 Jul 2010 05:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.453 X-Spam-Level: X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599] 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 YxqBYjEJIWLd for ; Fri, 30 Jul 2010 05:05:13 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id D9F3C3A67FA for ; Fri, 30 Jul 2010 05:05:12 -0700 (PDT) Received: from [128.89.253.157] (port=50540 helo=dhcp-22e1.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OeoLJ-000LXC-BP for geopriv@ietf.org; Fri, 30 Jul 2010 08:05:37 -0400 Message-Id: <460B37C8-D974-46C3-BDA8-C1981AEDB16D@bbn.com> From: "Richard L. Barnes" To: geopriv@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 30 Jul 2010 14:05:33 +0200 X-Mailer: Apple Mail (2.936) Subject: [Geopriv] policy-uri X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 12:05:14 -0000 The only concern raised in the meeting with regard to draft-barnes- geopriv-policy-uri was when Hannes noted that the exchange could be made more efficient (in the HELD context) overlaying the policy interactions on a HELD transaction. For example, the client could provide policy data in a object, and the server could specify policy it intends to use in the . I think we should not do this. The problem is that it introduces weird failure cases: Consider the following request: civic geodetic locationURI ... Suppose a server receives this request, and the server is happy to provide all three types of location, but it doesn't want to accept the policy. What should happen is that the server can provide location and indicate that it has rejected the policy. With the current HELD syntax, the rejection of policy could only be indicated with an response, which would mean that location wouldn't get delivered. So we would need to introduce a separate, "non-critical" error reporting mechanism. Handling policy in a separate channel allows policy negotiations not to interfere with basic delivery -- we can benefit from the error- handling mechanisms in HTTP, without having to re-implement it inside the HELD XML. An extra HTTP request is not that expensive. As was said on another topic in the meeting: Let's just have one way. --Richard From Hannes.Tschofenig@gmx.net Fri Jul 30 05:06:48 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 100B43A6967 for ; Fri, 30 Jul 2010 05:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 XfKR-oQrptzD for ; Fri, 30 Jul 2010 05:06:47 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id C1FA93A67FA for ; Fri, 30 Jul 2010 05:06:46 -0700 (PDT) Received: (qmail invoked by alias); 30 Jul 2010 12:07:09 -0000 Received: from dhcp-85c8.meeting.ietf.org (EHLO [130.129.133.200]) [130.129.133.200] by mail.gmx.net (mp006) with SMTP; 30 Jul 2010 14:07:09 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18PILJy8EAP2DWh4sF9eL6n0sm1SNrV05qp2Ml4xe 0KWLfVlNqfO344 Message-ID: <4C52C09F.1040401@gmx.net> Date: Fri, 30 Jul 2010 14:07:59 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Richard L. Barnes" References: <460B37C8-D974-46C3-BDA8-C1981AEDB16D@bbn.com> In-Reply-To: <460B37C8-D974-46C3-BDA8-C1981AEDB16D@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: geopriv@ietf.org Subject: Re: [Geopriv] policy-uri X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 12:06:48 -0000 Why not use the existing HELD Context document? On 30.07.2010 14:05, Richard L. Barnes wrote: > The only concern raised in the meeting with regard to > draft-barnes-geopriv-policy-uri was when Hannes noted that the > exchange could be made more efficient (in the HELD context) overlaying > the policy interactions on a HELD transaction. For example, the > client could provide policy data in a object, and > the server could specify policy it intends to use in the > . I think we should not do this. From Hannes.Tschofenig@gmx.net Fri Jul 30 05:12:10 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F2C63A6985 for ; Fri, 30 Jul 2010 05:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 ylPeXk36MVG9 for ; Fri, 30 Jul 2010 05:12:07 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 500833A6839 for ; Fri, 30 Jul 2010 05:12:06 -0700 (PDT) Received: (qmail invoked by alias); 30 Jul 2010 12:12:30 -0000 Received: from dhcp-85c8.meeting.ietf.org (EHLO [130.129.133.200]) [130.129.133.200] by mail.gmx.net (mp044) with SMTP; 30 Jul 2010 14:12:30 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+4sTkN5d+49TlRITv8W/TmgNSbG5AozF9Zb18Mi4 PPdZ61+rGE4gV/ Message-ID: <4C52C1DF.90305@gmx.net> Date: Fri, 30 Jul 2010 14:13:19 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Richard L. Barnes" References: <460B37C8-D974-46C3-BDA8-C1981AEDB16D@bbn.com> In-Reply-To: <460B37C8-D974-46C3-BDA8-C1981AEDB16D@bbn.com> Content-Type: multipart/alternative; boundary="------------050509030209000908030005" X-Y-GMX-Trusted: 0 Cc: geopriv@ietf.org Subject: Re: [Geopriv] policy-uri X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 12:12:10 -0000 This is a multi-part message in MIME format. --------------050509030209000908030005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Another question: there was some work to do a non-XCAP (REST/HTTP) based approach to configure call handling (forward etc.) rules on a server. It was not to replace XCAP but that work run into "who's going to implement it" type of issues. What happened with that work? Seems to be relevant to me. Ciao Hannes On 30.07.2010 14:05, Richard L. Barnes wrote: > > > The only concern raised in the meeting with regard to > draft-barnes-geopriv-policy-uri was when Hannes noted that the > exchange could be made more efficient (in the HELD context) overlaying > the policy interactions on a HELD transaction. For example, the > client could provide policy data in a object, and > the server could specify policy it intends to use in the > . I think we should not do this. > > The problem is that it introduces weird failure cases: Consider the > following request: > > civic geodetic locationURI > ... > > > Suppose a server receives this request, and the server is happy to > provide all three types of location, but it doesn't want to accept the > policy. What should happen is that the server can provide location > and indicate that it has rejected the policy. With the current HELD > syntax, the rejection of policy could only be indicated with an > response, which would mean that location wouldn't get > delivered. So we would need to introduce a separate, "non-critical" > error reporting mechanism. > > Handling policy in a separate channel allows policy negotiations not > to interfere with basic delivery -- we can benefit from the > error-handling mechanisms in HTTP, without having to re-implement it > inside the HELD XML. An extra HTTP request is not that expensive. > > As was said on another topic in the meeting: Let's just have one way. > > --Richard > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv --------------050509030209000908030005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Another question:

there was some work to do a non-XCAP (REST/HTTP) based approach to configure call handling (forward etc.) rules on a server. It was not to replace XCAP but that work run into "who's going to implement it" type of issues.

What happened with that work? Seems to be relevant to me.

Ciao
Hannes



On 30.07.2010 14:05, Richard L. Barnes wrote:
<hat type="individual"/>

The only concern raised in the meeting with regard to draft-barnes-geopriv-policy-uri was when Hannes noted that the exchange could be made more efficient (in the HELD context) overlaying the policy interactions on a HELD transaction.  For example, the client could provide policy data in a <locationRequest> object, and the server could specify policy it intends to use in the <locationResponse>.  I think we should not do this.

The problem is that it introduces weird failure cases: Consider the following request:
<locationRequest>
  <locationType>civic geodetic locationURI</locationType>
  <ruleset> ... </ruleset>
</locationRequest>

Suppose a server receives this request, and the server is happy to provide all three types of location, but it doesn't want to accept the policy.  What should happen is that the server can provide location and indicate that it has rejected the policy.  With the current HELD syntax, the rejection of policy could only be indicated with an <error> response, which would mean that location wouldn't get delivered.  So we would need to introduce a separate, "non-critical" error reporting mechanism.

Handling policy in a separate channel allows policy negotiations not to interfere with basic delivery -- we can benefit from the error-handling mechanisms in HTTP, without having to re-implement it inside the HELD XML.  An extra HTTP request is not that expensive.

As was said on another topic in the meeting: Let's just have one way.

--Richard
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

--------------050509030209000908030005-- From rbarnes@bbn.com Fri Jul 30 05:20:39 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 578323A6869 for ; Fri, 30 Jul 2010 05:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.135, 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 kUrUciO4MzXv for ; Fri, 30 Jul 2010 05:20:38 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id F419D3A67E6 for ; Fri, 30 Jul 2010 05:20:37 -0700 (PDT) Received: from [128.89.253.157] (port=50588 helo=dhcp-22e1.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OeoaD-000Les-K9; Fri, 30 Jul 2010 08:21:02 -0400 Message-Id: <4BE64AB0-9145-447D-84EA-2D8A8E9EE591@bbn.com> From: "Richard L. Barnes" To: Hannes Tschofenig In-Reply-To: <4C52C1DF.90305@gmx.net> Content-Type: multipart/alternative; boundary=Apple-Mail-2--609933878 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 30 Jul 2010 14:21:00 +0200 References: <460B37C8-D974-46C3-BDA8-C1981AEDB16D@bbn.com> <4C52C1DF.90305@gmx.net> X-Mailer: Apple Mail (2.936) Cc: geopriv@ietf.org Subject: Re: [Geopriv] policy-uri X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 12:20:39 -0000 --Apple-Mail-2--609933878 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit What's in the policy URI draft *is* REST/HTTP, and could easily be re- used in other contexts. So if the other work stalled, we can replace it with this. Could you provide a more specific reference? Otherwise, it doesn't seem like this issue should be blocking for this draft. --Richard On Jul 30, 2010, at 2:13 PM, Hannes Tschofenig wrote: > Another question: > > there was some work to do a non-XCAP (REST/HTTP) based approach to > configure call handling (forward etc.) rules on a server. It was not > to replace XCAP but that work run into "who's going to implement it" > type of issues. > > What happened with that work? Seems to be relevant to me. > > Ciao > Hannes > > > > On 30.07.2010 14:05, Richard L. Barnes wrote: >> >> >> >> The only concern raised in the meeting with regard to draft-barnes- >> geopriv-policy-uri was when Hannes noted that the exchange could be >> made more efficient (in the HELD context) overlaying the policy >> interactions on a HELD transaction. For example, the client could >> provide policy data in a object, and the server >> could specify policy it intends to use in the . >> I think we should not do this. >> >> The problem is that it introduces weird failure cases: Consider the >> following request: >> >> civic geodetic locationURI >> ... >> >> >> Suppose a server receives this request, and the server is happy to >> provide all three types of location, but it doesn't want to accept >> the policy. What should happen is that the server can provide >> location and indicate that it has rejected the policy. With the >> current HELD syntax, the rejection of policy could only be >> indicated with an response, which would mean that location >> wouldn't get delivered. So we would need to introduce a separate, >> "non-critical" error reporting mechanism. >> >> Handling policy in a separate channel allows policy negotiations >> not to interfere with basic delivery -- we can benefit from the >> error-handling mechanisms in HTTP, without having to re-implement >> it inside the HELD XML. An extra HTTP request is not that expensive. >> >> As was said on another topic in the meeting: Let's just have one way. >> >> --Richard >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www.ietf.org/mailman/listinfo/geopriv > --Apple-Mail-2--609933878 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
What's in the policy URI = draft *is* REST/HTTP, and could easily be re-used in other contexts. =  So if the other work stalled, we can replace it with = this.

Could you provide a more specific = reference?  Otherwise, it doesn't seem like this issue should be = blocking for this = draft.

--Richard


On Jul 30, 2010, at 2:13 PM, Hannes Tschofenig wrote:

Another question:

there = was some work to do a non-XCAP (REST/HTTP) based approach to configure = call handling (forward etc.) rules on a server. It was not to replace XCAP but = that work run into "who's going to implement it" type of issues.
=
What happened with that work? Seems to be relevant to me.

= Ciao
Hannes



On 30.07.2010 14:05, Richard L. = Barnes wrote:
<hat type=3D"individual"/>

The only = concern raised in the meeting with regard to = draft-barnes-geopriv-policy-uri was when Hannes noted that the exchange = could be made more efficient (in the HELD context) overlaying the policy = interactions on a HELD transaction.  For example, the client could = provide policy data in a <locationRequest> object, and the server = could specify policy it intends to use in the = <locationResponse>.  I think we should not do this.
=
The problem is that it introduces weird failure cases: Consider the = following request:
<locationRequest>
  = <locationType>civic geodetic locationURI</locationType> =
  <ruleset> ... </ruleset>
= </locationRequest>

Suppose a server receives this = request, and the server is happy to provide all three types of location, = but it doesn't want to accept the policy.  What should happen is = that the server can provide location and indicate that it has rejected = the policy.  With the current HELD syntax, the rejection of policy = could only be indicated with an <error> response, which would mean = that location wouldn't get delivered.  So we would need to = introduce a separate, "non-critical" error reporting mechanism.
=
Handling policy in a separate channel allows policy negotiations = not to interfere with basic delivery -- we can benefit from the = error-handling mechanisms in HTTP, without having to re-implement it = inside the HELD XML.  An extra HTTP request is not that expensive. =

As was said on another topic in the meeting: Let's just have = one way.

--Richard
= _______________________________________________
Geopriv mailing = list
Geopriv@ietf.org
https://www.ietf.or= g/mailman/listinfo/geopriv

=

= --Apple-Mail-2--609933878-- From rbarnes@bbn.com Fri Jul 30 05:22:38 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA11D3A698B for ; Fri, 30 Jul 2010 05:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.472 X-Spam-Level: X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] 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 DbT3CiNRYI1f for ; Fri, 30 Jul 2010 05:22:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 4B4FD3A698A for ; Fri, 30 Jul 2010 05:22:37 -0700 (PDT) Received: from [128.89.253.157] (port=50594 helo=dhcp-22e1.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Oeoc9-000Lg8-D3; Fri, 30 Jul 2010 08:23:01 -0400 Message-Id: <832A191B-0682-4BE2-AE41-AEF7B3078253@bbn.com> From: "Richard L. Barnes" To: Hannes Tschofenig In-Reply-To: <4C52C09F.1040401@gmx.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 30 Jul 2010 14:23:00 +0200 References: <460B37C8-D974-46C3-BDA8-C1981AEDB16D@bbn.com> <4C52C09F.1040401@gmx.net> X-Mailer: Apple Mail (2.936) Cc: geopriv@ietf.org Subject: Re: [Geopriv] policy-uri X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 12:22:39 -0000 Simplicity: This document does everything that HELD-Context does (except for ), without requiring any new XML. (And should be a policy extension, anyway.) Generality: This document is not specific to HELD, so that, e.g., it can be used with DHCP. On Jul 30, 2010, at 2:07 PM, Hannes Tschofenig wrote: > Why not use the existing HELD Context document? > > > On 30.07.2010 14:05, Richard L. Barnes wrote: >> The only concern raised in the meeting with regard to draft-barnes- >> geopriv-policy-uri was when Hannes noted that the exchange could be >> made more efficient (in the HELD context) overlaying the policy >> interactions on a HELD transaction. For example, the client could >> provide policy data in a object, and the server >> could specify policy it intends to use in the . >> I think we should not do this. > From Hannes.Tschofenig@gmx.net Fri Jul 30 05:34:13 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 493B43A698E for ; Fri, 30 Jul 2010 05:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 cEK1J+PeZPA4 for ; Fri, 30 Jul 2010 05:34:07 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id C5CD43A699F for ; Fri, 30 Jul 2010 05:34:02 -0700 (PDT) Received: (qmail invoked by alias); 30 Jul 2010 12:34:08 -0000 Received: from dhcp-85c8.meeting.ietf.org (EHLO [130.129.133.200]) [130.129.133.200] by mail.gmx.net (mp014) with SMTP; 30 Jul 2010 14:34:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18/f9sEn60/c9BYzr8JlQbOW0WDsOKR4lqthonXvf JAes43ucwwgmeu Message-ID: <4C52C6F1.2090908@gmx.net> Date: Fri, 30 Jul 2010 14:34:57 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Richard L. Barnes" References: <460B37C8-D974-46C3-BDA8-C1981AEDB16D@bbn.com> <4C52C1DF.90305@gmx.net> <4BE64AB0-9145-447D-84EA-2D8A8E9EE591@bbn.com> In-Reply-To: <4BE64AB0-9145-447D-84EA-2D8A8E9EE591@bbn.com> Content-Type: multipart/alternative; boundary="------------080308000805070906090906" X-Y-GMX-Trusted: 0 Cc: geopriv@ietf.org Subject: Re: [Geopriv] policy-uri X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 12:34:13 -0000 This is a multi-part message in MIME format. --------------080308000805070906090906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I did not follow the work; maybe some of the hardcore SIP guys may know the status of this work. On 30.07.2010 14:21, Richard L. Barnes wrote: > What's in the policy URI draft *is* REST/HTTP, and could easily be > re-used in other contexts. So if the other work stalled, we can > replace it with this. > > Could you provide a more specific reference? Otherwise, it doesn't > seem like this issue should be blocking for this draft. > > --Richard > > > On Jul 30, 2010, at 2:13 PM, Hannes Tschofenig wrote: > >> Another question: >> >> there was some work to do a non-XCAP (REST/HTTP) based approach to >> configure call handling (forward etc.) rules on a server. It was not >> to replace XCAP but that work run into "who's going to implement it" >> type of issues. >> >> What happened with that work? Seems to be relevant to me. >> >> Ciao >> Hannes >> >> >> >> On 30.07.2010 14:05, Richard L. Barnes wrote: >>> >>> >>> The only concern raised in the meeting with regard to >>> draft-barnes-geopriv-policy-uri was when Hannes noted that the >>> exchange could be made more efficient (in the HELD context) >>> overlaying the policy interactions on a HELD transaction. For >>> example, the client could provide policy data in a >>> object, and the server could specify policy it intends to use in the >>> . I think we should not do this. >>> >>> The problem is that it introduces weird failure cases: Consider the >>> following request: >>> >>> civic geodetic locationURI >>> ... >>> >>> >>> Suppose a server receives this request, and the server is happy to >>> provide all three types of location, but it doesn't want to accept >>> the policy. What should happen is that the server can provide >>> location and indicate that it has rejected the policy. With the >>> current HELD syntax, the rejection of policy could only be indicated >>> with an response, which would mean that location wouldn't >>> get delivered. So we would need to introduce a separate, >>> "non-critical" error reporting mechanism. >>> >>> Handling policy in a separate channel allows policy negotiations not >>> to interfere with basic delivery -- we can benefit from the >>> error-handling mechanisms in HTTP, without having to re-implement it >>> inside the HELD XML. An extra HTTP request is not that expensive. >>> >>> As was said on another topic in the meeting: Let's just have one way. >>> >>> --Richard >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> https://www.ietf.org/mailman/listinfo/geopriv >> > --------------080308000805070906090906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I did not follow the work; maybe some of the hardcore SIP guys may know the status of this work.


On 30.07.2010 14:21, Richard L. Barnes wrote:
What's in the policy URI draft *is* REST/HTTP, and could easily be re-used in other contexts.  So if the other work stalled, we can replace it with this.

Could you provide a more specific reference?  Otherwise, it doesn't seem like this issue should be blocking for this draft.

--Richard


On Jul 30, 2010, at 2:13 PM, Hannes Tschofenig wrote:

Another question:

there was some work to do a non-XCAP (REST/HTTP) based approach to configure call handling (forward etc.) rules on a server. It was not to replace XCAP but that work run into "who's going to implement it" type of issues.

What happened with that work? Seems to be relevant to me.

Ciao
Hannes



On 30.07.2010 14:05, Richard L. Barnes wrote:
<hat type="individual"/>

The only concern raised in the meeting with regard to draft-barnes-geopriv-policy-uri was when Hannes noted that the exchange could be made more efficient (in the HELD context) overlaying the policy interactions on a HELD transaction.  For example, the client could provide policy data in a <locationRequest> object, and the server could specify policy it intends to use in the <locationResponse>.  I think we should not do this.

The problem is that it introduces weird failure cases: Consider the following request:
<locationRequest>
  <locationType>civic geodetic locationURI</locationType>
  <ruleset> ... </ruleset>
</locationRequest>

Suppose a server receives this request, and the server is happy to provide all three types of location, but it doesn't want to accept the policy.  What should happen is that the server can provide location and indicate that it has rejected the policy.  With the current HELD syntax, the rejection of policy could only be indicated with an <error> response, which would mean that location wouldn't get delivered.  So we would need to introduce a separate, "non-critical" error reporting mechanism.

Handling policy in a separate channel allows policy negotiations not to interfere with basic delivery -- we can benefit from the error-handling mechanisms in HTTP, without having to re-implement it inside the HELD XML.  An extra HTTP request is not that expensive.

As was said on another topic in the meeting: Let's just have one way.

--Richard
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv



--------------080308000805070906090906-- From Hannes.Tschofenig@gmx.net Fri Jul 30 05:49:08 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FC413A69A6 for ; Fri, 30 Jul 2010 05:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 3QUkeSRb7ajO for ; Fri, 30 Jul 2010 05:49:07 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id CAE2E3A6944 for ; Fri, 30 Jul 2010 05:49:06 -0700 (PDT) Received: (qmail invoked by alias); 30 Jul 2010 12:49:30 -0000 Received: from dhcp-85c8.meeting.ietf.org (EHLO [130.129.133.200]) [130.129.133.200] by mail.gmx.net (mp026) with SMTP; 30 Jul 2010 14:49:30 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Z/DFIgVEZOJeMmz/sV4TdGpFfS90Cf2dpXKRT3X kNMkvA0oZMyziQ Message-ID: <4C52CA8B.1060103@gmx.net> Date: Fri, 30 Jul 2010 14:50:19 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Richard L. Barnes" References: <460B37C8-D974-46C3-BDA8-C1981AEDB16D@bbn.com> <4C52C09F.1040401@gmx.net> <832A191B-0682-4BE2-AE41-AEF7B3078253@bbn.com> In-Reply-To: <832A191B-0682-4BE2-AE41-AEF7B3078253@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: geopriv@ietf.org Subject: Re: [Geopriv] policy-uri X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 12:49:09 -0000 Hi Richard, I have my doubts that this mechanism gets used for the DHCP based solution. DHCP does not provide confidentiality protection as a built-in feature. As Marc mentioned in response to issue#23 (see http://trac.tools.ietf.org/wg/geopriv/trac/ticket/23) I raised every target would be given the exact same location information on a shared medium. So, this is draft-ietf-geopriv-rfc3825bis. Note: The draft that was forwarded to the IESG does not point out this important security aspect, I believe. If you don't make the same assumption for the DHCP-URI draft then you suddenly allow others to modify your policies. This would be really bad. If you make the assumption that everyone on a shared medium gets the same pointer to location and also pointer to policy then you still allow others to modify the policy but there is at least no privacy harm with revealing location but rather denial of service. Ciao Hannes On 30.07.2010 14:23, Richard L. Barnes wrote: > Simplicity: This document does everything that HELD-Context does > (except for ), without requiring any new XML. (And > should be a policy extension, anyway.) > > Generality: This document is not specific to HELD, so that, e.g., it > can be used with DHCP. > > > > On Jul 30, 2010, at 2:07 PM, Hannes Tschofenig wrote: > >> Why not use the existing HELD Context document? >> >> >> On 30.07.2010 14:05, Richard L. Barnes wrote: >>> The only concern raised in the meeting with regard to >>> draft-barnes-geopriv-policy-uri was when Hannes noted that the >>> exchange could be made more efficient (in the HELD context) >>> overlaying the policy interactions on a HELD transaction. For >>> example, the client could provide policy data in a >>> object, and the server could specify policy it intends to use in the >>> . I think we should not do this. >> From rbarnes@bbn.com Fri Jul 30 06:12:58 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5D143A6944 for ; Fri, 30 Jul 2010 06:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599] 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 9iIpmJ9IuxMA for ; Fri, 30 Jul 2010 06:12:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 6CA5B3A67E3 for ; Fri, 30 Jul 2010 06:12:56 -0700 (PDT) Received: from [128.89.253.157] (port=50862 helo=dhcp-22e1.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OepOq-000Nx1-Ry; Fri, 30 Jul 2010 09:13:21 -0400 Message-Id: From: "Richard L. Barnes" To: Hannes Tschofenig In-Reply-To: <4C52CA8B.1060103@gmx.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 30 Jul 2010 15:13:19 +0200 References: <460B37C8-D974-46C3-BDA8-C1981AEDB16D@bbn.com> <4C52C09F.1040401@gmx.net> <832A191B-0682-4BE2-AE41-AEF7B3078253@bbn.com> <4C52CA8B.1060103@gmx.net> X-Mailer: Apple Mail (2.936) Cc: geopriv@ietf.org Subject: Re: [Geopriv] policy-uri X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 13:12:58 -0000 If the DHCP server is providing the same information to everybody -- effectively providing a value by reference -- then there's no reason to have a policy URI. You just wouldn't do it. Adding a policy URI does introduce another attack vector. However, if the client doesn't trust the local network to be secure enough, he can always irrevocably kill the URI by sending a DELETE request. --Richard On Jul 30, 2010, at 2:50 PM, Hannes Tschofenig wrote: > Hi Richard, > > I have my doubts that this mechanism gets used for the DHCP based > solution. > > DHCP does not provide confidentiality protection as a built-in > feature. As Marc mentioned in response to issue#23 (see http://trac.tools.ietf.org/wg/geopriv/trac/ticket/23) > I raised every target would be given the exact same location > information on a shared medium. So, this is draft-ietf-geopriv- > rfc3825bis. > > Note: The draft that was forwarded to the IESG does not point out > this important security aspect, I believe. > > If you don't make the same assumption for the DHCP-URI draft then > you suddenly allow others to modify your policies. This would be > really bad. > > If you make the assumption that everyone on a shared medium gets the > same pointer to location and also pointer to policy then you still > allow others to modify the policy but there is at least no privacy > harm with revealing location but rather denial of service. > > Ciao > Hannes > > On 30.07.2010 14:23, Richard L. Barnes wrote: >> Simplicity: This document does everything that HELD-Context does >> (except for ), without requiring any new XML. (And >> should be a policy extension, anyway.) >> >> Generality: This document is not specific to HELD, so that, e.g., >> it can be used with DHCP. >> >> >> >> On Jul 30, 2010, at 2:07 PM, Hannes Tschofenig wrote: >> >>> Why not use the existing HELD Context document? >>> >>> >>> On 30.07.2010 14:05, Richard L. Barnes wrote: >>>> The only concern raised in the meeting with regard to draft- >>>> barnes-geopriv-policy-uri was when Hannes noted that the exchange >>>> could be made more efficient (in the HELD context) overlaying the >>>> policy interactions on a HELD transaction. For example, the >>>> client could provide policy data in a object, >>>> and the server could specify policy it intends to use in the >>>> . I think we should not do this. >>> > From Hannes.Tschofenig@gmx.net Fri Jul 30 06:16:50 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E55D13A69F2 for ; Fri, 30 Jul 2010 06:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 Gw7UzunQwsm3 for ; Fri, 30 Jul 2010 06:16:46 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id E96C53A69F5 for ; Fri, 30 Jul 2010 06:16:36 -0700 (PDT) Received: (qmail invoked by alias); 30 Jul 2010 13:16:54 -0000 Received: from dhcp-85c8.meeting.ietf.org (EHLO [130.129.133.200]) [130.129.133.200] by mail.gmx.net (mp070) with SMTP; 30 Jul 2010 15:16:54 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+R2zIg3SuRXwf6Y1Je+EVC5F5Nh9FcAyW+fh6hJl xoiZC9JR9asIz3 Message-ID: <4C52D0F6.1030701@gmx.net> Date: Fri, 30 Jul 2010 15:17:42 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Richard L. Barnes" References: <460B37C8-D974-46C3-BDA8-C1981AEDB16D@bbn.com> <4C52C09F.1040401@gmx.net> <832A191B-0682-4BE2-AE41-AEF7B3078253@bbn.com> <4C52CA8B.1060103@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: geopriv@ietf.org Subject: Re: [Geopriv] policy-uri X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 13:16:50 -0000 As you see, the DHCP story is very weak. I am wonder who wants to deploy it. On 30.07.2010 15:13, Richard L. Barnes wrote: > If the DHCP server is providing the same information to everybody -- > effectively providing a value by reference -- then there's no reason > to have a policy URI. You just wouldn't do it. > > Adding a policy URI does introduce another attack vector. However, if > the client doesn't trust the local network to be secure enough, he can > always irrevocably kill the URI by sending a DELETE request. > > --Richard > > > > > > On Jul 30, 2010, at 2:50 PM, Hannes Tschofenig wrote: > >> Hi Richard, >> >> I have my doubts that this mechanism gets used for the DHCP based >> solution. >> >> DHCP does not provide confidentiality protection as a built-in >> feature. As Marc mentioned in response to issue#23 (see >> http://trac.tools.ietf.org/wg/geopriv/trac/ticket/23) I raised every >> target would be given the exact same location information on a shared >> medium. So, this is draft-ietf-geopriv-rfc3825bis. >> >> Note: The draft that was forwarded to the IESG does not point out >> this important security aspect, I believe. >> >> If you don't make the same assumption for the DHCP-URI draft then you >> suddenly allow others to modify your policies. This would be really bad. >> >> If you make the assumption that everyone on a shared medium gets the >> same pointer to location and also pointer to policy then you still >> allow others to modify the policy but there is at least no privacy >> harm with revealing location but rather denial of service. >> >> Ciao >> Hannes >> >> On 30.07.2010 14:23, Richard L. Barnes wrote: >>> Simplicity: This document does everything that HELD-Context does >>> (except for ), without requiring any new XML. (And >>> should be a policy extension, anyway.) >>> >>> Generality: This document is not specific to HELD, so that, e.g., it >>> can be used with DHCP. >>> >>> >>> >>> On Jul 30, 2010, at 2:07 PM, Hannes Tschofenig wrote: >>> >>>> Why not use the existing HELD Context document? >>>> >>>> >>>> On 30.07.2010 14:05, Richard L. Barnes wrote: >>>>> The only concern raised in the meeting with regard to >>>>> draft-barnes-geopriv-policy-uri was when Hannes noted that the >>>>> exchange could be made more efficient (in the HELD context) >>>>> overlaying the policy interactions on a HELD transaction. For >>>>> example, the client could provide policy data in a >>>>> object, and the server could specify policy it >>>>> intends to use in the . I think we should not >>>>> do this. >>>> >> From Martin.Thomson@andrew.com Fri Jul 30 08:13:06 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A82C3A69ED for ; Fri, 30 Jul 2010 08:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.09 X-Spam-Level: X-Spam-Status: No, score=-3.09 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599] 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 VfOHfxSMONdj for ; Fri, 30 Jul 2010 08:13:04 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 7D51A3A6829 for ; Fri, 30 Jul 2010 08:13:04 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:5531 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S29041335Ab0G3PN3 (ORCPT ); Fri, 30 Jul 2010 10:13:29 -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; Fri, 30 Jul 2010 10:13:28 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 30 Jul 2010 23:13:26 +0800 From: "Thomson, Martin" To: Hannes Tschofenig , "Richard L. Barnes" Date: Fri, 30 Jul 2010 23:15:40 +0800 Thread-Topic: [Geopriv] policy-uri Thread-Index: Acsv69e/qUII65uYSi2irvcNO9dYAwADgndQ Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB773AD4@SISPE7MB1.commscope.com> References: <460B37C8-D974-46C3-BDA8-C1981AEDB16D@bbn.com> <4C52C09F.1040401@gmx.net> <832A191B-0682-4BE2-AE41-AEF7B3078253@bbn.com> <4C52CA8B.1060103@gmx.net> <4C52D0F6.1030701@gmx.net> In-Reply-To: <4C52D0F6.1030701@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "geopriv@ietf.org" Subject: Re: [Geopriv] policy-uri X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 15:13:06 -0000 QWN0dWFsbHkgLSB0aGUgcG9saWN5IFVSSSBkb2Vzbid0IG1ha2UgdGhpbmdzIHdvcnNlIGF0IGFs bC4gIElmIHRoZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlIHBvbGljeSBVUkkgaXMgY29tcHJvbWlz ZWQgaW4gdHJhbnNpdCB3aXRoIERIQ1AsIHRoZW4gc28gaXMgdGhlIGNvbmZpZGVudGlhbGl0eSBv ZiB0aGUgY29ycmVzcG9uZGluZyBsb2NhdGlvbiBVUkkuICBJdCBpcyB0cnVlIHRoYXQgdGhlIERI Q1Agc2VjdXJpdHkgc3RvcnkgaXMgd2VhaywgYnV0IHRoaXMgY2VydGFpbmx5IGRvZXNuJ3QgbWFr ZSBpdCBhbnkgd29yc2UuICBJbiB0aGUgZ2VuZXJhbCBjYXNlLCBpdCB3aWxsIG1ha2UgaXQgYmV0 dGVyLCBhcyBvbmx5IGFuIGF1dGhvcml6YXRpb24gcG9saWN5IGNhbi4NCg0KLS1NYXJ0aW4NCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBnZW9wcml2LWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpnZW9wcml2LWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBI YW5uZXMgVHNjaG9mZW5pZw0KPiBTZW50OiBGcmlkYXksIDMwIEp1bHkgMjAxMCAzOjE4IFBNDQo+ IFRvOiBSaWNoYXJkIEwuIEJhcm5lcw0KPiBDYzogZ2VvcHJpdkBpZXRmLm9yZw0KPiBTdWJqZWN0 OiBSZTogW0dlb3ByaXZdIHBvbGljeS11cmkNCj4gDQo+IEFzIHlvdSBzZWUsIHRoZSBESENQIHN0 b3J5IGlzIHZlcnkgd2Vhay4NCj4gSSBhbSB3b25kZXIgd2hvIHdhbnRzIHRvIGRlcGxveSBpdC4N Cj4gDQo+IE9uIDMwLjA3LjIwMTAgMTU6MTMsIFJpY2hhcmQgTC4gQmFybmVzIHdyb3RlOg0KPiA+ IElmIHRoZSBESENQIHNlcnZlciBpcyBwcm92aWRpbmcgdGhlIHNhbWUgaW5mb3JtYXRpb24gdG8g ZXZlcnlib2R5IC0tDQo+ID4gZWZmZWN0aXZlbHkgcHJvdmlkaW5nIGEgdmFsdWUgYnkgcmVmZXJl bmNlIC0tIHRoZW4gdGhlcmUncyBubyByZWFzb24NCj4gPiB0byBoYXZlIGEgcG9saWN5IFVSSS4g IFlvdSBqdXN0IHdvdWxkbid0IGRvIGl0Lg0KPiA+DQo+ID4gQWRkaW5nIGEgcG9saWN5IFVSSSBk b2VzIGludHJvZHVjZSBhbm90aGVyIGF0dGFjayB2ZWN0b3IuICBIb3dldmVyLA0KPiBpZg0KPiA+ IHRoZSBjbGllbnQgZG9lc24ndCB0cnVzdCB0aGUgbG9jYWwgbmV0d29yayB0byBiZSBzZWN1cmUg ZW5vdWdoLCBoZQ0KPiBjYW4NCj4gPiBhbHdheXMgaXJyZXZvY2FibHkga2lsbCB0aGUgVVJJIGJ5 IHNlbmRpbmcgYSBERUxFVEUgcmVxdWVzdC4NCj4gPg0KPiA+IC0tUmljaGFyZA0KPiA+DQo+ID4N Cj4gPg0KPiA+DQo+ID4NCj4gPiBPbiBKdWwgMzAsIDIwMTAsIGF0IDI6NTAgUE0sIEhhbm5lcyBU c2Nob2ZlbmlnIHdyb3RlOg0KPiA+DQo+ID4+IEhpIFJpY2hhcmQsDQo+ID4+DQo+ID4+IEkgaGF2 ZSBteSBkb3VidHMgdGhhdCB0aGlzIG1lY2hhbmlzbSBnZXRzIHVzZWQgZm9yIHRoZSBESENQIGJh c2VkDQo+ID4+IHNvbHV0aW9uLg0KPiA+Pg0KPiA+PiBESENQIGRvZXMgbm90IHByb3ZpZGUgY29u ZmlkZW50aWFsaXR5IHByb3RlY3Rpb24gYXMgYSBidWlsdC1pbg0KPiA+PiBmZWF0dXJlLiBBcyBN YXJjIG1lbnRpb25lZCBpbiByZXNwb25zZSB0byBpc3N1ZSMyMyAoc2VlDQo+ID4+IGh0dHA6Ly90 cmFjLnRvb2xzLmlldGYub3JnL3dnL2dlb3ByaXYvdHJhYy90aWNrZXQvMjMpIEkgcmFpc2VkIGV2 ZXJ5DQo+ID4+IHRhcmdldCB3b3VsZCBiZSBnaXZlbiB0aGUgZXhhY3Qgc2FtZSBsb2NhdGlvbiBp bmZvcm1hdGlvbiBvbiBhDQo+IHNoYXJlZA0KPiA+PiBtZWRpdW0uIFNvLCB0aGlzIGlzIGRyYWZ0 LWlldGYtZ2VvcHJpdi1yZmMzODI1YmlzLg0KPiA+Pg0KPiA+PiBOb3RlOiBUaGUgZHJhZnQgdGhh dCB3YXMgZm9yd2FyZGVkIHRvIHRoZSBJRVNHIGRvZXMgbm90IHBvaW50IG91dA0KPiA+PiB0aGlz IGltcG9ydGFudCBzZWN1cml0eSBhc3BlY3QsIEkgYmVsaWV2ZS4NCj4gPj4NCj4gPj4gSWYgeW91 IGRvbid0IG1ha2UgdGhlIHNhbWUgYXNzdW1wdGlvbiBmb3IgdGhlIERIQ1AtVVJJIGRyYWZ0IHRo ZW4NCj4geW91DQo+ID4+IHN1ZGRlbmx5IGFsbG93IG90aGVycyB0byBtb2RpZnkgeW91ciBwb2xp Y2llcy4gVGhpcyB3b3VsZCBiZSByZWFsbHkNCj4gYmFkLg0KPiA+Pg0KPiA+PiBJZiB5b3UgbWFr ZSB0aGUgYXNzdW1wdGlvbiB0aGF0IGV2ZXJ5b25lIG9uIGEgc2hhcmVkIG1lZGl1bSBnZXRzIHRo ZQ0KPiA+PiBzYW1lIHBvaW50ZXIgdG8gbG9jYXRpb24gYW5kIGFsc28gcG9pbnRlciB0byBwb2xp Y3kgdGhlbiB5b3Ugc3RpbGwNCj4gPj4gYWxsb3cgb3RoZXJzIHRvIG1vZGlmeSB0aGUgcG9saWN5 IGJ1dCB0aGVyZSBpcyBhdCBsZWFzdCBubyBwcml2YWN5DQo+ID4+IGhhcm0gd2l0aCByZXZlYWxp bmcgbG9jYXRpb24gYnV0IHJhdGhlciBkZW5pYWwgb2Ygc2VydmljZS4NCj4gPj4NCj4gPj4gQ2lh bw0KPiA+PiBIYW5uZXMNCj4gPj4NCj4gPj4gT24gMzAuMDcuMjAxMCAxNDoyMywgUmljaGFyZCBM LiBCYXJuZXMgd3JvdGU6DQo+ID4+PiBTaW1wbGljaXR5OiBUaGlzIGRvY3VtZW50IGRvZXMgZXZl cnl0aGluZyB0aGF0IEhFTEQtQ29udGV4dCBkb2VzDQo+ID4+PiAoZXhjZXB0IGZvciA8c25hcHNo b3Q+KSwgd2l0aG91dCByZXF1aXJpbmcgYW55IG5ldyBYTUwuICAoQW5kDQo+ID4+PiA8c25hcHNo b3Q+IHNob3VsZCBiZSBhIHBvbGljeSBleHRlbnNpb24sIGFueXdheS4pDQo+ID4+Pg0KPiA+Pj4g R2VuZXJhbGl0eTogVGhpcyBkb2N1bWVudCBpcyBub3Qgc3BlY2lmaWMgdG8gSEVMRCwgc28gdGhh dCwgZS5nLiwNCj4gaXQNCj4gPj4+IGNhbiBiZSB1c2VkIHdpdGggREhDUC4NCj4gPj4+DQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+IE9uIEp1bCAzMCwgMjAxMCwgYXQgMjowNyBQTSwgSGFubmVzIFRzY2hv ZmVuaWcgd3JvdGU6DQo+ID4+Pg0KPiA+Pj4+IFdoeSBub3QgdXNlIHRoZSBleGlzdGluZyBIRUxE IENvbnRleHQgZG9jdW1lbnQ/DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+IE9uIDMwLjA3LjIwMTAg MTQ6MDUsIFJpY2hhcmQgTC4gQmFybmVzIHdyb3RlOg0KPiA+Pj4+PiBUaGUgb25seSBjb25jZXJu IHJhaXNlZCBpbiB0aGUgbWVldGluZyB3aXRoIHJlZ2FyZCB0bw0KPiA+Pj4+PiBkcmFmdC1iYXJu ZXMtZ2VvcHJpdi1wb2xpY3ktdXJpIHdhcyB3aGVuIEhhbm5lcyBub3RlZCB0aGF0IHRoZQ0KPiA+ Pj4+PiBleGNoYW5nZSBjb3VsZCBiZSBtYWRlIG1vcmUgZWZmaWNpZW50IChpbiB0aGUgSEVMRCBj b250ZXh0KQ0KPiA+Pj4+PiBvdmVybGF5aW5nIHRoZSBwb2xpY3kgaW50ZXJhY3Rpb25zIG9uIGEg SEVMRCB0cmFuc2FjdGlvbi4gIEZvcg0KPiA+Pj4+PiBleGFtcGxlLCB0aGUgY2xpZW50IGNvdWxk IHByb3ZpZGUgcG9saWN5IGRhdGEgaW4gYQ0KPiA+Pj4+PiA8bG9jYXRpb25SZXF1ZXN0PiBvYmpl Y3QsIGFuZCB0aGUgc2VydmVyIGNvdWxkIHNwZWNpZnkgcG9saWN5IGl0DQo+ID4+Pj4+IGludGVu ZHMgdG8gdXNlIGluIHRoZSA8bG9jYXRpb25SZXNwb25zZT4uICBJIHRoaW5rIHdlIHNob3VsZCBu b3QNCj4gPj4+Pj4gZG8gdGhpcy4NCj4gPj4+Pg0KPiA+Pg0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gR2VvcHJpdiBtYWlsaW5nIGxpc3QN Cj4gR2VvcHJpdkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2dlb3ByaXYNCg== From Martin.Thomson@andrew.com Fri Jul 30 17:07:45 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF5DF3A6910 for ; Fri, 30 Jul 2010 17:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.085 X-Spam-Level: X-Spam-Status: No, score=-3.085 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599] 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 Ardu3CvxpeHi for ; Fri, 30 Jul 2010 17:07:44 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 086373A6405 for ; Fri, 30 Jul 2010 17:07:44 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:54742 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S345040Ab0GaAIJ (ORCPT ); Fri, 30 Jul 2010 19:08:09 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Fri, 30 Jul 2010 19:08:09 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Sat, 31 Jul 2010 08:08:06 +0800 From: "Thomson, Martin" To: "geopriv@ietf.org" , "rjsparks@nostrum.com" , Hannes Tschofenig Date: Sat, 31 Jul 2010 08:08:05 +0800 Thread-Topic: location obscuring Thread-Index: AcswAH5D6/+JsKZ3RjmJNhzCv+nDDA== Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB773B17@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {F73B8216-0959-4EAD-B696-A5D2B0328F68} x-cr-hashedpuzzle: CoA/ DNU7 FHwn G2FR JPSp JUkz L0Ux MLLA NNl/ YNdb bpxk b0Lz eo4s fmbI ixEg kcLl; 3; ZwBlAG8AcAByAGkAdgBAAGkAZQB0AGYALgBvAHIAZwA7AGgAYQBuAG4AZQBzAC4AdABzAGMAaABvAGYAZQBuAGkAZwBAAGcAbQB4AC4AbgBlAHQAOwByAGoAcwBwAGEAcgBrAHMAQABuAG8AcwB0AHIAdQBtAC4AYwBvAG0A; Sosha1_v1; 7; {F73B8216-0959-4EAD-B696-A5D2B0328F68}; bQBhAHIAdABpAG4ALgB0AGgAbwBtAHMAbwBuAEAAYQBuAGQAcgBlAHcALgBjAG8AbQA=; Fri, 30 Jul 2010 16:01:38 GMT; bABvAGMAYQB0AGkAbwBuACAAbwBiAHMAYwB1AHIAaQBuAGcA acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: [Geopriv] location obscuring X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2010 00:07:45 -0000 V29ya2luZyBvbiB0aGlzIHByb2JsZW0gdGhyb3VnaG91dCB0aGlzIHdlZWsgaW4gbXkgc3BhcmUg dGltZSwgd2l0aCB0aGUgYWNjb3JkYW50IGxhY2sgb2Ygc2xlZXAgdGhhdCBnb2VzIHdpdGggYW4g SUVURiBtZWV0aW5nLCBJIGhhdmUgYmVlbiBmYWxsaW5nIGZvciBhIHRyYXAuICBUaGVyZSBpcyBh biB1bmRlcmx5aW5nIGluY29ycmVjdCBhc3N1bXB0aW9uIGFib3V0IHRoZSBwcm9ibGVtIHRoYXQg d2UndmUgYWxsIGZhbGxlbiBmb3IuDQoNClRoZSBsaWUgaW4gdGhlIGFzc3VtcHRpb24gaXMgcmV2 ZWFsZWQgYnkgdGhpcyBzdGF0ZW1lbnQ6DQoNCiBMb2NhdGlvbiBjYW4gY2hhbmdlLg0KDQpJZiB0 aGF0IGlzbid0IGVub3VnaCBvZiBhIGNsdWUsIGxldCBtZSBleHBsYWluLg0KDQpUaGUgbG9jYXRp b24gdGhhdCB3ZSBwcm92aWRlIGF0IGFueSBvbmUgaW5zdGFudCBtaWdodCBiZSBjb3JyZWN0IGZv ciB0aGF0IGluc3RhbnQsIGJ1dCB3ZSBhcmUgdW5kZXIgbm8gb2JsaWdhdGlvbiB0byBlbnN1cmUg dGhhdCB0aGUgbG9jYXRpb24gaXMgY29ycmVjdCBmb3IgdGhlIGZ1dHVyZS4gIA0KDQpBc3N1bWlu ZyBhcyB3ZSBkaWQgdGhhdCBsb2NhdGlvbiBpcyBjb25zdGFudGx5IGFuZCBwZXJmZWN0bHkgYXZh aWxhYmxlIGluIG91ciBzaW11bGF0aW9ucyBvZiB0aGUgb2JzY3VyaW5nIGFsZ29yaXRobSwgd2Ug Y29tcGxldGVseSBmZWxsIGZvciBpdC4NCg0KSW5zdGVhZCwgaGVyZSBpcyB3aGF0IEkgcHJvcG9z ZToNCg0KRm9yIGEgbG9jYXRpb24gd2l0aCBjZW50cm9pZCBDW25dLCB1bmNlcnRhaW50eSBVW25d IGFuZCBhbiBvYnNjdXJpbmcgZGlzdGFuY2UgRDoNCg0KICAxLiBXZSBvYnNjdXJlIGxvY2F0aW9u IGluZm9ybWF0aW9uIHVzaW5nIHRoZSBzaW1wbGUgYWxnb3JpdGhtOiBpbmNyZWFzZSB1bmNlcnRh aW50eSB0byBELCBhbmQgbW92ZSB0aGUgcG9pbnQgcmFuZG9tbHkgYnkgKEQgLSBVW3hdKS4gIElm IHRoZSB1bmNlcnRhaW50eSBpcyBhbHJlYWR5IGJpZyBlbm91Z2gsIGp1c3QgcGFzcyB0aGUgbG9j YXRpb24gb24uDQoNCiAgMi4gU2F2ZSB0aGUgb3JpZ2luYWwgcG9pbnQgYW5kIHN1cHByZXNzIGFu eSBmdXJ0aGVyIHJlcG9ydHMgYWJvdXQgdGhlIGxvY2F0aW9uIHVudGlsIHRoZSBjZW50cm9pZCBt b3ZlcyBhIGRpc3RhbmNlIG9mIG1vcmUgdGhhbiBEOyB0aGF0IGlzLCB1bnRpbCB8IENbeCt5XSAt IENbeF0gfCA+IEQuDQoNCiAgMy4gUmVwZWF0IGFkIG5hdXNldW0uDQoNCllvdSBzZWUsIGJ5IHN1 cHByZXNzaW5nIGxvY2F0aW9uIHVwZGF0ZXMgdW50aWwgdGhlIGxvY2F0aW9uIHdlIGtub3cgbW92 ZXMgbW9yZSB0aGFuIEQsIHRoZW4gd2UgaGlkZSBsb2NhdGlvbi4gIEluIGJldHdlZW4gdGltZXMs IHRoZXJlIGlzIG5vIHByb21pc2UgdGhhdCB0aGUgbG9jYXRpb24gaXMgd2l0aGluIHRoZSB1bmNl cnRhaW50eSByZWdpb24gcHJvdmlkZWQsIGFuZCBub3Igc2hvdWxkIHRoZXJlIGJlLg0KDQpJIHRo aW5rIHRoYXQgdGhpcyB3b3Jrcy4gIEkgbmVlZCBzb21lIHNsZWVwIGFuZCBhIGxpdHRsZSB0aW1l IHdpdGggYSBwaWVjZSBvZiBwYXBlciBhbmQgYSBwZW4gdG8gdmVyaWZ5IHRoaXMsIGJ1dCBJIHRo aW5rIHRoYXQgdGhpcyBpcyB0aGUgd2F5IGZvcndhcmQuDQoNCi0tTWFydGluDQo= From Martin.Thomson@andrew.com Fri Jul 30 17:07:45 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B7E63A6405 for ; Fri, 30 Jul 2010 17:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.079 X-Spam-Level: X-Spam-Status: No, score=-3.079 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599] 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 PgHFIgjifxhv for ; Fri, 30 Jul 2010 17:07:44 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 2B0883A6842 for ; Fri, 30 Jul 2010 17:07:44 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:33847 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S29073899Ab0GaAIJ (ORCPT ); Fri, 30 Jul 2010 19:08:09 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Fri, 30 Jul 2010 19:08:09 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Sat, 31 Jul 2010 08:08:06 +0800 From: "Thomson, Martin" To: "geopriv@ietf.org" Date: Sat, 31 Jul 2010 08:08:06 +0800 Thread-Topic: HELD and GET Thread-Index: AcswARO5gFZHpHepRfyKNFY6AMYSXg== Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB773B18@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {5A947D3F-CBC8-49B1-B237-4B60064ED8D9} x-cr-hashedpuzzle: Ac6q Djs/ D0DH Emwl FRV6 FSXc FVIR F2Bs HGZk HjQa HwmS IgD9 JeBV JgRK J8jW KhwD; 1; ZwBlAG8AcAByAGkAdgBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {5A947D3F-CBC8-49B1-B237-4B60064ED8D9}; bQBhAHIAdABpAG4ALgB0AGgAbwBtAHMAbwBuAEAAYQBuAGQAcgBlAHcALgBjAG8AbQA=; Fri, 30 Jul 2010 16:05:49 GMT;SABFAEwARAAgAGEAbgBkACAARwBFAFQA acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: [Geopriv] HELD and GET X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2010 00:07:45 -0000 SSd2ZSBoYWQgYSBsaXR0bGUgY2hhdCB3aXRoIHRoZSBIVFRQIGd1cnVzIChUaG9tYXMsIE1hcmss IFl2ZXMpIGFuZCBnb3R0ZW4gdGhlIGZlZWRiYWNrIHRoYXQgbm90IGRvaW5nIEdFVCB3b3VsZCBi ZS4uLnN0dXBpZC4NCg0KSSBhbSBzeW1wYXRoZXRpYyB0byB0aGUgc3VnZ2VzdGlvbiB0aGF0IG9u ZSBtZXRob2QgaXMgZWFzaWVyLCBidXQgaW4gdGhpcyBjYXNlLCB0aGUgZGVsdGEgaW4gdGVybXMg b2YgbWVjaGFuaXNtIGFuZCBpbXBsZW1lbnRhdGlvbiBpcyBzbyB0cml2aWFsLCBpdCdzIGFjdHVh bGx5IGhhcmQgdG8gaW1hZ2luZSBob3cgdGhpcyB3b3VsZCBiZSBhIGJhZCB0aGluZy4NCg0KT24g dGhlIGZsaXAgc2lkZSwgdGhlcmUgYXJlIHRvbyBtYW55IGNhc2VzIHdoZXJlIHdlIGJhc3RhcmRp c2VkIHRoZSB1c2Ugb2YgSFRUUCBpbiB0aGUgcGFzdC4gIEkgd291bGQgbGlrZSB0byBtYWtlIHNv bWUgc3RlcHMgdG8gcmVjdGlmeSB0aGlzLg0KDQotLU1hcnRpbg0KDQpwLnMuICBJIGRvbid0IG1p bmQgc2hhcmluZyB0aGlzLiAgVGhpcyBpcyBhbG1vc3QgZXhhY3RseSB3aGF0IHdlIGRvIGluIG91 ciBpbXBsZW1lbnRhdGlvbjoNCg0KaGFuZGxlUG9zdChyZXF1ZXN0KSB7DQogIGRvSEVMRChyZXF1 ZXN0LCByZXF1ZXN0LmJvZHkpOw0KfQ0KDQpoYW5kbGVHZXQocmVxdWVzdCkgew0KICBkb0hFTEQo cmVxdWVzdCwgcHJlYnVpbHRCb2R5KTsNCn0NCg== From Martin.Thomson@andrew.com Fri Jul 30 17:07:45 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E23C43A6405 for ; Fri, 30 Jul 2010 17:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.074 X-Spam-Level: X-Spam-Status: No, score=-3.074 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599] 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 qb2penUfSocn for ; Fri, 30 Jul 2010 17:07:44 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 577693A6888 for ; Fri, 30 Jul 2010 17:07:44 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:54998 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S29073892Ab0GaAIJ (ORCPT ); Fri, 30 Jul 2010 19:08:09 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Fri, 30 Jul 2010 19:08:09 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Sat, 31 Jul 2010 08:08:08 +0800 From: "Thomson, Martin" To: "geopriv@ietf.org" , "Peterson, Jon" Date: Sat, 31 Jul 2010 08:08:07 +0800 Thread-Topic: privacy and third party LIS discovery Thread-Index: AcswAgcnb2hjS+M9S7e5uLctCEBr+g== Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB773B19@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: [Geopriv] privacy and third party LIS discovery X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2010 00:07:46 -0000 VGhlIHF1ZXN0aW9uIG9mIHRoZSBwcml2YWN5IHN0b3J5IGZvciByZXMtZ3ctbGlzLWRpc2NvdmVy eSBjYW1lIHVwIGluIHRoZSBtZWV0aW5nLg0KDQpJdCdzIHRydWUgdGhhdCB0aGUgZHJhZnQgZG9l c24ndCBoYXZlIGEgc3RvcnkgYW5kIGl0IGRvZXMgbmVlZCBvbmUuDQoNCkhvd2V2ZXIsIHRoZSBj b21wbGFpbnRzIHRoYXQgSm9uIGhhZCAoYW5kIEkga25vdyB0aGF0IGhlIGlzIG5vdCBhbG9uZSBp biB0aGlzLCB0aGV5IGFyZSB2YWxpZCBjb21wbGFpbnRzKSB3ZXJlIG5vdCB3aXRoIHRoaXMgZHJh ZnQuDQoNClRoZSBjb21wbGFpbnRzIGFyZSBhbGwgcHJlZGljYXRlZCBvbiB0aGUgbm90aW9uIHRo YXQgdGhpcmQgcGFydHkgZGlzY292ZXJ5IGVuYWJsZXMgdGhlIHRoaXJkIHBhcnR5IHJlcXVlc3Qg c2NlbmFyaW8uICBUaGlzIHdvdWxkIG9ubHkgYmUgdHJ1ZSBpZiB0aGUgaWRlbnRpdHkgb2YgdGhl IExJUyB3ZXJlIGFueSBncmVhdCBzZWNyZXQuICBUaGlzIGlzIHdoYXQgTElTIGRpc2NvdmVyeSBz dGF0ZXMuDQoNClNvLCBpbiBhY3R1YWwgZmFjdCwgdGhlIGNvbmNlcm5zIHdlcmUgd2l0aCB0aGUg aGVsZC1pZGVudGl0eS1leHRlbnNpb25zIGRyYWZ0LiAgSSBkaXNjdXNzZWQgdGhpcyB3aXRoIEpv biBhbmQgaGUgc3RpbGwgYmVsaWV2ZXMgdGhhdCB3ZSBuZWVkIGEgYmV0dGVyIG9wZXJhdGlvbmFs IHN0b3J5IGluIHRoaXMgcmVnYXJkLiAgSSB3aWxsIGZvbGxvdyB0aGlzIHVwIHdpdGggaGltIGFu ZCBzZWUgd2hhdCB3ZSBjYW4gZG8gdG8gc29ydCB0aGlzIG91dC4NCg0KLS1NYXJ0aW4NCg== From rbarnes@bbn.com Fri Jul 30 17:45:22 2010 Return-Path: X-Original-To: geopriv@core3.amsl.com Delivered-To: geopriv@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96B403A67F2 for ; Fri, 30 Jul 2010 17:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599] 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 PrdFg8qcpCuE for ; Fri, 30 Jul 2010 17:45:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id B445D3A6405 for ; Fri, 30 Jul 2010 17:45:21 -0700 (PDT) Received: from [128.89.253.117] (port=51580 helo=[192.168.48.64]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Of0Cw-0008bF-0i; Fri, 30 Jul 2010 20:45:46 -0400 Message-Id: <2F2AA07B-07CC-4DCE-9BFC-9320F3AB7D24@bbn.com> From: "Richard L. Barnes" To: "Thomson, Martin" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03EB773B18@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 31 Jul 2010 02:45:45 +0200 References: <8B0A9FCBB9832F43971E38010638454F03EB773B18@SISPE7MB1.commscope.com> X-Mailer: Apple Mail (2.936) Cc: "geopriv@ietf.org" Subject: Re: [Geopriv] HELD and GET X-BeenThere: geopriv@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Geographic Location/Privacy List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2010 00:45:22 -0000 This seems sensible to me. It simplifies behavior for many clients and doesn't require much effort on the server. --Richard On Jul 31, 2010, at 2:08 AM, Thomson, Martin wrote: > I've had a little chat with the HTTP gurus (Thomas, Mark, Yves) and > gotten the feedback that not doing GET would be...stupid. > > I am sympathetic to the suggestion that one method is easier, but in > this case, the delta in terms of mechanism and implementation is so > trivial, it's actually hard to imagine how this would be a bad thing. > > On the flip side, there are too many cases where we bastardised the > use of HTTP in the past. I would like to make some steps to rectify > this. > > --Martin > > p.s. I don't mind sharing this. This is almost exactly what we do > in our implementation: > > handlePost(request) { > doHELD(request, request.body); > } > > handleGet(request) { > doHELD(request, prebuiltBody); > } > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www.ietf.org/mailman/listinfo/geopriv